1. はじめに
SupershipでScaleOut DSPのデータ基盤関連の開発をしている @yu-imamura です。
2021年〜2023年にかけてSupershipのScaleOutのデータ基盤はオンプレミスからGoogle Cloud (GCP)へ移行しました。
移行が意思決定された背景は以下で語られました。今回はこの移行プロジェクトをリードした立場として、その実際の過程や移行の成果についてまとめます。
会社の大規模データ基盤をクラウドへ移行することを意思決定した話
2. 移行の背景
クラウド移行前のオンプレミス環境はHadoopをベースに構成されおり、以下に述べる課題がありました。
A. ITライフサイクル
移行当時、Hadoop基盤を構成するメインのサーバ約300台は2022年から2023年にかけて保守期限を迎えることが決まっていました。
このサーバを全て入れ替えるための工数を確保することは困難であることが予想されました。
B. 非機能要求
ここで非機能要求が指しているのは主にデータガバナンスです。
長くオンプレミスで運用されてきたHadoop基盤はデータの流通状況の把握がかなり難しくなっていました。
データを活用・運用するシーンにおいて発生する以下のような問いに対して即答することが困難であり、都度人手をかけて調査する必要がありました。
- 「問題が認識されたこのデータのパイプライン上流にあるデータは何か？」
- 「このデータを利用するために遵守すべき利用規約はどれか？」
C. 固定資産管理上の認知負荷
ハードウェアの固定資産を調達〜検収〜棚卸する作業はインフラエンジニアおよび管理部門にとっても負担です。
後述するようなビジネスの変化を前提とした場合、固定資産への大規模な投資について 適切な意思決定を繰り返しながら データ基盤クラスタを維持する難易度が高いと認識されるようになってきました。
D. ビジネス環境の大変動
データ基盤の視点でScaleOutを捉えると、ここ数年のうちに収容しているデータの分布は変化しています。
また今後もビジネス戦略は変化していく見通しです。
例えば以下のような変化により収容するデータの量・質もまた変化していきます。
- 動画広告に関わる配信ログデータの増加
- 3rd Party Cookie規制にともなう代替手法に関わる新しいデータの収容
E. 事業を継続するための人材獲得
オンプレミスではHadoopをベースに多くの内製スクリプトを組み合わせた運用が行われていました。
そのスクリプト群の集積により徐々に新規参入者の敷居が高くなっていました。
F. 棚卸し
個別の要件に対応しながらデータ基盤の開発を繰り返してきたことで、現在価値を生んでいるのかが分からないダークデータが存在していました。データが存在する以上、HDFSの一定量占有しているにも関わらず価値提供に貢献しておらず、コストパフォーマンスの悪い状態でした。
3. 移行の手順
オンプレミス機器の保守期限は決まっています。これまでに移行を完了させる必要がありました。
期間的制約がある中で現行ワークロードを大きく変更し検証をしなおす時間を確保することは難しいと予想されました。
したがって移行をフェーズを2つに分ける 「Lift and Shift」という戦略で移行に取り組みました。
- できるだけ早く現行ワークロードをオンプレミス環境から撤収することを優先するLiftフェーズ
- クラウド移行後にワークロードをクラウド適応させることで更に性能・コスト・運用負担を最適化するShiftフェーズ
特にオンプレミスからの脱却を図るLiftフェーズでは以下のような切り替えを計画して実行しました。
4. オンプレミスHadoop基盤(移行前)の概要
オンプレミスのデータ基盤はHadoop/YARNクラスタを構築し、各プロダクトからHiveやHDFSのインタフェースを通じてデータを読み書きしていました。
約300台のワーカーノードを持ち11PBのキャパシティを持つHDFSが構築されていました。
主に利用していたアプリケーションは以下です。
- Hive
- Hue
- Presto
- Spark
- Pig
- Sqoop
- Tez
- HBase
全体像は以下の通り。社内の資料を加工している都合で後述する図と一貫性のないデザインである点などはご容赦ください。
5. Google Cloud(移行後)の概要
データ基盤のみクラウドへ移行したのが現状であるため、 Cloud InterConnectと共有VPCを利用してオンプレミスとGCPのネットワークを接続 しています。データ分析の入力となるデータはほぼオンプレミス環境のサーバからCloud Storageに転送されてきます。
このオンプレミスとクラウドの専用線接続は大規模なオンプレミスの広告配信基盤と接続するために必要であり、ScaleOutのデータ基盤の特殊な側面だと考えます。
Liftフェーズが完了した現時点ではオンプレミスで運用されていたHadoopベースのワークロードを維持する必要があったためDataprocクラスタを多用しています。
特にオンプレミスのHadoopクラスタを擬似的に再現するように、長命のDataprocクラスタを構成している箇所があり、このクラスタのキャパシティ調整は現在でも運用上の負担となっています。
6. 移行の課題と解決策
実際の移行では多くの課題がありましたが、代表的なものとして以下のような課題がありました。
必要なデータの確実な移行(コピー)
オンプレミスのHDFSに長期間保存されているデータはクラウドへコピーするだけでもかなりの時間がかかります。
保持期間が長くサイズの大きい広告配信実績データを優先的にHDFSからCloud Storageへとコピーするようにしました。
Hadoop/Hiveのバージョンアップによる挙動の変化
認識していなかったデフォルト設定の変更や設定の引き継ぎ漏れなどから作成されたファイルが極端に細分化されて small files problem を招いたことがありました。
バージョン間の互換性を充分に調査できていなかったため、起こるべくして起きた問題でした。
クラスタのキャパシティ調整
前述の通りいくつかのDataprocクラスタは作りっぱなしでHiveクエリを受け付ける構成になっています。
このクラスタに対して日次実行で大量にスケジューリングされるジョブを円滑に完了させるための自動スケーリングの調整は試行錯誤しました。これは現在でも適宜調整が続いています。
コスト抑制
オンプレでの設計をほぼそのまま踏襲してクラウドに移植したLiftフェーズでは、実装にDataprocクラスタに移植してみると予想以上にCompute Engineのコストが大きいものも見つかっています。
移行中にもこの問題は把握されており、期限の迫る中でこまごまと対処はしていたものの根本的な抑制には至りませんでした。
Liftフェーズが完了した現在もコスト抑制のための施策を継続しています。
7. 移行後の効果と成果
オンプレのHadoopクラスタを撤収した現在は、Lift and ShiftにおけるLiftフェーズが完了した状態です。
つまりまだ Shiftというクラウド適応のフェーズが残っており まだこれからもう一段階移行が必要です。
それでも前述した課題のいくつかは解決されたと考えています。
A. ITライフサイクル
当初計画よりも2ヶ月ほど遅延しましたが、全てのサーバが保守期限切れとなる前になんとかオンプレミス環境から撤収することができました。
撤収対象のラックのサーバが全てシャットダウンされる瞬間は感慨深いものがありました。
B. 非機能要求
データガバナンスについては現在のDataproc中心のデータ利用ではまだ充分に整備できていません。
さらにBigQueryをメインに据えるなど、Shiftフェーズで手を打っていく必要があります。
C. 固定資産管理上の認知負荷
使っていないものを止める・削除することでコストを削減するというアプローチが取れるようになりました。
クラウド利用の利点は良くも悪くもこの費用の流動性であると強く感じました。
ワークロードの効率改善の結果が比較的すぐにコストに反映されるため、成果がわかりやすい (関係者に伝えやすい) というのもメリットでした。
とはいえコストに関するデータを活用して更にビジネスサイドや経営層を円滑にコミュニケーションを取る余地は残されています。
D. ビジネス環境の大変動
ビジネスの変化はこれからも続きます。
ここについては事業上のマイルストンをいくつか達成していった結果としてまた振り返りたいと思います。
E. 事業を継続するための人材獲得
GCPが提供するサービスをできるだけ使うように手を入れていった結果、オンプレミスの監視や運用で使われていた内製スクリプトはほとんど駆逐することができました。
内製スクリプトを駆逐したことで技術的情報の一部がGCPの公式ドキュメントで説明されるようになりました。
F. 棚卸し
データの消費者にとって必要なデータだけをホワイトリスト形式でクラウド移行したことにより、結果的にダークデータはオンプレミスのHDFSに残したまま撤収された形となりました。
移行の結果、整理が進み保存しているストレージのサイズは1/3まで減らすことができました。
移行直後のコスト削減の過程で意識的にデータ量を削ったこともありますが、オンプレミスにあったデータの２/3が削除可能なデータがあったことになります。
8. 今後の課題
上記を踏まえて直近で取り組んでいく課題について整理します。
データガバナンス
Dataprocを軸にしたデータスタックでガバナンスを効かせようと思うと、複数のOSSを組み合わせる必要があります。(Apache Rangerなど)
それらをもってしてもPub/SubやBigTableなどのマネージドサービスを包含したデータの横断的な統制・管理は難しいと考えられます。
幸いにしてGCPでは Dataplex というデータ統制のマネージドサービスが提供されています。これを活用してできるだけGCPを利用する恩恵を受けられるように、クラウド適応していくことになります。
コスト最適化
依然としてDataprocのCompute Engineのコストは本クラウド基盤全体のコストにおいて高い割合を占めています。
事業としてもクラウドに移行したメリットを経済的側面から享受するためにもこのコストの削減は引き続き必要です。
運用負担の軽減
オンプレミスのHadoopクラスタをほぼそのままクラウドに再現するような構成がいくつか残っています。
形だけクラウドに移動しておきながら実質全くクラウドに適応できていない状態です。
こうしたワークロードはどうしてもクラウドが提供する恩恵を受けにくく、運用の手間が度々発生しがちです。
これらのワークロードの運用負担も引き続きクラウド適応を進めていくことで軽減していく予定です。
9. まとめ
2021年 〜 2023年にかけて実施したScaleOutのデータ基盤のクラウド移行は現在も進行中です。
Liftのフェーズは完了しいくつかの恩恵を得ることはできましたが、ガバナンスやコスト最適化などの大きな課題もまだ残っています。
これらを解決するためにもこれからShiftフェーズの移行に取り組んでいきます。
最後に宣伝です。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership 採用サイト
是非ともよろしくお願いします。