Web APIでのログ収集におけるCloud Runの利用

詳細は「技術的負債解消LT会で「データ基盤の負債解消のためのリプレイス」を発表しました」に記載しています

ツール導入前の課題

• AWS上のデータ分析基盤（収集・蓄積等）と、Google Cloud上のデータ活用基盤（情報推薦・機械学習等）の2つあった
• AWSの分析基盤は負債が蓄積していたため、2022年ごろから、Google Cloudへのリプレイスを進めていた
• 特に、各種ログ（Webログ、ネイティブアプリログ、メール開封ログなど）の収集を行うシステムは、Elastic Beanstalk, Lambdaを中心に構築されていたが、構成が複雑で開発効率の低さが課題だった
• メインのWebログとアプリログはGoogle Analytics 4に移行したが、2024年に、残りのログの収集システムをGoogle Cloudでリプレイスする必要があった

どのような状態を目指していたか

• データ基盤で利用技術が統一されている
• 多くの部分がマネージドでメンテナンスが容易である
• 収集するログの追加を行いやすい

• Google Kubernetes Engine（Autopilot）
• Google App Engine
• Google Cloud Storage（画像などのファイルを配置し使用状況ログを取得）

• フルマネージドで、スケールイン・スケールアウトが高速であること
• コードサイズなどのプラットフォーム上の制約が少ないこと。DockerやFastAPIを選択できること
• POSTメソッドでのログ収集もできること
• カナリアリリースが容易であること
• パフォーマンスモニターのダッシュボード等、利便性が高いこと

• Cloud Runは機械学習モデルのサーブなどの目的でデータ活用基盤で2020年ごろから利用しており、一定の知見があった

改善したかった課題はどれくらい解決されたか

• 利用技術の統一により開発体験や開発効率の課題は概ね解決されたと考えている

どのような成果が得られたか

• インフラストラクチャーではなくアプリレイヤー、ログやデータ連携そのものに集中できるようになった
• 2025年中に、新たなSaaSからのログ取得機能の追加を予定しているが、実装・検証が必要な項目が減った
• Google Analytics 4との連携など、他の用途でもCloud Runの利用を広げている

• スケールアウト等を含む性能評価をどの程度実施するか。アプリケーションでの工夫により大きな問題はでないと判断しシビアな事前評価は行えていない
• CloudRun、Pub/Sub、BigQueryのそれぞれの間でのログ欠落の監視。現在も一部未解消
• カスタムドメインのマッピングで、従来、利用してきたCloud Runのドメインマッピングを使うか否か。ロードバランサーが不要で容易だが、プレビュー状態が続いており、レイテンシーがやや大きい

Cloud RunはWeb API以外にも、Cloud Runジョブ、Cloud Run関数などの機能追加により、様々な用途で利用できるため、Cloud Runをファーストチョイスとし、それで足りない場合に、徐々に他サービスを導入していくのが良いのでは、と思います

• 収集するログの追加
• Cloud Runのドメインマッピングからの移行、Cloud Armorの検証
• Recommenderを利用した設定の最適化
• イベントドリブンなログ収集での活用や、Cloud Runジョブの検証、オンライン機械学習システムの検証など