1
/
5

Dockerコンテナデプロイサービスの比較 (Beanstalk Multi-container Docker/ECS) (20170317更新)

【概要】

最近Dockerコンテナでシステムの本番運用を始めました。その際にデプロイサービスとして検証したのがBeanstalk Multi-dockerとECS。今回は実際に両方触ってみて、両者のメリット・デメリットをまとめます。

尚、調査する上で、ECSで動作するRails コンテナ (Amazon Linuxイメージ) を作りました。ソースは GitHub で公開しています。


【機能比較】

Beanstalk、ECS共にDockerコンテナを動かすことはできますが、機能比較するとこんな感じです。

※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はいくつかデプロイツールが公開されてます。これも機能を比較してみました。

ecs-cliはクラスタの設定を ~/.ecs/config に書き込むイマイチ仕様だったので、今回はecs-deployを採用。

最近はDocker CI環境を構築し、ecs-deployをラップしたデプロイツールでコンテナの本番運用を始めてます。

次のフェーズとしてデプロイの自動化を検討しているので、これについてはまた次回書こうと思います。

株式会社pringでは一緒に働く仲間を募集しています
1 いいね!
1 いいね!
同じタグの記事
今週のランキング