Amazon Web Services ブログ
Amazon CloudWatch を活用した Amazon Kinesis Data Firehose 配信ストリームの状態の把握
本記事は Amazon Web Services, Startup Solutions Architect Manager である Alon Gendler によって投稿されたものです。
世界中で生成されるデータの量の増加がますます加速しています。データは、IoT、広告、ゲーム、セキュリティ監視、機械学習 (ML) など、増え続けるユースケースをサポートするために生成されています。これらのユースケースの発展がストリーミングデータの量と速度の両方を駆動させた結果、企業はデータをニアリアルタイムで取得、処理、変換、分析、さまざまなデータストアに取り込む必要が出てきています。
Amazon Kinesis Data Firehose は、ストリーミングデータをデータレイク、データストア、分析サービスに確実にロードする最も簡単な手段です。Kinesis Data Firehose に送信されるデータの量が増えると、データの取り込み、変換、配信の状態を把握し、監視することが必要になります。
本記事では、Firehose 配信ストリームのメトリクスと Kinesis Data Firehose コンソールにある Amazon CloudWatch ダッシュボードの機能について説明します。これらの機能により、Kinesis Data Firehose で設定された送信先において権限不足、設定の誤り、またはその他の問題が Firehose により検知され障害として報告されたことに対するアラームの作成が可能になります。また、Lambda を使ったデータ変換 が設定されている場合、 Lambda 関数の呼び出しの失敗、AWS アカウントに関連付けられている Kinesis Firehose クォータ への到達、といったエラーも生じえます。このようなエラー発生の場合、Kinesis Data Firehose から送信先へのデータ配信が遅れたり、失敗したりする可能性があります。この記事で説明する CloudWatch アラームは、このような事態を迅速に特定するのに役に立ちます。
また、この記事では、クォータの引き上げリクエストの送信、データプロデューサーでのエクスポネンシャルバックオフのような、アラームをトリガーにしたさまざまなプロアクティブなアクションについても紹介します。
配信ストリームを監視し、必要なアクションを実行することで、データが途切れることなく送信先に配信され、リアルタイムでビジネスに役立つインサイトが得られます。
Kinesis Data Firehose へのデータ取り込みの監視
データプロデューサーから Kinesis Data Firehose へのデータの送信は、Amazon Kinesis Data Streams (本記事で後述)、Kinesis Agent、または PutRecord や PutRecordBatch といった Kinesis Data Firehose API オペレーションによって行えます。Kinesis Data Streams をデータソースとして使用するとき、Kinesis Data Firehose は Kinesis Data Stream のスケーリングに合わせて自動的にスケーリングされます。API オペレーションで直接データを取り込む場合は、API リクエストのスロットリングを回避するために、AWS アカウントに関連付けられているクォータを把握する必要があります。データプロデューサーの動作によっては、このスロットリングがデータプロデューサーでのリトライに繋がり、データの配信に遅延が発生する可能性があります。また、データプロデューサーでリトライ機構が実装されていない場合、スロットリングがデータの欠損につながる可能性があります。
Firehose 配信ストリームの使用状況に関するより深いインサイトを得るためのクォータをモニタリングし、プロアクティブにスケーリングさせるのに役立つCloudWatch メトリクスとして、ThrottledRecords、 RecordsPerSecondLimit、BytesPerSecondLimit、および PutRequestsPerSecondLimit が挙げられます。Kinesis Data Firehose コンソールの Monitoring タブにある CloudWatch メトリクスダッシュボードを使うことで、現在の使用量とクォータを簡単に可視化できます。
PutRecord または PutRecordBatch を使ってデータを配信ストリームに直接取り込む場合、ThrottledRecords メトリクスを監視することを推奨します。このメトリクスは、データの取り込みが配信ストリームのいずれかの制限を超過したことによりスロットリングされたレコード数を示します。Kinesis Data Firehose では、取り込み中のスロットリングレートが 1 秒単位で計算されます。しかしながら、前述のメトリクスは CloudWatch に集計、送信される単位は5 分です。そのため、データ取り込みメトリクス上、制限に達したように見えなくても、その 5 分間のウィンドウ内でスロットリングが発生する可能性があります。
データプロデューサーが実際にスロットリングされる前にアラームを受けるには、配信ストリームのいずれかの上限に達する前に発火する、追加の CloudWatch メトリクスを使ったアラームを作成すれば良いです。具体的に、IncomingRecords、IncomingBytes、IncomingPutRequests という CloudWatch メトリクスを使用すれば実現できます。これらのメトリクスの制限を確認するには、Amazon Kinesis Data Firehose のクォータを参照してください。
CloudWatch アラームの作成には、次の取り込みメトリクスとそれらに対応する制限メトリクスを用いることができます:
- RecordsPerSecondLimit – 1 秒あたり取り込むことができるレコードの最大数 (
IncomingRecords) - BytesPerSecondLimit – 1 秒あたり取り込むことができるデータの最大量 (
IncomingBytes) - PutRequestsPerSecondLimit – 1 秒あたり正常に実行できる
PutRecordおよびPutRecordBatchAPI リクエストの最大数 (IncomingPutRequests)
取り込みレートが制限に近づいたときのアラームを設定するには、取り込みレートとそれに対応する制限との関係をパーセンテージで確認します。Kinesis Data Firehose のメトリクスが CloudWatch に 5 分間隔で送信されるため、このメトリクスを5分という集約期間の長さを秒単位で表したもの (300 秒) で割る必要があります。たとえば、1 秒あたりの受信レコード数が API オペレーションクォータの 80% を超えたときにアラームを発火させたい場合、CloudWatch アラームは次のように定義されます:
このような定義では、取り込みレートがどのくらい制限に近いかをプロアクティブに把握することができ、パーセンテージを変更することでユースケースに応じて柔軟に変更できます。スロットリングにつながるボトルネックを防ぐには、上述の3つの配信ストリーム取り込みレートメトリクスを個別に監視することが重要です。
CloudWatch アラームを使用したアラームの定義
CloudWatch アラームは、AWS マネジメントコンソールを使って手動で定義するか、AWS CloudFormation で定義することができます。CloudFormation テンプレートを使った方法から始め、両方の方法について説明します。
以下のテンプレートは CloudWatch アラームを作成します。これらのアラームは、ニーズに合わせてカスタマイズできます。
スタックを作成する際に、監視対象の Firehose 配信ストリーム名と、通知を受けとりたいクォータの使用割合 (80% など) を指定します。スタックの作成が成功すると、4 つの CloudWatch アラームが作成されます。
コンソールから CloudWatch アラームを手動で作成ために、次の手順を実施します:
- Kinesis Data Firehose コンソールで、配信ストリームを選択肢します。
- Monitoring タブで、監視したいメトリクスの
その他のオプションアイコンを選択します (この例では、1 秒あたりの受信レコードを監視しています)。 - オプションメニューのメトリクスで表示を選択します。
CloudWatch コンソールでは、現在の API オペレーション数 (青線) とクォータ (赤線) を示すグラフが表示されます。
- アラームを作成するには、数式を追加を選択します。
- 一般を選択してパーセンテージを選択します
- グラフの左上の編集ボタンを選択し、
1 秒あたりのレコード数のクォータ割合を入力します。 - メトリクス式は
100*(e1/m2)となっています。これは、前述の100*(BytesPerSecond/BytesPerSecondLimit)という数式を表し、クォータの上限にどれだけ近づいているかを割合で表したものです。 - メトリクス
e1の式をMETRICS("m1")/300からm1/300に変更します。
Y 軸のラベルも変更できます。
- グラフオプションタブを選択し、Left Y Axis セクションのラベルに
割合と入力します。
- アラームに使用する式が完成したので、ページ上の他の式とメトリクスをすべて選択解除します。
作成した式のみが選択されていることを確認します。
CloudWatch アラームの作成
ここまでの手順でアラームのベースとして使える、IncomingRecordsとRecordsPerSecondクォータを監視するための式を作成しました。これで、ビジネスユースケースが要求する許容レベルを調整することができます。
- 作成した式の横にあるアラームアイコンを選択します。
- メトリクスと条件の指定セクションで、アラームが制限の 75% を超えたときにアラームを発火するように入力します。
- アクションの設定セクションで、アラームの転送方法を指定します。
このアラームは、Amazon Simple Notification Service (Amazon SNS) トピックを通じて、監視システム、もしくはメールアドレスに転送することができます。この記事では、新しい SNS トピックを作成し、admin@example.com を購読させます。
制限に近づいたときに実行できるアクション
制限に近づいたら、このセクションで説明するいくつかのアクションを取ることができます。
クォータの引き上げをリクエストする
アラームが発火したときに実行できるアクションの 1 つは、Amazon Kinesis Data Firehose 制限緩和フォームを使用してクォータの引き上げをリクエストすることです。3 つのクォータはそれぞれ他の値に比例する形で増加します。たとえば、米国東部 (バージニア北部)、米国西部 (オレゴン)、またはヨーロッパ (アイルランド) のスループットクォータを 5 MiB/秒から 10 MiB/秒に増やすと、残りの 2 つのクォータは 2,000 リクエスト/秒から 4,000 リクエスト/秒に、500,000 レコード/秒から 1,000,000レコード/秒に増加します。AWS リージョン別のサービスクォータの詳細については、Amazon Kinesis Data Firehose クォータをご参照してください。
PutRecordBatch API を使用する
API コール PutRecord を使用して Firehose 配信ストリームにイベントを書き込み、リクエスト/秒のクォータに達している場合、PutRecordBatch API オペレーションの使用を検討してください。PutRecordBatch は、1 回の呼び出しで複数のデータレコードを配信ストリームに書き込みます。これにより、1 つのレコードを書き込むより高いプロデューサーあたりのスループットを実現し、配信ストリームへの 1 秒あたりのリクエスト数が削減されます。
エクスポネンシャルバックオフを実装する
前述したように、配信ストリームを監視していても、データストリームにバーストが発生する可能性があります。これは、システムの使用量の急増や、市況の活発化などの外部要因によるものである可能性があります。プロデューサーを複数のレコードのスロットリングから保護するには、エクスポネンシャルバックオフを実装するという手段が有効です。エクスポネンシャルバックオフは一般的に使用されるアルゴリズムで、Kinesis Data Firehose にレコードを送信される際にレコードがスロットリングされたら、送信のレートを下げてゆっくりリトライすることで、最終的にプロデューサーがレコードを正常に送信できるようにします。。
レコードがスロットリングされたときの Kinesis Data Firehose API のレスポンスは以下のとおりです:
- API オペレーション
PutRecordを使用する場合、サービスから返されるエラーはServiceUnavailableExceptionで HTTP ステータスコードは 500 になります。 PutRecordBatchを使っている場合は、RequestResponses配列を順に確認していってし、ErrorCodeが 500 でErrorMessageがServiceUnavailableExceptionになっているPutRecordBatchResponseEntryを探す必要があります。また、API 呼び出しが成功した場合でも、レスポンス内にある FailedPutCount の値を確認することが勧められます。
どちらの場合でも、エクスポネンシャルバックオフを使用して操作を再試行する必要があります。 エクスポネンシャルバックオフの実装の詳細については、「AWS でのエラー再試行とエクスポネンシャルバックオフ」を参照してください。
Kinesis Data Firehose と Kinesis Data Streams の連携
Amazon Kinesis Data Streams は、きわめてスケーラブルで持続的なリアルタイムのデータストリーミングサービスです。データプロデューサーがデータを直接 Kinesis Data Streams に送信できる場合、Kinesis Data Firehose はそのデータを直接 Kinesis Data Streams から読み取り、送信先に配信することができます。Firehose 配信ストリームのソースとして Kinesis Data Streams を使う場合、前述のスループット制限は適用されません。これは、Kinesis Data Firehose が Kinesis Data Streams のデータストリームのシャード数に応じて自動的にスケーリングするためです。
Firehose 配信ストリームをコンシューマーとして Kinesis Data Streams にアタッチしていて、かつそれ以外で AWS Lambda などのコンシューマーアプリケーションがある場合 (「Amazon Kinesis で AWS Lambda を使用する」を参照)、コンシューマーアプリケーションの読み取りレートの合計がシャードあたりの2 MB/秒の制限 を超えていないか確認してください。
この制限の超過により、Kinesis Data Firehose を含むコンシューマーアプリケーションの読み取りスループットが Kinesis Data Streams によってスロットリングされる可能性があります。シャードあたりの読み取りキャパシティーを増やす必要がある場合、Lambda (「AWS Lambda がストリーミングを高速化する Kinesis Data Streams の拡張ファンアウトと HTTP/2 をサポート」 を参照) や Kinesis Consumer Library を利用したカスタムコンシューマーに対して、 Kinesis Data Streams の拡張ファンアウトを適用することで、各コンシューマーに専用スループットを割り当てることができます。ただし、現在のところ Kinesis Data Firehose における拡張ファンアウトの利用はサポートされていません。この機能により、コンシューマーアプリケーションは 2 MB/秒の読み取りスループットから分離して接続されるため、シャードから読み取りを行う他のコンシューマーアプリケーションには影響しません。
書き込みキャパシティーを増やしたい場合は、コンソールまたは UpdateShardCount API を使用して、ストリーム内のシャード数を簡単にスケールアップできます。
Kinesis Data Firehose でのデータ配信の監視
ネットワークタイムアウト、権限不足、送信先設定や AWS Key Management Service (AWS KMS) のキー ARN などの設定に誤りがある場合、Kinesis Data Firehose から送信先へのデータ配信が遅延または失敗する可能性があります。Lambda を使ったデータ変換が設定されている場合、Lambda 関数の呼び出し失敗もエラー発生につながる可能性があります。
Kinesis Data Firehose は配信または処理エラーを検出すると、設定された再試行期間が終了するまで再試行します。
再試行期間が終了してもデータが正常に配信できない場合、Kinesis Data Firehose は最大 24 時間までデータを内部的に保持します。24 時間の最大保持期間を超えても問題が続く場合、Kinesis Data Firehose はデータを破棄し、データが失われます。
このようなデータ配信の問題が続くと、Kinesis Data Firehose でまだ配信されていない最も古いレコードの経過時間を示すデータの鮮度メトリクス (data freshness metric) が増加し続けます。データの鮮度メトリクスが4時間のしきい値を超えたときに発火する CloudWatch アラームを作成することでこのようなときにアラームを受け取ることができます。アラームを設定して、データの鮮度メトリクス値の p90 の履歴を監視することをお勧めします。たとえば、データの鮮度のばらつきを検出するためのアラームしきい値として、特定の許容レベル (観測値を 50% 上回るなど) を設定します。
設定されているKinesis Data Firehose の送信先に応じた適切なデータの鮮度メトリクスの監視をお勧めします (DeliveryToS3.DataFreshness、DeliveryToAmazonOpenSearchService.DataFreshness、DeliveryToSplunk.DataFreshnes または DeliveryToHttpEndpoint.DataFreshness)。詳細については、「CloudWatch メトリクスを使用した Kinesis Data Firehose のモニタリング」を参照してください。
アラームが発火した場合、データの鮮度変動の根本原因を把握するための対策を講じる必要があります。このような変動の原因としては、Kinesis Data Firehoseのデータ変換を使用したときの Lambdaの変換ロジックの変更、または Lambda 同時実行の設定変更 などが考えられます。また、パラメーター、入力レコード形式の変換、または入力レコードタイプの変更が原因である可能性もあります。詳細については、「データの鮮度メトリクスの増加または未発行」を参照するか、必要に応じてテクニカルサポートを利用してください。
データ変換または送信先の問題が原因でデータ配信が失敗した場合、CloudWatch Logs に詳細な障害ログが記録されるため、トラブルシューティングに役立ちます。
また、送信先へのデータ配信バイトレート (DeliveryToS3.Byte など) の監視をお勧めします。このバイトレートは、データ取り込みバイトレート (IncomingBytes) に持続的な平均値に基づいて一致しない、もしくは超えない場合、データの鮮度メトリクスが増加し、データ損失につながる可能性があります。観測された配信データレートが取り込み率よりも低く、Kinesis Data Firehose データ変換で使用する場合は、Lambda の同時実行レベルや Lambda 変換ロジックなどのボトルネックの調整を検討してください。
送信先へのデータの配信に関するさらなる情報を得るには、監視できる CloudWatch メトリクスを提供しています。
たとえば、配信されたレコードの数を監視して、Kinesis Data Firehose から送信先に取り込まれたデータを追跡できます。
送信先ごとの詳細と追加メトリクスについては、「CloudWatch メトリクスを使用した Kinesis Data Firehose のモニタリング」を参照してください。
まとめ
この投稿では、Firehose 配信ストリームのメトリクスと Kinesis Data Firehose コンソールにある CloudWatch ダッシュボードを使った監視機能について説明しました。これにより、Firehose 配信ストリームのデータ入力とデータ配信に関する運用上の洞察を得ることができ、いずれかのメトリクスがしきい値を超過したときに通知を受けるための CloudWatch アラームを作成することができます。また、クォータを増やすリクエストの送信や、データプロデューサーにエクスポネンシャルバックオフの実装など、これらのアラームがトリガーされたときに実行できるさまざまなアクションについても説明しました。
配信ストリームを監視し、これらのアクションを実行することで、ビジネスデータが途切れることなく送信先に配信され、ニアリアルタイムでビジネスに役立つインサイトが得られるようになります。
原文はこちらです。
本ブログは Startup Solutions Architect の Torgayev Tamirlan が翻訳しました。