Google Cloud Next Tokyo '24 Day 1

はじめに

ZIPAIRでは、システムのインフラ構築にあたりGoogle Cloudを利用しています。今回、Google Cloudおよびその活用について最新動向を学ぶため、ZIPAIRの技術チームメンバーでGoogle Cloud Next Tokyo ‘24に参加しました。
本記事では、Day 1に参加したセッションのレポートをお届けします。

参加したセッション

Day 1では、以下のセッションに参加しました。

移行から運用までデータベースを Google Cloud で徹底的に楽をする

このセッションでは、データベースの移行から運用でGoogle Cloudをどう使うのかについて紹介していました。

オンプレミスの運用には課題が多く存在していますが、Google Cloudを利用することでオンプレミスの抱える課題を簡単に解決できるとのことでした。
移行を楽にするテクニックとして、Google Cloudが提供するOSSのDatabase Migration Assessmentツールで移行難易度を評価できます。また、IaCツールを利用することで、宣言的に移行先の環境を作成可能であったり、Database Migration Serviceの生成AIによるSQL変換の自動化などを紹介しておりました。

後半では、時間の関係で詳細までは説明していませんでしたが、Google Cloudにはデータベースの移行や運用に便利な機能やツールが数多くあることを紹介していました。

進化するコンテナ環境: Google Kubernetes Engine と Cloud Run の最新アップデートと使い所を徹底解説

このセッションではGoogle Kubernetes Engine (GKE)とCloud Runにどのようなアップデートが行われ、どのような使い方ができるようになったのかを紹介していました。

GKEに関するアップデートはWorkload Identity Federation for GKEについてです。従来のWorkload IdentityではKubernetesサービスアカウントがGoogle Cloudサービスアカウントの権限を借用してGoogle Cloud APIへのアクセスを制限します。
Workload Identity Federation for GKEではKubernetesサービスアカウントに直接IAMロールの付与が可能となりました。それにより、Google Cloudサービスアカウントの準備が不要となったようです。
Container Image PreloadingというGKE Node Poolにセカンダリディスクを追加する機能についても紹介されました。コンテナイメージやデータをNode上にPreloadしておくことでコンテナの立ち上げ速度を向上できるようです。

Cloud Runに関するアップデートはDirect VPC Egressについてです。
Direct VPC EgressによりServerless VPC Access Connectorを利用せずとも直接VPC内にトラフィックを送信することが可能になりました。
また、自動セキュリティアップデートが追加され、Cloud RunにデプロイされたイメージのベースイメージをGoogleが自動更新できるようになったようです。

このようにGoogle Cloudのプロダクトは日々アップデートされておりますます便利かつ使いやすくなっていることを実感できるセッションとなっていました。

Platform Engineering 入門: Golden Path の構築と活用

プラットフォームエンジニアリングは近年、注目を集めている分野です。急速に発展した技術により開発速度は飛躍的に向上しました。一方、多様な専門知識がエンジニアに求められるようにもなりました。テストの自動化やデータベース、ネットワーク、セキュリティなど求められる専門知識は多岐にわたります。

そのような、課題に対する解のひとつとしてプラットフォームエンジニアリングがあります。プラットフォームエンジニアリングではプロダクトとしてのプラットフォームをエンジニアへ提供します。例えばあらかじめセキュリティ等を考慮したインフラを構築できるツールをテンプレートとして提供します。このようなテンプレートはゴールデンパスとも呼ばれます。プラットフォームは複雑なインフラに対してエンジニアがより扱いやすい抽象レイヤーを提供します。

発表ではGKE Enterpriseが取り上げられており、フリートによるマルチクラスタ管理やTeam Scopeを用いたチーム単位でのマルチテナント管理などが紹介されていました。弊社ではGKEを使用していませんが、開発規模が大きくなった際、参考にできる発表内容だったと感じました。

BigQuery Migration Service を活用してデータ基盤を BigQuery に段階的移行した事例の紹介

BigQuery Migration Serviceを活用してAWS上のデータ基盤をどのように移行したのかを事例を交えて紹介していました。BigQuery Migration Serviceを利用することで、データ移行の効率性が高められていました。
事例では、移行評価・SQL変換・データ移行・データ検証を反復しておこなったようです。

移行には次のツールを活用したと述べていました。
移行評価ではLooker Studio、SQL変換ではSQLトランスレータ、移行ツールにはdwh-migration-dumperが利用されました。また、データ転送にはData Transfer Service、データの妥当性の検証にはData Validation Toolが利用されました。
ワークフローを用いて段階的に移行することでサイクルを回す毎に効率を高めることができ、大量データを移行することが実現できたということです。

Google Cloud VMware Engine を起点とした JALインフォテックのインフラ改革プラン

このセッションでは、JALインフォテックにおけるGoogle Cloud VMware Engine (GCVE)を活用したインフラ改革についての発表がなされました。Lift & Transformationという概念に基づき、単なるクラウド移行ではなく新しい価値を付与することを目指すと述べられており、クラウド移行に際して非常に参考になる事例であると感じました。

