博士

ロボ子、Lambdaが毎月150万人以上のアクティブな顧客と数十兆回の呼び出しを処理しているって、知ってたかのじゃ？

ロボ子

はい、博士。それはすごい数ですね！

博士

Lambdaサービスチームが、非同期イベント処理システムを構築した経験に基づいて、高度に分散されたアプリケーションを実装するための推奨事項と洞察を提供しているらしいぞ。

ロボ子

非同期呼び出しって、具体的にどういう時に使うんですか？

博士

非同期呼び出しは、クライアントが即時応答を期待せずに処理のためのペイロードを送信する、非同期データ処理やジョブ送信などのシナリオで使われるのじゃ。

ロボ子

なるほど。Lambdaサービスは、それをどうやって実現しているんですか？

博士

Lambdaサービスは、リクエストを内部キューに配置して、HTTP 202をクライアントに即座に返すのじゃ。そして、大規模な非同期リクエストを処理するために、キューイングの仕組みを進化させてきたらしいぞ。

ロボ子

キューイングの仕組みを進化…ですか？

博士

最初は単一の共有キューから、複数のキューへのランダムなリクエスト配置、そして一貫性のあるハッシュ法を使用したインテリジェントなパーティショニングへと進化していったらしいのじゃ。

ロボ子

すごい！

博士

さらに、「2つのランダムな選択の力」という論文からヒントを得て、シャッフルシャーディング技術を導入したらしいぞ。

ロボ子

シャッフルシャーディング…ですか？

博士

テナントを複数のランダムに割り当てられたキューにシャッフルシャードして、非同期呼び出しを受信すると、最小のバックログを持つキューにメッセージを配置して、負荷分散を最適化するのじゃ。

ロボ子

なるほど！　負荷分散を最適化するんですね。

博士

Lambdaの分散型アーキテクチャは、依存関係と内部コンポーネントの潜在的な停止に耐えるように構築されているから、顧客への影響を制限できるのじゃ。

ロボ子

停止しても大丈夫なんですね！

博士

フロントエンドサービスは停止中に処理バックログを構築し、バックエンドはインフライトメッセージを失うことなく徐々に回復するらしいぞ。

ロボ子

すごいですね。他に何か重要なことはありますか？

博士

Lambdaサービスを非同期処理に使用する場合は、状況認識と潜在的な減速のために呼び出しを監視する必要があるのじゃ。AsyncEventReceived、AsyncEventAge、AsyncEventDroppedなどのメトリックを使用して、内部処理に関する洞察を取得できるぞ。

ロボ子

監視が大切なんですね。

博士

AsyncEventReceivedは、Lambdaサービスが処理のために正常にキューに入れることができた非同期呼び出しの数を追跡するのじゃ。

ロボ子

AsyncEventAgeは、メッセージが関数によって処理される前に内部キューで費やした時間を追跡。

博士

AsyncEventDroppedは、Lambdaが処理できなかったために内部キューでドロップされたメッセージの数を追跡するのじゃ。

ロボ子

AWS X-Rayトレースを有効にして、Lambdaサービストレースをキャプチャすることも可能なんですね。

博士

AWS::Lambdaトレースセグメントは、Lambdaサービスがリクエストを内部キューにルーティングするのに費やす時間の内訳、メッセージがキューで費やす時間、および関数が呼び出されるまでの時間をキャプチャするのじゃ。

ロボ子

Lambdaの非同期処理、奥が深いですね！

博士

そうじゃろ？　ところでロボ子、キューにメッセージが溜まりすぎてドロップされちゃった時、どうすればいいと思う？

ロボ子

えーと…メッセージを拾って、もう一度キューに入れる…ですか？

博士

正解！　それを「キューピッド」って呼ぶのじゃ！…って、キューだけにね！