みなさんこんにちは。@ryuzeeです。 6月10日にAmazon Web Services企業導入ガイドブックが発売になっていますのでよろしくお願いします。
さて今回はAWS上でログ収集と分析をする際に、Amazon Elasticsearch Serviceを使う前提とした場合だとどのような構成案がありそうかいくつか考えてみたのでご紹介します。
なお、検討の材料にしている全体の構成としては、複数のVPC(またはAWSアカウント)があって、さらにオンプレ側とDirect ConnectやInternet VPNで接続しているような、よくあるそれなりの規模の構成になります。 各VPCの中には複数のサブネットがあり、そのうちのいくつかはプライベートサブネットに分かれているものとします(個人的にはインターネットゲートウェイの有無しか違いがないので、プライベートサブネットあまり作りたくない)。
定番のログ集約用のAggregatorを用意する例。Amazon Elasticsearch ServiceはVPC外のサービスでアクセスするには、インターネットに繋がらないといけない(実際にはAWSの中で折り返し)ので、Aggregatorはパブリックサブネットに配置します。それぞれのVPCやアカウントとはVPCピアリングで直結し、AggregatorまではローカルIPでアクセスする形になります。 Aggregator側からAmazon Elasticsearch Serviceにデータを登録するためには、fluent-plugin-aws-elasticsearch-serviceプラグインを利用します。 またここで併せてログをS3に保存したければ、fluent-plugin-s3を併用すれば良いでしょう。
この構成のメリットは以下のとおりです。
一方で以下の点については考慮が必要です。
こちらの例はEC2を使わずに実現する例。各サーバのFluentdでfluent-plugin-s3を利用し、指定したS3のバケットにログをためていきます。プライベートサブネットからの場合はプロキシを通します。 Lamdaでは、S3のバケットにファイルが作られたら、そのイベントをトリガーにしてLambda Functionを起動し、データをElasticsearch側に登録します。詳細なやり方についてはAWSのサイトでも紹介されています。
この構成のメリットは以下のとおりです。
一方で考慮点としては以下が挙げられます。
Kinesis Streamsは、次々と送られてくる大量のデータをリアルタイムで集めてくれる土管のようなサービスです(Kinesis Firehoseは同じような感じでS3などにファイルを溜めてくれるサービスですが東京にはまだありません)。 各サーバからKinesis Streamsにログを送り続けて、そのデータをKinesis App(EC2上に実装)やLambdaを使って順番に処理していく形になります。 なお、fluentdのプラグインは、fluent-plugin-kinesisとなり、こちらもプロキシに対応しているので、プライベートサブネットからの場合はプロキシ経由にします。
この構成のメリットは以下のとおりです。
一方で考慮点としては以下が挙げられます。
さてどれがいいでしょうねぇ…