マルチアカウントにおけるログ集約のアーキテクチャ事例 | AWSクラウドアーキテクチャ

AWSマルチアカウント環境におけるログ集約のアーキテクチャを、事例から学びます。


はじめに

AWSから上の動画が投稿されました。
BiogenのAWSマルチアカウント環境における、ログ集約の方法が解説されています。

今回はこの動画のアーキテクチャを改めて自分で書き下し、マルチアカウントにおけるログ集約の方法を学んでいきます。


アーキテクチャ

f:id:BioErrorLog:20200213084346p:plain

Individual accountからCentralized accountへ、Kinesis Firehoseを介してログをストリーミングするアーキテクチャになっています。

このIndividual accountは実際に何百も存在し、それらのログがCentralized accountに集約されているそうです。


アーキテクチャの設計としては、アカウント規模が大きくスケールすることを考慮し、S3やKinesis Firehose、Lambdaなど使用量に合わせて自動スケールするサービスが多く取り入れられています。

また多くのサーバレスのサービスを多く採用することで、可用性を保証しつつメンテナンスのコストを削減しています。


収集するログは次の3種類です。

  • VPCフローログ
  • CloudTrailログ
  • EC2-CloudWatchログ

ここで、EC2のログは直接Kinesis Firehoseのエージェントによって収集されるのではなく、CloudWatchのエージェントによって収集されています。

これには理由が二つあり、一つ目にはKinesisエージェントがWindowsに対応していないことが挙げられています(現在はKinesisエージェントもWindowsに対応している模様です)。

二つ目の理由は、CloudWatchエージェントがOSレベルのログも収集できる点が挙げられています。


次に、これらのログはKinesisを介してLambdaへ配信されます。

ここのLambdaは2つの役割を担っています。

一つ目は、それぞれ異なるフォーマットのログを変換することです。
二つ目は、S3に保存するログを取捨選択することです。

このLambdaを介して、各種ログがCentralized accountのS3に保存されます。


このCentralized accountのS3には、すべてのIndividual accountからのログが保存されています。

ログを直接Elasticsearchに配信するのではなくS3に保存する理由としては、Kibanaなど他の可視化プラットフォームが利用できる点が一つ目に挙げられています。

また、S3のスケーラビリティとデータ暗号化機能、データライフサイクル機能が利用できることも、S3に保存する利点として挙げられています。


S3に保存されたデータは、Lambdaを介してElacticsearchにプッシュされます。

Elacticsearchでは、アプリケーション名をキーワードとして検索することによって、アプリケーション障害の原因などを可視化・分析できるようにしているとのことです。

このようなアーキテクチャを構築する以前の障害発生時には、まずどのアカウントに属するEC2が障害を起こしたのかを特定し、その後EC2にSSHしてアプリケーションログを確認、そしてVPCフローログとCloudTrailログをチェックすることで障害の原因を特定していたそうです。

ログの集約・分析の仕組みを構築することで、これらの手間を削減することができます。


おわりに

Biogenの事例から、AWSマルチアカウントにおけるログ集約のアーキテクチャを学びました。

ログ集約過程におけるLambdaの使い方や、Elasticsearchの使い方などが、私にとって特に勉強になりました。

Kinesis FirehoseやElasticsearchは私自身使ったことがないので、いつか使ってみたいものです。

それにしても、このような動画シリーズは初学者にとってとてもありがたい存在なので、AWSにはぜひ今後も配信し続けてもらえればと願っています。


こちらもどうぞ

www.bioerrorlog.work


参考

Biogen: Centralized Logging Solution for Multi Accounts