前回の用語説明はIaCで終わりまいしたのでこのPart2ではロールバック、ブルーグリーンデプロイメント、カナリアリリースからお話しいたします。
目次
高いSLOを達成するためには、常にサービスを利用可能な状態にしておく必要があります。そのための重要な仕組みとして、ロールバックがあります。
これまでのオンプレ環境では定期メンテナンスなどを予めスケジュールし、週末の夜間などに「現在メンテナンスのため利用ができません」などのSorry PageといわれるWebページを表示するようにしておき、その間に本番環境を直接パッチ適用、新しい機能のリリースやバージョンアップ作業を行い、一通りのテストを実施しした後、予定されている再開時間までにもとのサービス提供URLへフロントのロードバランサーにて切り替えを行うといったやり方が主流でした。
ただこの方法だと新しくリリースしたバージョンが不具合などで遅延や最悪の場合システム停止を引き起こす要因ともなり、可用性や信頼性に大きな影響を及ぼしてしまうという問題がありました。
クラウド環境では本番環境と全く同じスペックの環境をIaCなどによりオンプレよりも遥かに簡単に確保することができるようになりました。そしてすべての更新作業が完了しリリースした本番環境にテストでは露呈しなかった問題などが発生した場合でも、直前のバージョンに自動的に戻すことによりサービスの可用性を下げずに運用を続けられます。その後本番環境の運用が軌道に乗ったあとは、リソース節約のために、この場合もIaCでコマンド一発ですべての環境を削除し、コストを最小限に抑えながら安全にリリース作業を完了することも可能になりました。
ブルーグリーンデプロイメントはロールバックを実現するための一つの方法です。現在問題なく稼働している環境をブルーとすると、それとは別の環境をグリーンとして用意し、そこに新しいバージョンをデプロイします。一時的にはブルーとグリーンの両方の環境が稼働する状態です。フロントのロードバランサーなどでブルーへのアクセスの一部もしくは全部をグリーンに振り替えます。もし振り替えたときに問題が発生したら、ブルーに戻すことにより障害を最小限に抑えてデプロイ作業を行うことができます。
オンプレでこれをやろうとするとデプロイ時に本番環境と同じ環境を別途用意する必要があり、デプロイが成功した後に用意したテスト環境が無駄になってしまい、コスト的に難しかったのです。クラウドであれば使った分だけしかコストは掛からないので、無事にデプロイが完了したらテスト環境を破棄すれば無駄なコストはかかりません。
カナリアリリースとは昔炭鉱で事故が発生した時、炭鉱の中に入るときにカナリアをかごに入れてそれを鉱夫が自分よりも前に出して入ることにより、いち早くガス漏れなどの異常に気づくことができるといった方法からカナリアリリースという名前がつけられました。
ブルーグリーンデプロイメントは現行環境と新規環境をあるタイミングでロードバランサーにより一気に切り替えますが、カナリアリリースはすべてのリクエストのうち数パーセントずつ新規環境に振り分けていき障害の可能性を最小限に抑えながらリリースを完了できるという違いがあります。
イミュータブルインフラストラクチャを日本語にすると「不変のインフラ」と訳されます。一度サーバーを構築したらその後はその環境を変更するのではなく別途用意したバージョンで環境ごと置き換える、といった仮想化やクラウドを基盤としたインフラの考え方です。
OSやインフラ環境を更新する場合、既存の環境に修正パッチやセキュリティパッチを当てて問題のある部分を改修するのがこれまでの考え方でした。オンプレでは本番環境と全く同じテスト環境を用意するのは難しいため、夜間の利用者の少ない時間帯に一旦システムを停止し、本番環境に直接パッチを当てて(もちろんその前にバックアップなどは取りますが)、一通りのテストを行った後問題がなければユーザーのアクセスを許可するなどしていました。これは計画停止として事前にユーザーなどには通知するものの、一定時間サービスが利用できなくなる時間が発生します。
イミュータブルインフラは本番環境にはパッチなどを直接当てるなどはせず、別途用意したテスト環境で問題を解決した環境が用意できた時点でユーザーからの新しいアクセスを新しい環境に振り分けるという方法を取ります。これにより、ユーザーから見ると知らないうちにパッチなどが適応された新しいバージョンのサービスを利用するようになり、計画停止なしで最新の環境へ移行が完了します。万が一、新しく用意した環境にまだ問題が発見された場合、正常に稼働していた元の環境にユーザーからのアクセスを誘導することによりユーザーには障害を露呈することなくサービスの提供を継続することが可能になります。
この方法によりSLOもしくはSLAを維持しながら新しいサービスのリリースだけでなく、問題改修やパッチの適応なども計画停止なしにサービスの提供を続けることができるようになります。
コンテナときいて最初にイメージするのは大きな貨物船の上に積み上げられた鉄の長方形の箱のようなものではないでしょうか。貨物船はクラスタ化されたサーバー郡などのアプリケーションを動かすための土台で、その上に隙間なく積み上げられたコンテナがアプリケーションというふうに見ることができます。
もしコンテナのような容器がなければ、個々の荷物を積み上げてなんとか荷崩れしないように上からネットやワイヤーのようなもので落下しないようにしなければなりません。コンテナを使えば、クレーンなどで大量の荷を船の上に整然と並べ、より多くの荷物を効率的に運搬できます。
この考えをデータセンター内のサーバーリソース上に様々なOS、コンフィグレーション、アプリケーション設定、ネットワーク設定をDockerファイルという定義ファイルにまるで荷物リストのように記述するだけで、必要な数だけうまく仮想環境上に配置してくれるのがkubernetesです。
オンプレでの開発、特にレガシー環境ではサービスをリリースするまでに最適なCPUやメモリの計算が非常に難しく、また通常はマシン単位でOSのバージョン、コンフィグレーション、アプリに必要となるライブラリのインストールなど多くの作業が必要でした。OSや言語が違えば、それに必要となるライブラリなども違ってくるため、通常は一つのハードウェアには複数の混在したOSや言語などを設定することは少なく、別々の環境を用意することも当たり前でした。
データセンター内でサービスごとに、必要とされる環境とサーバーを個別に正しく設定するような作業こそが自動化すべきトイルと考えられます。またこの状況をデータセンター全体で見たら、あるサービスは常にアクセスが多くリソースをぎりぎりまで使い、あるサービスはリソースに余裕があるといったハードウェアとアプリケーションのリソース配分バランスが取れていないことも問題でした。
この状況をクラウドインフラ上にコンテナとkubernetesを導入することにより、常に最適な環境設定を自動化することが可能になります。SLOを実現する際にCI/CD同様、最適なリソース配置の自動化の仕組みとしてコンテナ技術とkubernetesのようなオーケストレーションによってデータセンター全体の運用自動化の仕組みが必要となるわけです。
次回の章でインシデント発生した時の考えかたについてご説明します。
→次の章へ続く【第6章 -Part3】SREに必要となる開発環境を理解するための用語解説
Follow me!