ALBアクセスログのCloudWatch出力
株式会社Works Human Intelligence / 内田匠
メンバー / フルスタックエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 11名〜50名
利用機能 | ツールの利用規模 | 事業形態 |
---|---|---|
ログ監視、アラーム通知機能、ダッシュボードなど | 11名〜50名 | B to B |
利用機能 | ログ監視、アラーム通知機能、ダッシュボードなど |
---|---|
ツールの利用規模 | 11名〜50名 |
事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
Lambdaを使うことで、S3にログが追加された際、すぐに処理を開始できます。トラブルが発生した時に、ログを素早く確認できることが重要なので、ログをリアルタイムでCloudWatchに反映するようにしています。
CloudWatchにログを送信する際は、イベントの数やサイズ制限を考慮してバッチ処理を行うようにしました。これにより、アクセスが集中する状況でもログが安定して出力されるように工夫しています。
導入の背景・解決したかった問題
導入背景
ALBのアクセスログはS3に出力されていましたが、確認する際にはログファイルをダウンロードし、CLIを用いて内容をチェックする必要がありました。このプロセスでログの確認は可能でしたが、業務において少なからず手間がかかっていました。
そのため、ログの確認が必要になった際に、迅速かつ直接的にログにアクセスできる状態を実現したいと考えていました。
比較検討したサービス
- Amazon Athena
比較した軸
既存の運用との整合性
チーム内ではCloudWatchを用いたログ監視が定着していたため、慣れ親しんだサービスを活用することにより、スムーズな運用を継続できることを重視しました。
導入の容易さ
チーム内では既にログの確認に手間がかかっていました。そのため、Amazon Athenaよりも導入から運用開始までのスピードが速く、既存のAWS環境とのシームレスな統合が可能なCloudWatchの採用を決めました。
導入の成果
アラートや問い合わせに対応する際、トラブルシューティング時にログを即座に確認できるようになり、原因の特定や問題の切り分けが迅速になりました。
導入に向けた社内への説明
上長・チームへの説明
CloudWatchの利用によってコストが大きくなりすぎないかという懸念がチーム内でありました。 この懸念に対しては、ピーク時のALBリクエスト数を基に、CloudWatch利用にかかる予想コストを詳細に計算しました。 提示した計算の結果により、予想されるランニングコストが許容範囲内であることを示すことで、費用面の心配が問題ないことを説明しました。
活用方法
よく使う機能
ログ監視機能
問い合わせ対応やアラート対応時のトラブルシューティングに利用しています。
ツールの良い点
リアルタイム性
ログをリアルタイムで監視できるため、問題が発生した際に迅速な対応が可能です。
データの可視化
メトリクス機能を用いてデータを定量化し、ダッシュボード上でのグラフによる可視化を通じて、システムの状態を直感的に理解できます。
横断的な監視
Lambda、S3、ECSなど、AWS上の多様なリソースを統合的に監視することができます。
ツールの課題点
定期的なコストの見直し
従量課金制のため、予期しないリクエストの増加でコストが予想以上に高くなる可能性があり、継続的な監視と費用の見直しが必要です。
ツールを検討されている方へ
AWS環境で統合的なモニタリングが必要で、ダッシュボードやアラートを活用したリアルタイム監視を重視される場合、CloudWatchは適していそうです。 ただし、コストが予想以上に高くなる可能性があるため、定期的な運用の見直しとコスト管理を行うことをお勧めします。
株式会社Works Human Intelligence / 内田匠
メンバー / フルスタックエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 11名〜50名
よく見られているレビュー
株式会社Works Human Intelligence / 内田匠
メンバー / フルスタックエンジニア / 従業員規模: 1,001〜5,000名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法