注
Time Series Insights サービスは、2024 年 7 月 7 日に廃止されます。 既存の環境をできるだけ早く別のソリューションに移行することを検討してください。 非推奨と移行の詳細については、
注意事項
これは Gen1 の記事です。
この記事では、予想されるイングレス レートとデータ リテンション期間の要件に基づいて、Azure Time Series Insights Gen1 環境を計画する方法について説明します。
ビデオ
Azure Time Series Insights でのデータ リテンション期間と、その計画方法について詳細を確認するには、以下のビデオをご覧ください。
ベスト プラクティス
Azure Time Series Insights の使用を開始するには、分単位でプッシュすることが予想されるデータの量と、データを保存する必要がある期間を把握しておくことをお勧めします。
Azure Time Series Insights の 2 つの SKU の容量とリテンション期間の詳細については、「Azure Time Series Insights の価格」をご覧ください。
長期的な成功に向けて Azure Time Series Insights 環境を最善に計画するには、次の属性を検討します。
ストレージ容量
既定では、Azure Time Series Insights は、プロビジョニングするストレージの容量 (ユニット×ユニットごとのストレージ容量) とイングレスに基づいてデータを保持します。
データの保持
お使いの Azure Time Series Insights 環境内で [データ リテンション期間] 設定を変更できます。 リテンション期間は最大 400 日まで有効にできます。
Azure Time Series Insights には 2 つのモードがあります。
- 1 つのモードでは、最新のデータに対して最適化されます。 古いデータを消去するポリシーが強制され、最近のデータをインスタンスで利用できるように残します。 このモードは、既定でオンになっています。
- もう 1 つのモードでは、構成されているリテンション制限を下回るようにデータが最適化されます。 [Pause ingress]\(イングレスを一時停止\) がストレージ上限の超過動作として選択されているとき、新しいデータのイングレスが防止されます。
Azure portal 内の環境の構成ページ上で、リテンション期間を調整し、2 つのモードを切り替えることができます。
重要
Azure Time Series Insights Gen1 環境では、最大 400 日のデータ リテンション期間を構成できます。
データ保有期間を構成する
Azure Portal で、Time Series Insights 環境を選択します。
[Time Series Insights 環境] ウィンドウで、[設定] 下の [ストレージの構成] を選択します。
[データ リテンション期間 (日)] ボックスに、1 から 400 までの値を入力します。
ヒント
適切なデータ リテンション ポリシーの実装方法について詳しくは、リテンション期間の構成方法に関する記事をご覧ください。
イングレス容量
次に、Azure Time Series Insights Gen1 の主な制限の概要を示します。
SKU のイングレス レートと容量
新しい Azure Time Series Insights 環境を構成する場合、S1 および S2 SKU のイングレス レートと容量には柔軟性があります。 SKU の容量は、格納されているイベント数またはバイト数のいずれか早い方に基づいて、1 日のイングレス レートを示します。 イングレスは分単位で測定され、トークン バケット アルゴリズムを使用してスロットリングが適用される点に留意してください。 イングレスは 1 KB のブロック単位で測定されます。 たとえば、0.8 KB の実際のイベントは 1 つのイベントとして測定され、2.6 KB のイベントは 3 つのイベントとしてカウントされます。
| S1 SKU の容量 | イングレス レート | 最大ストレージ容量 |
|---|---|---|
| 1 | 1 日あたり 1 GB (100 万イベント) | 30 GB (3,000 万イベント) |
| 10 | 1 日あたり 10 GB (1,000 万イベント) | 300 GB (3 億イベント) |
| S2 SKU の容量 | イングレス レート | 最大ストレージ容量 |
|---|---|---|
| 1 | 1 日あたり 10 GB (1,000 万イベント) | 300 GB (3 億イベント) |
| 10 | 1 日あたり 100 GB (1 億イベント) | 3 TB (30 億イベント) |
注
容量は直線的にスケーリングされるので、容量が 2 の S1 SKU であれば、サポートされるイベント受信レートは 1 日あたり 2 GB (200 万)、1 か月あたり 60 GB (6,000 万イベント) となります。
S2 SKU 環境では、サポートされる 1 か月あたりのイベント数が大幅に増え、イングレス容量が大幅に増えました。
| SKU（在庫管理単位） | 1 か月あたりのイベント数 | 1 分あたりのイベント数 | 1 分あたりのイベント サイズ |
|---|---|---|---|
| S1 | 30,000,000 | 720 | 720 KB |
| S2 | 300,000,000 | 7,200 | 7,200 KB |
プロパティの制限
Gen1 プロパティの制限は、選択されている SKU 環境によって異なります。 指定されたイベント プロパティには、対応する JSON、CSV、およびグラフの列があり、Azure Time Series Insights エクスプローラー内で表示できます。
| SKU（在庫管理単位） | 最大特性 |
|---|---|
| S1 | 600 プロパティ（列） |
| S2 | 800 属性（列） |
イベントの発生源
インスタンスごとに最大 2 つのイベント ソースがサポートされています。
- イベント ハブ ソースを追加する方法を学習します。
- IoT ハブ ソースを構成します。
API の制限
Azure Time Series Insights Gen1 の REST API の制限については、REST API リファレンス ドキュメントを参照してください。
環境計画
Azure Time Series Insights 環境を計画する場合に注目すべき 2 つ目の分野は、イングレス容量です。 1 日あたりのイングレス ストレージとイベント容量は、1 KB ブロック単位で 1 分ごとに測定されます。 最大許容パケット サイズは 32 KB です。 32 KB を超えるデータ パケットは切り捨てられます。
1 つの環境で、S1 SKU または S2 SKU の容量を 10 ユニットまで増やすことができます。 S1 環境から S2 に移行することはできません。 S2 環境から S1 に移行することはできません。
イングレス容量については、最初に、1 か月単位を基にして必要な合計イングレスを決定します。 次に、分単位でのニーズを決定します。
分単位の容量にはスロットリングとレイテンシーが影響します。 データ イングレスのスパイクの持続時間が 24 時間未満の場合、Azure Time Series Insights では、上の表に示したレートの 2 倍のイングレス レートまで "キャッチアップ" することが可能です。
たとえば、単一の S1 SKU を用意して 1 分あたり 720 イベントのレートでデータをイングレスすると、データ レートのスパイクが 1440 イベント以下のレートで 1 時間未満であれば、環境内で顕著な待機時間は発生しません。 ただし、1 分あたり 1440 イベントを超える状態が 1 時間以上続いた場合、環境内では、視覚化されクエリに使用できるデータに待機時間が発生する傾向があります。
プッシュすることが予想されるデータの量が事前にわからない場合があります。 この場合、Azure portal サブスクリプションで Azure IoT Hub と Azure Event Hubs のデータ テレメトリを確認できます。 テレメトリは、環境をプロビジョニングする方法を決定する際に役立ちます。 Azure portal にあるそれぞれのイベント ソースの [メトリック] ウィンドウを使用して、テレメトリを表示します。 イベント ソースのメトリックを理解すると、Azure Time Series Insights 環境をより効果的に計画し、プロビジョニングできます。
イングレス要件の計算
イングレス要件を計算するには:
イングレス容量が 1 分あたりの平均レートを上回っていることを確認し、環境が、用意している容量の 2 倍に相当する予想されるイングレスを 1 時間未満で十分に処理できる規模であることを確認します。
1 時間を超えて持続するイングレスのスパイクが発生した場合、そのスパイク レートを平均として使用します。 スパイク レートを処理するために、その容量を備えた環境をプロビジョニングします。
スロットリングとレイテンシーの軽減
調整と待機時間が発生しないようにする方法については、待機時間と調整の緩和に関する記事をご覧ください。
イベントを企画する
Azure Time Series Insights へイベントを送信する方法によって、プロビジョニングしている環境のサイズが確実にサポートされることが重要です。 (逆に、Azure Time Series Insights が読み取るイベント数と各イベントのサイズに対して、環境のサイズをマップできます。)また、データにクエリを実行する際に、必要に応じてスライスとフィルターに使用する属性を検討することも重要です。
ヒント
イベントの送信に関するページで、JSON の整形のドキュメントを参照してください。
参照データの確認
参照データセットは、イベント ソースからのイベントを増幅する項目の集まりです。 イベント ソースから受信した各イベントは、Azure Time Series Insights のイングレス エンジンによって、指定した参照データ セット内の対応するデータ行と結合されます。 増幅されたイベントは、その後、クエリに利用できます。 結合は、参照データセットに定義されている主キー列に基づきます。
注
参照データは、遡及的に結合されることはありません。 構成されてアップロードされた後は、現在および将来のイングレス データのみが対応付けられ、参照データセットに結合されます。 大量の履歴データを Azure Time Series Insights に送信することを計画している場合、Azure Time Series Insights 内で最初に参照データのアップロードや作成を行わないと、作業をやり直す必要が生じることがあります (ちなみに、楽しいことではありません)。
Azure Time Series Insights での参照データの作成、アップロード、管理方法について詳しくは、参照データセットのドキュメントをご覧ください。
ビジネス ディザスター リカバリー
このセクションでは、障害が発生した場合でもアプリとサービスを実行し続ける Azure Time Series Insights の機能について説明します (ビジネス ディザスター リカバリーと呼ばれます)。
高可用性
Azure Time Series Insights は、Azure サービスとして、Azure リージョン レベルで冗長性を使用して、特定の 高可用性 機能を提供します。 たとえば、Azure では、リージョン間の可用性 機能を使用して、Azure の
Azure を通じて提供される追加の高可用性機能 (および Azure Time Series Insights インスタンスでも使用できる機能) は次のとおりです。
フェールオーバー : Azure では、地理的レプリケーションと負荷分散を提供しています。 データ復元の とストレージの回復: Azure には、データを保持および回復するための オプションがいくつか用意されています。 Azure Site Recovery : Azure は、Azure Site Recoveryを通じて復旧機能提供します。 - Azure Backup: Azure Backup では、Azure VM のオンプレミスバックアップとクラウド内バックアップの両方がサポートされます。
関連する Azure 機能を有効にして、デバイスとユーザーにグローバルなリージョン間の高可用性を提供してください。
注
リージョン間の可用性を有効にするように Azure が構成されている場合、Azure Time Series Insights でリージョン間の可用性の構成を追加する必要はありません。
IoT とイベント ハブ
一部の Azure IoT サービスには、組み込みのビジネス ディザスター リカバリー機能も含まれています。
- リージョン内の冗長性を含む Azure IoT Hubのディザスター リカバリー（高可用性）
- Azure Event Hubs ポリシー を設定する
- Azure Storage の冗長性
Azure Time Series Insights を他のサービスと統合すると、追加のディザスター リカバリーの機会が提供されます。 たとえば、イベント ハブに送信されたテレメトリは、バックアップ Azure Blob Storage データベースに保持される場合があります。
Azure Time Series Insights（Azure 時系列インサイト）
中断された場合でも、Azure Time Series Insights のデータ、アプリ、サービスを実行し続けるには、いくつかの方法があります。
ただし、次の目的で、Azure Time Series 環境の完全バックアップ コピーも必要であると判断する場合があります。
- フェールオーバー インスタンス は、特に Azure Time Series Insights に対してデータとトラフィックをリダイレクトするために使用されます。
- データと監査情報を保持するには
一般に、Azure Time Series Insights 環境を複製する最善の方法は、バックアップ Azure リージョンに 2 つ目の Azure Time Series Insights 環境を作成することです。 イベントは、プライマリ イベント ソースからこのセカンダリ環境にも送信されます。 2 つ目の専用コンシューマー グループを使用していることを確認します。 前述のように、そのソースのビジネス ディザスター リカバリー ガイドラインに従ってください。
重複する環境を作成するには:
- 2 番目のリージョンに環境を作成します。 詳細については、「Azure portalで新しい Azure Time Series Insights 環境を作成する」を参照してください。
- イベント ソース用の 2 つ目の専用コンシューマー グループを作成します。
- そのイベント ソースを新しい環境に接続します。 2 番目の専用コンシューマー グループを指定していることを確認します。
- Azure Time Series Insights 、IoT Hub および Event Hubs 、 のドキュメントを確認します。
イベントが発生した場合:
- ディザスター インシデントの発生時にプライマリ リージョンが影響を受ける場合は、Azure Time Series Insights のバックアップ環境に操作を再ルーティングします。
- フェールオーバー後にハブ シーケンス番号が 0 から再起動されるため、重複するイベントのような外観を作成しないように、コンシューマー グループが異なる両方のリージョン/環境でイベント ソースを再作成します。
- 現在は非アクティブになっているプライマリ イベント ソースを削除して、環境で使用可能なイベント ソースを解放します。 (環境ごとに 2 つのアクティブなイベント ソースに制限があります)。
- 2 番目のリージョンを使用して、すべての Azure Time Series Insights テレメトリとクエリ データをバックアップおよび復旧します。
重要
フェールオーバーが発生した場合:
- 遅延も発生する可能性があります。
- 操作が再ルーティングされるため、メッセージ処理の一時的な急増が発生する可能性があります。
詳細については、「Azure Time Series Insightsの待機時間を軽減する」を参照してください。
次のステップ
Azure portal で新しい Azure Time Series Insights 環境を作成することから開始します。
Azure Time Series Insights にイベント ハブのイベント ソースを追加する方法を学習します。
IoT Hub イベント ソースを構成する方法を参照します。