Azure Time Series Insights Gen1 環境の計画

[アーティクル]
06/01/2023

Note

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 億イベント)

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 つのイベントソースがサポートされています。

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

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 では geo レプリケーションと負荷分散が提供されます。
データの復元 と ストレージの回復: Azure には、データを保持および回復するための複数のオプションが用意されています。
Azure Site Recovery: Azure は、Azure Site Recovery を通じた復旧機能を提供します。
Azure Backup: Azure Backup は、Azure VM のオンプレミスおよびクラウド内バックアップの両方をサポートしています。

デバイスやユーザーにグローバルで複数のリージョンにわたる高可用性を提供するには、必ず関連する Azure 機能を有効にしてください。

Note

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

IoT ハブとイベントハブ

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

Azure IoT Hub の高可用ディザスターリカバリー (リージョン内の冗長性が含まれます)
Azure Event Hubs ポリシー
Azure Storage の冗長性

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