022-AWS SAP AWS 「理論・実践・一問道場」指数バックオフ

type

status

date

slug

summary

理論

参照元：

サーバーレスアプリケーション開発におけるエラーハンドリング ~ Web API パターン ~ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS

Web API パターンにおけるサーバーレスのエラーハンドリングを AWS で実現する際に抑えておくべきポイントについて紹介します。

https://aws.amazon.com/jp/builders-flash/202307/serverless-error-handling-2/

Web API パターンのサーバーレスアプリケーションの特徴

Push 形式の起動

Web API は外部からの HTTP リクエスト によってトリガーされる Push 形式 を採用しています。

クライアントがリクエストを送信する責任を持つため、サーバー側はリクエストの処理ロジックに専念できます。

同期通信の特性

Web API では、クライアントがリクエストを送信すると、サーバーが処理を実行し、すぐにレスポンスを返します。

レスポンス内容:

正常時: クライアントで利用可能なデータを返す。

エラー時: エラー情報を返し、クライアントが適切なエラーハンドリングを行えるようサポートします。

Push 形式と Pull 形式の比較（補足）

Push 形式（Web API の特徴）: クライアントがリクエストを送信し、それに応じてサーバーが処理を行う。

Pull 形式（別のパターン）: サーバーが外部からデータを取りに行く形式。サーバー側でエラーハンドリングを含む責任が増えるが、AWS の「イベントソースマッピング」などで負担を軽減する仕組みが提供されている。

Web API パターンのサーバーレスアプリケーションを AWS 上で構築するには、2 つの主要なサービスを使用します：

1.Amazon API Gateway:

HTTP リクエストを処理する Web サーバーとして機能し、API の作成、公開、管理を行います。主に REST API を構築する際に使用され、モバイルや業務系 API に利用されます。

2.AWS AppSync:

GraphQL を利用した API を構築するためのサービスです。リアルタイムのチャットアプリなど、リアルタイムモバイルやオフライン対応のアプリケーションで使用されます。

サーバーレスな Web API を構築するには、Amazon API Gateway（HTTP リクエストを処理する）と AWS Lambda（バックエンド処理を実行する）を組み合わせます。Lambda はイベント駆動型で、さまざまなプログラミング言語をサポートし、広範なユースケースに対応します。

エラーを処理

クライアント側で行うエラーハンドリングの一つに「リトライ」があります。リトライは一時的なエラー（例：スロットリング、一時的な障害、ネットワーク問題）に対応する方法です。

リトライのポイント

リトライが必要なエラー：

一時的な障害やリクエスト制限（スロットリング）など。

リトライが不要なエラー：

不正なデータやアクセス権限の不足など、設定修正が必要なエラー。

リトライ設定

回数と間隔を適切に設定することが重要。短時間で繰り返しリクエストするとサーバーに負担をかけるため、間隔を調整します。

エクスポネンシャルバックオフとジッター（ランダムに間隔を変更）を使うのが推奨されます。

【ジッター】

ジッターはリトライの際にランダムな遅延を加えることで、同時に発生するリクエストやそのリトライによる競合や過負荷を避けるための効果的な手法です。この方法を使用することで、リクエストが集中する時間帯にエラーの再発を防ぎ、システム全体の安定性を保つことができます。

リトライ実装

AWS SDKを使用すると、エクスポネンシャルバックオフとジッターを含むリトライを簡単に実装できます。例えば、フロントエンドアプリケーションからAPI Gatewayへのリクエストを行う際、AWS SDKが自動でリトライ機能を適用します。

以下の表でエクスポネンシャルバックオフとジッターの違いをまとめました：

特徴	エクスポネンシャルバックオフ	ジッター
目的	リトライ間隔を長くして負荷を減らし、システムの復旧時間を確保	同時リクエストの競合を避け、リトライのタイミングを分散
リトライ間隔	初回リトライから指数的に増加（例：1秒 → 2秒 → 4秒）	リトライ間隔にランダムな時間のずれを加える
主な効果	リクエストが集中しないようにし、システムにかかる負荷を減少	同時リトライによる競合や過負荷を防ぐ
使用場面	リトライ回数が多い場合に有効	複数のクライアントが同時にリトライする場合に有効

このように、両者は異なる目的で使用されますが、合わせて使うことで、リトライによるエラー処理をより効果的に行えます。

以下はその簡単なサンプルコードです。

AWS SDK を使うと、エクスポネンシャルバックオフとジッターを備えたリトライ機能が自動で実装されます。API呼び出し時に apigClient.methodName を使うと、SDKがリトライ処理を行い、手動での実装が不要です。これにより、サーバーレスアーキテクチャでのエラーハンドリングが簡単に実現できます。

実践

エクスポネンシャルバックオフ（Exponential Backoff）を実装したLambda関数をテストするために、以下の構成と手順を紹介します。エクスポネンシャルバックオフを使用する場合、APIのリクエストが失敗した場合に一定の待機時間をおいて再試行を行い、待機時間が増加していく仕組みを作成します。

構成概要

Lambda関数: AWS Lambdaを使ってS3バケットをリストするAPIを作成します。失敗した場合はエクスポネンシャルバックオフを使って再試行します。

API Gateway: HTTPエンドポイントを公開し、Lambda関数をトリガーします。

S3: Lambda関数がリストするS3バケットを準備します。

1. Lambda関数の作成

Lambda関数でエクスポネンシャルバックオフを実装し、S3バケットのリストを取得します。バックオフ処理には、最大再試行回数や再試行間隔を設定します。

2. API GatewayでHTTPエンドポイントを作成

次に、API Gatewayを使って、HTTPリクエストがLambda関数をトリガーするように設定します。

手順:

API Gatewayを作成:

AWS Management Consoleで「API Gateway」を選択し、新しいHTTP APIを作成します。

