AWS の VPC Flow Logs を Datadog に流し込むときのポイント

最近会社で複数の VPC の間で Peering を設定する機会があったので監視とデバッグ用途も兼ねて Flow Logs を Datadog に流し込むように設定しました。

公式のチュートリアルでは複数の設定方法が紹介されていてどれを選ぶか迷ったし、ログを見やすくするコツを見つけたのでここで共有します。

VPC Flow Logs ってなんなん？

公式ドキュメントによると

VPC フローログは、VPC のネットワークインターフェイスとの間で行き来する IP トラフィックに関する情報をキャプチャできるようにする機能です。
<中略>
フローログは、多くのタスクで役立ちます。たとえば、特定のトラフィックがインスタンスに到達していない場合のトラブルシューティングに役立ちます。これにより、制限が過度に厳しいセキュリティグループルールを診断できます。また、セキュリティツールとしてフローツールを使用し、インスタンスに達しているトラフィックをモニタリングすることができます。
-- AWS ドキュメント --

今回は VPC Peering のデバッグ（簡単に言うとどこで詰まっているか）と継続的な疎通確認のために使わせていただきました。

VPC Flow Logs の取得方法

VPC Flow Logs を Datadog に取り込む方法は主に三つあります。

1. ログを CloudWatch に吐き出して Datadog Lambda function 経由で渡す方法
2. ログを S3 に吐き出して Datadog Lambda function 経由で渡す方法
3. 上の設定を Datadog Lambda function に任せる方法

理想は3番の方法で管理コストを下げるのが望ましいのですが、今回は同じ AWS アカウントで管理されているレガシーシステムと監視体制を綺麗に分けたかったので1番と2番の比較になりました。

CloudWatch 経由の問題点

CloudWatch 経由だと比較的にリアルタイムに近い形でログが Datadog に到達するので最初はこの方法で連携を試してみましたがすぐに問題を発見しました。

それは Lambda の発火頻度が非常に高いことです。仕組み的には CloudWatch のイベント毎に Lambda が発火するのでその分コストがかかります。テスト環境での小規模ネットワーク通信でも一分約 15 回発火し、毎回約 0.5 秒課金されるので長期的に考えるコストが少し心配でしたので図の 10:00 前後に S3 方式に切り替えました。

S3経由の問題点

S3経由の場合 AWS 内部でバッチ処理が行われて定期的に（約5分）指定された S3 にログファイルを書き込む仕様になっていますので、その S3 のイベントを Datadog Lambda function に向けるとファイル内容をアップロードしてくれる仕組みです。ここで気づいた人もいると思いますが、問題は VPC のイベントが発生した時間と Datadog にアップロードされる時間に差分が発生することです。

赤棒の左側が本来の状態ですが、Datadog がバッチ処理によるアップロード時間をイベントの発生時間と認識したため全ての VPC Flow Logs がアップロードした時間帯に集中しています。もちろん読めなくはないが、このままでは直感的ではないためデバッグの際に余計な神経をすり減らすことにます。

クロックスキュー修正

幸い Datadog には強力なパイプライン機能が備わっているのでこれを使ってクロックスキュー（時間差）を修正しました。

ロジックは非常にシンプルで、訳すとログのアップロード時間の代わりにログ内のタイムスタンプを使ってように設定してます。一つ前のスクリーンショットでは想像しづらかったと思いますが、赤棒の右と左のイベント量は全く同じです。違うところはイベントの発生時間を設定したことによってログが Datadog にアップロードした時間に固まるのではなく、実際に発生した時間帯にマッピングされているところです。

最後に

今回は VPC のデバッグや監視と Datadog の連携方法の違いについて少しお話しさせていただきました。微々たる違いかもしれませんが、この一手間によって開発と運用が少しでも楽になれると幸いです。