Razor Group が AWS でモダンなデータレイクハウスを構築するまでの道のり

本記事は 2026 年 8 月 28 日 に公開された「Razor Group’s journey to a modern data lakehouse on AWS」を翻訳したものです。

Razor Group は、複数のグローバルマーケットプレイスで 250 以上のブランドを展開する、欧州有数の EC アグリゲーターです。売上高は 4 億ドルを超え、ダイナミックプライシングや在庫最適化から広告費の配分、サプライチェーンの制御に至るまで、あらゆる重要な経営判断をデータで支えています。

事業の中心にあるのが、独自プラットフォームの Razor Operating System (ROS) です。9,300 以上のデータパイプラインを通じて月間 3 億 7,000 万件を超える API 呼び出しを処理し、マーケットプレイスのシグナルを大規模な自動アクションへと変換しています。

本記事では、Razor Group が AWS 上に レイクハウスアーキテクチャを構築し、データプラットフォームを最適化した方法を紹介します。アーキテクチャ上の意思決定、段階的な移行アプローチ、そして測定可能なビジネス成果を取り上げます。ワークロードのパフォーマンス向上、インフラコストの削減、分析基盤でのマルチエンジン対応、いずれを目指す場合でも、本記事の設計図から自社に合わせて応用できる具体的な知見が得られます。

ビジネス課題: 急成長を支えるデータ基盤のスケーリング

Razor Group のブランドポートフォリオが急速に拡大するにつれ、データプラットフォームへの要求も大きく高まりました。価格決定、在庫補充、広告入札がほぼリアルタイムで行われる EC のスピードに、分析基盤を追随させる必要があったのです。

Amazon Redshift のプロビジョンドクラスターで構築した既存アーキテクチャは、初期の成長段階では十分に役割を果たしていました。しかしワークロードが多様化しデータ量が急増すると、いくつかの最適化の余地が見えてきました。

図 1: 移行前の Razor Operating System データアーキテクチャ

• ワークロードの競合: ETL、変換、分析用の 1,000 を超える SQL モデルが同じコンピューティングリソースを取り合い、処理のピーク時に競合が発生していました。
• コストと使用率のミスマッチ: クラスターは 24 時間 365 日稼働し続けていましたが、ワークロードを分析すると、コンピューティング需要の 98% はインタラクティブな分析ではなくバッチ ETL によるものでした。その結果、オフピーク時に大量のアイドル容量が生じていました。
• データ鮮度のギャップ: バッチ中心のパイプラインではデータの反映に 4〜6 時間の遅延があり、動きの速いマーケットプレイスの状況にチームが対応しきれませんでした。
• スケーリングの制約: 同時利用ユーザーとパイプラインの複雑さが増すなか、垂直スケーリングだけでは、ワークロードを分離したい、容量を柔軟に調整したいというニーズには応えられませんでした。

いずれも特定のサービスの欠陥ではありません。Razor Group のワークロードの規模と多様性に合わせて、アーキテクチャを進化させる時期に来ていることを示すものでした。

なぜレイクハウスアーキテクチャなのか

Razor Group は既存の投資を置き換えるのではなく、モダンなレイクハウスアーキテクチャを採用してワークロードの配置を最適化する機会があると捉えました。意思決定を後押しした基本原則は次のとおりです。

• オープンテーブルフォーマット: Apache Iceberg は ACID トランザクション、タイムトラベル、スキーマ進化を備えています。データは一度だけ保存され、互換性のあるどのエンジンからも重複なくアクセスできます。
• ワークロード単位の柔軟なスケーリング: データを Amazon Simple Storage Service (Amazon S3) に永続化することで、各エンジンが自身のワークロードに合わせて独立してコンピューティングをスケールできます。各エンジンはピーク処理時に起動し、アイドル時にはゼロまでスケールダウンするため、共有インフラを過剰にプロビジョニングせずに済みます。
• マルチエンジンの柔軟性: ワークロードごとに要件は異なります。負荷の高い ETL は分散 Spark 処理、アドホックな探索はサーバーレスクエリ、ビジネスインテリジェンス (BI) ダッシュボードは高性能なウェアハウスエンジンと、それぞれの目的に最適なエンジンを活用できます。

