AWS Black Belt Online Seminar「Amazon EC2 Container Service」の資料およびQA公開
みなさんこんにちは。ソリューションアーキテクト小川です。
先日開催したBlackBeltオンラインセミナー「Amazon EC2 Container Service」の資料が公開されました。公開資料には当日発表者である岩永より、Appendixが盛りだくさんに加えられておりますので、当日セミナーに参加された方も、見逃してしまった方も、資料チェックしてみて下さい。
Q1. ecs-agentとの疎通が途絶えた場合、インスタンスをクラスタから除外(インスタンス削除)したいです。どのような方法で対応可能でしょうか？
A1. こうなってしまったインスタンスの対処はユーザ側に任せられているので、describeContainerInstancesなどで状態をチェックしてEC2のAPIで削除を行うと良いと思います。
Q2. Docker Swarm と Kubernetes との違い、利点があればお教えください。
A2. マスターサーバ等のクラスタ管理ソフトウェアが不要であること、スケーラビリティ、柔軟なスケジューラの利用(例えばMesos Schedulerと連携可能)、AWSの他のサービスとの連携がAmazon ECSの利点になります。
Q3. ELB,ALBと動的ポートマッピングで、EC2側のセキュリティグループはどのような状態になりますか？ある程度のtcpポートレンジで開けることになりますか？SGのルール更新も動的ですか？
A3. 自動更新はなくEC2のセキュリティグループがそのまま適応されるので、そのクラスタで動くコンテナに必要な通信は全て許可する必要があります。つまり、動的ポートマッピングでALBとの間の通信については、割当られるポートレンジを全て許可しておく必要があります。
動的に割当られるポートレンジについてはドキュメントに記載がありますのでご確認下さい。(portMappingsのhostPortの項目です)
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html#container_definitions
Q4. こちらバージョンアップするときに古いソースと新しいソースが混在する時間があるように見えるのですが一気にソースを入れ替えることはできるのでしょうか。それが100/200の設定で一気に変わるのでしょうか。
A4. Blue/Greenデプロイですので混在し得ます。Minimumを出来る限り小さくし(ダウン許容なら0)、Maximumを出来る限り大きくすることで、可能な限り最速での切替を行うことができます。但し、本当に一気に切り替わる必要が本当にあるのかは要検討かと思います。
Q5. コンテナに置くデータが5Gあった時すべてのコンテナに5Gのデータを置くことに鳴るのでしょうか。それともデータコンテナなどを作ってリンクができるのでしょうか
A5. ナイーブな作りをすれば全てのコンテナが5Gのデータを持ちますので、イメージのPullに時間がかかります。リンクもできますがTask内となりますので、同じことになります。共有ファイルシステムやS3などのオブジェクトストレージを使う方向が良いと思います。
Q6. instanceをスケールアウトすることは可能でしょうか？
A6. EC2インスタンスを起動してClusterに登録するだけです。Auto Scaling GroupやSpot Fleetを使って自動化すると良いと思います。
Q7. Minimum/Maximum healthy percentの値を調整することでServiceのローリングアップアップデートは可能なのでしょうか？
A7. ローリングアップデートの定義によりますが、例えばdesiredCount 10に対して、Minimum 90, Maximum 100とすれば1 Taskずつ入れ替わっていくことになります。
Q8. desired countを減らした時、どのインスタンスにあるタスクが落ちますか？
A8. ランダムと思って頂ければと思います。
Q9. タスクが起動できないことを検知してインスタンスを増やすことはできますか？
A9. runTaskが失敗したり、describeServicesのEventsでリソース不足であることを確認したら、Clusterで使っているAuto Scaling GroupやSpot Fleetの数を変更するAPIを実行することで自動化可能です。
Q10. タスクが落ちるときにログ（ファイル）をS3などに送信するにはどうするのがよいでしょうか。
A10. Factor Appにあるように、ログはストリームで外に転送しておくのが一番オススメです。awslogsを使ってCloudWatch Logsに入れておけば、S3への書き出しも可能です。ホスト側のボリュームをマウントして書いておいて、ホスト側のプロセスでそれを送信しておく方法も考えられますが、今度はホストが落ちた時にどうするかを考える必要が出てくるので、イタチごっこになります。
Q11. CPUのリミットについて教えてください。
A11. CPUのリミットは、もしそのインスタンス上でCPU使用率が競合してきた時に、その値をベースに制限されます。インスタンス上でCPUが余っていれば、リミットを超えて使うことが可能です。
Q12. ECSを導入することによるベンダーロックインは発生しないでしょうか？
A12. ECSが実現していることと似たような事は実装可能であり、多くのクラスタ管理ソフトウェアが似通ったコンセプトを持っています。コンテナ化することでアプリ自体のポータビリティが上げられるので、むしろロックインとは逆の方向になるかと思います。なお、導入の容易さという点でECSの利点があるかと思います。
Q13. ecs-agentコンテナも計算の対象に含まれますか？また、ecs外で動かしているコンテナがある場合はどうなりますか？
A13. リソースについてかと思いますが、ecs-agentはCPU/Memory共に予約無しで動くので利用可能リソースは消費しません。ECS外で動かしているコンテナが使っているリソースについては全く考慮しないので、出来る限りECSのTaskとして起動することをオススメします。メモリについては、ecs-agentにECS_RESERVED_MEMORYという設定、ポートについてはECS_RESERVED_PORTS/ECS_RESERVED_PORTS_UDPを与えることで、調整は可能です。
以上です。今後のBlackBeltオンラインセミナーの配信予定は下記のリンクより確認頂けます。
https://aws.amazon.com/jp/about-aws/events/webinars/
AWSに関する技術のキャッチアップの場として是非ご活用下さい。
コメント