Amazon Kinesis および Amazon Athena を使用して VPC ネットワークのトラフィックを分析および視覚化する

ネットワークログの分析は多くの組織で一般的に実施されています。ネットワークログを収集し、分析することにより、ネットワーク上のデバイスがそれぞれ、およびインターネットとどのように通信しているかを把握できます。たとえば、監査、コンプライアンス、システムのトラブルシューティング、セキュリティフォレンジックなど、ログ分析を実行する理由は多数あります。 Amazon Virtual Private Cloud (VPC) では、VPC Flow Logs を使用してネットワークフローをキャプチャできます。 VPC、サブネット、ネットワークインターフェイス用のフローログを作成できます。サブネットまたは VPC のフローログを作成した場合、VPC の各ネットワークインターフェイスまたはサブネットがモニタリングされます。フローログのデータは Amazon CloudWatch Logs のロググループに公開され、各ネットワークインターフェイスにはユニークなログストリームが作成されます。

CloudWatch Logs にはこのログデータの洞察を確保するうえで有用なツールがいくつか用意されています。しかし、ほとんどの場合、ログデータを S3 に効率的にアーカイブし、SQL を使用してクエリ検索する手法が好まれます。この手法ではログの保存に対しより大きな柔軟性と管理性が得られるとともに、必要な分析も実行できるようになります。しかし同時に、分析を自動的に実行することでログデータが生成された直後にログデータの洞察をほぼリアルタイムで取得する機能もよく好まれる傾向にあります。また、VPC 内のネットワークトラフィックをより明確に理解できるよう、ダッシュボードである程度のネットワークの特徴を視覚化することにも関心が集まっています。つまり、S3 への効率的なログのアーカイブとリアルタイムのネットワーク分析、データの可視化のすべてを達成するにはどうすればよいでしょうか? これは、CloudWatch、Amazon Kinesis、AWS Glue、Amazon Athena などの複数の機能を組み合わせることで達成自体は可能ですが、このソリューションをセットアップし、すべてのサービスを構成するのは容易ではありません。

このブログ記事では、VPC フローのログデータを収集、分析、資格するための完璧なソリューションについて解説します。さらに、独自のアカウントにこのソリューションを効果的にデプロイできる 1 つの AWS CloudFormation テンプレートを作成しました。

ソリューションの概要

このセクションではアーキテクチャの概要とこのソリューションの各ステップについて解説します。

私たちは 1 回限り、またはアドホックでフローログデータをクエリする機能を必要としています。また、ほぼリアルタイムでそれを分析できる手立ても必要です。つまり、私たちのフローログデータはこのソリューションを通して 2 つのパスを取ることになります。アドホッククエリには、Amazon Athena を使用します。 Athena を使用することで、標準の SQL を使用し、S3 に書き込まれたデータをクエリできます。クエリパフォーマンスを改善し、コストを削減する Athena のベストプラクティスは、Apache Parquet などの列形式でデータを保存する方法です。このソリューションでは Kinesis Data Firehose のレコード形式変換機能を使用して、S3 にデータを書き込む前に、フローログのデータをParquet へと変換します。データを圧縮形式に変換する場合、列形式では Athena を使用することで、クエリの実行時に S3 からのデータスキャンの量が抑えられるため、コストが削減されます。それにより、コストが抑えられ、クエリパフォーマンスが向上します。

CloudWatch のログから Kinesis Data Firehose へデータをストリーミングすることにより、フローログデータにほぼリアルタイムの分析を行うという 2 つ目のパスが実現しました。 Kinesis Data Analytics は Kinesis Data Firehose へ配信されるとすぐに、ログデータの分析のために使用されます。 Analytics アプリケーションはフローログから主要なデータを収集し、ほぼリアルタイムの CloudWatch ダッシュボードを運用するために使用されるカスタムの CloudWatch 基準を作成します。

各ステップを細かく見ていきましょう。

1. VPC フローログ

VPC フローログ機能には VPC のネットワークフローが含まれます。このソリューションでは、1 つの VPC 内の全ネットワークトラフィックを取り込むものとします。 CloudFormation テンプレートを使用することで、取り込む VPC を定義できます。フローログの各行には、送信元と受信先の 2 つのエンティティ間を移動するパケットに関するスペース区切りの情報が含まれます。ログの行には送信元と受信先の IP アドレスとポート、パケットの数、そしてデータに実行されるアクションなど、詳細な情報が含まれます。実行されるアクションの例としては、受け入れるか拒否するかのいずれかです。以下に一般的なログの例を示します。

