AWSを使ってると出てくる様々なログを整理して分析したい

はじめに

この記事はDevOps on AWS大全 実践編の一部です。
DevOps on AWS大全 実践編の一覧はこちら。

この記事ではAWSを使ってると出てくる様々なログを整理して分析するアーキテクチャを決める流れを解説しています。

具体的には以下流れで説明します。

• 解決したい課題の整理
• 今回使うAWSサービスの整理
• アーキテクチャの策定
• 策定したアーキテクチャで達成できたこと

AWSの区分でいう「Level 400 : 複数のサービス、アーキテクチャによる実装でテクノロジーがどのように機能するかを解説するレベル」の内容です。

この記事を読んでほしい人

• DevOpsエンジニアがアーキテクチャを決めるときにどのような思考フローを踏んでいるか知りたい人
• AWSを使ってると出てくる様々なログを整理して分析するアーキテクチャを知りたい人
• AWS Certified DevOps Engineer Professionalを目指している人

前回までの流れ

こちらの記事でパイプラインのアーキテクチャを策定しました。

解決したい課題の整理

現在、解決したいと思っている課題は以下になります。

• 各種ログをAWSのストレージサービスに格納したい
• ログを場合によっては分析したい
• 監査系のログの保管コストは安くしたい
• アラートを飛ばす必要があるログが出力された際には通知してほしい

ということで、これをどうやって解決するか考えていきましょう。

今回使うAWSサービスの整理

今回使う代表的なAWSサービスの概要とベストプラクティスは以下の通りです。

Amazon CloudWatch Logs

Amazon CloudWatch Logsは、AWSのサービスやアプリケーションのログをモニタリング、分析、保存するためのサービスです。
Amazon CloudWatch Logsを使用すると、ログデータをリアルタイムに監視したり、アラームやメトリクスを作成したり、ロググループやログストリームに分類したりできます。
また、Amazon Athenaと連携して、ログデータをSQLでクエリすることもできます。

Amazon Athena

Amazon Athenaは、サーバレスなインタラクティブなクエリサービスで、Amazon S3に保存されたデータを標準的なSQLで分析できます。
また、Amazon CloudWatch Logsのログデータをクエリする際にも便利です。
例えば、CloudTrailの監査ログやVPC Flow LogsなどのログデータをAthenaで分析することができます。

Amazon S3

Amazon S3は、オブジェクトストレージサービスで、インターネット経由でどこからでもアクセスできる耐久性の高いストレージです。
Amazon S3は、様々な種類や規模のデータを保存し、管理することができAmazon CloudWatch Logsのログデータを保存する際に使用されます。
例えば、CloudWatch Logsのエクスポート機能を使って、ログデータをS3にエクスポートすることができます。

ベストプラクティス

以下は、これらのサービスを使用する際のベストプラクティスです。

サービス	ベストプラクティス
Amazon CloudWatch Logs	- ロググループとログストリームを適切に設定し、ログデータを整理する。 - ログデータに対してメトリクスフィルターを作成し、重要な情報を抽出する。 - ログデータに対してアラームやダッシュボードを作成し、異常やパフォーマンスの問題を検知する。 - 不要なログデータは定期的に削除するか、S3にエクスポートしてコストを削減する。
Amazon Athena	- データソースとして使用するS3バケットやフォルダーを指定し、テーブルやビューを作成する。 - データの形式や圧縮方式に応じて適切なSerDeやInputFormatを選択する。 - パーティショニングやバケッティングなどのテクニックを使ってデータを効率的に分割し、クエリのパフォーマンスを向上させる。 - クエリ結果のキャッシュやワークグループなどの機能を使ってコストや実行時間を最適化する。
Amazon S3	- データのアクセス頻度や耐久性に応じて適切なストレージクラスを選択する。 - データの暗号化やバージョニングなどの機能を使ってデータのセキュリティや耐久性を高める。 - データライフサイクルポリシーを使ってデータの移行や削除を自動化する。 - S3 Intelligent-TieringやS3 Glacierなどの低コストなストレージクラスを使って長期保存するデータのコストを削減する。

アーキテクチャの策定

ここからはやりたいことを順番に考えながらアーキテクチャを策定していきます。

ログ収集の基本パターン整理

AWSでログを収集する場合、基本的にはS3あるいはCloudWatchLogsに格納します。
準リアルタイムで見たいなど特別な要件があるときにはOpenSearchへ格納するという場合もありますがあまり実例に遭遇しないので今回は割愛します。

S3に格納

AWSでログを収集する場合、最終目的地はS3にすることが基本です。
理由はコストと分析のしやすさです。

まず、コストについてです。
後述するCloudWatchLogsと比較してS3のコストは相対的に低く、監査目的など長期の保存でなくても基本的にはS3に保存することがおすすめです。

続いて分析のしやすさです。
S3に格納することでAthenaを用いたクエリ分析など、様々な分析を行いやすくなります。
CloudWatchLogsでも簡易な分析であれば、CloudWatchLogs InsightやAthenaで分析が可能ですが若干の制約事項があります。

なお、S3へのログ出力にはいくつかのパターンがあります。

一番単純なのは直接S3に出力できるパターンでALBのアクセスログなどが該当します。

次のパターンはKinesis Data Firehoseに配信できるのでKinesis Data Firehose経由でS3に送信するパターンでAPI Gatewayのログなどが該当します。

