Amazon S3を苦しめた“ログの山” 「Iceberg」でログ抽出を数時間から数分に：データに埋もれるエンジニアを救う

「Amazon S3」の裏側では膨大なログが生成され、エンジニアはPB級のデータから必要な情報をすぐに見つけられらない状況に陥っていた。数時間を要した検索を、「Apache Iceberg」への移行で数分に短縮した方法とは。

[TechTargetジャパン]

　Amazon Web Services（AWS）が提供するクラウドオブジェクトストレージ「Amazon Simple Storage Service」（Amazon S3）は、写真や医療記録から機械学習モデルまで、世界中のあらゆるデータを預かるインフラだ。その裏側では、サービスを運用、監視するための内部ログが絶えず生成されており、データの保存容量はE（エクサ）B規模に達している。

　この膨大なデータの山から特定の障害原因やレイテンシ（遅延）のスパイクを特定するのは容易ではない。かつてのAmazon S3運用チームは、P（ペタ）B級のログから必要な情報を探すために、JavaScriptで複雑な検索条件や処理を記述・実行していた。しかしデータ量が劇的に増加するにつれて、結果を得るまでに数時間から数日かかるようになり、エンジニアは分析そのものよりもデータを探し出すことに時間を奪われるようになっていた。

　この課題を根本から解決するため、Amazon S3運用チームはデータ管理システムにオープンソースのテーブルフォーマット「Apache Iceberg」を採用した。ログの形式を、テキスト形式から各列（カラム）を個別に記録する「列指向形式」に切り替える大規模な変革だ。結果として、クエリの実行時間を数時間から数分へと短縮し、数千時間に及ぶ作業時間を本来の業務に還元することに成功している。

　これほど巨大で、「絶対に止めることが許されない」システムのログインフラを、どのようにして移行したのか。その背景には、既存システムに影響を与えない工夫と、データスキャン量を最小化する緻密な仕組みがあった。

アプリケーションを変更させない「中継型」の移行戦略

併せて読みたいお薦め記事

Apache Icebergの実力

• 覇権争いは終了？　SnowflakeやSAPが「Apache Iceberg」の採用を急ぐ理由
• 高齢のITエンジニアは“人手不足の救世主”になり得るか

　2025年に開催されたAWSの年次技術カンファレンス「AWS re:Invent 2025」のセッション「Inside S3: Lessons from exabyte-scale data lake modernization」において、Amazon S3運用チームのプリンシパルエンジニアであるカール・サマーズ氏と、シニアスペシャリストソリューションズアーキテクトのラン・パーガミン氏が、その舞台裏を語った。

　Amazon S3を構成する数万のマイクロサービスのログ出力形式を、一斉にApache Iceberg向けの「Apache Parquet」（列指向のデータファイルフォーマット）に変更することは現実的ではない。移行における最大の原則は、データを出力するシステムのワークフローを変更させないことだった。

　そこで運用チームは、従来のテキストログをパース（分析）して構造化し、データを圧縮した上でApache Parquet形式のファイルを作成する独自のトランスコーダー（データ変換機能）を開発した。既存のアプリケーションはこれまでと同じAPIと形式でログを出力し続け、バックグラウンドでトランスコーダーがApache Iceberg形式のテーブルへの配置を担う仕組みを構築した。

　変更を適用する際には「サーバごと」「アベイラビリティーゾーンごと」など段階的なアプローチを採った。一時的に旧システムと新システムにデータを二重出力させることで、データの一貫性やパフォーマンスを監視し、予期せぬ不具合が発生した際には即座に元の状態へ戻せる「保険」をかけた上で移行を進めた。

SQLとプッシュダウン最適化によるスキャン量の削減

　ログへのアクセス方法も刷新された。検索のために複雑なJavaScriptスクリプトを個別に書く体制から脱却し、誰もが必要なデータを見つけられるようログのカタログ化を進め、標準的なSQLをインタフェースとして採用した。エンジニアが発行したSQLクエリに対し、ストレージで検索対象を最小限に絞り込む「プッシュダウン最適化」も実装した。

• 不要データのスキップ（Predicate Pushdown）
  • ログをスキャンする際、クエリの条件に合致しない不要な操作タイプのレコードはそもそも読み込まずに除外する手法。
• 必要な列のみの抽出（Projection Pushdown）
  • 条件に合致したレコードの中から、クエリに必要な情報を含むカラム（列）だけを抽出して取得する手法。

　この2つの最適化によって、処理対象となる行数と、各行から抽出するデータ量の両方を削減し、コンピューティングリソースの消費を抑えながらクエリを高速化させた。

データ配置の最適化

　クエリの最適化に加えて、テキストログという物理構造の限界に突き当たる。そこでApache Icebergの機能を活用し、物理的なデータレイアウトの最適化が図られた。

　1つ目はインテリジェントなデータ分割だ。Apache Icebergのマニフェストファイル（管理用メタデータファイル）に含まれる統計情報を利用することで、クエリに関連しないデータファイル群を丸ごとスキップする「二段階プルーニング」が可能になる。

　2つ目はソート戦略だ。リクエストIDなどの特定のキーでログデータをソートして保存しておけば、Apache Icebergは各ファイルが保持するデータの範囲を把握し、条件に合致する特定のファイルだけにアクセスできる。適切なパーティショニングとソートを組み合わせることで、エクサバイトの海からスキャン対象を数桁単位で絞り込むことに成功した。

適応力と構造を両立する3層のスキーマ設計

　Amazon S3のログは日々項目が変化するため、構造化による検索スピードと、未知のデータを扱う適応力のバランスを取る必要がある。そこで運用チームは、過去のクエリパターンを分析し、ログデータを3つの層に分類した。

1. アイデンティティー層
   • リクエストIDやタイムスタンプなど、ほぼ全ての検索条件に用いられる基本情報をフラットな形で保持する。
2. メトリクス層
   • パフォーマンスやリソース使用率などの数値データ。必要な項目だけを読み取れる形式でグループ化している。
3. コンテキスト層
   • デバッグ情報など、上記のどちらにも当てはまらない任意のデータ。ログに新たな要素が追加されても既存の検索処理を壊さないよう独立して保持する。

　この設計によって、高速な集計を実現しつつ、システムの成長に追従できる適応力を確保した。

---

　Amazon S3の事例が示唆しているのは、レガシーシステムから最新のデータレイクへモダナイゼーションを図る際、技術そのものの導入以上に「稼働中のシステムや現場のエンジニアに影響を与えずにどう橋渡しをするか」が鍵を握るということだ。既存の運用を尊重しながら、データ構造を最適化していく段階的なアプローチは、企業が抱えているデータをいかに活用すればよいかを示す好例だと言える。

　今後のAmazon S3のログシステムは、ログ出力エージェント自身を段階的に改修し、より効率的なコレクターを経由して直接データレイクにデータを集約する方針だ。

本稿は、AWSが2025年12月4日に公開した動画「AWS re:Invent 2025 - Inside S3: Lessons from exabyte-scale data lake modernization (STG351)」を基に作成しました。