2 123456789010 eni-abc123de 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

行の各項目について詳しくは、VPC フローログ (フローログレコード) を参照してください。 VPC フローログが CloudWatch Logs へと配信されるまでに、およそ 10 分間、VPC フローログがパッファリングされる点に注意してください。

2. Kinesis Data Firehose へストリームする

CloudWatch Logs のサブスクリプションを作成することで、フローログが CloudWatch Logs に到達すると、自動的にストリーミングされます。このソリューションのサブスクリプションフィルタは、送信先として Kinesis Data Firehose を使用します。 Kinesis Data Firehose は Amazon S3 などのデータストアにデータをストリーミングする最も効率的な方法です。 CloudWatch Logs のサブスクリプションフィルタはまた、スペース区切りのログの行を構文解析し、ログの各行に構造化された JSON オブジェクトを作成するように構成されています。オブジェクトの各属性の命名規則は、VPC フローログ別の各要素によって定義された名前に従います。そのため、前述のログ行の例では、以下の JSON レコードをストリーミングします。

 {
    "version": 2,
    "account-id": "123456789010",
    "interface-id": "eni-abc123de",
    "srcaddr": "172.31.16.139",
    "dstaddr": "172.31.16.21",
    "srcport": 20641,
    "dstport": 22,
    "protocol": 6,
    "packets": 20,
    "bytes": 4249,
    "start": 1418530010,
    "end": 1418530070,
    "action": "ACCEPT",
    "log-status": "OK"
}

CloudWatch Logs のサブスクリプションは、gzip 圧縮されたレコードコレクションとして、設定された宛先にデータを送信します。データを分析するために、まずこのファイルを解凍する必要があります。

3. AWS Lambda を使用してレコードを解凍する

ファイルの最終送信先に書き込む前にストリーミングするデータの変換または強化が必要になる状況がある可能性があります。このソリューションでは CloudWatch Logs からストリーミングされるデータを解凍する必要があります。 Amazon Kinesis Data Firehose のデータ変換機能を使用すると、AWS Lambda の関数を使ってデータを解凍できます。 Kinesis Data Firehose が関数の呼び出しを管理します。関数の中でデータは解凍され、Kinesis Data Firehose に戻されます。 Lambda 関数の詳細なソースコードはこちらで参照できます。

4. Apache Parquet にデータを変換する

Amazon Athena で各種機能の実行を活用するために、ストリーミングデータを S3 へパーシストする前に、Apache Parquet 形式に変換します。この変換を実行するために、Kinesis Data Firehose のレコード形式変換機能を使用します。 JSON 形式から Parquet 形式へ変換する際、Kinesis Data Firehose ではスキーマを確認しておく必要があります。これを実行するために、Glue データカタログで表を構成します。この表では、受信する JSON レコードの属性を表のフィールドにマッピングします。

5. Amazon S3 へデータをパーシストする

Kinesis Data Firehose のデータ形式変換機能を使用する場合、唯一のサポート送信先は S3 になります。 Kinesis Data Firehose は一定期間またはデータサイズがしきい値に達するまでデータをバッファリングし、その後 S3 に Parquet 形式ファイルを作成します。一般的に、Parquet 形式に変換することで、ファイルは効率的に圧縮されます。ファイルサイズが小さすぎるのは、Athena クエリ用として最適ではありません。 S3 で作成されるファイルのサイズを最大化するためにこのソリューションは 15 分間または 128 MB までバッファリングを実行するよう構成されています。ただし、この構成は Kinesis Data Firehose コンソールでお客様のニーズに合うように調整できます。

6. Athena の SQL でフローログをクエリする

このソリューションでは、Athena はフローログデータにクエリを実行できるようにするため、Glue Data Catalog で作成されたデータベースと表を使用します。この記事の後半でサンプルクエリをご紹介しています。ご覧ください。

7. Kinesis Data Analytics でほぼリアルタイムにネットワークフローを分析する

