LINEヤフーは、総容量3ペタバイトを超えるオンプレミスDWH（データウェアハウス）をAmazon Redshiftへ移行した。ピーク時の性能課題に対し、マルチAZ構成や自動ワークロード管理（WLM）を導入して対処。バッチ処理の高速化やNoOps化を実現し、公式MCPサーバ整備による「AIレディ」な基盤構築を進めている。
大規模なオンプレミスDWHのクラウド移行は一筋縄ではいかない。技術評価や総所有コスト（TCO）の検討に加え、既存環境のバッチ処理が集中するピーク時の負荷をクラウドで再現し、レスポンス要求を満たせるかどうかの検証が必要になる。さらに、社内IPアドレスの拡張や構成変更の難しさなど、考慮すべき点は多い。
3000人超が使うペタバイト級DWHに最適な基盤とは
ペタバイト級のデータ基盤をクラウドシフトしたLINEヤフーの取り組みは、これらに対処した好例だ。多数のサービスが相乗りするマルチテナント環境において、同社は厳しい性能要求をいかにクリアし、生成AI時代を見据えた次世代プラットフォームへの移行を果たしたのか。
同社の田中崇行氏（Data CBU データPFインフラユニット データプロセッシングPFディビジョン）は、2026年6月開催の「AWS Summit Japan 2026」においてプロジェクトの詳細を語った。本稿では同氏の講演を基に、大規模負荷検証の実際と「AIレディ」なデータ基盤構造へのアプローチを紹介する。
田中氏はDWH移行プロジェクトをリードし、現在はDWHを活用したAIプロジェクトを推進している。所管するデータ基盤組織は「Data for All」というビジョンを掲げ、社内外のユーザーのために便利で安全なデータ基盤を提供することを目指している。経営統合によって同社が扱うデータ量は爆発的に増加し、オンプレミスのHadoop基盤には現在1.1エクサバイト超のデータが蓄積されている。
クラウド移行の対象となったのは、Hadoop基盤からの同期データや分析過程で生成されたデータを含む、総容量3ペタバイト超のオンプレミスDWHだ。ユーザー数は3000人を超え、1日当たりのクエリ発行数は約7.25万回に達する国内有数の分析基盤である。
約400のクエリで性能検証し採用したクラウドDWH
この大規模DWHの移行に向けて、PoC（概念実証）に踏み切る契機となったのは、部門CTOからの厳しい指図だった。「『長年、現行のDWHを使い続けているが、他の新しい技術とちゃんと比較した上で判断しているのか。既存に比較し、評価すべきではないのか』と聞かれたのがスタートでした」と田中氏は振り返る。
使い慣れた環境を無批判に踏襲せず、最先端の優れた技術を客観的に評価することが求められた。移行作業の工数やTCOの評価も要件に含め、クラウドDWHを比較対象に据えた大規模なPoCを開始した。
PoCの技術検証項目（クライテリア）を策定するに当たり、基本的な機能や可用性などの一般的な非機能要件では、既存環境とクラウドDWHの間に決定的な差は見られなかった。そのため、評価の軸をパフォーマンスに絞り込み、「性能要件の検証に注力しました」と田中氏は話す。
移行対象のDWHは、「広告」「コマースショッピング」「その他」の3クラスタから構成されるマルチテナント環境だ。単純なベンチマークテストでは実態に即した計測ができないため、クラスタ別に代表的なクエリ群を選定し、データを全量移行して実際の負荷を再現する検証手法を採用した。数ペタバイトのデータ転送には多大な時間を要したという。検証用の約400クエリは、各種クエリタイプ（SELECT、INSERTなど）やテーブル結合数、データ量で分類し、網羅的に選定した。
検証の結果、「Amazon Redshift」はSELECT処理の単体・同時実行性能で明確な優位性を示した。一方で、大量行のINSERTや特定の述語を含むクエリは極端に遅くなる傾向も確認。この性能劣化にはクエリの書き換えで対処する方針を固めた。書き換え工数もTCOに加算して総合評価し、最終的に性能とTCOの両クライテリアをクリアしたことから、Amazon Redshiftの採用を決定した。
移行プロジェクトの軌跡とアーキテクチャの工夫
PoC開始から約1年半を経てRedshiftの採用を決め、さらに約1年をかけて導入計画を策定。2024年前半にリザーブドインスタンスを購入すると、AWSプロフェッショナルサービスとともに移行プロジェクトを本格始動させた。
移行作業ではユーザー側でクエリの書き換えや検証が発生するため、当初から協力会社のエンジニアを投入して支援体制を構築した。プロジェクトが佳境に入るとサポート要求が増え、技術課題も高度化したため、Redshiftを本番相当のインスタンスへ増強。協力会社のエンジニアも体制も倍増し、2026年3月末にすべての移行作業を完遂させた。
Redshiftによる新DWH環境は、AWSアカウント内にVPC（Virtual Private Cloud）を二段構えにして構成している。Redshiftクラスタを配置するVPCと、社内ネットワークと接続するエンドポイント用VPCを分離し、Redshift Managed VPCエンドポイントでルーティングする仕組みだ。
これはオンプレミスとクラウドを接続する環境において厳しく制限される、社内IPアドレス空間の制約を回避するための工夫だ。VPCを二段構えにすることで全社のネットワークルールを守りつつ、将来的な拡張に必要なIPアドレス空間を豊富に確保している。
クラスタは、RA3.16xlargeノードを全体で60以上配置する巨大な構成だ。クラスタ間にはデータシェアリング構造を採用し、物理的なデータコピーの手間を削減。データの鮮度を保ったまま横断的な分析が可能となった。ただし、シェアリングされたビューの多段参照はできず、クラスタ間の利用状況を正確に把握しておかなければ権限制御が複雑化するため、運用面での厳密な統制が求められる。
マルチAZ構成、自動ワークロード管理で性能問題を克服
順調に見えた移行プロジェクトだが、終盤に大きな課題が発覚する。大規模ユーザーから、「選択したクエリの同時実行検証だけでは、バッチ処理が集中するピーク時の運用に本当に対応できるか不安だ」という指摘が入ったのだ。
これを受け、既存DWHのピーク時ワークロードを疑似的に再現して追加検証を実施した結果、想定したノード数では性能を満たせないことが判明する。従来環境では合計9万5247秒で完了していた処理が、Redshift上では2倍以上の時間を要した。
対策として単純にノード数を増やせば予算を超過してしまう。そこで、田中氏らはAWSや事業部門と協議し、「95%のクエリが38分以内で終わること、かつ平均応答時間が既存DWHの9万5247秒以下であること」を新たなクライテリアに設定した。
このハードルをクリアする端緒となったのが、アーキテクチャの根本的な見直しだ。これまでのシングルアベイラビリティゾーン（Single AZ）構成からマルチAZ構成に変更し、自動ワークロード管理（WLM）を導入した。マルチAZ構成ではプライマリクラスタの負荷が高まると、自動的に別AZのセカンダリクラスタへクエリをルーティングする。
これによってキュー待機時間が短縮され、同時実行性能が飛躍的に向上した。手動設定だったWLMを自動化し、機械学習によるリソース最適化に任せたこともパフォーマンス向上に貢献している。
この構成にたどり着くまでに、「Elastic Resize」機能、「Classic Resize」機能（※）を活用し、短期間で何度も検証を繰り返せたことが、コストと性能要件を満たす構成を見つける助けとなった。
ただし、個別の性能向上をもたらすマルチAZ構成にも留意点がある。「何でもうまくセカンダリーに振られるわけではなく、ルーティングできるクエリのタイプに制限があることには注意が必要です」と田中氏は指摘する。読み取り処理はスケールしやすいが、一部の更新系処理などは対象外となるため、制限を把握した上でアプリケーション側の処理を設計していく必要がある。
※Elastic ResizeとClassic ResizeはRedshiftのクラスタ構成を変更する機能。前者は数分でノード数を素早く増減でき、後者はノードのタイプ自体を変更できる。環境を再構築することなく柔軟にスペックを変えられるため、迅速な検証に役立つ。
クラウド化がもたらした3つの技術的恩恵
数々の困難を乗り越えて完遂したRedshiftへの移行は、ユーザー部門と基盤チームの双方に技術的恩恵をもたらした。
その1つ目が、バッチ処理性能の向上だ。特定ジョブをまとめたDAG（Directed Acyclic Graph）の実行時間を集計したところ、全体平均で26%の高速化が確認された。データの取得や集計処理が大幅に短縮されている。UPDATEやINSERTなど更新系処理の一部に見られた遅延は、一時テーブルを使ったロード処理へロジックを変換して対処している。
2つ目は、インフラ構築スピードと柔軟性の飛躍的な向上だ。マルチテナント環境では、しばしば「特定のプロジェクト用に独立した専用クラスタが欲しい」といった要望が寄せられる。オンプレミスならハードウェア調達から数カ月を要するが、現在は「AWS CloudFormation」によってわずか数日で用意できる。新たに構築した専用クラスタからは、データシェアリング機能で既存クラスタのテーブルを直接参照することも可能だ。大量のデータをコピーする手間が省け、ユーザーは待たされることなくデータ分析に取り掛かれる。
3つ目は、物理的な保守作業をなくすNoOps（運用レス）化を実現し、AWSが提供する最新の技術を自社アーキテクチャに組み込めるようになったことだ。ハードウェア故障への対応やディスク交換から解放された効果は計り知れない。
「長時間のシステム停止を伴う物理メンテナンスなどが不要になった利点は大きいと思います。従業員が対応しなければならない作業が減り、非常に助かっています」と田中氏は語る。
費やしていたリソースを、基盤チームは新たな設計、開発にシフトできるようになった。今後はデータ連携を迅速化する「ゼロETL」機能の導入や、次世代DWH「Amazon Redshift RG instance」の採用に向けた検証を進めるなど、クラウドならではの先進技術を継続的に取り込んでいく考えだ。
公式MCPサーバの整備で「AIレディ」なデータ基盤へ
クラウドDWHへの移行はゴールではなく、次なるチャレンジへのスタートラインだ。LINEヤフーは現在、Redshiftによる新DWH基盤を「AIレディ」なプラットフォームへと進化させる取り組みを進めている。生成AIを組み込み、専門知識を持たないユーザーが自然言語でデータ探索をできる世界を目指している。
その中核を担うのがMCP（Model Context Protocol）サーバだ。AIクライアントからのリクエストを受け取り、データベースのスキーマ情報などを安全に提供する橋渡し役となる。現在、2つのユースケースの構想が進行している。
一つは、自然言語によるDWHアクセスだ。「先月の売上データを抽出して保存して」と入力するだけで、AIがSQLを生成、発行し、取得したデータをCSV化して指定ストレージに保存するといった処理を自動化する。
もう一つは、運用チーム向けの障害予兆検知と自動処置である。膨大な監視アラートをAIが受信して過去の類似障害ログと照合し、異常の兆候を捉えた際にはプロセス再起動などの一次対応までを自律的に実行する仕組みの構築を進めている。
技術検証は既に完了しているが、実装段階で新たな課題も浮上した。社内のAI活用が想定以上に早く進み、各部所から「独自に立てたMCPサーバをRedshiftに繋ぎたい」という要望が多数寄せられている。
こうした接続の野放しはセキュリティインシデントを招きかねない。そのため、データ基盤チームでは、安全な接続環境を提供すべく、セキュリティ要件を満たした公式MCPサーバの開発を急ピッチで進めているところだ。
「AIの活用が社内で加速すればするほど、それを支えるデータの重要性が増します。クラウドへ移行したペタバイト級のDWHを、今度はAIで使いやすいかたちに整備し、誰もが安全に活用できる環境を提供していくことが、データ基盤チームの次なる使命です」と田中氏は締めくくった。
