Amazon EC2を使用すると、ユーザーはプログラムまたは自動で仮想マシン（VM）をスピンアップできる。プログラムを使用するか、自動化するかは構成次第だ。Amazon EC2ユーザーは、VMを配置するインスタンスのタイプ、リージョン、アベイラビリティゾーン（AZ）を定義する。Amazon EC2のインスタンスはスケールアップ可能だが、Amazon EC2の真価はスケールアウトの機能を追加したときに発揮される。スケールアウトの機能は、異なるAZとリージョンにある複数のサーバにサービスを分散する。

　Amazon EC2の価格は、より少ない数の大きなインスタンスを実行すると抑えることができる。一部のサーバを完全に隔離して、他のサーバに影響しないようにしたいと考える企業はDockerを採用している。

　Dockerは、マイクロサービスとクラウドのポータビリティに重点を置いたサービスだ。マイクロサービスは、あるサービスの問題が他のサービスに影響することを回避するのに役立つ。例えば、PDFをアーカイブするプロセスで問題が発生し、CPUが枯渇したとしよう。このような場合に検索インデックス作成システムが無効になるのは望ましくないだろう。各サービスをそれぞれ専用のAmazon EC2インスタンスでスピンアップするのが、標準的な修復方法である。だが、m3.largeのインスタンスを2つ運用すると、m3.xlargeインスタンスを1つ運用するよりもコストが掛かる。Amazonは、多数のインスタンスを使用するより、大きなインスタンスを使用するユーザーを優遇している。

　ただし、Dockerは、AWSやクラウドに限定されるものではない。ITチームは、パブリッククラウドからベアメタルに至るまで、さまざまな場所でDockerを実行できる。Dockerは、VM上に抽象化レイヤーとして配置される。仮想化レイヤーのオーバーヘッドはそのままだ。つまり、企業はコードを書き直す必要なく、他のパブリッククラウドプロバイダーのサービスを試すことができる。主な機能が、時間を掛けて構築してきた「Amazon Machine Instances」（AMI）にある場合、問題は2つある。1つは、新しいセキュリティパッチに対応するためにAMIを更新するスクリプトを維持しなければならないことだ。もう1つは、米Googleの「Google Compute Engine」など、新しいクラウドプロバイダー用にシステムを再構築しなければならないことだ。

　以降、Amazon ECSをセットアップして運用するための手順を紹介する。

Amazon ECSを使い始める

　Amazon ECSには、DockerとAWSを使い始めるのに必要なものがそろったコンソールが用意されている。最初に実行すべき手順は、クラスタを作成して、インスタンスをDockerのプールに追加することだ。これらのインスタンスは「Auto Scalingグループ」（ASG）に追加できる。ASGにインスタンスを追加すると、正常なインスタンスがいつでも利用可能になり、Dockerシステムにはコンテナの実行状態を維持するための余力が生じる。

　まず、Amazon ECSのコンソールにアクセスし、クラスタを作成されたい。これがDockerインスタンスの最上位レベルのグループになる。同じAWSのアカウントで、複数の個別のクラスタを使用してテスト／開発用の環境を分離することができる。

　クラスタを作成したら、次の手順はクラスタでインスタンスを起動することだ。個人的には、ASGの使用をお勧めする。これは、クラスタで一定数のインスタンスを実行する場合にも当てはまる。ASGを設定すると、サーバが停止したときに、自動的に別のサーバに差し替えられるため予防対策にもなる。

　コンソールで新しい起動構成を作成したら、AWS Marketplaceから最新のAmazon ECS最適化インスタンスを選択されたい。

　［Continue］をクリックし、起動するインスタンスのタイプを選択する。C4またはM3のインスタンスタイプでlarge以上の使用をお勧めする。T2またはT1は選択しないようにされたい。これらのインスタンスは、バーストキャパシティー用に設計されている。そのため、長期間に渡って実行されるプロセスの実行状態を維持することについて問題が発生する恐れがある。

　その他の項目についても必要な情報を設定したら、今度はASGのセットアップだ。ASGは画面に表示されるメッセージに従ってセットアップできる。ASGは「仮想プライベートクラウド」（Amazon VPC）で実行するように構成可能だ。だが、少なくとも2つの異なるアベイラビリティゾーンに存在する2つのサブネットで実行するようにセットアップされたい。

　ASGがクラスタでAmazon EC2をスピンアップしたら、Amazon ECSコンソールにインスタンスが表示されるようになる（図1）。

タスクの定義を作成する

　タスクとは、1つのサービスまたはマイクロサービスのために実行されている1つ以上のDockerコンテナだ。タスクは、シンプルなワークロードまたは複雑なワークロードに使用できる。前者の例はRedisサーバだ。また、後者の例には、データベース、Memcached、Webサーバのリンクされたコンテナを含むWordPressスタック全体などがある。これはコンテナをリンクして、連係させるのに役立つ。