ここまでの 6 つのステップを通じてデータを追跡することで、このソリューションでは Athena で SQL を使用してフローログをクエリできるようになります。これはアドホッククエリ、または長期間に生成されたデータのクエリを実行するのに最適です。しかし、このデータを最大限に活用するには、生成後できるだけ早急にそのデータを分析する必要があります。これを達成するために、このソリューションでは Kinesis Data Analytics (KDA) を使用し、フローログの分析や一部の直近の洞察を抽出しています。 Kinesis Data Analytics (KDA) では、SQL を使用することでストリーミングデータにクエリを実行し、データから直近の洞察を取得できるようにしています。このソリューションでは KDA アプリケーションは Lambda 関数を使用して gzip 圧縮された Kinesis Data Firehose のレコードを解凍し、フローログデータを分析して、関心事項の集約を作成します。 KDA アプリケーションは以下の集約を作成します。

拒否された TCP パケットの数、15 分ごと。
プロトコル別の拒否された TCP パケットの数、15 分ごと。

これらのメトリックスは 15 分ごとの時間枠で集約されます。その時間枠の最後で、KDA は Lambda 関数を呼び出し、関数の入力値として集約した値を渡します。

8. カスタムの CloudWatch メトリックスとして集約値を書き込む

KDA は 15 分の時間枠の最後で、Lambda 関数を呼び出し、関数の入力値として集約した値を渡します。 Lambda 関数はこれらの値を CloudWatch にカスタムメトリックスとして書き込みます。これにより、このソリューションで CloudWatch のアラームを使用し、これらのメトリックスのアラームをサポートできるようになります。そして、カスタムダッシュボードがメトリックスから作成されるようになります。

9. CloudWatch ダッシュボードで集約データを表示する

CloudWatch ダッシュボードはカスタマイズ可能な CloudWatch コンソールのホームページで、1 つの画面でリソースをモニタリングすることが可能です。 AWS のリソースようにメトリックスとアラームのカスタマイズしたビューを作成するために、CloudWatch ダッシュボードを使用できます。このソリューションでは、KDA アプリケーションで作成されたカスタムの集約をモニタリングするダッシュボードを作成します。このソリューションは始めやすいようにサンプルのダッシュボードを作成しますが、メトリックスを確認して、ニーズに合うダッシュボードとアラームを作成してください。

ソリューションのデプロイ

このソリューションを独自のアカウントへデプロイするには、スタックを作成するために CloudFormation テンプレートを使用してください。ソリューションのスタックは次の AWS リージョンにデプロイできます: 米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)。デプロイするには、デプロイ先のリージョンのリンクを選択してください。そのリージョンの CloudFormation コンソールが開き、テンプレートの URL が自動入力されます。

ソリューションを次の場所にデプロイする:

米国東部 (バージニア北部)

CloudFormation の Create Stack (スタックの作成) ウィザードが開きます。テンプレートのロケーションが自動入力されます。 [Next] (次へ) をクリックすると、いくつかのテンプレートのパラメータに値を入力するよう求めるメッセージが表示されます。

各パラメータの数値を確認します。

Stack name — この CloudFormation スタックの名称です。デフォルトの名前から変更することもできますが、短い名前を選択し (16 文字以下)、名前には小文字のみを使用してください。ここで使用する値は、このスタックによって作成される多数のリソース名のプレフィックスとして使用されます。小文字の簡潔な名前を指定することで、これらのリソース名がリソースの命名ルールに一致するようになります。
S3BucketName — Parquet ファイルが配信される S3 バケットの名前。この名前はグローバルにユニークである必要があります。
VPCId — フローログがキャプチャされる既存の VPC の ID。

[Next] (次へ) を選択して CloudFormation ウィザードの残りのフィールドのデフォルト値を受け入れます。しばらくするとスタックが作成されます。

フローログデータを分析する

スタックがデプロイされたあと、Athena でデータをクエリしたり、CloudWatch でデータを表示したりできるようになるまで最高で 15 分ほどかかる場合があります。 VPC 内のネットワークトラフィックについて学習するために、Athena で実行可能なサンプルクエリをいくつか見ていきましょう。

スタックをデプロイしたリージョンの Athena コンソールにナビゲートします。コンソールで「vpc_flow_logs」という名前のデータベースを選択します。このデータベースには「flow_logs」という表があるのが分かります。次のクエリを実行して VPC 内で最も多く拒否されるプロトコルがどれかを確認します。

