概要
最近Dockerコンテナでシステムの本番運用を始めました。その際にデプロイサービスとして検証したのがBeanstalk Multi-dockerとECS。今回は実際に両方触ってみて、両者のメリット・デメリットをまとめます。
尚、調査する上で、ECSで動作するRails コンテナ (Amazon Linuxイメージ) を作りました。ソースは GitHub で公開しています。
機能比較
Beanstalk、ECS共にDockerコンテナを動かすことはできますが、機能比較するとこんな感じです。
| 機能 | Beanstalk | ECS |
|---|---|---|
| EC2インスタンスの作成 | ◯ | ◯ |
| EC2セキュリティグループの割当 | アプリケーション環境単位で生成 | 既存のセキュリティグループを指定可能 |
| EC2オートスケーリング | ◯ | ◯ |
| ELB (CLB) の作成 | ◯ | ◯ |
| ELB (ALB) の作成 | ◯ (※1) | ◯ |
| ローリングデプロイ | ◯ | ◯ |
| ブルーグリーンデプロイ | ◯ | △ (OSS) |
| アラート通知 | ◯ 環境作成のエラー・ヘルスステータスの変化等を通知 |
☓ |
| ログ管理 | ◯ | ◯ |
| RDSインスタンスの生成 | ◯ | ☓ |
- ※1: CLIからのみ実行可能
Beanstalkの特徴
- 環境構築が楽。EC2+RDSという一般的なアプリケーションであればBeanstalkコンソールでほぼ完結
- コンテナを用いないアプリケーションも構築可能
- Multi-container Dockerを利用すると、裏でECSが動く (ECSを意識しなくてもアプリケーションが動く)
Beanstalkはとにかく環境構築が簡単。ウィザードに従ってうっかり Create environment なんて押すもんならいきなりインスタンス起動してアプリケーションが動き出す。間違えて3回くらい押した。
Beanstalkは環境構築が簡単な反面、裏で何のサービスが連動しているのか分かりにくい側面もあります。障害が発生した時、問題の切り分け (コンテナが原因なのか、ECSか、それともBeanstalkの問題か) が困難となる印象です。
ちなみにBeanstalkでもELBは利用できますが、ELB利用時にセッションストレージとしてよく使うであろうElastiCacheはBeanstalkのコンソールからは連携できないようです。
あと地味に便利だと思ったのはCloudWatchへのログ転送。Lambdaのように自動で各種ログをCloudWatchに流してくれる。恐らく裏でCloudWatch Logs Agentが動いてると思われる。
Beanstalkには色々と良い面もあるのですが、個人的にはセキュリティグループが謎の命名規則によって環境ごとに生成されまくるのが嫌という理由でECSの検討を始めました。
ECSの特徴
- Dockerコンテナのデプロイに特化
- ALBが使える
- CLBと比較してコストが安くパフォーマンスも高い
- WebSocket、HTTP/2対応
- L7ルーティング対応
- 動的ポートマッピング対応
- Dockerの新機能はBeanstalkより早く取り込まれる
ECSを利用する場合、Beanstalk Multi-container Dockerが裏でやってくれていた仕事 (クラスタの構築、タスクの作成、サービスの作成) を自前で準備する必要があります。これが結構面倒です。CloudFormationでテンプレート書けば良さそうですが。
またECS特有の「タスク」や「サービス」の仕組みを理解する必要がありますが、概念さえ理解してしまえば、コンテナに対するリソース制限からネットワーク設定まで幅広い制御が可能です。
もう一点、ECSの特徴としてALBが使えることは大きなメリットですが、中でも動的ポートマッピングが良い感じ。
CLBの場合、1ホスト (EC2 Container Instance) につき1コンテナしかポートマッピングできなかったのが、ALBの利用によって複数マッピング可能となりました。これによって、1ホストで複数のWebアプリケーションを動かすことが可能となります。
また、今までELB利用時は2台のインスタンスを分散配置させる必要がありましたが、ALBはポート単位でコンテナと接続するため、1ホストだけ配置しておけば、あとはよしなにリクエストを分散してくれるようになります。
ちなみにECSはいくつかデプロイツールが公開されてます。これも機能を比較してみました。
| パッケージ | GitHub Watch | GitHub Star | GitHub Fork | 特徴 |
|---|---|---|---|---|
| aws/amazon-ecs-cli | 67 | 491 | 79 | AWSオフィシャル。Docker composeファイルが利用可能 |
| silinternational/ecs-deploy | 31 | 473 | 154 | サービスのデプロイに特化 |
| stormcat24/ecs-formation | 8 | 78 | 9 | ブルーグリーンデプロイが可能 |
ecs-cliはクラスタの設定を ~/.ecs/config に書き込むイマイチ仕様だったので、今回はecs-deployを採用。
最近はDocker CI環境を構築し、ecs-deployをラップしたデプロイツールでコンテナの本番運用を始めてます。
次のフェーズとしてデプロイの自動化を検討しているので、これについてはまた次回書こうと思います。