社内向けのサービスで、OpsWorksとECSを使ってみた感想

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

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

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

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

5. 開発環境
 開発環境ではdocker-composeを使ってる
 サーバサイドエンジニアもフロントエンジニアも、数行のコマ
ンドで環境構築が出来る
$ docker-compose build
$ docker-compose run rails rake db:create
$ docker-compose run rails rake db:migrate
$ docker-compse up

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

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

8. AWSでDockerならECSでしょ！

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

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

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

12. Amazon ECS使うよ！

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

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

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

16. Push
hook
Build
Private Registry
Update
Service
ECS
自動化

17. まとめ

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

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

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

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