Azure Stream Analytics ジョブでのチェックポイントと再生の概念
この記事では、Azure Stream Analytics の内部チェックポイントおよび再生の概念と、これらがジョブの回復に与える影響について説明します。 Stream Analytics ジョブが実行されるたびに、状態情報が内部的に維持されます。 状態情報は、チェックポイントに定期的に保存されます。 一部のシナリオでは、ジョブ エラーまたはアップグレードが発生した場合にチェックポイント情報がジョブの回復に使用されます。 その他の状況では、チェックポイントを回復に使用できず、再生が必要です。
一時的な要素のステートフルなクエリ ロジック
Azure Stream Analytics ジョブの固有の機能の 1 つに、ウィンドウ集計、一時的な結合、一時的な分析関数などのステートフル処理の実行があります。 ジョブの実行時には、これらの各演算子によって状態情報が保持されます。 これらのクエリ要素の最大ウィンドウ サイズは 7 日間です。
テンポラル ウィンドウの概念は、いくつかの Stream Analytics クエリ要素に現れます。
ウィンドウ集計 (タンブリング ウィンドウ、ホッピング ウィンドウ、スライディング ウィンドウの GROUP BY)
テンポラル結合 (DATEDIFF を使用した JOIN)
テンポラル分析関数 (LIMIT DURATION を使用した ISFIRST、LAST、LAG)
OS のアップグレードを含むノードの障害からのジョブの回復
Stream Analytics ジョブが実行されるたびに、そのジョブが複数のワーカー ノード上で動作するように内部的にスケールアウトされます。 各ワーカー ノードの状態は、数分ごとにチェックポイントが設定されます。これは、障害が発生した場合にシステムの回復に役立ちます。
指定したワーカー ノードに障害が発生する場合や、そのワーカー ノードでオペレーティング システムのアップグレードが発生する場合があります。 自動的に回復するために、Stream Analytics は新しい正常なノードを取得し、使用可能な最新のチェックポイントから以前のワーカー ノードの状態を復元します。 作業を再開するには、チェックポイントの作成時点以降の状態に復元するためにわずかな再生が必要です。 通常、復元の時間差はわずか数分です。 ジョブに対して十分なストリーミング ユニットが選択されていれば、再生はすぐに完了します。
完全に並列なクエリでは、ワーカー ノードの障害後のキャッチアップに要する時間は以下に比例します。
[入力イベント レート] x [時間差]/[処理中のパーティション数]
ノード障害と OS アップグレードが原因で大幅な処理遅延が発生する場合は、クエリを完全に並列化し、ジョブをスケーリングしてより多くのストリーミング ユニットを割り当てることを検討してください。 詳しくは、「スループット向上のために Azure Stream Analytics ジョブをスケーリングする」をご覧ください。
現在の Stream Analytics では、このような種類の回復プロセスの実行時にレポートは表示されません。
サービス アップグレードからのジョブの回復
マイクロソフトでは、Azure サービス内で Stream Analytics ジョブを実行するバイナリをアップグレードすることがあります。 このときに、ユーザーが実行中のジョブは新しいバージョンにアップグレードされ、ジョブが自動的に再起動されます。
Azure Stream Analytics では、チェックポイントが使用されます。チェックポイントが付けられた前回の状態からデータを復元できます。 内部チェックポイントを利用できないシナリオでは、ストリーミング クエリの状態が再生手法によって完全に復元されます。 Stream Analytics ジョブで以前と同じ入力を正確に再生できるようにするために、ソース データの保持ポリシーを少なくともクエリのウィンドウ サイズに設定することが重要です。 そうしないと、ソース データの保持期間がウィンドウ サイズ全体を含むのに十分な長さでない可能性があるので、サービスのアップグレード中に不正な結果や部分的にしかない結果が生じる可能性があります。
一般に、必要な再生の量は、ウィンドウのサイズに平均イベント レートを掛けた値に比例します。 たとえば、入力レートが 1 秒あたり 1,000 イベントのジョブの場合、1 時間を超えるウィンドウ サイズには大きな再生サイズがあるものと見なされます。 完全で正しい結果が得られるように状態を初期化するのに最大で 1 時間分のデータを再処理することが必要になる場合があるため、長時間にわたって出力の遅延 (出力なし) が生じることがあります。 ウィンドウや他の一時的な演算子 (JOIN、LAG など) がないクエリは、再生がゼロになります。
再生キャッチアップ時間の見積もり
サービス アップグレードを原因とする遅延の長さを見積もるには、次の手法を使用できます。
予期されるイベント レートで、クエリの最大ウィンドウ サイズを十分にカバーするデータを含む入力イベント ハブを読み込みます。 イベントのタイムスタンプは、ライブ入力フィードであるかのように、その期間全体にわたって実時間とほぼ同じである必要があります。 たとえば、クエリに 3 日のウィンドウがある場合は、3 日間にわたってイベント ハブにイベントを送信し、イベントの送信を続けます。
開始時刻として [Now](今すぐ) を使用してジョブを開始します。
開始時刻から最初の出力が生成される時点までの時間を測定します。 この時間は、サービスのアップグレード中にジョブで発生するおおよその遅延です。
遅延が長すぎる場合は、ジョブをパーティション分割し、SU の数を増やして、負荷がより多くのノードに分散されるようにしてみます。 または、クエリのウィンドウ サイズを小さくし、(たとえば、Azure SQL Database を使用して) ダウンストリームのシンク内の Stream Analytics ジョブによって生成される出力に対して、集計またはその他のステートフル処理をさらに実行することを検討します。
ミッション クリティカルなジョブのアップグレード中のサービスの安定性に関する一般的な懸念事項がある場合は、ペアになる Azure リージョン内での重複ジョブの実行を検討してください。 詳しくは、「サービス更新中における Stream Analytics ジョブの信頼性を保証する」をご覧ください。
ユーザーが開始した停止および開始からのジョブの回復
ストリーミング ジョブ上でクエリ構文を編集したり、入力と出力を調整したりするには、ジョブを停止して、ジョブの設計を変更およびアップグレードする必要があります。 このようなシナリオでは、ユーザーがストリーミング ジョブを停止してもう一度開始する場合、回復シナリオはサービスのアップグレードに似ています。
チェックポイント データは、ユーザーが開始したジョブの再開に使用できません。 このような再開中の出力の遅延を見積もるには前のセクションで説明したのと同じ手順を使用し、遅延時間が長すぎる場合には同様の軽減策を適用します。
次のステップ
信頼性とスケーラビリティについて詳しくは、以下の記事をご覧ください。