データに埋もれるエンジニアを救う
Amazon S3を苦しめた“ログの山” 「Iceberg」でログ抽出を数時間から数分に
「Amazon S3」の裏側では膨大なログが生成され、エンジニアはPB級のデータから必要な情報をすぐに見つけられらない状況に陥っていた。数時間を要した検索を、「Apache Iceberg」への移行で数分に短縮した方法とは。
Amazon Web Services(AWS)が提供するクラウドオブジェクトストレージ「Amazon Simple Storage Service」(Amazon S3)は、写真や医療記録から機械学習モデルまで、世界中のあらゆるデータを預かるインフラだ。その裏側では、サービスを運用、監視するための内部ログが絶えず生成されており、データの保存容量はE(エクサ)B規模に達している。
この膨大なデータの山から特定の障害原因やレイテンシ(遅延)のスパイクを特定するのは容易ではない。かつてのAmazon S3運用チームは、P(ペタ)B級のログから必要な情報を探すために、JavaScriptで複雑な検索条件や処理を記述・実行していた。しかしデータ量が劇的に増加するにつれて、結果を得るまでに数時間から数日かかるようになり、エンジニアは分析そのものよりもデータを探し出すことに時間を奪われるようになっていた。
この課題を根本から解決するため、Amazon S3運用チームはデータ管理システムにオープンソースのテーブルフォーマット「Apache Iceberg」を採用した。ログの形式を、テキスト形式から各列(カラム)を個別に記録する「列指向形式」に切り替える大規模な変革だ。結果として、クエリの実行時間を数時間から数分へと短縮し、数千時間に及ぶ作業時間を本来の業務に還元することに成功している。
これほど巨大で、「絶対に止めることが許されない」システムのログインフラを、どのようにして移行したのか。その背景には、既存システムに影響を与えない工夫と、データスキャン量を最小化する緻密な仕組みがあった。
アプリケーションを変更させない「中継型」の移行戦略
併せて読みたいお薦め記事
Apache Icebergの実力
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つの層に分類した。
- アイデンティティー層
- リクエストIDやタイムスタンプなど、ほぼ全ての検索条件に用いられる基本情報をフラットな形で保持する。
- メトリクス層
- パフォーマンスやリソース使用率などの数値データ。必要な項目だけを読み取れる形式でグループ化している。
- コンテキスト層
- デバッグ情報など、上記のどちらにも当てはまらない任意のデータ。ログに新たな要素が追加されても既存の検索処理を壊さないよう独立して保持する。
この設計によって、高速な集計を実現しつつ、システムの成長に追従できる適応力を確保した。
Amazon S3の事例が示唆しているのは、レガシーシステムから最新のデータレイクへモダナイゼーションを図る際、技術そのものの導入以上に「稼働中のシステムや現場のエンジニアに影響を与えずにどう橋渡しをするか」が鍵を握るということだ。既存の運用を尊重しながら、データ構造を最適化していく段階的なアプローチは、企業が抱えているデータをいかに活用すればよいかを示す好例だと言える。
今後のAmazon S3のログシステムは、ログ出力エージェント自身を段階的に改修し、より効率的なコレクターを経由して直接データレイクにデータを集約する方針だ。
本稿は、AWSが2025年12月4日に公開した動画「AWS re:Invent 2025 - Inside S3: Lessons from exabyte-scale data lake modernization (STG351)」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
関連記事
新着ホワイトペーパー PR
-
製品資料
[オーティファイ株式会社] AIでコーディングは加速したのにテストはそのまま? いまQAに必要な進化とは -
事例
[オーティファイ株式会社] QAで開発サイクルを遅延させない 8社の事例に学ぶ「テスト工程」の課題解決策 -
製品資料
[株式会社ガラパゴス] 「AIっぽい広告」の山に埋もれさせない AIマーケで着実に成果をだす秘訣とは? -
製品資料
[株式会社ガラパゴス] 「広告投資」調査レポート2026:勝ち組企業は何に投資しているのか? -
製品資料
[株式会社Helpfeel] 「問い合わせの渋滞」を解消、情シスの負担を軽減する“次世代型AI”活用方法
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
「Copilot」はなぜ放置される? “議事録要約止まり”を脱する処方箋
-
2
9割が頓挫する「AI内製化」 差がついたのはツールより設計力
-
3
脱VMwareの前提が崩れる BroadcomのVDDK公開停止で確認すべき点
-
4
膨らむAIコストに歯止め GitHubのマルチモデルルーターは何が違うのか
-
5
JSONをやめてPythonで送る トークン消費を約7割抑えるAIの設計
-
6
「WhatsApp」の暗号化は万全ではない? E2EEとマルチデバイス機能が生む死角
-
7
技術力だけでは「上に行けない」 シヤチハタCDOが語る、情シスが次の役割をつかむ条件
-
8
「コンテナ型データセンターの検討状況と課題」に関するアンケート
-
9
社内開発×ノーコードで検証速度を4倍にしたエアトリのWebサイト改善術
-
10
AI全部入り「Microsoft 365 E7」に企業が二の足を踏む訳 移行意向はわずか4%
ホワイトペーパーランキング PR
-
1
5回聞くだけじゃ足りない? トヨタ式「なぜなぜ分析」の正しい実践方法
-
2
生成AIで文書活用を進めるには? 効率化と安全性をどう両立する
-
3
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
4
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
5
インシデント対応工数を約3割削減、東京ガスの事例に学ぶ監視体制刷新のコツ
-
6
国税庁の次世代基幹システム「KSK2」稼働開始に向けて、対応すべき変更点とは?
-
7
5分で分かる「セキュア大容量ファイル転送サービス」の機能とメリット
-
8
「スクラム」と「カンバン」の違いとは? アジャイル型開発手法を徹底比較
-
9
ドラマで分かる、標的型攻撃メールの被害を受ける企業と回避できる企業の分岐点
-
10
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー