Google Cloud Next Tokyo '24 Day 2

はじめに

ZIPAIRの技術チームメンバーでGoogle Cloud Next Tokyo '24へ参加しました。この記事ではDay 2に参加したセッションのレポートをお届けします。Day 1の記事もありますのでぜひご覧ください。

参加したセッション

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

Sprocket の Google Cloud 全移行 〜DynamoDB から Cloud Spanner へ〜

本セクションではAWSが提供するNoSQLデータベースであるAmazon DynamoDBからSpannerへのデータ移行の事例が紹介されていました。SprocketはCX改善プラットフォームを提供する会社であり、Webサイト上でのエンドユーザーの動作を行動データと呼ばれるデータ形式にてAmazon DynamoDBへ保持していました。低いレスポンスタイムと高い可用性がクラウドプラットフォームのサービスに求められましたが、開発の初期段階においてその要件を満たすサービスはAmazon DynamoDB以外になかったそうです。時を経てサービスが安定して稼働するようになった際、データの読み書きに必要なインフラコストが課題となりました。加えてAmazon DynamoDBはNoSQLであるため、SQLを利用した調査が難しかったことも移行のきっかけとなったようです。今回はそれらの課題を解決するため、Google Cloudからスケーラビリティと高可用性、RDBMSのようなデータ一貫性を持つCloud Spannerが提案されました。

データ移行に際してGoogle Cloudからのガイドを参考にしておこなっていました。DynamoDBからエクスポートしたデータを一度Spannerへインポートした後、差分データをAWS LambdaとPub/Subを用いてSpannerへインポートしていたようです。手順自体は複雑なもののガイドに沿った実装であったため、さほど苦もなく実装できたそうです。しかしながら、NoSQLからの移行であるため、データ変換に苦労したと語っていました。

移行した結果、データベースのコストが45%削減され、SQLを実行できることによるメンテナンスコストの低減が達成されたようです。またデータ移行自体もサービスの稼働を止めることなく実施できたとのことです。DynamoDBからSpannerへの移行は事例も少ないらしく、有益な事例発表だったと感じました。

Vertex AIの業務への活用・導入のポイント

このセッションでは、業務でどのようにVertex AIを活用したかの事例が紹介されました。

社内ナレッジの検索や問い合わせ一次回答作成支援にVertex AIを組み込むことで、コストを削減できたとのことでした。
AI技術は日々進化しているので、今後どのようなことに活用されていくのか追っていきたいと思いました。

引越にゃんこ大戦争ー運営中のゲームを Google Cloud に移行するためにしたこと

にゃんこ大戦争を運営するポノス株式会社により、運営中のゲームをGoogle Cloudへ移行するためにおこなったことが紹介されていました。

スマホゲームでは定期メンテナンスが実施され、メンテナンス中はゲームができないといったことがよくあります。しかし、にゃんこ大戦争は定期メンテナンスをせず基本的にユーザーが遊び続けられる状態を維持するという方針のもと運営していると紹介されました。
Google Cloudへ移行する際も前述した方針を守れるよう、ユーザーへの影響を限りなくゼロにする必要があったようです。

データを一括移行する方法はゲームを止める必要があるため実施できず、引越しサービスを実装しデータ移行したということでした。引越しサービスはアクセスがあったユーザーのデータのみを移行するサービスで、VPC同士をCloud VPNで接続し、Auroraに直接クエリを投げるとのことでした。

こういったアプローチによりゲームプレイに影響を及ぼさないよう移行できる計画を立てていたことがとても印象に残りました。

リアル エンターテインメント事業におけるデータ基盤の取り組みの紹介

バンダイナムコグループでは会社統合後の事業再編により複数の分析システムが乱立し、システムデータのサイロ化が加速し問題となっていたようでした。
このセッションでは、サイロ化解消のためにどのような取り組みをおこなったかを紹介していました。

チーム毎にTreasure DataとGoogle Cloud Platformを利用していたため、コスト冗長も表面化していたそうです。そこでGoogle Cloudへ統合を決めたようです。
Treasure Dataを廃止するためにBigQueryへデータ連携したようですが、Treasure DataにはあってもBigQueryにない関数の実装やデータの整合性の確認に苦労したようでした。しかし、Google Cloudへ統合できたことで、コストの削減やサイロ化を解消でき、データの利活用へのベースができたということでした。

Bandainamco Entertainment ゲームタイトルにおけるリリース前後のインフラ最適化と課題

このセッションでは、Bandainamco Entertainmentのゲームインフラの事例紹介とKubernetes & AgonesおよびSpannerの利用上の注意点について発表がなされました。

