連載
» 2015年11月20日 05時00分 公開

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

[長妻賢, 澤井健,株式会社NTTデータ]
前のページへ 1|2|3|4       

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の運用管理に関する製品/サービスの特長、使い方を徹底解説する特集。



筆者紹介

長妻賢

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

澤井健

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

  • 執筆履歴

Software Design plusシリーズ『Hinemos 統合管理[実践]入門』(共著:技術評論社)


前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。