AWSでシステムを構築する場合、厳しい性能要求など特別な事情がある場合を除き、一般的にはマルチAZで構築します。
あらためて聞くまでも無いですが、それはなぜかというと可用性のためです。 AZ間は独立しており、一つのAZで問題がおきたとしても、他のAZでサービス継続できることでシステムの信頼性が上がります。
ECSのマルチAZ戦略
ECS(Elastic Container Service)の特にEC2起動モードの場合は、このマルチAZを実現する上で2段階の考慮が必要です。
- データプレーンであるコンテナインスタンス(EC2)がマルチAZで起動しているか
- コンテナインスタンス上で動く各タスク(コンテナ)がマルチAZで起動しているか
後者のタスクレベルで分散していなければ、障害発生時の影響が想定以上のものになってしまいかねません。
これを制御するために、これまでタスク配置の戦略を決めることができ、 AZで分散したり、コンテナインスタンスで分散して配置することで対障害性を向上させることができました。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-placement-strategies.html
ただし、これはあくまでもタスクを起動するときの話であり、 システムを運用する中で、コンテナインスタンスの停止などの影響でコンテナの配置に偏りが生じることがあります。
以下は各挙動による、タスクID, コンテナインスタンスID, AZの出力結果の例です。
# 初期状態
| Task ID | ContainerInstance ID | AZ |
| 45157257286d4f3981a2ff35001f1a46 | efc73e16e2124f8ebd95afb979fbcaa9 | us-east-1c |
| 485d46dc05404411ac615b0813f8ce63 | 39e05f45f51d467ba061e3f23fb2782b | us-east-1b |
| 4cef0f40b2ec4ca3b53be023a125b84f | fd0fe4a41a9b42b2bf2023b9c421beb2 | us-east-1a |
# us-east-1aのコンテナインスタンスが停止し、タスクが既存のコンテナインスタンスで起動した状態
| 45157257286d4f3981a2ff35001f1a46 | efc73e16e2124f8ebd95afb979fbcaa9 | us-east-1c |
| 485d46dc05404411ac615b0813f8ce63 | 39e05f45f51d467ba061e3f23fb2782b | us-east-1b |
| 87054724fb1045458d6ac7bbab585649 | 39e05f45f51d467ba061e3f23fb2782b | us-east-1b |
この状態では、us-east-1bで障害が発生するとタスクが2つダウンしてしまいます。 障害時の設計次第ですが、この場合期待するサービス提供ができなくなってしまう恐れがあります。
us-east-1aが復活して、ふたたびタスクを実行できる状態になったとしても、 タスクが起動したあとの状態ではバランスを取ることはしません。 そのため、例えばスケールアウトして新しいタスクを起動させることで再度バランスを取る(リバランス)必要がありました。
# スケールアウトし、us-east-1aでタスクを起動する
| 45157257286d4f3981a2ff35001f1a46 | efc73e16e2124f8ebd95afb979fbcaa9 | us-east-1c |
| 485d46dc05404411ac615b0813f8ce63 | 39e05f45f51d467ba061e3f23fb2782b | us-east-1b |
| 5d5224ba1cef43b0a63ce88af0c2a912 | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
| 87054724fb1045458d6ac7bbab585649 | 39e05f45f51d467ba061e3f23fb2782b | us-east-1b |
# スケールインして、もとのタスク数に戻す
| 45157257286d4f3981a2ff35001f1a46 | efc73e16e2124f8ebd95afb979fbcaa9 | us-east-1c |
| 5d5224ba1cef43b0a63ce88af0c2a912 | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
| 87054724fb1045458d6ac7bbab585649 | 39e05f45f51d467ba061e3f23fb2782b | us-east-1b |
コンテナオーケストレーションの世界ではKubernetesが有名ですが、 Kubernetesには、Deschedulerと呼ばれるこのリバランスを自動化してくれる仕組みがあります。
https://github.com/kubernetes-sigs/descheduler
それに対して、ECSにはそのような自動化の仕組みがこれまで存在せず、 タスク配置に偏りが発生していることを検知して、手動で調整する必要がありました。
ECSの自動リバランス
そんな中、先日ついにECSでもリバランスの仕組みが導入されたことが発表されました。
これを利用することで、以下のように自動でバランスが崩れたことを検知してリバランスしてくれます。
# 偏りがある状態
| d420d2c918d747f6a2cf1a65c8869354 | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
| dbf602f92bbf4c9ba5847b505aad5a55 | 0f8741e98ef14fea8a9be97b47dd9314 | us-east-1c |
| e6d1c1c466e441cda44d94c77372bb7e | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
# 新しくタスクが起動する
| 6c9096df62cb47058713acd2273d27ef | fbd9e4f75ffa486ca31a523610e45572 | us-east-1b |
| d420d2c918d747f6a2cf1a65c8869354 | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
| dbf602f92bbf4c9ba5847b505aad5a55 | 0f8741e98ef14fea8a9be97b47dd9314 | us-east-1c |
| e6d1c1c466e441cda44d94c77372bb7e | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
# 余分なタスクが終了し、リバランスが完了する
| 6c9096df62cb47058713acd2273d27ef | fbd9e4f75ffa486ca31a523610e45572 | us-east-1b |
| dbf602f92bbf4c9ba5847b505aad5a55 | 0f8741e98ef14fea8a9be97b47dd9314 | us-east-1c |
| e6d1c1c466e441cda44d94c77372bb7e | 96d493dfb02b4ca1b7d9e872ac0e1fc1 | us-east-1a |
やっていることは手動でスケールアウト・スケールインしているのと変わらないですね。 ただ、サービスの設定を変更することなく、タスクの起動状況を見て自動でリバランスしてくれるので便利です
もっと偏りが極端な場合は？
先ほどの例では1タスクだけが分散できてないケースでしたが、 複数のタスクが偏っていても、まとめて対処してくれます。
# 1インスタンスだけに偏らせてみる
| 131b81060b6b4aeeaa1db54b859f8aa6 | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
| 90426a6661e04f73a1535f184279285d | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
| bc2d2be6f4564eee81eccfbdcb957ac3 | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
# us-east-1a, us-east-1bそれぞれでタスクが起動する
| 131b81060b6b4aeeaa1db54b859f8aa6 | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
| 8878019b21bd4f2ab3d18397a9e84b43 | d3cee28f9fc3461aa28b1276393ea7f5 | us-east-1b |
| 90426a6661e04f73a1535f184279285d | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
| 9320850d8f104975ab3d4263e3eda958 | a5821139a27c415893594f698e9c130b | us-east-1a |
| bc2d2be6f4564eee81eccfbdcb957ac3 | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
# リバランスが完了する
| 8878019b21bd4f2ab3d18397a9e84b43 | d3cee28f9fc3461aa28b1276393ea7f5 | us-east-1b |
| 9320850d8f104975ab3d4263e3eda958 | a5821139a27c415893594f698e9c130b | us-east-1a |
| bc2d2be6f4564eee81eccfbdcb957ac3 | 138a5de0b5c447a895a1fed88817bba2 | us-east-1c |
利用する上での注意点
細かい機能制約はドキュメントを見てください。 DAEMON戦略の場合は利用できないなど、仕組み上当然のものも多いので、そこまでこの辺が原因で動かないということは無いでしょう。
https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/service-rebalancing.html
それ以外に実際にさわってみて以下の注意が必要かと思いました。
- 意外と検知までに時間がかかる
- リバランスするために必要なコンテナインスタンスがREADYな状態になってから、実際にリバランスが発動するまでに、20分前後かかりました
- 検知間隔はコントロールできない
- 上の項目とあわせて、少なくとも現時点では検知の間隔をコントロールできないのでリバランス発動まで待つ必要があります
- もっと早く作動させたかったり、実行のタイミングをメンテナンス時間したい等コントロールしたい場合は、これまでどおり手動でやる必要があります
- タスクの同時実行数
- これは手動でスケールアウトする場合も同じですが、一時的にタスクが通常よりも多く起動することになります
- VPC Trunkingが有効であればそこまで問題になることは無いでしょうが、コンテナ起動数の上限に達していたり、同時実行数がなんらかのライセンス違反になったり、には気をつけましょう
まとめ
今回は、ついにECSにきたタスクリバランスの自動化について紹介しました。
出たばかりでまだまだのびしろも感じますが、対処を自動でやってくれるのは便利なので ECSを利用している方はぜひご検討ください。
そして、もしこれまでタスクのマルチAZ戦略についてあまり見落しがあった場合は せっかくの機会ですので、想定する障害とそのときに満たしているべき要求事項と設計があっているか、 実際にシステムは期待通りに動くのか、あらためて確認してみると良いでしょう。
Share