[report]サーバレスアーキテクチャのトラブルシューティングを体験してきた in #reinvent (SPL302-R Troubleshooting serverless applications)

こんにちは、大阪オフィスのかずえ@re:Inventです。re:InventにてサーバーレスアプリケーションのトラブルシューティングをするSpotlight Labセッションに参加しましたのでレポートします。

Spotlight Labって?

いわゆる「手を動かす」系のセッションです。会場に入ると、2つモニターが用意された席に案内されます。片方にガイドを表示し、もう片方にAWSコンソールを表示して手を動かす内容です。

会場の雰囲気

講師はここから話します。

セッション紹介文

Monitor and debug an application using AWS X-Ray, Amazon CloudWatch metrics, Amazon CloudWatch Logs, and CloudWatch Logs Insights. Working in teams, use these tools to troubleshoot issues in a deployed lab.

※ Event Catalogに記載のセッション紹介文引用

内容

概要

マイクロサービスアーキテクチャーの難しい点の一つは、把握しておく必要のあるインテグレーションポイントがたくさんあることです。トランザクションが失敗したら、もしくは予想よりも遅かったら、サービスフローのどこが失敗しているのか、どのように突き止めるのでしょうか?

このラボでは以下を実施します。

  • 分散トレーシングのためにAWS X-Rayを有効化する
  • トラブルシューティング支援のためCloudWatch logsを生成する
  • サーバーレスアプリケーション内の報告済み問題を調査し解決する

Tasks

  • Task1: CloudWatchとX-Rayの起動
  • Task2: X-Rayの有効化
  • Task3: 画像アップロード
  • Task4: アプリケーションエラー(4つ)の修正

アプリケーション概要

  • ユーザーが写真をアップロードすると自動的にリサイズされ、写真右下にAWSロゴの透かしが入り、内容がチェックされる
  • 写真を選び校正用PDFプルーフをリクエスト
  • PDFは出版パートナーに送信され印刷→ユーザーに送られる

残念ながら現在は写真アップロード時にエラーが出る状態

構成図は以下です。

アプリケーションエラー概要

こらから調査するアプリケーションエラーの概要は以下です。

  • S3バケットに画像が全くアップロードされていない
  • アプリケーションが500エラーを吐いている(X-Rayで確認可能)
  • プリントベンダーへの製本印刷リクエストの送信失敗
  • Step FunctionsがImageProcessingStateMachine でエラーが起きていると指摘している

トラブルシューティングのヒント

  • addAlbumのAPI GatewayリソースがPOSTの代わりにGETトラフィックを受けるように設定されている
  • API Gatewayは同期イベントソースで、リクエストをドロップするまで20秒しか待たない。ドロップされたリクエストというのは、別の方法で捕捉していない限りユーザーのデータが失われるということです。CloudWatch Logsに現れるタイムアウトエラーと関数のタイムアウト設定を比べてみましょう
  • SQSのコンソールに行って、xxxx-BookPrintQueue-xxx のメッセージが見れるか確認しましょう。メッセージカウントが0以上なら、ユーザーは誰もメッセージを受け取ってないということです。
  • 製本プロセスは DigitalBindingFunction で制御されています。この関数は製本時にランタイムエラーを引き起こしています。

    Let's troubleshoot!

と、このあたりまで説明がありまして、ここからは各自目の前のPC使って取り組んでね、という感じです。「隣の人や同じテーブルの人は同士だから助け合ってな!」と言われました。

最初に以下のような画面が出てきて、AWSアカウント/ユーザー名/パスワードとか、使うAPIのエンドポイントとかを教えてくれます。後はガイドに従って進めて、途中からトラブルシューティングに入ります。

最初の「CloudWatchとX-Rayの起動」のところのガイドはこんな感じです。まったくCloudWatch LogsやX-Ray触ったことなくても、操作手順がすべて書いてあるので問題なく進めていけます。

トラブルシュートのパートに入ったら、そこに入るまでのガイドで紹介された各種リソースを調べながら解決していきます。全然わからなくても大丈夫。ヒントと答えの欄もあるので、そこを開けば教えてくれます。ちなみに4つあるエラーの内の最初のものは事前説明にあった通り、GETリクエストを受け付けているAPI GatewayリソースをPOSTに変更すれば解決できました。

感想

説明込みで1時間半のセッションでしたが、私は4つあるエラーの2つ目の対応中で時間切れとなるかなり消化不良の体験になってしまいました。。力不足を実感しました。とはいえトラブルシュートは楽しかったのでこれからも手を動かして行きたいなと感じました(できれば続きを家でもできるようにしてほしい)

皆さんもre:Inventに参加された際にはSpotlight Labセッションを取ってみることをお勧めします!