目次
Cloud Run servicesで構築する推薦API
参考になった
21
会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
レビュー投稿日の情報になります
株式会社タイミー / ozeshun
メンバー / データサイエンティスト
最終更新日投稿日
| ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|
| 10名以下 | 2023年3月 | B to C |
| ツールの利用規模 | 10名以下 |
|---|---|
| ツールの利用開始時期 | 2023年3月 |
| 事業形態 | B to C |
アーキテクチャ
アーキテクチャの意図・工夫
主にGoogle Cloudで開発をしているデータサイエンス組織（以下DS組織）が保守運用をしやすくするために、ML Pipelineと推薦APIをGoogle Cloudに閉じた形で構築しました。
導入の背景・解決したかった問題
導入背景
導入当時の状況
弊社ではアプリ本体の基盤はAWS、データ基盤はGoogle Cloudを使っています。 導入当時はアプリ本体を開発しているプロダクト組織とDS組織がやや組織として遠い状況下で、推薦APIの保守運用をDS組織で担当する事が決まりました。
どのような状態を目指していたか
API基盤への知見がそれほど高くないDS組織でも保守運用が出来て、ABテストの設定などのAPI内部のコードの変更をDS組織に閉じてスピーディーにデプロイ出来る事を目指しました。
比較検討したサービス
- GKE
- AWS Lambda
比較した軸
- DS組織がメインに開発している基盤か
- DS組織単体でも保守運用が可能か
選定理由
- DS組織が主に開発していたGoogle Cloudのサービスであること
- 保守運用の容易さ
- 既にCloud Runでの開発経験がDS組織であったこと
導入の成果
どのような成果が得られたか
- DS組織に閉じて運用しているので、高速なABテストが実現出来ている
- プロダクト全体に影響を与えるような障害はほとんど発生していない
導入時の苦労・悩み
- Cloud Run自体のレイテンシ、可用性が安定しないタイミングがありこちら側ではどうしようも出来ない状況がたまに発生すること
- 推薦APIのABテストの振り分けロジックをどこで（Load Balancer or リバースプロキシ or Cloud Run）実現するか
導入に向けた社内への説明
上長・チームへの説明
プロダクト開発組織がAWS、データ組織がGoogle Cloudというマルチクラウド構成という前提で、推薦APIの運用（ABテストのロジック含む）をデータ組織（特にDS組織）が行っていく上で
- DS組織で完結して高速に実験を回すことができる
- 負荷対応等にあまり工数を割く必要がない、サーバーレスなサービスである
- コンテナベースなので、開発環境と本番環境の環境差異を最小限に抑えることができる
- これまでメンバーが開発・運用経験のあるサービスである
以上の点から上長・チームに説明し、Cloud Run Servicesが選定されました。
活用方法
よく使う機能
- Cloud Runコンソールでのメトリクスの可視化機能
→ サービス全体のレイテンシ、エラー率を把握するのに使用しています - サイドカーでのデプロイ機能
→ Datadog AgentをサイドカーとしてデプロイしてAPMとして運用するのに使用しています
ツールの良い点
- インフラ管理の煩雑さから解放され、アプリケーション開発に集中することができる
- マルチコンテナ構成でのAPMの導入が容易に出来る
- トラフィック量に応じてインスタンス数を調整してくれるので、コスト効率が高い
- Terraform, YAMLによる構成管理が容易である
ツールの課題点
- サービス自体のレイテンシ、可用性が安定しないタイミングがある
- リソース確保がCloud Providerに依存する形なので、どうしてもサービスが落ちてはいけない状況時、最低インスタンス数を手動で調整する必要がある
- VPC内のリソース（Memorystoreなど）と通信する時には別途VPCアクセスコネクタを構築する必要がある
今後の展望
以下の事項の実施を検討しています。
- 本番環境デプロイ時にトラフィックの割り当てを段階的に増やせるような設定をする
- タイムアウト時のプロダクト本体のRails APIと推薦APIの通信方法の見直し
株式会社タイミー / ozeshun
メンバー / データサイエンティスト
よく見られているレビュー
株式会社タイミー / ozeshun
メンバー / データサイエンティスト
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法