AWSのDocker管理サービス、Amazon EC2 Container Serviceの概要と使い方：Docker運用管理製品／サービス大全（5）（4/4 ページ）

数多く台頭しているDockerの運用管理に関する製品／サービスの特長、使い方を徹底解説する特集。今回は、AWSが提供するECSの概要や主な機能、環境構築方法、オーケストレーション設定やスケーリングを行う手順など使い方などについて。

[長妻賢, 澤井健，株式会社NTTデータ]

ECSでスケーリングを行う手順

　ここからは、ECSでのコンテナー数のスケーリングを行う手順を解説します。

手動によるTask数の増減の検証

　ECSはClusterを作成するときにELB、Container instance（EC2インスタンス）、Task（コンテナー）を作成します。しかし、ECSではServiceでELBとコンテナーを制御し、Auto ScalingでContainer instanceを制御する仕組みになっています。そのため、Task数を増減させる場合は手動でClusterとAuto Scalingの設定を変更する必要があります。

　Task数の増加は下記の手順で行います。

　まずは、Auto Scalingの設定でインスタンス数を増加させContainer instanceを増加させます。

　次に、Container instanceが増えたことを確認し、最後にClusterのServiceのUpdateを行いTask数を増加します。

　Task数の減少は下記の手順で行います。

1. ClusterのServiceのUpdateを行いTask数を減少させる
2. Auto Scalingのインスタンス数を減少させる
3. Container instance（EC2インスタンス）が減ったことを確認する
4. 062＃

ECSのリソース管理とスケーリングの自動化

　ECSではServiceでELBとコンテナーを制御し、Auto ScalingでContainer instanceを制御する仕組みになっています。そして、ECSではContainer instance上で動作できるTask（コンテナー）数を「CPU Unit」「Memory」のリソースで管理しています（正確には上記に加えポートが使用可能かでも判定されます）。

　そして、この利用可能な「CPU Unit」「Memory」リソースはカスタムメトリクスを使うことによってCloud Watchで監視することができます。そのため、上記のリソースをAuto Scalingのトリガーとして使用することでスケーリングの自動化を行うことができます。

　これは「ユーザーはTaskの増減を自由に行い、それに合わせてContainer instanceの数をスケーリングさせる」方法です。

　t2.microのContainer instanceは生成時に利用可能なリソースとしてCPU Unit：1024／Memory：1024を持ちます。そして、Task DefinitionからTask（コンテナー）が作成され、Container instanceに割り当てられると、利用可能なCPU Unit／MemoryがContainer instanceから減っていきます。

　Container instanceが利用可能なCPU Unit／MemoryはECSのコンソールから確認でき、さらにこの値はカスタムメトリクスに設定することにより、Cloud Watchからも監視できます。

　ここからは、下記リストのCPU Unitのリソースを例に採り、スケーリングを説明します。

• Container instance
  • Container instanceの総利用可能なCPU Unit：1024
• Task Definition
  • HTTPD：CPU Unit 256
  • Postgres：CPU Unit 512
  • Redies：CPU Unit 128
  • Databook：CPU Unit 256
• スケーリングポリシー
  • 「利用可能なCPU Unit < 200」の場合にスケールアウト

　まずは、ECSを利用してHTTPDとPostgressのコンテナーを持ったContainer instance環境を作成します。

　次に、自動で作成されたAuto Scalingにはスケーリングポリシーがないため、上記のスケーリングポリシーを設定します。

　続いて、別途カスタムメトリクス実行用のEC2を作成し、監視するための取得を行うスクリプトをcronを設定、実行しCPU Unitの値をCloud Watchに送信します。

　そして、Container instanceに新しくRedisのコンテナーを追加します。

　この場合はContainer instanceにコンテナーを載せるスペースが少なくなったため、スケーリングポリシーにより新しくContainer instanceを作成します。

　さらに、DatabookコンテナーをClusterに追加します。この場合は新しく作成されたContainer instanceに配備されます。

　このように、ServiceのSchedulerは下記の機能を持っています。

• 追加されたTaskをリソースが空いているContainer instanceに配備する
• クラスター構成の場合は複数のContainer instanceにコンテナーを作成し、そのContainer instanceをELBに設定する

　ただし、Container instance内の最適化は行われないため、上記のようにDatabookコンテナーをClusterに追加した後に、CPU Unit：800のコンテナーを追加しようとすると、「リソースがありません」といったメッセージが出力され、追加することができません。

　また、コンテナー内のリソース情報はAWS CLIでは取得できないため、こちらをスケーリングのトリガーにすることはできません。

次回は、AWSの「Elastic Beanstalk」について

　次回は、AWSが提供するPaaS「AWS Elastic Beanstalk」のDocker管理サービスとしての側面について解説します。

特集：Docker運用管理製品／サービス大全

数多く台頭しているDockerの運用管理に関する製品／サービスの特長、使い方を徹底解説する特集。

特集：Docker運用管理製品／サービス大全

筆者紹介

長妻賢

NTTデータで基盤系技術者として各種開発に従事。運用管理製品Hinemosをクラウドに対応させるべく開発をしつつ、AWSにおける運用を議論するコミュニティ「OpsJAWS」の立ち上げに携わるなどしている。

澤井健

富山県出身。NTTデータに入社後、PostgresForestやHinemosの開発、保守、導入支援に携わり、今はHinemosのクラウドへの普及展開を進めている。休日は仕事を離れ、宝塚観劇のため日比谷や兵庫に訪れるなど趣味を満喫している。

• 執筆履歴

Software Design plusシリーズ『Hinemos 統合管理［実践］入門』（共著：技術評論社）