【One Tech #10】運用目線からデプロイ戦略について語ってみた！

ローリングアップデートとは、サーバ一台ずつ順番にデプロイを実施してリリースする方法です。サーバーを一つずつ順番に切り離して、デプロイ作業を実施します。

一部旧バージョンを残しているため、ロールバックがしやすい利点があります。

また、サーバを一つずつ切り離していくため、全サーバが遮断される時間が無くダウンタイムがゼロになります。

一方で、一時的に新バージョンと旧バージョンが混在するため、バージョン管理のコストが高くなります。

また、ユーザがどちらのバージョンにもアクセスする可能性があり、新旧バージョンでの互換性が無い場合にはこの方法は利用不可になります。互換性を考慮していないと、新旧バージョンの差異によるサービス障害が発生してしまいます。

ブルーグリーンデプロイ

稼働中サーバー（ブルー側）とは別のサーバー（グリーン側）に対して新バージョンをデプロイする方法です。動作確認が問題なければ、ブルー側を切り離して、グリーン側接続して新バージョンを公開します。

デプロイ中も旧バージョンのブルー側が稼働しているため、ダウンタイムがゼロになります。さらに、新バージョンで問題があった際は、グリーン側を切り離してブルー側を接続することで、すぐにロールバックが可能です。

また、ブルー側とグリーン側に分かれているため、新旧バージョンが同時に実行されない面で安全性が高く、バージョンの管理コストもローリングアップデートよりは低いです。

その分、ブルー側とグリーン側に分けるため、2倍のリソースが必要になります。

イミュータブルデプロイ

イミュータブルデプロイメントとは、デプロイの完了後に旧環境を削除する手法です。ブルーグリーンデプロイとは旧環境を削す点で異なります。 

グリーン側に新バージョンをデプロイし、動作確認に問題なければ切り替えを行い、ブルー側の旧環境は削除してしまいます。

旧環境を残さない分、ブルーグリーンデプロイよりは運用コストの削減が可能となりますが、ロールバックする場合は再度旧バージョンをデプロイする必要があります。

シンボリックリンク切替

シンボリックリンク切替とは、稼働中のサーバーの別の環境にデプロイを実施し、アプリケーションの起動リンクを新バージョンに切り替える手法です。

この手法のメリットは、サーバ稼働中にデプロイ作業が可能であり、リソースも少なくて済みます。デプロイ作業の自動化も可能となります。

ただし、サーバーの再起動が必要な場合があり、場合によってはダウンタイムが発生します。

また、稼働中のサーバに対して作業を行うため、作業のミスによる障害も懸念点です。

カナリアデプロイ

カナリアデプロイは、ブルーグリーンデプロイのグリーン側にデプロイを行った後、少しずつ新バージョンへ移行していく方法です。

まず一部のユーザにのみ公開して新バージョンの検証をし、不具合が起きないか確認します。問題が無ければ、様子を見ながら徐々に公開範囲を増やしていきます。

ダウンタイムがゼロであり、旧バージョンも動いているためロールバックもすぐにできます。

また、新しいバージョンを本番環境で試して様子を見ながら新しいバージョンに移行できるため、障害が起きにくくなるという利点もあります。

一方で新バージョンの完全な公開までに時間がかかる問題があります。

また、一時的に新旧バージョンの管理や公開範囲の管理が必要となり、運用コストが高いです。

運用視点での比較

さて、ここまで様々なデプロイ方法について紹介してきました。最後に私個人の視点で、運用面から見たデプロイ手法のメリット・デメリットを比較したいと思います！

運用で大切なのは、以下にサービスを「安定して」「安全に」「コストをかけず」実施することかと思っております。そこで、今回は比較の項目を、私なりに以下に分類しています。

　安定＝「ダウンタイム」、「ロールバックの速さ（障害復旧のスピード）」
　安全性＝「障害の起こりにくさ」
　コスト＝「リソース（環境コスト）」と「管理の煩雑さ（人員コスト）」

コストに余裕があるなら、下記の３つの優先順位は明らかです。

　ブルーグリーンデプロイ＞イミュータブルデプロイ＞ローリングアップデート

コストに制限がある場合は、新旧バージョンの互換性によってローリングアップデートと従来のデプロイを分けるのが良いのではないでしょうか。

あくまでの私の主観にはなりますが、シンボリックリンク切替のような、安全性が懸念されるものは推薦しにくいです。（環境にもよりますが・・・）

障害が発生すればその分コストもかかりますし、メリットもあまり活かせないかと思います。

カナリアデプロイはコストに余裕があれば最良ですが、管理の煩雑さも間違いなく一番です。管理の煩雑さは裏を返せば、管理によって有用な運用ができるということです。

常に進化するIT業界では、新バージョンが公開できないのは痛手です。しかし、限定したユーザにのみ公開できる点でデプロイ自体は早期に実施できます。問題をしっかりと監視・管理しながらリリースを順調に進めることで、結果的に早期の新バージョン公開も可能になります。

新バージョンで起こりうる問題を管理しながら、公開範囲も決めていくのは難しいですが、工夫次第で有用性は高い方法だと思います。

まとめ

これまで、運用目線から「デプロイ戦略」について解説していきましたが、いかがだったでしょうか？

デプロイは開発・運用が大きく関わる部分であり、DevOpsの観点からもデプロイ戦略は大切だと思います！

安定・安全・コスト等色々な面があり、一概に何が良いとは言えませんが、臨機応変に対応するのも運用で大切なことだと思っています。

有用なデプロイ方法を選択していくだけでなく、選択したデプロイ方法を如何に運用で活用できるか、というのは運用の腕の見せ所ではないでしょうか？

まだまだ未熟ですが、常に良い運用ができるようなエンジニアになれるよう精進して参ります！

次回の【One Tech】もお楽しみに〜！