📝
Google Cloud Next Tokyo '24の事例セッションを個人的にピックアップ
はじめに
8月に開催された、Google Cloud Next Tokyo '24のセッション動画が、以下で公開されていました。
個人的に気になったセッションを備忘録的にまとめました。
DAY 1 セッション
アプリケーション開発
Google Cloud モニタリング ベスト プラクティス
Ubie株式会社 坂田 純 氏
- GMP(Google Cloud Managed Service for Prometheus)の紹介
- Prometheus
- オープンソースのモニタリング/アラーティングツール
- ワークロードからメトリクスをスクレイプする
- エージェントからPUSHする形ではない
- 各ワークロードはPrometheusの形式でメトリクスを出せば良い
- 課題
- ストレージ：長期保存によるストレージ増加、クエリの実行パフォーマンス
- スケーリング：単一構成ではスクレイピング、メトリクスの収集機能などに限界
- Google Cloud Managed Service for Prometheus(GMP)
- Cloud Monitoring(Google Cloudのネイティブの監視ソリューション)が直接サポートする Prometheus
- ほぼ無限にスケールするデータベース、メトリクスの収集機能
- クエリ言語はPromQL
- Cloud Monitoringの全機能でPromQLが利用可能
- Google独自のMQLは無くなっていく模様
- 利用
- GKEでは、オプションを有効化するだけでインストールされ、メトリクスの収集が可能
- Cloud Runでは、サイドカーパターンで利用可能
- 可視化
- Ubie社ではGrafanaを利用
- Cloud MonitoringのSLO Monitoringも可視化可能
- Ubie社ではGrafanaを利用
- コスト対策
- 不要なメトリクスは
metricRelabelingでdropさせることが可能
- 不要なメトリクスは
- Prometheus
データ分析
近畿日本鉄道における鉄道データを用いたコスト最適の為のデータ統合、可視化の取組み
近畿日本鉄道株式会社 佐藤 広和 氏
株式会社データフォーシーズ 坂本 唯史 氏
- データ活用の推進
- 既存保有のデータ棚卸～分析で成果を出すことで、データ活用文化を醸成
- データ活用プロジェクト事例
- 券売機プロジェクト
- 各駅・コーナー（駅の出口）ごとの券売機の適正台数、適正配置の決定
- 担当者のために、Excelで対応
- 削減台数を入力することで、混雑状況が変化するようなシミュレーションシートを作成
- 改札機プロジェクト
- 各駅・コーナー（駅の出口）ごとの改札機の適正台数の分析
- IC専用 / IC・磁気カード両用機器の割合
- 1分単位の混雑度から分析
- データボリュームが3億件以上で、データ基盤の準備が必須
- 構成・フロー
- 近鉄側でデータを収集・とりまとめ
- Googleドライブに格納
- スポットのプロジェクトのため、手動
- Pythonで整形し、Cloud Storage・BigQueryに格納
- LookerStudioで可視化
- LookerStudio活用のメリット
- シミュレーションの試行錯誤はBIで。都度のレポーティングが不要に
- パラメータ機能によって、BigQueryのWHERE句で指定した変数を動的に連動可能
- KPIをすぐに作成 / 確認
- 必要なグラフをすぐに追加し、URLリンクやPDFで関係者へ迅速に連携可能
- シミュレーションの試行錯誤はBIで。都度のレポーティングが不要に
- 各駅・コーナー（駅の出口）ごとの改札機の適正台数の分析
- 券売機プロジェクト
データベース
大規模決済中継システムにおける Cloud SQL から Spanner への移行と苦労
株式会社NTTデータ 鳥海 克成 氏
株式会社NTTデータ 松井 僚太郎 氏
- Cloud SQL から Spanner へ移行
- Omni Payment Gatewayのデータベース部分
- なぜ移行するか
- メンテナンス停止の回避
- Cloud SQLのメンテナンス期間中は要サービス停止。都度夜間作業とお客様への通知が必要
- 決済の大幅増加見込み
- TPSが現状から50倍増加する予定
- 可用性要件
- サービス全体で99.99%の可用性が必要
- アーキテクチャ全体をマルチリージョン化
- （移行時はソウルリージョンでマルチにしていたが、デュアルリージョン構成がGAされた模様）
- メンテナンス停止の回避
- なぜCloud SQLを使用していたか
- 初期方針はマルチクラウドを想定。MySQLを利用
- コスト面で、サービス開始時は高額なDBが利用できなかった
- 可用性の要件が、初期は99.95%で十分だった
- 気を付けたポイント
- 移行前
- テーブル構造
- ホットスポット回避
- 時系列データが含まれているULIDを、反転してホットスポット回避
- セカンダリインデックスを最低限に
- 挿入がメイン用途なので、インデックスは最低限に
- 時間系インデックスは削除
- 挿入がメイン用途なので、インデックスは最低限に
- ホットスポット回避
- クエリ・検索方針
- Spannerは簡単な検索のみ
- 主キー、セカンダリインデックスでの簡単な検索のみ
- 複雑な検索はBigQueryに任せる
- 時系列データなど
- shardIDで時系列検索に対応できるが、余計なインデックスを張らないようにするため、不採用
- 時系列データなど
- 検索条件でBigQueryを検索。取得した主キーでSpannerから全データ取得
- Spannerは簡単な検索のみ
- 非機能要件
- コスト算出
- 商用環境で利用予定のマルチリージョンで検証
- 本番と同程度のTPSで負荷をかけて、ノード数とストレージ量などを算出
- 同じ負荷でも、シングル/マルチリージョンではCPU利用料・必要ノード数が変わる
- レイテンシ
- 検索は、MySQLと比較してかなり遅い（簡単な検索で十数ms）
- マルチリージョンだと、シングルリージョンからさらに1.5倍
- コスト算出
- テーブル構造
- 移行中
- データ整合性を担保 & ダウンタイムゼロ
- Phase.1 新規のSpannerに保存するマイクロサービスを作成。メッセージ送り先に追加し、既存のCloud SQLとSpannerの両方に保存される状態
- Phase.2 Phase.1以前のCloud SQLのデータをDumpして変換、Spannerに移行
- データ変換サービスには、大量にメモリが利用できるBatchを採用
- Phase.3 不整合データを検知して補正する仕組みを構築
- 移行中に更新されるレコードへの対処
- 移行完了後も不整合がない確認に利用
- Phase.4 後続の処理をSpanner側のマイクロサービスに繋ぎ変え
- 加盟店ごとに変更し、カナリアリリース的に変更
- データ整合性を担保 & ダウンタイムゼロ
- 移行後
- リソース監視
- Query Insights
- クエリごとのCPU使用率、実行回数、レイテンシが見える
- アプリケーション側でタグを付与すれば、タグごとに集計可能
- ロックの分析情報、トランザクション分析情報など、色々なダッシュボードが用意されている
- クエリごとのCPU使用率、実行回数、レイテンシが見える
- Query Insights
- リソース監視
- 移行前
- その他苦労点
- 分散トランザクションの性質によるロック
- 性能試験時に、想定外のロック待機発生
- 原因
- 1つのトランザクション内でセカンダリインデックスを含む複数テーブルへの操作を行う
- コミット要求時にすべてのテーブルに確認を取り、すべてOKならコミットを実行する作り
- Spannerがホットな状態だとデータが更新中の事があり、次のコミットで待機が発生
- 減らすためにはしっかりウォームアップ
- 性能試験前に1時間ほどかけてウォームアップ
- 徐々にトラフィックを増やして負荷をかける
- 本番相当のTPS/QPSで行う
- PKのキーレンジをそろえる
- 性能試験前に1時間ほどかけてウォームアップ
- セッション管理にはセッションプールを利用
- セッション作成には数百msかかる
- セッションプールの設定項目あり。GoとJavaのクライアント側で設定可能
- プールされているセッションも、リソースへの影響は極小
- 内部的にセッション確保のため、50分に一度、Select 1を実行している模様
- セッション回りの指標は、OpenTelemetryによりモニタリング可能
- 分散トランザクションの性質によるロック
インフラストラクチャ
Google Cloud VMware Engine を起点とした JALインフォテックのインフラ改革プラン
株式会社JALインフォテック 瀬崎 健太郎 氏
株式会社JALインフォテック 爰野 寛太 氏
Google Cloud 栃沢 直樹 氏
- Google Cloud VMware Engine (GCVE) とは
- オンプレミスで運用しているVMware vSphere ベースの VM をそのままクラウド移行（リホスト）
- 「クラウドには移行したいが、イメージ変換が難しい」というニーズに適う
- GCVEの移行を足掛かりとして、リプラットフォームやリアーキテクトが望ましい
- オンプレミスで運用しているVMware vSphere ベースの VM をそのままクラウド移行（リホスト）
- Google Cloud VMware Engine のメリット
- Google Cloud ファースト パーティ サービスである
- Googleクラウドコンソールで操作可能
- vCenterでの運用が継続可能
- vCenter 管理者権限相当も利用可能
- Google Cloudサービスとシームレスに統合
- SLAが99.99%
- オンプレミスとの接続が用意
- 既にオンプレミスとVPCとがつながっていれば、専用に別途接続は不要
- ピアリングやカスタムルートの設定で可能
- 既にオンプレミスとVPCとがつながっていれば、専用に別途接続は不要
- Hybrid Subnetsで、GCEインスタンスに変換しつつ同一サブネットで移行も可能（プレビュー）
- IPアドレスが変えられないVMなど
- その他拡張機能など
- 外部データストアマウントの拡張
- データストアだけ拡張したい際の選択肢
- Filestore
- NetApp Volume
- VMware Engine Storage Only Node
- GCVE vSAN クラスタ に対してストレージ専用ノードをデプロイ（リーズナブルに利用可能）
- データストアだけ拡張したい際の選択肢
- GCVE Protected
- バックアップソリューション
- ライセンス持ち込み可能
- VMware ソフトウェアライセンスはBroadcom社と契約
- ESXiホストやインフラ、サポートなどはGoogle Cloud
- （ライセンスがない場合は、すべてGoogle Cloudより購入）
- 外部データストアマウントの拡張
- Google Cloud ファースト パーティ サービスである
- Lift & Transform 事例
- NW 構成パターンを複数用意し、アプリによって選択可能とした
- GCVE 移行 (Re:host)
- GCVE移行専用のPrivate Cloud
- モダナイゼーション (Re:platform)
- M2VMなどで、Google上のVMに移行するためのVPC
- モダナイゼーション (Re:architect)
- Google Cloudのサービスに変換して利用できる環境
- GCVE 移行 (Re:host)
- NW 構成パターンを複数用意し、アプリによって選択可能とした
マイグレーション サービスを活用して VM の IP アドレスもそのまま Google Cloud へ移行した話
日本特殊陶業株式会社 南川 慎一 氏
Google Cloud 堂ノ脇 梓 氏
- 日本特殊陶業株式会社での課題や解決策
- 移行を検討した際の現状と課題
- オンプレミス仮想基盤の老朽化 / リソース枯渇
- 年単位で対応、リソース引き渡し相手の選別
- リフトへの技術的課題
- 昔からのシステムなので、担当者もわからない
- ベンダーもいなくなっている
- IPをハードコーディング
- Google Cloud の知識 / ナレッジ不足
- オンプレミス仮想基盤の老朽化 / リソース枯渇
- 最初のチャレンジ
- GCVE（Google Cloud VMware Engine）でリフト
- 期待したほどリフトせず
- Google側より、M2VM ＋ Hybrid Subnet を使った移行方式を提案
- GCVE（Google Cloud VMware Engine）でリフト
- M2VM ＋ Hybrid Subnetの検証
- Hybrid Subnet の検証
- 本利用のVPCと接続し検証
- Google Cloud -> オンプレミスの全通信が不通に
- 本利用のVPCと接続し検証
- Hybrid Subnet の再検証
- Step別に分けて検証
- 1回目と同事象発生も、すぐに解決
- Step別に分けて検証
- M2VM との検証
- Hybrid Subnet の検証
- Google Cloud -> オンプレミス不通の詳細
- 原因
- Cloud Router へのアドバタイズ設定追加
- Google Cloud側に、（オンプレミスと同じ？）サブネット「10.x.x.0/22」を作成
- 10.x.x.0/22 の IP アドレスは”Google Cloud 内に存在する”とCloud Router が判定し、オンプレ側にルーティングしない
- 解決策
- BGP設定の中に「カスタム学習ルート」という設定
- 「10.x.x.0/22」を設定すると、Google Cloudにない場合はオンプレ側を見るようにできる
- BGP設定の中に「カスタム学習ルート」という設定
- 原因
- 移行作業の流れ
- 事前準備
- ユーザ説明＆作業日調整
- 作業前日までに、M2VM にて移行対象サーバのレプリケーション実施
- マストではないが、当日の停止時間が短くなる
- 実施していた場合は1時間程度。未実施の場合は倍以上
- マストではないが、当日の停止時間が短くなる
- 作業当日（大体半日程度）
- オンプレ L3 スイッチの Static Route 追加
- Cloud Router へのアドバタイズ設定追加
- 新規サブネットの場合はサブネット追加とカスタム学習ルート追加
- M2VM を使った移行実施
- アプリケーションの動作確認
- Backupや監視設定、等々
- 事前準備
- 実施しての課題
- 停止が必ず必要。無停止のシステムはどうするか
- IPアドレスでは、オンプレにあるのかGoogle Cloudにあるのか判別できず
- NW 構成上、Hybrid Subnet が難しいセグメントがいくつもあることが判明
- 経路上のすべてのスイッチにProxy ARPの設定が必要だが、それをOFFにしている環境がある
- DB等のライセンス問題（Oracleなど）
- ESX単位でライセンスを購入しており、GCE用に追加でライセンス費用が掛かる
- 30 TB 超えのサーバ
- レプリケーションが失敗する（原因不明）
- M2VMのカットオーバー機能の完了に9時間以上かかる
- 移行先 Zone を一つにしていたためリソース枯渇
- 移行を検討した際の現状と課題
DAY 2 セッション
データ分析
使われないダッシュボードを産まないためのプロジェクト マネジメント
Sansan株式会社 坂口 遥 氏
- ダッシュボード構築におけるよくある失敗
- できるもの
- 積み上がる使われているかわからないダッシュボード
- 積み上がる似たようなテーブル
- それに伴い、肥大化する運用保守コスト
- それぞれ、良くしようとしている
- 現場ではダッシュボードを使って何かしたいという思いはある
- ダッシュボード企画者は良いものを届けようと努力している
- 実装者は依頼にスピーディーに答え、依頼内容を忠実に実装する
- 容易に負債化してしまう理由
- BI ツールの発展によってダッシュボードを作るハードルは低下
- 一方、ダッシュボードそのものや裏側のデータライフサイクルは、サービスやプロダクトよりも長いことがある
- 売るサービス・プロダクトが変わっても、モニタリングする指標は一定で普遍的
- こうならないために
- ダッシュボードはデータと合わせた一つのプロダクト と捉え、ソフトウェア開発の御作法などを取り入れていく
- できるもの
- ダッシュボード構築を成功に導くKey Factor
- ステークホルダー マネジメント
- キーマンの見極めと巻き込み
- 意思決定者、エバンジェリスト、データ利活用に関心が高い人
- トップダウンアプローチが速い
- 偉い人に気に入られたら勝ち
- 「その意思決定はどのダッシュボードを見て決めたの？」と、マネージャーがデータを見る文化の浸透に寄与
- キーマンの見極めと巻き込み
- アジャイル ソフトウェア開発
- Quick and Dirty を許容し、PDCA を高速で回し、不確実性を極小化
- インサイトが得られるダッシュボードを突き詰める
- 序盤はビジュアライズは不要
- 表形式だってよい
- Quick and Dirty を許容し、PDCA を高速で回し、不確実性を極小化
- ダッシュボードのアウトカム定義
- ユーザーのアクションに繋がっているか
- アクションから、アウトカムが生み出せているか
- アウトカムが生み出せていないのであれば改善の余地あり
- 作った後もブラッシュアップ
- ユーザーとの定期的な会話、フィードバック
- どんなアクションに、アウトカムにつながるのか
- 「あれが見たい、これが見たい」で作ってはいけない
- ステークホルダー マネジメント
- ダッシュボード構築における5 つの Phase
- Phaseに、ツールは異なっていてもよい。最適なツールを用いる
- 柔軟かつ保守性の高いバックエンド群を選定
- Phase.0 探索、現状調査
- 想定ユーザーにヒアリング
- 何かしらの数値を見て意思決定をしている
- 現場の（難解な）表などにこそ、大きなヒントあり
- 現場の数値化・見える化している業務を観察
- どこからデータを持ってきている
- どこに張り付けている
- どんな集計をしている
- どう使われている
- 誰かに見せている
- 施策の検討に使われている
- 想定ユーザーの、周辺の方々にもヒアリング
- 想定ユーザの前工程、後工程にかかわっている方々の情報も重要
- 前・後もカバーできるような種が見つかることも
- 想定ユーザーにヒアリング
- Phase.1 要求定義、要件定義
- 決めるべき要素
- Why/So What：見た上でどんなアクションを取るのか？
- Who：誰が見るのか？
- When：いつ見るのか？
- How Much：どれくらいの頻度で見るのか？
- How：どのような形で見るのか？
- What：何の数値を見るのか？
- 以下のケースでは、上記6つのケースは異なる
- 毎日の朝会で、営業活動をしているメンバーの行動量を把握し、芳しくないメンバーにフォローしたい
- プロダクトが正常に動作していることを確認したい、異常値を把握したい
- プロダクトの方向を確認するために、全体の利用状況を把握したい
- 6つの要素は、最初からきれいに定義する必要はない
- 決めるべき要素
- Phase.2 PoC 開発、仮説検証
- Quick and Dirty を一定許容し、高速で PDCA サイクルを回していく
- このPhaseは、Google Sheets や Looker Studio など変更が容易なものを採用し、仮運用する
- 中間層のSQLは可読性高く
- 一旦巨大でもよし
- Phase.3 試運転、データ モデリング開始
- ユーザーからフィードバックをもらいつつ、DWH の要件を見極めていく
- データモデリングを行うことによって、ELT の柔軟性/保守性が増していく
- Phase.4 本番稼働、保守
- 本番稼働する前に、データ加工の責務と範囲を明確にする
- 可能な限り、データの加工処理は ETL/ELT に寄せた方が保守性が高くなる
- Looker 側で大きなSQLを許すと、（どこで加工されたかわからなくなり）見通しが悪くなる
- Phase.0 探索、現状調査
おわりに
AWSと同様にAIが多かった印象ですが、自分の興味は移行とかデータ周りなので、そちらばかりのまとめになってしまいました。
この記事がどなたかのお役に立てれば幸いです。
Discussion