デプロイ手法＠リリース¶
はじめに¶
本サイトにつきまして、以下をご認識のほど宜しくお願いいたします。
01. 品質を高めるデプロイ¶
デプロイが自動化されていること¶
アプリケーションのデプロイまでの各ステップ (ビルド、ホワイトボックステスト、デプロイ) を自動化する。
これにより、デプロイがより簡単になり、ヒューマンエラーを防げる。
DevOpsのCI/CDパイプラインを導入することによりこれを実装する。
ビッグバンデプロイではないこと¶
アプリケーションのデプロイの粒度を小さくし、小さなデプロイを頻繁に実行する。
これにより、人間の確認範囲を小さくし、デプロイ時に予期せぬ問題が起こることを防げる。
アジャイル開発やマイクロサービスアーキテクチャを導入することによりこれを実装する。
デプロイ内容がわかるようにしておく¶
デプロイ内容がわかるように、タスクやプルリクエストに対するリンクを明記しておく。
これにより、デプロイ時の予期せぬ問題を即解決できる。
デプロイノートやPRRモデルを導入することによりこれを実装する。
02. インプレースデプロイメント¶
インプレースデプロイメントとは¶
最初に旧アプリケーションを停止し、サーバーのOSとミドルウェアの構成はそのままで、アプリケーションのみを上書きする。
その後、アプリケーションを再起動する。
ダウンタイムの有無¶
旧アプリケーションの停止から新アプリケーションの再起動まで、に相当する時間のダウンタイムが発生する。
ただし、CodeDeployの様に、ロードバランサ－を使用して、現環境と新環境に対するルーティングを切り替えるようにすると、ダウンタイムを防げる。
技術ツール例¶
- Capistrano
- AWS (CodeDeploy)
- Fablic
- Git (手動で
git pullコマンド) - Istio
03. ローリングアップデート (ローリングデプロイメント)¶
ローリングアップデートとは¶
特にアプリケーションが冗長化されている場合に使用するデプロイ手法。
現環境と新環境のインスタンスの合計数を維持しながら、新環境インスタンスを段階的にデプロイする。
新環境インスタンスが起動が完了したことをヘルスチェックなどで確認し、起動が完了したことを確認できれば、社外を含む全てのアクセスのルーティング先を新環境インスタンスに自動的に切り替えていく。
リクエストできる新環境インスタンスを増やしながら、現環境インスタンスを少しずつ削除していく。
この時、マネージドなデプロイツールを使用すると、ルーティング先の切り替え作業がより簡単になる。
補足として、Kubernetesのアップグレード手法のインプレースアップグレードも、ローリングアップデートに所属する。
類似するブルー/グリーンデプロイメントとの違い¶
ブルー/グリーンデプロイメントとは異なり、冗長化された新環境に自動的に切り替えられるため、開発者のリリース作業の工数が少なくなる。
一方で、フロントエンド領域とバックエンド領域が異なるアプリケーションとして稼働している場合、これらのデプロイを同時に完了できない。
また、新環境の起動のみしか自動的に確認されないため、具体的な動作が正常か否かをリリース作業後に確認する必要がある。
ダウンタイムの有無¶
新アプリケーションの起動を確認してから、旧アプリケーションを停止するため、ダウンタイムが発生しない。
技術ツール例¶
- AWS ECS、AWS EKS)
- Kubernetes
04. ブルー/グリーンデプロイメント¶
ブルー/グリーンデプロイメントとは¶
2個の環境に名前をつける時に、優劣の印象がないように色が選ばれ、色の中でも無難な青と緑になった。
『ブルー/グリーン』という言葉は、これに由来している。
以下の手順で実施する。
(1)-
現環境 (Prodブルー) を残したまま、新環境 (Testグリーン) をデプロイする。
(2)-
開発者のみが新環境にリクエストを送信できるように (例：特定のポート番号を公開する) し、新環境で機能テストを実施する。
(3)-
新環境の動作に問題が起こらなければ、社外を含む全てのアクセスのルーティング先を、新環境に手動で切り替える。
(4)-
新環境に対する切り替えが完全に完了した後、新環境から現環境にロールバックする場合に備えて、現環境は削除せずに残しておく。
何を基点にしてルーティング先を切り替えるかによって、具体的な方法が大きく異なり、ロードバランサーを基点とする場合が多い。
この時、マネージドなデプロイツールを使用すると、ルーティング先の切り替え作業がより簡単になる。
類似する他のデプロイ手法¶
▼ ローリングアップデートとの違い¶
ローリングアップデートとは異なり、開発者のタイミングでルーティング先を新環境に切り替えられるため、フロントエンド領域とバックエンド領域が異なるアプリケーションとして稼働している場合、これらのデプロイを同時に完了できる。
また、特定の動作が正常か否かをリリース作業前に確認できる。
一方で、開発者のリリース作業の工数が多くなる。
▼ イミュータブルデプロイメントとの違い¶
ブルー/グリーンデプロイメントと似たものとして、イミュータブルデプロイメントがある。
これは、ブルー/グリーンデプロイメントと手順はほとんど同じであるが、リリース後に現環境を削除してしまう。
一方でブルー/グリーンデプロイメントでは、現環境はリリース後も削除せずに稼働させたままにしておく。
ダウンタイムの有無¶
新アプリケーションの起動を確認してから、旧アプリケーションを停止するため、ダウンタイムが発生しない。
技術ツール例¶
- AWS (CodeDeploy、ElasticBeanstalk)
- ArgoCD
05. カナリアリリース¶
カナリアリリースとは¶
昔、炭鉱内に一酸化炭素があるか否かを判断するために、炭鉱労働者が自身よりも先に死ぬカナリアを一緒に持ち歩いた。
『カナリア』という言葉は、これに由来している。
現環境と新環境を用意した上で、一部のユーザー (由来のカナリアに相当) の手を借りて新環境を実地的にテストし (例：該当のエラーメトリクスが基準値を満たすか) 、新環境に問題が起こらなければ全てのユーザーを新環境にルーティングする。
システムのユーザーがバグに寛容でないと採用できないリリース手法である。
手順¶
以下の手順で実施する。
(1)-
現環境を残したまま、新環境をデプロイする。
(2)-
一部の一般ユーザーのリクエストのみを新環境にルーティングし、実際のユーザー (由来のカナリアに相当) の手を借りて、本番環境で実地的に検証する (例：該当のエラーメトリクスが基準値を満たすか) 。
この実地的なテストで新環境で問題が起こらなければ、ルーティングされるユーザーを手動で段階的に増やしていく。
(3)-
新環境に問題が起これば、ロールバックとして現環境に対する重み付けを
100%とする。 (4)-
新環境に対する重み付けが
100%になった後、現環境を削除する。この時、マネージドなデプロイツールを使用すると、ルーティング先の重み付け値の変更作業がより簡単になる。
類似するデプロイ手法との違い¶
▼ ダークカナリアリリースとの違い¶
ダークカナリアリリースとは異なり、特定の関係者ではなく、一般ユーザーを新環境にルーティングする。
技術ツール例¶
- AWS (API Gateway、Route53やALBによる重み付けルーティング)
- ArgoCD
06. ダークカナリアリリース¶
ダークカナリアリリースとは¶
特定の関係者 (社員、協力会社) のリクエストのみを新環境にルーティングし、これらの手を借りて、本番環境で実地的に検証する (例：該当のエラーメトリクスが基準値を満たすか) 。
類似するデプロイ手法との違い¶
▼ カナリアリリースとの違い¶
カナリアリリースとは異なり、一般ユーザーではなく、特定の関係者のみを新環境にルーティングする。
07. ダークローンチ¶
ダークローンチ¶
全ての一般ユーザーがルーティングされるデプロイ手法 (例：カナリアリリース以外) と組み合わせる。
ただし、機能をこっそりリリースしておく。
を使用したいユーザーだけがトグルなどで有効化できるようにしておき、本番環境で実地的に検証する (例：該当のエラーメトリクスが基準値を満たすか) 。