データに埋もれるエンジニアを救う
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
-
製品資料
“攻撃者優位”なサイバーセキュリティ、全ての「穴」をふさぐ方法とは? -
製品資料
実際に悪用される脆弱性は4%前後 優先的に対処すべき脆弱性を把握するには? -
製品資料
HubSpotの機能を拡張する法人データ活用法 -
製品資料
面倒で非生産的な「名寄せ」作業 高精度&高効率に実施するには? -
製品資料
名刺管理には「その先」がある 成果のでない営業活動から脱却する秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
Netflixのバックエンドは「ほぼJava」 3000超のアプリを支える開発基盤の裏側
-
2
ISMSの“コンサル丸投げ”が招く数千万円の無駄 NTTドコモビジネスの脱出劇
-
3
「Microsoft 365」が乗っ取られる 跡形もなくMFAを破る手口
-
4
「WSUS」終了の時限爆弾 “本命”移行先ツールとMicrosoft提唱の新管理手法
-
5
「結局使わなくなる」Microsoft 365 Copilotを半年で定着 キリンの3施策
-
6
アラート47%削減 オープンハウスが捨てた「全部メール通知」の監視体制
-
7
IT製品の導入に関するアンケート「サーバ&ストレージ」編
-
8
継続利用は4割どまり M365 Copilotが「効く業務」と期待外れの境界
-
9
「企業におけるAIの運用」に関するアンケート
-
10
「OSの選定・導入」に関するアンケート
ホワイトペーパーランキング PR
-
1
AIエージェントで多様な日常業務を効率化するための入門ガイド
-
2
財務・会計はAI活用でどう変わる? 調査で見えた変革の道筋
-
3
AIが「わざわざ使うツール」になっていない? 業務で自然に使う導線にする秘訣
-
4
JR西日本ITソリューションズが「監視業務の属人化」を解消した方法とは?
-
5
「脱Excel」か「Excel快適化」か? 現場にやさしい業務改善の進め方
-
6
「結局、一部の人しか使わない」 AI活用が業務に定着しない根本的な理由
-
7
コスト分析で見る「デバイス復旧」の代償 損失額から導きだされた投資戦略とは
-
8
Macの安全神話は崩壊? 最新の脅威動向から見えた攻撃のトレンドと有効な対策
-
9
ゼロトラストにおける「IDaaSの課題」と補完すべき重要機能とは?
-
10
「NAS」「SAN」「DAS」は何が違う? いまさら聞けないストレージの基礎
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー