Squarespace、Google Cloud の分析レイクハウスでエスカレーション件数を 87% 削減

※この投稿は米国時間 2023 年 4 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回お話を伺ったのは、オールインワンのウェブサイト構築および e コマース プラットフォームを提供する Squarespace です。同社は自己ホスト型の Hadoop エコシステムから、BigQuery、Dataproc、Google Kubernetes Engine（GKE）を実行する Google Cloud に移行しました。その移行の計画と実施、そして同社が獲得した成果について詳しくお話しいただきました。

あるメイクアップ アーティストが、自宅で美容ビジネスを営んでいるとしましょう。小規模ビジネスのオーナーであるため、ウェブサイト構築を担当するソフトウェア開発チームはありません。しかし、ビジネスの概要を紹介し、利用者による直接予約を受け付ける必要があります。また、支払いプロセスの処理や、新規クライアントと既存クライアントに対するサービスの継続的なマーケティングも行わなければなりません。

そうしたビジネスの力になるのが Squarespace です。Squarespace は、ウェブサイト、ドメイン、オンライン ショップ、マーケティング ツール、スケジューリングのすべてに対応するオールインワン プラットフォームであり、ユーザーによるビジネスのオンライン プレゼンスの実現を支援するものです。前述のケースで Squarespace を導入すれば、メイクアップ アーティストはビジネスの拡大と運営に全力を傾けて、デジタル ウェブサイト プレゼンスとスケジュール管理作業を Squarespace に任せることができます。Squarespace は、お客様とそのエンドユーザーに代わってデータを管理し、処理します。Squarespace がデータを保存することで、お客様のユーザー機能にイノベーションがもたらされ、このプラットフォームへのお客様主導の優先投資が促進されます。

2022 年の第 4 四半期まで、Squarespace は 2 つの個別管理の Hadoop クラスタから構成される自己ホスト型の Hadoop エコシステムを利用していました。地理冗長を目的としてアクティブ / パッシブモデルを利用していたため、両方のクラスタを「複製」していました。また、ステージング インスタンスも存在していました。このシステムを使い続けるなかで、ソフトウェアおよびハードウェア インフラストラクチャが徐々に老朽化し始めました。間もなくディスク空き容量が不足するようになり、保存するデータに制限を設けなければならくなりました。「データパージ」、つまりファイルの一括削除によってディスク容量を空ける作業は、ほぼ四半期ごとに行われるようになりました。

2021 年の前半には、プラットフォーム利用の増加のペースを維持できないことはわかっていました。特に、数百個のテーブルを格納していたオンプレミスの Presto デプロイメントと Hive デプロイメントに無理が出てきました。このインフラストラクチャの保守を担当していたデータ プラットフォーム チームも小規模で、インフラストラクチャのスケーリングと保守をこなしながらユーザーにプラットフォームの機能を提供することは不可能でした。この時点で、一か八かインフラストラクチャを使い続けるか、クラウド マネージド ソリューションに移行するか、決断を迫られました。上層部からの支持もあり、Google Cloud を導入することになりました。それは、このプラットフォームに対する信頼があり、移行とデプロイを短期間で行えることがわかっていたためです。

プロジェクトの計画

依存関係のマッピング

事前に必要な時間をかけて、計画したクラウド インフラストラクチャのマッピングを行いました。維持するもの、更新するもの、置き換えるものを判断しました。コンポーネントごとに最適な方法を選択できたため、この戦略は有益でした。たとえば、オンプレミスの Hadoop Distributed File System（HDFS）を、Hadoop GCS コネクタを使用して Cloud Storage に置き換えることにしましたが、既存のレポートジョブに変更はなく、書き換えも行いませんでした。

詳細な依存関係トラッキング

ステークホルダーを特定し、早い段階からプロジェクトの意図を伝え始めました。各チームと協力関係を結んだ後、進捗状況確認のためのミーティングを毎週行い、問題点について話し合いました。また、作業の管理にビジュアルなプロジェクト計画を利用したおかげで、チーム間の依存関係を把握しながら移行を完了できました。

徹底的な非優先順位付け

目標とする日付から逆算し、移行処理を進めながら次の 2 か月分の作業を絞り込んでいきました。上層部からトップダウンの支持を得られたため、チームは重要度の低いリクエストに対して「今はできません」と対応し、作業の中断を一貫して回避できました。また、これにより、移行後にそれらのリクエストに対応する時期に関して、現実的なスケジュールを立てることができました。

作業分担

チームごとに作業を割り当てたため、作業に費やす時間を最適化できました。

• データ プラットフォーム チームは、テーブルの名前を変更してドロップするツールや、プログラムでデータベース テーブル全体の差分を取って完全一致の出力を確認するツールを開発しました。これらのツールは再利用可能なものです。また、オンプレミスの Presto をミラーリングした Trino インスタンスを Google Cloud に作成しました。

• データ エンジニアリング チームはこれらのツールを利用しながら、各データ パイプラインを移行しました。

テクノロジー戦略

アプローチ

すべてのシステムとパイプラインを対象としたコンピューティングとストレージの移行を実現するため、イテレーション アプローチを採用しました。毎回わずかな変更を一部にだけ加えることで、移行フェーズごとに出力を検証できます。こうしてイテレーション アプローチのメリットを獲得し、手動による検証にかかる時間を何時間分も削減しながら、以下に示すようなアーキテクチャ全体を実現できました。

フェーズ 1: プラットフォームとポリシーのカットオーバー

最初のステップは、クエリエンジンである Presto をカットオーバーして Google Kubernetes Engine（GKE）で実行するようにすることでした。このサービスをデプロイすることで、エンドユーザーにはこのソフトウェア（現在の名称は Trino）の最新バージョンでクエリのテストを開始する場が与えられました。また、プラットフォームのポリシーもカットオーバーしました。つまり、Cloud Storage バケットの使用またはデータアクセスのための IAM 権限の割り当てに関するガイドラインを定めたのです。

フェーズ 2: クラウドへのコンピューティングの移行

Trino インスタンスを Google Cloud に移行した後、このインスタンスにオンプレミスのデータストアへのアクセス権を付与しました。Trino Airflow オペレーターを更新し、オンプレミスではなく Google Cloud でジョブを実行するようにしました。Spark のプロセスは Dataproc に移行されました。ステークホルダーのチームは、オンプレミスでのコンピューティングからクラウドベースのコンピューティングへと 1 つずつ切り替える一方で、データの読み書きはオンプレミスで継続しました。また、Google Cloud ベースのストレージに直接移行するという選択肢もありました。現在のコミットメント スケジュールではどの順番に処理することが最適であるかの判断はチームに委ねましたが、オンプレミスのストレージを終了する期限は明確に定めました。

フェーズ 3: ストレージのカットオーバー

すべてのジョブが問題なく Google Cloud で実行されていることを確認し、出力を検証した後で、Google Cloud のデータソース（Cloud Storage / BigQuery）からデータを読み取るようにダウンストリーム プロセスのリダイレクトを開始しました。古いクラスタに対する HDFS の読み取りと書き込みが次第にゼロになっていく様子を確認できました。この時点で、オンプレミスのハードウェアの運用を終了できることがわかりました。

フェーズ 4: カットオーバーのオーケストレーション

オーケストレーション プラットフォームの Airflow はオンプレミスで実行されています。2023 年にこれを Cloud Composer に移行するための調査を行っています。このコンポーネントが担う機能は小さなものですが、関与するチームやジョブの数が多いため、最大規模の移行となります。

上層部からの支持

社内のプロジェクト支援者は、ハードウェアを廃止する必要があったインフラストラクチャ チームでした。データチームが Google Cloud への移行に専念できるよう、インフラストラクチャ チームの上層部は、データグループが担う業務を軽減するためのあらゆる機会を特定しました。

データグループの上層部は、社内の別組織からエンジニアへの依頼すべてを遮断し、移行に関係のないリクエストについてはすべて「ノー」と言えるよう十分なサポート体制をとりました。

Squarespace の今後の展望

Hadoop エコシステムを Google Cloud に無事に移行できたことで、インフラストラクチャの保守にまつわる大きな負担が消失しました。移行前の数か月と移行直後の数か月を比較すると、エスカレーション件数が 87% 減少しています。データ プラットフォーム チームとデータ インフラストラクチャ チームはさまざまなサービスやファイルシステムの状態のモニタリングに集中する必要がなくなり、現在では社内ユーザーがビジネスを推進するために必要とする新機能やより優れたソフトウェアの提供に注力しています。

当社の分析レイクハウス計画における次のステップは、データレイクの移行で手にした成功を継続させ、その他のインフラストラクチャ業務も Google Cloud に移行することです。オンプレミスのデータ ウェアハウスを BigQuery に移行する計画を積極的に進めており、Airflow インスタンスの Cloud Composer への移行についても検討を開始しました。

データのモダナイゼーションに向けた取り組みを開始する方法の詳細については、Google Cloud までお問い合わせください。