必要なリソース（例: /s3-buckets）とメソッド（例: GET）を作成します。

Lambda関数をAPI Gatewayに統合:

作成したGETメソッドに、先ほど作成したLambda関数を統合します。

デプロイ:

API GatewayでAPIをデプロイし、エンドポイントURLを取得します。

3. S3バケットの設定

Lambda関数がS3バケットのリストを取得するので、事前に少なくとも1つ以上のS3バケットが存在する必要があります。もし必要であれば、新しいS3バケットを作成してください。

4. テスト方法

4.1 Lambda関数のテスト

Lambdaコンソールから直接関数をテストできます。

イベントは {} のように空のJSONで設定できます。
関数が正常に動作する場合、S3バケットのリストが含まれたレスポンスが返されます。
s3:ListAllMyBuckets IAMロールに適切な権限を付与することで、アクセスできるようにします。

4.2 API Gatewayを介してテスト

API Gatewayを介してLambda関数をHTTPリクエストでテストするには、以下の手順を実行します。

Postman、curl、またはブラウザを使ってAPI GatewayのエンドポイントURLにGETリクエストを送信します。

レスポンスにS3バケットのリストが含まれていれば、成功です。もしバックオフが発生した場合は、再試行の間隔（エクスポネンシャルバックオフの挙動）がコンソールログに表示されます

4.3 エラーハンドリングのテスト

S3へのアクセスに必要な権限（s3:ListAllMyBuckets）がない場合、APIは失敗し、500 Internal Server Error が返されるはずです。

5. CloudWatch Logsで詳細なログの確認

Lambda関数の実行後、CloudWatch Logsに記録されたログを確認して、エクスポネンシャルバックオフの挙動を確認できます。

Lambdaの実行ログがCloudWatchに出力されるので、そこにバックオフの試行回数や遅延時間が表示されます。

ログ例:

まとめ

エクスポネンシャルバックオフをLambda関数に実装し、失敗した場合に自動で再試行を行うように設定しました。

API Gatewayを使って、HTTPリクエストを介してLambda関数を呼び出し、S3バケットのリストを取得する構成を作成しました。

テスト方法として、Lambdaコンソール、API Gateway経由でのHTTPリクエスト、およびCloudWatch Logsでログを確認する方法を使用しました。

一問道場

質問 #22

トピック 1

あるソフトウェア会社が、Amazon API Gateway、AWS Lambda関数、およびAmazon DynamoDBを使用してREST APIを提供しています。

現在、PUTリクエストでエラーが増えており、そのほとんどが特定のAPIキーで認証された少数のクライアントから発信されています。

エラーの多くは1つのクライアントから発生しており、APIは非クリティカルで、クライアントはリトライを受け入れられるため、即座にエラーを解消する必要はありません。しかし、エラーが顧客に表示されることで、APIの評判が悪化しています。

「非クリティカル」とは、システムやプロセスにおいて、重要度がそれほど高くない、あるいは障害や問題が発生しても即座に重大な影響を及ぼさないことを指します。

顧客体験を改善するために、ソリューションアーキテクトは何を推奨すべきか？

A. クライアントアプリケーションで「指数バックオフ（リトライ時に待機時間を段階的に長くする）」と「不規則な変動」を使ったリトライロジックを実装する。

エラー発生時には詳細なエラーメッセージを表示するようにする。

B. API Gatewayで使用計画を作成し、APIスロットリングを実施する。

クライアントアプリケーションが「コード429（リクエスト制限を超えた）」のエラーを適切に処理できるようにする。

C. APIキャッシュを有効にして、APIの応答性を向上させる。

10分間の負荷テストを実施し、キャッシュ容量が適切であることを確認する。

D. Lambda関数に予約済みの同時実行設定を実装し、トラフィックの急増に対応できるようにリソースを確保する。

解説

この問題はクライアント側のエラーに該当します。具体的には、PUTリクエストのエラーが特定のAPIキーで認証されたクライアントから発生しており、そのクライアントはリトライを受け入れられる状況にあります。エラーが顧客に表示されることでAPIの評判が悪化しているものの、即座に解消する必要はなく、非クリティカルな問題として扱われています。

このような場合、リトライメカニズムやエラーハンドリングが重要で、特にクライアント側でリトライ処理を行い、エラーを回避することが推奨されます。

このシナリオでは、エラーが特定のAPIキーを使った少数のクライアントから発生しており、リトライが許容される状況です。したがって、顧客体験を改善するためには、クライアント側でリトライロジックを適切に処理し、APIが過負荷にならないようにすることが重要です。

そのため、最も適切な解決策はAです。

A. クライアントアプリケーションで「指数バックオフ」と「不規則な変動」を使ったリトライロジックを実装することで、エラーが発生した場合に過剰なリクエストを防ぎ、APIの過負荷を避けることができます。指数バックオフは、再試行時に待機時間を段階的に長くすることで、リソースへの負荷を減らし、リトライ時の競合を避ける効果があります。

他の選択肢についても見てみましょう：

B. APIスロットリングはリクエスト数を制限する方法であり、これが過剰なリクエストを防ぐのに役立つかもしれませんが、リトライが許容される状況では、クライアント側でリトライロジックを改善する方が適切です。

C. APIキャッシュは応答性を向上させるかもしれませんが、エラーの根本的な原因を解決するものではありません。キャッシュはデータを一時的に保存し、応答速度を向上させることが目的です。

D. Lambda関数の同時実行設定を調整することはトラフィック急増時のリソース確保に役立ちますが、このシナリオではエラーの原因がクライアント側の過剰なリクエストである可能性が高く、サーバー側のリソース確保ではなく、クライアント側の改善が必要です。

したがって、Aが最も適切な選択肢です。