[レポート] AWSでコンテンツ配信をデバッグするための4つのステップ #reinvent #NET303

はじめに

こんにちは。大阪オフィスの林です。

2019年12月02日〜2019年12月07日で、アメリカのラスベガスにてAWS re:Invent 2019が開催されています！この記事は「Four steps for debugging your content delivery on AWS」セッションに参加したレポートです。

セッション概要

コンテンツ配信では、次のようなさまざまな場所で問題が発生する可能性があります。たとえば、オリジンでHTTP 5xxエラーが返される場合。Amazon CloudFrontで、オリジンに接続できない場合。または、Lambda @ Edgeで、コードが未処理の例外をスローした場合。このセッションでは、Amazon CloudWatch、Amazon Athena、CloudFrontモニタリングダッシュボードなどのAWSサービスを使用して、AWSコンテンツ配信の問題をデバッグする4つのステップを実行します。ラップトップを持参してください。

セッション形式

「Builders Session」は通常のセッションともチョークタイプのセッションとも異なり、今回の場合、6人程度で1チーム（1テーブルに座る）になって、先生的な人が一人ついて、説明を聞きながらハンズオンを進めていく形式でした。※正直英語が不安でしたが全然何とかなりました！

セッションの進め方

はじめに、イベントのダッシュボード的なURLとログインに必要な情報が書かれた紙をテーブルで渡されるので、そのURLにアクセスしてログインします。

あとは、参照先のURLと先生の言うことに従いながらハンズオン形式で進めていきます。

セッションの内容

今回のセッションでは、4つのステップに分かれて、CloudFrontのdebugを行っていきました。

1. ロギングの有効化
2. アラームの設定
3. CloudFrontでの配信のトラブルシューティング
4. Lambda@Edgeをデバッグする

はじめに

architectureの概要

トラフィックフローは、Amazon CloudFrontディストリビューションを通過して、アプリケーションのさまざまな部分、この場合はLambda@Edge関数とEC2インスタンスにインストールされたアプリケーションに到達します。セッションの一環として、Amazon CloudFrontからのログはAmazon S3バケットに保存されます。このバケットは、後でAWS Glueクローラーによって処理され、Amazon Athenaを使用して、目的の各データをクエリします。

以下の図は、このセッションで使用される単純なWebアプリケーションのデプロイに使用されるアーキテクチャを示しています。Amazon CloudFrontディストリビューションの設定では、Application Load Balancerをデフォルトのオリジンとして使用しています。アプリケーションを含むインスタンスは、Amazon VPCで設定された異なるパブリックサブネットで実行され、Auto Scalingグループを使用して、インスタンスからのCPUしきい値に基づくAmazon CloudWatchアラームまたは負荷で実装されたヘルスチェックによってトリガーされる必要な回復力を提供します。アプリケーションはリクエストで送信された応答のHTTPステータスコードのタイプを記述するJSONオブジェクトをデフォルトで返す単純なアプリケーションです。Pathパラメーターを使用して、応答で同等のHTTPステータスコードをトリガーします。例えばパスへのHTTP GET要求/200は、HTTPステータスコード200で次の出力を生成します。JSON形式の応答の本文には、要求に応答しOriginたEC2インスタンスの1つであった値を示す要素responseByが含まれてます。

Amazon EC2インスタンスにデプロイされたアプリケーションと同じ機能を使用して、このLambda@Edge関数は、送信されたパラメーターに基づいてHTTPステータスコードを提供するように構成されます。Lambda@Edgeのロギングは、サービスの性質によりAmazon CloudWatchで行われるため、問題が発生したときに分析するためのリアルなソースになります。例えばパスへのHTTP GET要求/lambda/404は、HTTPステータスコードが404の出力を生成します。

それではdebugの検証を始めていきます。

STEP 1. ロギングの有効化

今回は、1分間に5xxErrorRateが0.1％を超えると必ずアラームがトリガーされるように設定し、[次へ]をクリックします。

作成済みの既存のSNSトピックを選択します。

次にテスト用のトラフィックを生成するのですが、セッションで準備されていた「Cloud9」の環境とテストトラフィックを発生させるシェルと使いました。

次にAthenaでテーブルを作成します。右上のメニューの[設定]をクリックして結果を保存するようにAmazon Athenaの設定を構成し、[クエリ結果の場所]フィールドにロギングに使用するS3バケットのURIを入力し、最後に「/athena-results/」を追加します。

下記のクエリを実行させます。

アラームが鳴ったり問題が発生した場合、適切なツールを使用してトラブルシューティングできるようにする必要があります。エラーの原因を判断するには、CloudFrontコンソールのモニタリングダッシュボードに移動し、コンソールで配信メトリックスと関連する機能メトリックスの両方を選択して表示できます。たとえば、5xxErrorRateに設定したアラームに基づいて通知を受け取ったとします。次の手順に従って、何が起こっているかを追跡します。

最初にエラー率ダッシュボードを見ます。Lambda@Edgeが原因の5xxエラーがある場合、次のセクション「ステップ4：Lambda @ Edgeのデバッグ」で詳細を確認します。ここに出てくるエラーはCloudFrontが原因なので何らかの分析を行って原因を確認できます。

まとめ

セッションの内容をある程度かいつまんでレポートさせて頂きました。どのようにデバックするかはケースバイケースでもありますが、幾つかのデバックのパターンを覚えておいても損はないと思います！

以上、大阪オフィスの林がお送りしました！