この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
テントの中から失礼します、IoT 事業部のてんとタカハシです！
AppConfig で作成したアプリケーションの環境に設定をデプロイした直後、設定する情報を間違えてしまった等で、すぐさま再デプロイを行いたい時があります。ただし、選択したデプロイ戦略の設定によっては、デプロイ直後の再デプロイが不可になる（一定時間待つ必要がある）場合があります。
AppConfig 初心者の私は、そもそもデプロイ直後は再デプロイ不可な仕様なんだと勘違いしていましたが、色々と調べてみると回避可能であることを確認できたので、本記事でご紹介したいと思います。
前提
- アプリケーション「SampleApplication」が作成済みであること
- 上記に環境「dev」が作成済みであること
- 上記に機能フラグ設定プロファイル「SampleProfile」が作成済みであること
- 自由形式の設定プロファイルでも問題ありませんが、本記事では機能フラグを例として使用します
デプロイ直後の再デプロイがエラーになる事象
機能フラグに属性を追加して、バージョン「1」を作成します。その後「デプロイを開始」をクリックします。
環境「dev」にバージョン「1」をデプロイします。デプロイ戦略は「AppConfig.AllAtOnce (Quick)」を選択します。その後「デプロイを開始」をクリックします。
デプロイ戦略「AppConfig.AllAtOnce (Quick)」はデフォルトで用意されている設定で、下記のドキュメントに説明が記載されています。
「この戦略では、すべてのターゲットにただちに設定をデプロイします」と記載があるため、これを選択しておけば、デプロイがすぐに完了しそうな雰囲気です（この理解が微妙に間違いだったことが後に分かります）。
デプロイ開始後、デプロイの詳細画面に遷移されます。画面右上の更新ボタンをクリックすると、デプロイのステータスにある「完了の割合」が100%と表示されます。
と、ここで機能フラグに追加した属性に間違いがあったことに気付くとします。属性を編集してバージョン「2」を作成した後に「デプロイを開始」をクリックします。
そのまま「デプロイを開始」をクリックします。
すると、エラーが表示されました。
内容は下記の通りです。
ConflictException: Environment f73rq4b currently has a state of DEPLOYING. The current deployment must finish before a new deployment can be started.
環境の状態が「DEPLOYING」なので、新しいデプロイを実行することができないようです。あれれ、さきほど100%って記載があったような。
環境の詳細画面を確認すると、先ほど行ったデプロイの状態が「ベーキング」となっています。
10分後に環境の詳細画面を確認すると、デプロイの状態が「完了」に変わっていました。
ベーキング及びベイク時間とは
デプロイの状態「ベーキング」とは何ぞや？と思い、AWS のドキュメントを漁っていたら「ベイク時間」という設定に辿り着きました。
This setting specifies the amount of time AWS AppConfig monitors for Amazon CloudWatch alarms after the configuration has been deployed to 100% of its targets, before considering the deployment to be complete. If an alarm is triggered during this time, AWS AppConfig rolls back the deployment. This setting specifies the amount of time AWS AppConfig monitors for Amazon CloudWatch alarms after the configuration has been deployed to 100% of its targets, before considering the deployment to be complete. If an alarm is triggered during this time, AWS AppConfig rolls back the deployment.
ベイク時間とは、設定のデプロイが開始され、ステータスが100%になった後、事前に紐付かれた CloudWatch アラームを監視する時間のようです。この時間の間は、デプロイの状態が「ベーキング」となり、CloudWatch アラームが鳴った場合は、AppConfig が自動でロールバックを行なってくれるようです。
先ほどデプロイした時に選択した「AppConfig.AllAtOnce (Quick)」は、ベイク時間が「10分」に設定されていました。そのため、デプロイが開始されてステータスが100%になった後の10分間は、何か問題が発生した時にロールバック可能な時間ということで、新しいデプロイの開始は不可になっていたということです。
CloudWatch アラームと連携してロールバックを行う例が下記のドキュメントに記載されています。本記事ではロールバックについて深掘りしませんが、興味がある方は併せてご参照いただければと思います。
また、デプロイ戦略はデフォルトで用意されている設定以外に、独自のデプロイ戦略を作成できるようなので、デプロイ即完了かつベイク時間無しのデプロイ戦略が作成できるのではないかと思い、実際に試してみました。
デプロイ即完了かつベイク時間無しのデプロイ戦略を作成する
デプロイを開始する画面で「デプロイ戦略を作成」をクリックします。
設定する値は下記の通りです。
- デプロイタイプ：リニア
- ステップパーセント：100
- デプロイ時間：0
- 処理時間：0（表記揺れですが「処理時間」=「ベイク時間」になります）
この設定は、先ほど選択したデプロイ戦略「AppConfig.AllAtOnce (Quick)」のベイク時間を「0」にしただけの設定になります。
作成したデプロイ戦略の挙動を確認する
新しく作成したデプロイ戦略の挙動を確認していきます。
デプロイを開始する画面で、先ほど作成したデプロイ戦略が選択されていることを確認した後「デプロイを開始」をクリックします。
すると、すぐさま「完了した割合」が100%、「状態」が完了と表示されるようになりました。
再度、機能フラグの属性を編集して、バージョン「3」を作成します。その後「デプロイを開始」をクリックします。
そのまま「デプロイを開始」をクリックします。
すると、エラーが発生することなく、デプロイを開始することができました。
ということで、独自で作成したデプロイ戦略により、待ち時間なしで再デプロイ可能な設定の挙動を確認することができました。
おわりに
再デプロイする度に待ち時間が発生してしまうと色々困りごとも増えてしまうので、その辺を自由に設定できる機能は便利だなと思いました。
ベイク時間を上手く活用することにより、自動でロールバックも可能なので、利用用途によって使い分けができれば良いんじゃないかなと思います。CloudWatch アラームとの連携も便利そうなので時間がある時に試してみようと思います。
今回は以上になります。最後まで読んで頂きありがとうございました！
4
