![[Elastic Beanstalk] 新しいデプロイメントポリシー、イミュータブル（immutable）を試してみた](https://devio2023-media.developers.io/wp-content/uploads/2014/05/Elastic_Beanstalk.png)
[Elastic Beanstalk] 新しいデプロイメントポリシー、イミュータブル（immutable）を試してみた
はじめに
AWSチームのすずきです。
AWSにより提供されている、アプリケーション環境の構築、管理サービスAWS Elastic Beanstalk、 先日（2016年4月）のアップデートにより、新しいデプロイメントポリシー（immutable、Rolling additional batch）の指定が可能になりました。
AWS Elastic Beanstalk で、 2つの新しいデプロイメントポリシーとAmazon Linux AMI 2016.03 が利用可能に
従来のElastic Beanstalk アプリケーションのデプロイは 既存のインスタンスに対し上書きされる形で実施されていたため、デプロイ中にサービス影響が及ぶなどの 問題になる事がありました。
新たに追加されたデプロイメントポリシー「immutable」、AWSの日本語コンソール上で 「変更不可」と表示されているポリシーを利用すると、 新しいバージョンのアプリケーション環境用として新規のEC2インスタンスが用意され、 クリーンな環境に対するデプロイが実施されるようになりました。
今回、稼働中のElastic Beanstalk アプリケーション環境を利用して、 「immutable」なデプロイメントポリシーを利用してデプロイを実施する機会がありました。 デプロイ作業中のEC2環境の動作などについて紹介させていただきます。
事前準備
新しいElastic Beanstalkデプロイメントポリシーは、プラットフォームバージョンとして2.1.0以降を必要とします。
古いプラットフォーム、2.0.8以前を利用されている場合、プラットフォームバージョンの更新が必要です。
プラットフォームを2.1.0に更新する事で、AmazonLinuxのリリースは2016.03に更新されます。 OSやカーネルバージョンに依存するアプリケーションやミドルウェアをご利用の場合ご注意ください。
実行環境情報
- プラットフォーム: 64bit Amazon Linux 2016.03 v2.1.0 running PHP 5.6
- インスタンスタイプ: t2.micro
- インスタンス数: 4台
- アプリケーションサイズ: 18MB（ZIP圧縮状態）
更新とデプロイメントの設定
- デプロイメントポリシーの変更は、Elastic Beanstalk環境の設定画面、「更新とデプロイメント」より可能です
従来の「1回にすべて」（All at once)、「ローリング」（Rolling）に加え、
- 追加バッチとローリング（Rolling additional batch)
- 変更不可（immutable）
の選択が可能になりました。
今回検証は、ポリシーとして変更不可（immutable）を指定しました。
今回のElastic Beanstalkのアップデートにより、EC2のインスタンスタイプやプラットフォームの変更など、 EC2インスタンスの交換時に用いられるポリシーも「ローリング更新のタイプ」として指定出来るようになりました。
デプロイ操作
- AWSコンソールの「アップロードとデプロイ」より、Elastic Beanstalk アプリケーションのデプロイを実施しました。
- 「デプロイメント レファレンス」として、デプロイメントポリシーの都度指定も可能になりました。
デプロイ中の動作
- 変更不可（immutable）のポリシーでデプロイ中の、オートスケールグループと、EC2インスタンスの挙動を確認しました。
新規Auto Scaling グループの設置
- 新しいアプリケーション環境の動作確認環境として、名称に「immutable」を含むAuto Scaling グループが新規に生成されます。
1台目のEC2インスタンス起動
- 1台目のEC2インスタンスが起動します。
2〜4台目のEC2インスタンス起動
- 1台目のEC2インスタンスのヘルスチェックに成功すると、名称に「immutable」を含むAuto Scaling グループの希望台数が1→4台に追加されました。
- 2，3，4台目のEC2インスタンスが起動します。
- 新旧あわせて8台のEC2インスタンス、稼働状態になりました。
Auto Scaling グループの変更
- 新環境の4台のヘルスチェックに成功すると、新環境のEC2インスタンスは、 名称に「immutable」を含むAuto Scaling グループから、元々のAuto Scaling グループへの移動が行われます。
*インスタンスの移動完了後、名称に「immutable」を含むAuto Scaling グループは削除されます。
旧環境の縮退
- 古いアプリケーション環境のEC2インスタンス、撤去が行われます。
- 並行稼働時間は1時間以下、冗長稼働に伴うAWS費用の追加は0.08$ （t2.micro単価:0.02$×4台）でした。
- Auto Scaling グループ設定のEC2インスタンス数、デプロイ前の台数に戻ります
デプロイ完了
- 全てのデプロイ処理が滞り無く完了すると、Elastic BeanstalkのステータスがOkとなります。
イベント
- Elastic Beanstalkのイベント情報の詳細は以下の通り
- EC2インスタンス4台の入替の所要時間は27分でした。
まとめ
従来のElastic Beanstalk、デプロイに伴う事故が許容されない環境では、
- 新規eb環境設置
- 新eb環境に新アプリケーションをデプロイ
- 新eb環境の動作確認
- 新eb環境のインスタンス数調整
- 新旧eb環境をDNSスイッチで入替
- 旧eb環境を撤去
とした作業をしていましたが、今回のアップデートでより効率的に実施できる可能性が高まりました。
また、Elastic Beanstalkでは「.ebextention」に配置したカスタム設定ファイルにより、 任意のミドルウェアやライブラリの追加が可能ですが、 パッケージの名称変更や後方互換性の失われた場合、EC2インスタンスの起動時期により不整合が生じたり、 設定などの冪等性（べきとうせい）の確保が困難、結果切戻しに失敗するなどの問題が 生じる事もありました。
今回利用可能となったElastic Beanstalkのデプロイポリシーの利用により、 よりシンプルな管理とリスクを抑えた運用が可能となる効果も期待できると思われます。
数年前にクラウドの特性を活かした運用スタイルとして注目された、 一度セットアップしたらサーバは二度と変更を加えないというイミュータブル インフラストラクチャー。 AWS Elastic Beanstalkであれば、過剰なサーバリソースや工数などを必要とせず 実用レベルで実現できる可能性が高まりました。是非その活用をご活用ください。
