【Elastic Beanstalk】AWSサービスしりとりリレー 第3日目

皆さんこんにちは。
AWSサービスしりとりリレー3日目担当の川合です。

私の担当は、【Elastic Beanstalk】となりますので、このサービスについて記事にしたいと思います。

今回は、色々種類があってややこしいデプロイ方法について記事にしたいと思います。

Elastic Beanstalk とは

アプリケーションのコード や Dockerファイルをアップロードするだけで、コードを動かすインフラ部分を自動で構築してくれるサービスになります。

普段構築しているEC2でもインフラを用意する事は出来ますが、EC2を作成するにしても

• VPCのネットワークはどうするか？
• EC2を作成するAZはどこにするか？シングル構成なのか、マルチ構成なのか？
• アプリケーションの日々の運用はどうするのか？
• そもそもOSのメンテンナンスはどうするのか？
  いざインフラを用意するにしても考慮する点が多数あったりします。

その点 Elastic Beanstalk ですと、いくつかのプリセットが予め用意されています。
インスタンス設定など各設定毎に内容を簡単にカスタマイズする事が出来るので、インフラ構築の敷居がかなり低くなっています。また柔軟にカスタマイズが可能です。

また、アプリケーションのバージョンアップに伴う切り替え作業にも今回記事にするデプロイポリシーが大活躍します。切り替え作業はかなり神経を使う作業ですし、失敗した場合にすぐに元に戻してサービスを復旧させる必要があったり大変な作業です。

デプロイポリシー

Elastic Beanstalk には、5つのデプロイメントポリシーが用意されています。

• All at once (一度にすべて)
  デプロイの時間が一番短いけれど、サービスの断時間を許容する必要があるポリシー

• Rolling (ローリング)
  断時間を許容できないが今あるインスタンスを利用して更新するポリシー　

• Rolling with additional batch(追加バッチによるローリング)
  断時間も許容できず尚且つデプロイ中に新・旧のインスタンスが混在するが全体的なインスタンス数は維持したいポリシー

• Immutable (イミュータブル)
  今あるインスタンスを更新せず、新しいインスタンスで処理をするポリシー
  切り替えが完了するまで新・旧の環境が平行稼働

• Traffic splitting(トラフィック分割)
  こちらも新しいインスタンスで処理をするが、さらにトラフィックを制御して
  振り分け先を変更するポリシー

コードのデプロイ先を意識する

デプロイポリシーによって、コードがデプロイされるインスタンスが既存のものなのか、それとも新規に用意されたインスタンスにデプロイされるのかの違いがあります。

既存インスタンス

今動いているアプリケーションに上書きするイメージです。
今あるインスタンスにデプロイしますので、デプロイの完了までの時間は短くなります。
ただし、更新中の既存インスタンスがその間利用出来ないというデメリットがあります。

新規インスタンス

逆に今度は新しいインスタンスを別途用意して、そちらにアプリケーションをデプロイします。
アプリケーションのデプロイの前に、インスタンスを用意する時間が加算されますのでデプロイ全体の作業時間が長くなってしまうデメリットがあります。
ただし、既存インスタンスは触らないのでアプリケーションのデプロイ中でもサービスを継続利用出来るメリットがあります。

ロールバック、切り替えを意識する

デプロイ先の意識とは別に、ロールバックと切り替えについても考える必要があります。

ロールバック

何かミスがあった、コードに問題があり予期せぬ不具合が見つかった等で前のバージョンに戻す事が必要になる場合があります。

コードのデプロイ先の話と関連して、既存インスタンスと新規インスタンスで差異があります。

既存の場合は既にアプリケーションが新しいものに置き換わっているので、元々のバージョンに戻す必要があります。
上書きしてしまったデータを別の所で保存していた前のデータに置き換えるようなイメージ。

逆に新規インスタンスの場合は、元々の既存インスタンスが存在するのでそちらを継続利用すれば問題ありません。そのため異常な新規インスタンスを削除さえしてしまえば元に戻ります。

切り替え

何もミスがなく作業が終われば、後は切り替えるだけになります。
既存インスタンスの場合だと、既に中身が更新されているので実質切り替えは終わっています。
そのまま同じインスタンスで新しいバージョンを試せます。

逆に新規インスタンスの場合だと、新規インスタンスに切り替える必要があります。
既存インスタンスでサービスが提供され続けているので、それを新規インスタンスに振り分けます。

Blue/Green

厳密には、デプロイメントポリシーではありませんが、切り替えの手法のオプションとして利用する事が可能です。
環境自体を2セット用意して、接続先をまるっと新しいものに切り替えてしまうイメージです。
コスト面には目をつぶるとして、断時間、ロールバック、切り替え方法 全てが完璧なようにも見えたりするのですがDNSの更新が発生するので、ユーザーの動線を制御するのが難しかったりします。

まとめ

今回は、Elastic Beanstalk のデプロイに関連する内容について記事にしてみました。
実際に記事を書くにあたって以前理解していた内容ではありましたが、少し忘れていた部分もあったので内容をもう一度整理出来たような気がします。

通常のEC2インスタンスではこのような流れであったり実際の作業を自分達でより詳細な作業まで実施しないといけないですが、Elastic Beanstalkではこれらがコンソールから触る事で簡単に作業を行うことが可能です。

基本的に外部にリリースされているサービスでいつでもサービスが停止してもよいというものはなかなかないかと思います。定期メンテナンスの時間をしっかり確保できるのであればいいですが、中々時間も確保しづらい場合もあるので条件に応じてポリシーを使い分ければいいかと思います。