select protocol, sum(packets) as rejected_packets
from flow_logs
where action = 'REJECT'
group by protocol
order by rejected_packets desc

次の例と似たような結果が戻るはずです

この例では Internet Assigned Numbers Authority (IANA) により定義された標準に従うプロトコルボックスの値を示しています。つまり、前の例では、最初の 2 件の拒否されたプロトコルは TCP と ICMP です。

以下は、VPC のネットワークトラフィックを理解するのに役立つ追加クエリです。

過去 2 週間にパケットが拒否された IP アドレスの上位 10 件を特定します。

SELECT
	srcaddr,
	SUM(packets) AS rejected_packets
FROM flow_logs
WHERE start >= current_timestamp - interval '14' day
GROUP BY srcaddr
ORDER BY rejected_packets DESC
LIMIT 10;

HTTPS リクエストの受信数が最も多いサーバーの上位 10 台を特定します。

SELECT
	dstaddr,
	SUM(packets) AS packet_count
FROM flow_logs
WHERE dstport = '443'
GROUP BY dstaddr
ORDER BY packet_count DESC
LIMIT 10;

続いて、Kinesis Data Analytics を使用して実行するリアルタイムの分析について見てみましょう。デフォルトでこのソリューションは「VPC-Flow-Log-Analysis」というダッシュボードを作成します。このダッシュボードにデフォルトウィジェットを作成しました。 KDA によって生成される集約データは、以下の例に見られるように、いくつかのグラフに描写されています。

この例では、プロトコルごとの拒否されたパケットのチャートが可能性のある全プロトコルのサブセットを描写するよう作成されたことを示しています。このウィジェットを変更して、お客様の環境に適切なプロトコルを表示します。

次のステップ

このブログ記事で概説したソリューションは、VPC フローログの分析を開始するのに効率的な方法を説明しています。このソリューションを最大限に活用するには、次の手順を考慮してください。

Athena のクエリパフォーマンスを最適化するために、Glue 表にパーティションを作成します。現在のソリューションは Y/M/D/H ごとに区分された S3 にデータを作成します。しかし、これらの S3 プレフィックスは Glue パーティションに自動的にマッピングされません。これは Athena のクエリがすべての Parquet ファイルをスキャンすることを意味します。データ量が増えるにつれ、Athena のクエリのパフォーマンスは低下します。パーティションの作成と Athena のチューニングについて詳しくは、Top 10 Performance Tuning Tips for Amazon Athenaを参照してください。
他の VPC 、あるいは、別のリージョンにソリューションを適用します。もし、アカウントに複数の VPC がある場合、またはインフラストラクチャが複数のリージョンにデプロイされている場合には、それらのリージョンにもスタックを作成する必要があります。同一リージョン内に複数の VPC がある場合は、別の VPC コンソールを使用して、他の VPC ごとに新しいフローログを作成できます。スタックが最初に作成されたときに作成された同一の送信先ロググループに配信するフローログを構成します (CloudFormation テンプレートの CWLogGroupName パラメータ値)。
CloudWatch ダッシュボードでデフォルトウィジェットを変更します。このスタックはデフォルトの CloudWatch ダッシュボードを 2 つ作成しました。しかし、ニーズに合わせて、また、ご使用の環境のフローログから得たいインサイトをベースにさらに多く作成することも可能です。
ネットワークの動向についてさらに理解を深めるために、Athena で他のクエリを作成します。

結論

このブログ記事で作成されたソリューションを使用することで、VPC のネットワークトラフィックを簡単に分析できます。ほぼリアルタイムのソリューションと、履歴データにクエリを実行する機能の両方を実現できます。システムのニーズを満たすために、クエリと独自の可視化にこのソリューションを拡張することで、このソリューションを最大限に活用できます。

その他の参考資料

この記事が参考になった場合は、Analyze Apache Parquet optimized data using Amazon Kinesis Data Firehose, Amazon Athena, and Amazon Redshift、Preprocessing Data in Amazon Kinesis Analytics with AWS Lambdaもぜひご覧ください。

今回のブログ投稿者について

Allan MacInnis はアマゾンウェブサービスのソリューションアーキテクトです。Amazon Kinesis を使用してデータストリーミングソリューションの構築に関連した業務で、お客様を支援しています。余暇には、マウンテンバイクで山へ出かけたり、家族との時間を楽しんだりしています。

Amazon Web Services ブログ