コンテンツに移動
Google Cloud

ゲスト投稿 : MLB ファン向けの新サービスを Container Engine で構築した Loot Crate

2017年8月19日
Google Cloud Japan Team

編集部注 : Loot Crate は、ゲームやポップ カルチャーなどのファンの間ではよく知られた企業で、テーマごとのお楽しみボックスを 65 万人の会員に毎月届けています。同社はバックエンド サービスを Heroku で構築していますが、新たに手がけた “Sports Crate” サービスでは Rails アプリを Google Container Engine でコンテナ化し、Jenkins で継続的デプロイを行っています。本稿ではその概要を紹介しましょう。

私たち Loot Crate は 2012 年の創業以来、ファン向けサブスクリプション ボックス分野の世界的なリーディング企業として事業を展開しています。エンターテインメントやゲーム、ポップ カルチャーなどのクリエイターとパートナーシップを組み、ファンに向けて毎月テーマごとのお楽しみボックスを配送したり、インタラクティブな体験やデジタル コンテンツをプロデュースしたり、オリジナル ビデオ作品を撮影したりしています。創業から 5 年で、1,400 万以上のお楽しみボックスを世界 35 地域のファンに届けました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/89473.max-1600x1600.png

2017 年初頭、私たちは MLB(メジャー リーグ ベースボール)ファン向けの Sports Crate サービスを立ち上げることを任されました。2017 年の MLB シーズンが幕を開ける(開幕日は 4 月 2 日)、ほんの数か月前のことです。そのため、できるだけ早くサイトを立ち上げ、興味のある人からのメールを収集する必要がありました。

また、私たちのウィッシュ リストにも、トラフィックの増加に応じたサイトのスケーリングや、自動的なゼロダウンタイム デプロイ、秘密情報の効果的な管理、Docker イメージのメリットの活用などが含まれていました。

それまで当社のサービスは Heroku で構築していましたが、Sports Crate では Container Engine を試すことにしました。Container Engine を使えば、トラフィックのピーク時にもアプリがスケールしやすく、Google にログインするだけでリソースが管理でき、コスト管理も容易になると考えたからです。

Jenkins による継続的デプロイ

私たちのゴールは、シンプルな git push コマンドを使って Container Engine にアプリをうまくデプロイすることです。そこでまず、自動スケーリングする 2 ゾーンの Kubernetes クラスタを Container Engine 上に作成したうえで、クラスタに自動デプロイする方法を模索しました。

多くの調査を行い、Google Cloud のソリューション アーキテクトである Vic Iglesias 氏とも話し合った結果、Jenkins Multibranch Pipelines を採用することにしました。Kubernetes での継続的デプロイについて解説したガイドに従って操作すると、すぐにクラスタ内で Jenkins が稼働し、デプロイを操作できる状態になりました。

次に、Container Engine へのデプロイに向け、Rails アプリの Dockerfile を作成します。ここでは構築時間の短縮を図るため、Ruby とインストール済みの gem を使って独自のベース イメージを作成しました。また、Jenkins が Docker イメージを構築するときに、アセットをプリコンパイルして Google Cloud Storage にアップロードするための Rake タスクも作成しました。

Dockerfile を作成したら、Jenkins Pipeline をセットアップして Docker イメージを構築し、Google Container Registry にそのイメージをプッシュして、Kubernetes とそのサービスを自社の環境にデプロイします。GitHub ブランチ名に基づいた switch 文を使っている GitHub リポジトリに Jenkinsfile を置き、どの Kubernetes のネームスペースにデプロイするかを選択します(当社には、3 つの QA 環境と、ステージング環境、本番環境があります)。

Jenkinsfile は、GitHub からコードをチェックし、構築した Docker イメージを Container Registry にプッシュして、(成功と失敗を確認しながら)さまざまなデータベース マイグレーションを実行する Kubernetes のジョブを稼働し、テストを実行します。そして、アップデートされた Docker イメージを Container Engine にデプロイし、そのステータスを Slack にレポートします。このプロセス全体にかかる時間は 3 分未満です。

ローカルの開発環境で秘密情報の管理を改善

私たちは次に、ローカル環境での開発をより簡単で安全なものにすることに取り組みました。

私たちは開発をローカルで行い、Heroku 設定または UI に追加する環境変数を使って Heroku ベースのアプリをデプロイします。これはつまり、Heroku にログインできる人や Heroku へのアクセス許可を持つ人であれば、誰でも環境変数を参照できるわけです。

Sports Crate サービスでも同様に環境変数を使用しますが、より安全に扱いたいと考え、アプリが簡単に利用できる Kubernetes Secrets に環境変数を置きました。これにより、隠す必要のある秘密の情報をコードベースや開発者の PC から守ることができます。

ローカルの開発環境では Railtie を使った環境変数を利用し、開発環境の秘密情報を読み出して解析を行い、Rails 環境に配置します。これで開発者は、リポジトリに “cd” し、アプリがスタートする前に Kubernetes Secrets のプルダウンにて “rails server” や “rails console” を実行できるようになります。

TLS の解除と負荷分散

効果的に TLS 解除と負荷分散を行うことも必要でした。そこで、Kubernetes の Ingress リソースNginx Ingress Controller で利用することにしました。というのも、Google Cloud Platform(GCP)の Ingress Controller では、HTTP から HTTPS への自動リダイレクト機能が利用できないからです。私たちの証明書で設定された Ingress リソースと、固定 IP を持つサービスの裏で稼働している Nginx Ingress Controller を用意すれば、私たちのアプリに外部からアクセスできるようになります。さあ、だんだんとまとまってきましたね!

自動スケーリングとモニタリング

インフラの基本的な部分が GCP 上ですべてそろったら、今度は自動スケーリングやモニタリング、さらにはデプロイの実践やログに関する QA チームの教育に着手しました。

ポッドの自動スケーリングは Kubernetes の Horizontal Pod Autoscaling を実装することで対応しました。これは、CPU の使用率を確認し、アプリへのトラフィックが増えるとポッドを自動的にスケーリングします。

モニタリングについては、Datadog の Kubernetes Agent を使用し、重大な問題を検知するための指標を設定して PagerDuty にアラートを送るようにしました。

ロギングには Stackdriver を使用することにしました。Stackdriver Logging コンソールを使い、情報が必要なアプリ、ネームスペース、ポッドなどを適切にドリルダウンする方法を QA チームに教えました。

サービス始動

サービス開始が目前に迫る中、私たちは新しいアプリの負荷テストを実施しましたが、大量のトラフィックをうまくさばいていたのには驚きました。ポッドは必要に応じて自動的にスケーリングしていましたし、QA チームは Jenkins Multibranch Pipelines による継続的デプロイが大変気に入ったようです。全体的に見て、Container Engine は要件をすべて満たしており、私たちのほうも 1 か月足らずで新サービスを立ち上げることができました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Pzqmp3J81Xw6TgHCCPTTagmsewtwNOprmOGGQNURHP.max-1300x1300.PNG

次のプロジェクトとしては、他の Rails モノリシックアプリを Heroku から Container Engine に分離マイクロサービスとして移行させ、最新の Kubernetes 機能を利用できるようにします。ただでさえ強力な Rails アプリが、Container Engine への移行によってさらにパワフルになることを、私たちは楽しみにしています。

* この投稿は米国時間 7 月 12 日、Loot Crate の DevOps 担当 Director である Greg Brown によって投稿されたもの(投稿はこちら)の抄訳です。

- By Greg Brown, Director, DevOps, Loot Crate

投稿先