Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

Google Cloud Next Tokyo '24 2日目参加レポート

はじめに

2024年 8/1-8/2 にパシフィコ横浜で開催されているGoogle Cloud Next Tokyo ‘24に同じプロジェクトのメンバー数名で参加してきました。

この記事はDay2（8/2）の参加レポートです。

Day1のレポートはGoogle Cloud Next Tokyo ‘24 1日目参加レポートです。

基調講演

Day1と比較すると企業でのGoogle Cloud、主にGeminiの活用事例の話がメインでしたが、Day1に引き続き「生成AIを試す時代から実用化する時代への変化」というテーマが感じられる基調講演でした。活用事例としては以下が紹介されていました。

  • 日本テレビ放送網株式会社におけるGeminiを活用した動画像解析
  • ヤマト運輸株式会社におけるGoogle Maps Platformを活用した配送計画
  • トヨタ自動車株式会社における現場での利用を目指したAIプラットフォーム構築でのGemini Code Assistの活用
  • 株式会社三井住友フィナンシャルグループにおけるIT活用戦略とOffice365とGoogle Workspaceのハイブリッド利用

また、基調講演内で発表されたGoogle Cloudのアップデートとしては以下がありました。

特にSpannerは今回のアップデートによって益々使いやすいものとなりそうです。

セッション講演

Day2では5つのセッション講演を聞くことができました。ざっくりとした中身と所感を書いていきます。

建築・建設業界の DX 化を加速させるアンドパッドの AI / LLM 活用事例（株式会社アンドパッド）

  • 建築・建設業界の上流から下流までを一元管理できるアプリ開発
  • 作業現場情報を残す手段として黒板に書き込み、写真を撮って残すのが通例
    • この部分のデジタル化・自動化を目指すべく豆図AIキャプチャと黒板AIにおけるAI・LLM活用事例の紹介
    • ちなみに豆図は工事写真を補足説明するための断面の模式図や写真
  • 取り扱うデータに非構造データが多い
    • 図面、ドキュメント、現場写真、チャットなど
    • 業界ならではの特殊記号が多い
    • データの取り込みにOCRが主流だったが、LLM（Gemini）の活用を進めている
  • OCRとGeminiの比較
    • それぞれチューニングしたうえで認識結果を比較したところ、Geminiが圧勝
    • Geminiはfew-shot learningによって更なる性能向上可能性が見られた
    • Geminiに対するリクエストコストと精度のバランスが大事
      • 図面全体をスキャンさせると精度は上がるが、お金もかかる

OCRとGeminiの比較の話が面白かったです。前職でOCRを少し触っていたこともあり、認識精度を高めようとすると要らない部分まで文字と認識されるなどOCRの苦しみを味わったことがあります。GeminiなどLLMによって、コンテキストを理解することで精度高く文字・記号認識ができるようになってきたのは革新的ですね。もちろんコストが全然違うので、LLMによってOCRがすぐに淘汰されるということはなく、OCRを使うかLLMを使うかのシチュエーションやコストバランスが大事だと思いました。

引越にゃんこ大戦争ー運営中のゲームを Google Cloud に移行するためにしたこと（ポノス株式会社）

  • Aurora MySQLからSpannerへの移行話
    • 移行は現在進行形
  • 移行理由
    • メンテナンスがつらい
    • SpannerでUpsertができるようになった
    • （他にもありましたが聞き逃しました）
  • やめられない、止まらない
    • 移行はしたいがサービスは止められない
    • 過去バージョンのアプリでも遊べるようにしておきたい
    • 引っ越しサービスを考案
      • 希望ユーザー（アクティブユーザー）のみ、引っ越しサービス経由で移行してもらう
        • Cloud VPN（AWS⇔Google Cloud）でAuroraに直接クエリを投げて移行
      • 非アクティブユーザーは後日に一括移行
  • 負荷テスト話
    • GKE+Locust
    • ボトルネックを探すのにはCloud Traceが超便利だった
    • Cloud Runで全く性能が出ずに胃が痛くなる日々
      • パフォーマンスチューニングがされていないだけだった
      • AWSではElastic Beanstalkを使っていて、元々良い感じにチューニングされていた
  • サーバー切り替え話
    • クライアント側の問題で、DNSを切り替えてもすぐに向き先が変わらない場合もある
    • AWS側で新ドメインを作っておき、リバースプロキシで対応

Google Cloudへの現在進行形な移行話を赤裸々に語っており、非常に勉強になるセッションでした。特に「引っ越しサービス」という形でアクティブユーザーのデータ移行を実現しており、サービス運営しながらユーザーに配慮した移行というアイデアの素晴らしさを感じました。

