2024.11.19

AWSにおけるオブザーバビリティについて

keichan

Contents

はじめに
オブザーバビリティの重要性
CloudWatchアラームの最適化
障害対応の実例と学び
メトリクス・ログ・トレースの統合的な活用
コスト管理の重要性
終わりに

はじめに

秋も深まり、朝晩がだいぶ冷え込むようになってきましたね。最近体調を崩し気味ですが、家でも靴下を履くようにするとマシになってきましたkeichanです。
今回は、AWSの運用において重要なオブザーバビリティについて、私が感じたポイントや導入のコツをご紹介しようと思います。

オブザーバビリティの重要性

最近のシステム開発では、マイクロサービスやサーバーレスといった分散アーキテクチャの採用が増えてきています。その中で特に感じたのが、システムの状態を正確に把握することの難しさです。
システムが複雑化するほど、従来の単純な監視だけでは、問題の根本原因を特定するのが困難になります。

AWSでは、Amazon CloudWatchやAWS X-Ray、OpenSearch Serviceといったオブザーバビリティのツールが提供されていますが、これらをただ導入するだけでは十分とは言えません。
メトリクス、ログ、トレースといった3つの要素をどのように組み合わせ、活用していくかが鍵となります。

CloudWatchアラームの最適化

まず私が取り組んだのが、CloudWatchアラームの設定です。
特に、日本の企業では「障害を未然に防ぐ」という文化が根付いており、アラームの設定にも細心の注意を払います。しかし、あまりに多くのアラームを設定してしまうと、通知が多くなり担当者の負担が増えてしまいます。

そこで、重要なメトリクスに絞ってアラームを設定することを心がけました。例えば、EC2のCPU使用率やRDSの接続数など、システム全体のパフォーマンスに直接影響を与えるものに重点を置くようにしました。

障害対応の実例と学び

ここで、私たちのチームが実際に経験した障害対応の実例を紹介したいと思います。ある日、特定のAPIエンドポイントに対するリクエストが急激に増加し、サービス全体が遅延する問題が発生しました。
このとき、まずCloudWatchのメトリクスとX-Rayのトレースを確認しました。

1. メトリクスからの異常検知

CloudWatchのダッシュボードで、API Gatewayのリクエスト数とエラーレートが急上昇していることを確認しました。特に、5xxエラーが増加しており、バックエンドのLambda関数がタイムアウトしていることがわかりました。

2. トレースでの問題特定

次に、AWS X-Rayでリクエストのトレースを確認しました。ここで判明したのは、特定のデータベースクエリが異常に時間がかかっていることでした。データベースの負荷が高く、他のリクエストも連鎖的に遅延している状況でした。

3. 障害の原因と対策

問題の原因は、APIの新機能リリース後に特定のクエリが非効率になっていたことでした。インデックスの最適化とキャッシュの導入を行い、データベースの負荷を軽減しました。また、API Gatewayにリクエスト制限（スロットリング）を設定し、バックエンドの負荷を軽減する対応も行いました。

4. 学びと改善

この障害対応から得られた学びは、プロアクティブな監視の重要性です。メトリクスやトレースのデータがすぐに確認できたことで、迅速に問題を特定できました。また、リクエストの増加に備えて、API Gatewayのスロットリングやデータベースのキャッシュ化といった事前対策の必要性を再認識しました。

メトリクス・ログ・トレースの統合的な活用

オブザーバビリティを高めるためには、メトリクス・ログ・トレースのデータを統合的に活用することが不可欠です。
私は、AWSのOpenSearch Service（旧Elasticsearch Service）を活用し、CloudWatch LogsとX-Rayのデータを統合しました。これにより、異常検知や原因特定の際に、1つのダッシュボードでシステムの全体像を把握できるようになりました。

具体的には、以下のようなダッシュボードを作成しました。

リアルタイムのメトリクス表示（CPU使用率、メモリ使用率、エラーレート）
エラー発生時の詳細ログ表示（APIエラー、スタックトレース）
トレース結果の可視化（リクエストのフロー、遅延の原因）

これにより、問題発生時の対応速度が大幅に向上しました。

コスト管理の重要性

AWSのオブザーバビリティツールを導入する際に見逃せないのが、コスト管理です。
CloudWatchやX-Ray、OpenSearch Serviceを使うと、データの収集や保持にかかるコストが意外と高額になることがあります。
特に、CloudWatch Logsはデフォルトで大量のデータを収集する設定になっているため、注意が必要です。

私のチームでは、定期的にログデータの使用状況を確認し、ログのフィルタリングや保存期間の見直しを行うことで、コストを最適化しました。
また、必要に応じて、S3にログをアーカイブすることで、長期保存のコストも抑えています。