1つ目の事例は「僕のヒーローアカデミア ULTRA RUMBLE」におけるサーバーコスト圧縮についてです。ゲームのユーザーはマッチング後、GKE上のDedicated Game Serverへ接続して試合をします。このサーバーに接続している間、つまり試合中にのみ課金され、試合が終わると課金も停止されます。当初はこのサーバーに4コアのN1スタンダードマシンを用いており、サーバーあたり2試合を同時に処理していました。しかし、これを4コアのT2Dスタンダードマシンに置き換えたことで、サーバーあたり4試合の同時実行が可能になりました。その結果、起動されるサーバー数が減りコスト圧縮を実現できたそうです。

2つ目の事例は「鉄拳8」におけるワールドワイドマッチングについてです。ユーザー同士が対戦する際には、直接通信するのではなくTURNサーバーというものを中継するアーキテクチャになっています。このTURNサーバーを世界各地のリージョンに配置することで、安定したワールドワイドマッチングを実現しているそうです。なお、こちらの事例については別のセッションにて詳細が語られているとのことでした。

続いて、Kubernetes & Agonesを利用する上で気を付けることについて説明がなされました。Agonesとは、Kubernetes上でゲームサーバーのホスティングとスケーリングを行うためのOSSです。1Podに収容する人数、ノードやPod数の上限、低コストで多くのPodを収容できるノードタイプの選択、バッファとなるPod数の管理など、コストやパフォーマンスを最適化することの重要性が語られました。また、Autopilotの利用や1Podへの複数Room割り当てといった、現在検討中のコストを下げるための対策も紹介されました。

最後に、Spannerについても利用上の注意点が語られました。プロファイリング手段を事前に把握しておくことや、リシャーディングが機能するようリリース前に負荷試験でウォームアップをしておくことが紹介されました。Spannerは学習コストがやや高いものの、適切に利用できればそのベネフィットは非常に大きいと言えます。また、その信頼性も高く、Bandainamco Entertainmentのインフラ案件でSpanner起因の障害はこれまで一度も発生していないとのことでした。

脅威インテリジェンス プラットフォームの新しいかたち： Google Threat Intelligence で何が変わるのか？

このセッションでは、Google Threat Intelligenceの概要と脅威インテリジェンスの活用方法について発表がなされました。

Google Threat Intelligence (Google TI)は2024年6月から一般提供が始まった脅威インテリジェンスプラットフォームです。Mandiantの調査によると、近年のサイバー攻撃はより鋭く、速くなっており、新たなぜい弱性を利用するケースが増えています。Google TIは、MandiantやVirusTotalの製品などを統合し専門知と集合知をGoogleでつなぐことを目的としています。さらに、Google TIでは単に脅威を調べるだけでなく、そこからアクションにつながるように設計されていることも大きな特徴です。

セキュリティにおけるリスクベースアプローチには、「敵を知る」ための攻撃者視点と、「己を知る」ための守るべき組織視点の2方向があります。その中で、脅威インテリジェンスは「敵を知る」アプローチに当たります。脅威インテリジェンスの体系は上位の概念から順に、戦略、運用、戦術の3段階のレイヤーに分けられます。Google TIでは、戦略レベルに強いMandiantと戦術レベルに強いVirusTotalを組み合わせることで、より包括的な脅威インテリジェンスを提供します。

また、セッションではGoogle TIにおける3つのユースケースが紹介されました。

• 脅威プロファイリング：AIによる脅威アクターの解析、TTPsの把握や追跡、IoCのモニタリングを通じて、自組織を狙う脅威に集中できます。
• IoCの調査解析：不審なログやファイルなどから得られたIoCを調査し、関連する攻撃や脅威アクターを把握します。最終的には、脅威プロファイリングを更新しモニタリングを強化することで、調査結果をシームレスに運用へと落とし込むことができます。
• 能動的リスク監視：Attack Surface Management (ASM)により、組織が把握していない情報資産の発見や新たなぜい弱性への早期対応を可能にします。また、Digital Threat Monitoring (DTM)により自組織への攻撃の兆候を迅速に検知します。

最後に、Google Security Operationsとの統合についても触れられました。Security Operationsは先述の「己を知る」アプローチに相当します。Google TIと統合することで、包括的なセキュリティを構築できることが強調されていました。

まとめ

Google Cloud Next Tokyo '24 Day 2の各セッションの内容をお伝えしました。今後もカンファレンスに参加した際は、また記事として投稿する予定です。お見逃しのないようフォローのほど、よろしくお願いいたします。