また、AuroraからSpannerへの移行話はDay1の「スケーラビリティと信頼性を追求: Global で 5,500 万ユーザーを抱えるカレンダー シェアアプリのデータベースを Aurora から Cloud Spanner へ移行」でも語られておりました。この発表でも、SpannerでUpsertができるようになったことが移行の障壁を下げたとの内容があり、今後も同様の移行話が出てきそうです。

ちなみに、負荷テスト話で出てきたGKE+Locustによる負荷テストは拙著もあるので参考にしてください。

BNE ゲームタイトルにおけるリリース前後のインフラの最適化と課題（株式会社バンダイナムコエンターテインメント）

  • 2つのゲームタイトル事例を紹介
    • 僕のヒーローアカデミア ULTRA RUMBLE
    • 鉄拳8
  • 構成
    • GKE + Agones
  • サーバーコスト圧縮
    • サーバーをn1-standard-4→T2D-standard-4へ変更
    • 1.8コアで1試合だったのが、0.8コアで1試合できるようになり、1サーバーで4試合対応可能に
    • サーバーのチップが変わってしまうのが大きな決断ではあったが、何とか対応できた
  • ワールドワイドマッチング
    • 北米・欧州・アジア圏といったRegion区切りでGKEを配置
    • ゲームは物理的条件によるレイテンシが結構効いてくる
      • 例えばアジア圏といってもシンガポールから日本は結構距離があるため、P2Pが大変
  • 開発におけるTIPS話
    • 設計段階でGKEの1Podに収容する人数を決めておく
      • 何CPU必要なのかといったインフラコストに直結するため
      • 場合によってはAgonesを使わないほうが安上がりする場合もある
    • 通信量と通信料
      • EGRESSの通信量が膨らみがち
      • EGRESSの通信料はComputeEngineの料金の中で課金されるので見逃さないように気を付けたい
    • バッファとするPod数
      • バッファは保険なのでコストがかかり続ける
      • 結構ぎりぎりを攻めるようにしている
  • Spanner話
    • プロファイリングの手段
      • 無知は罪
      • APM、Cloud Trace、Datadogなどプロファイリングするのはマスト
    • ウォームアップ
      • リリース前にノード数を増加するだけではリシャーディングされないため、負荷に耐えられなくなる
      • リリースの数日前には負荷テストを行ってウォームアップしておき、確実にリシャードしておく

個人的にゲームが好きなので、自分たちが触れる表側を想像しながらその裏側話を聞くのは大変楽しいものです。ゲーム内の衝突判定にはCloudのネットワークでは遅すぎるからP2Pを利用している部分や、マッチング毎にGKEのPodが立ち上がり、その中で試合が行われているなどワクワクする話が盛りだくさんです。

ゲームにおけるマルチリージョナル戦略は単純に可用性を高めるためというわけではなく、物理的にユーザーと距離を縮めておかないとレイテンシによってサービスが提供できないというあたりが業界の違いを感じさせられます。また、ゲームのマッチ毎にPodがポコポコ立ち上がり、終われば消滅していく部分などもGKEというかKubernetesの恩恵をフルに享受できているんだなーと思いました。

Google Cloud を用いたソフトウェア開発の内製化組織の早期立ち上げの実現（株式会社EARTHBRAIN）

  • 内製化によってソフトウェアのコントローラビリティを獲得する
    • ビジネス上必要なシステムの機能追加をしつづけられる
    • 開発時間の短縮
    • 専属の内製チームにノウハウを蓄積させる
  • 内製化組織に向けたポイント
    • コア業務・技術を中心に内製化する
      • 例えば、EARTHBRAIN社ではDataplatformと3D技術
      • 競争優位性を維持しやすい
      • 隣接市場へ裾野を広げることも可能
    • フルマネージドサービスの活用
      • ノンコア業務は内製化しない
      • 何をやるかと何をやらないのかを見極める
  • 経営資源を効率よく投下すべき
    • メリハリをつけた開発
    • 昨今の国内エンジニアの採用は難しい…
      • 分野を絞ってエンジニアを集める
      • Internal Developer Platformはすぐに利益に直結しない
        • やりたいけど、一旦我慢する
    • 競争優位性に繋がる領域に絞って経営資源を投下する
  • 内製化後の改善も大切
    • To-Be像とのギャップを埋めていく
    • DORAの4keysを活用しEliteを目指す
    • もちろん、それぞれの指標で改善の労力は全然違うので、何を優先すべきかを考える

