同じサービスをECS と OpsWorks で運用してみた

JAWS-UG コンテナ支部 #2

自己紹介

市川　純リクルートマーケティングパートナーズ

@sparkgene

担当サービス• リクナビ進学アプリ• 料理サプリ• その他新規サービス

業務内容• AWS を使ったサービスのインフラ構築・運用• サーバサイドの開発

社内向けの知見共有サービス

システム構成

ElastiCache

RDS

EC2インスタンスELB

Amazon S3

Elastic Transcoder

開発環境を用意

開発環境開発環境では docker-compose を使ってるサーバサイドエンジニアもフロントエンジニアも、数行のコマンドで環境構築が出来る

$ docker-compose build$ docker-compose run rails rake db:create$ docker-compose run rails rake db:migrate$ docker-compse up

開発環境Nginx 、 Rails 、 Redis 、ストレージのコンテナが起動する

本番環境

ElastiCache

RDS

EC2インスタンスELB

Amazon S3

Elastic Transcoder

ここどうするか

AWS で Docker なら ECS でしょ！

ECS ちょっとツラそう。。そもそも Docker 初心者

ECS でステージングの構築を進めてたが、本番運用にはまだ作りこみが必要

最初のリリースは使い慣れた OpsWorks で行こう

OpsWorks のいいところrecipe を書けば同じサーバを簡単に立ち上げられる

デプロイがボタンひとつで簡単

専用のモニタリングがある

ライフサイクルイベントを使っていい感じに管理出来る

本番環境

ElastiCache

RDS

EC2インスタンスELB

Amazon S3

Elastic Transcoder

AWS OpsWorks

Amazon ECS 使うよ！

ECS のいいところDocker 使える！

開発環境も本番も同じ Docker イメージが使える（一部は）

Docker イメージからコンテナを起動するので速い

最近、クラスタ、サービスの単位でメトリクスが見れるようになった

ECS のつらいところDocker イメージを管理する Docker レジストリが必要デプロイ（コンテナの入れ替え）を自動化させるのが大変

コンテナの起動監視、ロールバックなど自前でスクリプト書かないとダメ

そもそも、 docker build 、 docker push 、 docker pullが遅い pull した後はコンテナの起動は早いけど、そこまでが結構掛かる

デプロイは Jenkins さんにまかせた

Push

hook Build

Private Registry

Push

UpdateService

Pull

ECS自動化

まとめ

ECS の悩み (1)ELB にぶら下げられるのはインスタンス単位の為、 ECS でコンテナを起動する時は、ポートを固定する必要があり、同じインスタンス内に同じ役割のコンテナを複数立てられない

安全にデプロイさせるために、インスタンスのリソースの空きを確保するしておく必要があり、 1 インスタンス多く立ち上げておく必要がある。

docker-compose を利用してコンテナを起動できない。task defenition をゴリゴリ書かないとダメ

ECS の悩み (2)バグった Docker イメージをリリースすると、 Service Update で無限にコンテナを立ててくれる

ECS インスタンスをオートスケールさせることはできるが、サービスで動かすタスクは自動で増えてくれない

コンテナのメトリクスは自前で監視する必要がある

結局どっちが良いのか今のやり方だと費用的に安く済むのは OpsWorks

ECS は private registry とリソース確保のために、インスタンス多く立ててる

開発環境と Amazon Linux の差異の影響を受けないのは ECS

正直どっちが良いか、まだ結論は出てない。。

ご静聴ありがとうございました