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

同じサービスを ECSとOpsWorksで 運用してみた JAWS-UGコンテナ支部 #2

自己紹介 市川 純 リクルートマーケティングパートナーズ @sparkgene 担当サービス • リクナビ進学アプリ • 料理サプリ • その他新規サービス 業務内容 • AWSを使ったサービスのインフラ構築・運用 • サーバサイドの開発

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

システム構成 Amazon S3 Elastic Transcoder ELB EC2 インスタンス RDS 開発環境を用意 ElastiCache

開発環境  開発環境では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、ストレージのコンテナが起動する

本番環境 Amazon S3 Elastic Transcoder ELB EC2 インスタンス RDS ここどうするか ElastiCache

AWSでDockerならECSでしょ！

ECSちょっとツラそう。。  そもそもDocker初心者  ECSでステージングの構築を進めてたが、本番運用にはま だ作りこみが必要  最初のリリースは使い慣れたOpsWorksで行こう

OpsWorksのいいところ  recipeを書けば同じサーバを簡単に立ち上げられる  デプロイがボタンひとつで簡単  専用のモニタリングがある  ライフサイクルイベントを使っていい感じに管理出来る

本番環境 Amazon S3 Elastic Transcoder ELB EC2 インスタンス RDS AWS OpsWorks ElastiCache

Amazon ECS使うよ！

ECSのいいところ  Docker使える！  開発環境も本番も同じDockerイメージが使える（一部は）  Dockerイメージからコンテナを起動するので速い  最近、クラスタ、サービスの単位でメトリクスが見れるように なった

ECSのつらいところ  Dockerイメージを管理するDockerレジストリが必要  デプロイ（コンテナの入れ替え）を自動化させるのが大変  コンテナの起動監視、ロールバックなど自前でスクリプト書かないと ダメ  そもそも、docker build、docker push、docker pullが遅い  pullした後はコンテナの起動は早いけど、そこまでが結構掛かる

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

Build hook Push Update Service Private Registry 自動化 ECS

まとめ

ECSの悩み(1)  ELBにぶら下げられるのはインスタンス単位の為、ECSで コンテナを起動する時は、ポートを固定する必要があり、同 じインスタンス内に同じ役割のコンテナを複数立てられない  安全にデプロイさせるために、インスタンスのリソースの空 きを確保するしておく必要があり、1インスタンス多く立ち上 げておく必要がある。  docker-composeを利用してコンテナを起動できない。  task defenitionをゴリゴリ書かないとダメ

ECSの悩み(2)  バグったDockerイメージをリリースすると、Service Updateで無限にコンテナを立ててくれる  ECSインスタンスをオートスケールさせることはできるが、 サービスで動かすタスクは自動で増えてくれない  コンテナのメトリクスは自前で監視する必要がある

結局どっちが良いのか  今のやり方だと費用的に安く済むのはOpsWorks  ECSはprivate registryとリソース確保のために、インスタン ス多く立ててる  開発環境とAmazon Linuxの差異の影響を受けないのは ECS  正直どっちが良いか、まだ結論は出てない。。

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