　タスクの定義でコンテナを構成するときには、コンテナ名、イメージ、CPU、メモリ、マップするオプションのポート、オプションの環境変数、オプションのオーバーライドコマンド、リンクを定義されたい。また、各コンテナ用に予約するメモリ（Mバイト単位）とCPUのユニット数を指定する必要がある（1基の2.8GHzプロセッサには、全部でCPUユニットが1024個ある）。この設定により、サーバが過剰な数のコンテナでオーバーロードすることを回避できる。つまり、1つのコンテナが過剰にリソースを消費して、他のコンテナの処理速度が低下する事態を回避することができる。クラスタのWebサイトには、利用可能なCPUユニットとRAMが表示される。このいずれかが不足したら、新しいコンテナを起動する前にクラスタで追加のサーバを起動されたい。

サービスを作成する

　タスクの定義を作成したら、今度はサービスの作成だ。サービスは、簡略化されたASGのECS版である。サービスにより、一定数のタスクインスタンスが実行されるようにし、開発者は実行中のインスタンスをロードバランサーに結び付けられるようになる。サービスのロールをアサインすると、コンパートメント化に役立つ。個々のDockerコンテナには、専用のIDとアクセス管理のロールが付与される。これにより、個々のDockerコンテナはAmazon EC2に匹敵するパワーを手に入れることができる。

　Private Docker Registryから始めることをお勧めする。Private Docker Registryでは、Dockerのイメージのプライベートリポジトリを作成して、システムにプルすることができる。Dockerのプライベートリポジトリは、「Amazon Simple Storage Service」（Amazon S3）のリポジトリへの保存がサポートされている構成可能なDockerコンテナのように見える。

　図2は筆者がDockerレジストリをホストするために使用したタスク定義のサンプルである。

　図3は関連サービスだ。

　筆者のDockerHubの内部ロードバランサーはポート80からポート5000にプロキシしている。VPC内でしか利用できないので、カスタム認証やSSLのサポートは不要だ。このDockerリポジトリからプルするようにイメージをセットアップすることができる。また、イメージを作成して、このリポジトリにプッシュするのに使用できる特別なDockerのインスタンスがある。

Blue-Greenアップデートを実行する

　「AWS Elastic Beanstalk」と同様に、Amazon ECSはアップデートに対応している。その手法は追加タスクのスピンアップ、ロードバランサーの切り替え、新しいコンテナの準備ができたら古いコンテナを終了するというものだ。通常、このプロセスによってダウンタイムが削減される。そのため、ITチームは顧客に影響を及ぼすことなく営業時間内にアップデートをプッシュできる。

　Blue-Greenの導入を行うには、新しいバージョンのタスクを作成し、その新しいバージョンのタスクを使用するようサービスを更新されたい。この新しいタスクは、新しいバージョンのイメージをポイントしているだろう。Amazon ECSでは、全てのタスクの変更内容が保存される。そのため、導入で何か問題が起こった場合は、簡単に古いバージョンに戻すことができる。

Amazon ECSとElastic BeanstalkのどちらがDockerコンテナに適しているのか

　AWSのインスタンスでDockerを運用するのは新しい概念ではない。定期的に新しい導入を使用するWebベースのアプリケーションが必要な場合は、DockerとElastic Beanstalkの組み合わせを使用するのが最善の策だろう。だが、アプリケーションの裏側で複数のマイクロサービスを実行する場合、この組み合わせは必ずしも理想的な環境とはいえない。Webアプリケーションが他のバックエンドシステムを動かしている場合、Amazon ECSとElastic Beanstalkの両方をDockerと使用しなければならないかもしれない。バックエンドシステムには、動画のトランスクリプトの抽出、イメージの自動顔認識、ゲームの分析などがある。

　SQSキューから読み取るようAmazon ECSのマイクロサービスに指示をしてから、サービスを拡張して、環境で複数のサービスのコピーを実行するのが最適な場合もあるだろう。例えば、m3.xlargeインスタンスが4つあるとしよう。このインスタンスでは、10個のPDF抽出ツール、2台のフルテキストインデックス作成システム、4台の配信システム、幾つかの雑多なタスクを実行している。雑多なタスクには、英Geckoboardのダッシュボードを更新したり、米Tableau Softwareの「Tableau」で分析するためにデータをRDSと同期する処理などがある。

　上述のサービスにアクセスして、実行するタスクの数を増やして、さらにPDF抽出プロセスを追加することができる。追加の領域が必要な場合は、サーバのサイズを増やすか、プールのサイズを大きくすることで対応可能だ。この作業をElastic Beanstalkで行うとしたら、10個のPDF抽出ツールを実行するために少なくとも10個の個別のインスタンスが必要になる。一方、Amazon ECSでは、小さなインスタンスを複数実行するよりも大きなインスタンスを安価に実行できるというメリットを活用することができる。

　AWSでDockerを使用している場合は、Amazon ECSが最適な選択肢となるだろう。AWSが作業の大半を行っているので、コンテナで一定数のインスタンスを実行した状態を維持して、「Amazon Elastic Load Balancing」（Amazon ELB）やAuto Scalingといったなじみのある要素を使用しながら、簡単にインスタンスを管理できる。