こんにちは、MSPの田所です。

AWS re:Invent 2024 が始まりました！
現場からイベント模様をお届けします。

セッション情報

Hands-on experience with Amazon CloudWatch

CloudWatch でハンズオンやります！

Your enterprise’s agility, customer satisfaction, and business growth depend on setting up great observability. In order to help you build high-performing and reliable applications, AWS provides a variety of turnkey AWS native observability services and solutions. In this workshop, learn how to monitor AWS services with Amazon CloudWatch, get hands-on experience with the most common use cases, and learn about and implement the newest features available. You must bring your laptop to participate.

CloudWatch でAWSサービスをモニタリングする方法を、比較的新しい機能も含めて体験してもらいます！

Session types: Workshop

2時間のワークショップ

今回のまとめ

以下を全て CloudWatch（と X-Ray）で監視する

  • インフラ（ログとカスタムメトリクス）
  • サービス（X-Rayトレーシング）
  • アプリ、ユーザー体験（RUM (Real User Monitoring) と Synthetics）
  • コンテナ（ECS, EKS のインサイト）

セッションの詳細

AWS のオブザーバビリティサービスは、インフラ、アプリ、ネットワークなど多岐に渡りカバーしています。
その多くが CloudWatch の機能で実装できますが、X-Ray や、Grafana, Prometheus, OpenTelemetry などオープンソースを利用するサービスも活用できます。

またエンドユーザー側から見て動作が良好かどうかの “Outside-in” と、バックエンドから見て稼働状況が良好かどうかの “Inside-out” の2つの視点があります。
これらをどちらもカバーするのがフルスタックオブザーバビリティという考え方です。

今回ハンズオンを行い、典型的なユースケースについて監視設定やトラブルシューティングを行いました。

1. パフォーマンスの問題

2台の ALB の背後に稼働する別々の EC2 でWebサイトを稼働させています。
これに対して問題がないかを見ていきます。

ロードバランサー別にメトリクスを見てみると、ひとつのサイトだけが明らかに応答が遅いことが分かりました。
ここに p90 elapsed time のメトリクスを設定し、1 秒以上の場合は Health Status を NG にするようダッシュボード上で設定します。
p90 ということで、リクエスト数の 90% が 1 秒未満の応答時間に収まっているかどうかを判定しています。
そこで NG 判定の出たWebサイトのコードを調べると、3 秒間待機する指示が入っており、コードを修正しました。
最終的に p90 elapsed time も OK になったことを確認して対応完了です。

 

2. X-Ray トレーシング

API Gateway – Lambda – DynamoDB のサーバレス構成のWebサイトがあります。
画面が正しく表示されないため、そのとラブルシューティングを行います。

分析のために X-Ray のトレースと Lambda PowerTools を有効化します。
Lambda PowerTools は、JSON 形式の構造化ログを取得するためのツールです。

トレースを確認すると、エラーは Lambda 関数で発生していることが分かりました。

Lambda 関数を確認したところ、エラーを発生させる行があったため修正しました。
エラーの修正は以上でしたが、コードにカスタムスパンを取得する記述を加えることで、さらに詳しい情報を見られることを確認しました。

3. RUM と Synthetics

ペットショップのWebサイトがあり、アプリのパフォーマンスやユーザー体験に関する監視設定を行います。

指定のドメインに対して RUM を設定し、ボタンを複数回押してチェックアウトする動作を Synthetics Canary で設定します。
CloudWatch Synthetics Recorder という拡張機能を使うと、ブラウザ上でボタンをポチポチするだけでその動作のスクリプトを生成することができます。
便利、、！

Synthetics の結果からエラーはありませんでしたが、RUM で遅延の大きいトランザクションがあることが分かりました。
HTML のスクリプトを修正して完了しました。

（画像撮り忘れました、ごめんなさい！）

4. Container Insights

コンテナリソースに対して Container Insights を設定します。

Container Insights を有効化し、メトリクスやログが記録されていること、ダッシュボードが利用できることを確認しました。

MSPとして

1. 機能がこんなにも増えている

CloudWatch というと資格勉強的にはこんなイメージではないでしょうか。

  • インフラのメトリクスやログを取得する
  • アラームを設定して SNS に通知したり EventBridge に連携する

しかし今回、RUM (Real User Monitoring) や Synthetics といったユーザー視点の監視、Container Insights といったコンテナクラスターの監視などの機能があることを学びました。
CloudWatch の機能が充実しているということは、AWS が統合された監視を重要視しており、今後オブザーバビリティがさらに重要度を増してくることの表れではないでしょうか。
MSPとして取り組むべきテーマであることは間違いありません。

2. アクションまで持っていく

ワークショップでは監視設定をするのみならず、実際にトラブルシューティングを行うまでを体験しました。
データを取得すること、データを可視化すること、も大事ですが、
データを解釈すること、データをアクションに繋げること、がさらに大事であると認識しました。
お客様に提供できる価値として、安定稼働や迅速な障害復旧がありますが、データをそれらの向上に繋げられるプロセス策定が大切であると思いました。

おわりに

改めて CloudWatch の重要性、AWS のオブザーバビリティへの注力を感じました。
今後の動向にも目が離せませんね。
CloudWatch をウォッチ！

おしまい