エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

Cloud Run で NEWS ランキング API を作った話

エンジニアリンググループ AI・機械学習チームの岩月です。

これは エムスリー Advent Calendar 2019 の12月8日の記事です。

今回は、先日ついにGAになった Cloud Run を利用して、 NEWS のランキング API を作成した件についてまとめます。

NEWS ランキング API の役割

エムスリーでは医療関連のニュースをはじめとする様々なニュースを扱っており、そこでのユーザーの行動ログは BigQuery にストリームで格納されています。 今回作成した NEWS ランキング API の目的は BigQueryにたまったログを集計したPVランキングを提供する ことです。

Cloud Run

比較的新しいサービスなので簡単に Cloud Run1 の紹介をします。 (複数のプラットフォームを選択できますが、今回は Cloud Run (フルマネージド) を対象としています。)

Cloud Run はマネージドのコンテナ実行環境です。ざっくりとした流れは、 HTTP 経由で呼び出されるコンテナをデプロイすることでエンドポイントが自動で作成され(HTTPSも対応してくれる)、すぐに利用できる状態にしてくれます。加えて、同時実行数によって0からNまでのスケールも可能というイカしたサービスです(もちろん制限や困りどころもあるので後述します)。

構成

今回作成したシステムのアーキテクチャは次の図のようになっています。

Batch 処理用と API 用の Cloud Run とデータのロードに必要なコンポーネントから構成されています。API部分には最近 チーム内で活用をすすめている Goa という Go のフレームワークを用いています。 具体的な Goa の活用については エムスリー Advent Calendar 2019 4日目の笹川の「Kubernetes上でのGoによるシンプルなAPIの開発と、その効率化のためのcookiecutter templateを作った話」 を読んでみてください。

f:id:kaito2-2:20191206211210p:plain
アーキテクチャ

処理のフロー

具体的な処理のフローは次のようになっています。

  1. Cloud Scheduler が Batch 用の Cloud Run をキック
  2. Batch 用の Cloud Run は以下の処理を実行
    • BigQueryのデータを集計し、結果を Cloud Storage へ格納
    • Cloud Storage から Cloud SQL へデータをロード
  3. 2でロードされたデータを API 用の Cloud Run がサービング

なぜこの構成になったか (Cloud Run を採用してよかった点)

運用のコストを減らしたかった

AI・機械学習チームでは多数のプロダクトを開発しておりデータエンジニアの人数を考えるとインフラの運用にかけるコストを少しでも減らしたいと考え、マネージドサービスを積極的に活用していく方針をとっています。そういった意味では Cloud Run によってサーバを意識せずに済むので助かっています。

GKE (Kubernetes) への移行がしやすい

このシステムの開発を開始した当初からチームのインフラを GKE (Google Kubernetes Engine) への移行が計画されていました。 Cloud Run の他には Cloud Functions や App Engine なども選択肢にありました。しかし、GKE への移行プランを考えるとコンテナを実行できる Cloud Run が適当だと考えました。

Cloud Run を使いたかった

正直あります。

Cloud Run を採用したことによる制限

Cloud Run の紹介でも書いたとおり、とても魅力的なサービスですがいくつかの制限があります。その中でも開発のなかで特に悩んだ点を紹介します。

Keep-Alive ができない

コンテナの思想から考えると当然だとも思えますが、Keep-Alive ヘッダーは無視されます。内部 API として使う際には TLS ハンドシェイクなどのオーバヘッドを抑えるために Keep-Alive したいというニーズがでてくるので悩みどころです。

コールドスタート

AWS Lambda(ちょうどProvisioned Concurrency for Lambda Functions が発表されましたが) などの 0スケールするサービスにはついてまわる問題であるコールドスタートは Cloud Run でも発生します。ping を送るなどの工夫によってある程度は改善されますが、それでもスケール時には数アクセスのレスポンスタイムが 1000ms を超えることがあります。

まとめ

上で書いたような制限はあるものの、低コストでAPIを構築・運用できるメリットは大きいと考えています。 Kubernetes のクラスターを作るほどのワークロードではないが、Batch を定期実行してその結果を API で提供したいというシーンはそこそこあると思います。そんなときは Cloud Run を用いて Batch と API をどちらも作成してしまうのもよいかも知れません。

We're hiring!

エムスリーでは最新のクラウド技術を活用して開発の効率化を進めています。 自分ならもっとクラウドを使いこなせるぞ!! 効率化できるぞ!! という方 是非お待ちしています!

jobs.m3.com

  1. https://cloud.google.com/run/↩