GCP native なクラウド移行 〜 2000年創業エムスリーが挑む 大規模クラウド移行の舞台裏 #2 〜 2020/12/03　高島 亮祐

自己紹介 ● 高島 亮祐（@rst76） ● 2019/01- エムスリー 基盤開発チーム ○ 認証やメール配信など共通サービスの開発運用 ○ 最近はクラウド移行がメイン ● 最近学んだこと： メダカは秋でも卵を産む（狭い部屋がさらに狭く…）

エムスリーの標準的なクラウド移行 ● Web サーバ、AP サーバは Fargate に ● DB は Aurora や RDS に ● ALB、Route 53、S3、Cloud Watch、Lambda ● 基本に忠実な構成

今回移行したサービス ● ユーザーのアクティビティをトラッキング ○ ページに埋め込まれた画像リンクからアクセス ○ アクセスを記録 ○ 実際の画像の URL にリダイレクト ○ 画像を取得 ● アクセス増加に伴って性能問題の 一因となっており、クラウド化 ● よし、GCP でサーバーレスだ トラッ キング コンテ ンツ ① ② ③ ④ ① ② ③ ④

GCP アーキテクチャ（旧） オンプレミス ブラウザ ロード バランサ Webサーバ apache アップ ローダ （随時） ログ Webサーバ apache DB アップ ローダ （日次） アップ ローダ ログ BigQuery 他のサービスと共用で 相互に悪影響… 移行にともない この経路は廃止

アーキテクチャ（新） ブラウザ GCP Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Run （随時） （日次） 基本的な流れは単純 → ぜんぶ GCP でいけそう 既存の連携処理と並行稼働が 必要で構成が少し複雑に

Cloud Run ● 役割はログ出力とリダイレクトなので nginx だけのコンテナ ● Kubernetes の管理はしたくないので、フルマネージドを選択 ● Cloud Pub/Sub への連携はログ出力先を設定するだけ ● とても楽だが注意点も ○ 1 つのコンテナインスタンスが受信できるリクエストは最大 80 ○ リクエスト数や連携するログ容量も従量課金 GCP Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Run （随時） （日次）

Cloud Pub/Sub ● 安定性のために導入 → 非常に安定して稼働しており安心 ● at-least-once の仕様が問題になる場合は対応が必要だが、 今回は対応せず GCP Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Run （随時） （日次）

Cloud Dataflow ● 単純なデータ連携なら Google の提供するテンプレートをそのまま 利用可能 ○ 例：BigQuery のスキーマに則った JSON が Cloud Pub/Sub にある ● 今回はデータ加工のために実装する必要があった ● データ連携という要求の単純さと比べると、実装は面倒 ○ Google の提供するテンプレート（Pub/Sub Subscription to BigQuery）は複雑（Apache Beam、AutoValue など独特の技術） ○ 実装しなくてすむよう事前にデータを加工しておく方がいいかも GCP Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Run （随時） （日次）

BigQuery ● BigQuery to BigQuery の連携に、Scheduled Query を利用 ○ SQL を定時起動するだけなので、管理は非常に容易 ○ 通常のデータ連携では、あまり出番がないかも ○ エムスリーでは、GCS / S3、既存の RDB、スプレッドシートなどの 外部データソースからデータを取り込むのにも使われている GCP Cloud Pub/Sub Cloud Dataflow BigQuery Cloud Run （随時） （日次）

料金 Cloud Run の CPU (同時実行設定に誤り…) Cloud Run の リクエスト数 ログ容量 Cloud Dataflow の CPU フロントエンド（Cloud Run の部分）を AWS にした類似サービスも

まとめ ● GCP でも問題なくクラウド移行できた ● 細かい制約に注意が必要 ○ Cloud Run はリクエスト数に対して従量課金 ○ Cloud Run の同時接続数 ○ Cloud Dataflow の実装要否 ● 基盤開発チームはメンバを募集中です！ （12/16 に採用説明会を予定）