Azure Time Series Insights Gen1 環境の計画

注意

Time Series Insights (TSI) サービスは、2025 年 3 月以降はサポートされなくなります。 できるだけ早く既存の TSI 環境を代替ソリューションに移行することを検討してください。 サポートの終了と移行の詳細については、こちらのドキュメントを参照してください。

注意事項

これは 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 日のデータ リテンション期間を構成できます。

データ リテンション期間の構成

  1. Azure Portal で、Time Series Insights 環境を選択します。

  2. [Time Series Insights 環境] ウィンドウで、 [設定] 下の [ストレージの構成] を選択します。

  3. [データ リテンション期間 (日)] ボックスに、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 億イベント)

Note

容量は直線的にスケーリングされるので、容量が 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 つのイベント ソースがサポートされています。

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 HubAzure 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 のイングレス エンジンによって、指定した参照データ セット内の対応するデータ行と結合されます。 増幅されたイベントは、その後、クエリに利用できます。 結合は、参照データセットに定義されている主キー列に基づきます。

Note

参照データは、遡及的に結合されることはありません。 構成されてアップロードされた後は、現在および将来のイングレス データのみが対応付けられ、参照データセットに結合されます。 大量の履歴データを 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 機能を有効にしてください。

Note

Azure が複数のリージョンにわたる可用性を有効にするように構成されている場合、Azure Time Series Insights でさらに複数のリージョンにわたる可用性を構成する必要はありません。

IoT ハブとイベント ハブ

次のような一部の Azure IoT サービスにも、組み込みのビジネス ディザスター リカバリー機能が含まれています。

Azure Time Series Insights を他のサービスと統合すると、ディザスター リカバリーの可能性が向上します。 たとえば、イベント ハブに送信されたテレメトリが、バックアップ Azure Blob Storage データベースに保持される場合があります。

Azure Time Series Insights

Azure Time Series Insights のデータ、アプリ、およびサービスが中断された場合でも、それらの実行を維持するためのいくつかの方法があります。

ただし、次の目的で、Azure Time Series 環境の完全なバックアップ コピーも要であると判断する場合があります。

  • データとトラフィックのリダイレクト先となる Azure Time Series Insights 専用の "フェールオーバー インスタンス" として
  • データおよび監査情報を保持するため

一般に、Azure Time Series Insights 環境を複製するための最善の方法は、バックアップ Azure リージョンに 2 つ目の Azure Time Series Insights 環境を作成することです。 イベントは、プライマリ イベント ソースからこのセカンダリ環境にも送信されます。 必ず 2 つ目の専用コンシューマー グループを使用してください。 前述のとおり、そのソースのビジネス ディザスター リカバリーのガイドラインに従います。

重複する環境を作成するには、以下の操作を行います。

  1. 2 つ目のリージョンに環境を作成します。 詳細については、Azure portal で新しい Azure Time Series Insights 環境を作成する方法に関するページを参照してください。
  2. イベント ソースの 2 つ目の専用コンシューマー グループを作成します。
  3. そのイベント ソースを新しい環境に接続します。 必ず 2 つ目の専用コンシューマー グループを指定してください。
  4. Azure Time Series Insights の IoT HubEvent Hub のドキュメントを確認します。

イベントが発生した場合:

  1. 障害インシデントの発生時にプライマリ リージョンが影響を受けた場合は、運用をバックアップの Azure Time Series Insights 環境に経路変更します。
  2. ハブ シーケンス番号は、フェールオーバー後に 0 から再開されるので、異なるコンシューマー グループを持つリージョンと環境の両方でイベント ソースを再作成して、重複イベントのようなものが作成されないようにします。
  3. 環境で使用可能なイベント ソースを解放するために、現在アクティブでないプライマリ イベント ソースを削除します。 (環境あたりのアクティブなイベント ソースの数は 2 つまでに制限されています。)
  4. 2 つ目のリージョンを使用して、すべての Azure Time Series Insights テレメトリとクエリ データをバックアップおよび復元します。

重要

フェールオーバーが発生した場合:

  • 遅延も発生することがあります。
  • 操作が再ルーティングされるため、メッセージの処理に瞬間的なスパイクが発生する可能性もあります。

詳細については、Azure Time Series Insights の待ち時間の短縮に関するページを参照してください。

次のステップ