こうした方針により、Razor Group はプラットフォーム全体からアクセスできる、ガバナンスの効いた単一のデータコピーを維持しつつ、各ワークロードを最適なエンジンに適正配置できるようになりました。

ソリューションの概要

Razor Group は AWS と協力し、複数の AWS サービスがそれぞれ補完的な役割を担う包括的なレイクハウスアーキテクチャを構築しました。

図 2: AWS 上のエンドツーエンドのレイクハウスアーキテクチャ

スケールを見据えた設計: レイクハウスのビジョン

Razor Group の新アーキテクチャを支えた核心はシンプルでした。どのエンジンからもクエリできる、単一のオープンフォーマットデータレイクを構築することです。旧モデルでは、ツールごとに独自のデータコピーを保持していました。新モデルでは、Amazon S3 上の単一のオープンフォーマットデータレイクが信頼できる唯一の情報源となり、目的別に用意した複数のコンピューティングエンジンが、その時々のワークロードに応じてそこからデータを読み取ります。

一般にレイクハウスアーキテクチャと呼ばれるこの転換は、データレイクのコスト効率とスケーラビリティに、データウェアハウスのクエリ性能とガバナンスを組み合わせたものです。レイクハウスのオープンテーブルフォーマットである Apache Iceberg は、ACID トランザクション、スキーマ進化、タイムトラベルを提供し、ベンダーロックインもありません。

ストレージとガバナンス: オープンなデータ基盤

• Apache Iceberg を用いた Amazon S3 Tables (Amazon S3 の機能) — 主要なストレージレイヤーであり、ACID トランザクション、パーティション進化、タイムトラベルを備えたオープンフォーマットのテーブルを提供します。データは一度だけ保存され、Iceberg 互換のどのエンジンからもアクセスできます。
• AWS Glue Data Catalog — すべてのコンピューティングエンジンで一貫したデータ探索を実現する、統合メタデータリポジトリです。
• AWS Lake Formation — 列レベル・行レベルのセキュリティによるきめ細かなアクセス制御を提供し、ガバナンスをプラットフォームの成長に合わせてスケールさせます。

コンピューティング: 適切なワークロードに適切なエンジンを

• Amazon Elastic Compute Cloud (Amazon EC2) 上の Apache Spark — 負荷の高い ETL や変換ワークロード向けの、柔軟な分散コンピューティングです。コスト最適化のために AWS Graviton インスタンスと Amazon EC2 スポットインスタンスを利用します。
• Amazon Athena — アドホックな探索や軽量なクエリを、Iceberg テーブルに対して直接実行できるサーバーレス SQL です。管理すべきインフラはありません。
• Amazon Redshift Serverless — BI ダッシュボード、Tableau のワークロード、インタラクティブ分析向けの高性能なサービングレイヤーです。Amazon Redshift Serverless は需要に応じて自動的にスケールし、アイドル時には一時停止するため、最も得意とする分析ワークロードでコスト効率を保ちます。

オーケストレーションとオブザーバビリティ

• Apache Airflow — 依存関係の追跡とサービスレベルアグリーメント (SLA) の監視により、9,300 を超えるデータパイプラインを管理するパイプラインオーケストレーションです。
• 包括的なオブザーバビリティスタック — すべてのレイヤーにわたるコスト配賦、パイプラインの正常性監視、データ品質チェックを実現します。

注: このアーキテクチャを当初設計した時点では、Amazon Redshift が Iceberg への書き込みに対応していなかったため、セルフマネージドの Spark が唯一実現可能な取り込み経路でした。この制約はすでに解消されています。Amazon Redshift は現在、Apache Iceberg の DML (UPDATE、DELETE、MERGE) を完全にサポートしており、従来の CREATE/INSERT 機能や AWS Glue の Iceberg マテリアライズドビューを補完します。これにより、読み書きの両方に対応した完全な Iceberg エンジンとなりました。

移行アプローチ

Razor Group は、リスクの高い一括切り替えではなく、5 つのステージからなる段階的な移行を採用しました。各ステージはそれ単体で価値を生みながら、次のステージの土台を築きます。移行期間中は Amazon Redshift と Spark の両パイプラインを並行稼働させ、事業継続性を保ちつつ、チームが出力を確実に比較できるようにしました。本番パイプラインが停止したり、ダッシュボードが利用できなくなったりする瞬間は一度もありませんでした。

移行の道のり: 5 つのフェーズ

移行は体系化された 5 つのフェーズで進み、各フェーズが前段を土台としつつ、次に進む前に段階的な価値を提供しました。

フェーズ 1: レイクハウスの基盤を確立する

クエリを 1 つ移行する前に、Razor Group は 3 つの問いに答える必要がありました。データはどこに置くのか、どう管理するのか、そしてどうクエリするのか、という問いです。

セルフマネージドの Iceberg ではなく S3 Tables を選んだ理由

Razor Group はすでに、テーブルフォーマットとして Apache Iceberg の採用を決めていました。オープンでエンジンに依存せず、ACID トランザクションとタイムトラベルを備えているためです。残る問いは、標準の S3 バケット上で Iceberg をセルフマネージドで運用するか、Amazon S3 Tables を使うかでした。

セルフマネージドの Iceberg は強力ですが、運用コストがかさみます。スモールファイルの増殖を防ぐためにコンパクションジョブを回す担当者が必要です。メタデータの肥大化がクエリプランニングを劣化させる前に、古いスナップショットを期限切れにする担当者も必要です。書き込みが中断した後に残る孤立したデータファイルを片付ける担当者も要ります。40 以上のスキーマにまたがる 700 以上のモデルが稼働し、その多くが 1 日に複数回マテリアライズされる環境では、こうした保守負荷はプラットフォームの成長とともに縮小するどころか拡大してしまいます。

S3 Tables は、こうした一連の作業をまるごと不要にしました。コンパクション、スナップショット管理、参照されないファイルの削除が、継続的かつ自動的に実行されます。統合された Iceberg REST Catalog API により、Spark、Trino、Athena、Amazon Redshift、Flink など互換性のあるエンジンは、個別のメタストアを維持することなくテーブルを検出してクエリできます。探索は AWS Glue Data Catalog を通じて統一されており、同カタログは現在、Iceberg REST Catalog プロトコルをアクセスインターフェイスとして公開しています。テーブルがファーストクラスの AWS リソースであるため、アクセス制御、暗号化、ライフサイクルポリシーは、ファイルパスの命名規則の上に複雑な S3 バケットポリシーを重ねるのではなく、テーブルレベルで機能します。

オープンテーブルフォーマットの保守をセルフマネージドで抱え込みたくない企業にとって、これが決め手となりました。

AWS Glue Data Catalog は、すべての階層にわたる統合メタデータ探索を提供します。Lake Formation は列レベル・テーブルレベルのアクセス制御を担い、最小権限の原則に従う AWS Identity and Access Management (IAM) ロールと、完全な監査証跡のために有効化した AWS CloudTrail を組み合わせています。

クエリプロトコルの選択

アーキテクチャの再設計前、Amazon Redshift クラスターの処理は 98% が ETL で、アナリストの SELECT クエリはコンピューティング時間のごく一部にすぎませんでした。置き換えるエンジンには、負荷の高いバッチ変換と、インタラクティブなアドホッククエリの両方に対応できることが求められました。

従来の Spark (spark-submit) はバッチ ETL をうまく処理しますが、クライアントとクラスターが密結合になります。ジョブごとにドライバー JAR のパッケージング、クラスパスの管理、クラスター内部からの投入が必要です。日々膨大なデータ量を処理する 200 以上の本番用有向非巡回グラフ (DAG) を運用するプラットフォームにとって、こうした運用上の摩擦は受け入れがたいものでした。

Spark Connect は、Spark 3.4 で導入された gRPC ベースのクライアント/サーバープロトコルであり、この密結合の問題を完全に解決しました。クラスターは永続的な gRPC エンドポイントを稼働させます。クライアントはリモートで接続し、クエリをネットワーク越しに投入します。Airflow のオペレーターはシンクライアントになります。セッションを開き、SQL を投入して結果を受け取り、成功と失敗がそのままタスクの状態に対応します。ドライバー JAR もポーリングも不要です。パイプラインのオーケストレーター、ウェブアプリケーション、開発者のノートブックなど複数の利用者が、いずれもローカルに Spark をインストールすることなく 1 つのクラスターを共有できます。

Spark Connect のデプロイ

Razor Group は、Amazon EC2 上にセルフホストの Spark クラスターをデプロイしました。オンデマンドの AWS Graviton リーダーノード、約 70% のコスト削減となるスポットワーカー、そして内部の Network Load Balancer を通じて公開した Spark Connect エンドポイントで構成されています。カスタムの Amazon マシンイメージ (AMI) に Spark、Iceberg、S3 Tables の一式を組み込んであるため、プライベートサブネットのノードは実行時にインターネットへアクセスしなくても必要なものをすべて備えています。

このフェーズ自体は直ちにビジネス価値を生むものではありませんでしたが、その後のすべてを可能にしました。

フェーズ 2: データ取り込みを移行する

Razor Group の取り込みレイヤーは、Amazon Selling Partner API、Seller Central ポータル、NetSuite ERP、そして独自のウェブスクレイパーからデータを取得します。旧アーキテクチャでは、これらすべてが COPY コマンドを通じて Amazon Redshift に取り込まれていました。そのためデータ鮮度はバッチジョブのスケジュールに左右され、分析クエリを処理するのと同じクラスター上でリソースを奪い合っていました。

Razor Group は取り込みパイプラインを、Apache Airflow がオーケストレーションする AWS Lambda 関数へ移行し、データを Iceberg 形式で S3 Tables に直接書き込むようにしました。スケジュール駆動からイベント駆動への転換により、鮮度が大幅に向上しました。Lambda 関数は処理すべきデータがあるときにのみ起動し、Airflow のセンサーは新しいデータが到着した瞬間に下流の変換をトリガーします。その結果、1 時間ごとの固定的なバッチウィンドウは、分単位で測れるデータ鮮度に置き換わりました。

オーケストレーションレイヤーは、90 以上のフローにまたがる 200 以上の DAG を管理し、数十のソースからのデータを大規模に処理します。移行にあたっては、書き込み先を Amazon Redshift の COPY から Iceberg 書き込みへ配線し直す必要がありましたが、オーケストレーションのロジック自体は最小限の変更で引き継げました。

このフェーズだけで、取り込みにおける常時稼働クラスターへの依存を断ち切り、コンピューティングコストを約 40% 削減しました。

フェーズ 3: 処理パイプラインを変換する

フェーズ 3 は技術的に最も難易度が高く、Razor Group が最も多くを学んだフェーズでもありました。チームは 1,000 以上の SQL モデルを Amazon Redshift から Apache Spark へ移行し、40 以上のスキーマにまたがる依存関係の連鎖を段階的にたどりながら進めました。モデルはメダリオン構造に沿って移行しました。取り込んだ生データの Bronze、クレンジングして整形したデータの Silver、そしてビジネスで即利用できる集計データの Gold です。

Razor Group は自動変換ツールと検証フレームワークを構築し、Amazon Redshift と Spark の出力を並行して実行して、何かを廃止する前に結果を 1 行ずつ比較しました。いくつかの種類の変換は、自動化で対応できる限界を試すものでした。

• ウィンドウ関数: Amazon Redshift の QUALIFY 句には Spark に相当するものがありません。使用箇所ごとに明示的な行番号付けを伴うサブクエリでラップする必要があり、在庫スキーマだけでも数十のモデルに影響しました。
• JSON のシリアライズ: 最も時間を要したカテゴリです。Amazon Redshift で JSON STRING として格納されていた複雑な列は、Spark では手書きの STRUCT 定義を伴う from_json() が必要でした。広告、注文、取引の各パイプラインにわたるネストされたペイロード列はいずれもスキーマの調査を要し、近道はありませんでした。
• 関数の方言: NVL から COALESCE、DATEADD からインターバル演算、LISTAGG から ARRAY_JOIN(COLLECT_LIST()) など、20 を超える関数レベルの変換がありました。
• スナップショットの排除: 最大の隠れたコストでした。ある時点の状態を保存するためだけに 1 日に複数回実行されるテーブル全体のコピーは、週あたり 35 時間を超える Amazon Redshift のコンピューティングを消費していました。Iceberg のネイティブなタイムトラベルにより、これらは一夜にしてコストゼロの操作になりました。

1,000 以上の SQL モデルを移行する際、機械的な構文変換は自動化ツールでうまく処理できます。しかしモデルの約 30% は人間の判断を必要としました。複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルです。これらのモデルが移行工数の 70% を占めました。

Razor Group は、この作業を加速するために Claude を活用した構造化された移行ワークフローを構築しました。ソース SQL を読み取り、依存関係を特定し、構文を変換し、不足しているベーステーブルを解決し、JSON パースを追加し、出力を検証してレイクハウスに書き込む、という流れです。このシステムは単に SQL を変換するだけではありませんでした。スキーマのコンテキストを適用し、モデル間の依存関係をたどり、エンジニアが手作業で見つけるには何時間もかかるようなエッジケースを検出しました。数年がかりになりかねなかった取り組みが、数週間で測れる体系的かつ再現可能なプロセスになったのです。このアプローチは移行のスピードを根本から変えました。

フェーズ 4: サービングレイヤーを統一する

データが Iceberg テーブルを流れるようになったことで、Razor Group はサービングレイヤーを 1 つに集約しました。エンドユーザーは Amazon Redshift Serverless を通じて Gold レイヤーの Iceberg テーブルにクエリを実行し、社内の探索や機械学習 (ML) のワークロードは Spark Connect を通じて同じテーブルを読み取ります。利用者ごとに別々のデータコピー、マテリアライズドビュー、抽出ジョブを維持する必要はなくなりました。

これがオープンテーブルフォーマットの戦略的な成果です。S3 上の Iceberg テーブルはエンジンに依存しません。今日はバッチ変換に Spark、明日はインタラクティブクエリに Trino、来四半期はストリーミングに Flink といった具合です。Iceberg を扱えるエンジンであれば、変換や移行なしにデータを読み取れます。Razor Group は単一ベンダーの SQL 方言に縛られていた状態から、ストレージレイヤーに手を加えることなく新しいエンジンを採用できる自由を手に入れました。

フェーズ 5: 運用体制とオブザーバビリティを整える

最後のフェーズで、レイクハウスを本番グレードに仕上げました。Razor Group は、すべてのパイプラインコンポーネントからメトリクス、トレース、ログを集約し、統一されたビューにまとめる包括的なオブザーバビリティスタックを構築しました。このビューは、一元的なログ検索、異常検知、そしてデータプラットフォーム全体にわたる障害を関連付ける自動アラートを支えます。

このオブザーバビリティレイヤーは、単に可視性を提供する以上のものでした。チームに自信をもたらしたのです。1 日に何千ものパイプライン実行を回しているとき、何かが壊れたら数分以内に、それが何によって引き起こされ、どの下流の利用者が影響を受けるのかを把握する必要があります。それが、後手に回る火消しと、先手を打つ運用との違いです。

