Elastic BeanstalkでImmutable deployを試す

やり方についてはドキュメントを読むと良い．

docs.aws.amazon.com

option_settings:
  aws:elasticbeanstalk:command:
    DeploymentPolicy: Immutable
    HealthCheckSuccessThreshold: Ok
    IgnoreHealthCheck: false
    Timeout: "600"

設定ファイルでやるならばこういった設定を書き，.ebextensions/ 以下に deploy.config みたいな名前で放り込んでデプロイするとImmutable deployがされる．

最初は素朴なhealth checkベースのrolling deployを試していたのだけど，JavaのApp serverと相性が悪いのか (私はJavaを書いています) 上手くhealth checkが通らない時があり，また場合によってはJavaのプロセスが2個立ち上がったりしてしまってまともにデプロイできなかったので，ものは試しとImmutable deployを試してみたところ上手く行った．

基礎的な動作・挙動についてはドキュメントを参照してもらうとして，immutable deployの利点は

• 新しいインスタンスが立ち上がって，その上にデプロイされるので環境がデプロイごとにクリーン
• 既存インスタンスに対する変更が行われるわけではないのでデプロイ中も安定する

というものが挙げられる．これはディスポーザブルな構成が持つ良い特徴そのもののように思う．
一方で懸念すべき点としては (公式ドキュメントにもあるが)

• デプロイ完了までにかかる時間がかなり増える
• デプロイ中一時的にインスタンス数が2倍になる
  • オンデマンド制限に引っかかる可能性がある
  • もちろんお金がかかる

と言うものがある．
前者については「一台だけ新しいインスタンスを立ててデプロイする」->「health checkが通るかどうか確認する」->「health checkが通るのであれば残りのインスタンスも立ててデプロイする」->「health checkが通るかどうか確認する」->「health checkが通るのであれば新しいインスタンス群をauto scaling groupに突っ込む」->「古いインスタンス群をauto scaling groupからterminateする」という手順を踏むのでそれは時間が長くなるだろうなという感じ．急ぎのデプロイの時は中々ヒリヒリしそうなので，場合によってはhealth checkをスキップしたり，別のデプロイ手法を試したりする必要がありそうだと思った．
後者についてはもうそういうもんだと割り切るしかあるまい……2倍の数のインスタンスが必要となるのはデプロイ時だけなので寛容な心が必要であろう (オンデマンド制限については考えなければならないだろうが)．

とはいえEC2も秒単位の時間課金になったので，かつてよりはImmutable deployもやりやすくなったんじゃないでしょうか．良い時代になりましたね．
それにしても日本語化されたドキュメント上で「Immutable」を「変更不能」と訳すの，気持ちはわかるんだがそれはどうなんだ……