この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。
「Google Cloud Day: Digital ’22」が2022年4月19日~21日に開催されました。 本ブログはイベント内のセッション「メルカリ Shops を支える Google Cloud の技術」のレポートブログです。
セッション概要
概要
メルカリ Shops のサービスを支えている Google Cloud の各種技術を中心に、技術アーキテクチャについて話します。 Cloud Run や Cloud Workflow, Vertex AI などの技術をどのように活用しているか、サーバーレスアーキテクチャの課題やその解決、今後の展望などを含みます。
取り上げる主な Google Cloud 製品 / サービス
- Vertex AI (旧 AI Platform)
- Cloud Run
- Cloud SQL
スピーカー
株式会社ソウゾウ 名村 卓 さま
メルカリShops について
- C2C フリマサービスのメルカリ内で B2C 事業者向けの販売機能を提供するサービス
- スマホひとつでネットショップがかんたんに作れるのが特徴
- サービスを支えるほぼすべてのシステムを Google Cloud 上で構築・運用している
使用している Google Cloud の技術と全体像
- 多くのコンポーネントが Cloud Run で稼働している
- アプリケーションは Web を中心とした技術スタック
- Next.js を使ったフロントエンド向けのサーバーや NestJS を使った BFF のサーバーがある
- ビジネスロジックはマイクロサービスのアーキテクチャで構成されている
- それぞれのマイクロサービスは gRPC を利用して通信している
- マイクロサービスごとに独立した Cloud Run のアプリケーションで稼働している
- CloudSQL はマイクロサービスごとに独立したインスタンスで稼働している
- 検索インデックスの作成などは Dataflow で行なっている
なぜサーバーレスなのか
- システムがシンプルになる
- 関心ごとがよりビジネスロジックに近くなる
- 運用負荷の軽減
- エンジニアがクリエイティブな発想に時間を費やすことができる
Cloud Run の選定理由
- コンテナベースで稼働すること
- Cloud Functions のようにコードだけで動くような抽象度の高いソリューションもあるが、コンテナベースの方がより柔軟な実行環境が提供できる（言語、フレームワークの制約 etc...）
- ローカル環境の構築も容易
- gRPC のサポート
- IAM のサポート
- Auto Scale によってスケールアウト・スケールインがほぼ自動 etc...
Cloud Run の活用
- Service To Service Authentication
- Cloud Run にIAM設定を行い gRPC の呼び出しにヘッダを付加することでサービスアカウントによる認証を実施している
- 参考：サービス間認証
- gRPC によるコールをサポートしていない技術のため、envoy による gRPC Proxy を Cloud Run 上で稼働して、通常の HTTP コールを経由した呼び出しをサポートしている
- リビジョンごとの Traffic Control 機能を活用して Github の Pull Request ごとの独立した環境を構築して開発中の動作確認を円滑にしている
- プロダクション環境へのデプロイ時にエラーレートやエラーログを監視しながらトラフィックをロールアウトする機能を実装している
サーバーレスを支援する各種Google Cloud の技術
Pub/Sub
- 多くの場面で活用している
- ステートレスなロジックに対してイベントを通達するためのメッセージングシステムとして活用
- ビジネスロジックに起因するイベントを登録することで様々なビジネスイベントに起因したロジックを柔軟に拡張できる
Cloud Scheduler
- 指定した時間や頻度をベースに HTTP エンドポイントをコールすることができる
- メルカリShops では gRPC Proxy を経由してマイクロサービスのビジネスロジックを定期的に実行している
Workflows
- 複雑な処理のワークフローをコントロールすることができる
Cloud SQL
- バックアップやパフォーマンスモニタリングをサポートしていて、複雑な知識が設定が必要ない
- データベースに関するオペレーションを意識する必要がない
Vertex AI
- マシンラーニングのトレーニング処理をサーバーレス化
- MLOps における運用負荷を軽減できる
Google Cloud におけるサーバーレス構成の現実
- インスタンス等の管理をしなくてもほとんどのアプリケーションを実現できるソリューションが整っている
- マシンラーニングに関わる部分がかなりサーバーレス化できた
- ステートレスな設計を意識する必要はある
- よりクラウドネイティブで、かつクラウドプラットフォームの技術に依存した設計になることもある
今後のアプリケーションの展開
- Cloud Run を主体とした構成を継続しつつより運用負荷をおさえたアーキテクチャを実現していきたい
- ステートフルな処理を含めたすべてのコンポーネントのサーバーレス化の実現
- マルチリージョン化によるさらなる高可用性の実現
Q&A（抜粋）
Q. Cloud Run で実現できなかった、しにくかったところは？
A. 当初は Cloud Run がリクエストを受け付けている間だけ CPU が動くという制約がありバックグラウンドの処理が止まってしまうことがあった（今は CPU を常に ON にする機能が実装されたので解消済み）。
時間がかかる処理が向いていない点については別のコンポーネントを組み合わせて回避している。
Q. Workflows を使った方がアプリケーションでロジックを実装するよりも楽になる？
A. Workflows を使うとマイクロサービスをつなぐロジックを定義としてワークフローをデプロイできる。マネージドサービスに倒すことで運用面でメリットもある。一方で複雑な処理になるとコードで書いた方がいい側面もある。
Q. PullRequest Environment で DB などの周辺のサービスやルーティングも含めて独立させているか
A. PullRequest ごとに Cloud Run と各マイクロサービスを立ち上げて独立性を保つようにしている。DB に関しては開発環境では同じインスタンスを参照している。
Q. Cloud Spanner ではなく Cloud SQL なのは理由があるか
A. Cloud Spanner も候補にあったが、利用予定のデータベースのフレームワークが Cloud Spanner に対応していなかったので、開発のしやすさを優先してPostgres互換の Cloud SQL を選択した。
Q. サーバーレス構成におけるセキュリティ対策の中で不正アクセスへの対策はどうしているか
A. IAMの設定ができるのでどのサービスアカウントや Google アカウントが Cloud Run をコールできるかの制約をベースにコントロールしている。
Cloud Run 利用における他のセキュリティ対策として Google Cloud の中からのみアクセスできるようにしたりロードバランサーを前段に置くことで Cloud Armer を設定してWAF機能をつけることもできる。
感想
Cloud Run は Google Cloud の中でも利用者の多いサービスというイメージでしたが、かなり使いこなされていて勉強になりました。
また、アーキテクチャや各サービスの選定理由がはっきりしていて設計する際のスタンスとしてとても理想的だなと感じました。
アーカイブが公開されていますので、気になった方は視聴してみてはいかがでしょうか。
以上、CX事業本部MAD事業部のYui(@MayForBlue)でした。
2