パイプラインのオーケストレーションは 3 つのパターンに集約されました。日次パイプライン (取り込みからマテリアライズ、エクスポート、AI エージェントによる分析まで)、15 分ごとにポーリングする運用ワーカー、そして週次のスクレイパージョブです。

切り替えは設計上ゼロダウンタイムでした。2 週間にわたって両方のスケジューラーを並行稼働させ、旧アーキテクチャのシステムを無効化する前に、すべてのパイプラインが同一の出力を生成することを自動比較チェックで検証しました。

成果とビジネスインパクト

レイクハウスアーキテクチャは、あらゆる面で測定可能な改善をもたらしました。

63% の削減は、レイクハウス稼働後のコスト (2026 年 1〜3 月) と、再設計前のコスト (直前の 3 か月間にあたる 2025 年 10〜12 月) を比較したものです。この数値は、両アーキテクチャのコンピューティングとストレージを含む、同一条件で比較したインフラの総合値です。移行前の列は Amazon Redshift クラスターのコンピューティングとマネージドストレージを対象としています。移行後の列は Amazon EC2 (オンデマンドとスポットの両方の Spark ワーカー)、AWS Lambda、AWS Glue、Amazon Athena、Amazon Redshift Serverless、S3 Tables のストレージを対象としています。データ転送や付随サービスは、2 つの期間で大きな差がなかったため除外しています。ワークロードの構成 (パイプライン数、モデル数、エンドユーザーのクエリ量) は、2 つの期間でおおむね同等に保ちました。

学んだこと

ツールではなく意思決定のループから始め、ウェアハウスを置き換える前に自社のワークロードを把握する。

移行全体で最も価値のあった活動は、コードを 1 行書くことではありませんでした。アーキテクチャ上の意思決定を下す前に実施した、Amazon Redshift のワークロード分析です。コンピューティングの 98% が ETL で、アナリストのクエリに回っているのはごくわずかだと判明したことが、オンデマンドの Spark への移行を裏付けました。同時に、ほとんど存在しないインタラクティブワークロードのために置き換え先のインフラを過剰にプロビジョニングすることも防げました。アーキテクチャの意思決定は常に、価格精度、プロモーションへの即応性、日中の損益の可視性といった、事業の根幹にある要件にさかのぼるべきです。テクノロジーではなく、そこから始めましょう。

複数のコンピューティングエンジンを前提に設計し、ワークロードごとに適切なエンジンを選ぶ。

単一エンジンのアーキテクチャを運用して得られた最も明確な教訓は、それによって何を手放すことになるかということです。BI、取り込み、バックフィル、ML のすべてを 1 つのコンピューティングレイヤーに縛りつけるのは避けましょう。それぞれコストとパフォーマンスの特性が根本的に異なるからです。いったん移行してしまえば、Iceberg、Spark、S3 Tables は最初から問題なく連携します。難しいのはテクノロジーではありません。難しいのは、40 以上のスキーマにまたがる 1,000 以上のモデルを対応付け、200 以上の DAG を通じて依存関係をたどり、ある列が実は 2 つのエンジン間で密かに異なる形でシリアライズされた JSON 文字列だったと突き止めることです。移行は、エンジニアリングであると同時に発掘プロジェクトでもあります。

変換は自動化しつつ、残る 30% を見込んでおく。

自動化ツールは機械的な構文変換をうまく処理するので、まず手を伸ばすべきツールです。しかし複雑な JSON ペイロード、深くネストされたウィンドウ関数、スキーマをまたぐスナップショット依存を含むモデルは人間の判断を要し、その作業は圧縮できません。当社のモデルの約 30% が大幅な手作業を必要とし、それらが移行工数全体の 70% を占めました。最初から正直に見込んでおきましょう。

オブザーバビリティにはコスト配賦を含めなければならない。そして思わぬコストの落とし穴に注意する。

