8月1日、2日の二日間に渡って開催されているGoogle Cloud Next Tokyo '24の1日目のレポートです。
1日目から山盛りのコンテンツが用意されており、会場の熱気と情報量に圧倒されました。
このレポートでは、Day1の講演や展示ブースで見聞きした情報を元に、Google Cloudの最新動向と活用のツボをお伝えします。
レポートに記載されている情報は、ファクトチェックをしていません。そのため、話半分で読んでいただき、気になった点は公式ドキュメントを確認していただくことをお勧めします。
なぜリアルイベントに参加するのか
イベント内容を紹介する前に、私がGoogle Cloud Next Tokyoに参加した目的をお話しします。
それは、自分が知らない分野について、学習の取っ掛かりを得るためです。
技術について知識を得るには、本を読んだり、ネット検索をしたりするのが王道です。なのですが、全く知らない分野を学ぶときに限っては、リアルイベントに参加するのが効率的です。
理由は、リアルタイムイベントでは技術分野の全体像を掴みやすいからです。専門書を読むなどして門外漢な分野を学ぶときは、分野の全体像を知らないまま学習を進めることになります。その結果、細かな知識は増えていっても、体系的な理解には、なかなか行き着きません。
それよりも、まず最初は、ざっくりとしたイメージを作るほうが良いです。リアルイベントでの講義は、限られた時間の中で情報を伝えることに特化しています。そのため、このような「ざっくりとしたイメージ」を得るには最適です。
そうして頭の中のイメージができたら、後は書籍やオンラインチュートリアルで学習を深められるはずです。
せっかく時間を取ってイベントに参加するので、未経験分野の展示にも積極的に顔を出して、知識の幅を広げていきたいですね。
全体を通しての傾向
イベントでは様々な講演や展示がありましたが、全体を通して次の２つが大きなテーマだと感じました。
- Gemini活用
- Observeability
Gemini活用については、最近の生成AIブームを見ていると、そりゃそうだという感じですね。とはいえ、Gemini活用の裾野は、想像以上に広がっていました。
一般利用者向けの Google Workspace 連携から、開発者向けのコーディング支援やデータ分析支援まで、様々な機能が既に実現されていました。Gemini が進出しない分野はないと思わせるぐらいの勢いです。
Observeability についても、業界では昨年あたりからトレンドらしいです。ちょうど、『オブザーバビリティ・エンジニアリング』の邦訳が O'REILLY から発売された時期ですね。
後でも紹介しますが、Observeability 人気はマイクロサービスアーキテクチャの隆盛が一因らしいです。マイクロサービスアーキテクチャの普及によって、開発速度や開発者体験が向上した反面、システム全体を仔細に渡って把握するのは困難になりました。その結果、システムの状態を普段から監視しておき、そのデータを障害対応などに活用しようという動きが出てきたらしいです。
大規模決済中継システムにおける Cloud SQL から Spanner への移行と苦労
株式会社NTTデータが、自社開発の決済プラットフォームOmni Payment Gateway™のデータ基盤を、Cloud SQL から Spanner に移行した話です。
移行の目的
移行の目的は可用性の向上です。特に、メンテナンス時のダウンタイムを最小限にしたかったとのこと。決済システムなので当然ですね。
開発当初はコスト優先で Cloud SQL を選定しました。しかし、契約顧客数が増えるに従い、システムに求める要件が変わったそうです。技術選定がビジネスの影響を受けることの好例だと思いました。
移行の具体的作業
データ基盤を移行するとはいえ、決済プラットフォームは停止できません。そのため、移行期間中は Cloud SQL と Spanner を共存させたそうです。移行作業は、カナリアリリース的に、加盟店ごとに行いました。
Cloud SQL と Spanner を共存させるうえで心配なのは、データ不整合です。この問題に対処するため、データ不整合を検知するアプリケーションを作成したそうです。
最後に、コスト評価についての話もありました。クラウドは従量課金のため、事前のコスト見積もりは難しい傾向にあります。今回の事例では、商用環境と同じ通信量・データ規模で、コストの事前検証を行ったようです。「商用環境と同じ」という点が重要で、これにより出来るだけ正確にコストを見積もることができます。
移行後の運用
データ基盤が Spanner に変わってからは、 Spanner の豊富なサービスを活用して運用を行っています。システム状態の可視化に力を入れているらしく、レイテンシーやロック、さらにセッションプール使用率の可視化事例を紹介していただきました。
レイテンシーとロックの可視化は Spanner の標準的な機能を使って行えるらしいです。一方で、セッションプール使用率は OpenTelemetry という計測ツールを使って確認するとのことでした。
Sansan x Splunk: Cloud Run 環境のオブザーバビリティを高める方法
Splunk Services Japan合同会社が提供しているオブザーバビリティのためのツールを、Sansan株式会社が自社サービスBillOneの開発現場で、どのように活用しているのかという話。
SansanがCloudRunを選んだ理由
Sansan株式会社のBillOneというサービスでは、実行基盤にCloudRunを利用しています。この技術選定の一番の理由は、「楽だから」だそうです(´ω｀)
CloudRunはコンテナを Artifact Registry などにアップロードするだけで、自動的にCompute NodeやDomainの割り当てなどを行ってくれるマネージドサービスです。そのため、エンジニア視点では、クラウド設定の詳細を考えずに、気軽にサービスを立ちあげる事ができます。
また、「コンテナをアップロードするだけで動かせる」点はビジネス上のメリットにもなるそうです。というのも、事業ごとにコンテナを作って動かすという戦略が取れるので、新規事業や事業の横展開がスムーズに行えるからです。
さらには、コスト面でも優れているとのことでした。特に、マイクロサービスではコスト削減が見込めます。マイクロサービスは、ものによっては、一ヶ月に数時間しか動作しないものもあります。こうした動作特性をもつサービスは、CloudRunの従量課金との相性が良いです。また、理由は詳しく話していませんでしたが、同類サービスのAppEngineよりも結構安く抑えられるそうです。
(小噺) システムは第３世代が成功しやすい
現在のBillOneは version 3 だそうです。
BillOneは、今でこそ請求書管理で市場を席巻していますが、開発初期は支払い管理で売り出そうとしていたらしいです。しかし、市場の受けが悪くて方針転換。
次に試したのは仕分け管理。これも失敗して、3度目の正直で請求書管理にたどり着いたそうです。似たような話が、『UNIXという考え方』にも載っていたような。
SREの問題1 (システムの全容把握)
システムの全容把握が不可能となり、いままでの運用では通用しなくなったことが問題として挙げられていました。
BillOneはここ数年間で急速に成長しているプロダクトです。そのため、次第にシステムの全容把握ができなくなっています。現在ではシステムを構成する様々なマイクロサービスの概要は分かるものの、中身までは把握できていない状況だそうです。
すると、レイテンシーが悪化した時やエラーが発生した時に、原因の調査が難しくなります。そうした難しいタスクはスキルのある人に属人化しやすく、業務負担の偏りが生じてしまうとのことでした。
SREの問題2 (稀な障害への対応)
BillOneは請求書管理を行うサービスなので、月初にアクセスが集中するという特性があります。そのため、月初だけレイテンシーが悪くなりがちです。
この原因を調査したいのですが、現象が「月初だけ」にしか起こらないため、調査は難航します。というのも、このレイテンシーの悪化は、月に一回しか再現しないからです。例えば、今日の調査で原因が分からなければ、来月まで調査が持ち越しになります。
サービスの規模に関わらず、稀な障害への対応は難しい課題です。
splunkを導入した結果
障害が起きたら、とりあえずsplunkを確認するようになったそうです。splunkには、システムがどのような動作をしたかが記録されています。この情報を、システム構成図などのドキュメントの情報と合わせて用いることで、効率よく障害の原因を調査できます。
また、splunkが障害調査のプラットフォームとしての役割を果たしてくれるので、障害調査を開発チームに任せやすくなったそうです。
進化するコンテナ環境 : Google Kubernetes Engine と Cloud Run の最新アップデートと使い所を徹底解説
GKEとCloudRunのアップデート紹介です。細かい内容は省いて、印象に残ったアップデートを記載します。
GKE: Workload Identity Federation
Kubernates Pod が GCP のサービスを使いたい場合、Kubernates Service Account に IAM ロールを直接付与できるようになりました。
従来は、 Kubernates Service Account が Google Service Account のロールを借用して GCP のサービスにアクセスしていました。この手順が簡略化できます。
GKE: リソース設定の最小値引き下げ
GKE (Autopilot mode) でのリソース設定の最小値が引き下げられました。これにより、今までよりも少ないコストで GKE を使い始めることができます。講演では、2ドル/月くらいから使えると話していました。
GKE: Container Image Preloading
AIモデルやライブラリなどの容量が大きいデータを、セカンダリディスクに格納しておけるようになりました。これにより、コンテナサイズを削減できるほか、Nodeの立ち上げが速くなります。
GKE: GKE Enterprise
エンタープライズ向けのプランが発表されました。GKE Audit Log を元に不審な操作を自動検知する機能 (GKE Thread Detection) や、業界ベンチマークやセキュリティ基準の遵守を自動監視する機能 (GKE Compliance) が使えます。
CloudRun: Direct VPC Engress
Serverless VPC Access Connector を経由せずに VPC へトラフィックを流せるようになりました。
CloudRun: ボリュームマウント
NFS や CloudStorage Fuse を CloudRun へマウントできるようになりました。構成ファイルを CloudStorage に格納しておき、CloudRun で使うなどのユースケースがあります。
自動セキュリティアップデート
ベースイメージを自動で更新してくれます。
Application Canvas
Gemini で自然言語からアーキテクチャを自動構成できます。
Gemini for Google Cloud: コード アシスタントからデータ分析まで、AI があなたのワークフローを加速
今年4月の Google Cloud Next '24 で発表された Gemini for Google Cloud を紹介していました。
Geminiの種類
Gemini は Google の生成 AI です。分野別にいくつかの Gemini が開発されているようです。
-
Gemini
コンシューマー向けです。TV CM でおなじみの Google検索支援や Gmail 返信支援などを行ってくれます。 -
Vertex AI
AI 開発者向けです。機械学習モデルの開発プラットフォームです。モデルのトレーニングやデプロイができます。 -
Gemini for Google Workspace
Google Workspaceと統合されています。 -
Gemini for Google Cloud
クラウド開発者向けです。
Gemini for Google Cloud の機能
Gemini for Google Cloud には6つの機能があります。
- Gemini Code Assist
- Gemini Cloud Assist
- Gemini in Security
- Gemini in BigQuery
- Gemini in Looker
- Gemini in Database
Gemini Code Assist
Google 社内で培われた DevOps や SRE のベストプラクティスを学習しています。
IDE 統合
VSCode や JetBrain の IDE に組み込むことができます。例えば、 VSCode では、コード生成用のサイドバーを表示できます。
コード生成
Gemini Code Assist のウィンドウにプロンプトを入力するとコードが生成され、ボタンクリックでファイルに反映できます。
他にも、コード内コメントとしてプロンプトを入力することもできます。
コードを RAG のデータソースとして使えるため、コーディング規則に沿ったコードが生成できます。コードはデータソースとして使われるのみで、Gemini の学習に使用されることはありません。
テストコード生成
テストコードも生成できます。テストしたい範囲をエディタ上で選択して、「右クリック」-> 「generate test codeボタンクリック」で生成できます。
コード説明
コードの解説を生成することもできます。説明してほしい範囲を選択して、「右クリック」-> 「explain thisボタンをクリック」で生成できます。
コードトランスフォーメーション
リファクタリングを任せることもできます。
コードベース全体を学習
最大100万トークンまで履歴に保持できるため、コードベース全体を考慮したコード生成が可能です。
Gemini in BigQuery
GCP コンソール内、もしくはエディタに組み込んで使います。
クエリのエラー修正
SQLにエラーがある場合、プロンプトを入力しなくても、エラー内容を考慮した修正案を提示してくれます。
BigQuery データキャンバス
データ分析の「データを探す」・「分析する」・「可視化する」を、一度に GUI で行えます。
各工程でプロンプトを入力して、期待する結果をデータキャンバスに指示します。また、一度出力された結果を、プロンプトで微調整することもできます。