この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
いわさです。
CloudFormation StackSetsは複数のアカウント・リージョンへCloudFormationスタックを同時展開することが出来る機能です。
そんなCloudFormation SetackSetsが複数オペレーションを管理してくれるようになりました。
スタックセット作成時のオプションに「マネージド型の実行」が追加されています。
本日はこちらを早速試して見ました。
非アクティブな実行
こちらは従来の動きになります。
「StackSetsは一度に１つのオペレーションを実行します。」と説明されています。
オペレーションというのはスタックセットに対するCreateやUpdate、Deleteのことです。
以下の確認では、スタックセットから東京リージョンへスタックをデプロイしている最中に、大阪リージョンへのデプロイを追加しました。
処理中のオペレーションが存在する場合、エラーになりましたね。
以下の確認では、EC2を東京リージョンへ新規作成している最中に、そのスタックセットのパラメータを上書きするアップデートを行った場合です。
同様に失敗しました。
今まで意識して使ったことなかったのですが、なるほど。
終了やキャンセルを待機するか、自前で自動デプロイされるような仕組みを構築しない限りは、後続作業を行うためには待つしかなかったんですね。
アクティブな実行
今回追加された、アクティブな実行を試してみましょう。
「StackSets は、競合しないオペレーションを並行して実行し、競合するオペレーションをキューに入れます。競合するオペレーションが終了すると、StackSets はリクエスト順にキューに入れられたオペレーションを開始します。」とされています。
確認結果から、競合しないオペレーションというのはスタックとして重複していないかどうかのようです。 例えば、東京リージョンへデプロイしている最中に東京以外のリージョンへの操作や他のアカウントへの操作は競合しないオペレーションとなります。
それ以外は競合するオペレーションと考えて良いでしょうです。
競合しないオペレーションの動き
東京リージョンへデプロイ中に大阪リージョンを追加した場合は以下のようになりました。
おお。先程はエラーになりましたが、同時に処理されています。すごい。
競合するオペレーションの動き
こちらは、東京リージョンのEC2のNameタグを更新(Name→Name2)している最中に、さらにNameタグを更新（Name→Name3）する操作をした場合です。
追加された更新オペレーションはQUEUEDとなり、待機していますね。いいぞ。
1つ目の更新オペレーションが完了したのち、RUNNINGとなりました。
最終的には後勝ちですね。
同じタグ更新などではなく同一スタックであれば競合すると見なされますので複数のタグの編集と最後にスタック自体の削除オペレーションを行った場合は以下のようになります。
全てキューに入っていますね。
ちなみにキューに入ったオペレーションはキャンセル出来ないようなのでご注意ください。
最後まで更新処理が完了したのち、スタックが削除されました。いいですね。
さいごに
本日はCloudFormation StackSetsの複数オペレーションを管理・制御する新機能を試してみました。
デフォルトは「非アクティブな実行」が選択されています。
オペレーションが途中で失敗する可能性などを考えるとキャンセルできないアクティブ実行だとそれはそれで待ち時間が長くなったり複数オペレーションで整合性を取らなければいけない場合に不都合が起きそうなので、そことの兼ね合いでどちらを選択するか決めると良いと思います。
リスクの考え方としては複数リージョンの並列デプロイに似てるかもしれません。
3
