【AWSのログ周りを整理する】第3回 運ぶ ── 発生源と置き場のあいだ

Transcript

1. 2026年9月 AWSのログ周りを整理する 第3回 運ぶ ── 発生源と置き場のあいだ 赤神青空
2. ▪全6回のうち、今回は第3回 このシリーズの地図 第1回 全体像 第2回 出す 第3回 運ぶ 第4回 貯める 第5回 調べる 第6回 選び方 今ココ はじめに 4段に分けて位置づける ログはどこで生まれるか 発生源と置き場のあいだ コストの大半はここで決まる 貯めたログに問い合わせる 結局どう決めるのか 2/8
3. ▪どれを選んでも用途が違うだけ 転送の3つの型 A B C CloudWatch Logs に集めてから外へ出す ロググループ サブスクリプション Data Firehose Amazon S Pipelines ロググループ S Tables Data Streams Lambda / KCL 任意の宛先 CloudWatch の中で変換まで済ませる データソース ⽣ストリームを⾃前のコンシューマで捌く プロデューサー A型が一番よく見る形。迷ったらここから始める 今ココ 運ぶ 3/8
4. ▪A型の起点サブスクリプションフィルタ ── 外へ出すときは必ずここ ロググループに付ける転送設定。外に出すときは必ずここが起点。 フィルタパターンで必要な行だけ絞れる 宛先は Firehose / Lambda / Data Streams アカウントをまたいだ集約もできる 低頻度アクセスクラスでは使えない点に注意 今ココ 運ぶ 4/8
5. ▪A型の運び役 Amazon Data Firehose ── 旧 Kinesis Data Firehose バッファが溜まったら勝手に配信する。コンシューマを書かなくてよい。 サイズか時間のどちらかでバッファして配信 宛先は S3 / OpenSearch / Redshift / HTTP 途中でLambdaを挟んで整形できる Parquetへの形式変換もここで指定できる 今ココ 運ぶ 5/8
6. ▪A型で使うか、C型で使うか Firehose と Data Streams Data Firehose（A型） 宛先に自動で配信する コンシューマ不要 数十秒〜数分の遅延が出る 流れた量に対する課金 Data Streams（C型） 生のストリームを保持する コンシューマを自分で書く 複数の処理系が同じ列を読める 秒未満のリアルタイム性が要るとき ログの転送だけが目的なら、ほぼ Firehose で足ります。 今ココ 運ぶ 6/8
7. ▪B型の中身CloudWatch Pipelines ── 2025年のre:Inventで追加 変換のためだけにLambdaを書く必要がなくなったのが大きい。 ソースは CloudWatch Logs / S3 / API の3系統 OCSF / CSV / Grok などのパーサーで整形する 条件分岐とDrop Eventsで不要なログを落とせる 出力先は CloudWatch Logs のみ。S3へは別途必要 処理自体は追加料金なし（取り込みと保管は通常どおり） 今ココ 運ぶ 7/8
8. ▪第3回で覚えて帰るのは3つ まとめ 01 転送は3つの型で足りる 迷ったらA型。C型は自前で処理を書くときだけ。 02 A型の起点と運び役 サブスクリプションフィルタで出し、Firehoseで運ぶ。 03 B型は変換に限られる 出力先はCloudWatch Logsのみ。S3へはA型を足す。 次回は「貯める」── コストの大半が決まる段を見ていきます 今ココ おわりに 8/8