スナップショット操作は最大の想定外でした。ある時点の状態を保存するために 1 日に複数回実行されるテーブル全体のコピーが、週 35 時間を超えるコンピューティングを消費していたのですが、「スナップショットとはそういうもの」だと誰も疑いませんでした。Iceberg のタイムトラベル機能がそのコストを解消し、この 1 つの機能だけで移行のかなりの部分が正当化できました。より広く言えば、見えないものは最適化できないので、クエリレベルの使用状況を追跡し、チームや機能に配賦しましょう。コストのオブザーバビリティはあれば嬉しいものではなく、基盤そのものです。

ガバナンスは任意ではない。基盤に組み込み、初日からステークホルダーの足並みをそろえる。

カタログとアクセス制御は、採用を拡大した後ではなく、その前に整える必要があります。同じ原則が人にも当てはまります。移行はインフラプロジェクトではなく、部門横断のプログラムです。当社の 2 週間の並行稼働は、行レベルの検証ではまったく捉えられなかったエッジケースを検出しました。Amazon Redshift と Spark の間のタイムゾーンの違い、同時書き込み時のパーティションプルーニングの挙動、非決定的なウィンドウ関数における微妙な並び順の違いです。並行稼働は単なるセーフティネットではありませんでした。移行の真価が実証された場そのものでした。適切なステークホルダーが最初から関与し、足並みをそろえていなければ、何ひとつ成り立ちません。

まとめ

Razor Group の道のりは、データアーキテクチャの最適化を目指す組織に貴重な教訓を提供します。

1. まずワークロードの構成を分析する。 コンピューティングの 98% がインタラクティブクエリではなく ETL だと理解できたことが、負荷の高い処理を柔軟な Spark にオフロードしつつ、最も得意とするインタラクティブ分析には Amazon Redshift Serverless を残すという判断を導きました。
2. マルチエンジンの柔軟性を前提に設計する。 Apache Iceberg のようなオープンテーブルフォーマットは、単一エンジンを選ぶ必要をなくします。各ワークロードは、アクセスパターン、コスト特性、パフォーマンス要件に最も適したエンジンで動きます。
3. 移行を自動化しつつ、複雑さを見込む。 自動トランスパイルは SQL モデルの 70% を処理しましたが、残る 30% がエンジニアリング工数の 70% を占めました。それを踏まえて計画しましょう。
4. オブザーバビリティにはコスト配賦を含める。 ワークロード単位のコストが見えなければ、最適化は当て推量になります。Razor Group は、Iceberg のスナップショット保守だけで週 35 時間を超えるコンピューティングを消費していたことを突き止めました。オブザーバビリティが表面化させ、自動化が解決した隠れたコストです。
5. ガバナンスを基盤に組み込む。 AWS Lake Formation と AWS Glue Data Catalog は、移行後に後付けするのではなく、初日からきめ細かなアクセス制御を提供しました。
6. 並行システムで検証する。 新旧アーキテクチャの 2 週間の並行稼働は、自動テストが見逃したエッジケースを検出し、自信をもった本番切り替えを支えました。

今後の展望

レイクハウスの基盤が整ったことで、Razor Group は AWS 上の統一されたオープンでガバナンスの効いたデータプラットフォームを原動力に、リアルタイムの価格モデルから AI 主導の在庫最適化まで、イノベーションを加速できる体制になりました。

同社の変革は、モダンなデータアーキテクチャがサービスの二者択一ではないことを示しています。それは各ワークロードを最もパフォーマンスの高い場所に配置し、オープンフォーマットでサイロを解消し、ビジネスの成長に応じて各レイヤーを独立してスケールさせることなのです。

他の組織が AWS 上で同様のレイクハウスアーキテクチャをどう実装しているかについては、How BigBasket uses the Iceberg-based lakehouse architecture on AWS to power lightning-fast grocery delivery across India を参照してください。

著者について

この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。