======
前置き
日本語でのElastic Beanstalk (以下単にBeanstalkと長いので呼びます。)の情報が意外とまだまだ少ないようなので、自分の中でのレビューも兼ねてまとめておきます。(node.jsアプリですが、他の場合も基本は一緒なはずです。)
Beanstalkでのデプロイ方針の全体像
現状自分の関わっているBeanstalkを使用しているアプリケーションでは、以下の流れでデプロイを行っています。基本AWSからデフォルトで提供されている機能しか使っていません。
- S3にビルドをアップロード
- API / CLI経由でのデプロイ
- Blue / Greenデプロイメント
以下、個別に詳細を見ていきます。
デプロイ準備: S3にビルドをアップロードする
現状以下のステップでビルドの作成／アップロードを行っています。
- npm install
- 対象フォルダをzipでまとめる
- ビルド用S3バケットにアップロードする
ここでは注意点が２つほど：
- npm installはBeanstalkのインスタンスでも再実施されるので、ビルド作成時には必要ないのですが、プライベートリポジトリへのアクセスを開けるのが面倒なことや、スケールアップの時間短縮のためにビルド作成時に実施しています。
- ビルド用S3バケットは対象Beanstalk Applicationと同じリージョンにある必要があります。
実際のコードのデプロイ: API/CLIでのデプロイ
初期の頃は、AWS CLIでaws elasticbeanstalk create-application-versionとaws elasticbeanstalk update-environmentの組み合わせで行っていたのですが、もう少し細かく制御するために最終的にPythonでのスクリプトを書いています。ただし、やっているい事は、create applicationでS3にアップロード済みのzipファイルの紐付け／ラベルを作成し、そのラベルを指定して既存の環境を更新することだけなので、CLIと大きくは変更はないです。
Blue / Green デプロイメント
現状フローは、Code Deployの機能追加前に確定されたものなので、Code Deployの機能を使わず、以前から存在するBeanstalkの機能しか使っていません。その上で、Blue Green的なデプロイを実現させています。事前準備として、以下のものをセットアップします：
- メインの本番環境(URL例: main-app.elasticbeanstalk.com)
- デプロイ用環境(URL例: main-app-deploy.elasticbeanstalk.com)
流れとしては、以下になります。
- デプロイ用環境に新バージョンをデプロイ (この際、数秒〜数十秒間ながらダウンタイムが発生するが、デプロイ専用URLなので、ユーザーへの影響はなし。)
- 必要であればメイン環境と同じ台数にスケールアップ
- メインの本番環境とDNSネームを交換する。(Beanstalkの SWAP URLsという機能です。)
この流れによって、ユーザーへの影響は一切なく新コードをデプロイすることができます。二度目移行のデプロイは、その段階でデプロイ用になっている環境に対して更新をして同じことをするだけで、問題ないです。
この方式のデメリットとしては、最低1台デプロイ専用にインスタンスを遊ばせておく必要があること、DNSネーム交換でのデプロイなため瞬時には切り替わらないこと、などがありますが現状大きな問題にはなっていません。
その他
いずれはCode Deployを使用したDNSに頼らないデプロイに切り替えたいのですが、30%〜50%の余裕を本番クラスターに持たせるのももったいないので検討だけで終わってます。。