最後は直接S3出力もKinesis Data Firehose配信もできずCloudWatchLogsに出力するしかないパターンでRDSのログなどが該当します。
この場合はCloudWatchLogsに出力し、Kinesis Data Firehoseに配信したうえで、S3に送信するという方法が一般的です。
もし、リアルタイム性を求めないのであればCloudWatchLogsのExport APIを定期実行してS3に出力してもよいでしょう。

CloudWatchLogsに格納

すでに書いたようにAWSでログは基本的にS3に出力しますが、要件によってはCloudWatchLogsに出力することがあります。

1つ目は簡単な一次解析を行いたい場合です。
Athenaを使うまでもなくパッとログを確認したい場合にはCloudWatchLogsに出力しておいたほうが便利です。
例えば、アプリケーションのエラーログなどがあげられます。

2つ目はログ監視でアラートを飛ばしたい場合です。
この場合、CloudWatchLogsに出力したうえでAlarmに引っ掛ける必要があります。

最後はCloudWatchLogsにのみ出力可能なサービスです。
この場合は、要件必須性というよりは技術制約になるのでS3に移動してしまうのがおすすめです。

いずれの場合でもコストの観点からCloudWatchLogsへの保管期間は最小に設定することがおすすめです。

セキュリティログを集めて調査時には分析、不審な挙動を示したら通知を飛ばしたい

ここからは、ログのパターンごとにアーキテクチャを考えていきます。

セキュリティ系のログはCloudTrail、Config、GuardDutyから出力されます。
それぞれ、S3に直接出力できるのでS3に出力したうえでライフサイクル設定を行い、一定期間が経過したらGlacierに移動させましょう。
S3に一時保管するのは調査のためにAthenaでクエリ発行する可能性を考慮してのことです。

また、セキュリティ系のログの場合には、特定のログが出た場合に通知を行いたいことがほとんどだと思います。
その場合、ConfigやGuardDutyなど個別のセキュリティサービスから通知を行うのではなくSecurityHubに集約したうえで通知を行うことがおすすめです。
これは、通知のための連携設定が1つで済むことが理由です。

これらをまとめると以下のようなアーキテクチャになります。

アクセスログを集めて調査時に分析したい

アクセスログは基本的にS3に出力できるものがほとんどですがいくつか例外があります。
1つめがCloudFrontのリアルタイムログです。
CloudFrontのアクセスログをS3に出力する場合は最大24時間遅延するため、準リアルタイムでの出力が必要であればKinesis Data Streamsに配信する必要があります。

もう1つがAPI Gatewayのログです。
これはCloudWatchLogsかKinesis Data Firehoseかしか選べないので基本はKinesis Data Firehoseに配信し、S3に出力します。

セキュリティ系のログ同様、S3に出力したログはライフサイクルを設定して削除あるいは、監査用途でのGlacierへの移動を忘れないようにしましょう。

これらをまとめると以下のようなアーキテクチャになります。

バックエンドログを集めて調査時には分析、エラー時には通知を飛ばしたい

バックエンドログとしてCompute系のログを集める場合を考えてみます。
バックエンドログは一次解析用、あるいはアラート通知にエラーログをCloudWatchLogsに送り、他ログをS3に送るという運用が一般的です。

まず、CloudWatchLogsへの出力についてです。
ECSとEKSの場合はawslogsログドライバを使うか、サイドカーコンテナを立てた上でOSSのFluentd、Fluentbitを使うかでログを転送します。
なお、EC2の場合はCloudWatchLogs Agentが必要です。
それぞれのログをCloudWatchLogsに送りAlarmを設定し通知を飛ばす、そのうえでエラーログをCloudWatchLogsで一次解析するというのがよくある運用でしょう。

また、S3に入れる場合直接S3には出力できないのでKinesis Data Firehoseに配信してS3に送信します。
例によって、ライフサイクルを設定した削除あるいはGlacierへの移動は忘れないようにしましょう。

これらをまとめると以下のようなアーキテクチャになります。

データベースのログを集めて調査時は分析したい

続いてデータベースのログです。
これは、基本的にCloudWatchLogsにしか出力できないのでCloudWatchLogsに出力した後にCloudWatchLogsからKinesis Data Fireへ配信してS3に送信することになります。

ElastiCacheのエンジンログだけ直接Kinesis Data Firehoseに配信できるので、CloudWatchLogsを経由させる必要はありません。

これらをまとめると以下のようなアーキテクチャになります。

その他AWSのSaaS系のログを集めて調査時には分析したい

今回は。DevOpsを軸に書いているのでCodeシリーズを取りあげますが大半のAWSサービスはこれから各パターンです。

CodeシリーズはCloudWatchLogsにしかログを出力できないのでCloudWatchLogsに出力したうえで、CloudWatchLogsからKinesis Data Fireへ配信してS3に送信します。

ただ、リアルタイム性があまり求められないような場合にはKinesisのコストを考慮してEventBridgeでのAPI CALLで定期出力させる場合があります。

これらをまとめると以下のようなアーキテクチャになります。

まとめ

本記事ではAWSを使ってると出てくる様々なログを整理して分析する方法をまとめました。

今回策定したアーキテクチャで実現できたのは以下の項目です。

• 各種ログをCloudWatchLogsあるいはS3に格納
• S3に格納したログに対してAthenaを利用した分析
• アラートを飛ばす必要があるログが出力された際の通知

次回はモニタリングを考えてみたいと思います。