Azure Stream Analyticsはジョブが実行されるたびに内部で状態情報を管理し、定期的にその状態をチェックポイントに保存します。 ジョブが失敗したりアップグレードされた場合、Stream Analyticsは最新のチェックポイントを使って回復できます。 ジョブがチェックポイントを使えない場合は、代わりにリプレイを行い、最近の入力イベントを再処理して状態を再構築します。
この記事では、Azure Stream Analyticsにおけるチェックポイントとリプレイの仕組みと、ジョブの復旧にかかる時間にどのように影響するかを説明します。
一時的な要素のステートフルなクエリ ロジック
Azure Stream Analyticsジョブのユニークな機能の一つは、ウィンドウ付き集約、時間結合、時間解析関数などのステートフル処理を行うことです。 これらの各演算子は、ジョブの実行時に状態情報を保持します。 これらのクエリ要素の最大ウィンドウ サイズは 7 日間です。
テンポラル ウィンドウの概念は、いくつかの Stream Analytics クエリ要素に現れます。
- ウィンドウ集計 (タンブリング ウィンドウ、ホッピング ウィンドウ、スライディング ウィンドウの GROUP BY)
- テンポラル結合 (DATEDIFF を使用した JOIN)
- テンポラル分析関数 (LIMIT DURATION を使用した ISFIRST、LAST、LAG)
OS のアップグレードを含む、ノード障害からのジョブの復旧
Stream Analyticsのジョブが実行されるたびに、サービスは内部的にスケールアウトして複数のワーカーノードにまたがって作業を行います。 サービスは数分ごとに各ワーカーノードの状態をチェックポイントし、障害が発生した場合に復旧できるようにします。
時には、あるワーカーノードが故障したり、そのワーカーノードでオペレーティングシステムのアップグレードが行われることがあります。 自動的に回復するために、Stream Analyticsは新しい健康なノードを取得し、最新の利用可能なチェックポイントから前のワーカーノードの状態を復元します。 作業を再開するために、ジョブは少量のデータを再生し、直近のチェックポイントの状態を復元します。 通常、復元のギャップはわずか数分です。 十分なストリーミングユニットを選べば、リプレイはすぐに完了します。
完全並列クエリでは、ワーカーノードの障害後に追いつくためにかかる時間は次の要素に比例します。
[入力イベントレート] x [ギャップ長] / [処理パーティション数]
ノード障害やOSアップグレードで処理遅延が大きく起きた場合は、クエリを完全並列にし、より多くのストリーミングユニットを割り当てるために作業を拡大することを検討してください。 詳細については、「 スループットを向上させるために Azure Stream Analytics ジョブをスケーリングする」を参照してください。
Stream Analyticsは現在、このような回復プロセスが行われている際のレポートを表示していません。
サービスのアップグレードによるジョブの復旧
Microsoft は、Azure サービスで Stream Analytics ジョブを実行するバイナリをアップグレードすることがあります。 この時点で、Microsoftは実行中のジョブを新しいバージョンにアップグレードし、ジョブは自動的に再起動します。
Azure Stream Analytics では、可能な限りチェックポイントを使用して、最後にチェックポイントが設定された状態からデータを復元します。 ストリームアナリティクスが内部チェックポイントを使えない場合、リプレイ技術でストリーミングクエリの全状態を復元します。 Stream Analyticsのジョブがまったく同じ入力を再生できるようにするには、ソースデータの保持ポリシーを少なくともクエリ内のウィンドウサイズに設定してください。 これを怠ると、サービスアップグレード時に誤った結果や部分的な結果になる可能性があります。なぜなら、Stream Analyticsはソースデータを十分に遡って保持し、ウィンドウサイズ全体を含めることができないからです。
一般に、必要な再生の量は、ウィンドウのサイズに平均イベント レートを乗算した値に比例します。 例えば、入力速度が1,000イベント/秒のジョブの場合、ウィンドウサイズが1時間を超えるほどリプレイサイズが大きくなります。 サービスは状態を初期化するために最大1時間分のデータを再処理する必要があるため、長期間にわたり出力遅延(出力なし)が発生することがあります。 ウィンドウや他の時間演算子( JOIN や LAGなど)がないクエリはリプレイが全くありません。
再生のキャッチアップ時間を見積もる
サービスアップグレードによる遅延の長さを推定するには、以下の手法に従ってください。
- 入力イベントハブに、予想されるイベントレートでクエリの最大のウィンドウサイズをカバーできる十分なデータをロードします。 イベントのタイムスタンプはその期間中、壁時計の時間に近いもので、まるでライブ入力フィードのように扱うべきです。 例えば、クエリに3日間のウィンドウがある場合は、イベントハブに3日間イベントを送信し、その後もイベントを送信し続けます。
- 「 今 」を開始時間として作業を始めましょう。
- 開始時刻からジョブが最初の出力を生成するまでの時間を測定します。 この時間はサービスアップグレード中に作業が発生する遅延の大まかさです。
- 遅延が長すぎる場合は、ジョブを分割してストリーミングユニットの数を増やし、負荷をより多くのノードに分散させてみてください。 あるいは、クエリのウィンドウサイズを縮小し、Stream Analyticsジョブが下流のシンクで生成する出力に対してさらに集約やその他の状態処理を行うことも検討してください(例えばAzure SQL Databaseの使用など)。
ミッション クリティカルなジョブのアップグレード中のサービスの安定性に関する一般的な問題については、ペアの Azure リージョンで重複するジョブを実行することを検討してください。 詳細については、「 サービスの更新中に Stream Analytics ジョブの信頼性を保証する」を参照してください。
ユーザーによる停止および再開後のジョブの復旧
ストリーミングジョブのクエリ構文を編集したり、入力・出力を調整したりするには、ジョブを停止して変更やジョブデザインのアップグレードを行う必要があります。 そのような場合、ストリーミングジョブを停止して再開すると、復旧のシナリオはサービスのアップグレードに似ています。
ユーザー主導のジョブ再起動はチェックポイントデータを使用できません。 このような再起動中の出力遅延を推定するには、前節で説明した手順を用い、遅延が長すぎる場合は同様の緩和策を適用してください。
関連するコンテンツ
信頼性とスケーラビリティの詳細については、次の記事を参照してください。