内製化組織を作っていくにあたっての組織や経営の話をされており、一番ハッとさせられる発表でした。自分はエンジニアリング寄りの人間でソフトウェア開発において全てをコントローラブルにしたいという気持ちになりがちなため、何をやらないのかを見極めるという観点はいつも忘れてるなーと痛感させられました。また、一概に内製化と言っても全て自分たちで作る必要はなく、他と比べて優位に立てる業務を見極めてそこから裾野を広げていくという考えは常に心に留めておきたいと思いました。

データ分析環境の Google Cloud 移行（出前館）

  • 出前館のDWH
    • 200TBのストレージ
    • 9000のテーブル
    • 9300億レコードと5億レコード/dayの更新
  • 移行理由
    • 従来のデータ分析環境の限界
      • 2000年にスタートしたサービスでシステムがレガシー
      • SQLのレスポンスが遅すぎる
      • データ統合が不完全
      • Biz側の要求に応えるのに時間がかかる
    • 業界スタンダードな環境が必要
      • 取り扱いに知識が必要で採用に障害となっている
    • タイミング
      • 他の基盤刷新もあり、同じタイミングで移行できた
  • 移行後の構成
    • DB→GCS→Composer（Airflow）
  • 運用話
    • BigQueryのSlotを利用し、Slot数はCloud Functionで繁忙時間に合わせて動的に変更
    • データ連携の時間をダッシュボード化しSLAを決める
    • Dataprexを利用してデータカタログを作る
  • 移行後のいろいろ
    • 改善事例
      • 独自環境ではなくなったため、学習コストが劇的に下がった
      • 粒度の高いデータ提供ができるようになった
      • マッチングアルゴリズムや待ち時間予測モデルなどの精度向上
      • 配達員のUXが劇的に改善した
    • 課題
      • データマネジメントの問題
        • BizユーザーからDatamartやDWHそのものを扱いたいという要望
        • 想定していないユースケースだったため、データがマネジメントされていない
        • DMBOK2に基づいて問題の整理や改善中

自分も現在のプロジェクトではデータ分析基盤に関わっていることもあり、非常に学びになりました。特にBigQueryのSlotは昨年のEditionの導入によって料金が上がってしまったので、動的にSlot数を制御するのは有用だなーと感じました。また、Bizユーザーが自身で直接DWHを利用したりDatamartを構築したりといった需要は、自身のプロジェクトを鑑みてもかなり高まってきてる感は共感できました。BigQueryなどでデータが簡単に扱えるようになったこともあり、更にデータの民主化が進んでいきそうです。

ちなみに、9月上旬ごろにはセッションの動画もYouTube等で公開されるみたいなので、ぜひ気になる講演があれば見てみてください。

ブース

Day1の参加報告で紹介し忘れてましたが、Google Cloud Professional資格を持っている人のみが入れる認定資格者ラウンジがあります。このラウンジではコンセント付きのテーブルが置かれており、ちょっとした作業をできます。また今年は資格全冠者向けに限定グッズプレゼント企画があったので、滑り込みで全冠しておいてよかったです。

Day2もDay1と同じブースが出展されているので、Day1で回りきれなかったブースにも足を運ぶことが可能です。所感としてはSaaSを提供している企業ブースに外資系の会社が多く見られました。割と直近で日本ブランチが作られている会社もあり、まだまだ市場として日本は注目されているんだなーと感じました。

この日に回った会社はABC順で以下になります（もちろん、これらの会社以外も出展があります）

まとめ

Day1、Day2ひっくるめた所感としては、Google CloudやGoogle WorkspaceとGeminiの融合を加速させていくぜ！ という気持ちが感じられました。Geminiの利用を標準化させていくことによって競合クラウドベンダーとの差分化を狙っていけるのではないでしょうか。ただ、Office365やOpenAIを擁するAzureに対してどのように戦っていくかは気になるところです。

元々マネージドサービスの利用が増えつつある潮流はありましたが、Geminiの活用によってノンマネージドで煩雑なインフラ構築も益々楽になっていくでしょう。今に始まった話ではないですが、Google Cloudやインフラ・DevOpsの知識でご飯を食べている自分としては身の振り方を考えていかないとなーと今回の参加で痛感させられました。
その反面、生成AIのおかげでフルスタックな開発が一人でも回せるようになっており、やったもん勝ち・手を動かしたもん勝ちな世界になってきています。自分も色々手を出してみようとやる気を貰える参加にもなりました。

イベント参加は色々考えさせられるきっかけを貰えるので、もし時間があればぜひオフラインでこういったイベントに参加してみることをおススメします！