今回移行する対象はオンプレミスのVMware vSphereであり、完全にクラウドネイティブなアーキテクチャに移行する前のステップとして、GCVEへのRehostを進めていることが語られました。GCVEではオンプレミスのVMwareで使われていたイメージをそのまま利用できるため、初期の移行コストを抑えつつGoogle Cloudとの連携を迅速に開始できることがメリットとして挙げられました。
移行の具体的な取り組みとしては、初めにGoogle Cloudや支援パートナーとのワークショップを実施したそうです。ワークショップではGoogle Cloudからの技術レクチャーが行われたほか、現状の課題やAs-Isを整理することで、そのあとの移行作業をスムーズに進めることができたと述べられていました。

また、移行作業と並行して、社内向けチャットボットの導入も実施されました。Vertex AI Searchを活用することで、効率的な社内情報の検索を可能にしたほか、ナレッジを半自動で蓄える仕組みを容易に構築できたそうです。ここでは、Google Cloudを活用すればAIの専門家でなくとも容易にAI導入を推進可能であることが強調されており、AI導入を検討している企業にとっては特に参考になる事例であると感じました。

Google Cloud モニタリング ベスト プラクティス

このセッションでは、Cloud MonitoringにおけるベストプラクティスとUbieにおけるモニタリングの実践について発表がなされました。

まず初めに、Cloud MonitoringならびにGoogle Cloud Managed Service for Prometheus (GMP)についての説明がなされました。GMPはCloud Monitoringが直接サポートするPrometheusであり、本来のPrometheusにおける課題であったストレージやスケーリングの問題が解消されています。また、Cloud MonitoringではPromQLが全ての機能で利用可能になっています。従来のクエリ言語MQLが非推奨になることも踏まえ、今後はPromQLの使用が推奨されていました。

次に、UbieにおけるGMPの利用について発表されました。Ubieではもともと独自にホスティングしたPrometheusや他社のPrometheusを利用していましたが、GMPリリース後はそちらに移行し、その結果かなりのコストを削減できたそうです。具体的には、必要なメトリクスのみ取得するような設定や、メトリクス種別ごとのアラート設定がコスト対策として有効だったようです。
また、GMPの利用についてUbie独自のプラクティスがいくつか紹介されました。アプリケーションのテンプレートに実装を組み込むことでサービス立ち上げ時からメトリクスを出力できるようにすることや、社内ツールでインフラコードを生成しメトリクス取得設定を自動化することが語られました。これらのプラクティスは、GMPに限らずモニタリング実装一般において有効なものとみられるため、我々もモニタリング実装において十分に活用の余地があると感じました。

スケーラビリティと信頼性を追求: Global で 5,500 万ユーザーを抱えるカレンダー シェアアプリのデータベースを Aurora から Cloud Spanner へ移行

このセッションでは、TimeTreeがどのようにしてカレンダーアプリのデータベースをAuroraからCloud Spannerへ移行しているかについて発表がなされました。

そもそも移行が必要になった背景として、データの増加と、ストレージやコネクション数といったデータベースリミットが問題になっていたようです。また、データベース移行先をCloud Spannerに決めた理由として、フルマネージドであることやGoogle Cloud製品とのシームレスな連携が可能であることを挙げていました。加えて、技術要因以外では、Google CloudによるTAPやCloud Spanner PMの協力などGoogleからの手厚いサポートがあったことにも触れていたのが印象的でした。

移行プロセスでは、対象データを決定し、マイルストーンや人員計画といった入念なプランが立てられました。また、Cloud Spannerのスキーマ設計においては、Readアクセスが多いというサービスの特徴を考慮し、インターリーブを活用したことが述べられました。ホットスポット発生を避けるためPrimary Keyをビット反転シーケンスに変更したことや、インターリーブの階層を浅くして初心者にも取り扱いやすくしたことなど、いくつかのプラクティスが語られました。

次に、Cloud Spannerへのデータマイグレーションについてのお話がありました。マイグレーションには、Google CloudがOSSとして公開しているspanner-migration-toolが利用されました。移行における注意点として、インターリーブを用いるため子テーブルより前に親テーブルをマイグレーションできるようにしなければならないことが挙げられていました。また、テストマイグレーションをサイクルで実施することで、認識できていない問題を洗い出す試みがなされているようです。

発表全体を通して、極めて丁寧に移行計画を進めていることが窺える内容でした。移行が全て完了した暁には、Cloud Spannerへの移行における一つの模範となりうる事例であると感じました。

まとめ

本記事では、Google Cloud Next Tokyo ‘24 Day 1の各セッションの概要についてお伝えしました。各セッションのアーカイブ動画は後日公開が予定されているようなので、本記事を読んでご興味を持たれた方は、後日アーカイブ動画の方もご確認ください。