今年流行りそうな「インフラエンジニア」向けトレンドのまとめ　その1　(Blue-Green DeploymentとImmutable Infrastructure編)

2024年11月
月	火	水	木	金	土	日
	1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30

あけましておめでとうございます。バズワード評論家横田でございます。(恐らく)皆様1月6日から出社ですね。お仕事がんばりましょう。

というわけで今年のインフラ業界の~~バズワード~~トレンドをまとめてみました。年始の仕事前にどうぞ

《Blue-Green DeploymentとImmutable Infrastructure》
1. 《Blue-Green Deployment(ぶるーぐりーん　でぷろいめんと)》
2. 《Immutable Infrastructure(いみゅーたぶる　いんふらすとらくちゃー)》
《Configuration(コンフィギュレーション)とOrchestration(オーケストレーション)》
1. 《Configuration(こんふぃぎゅれーしょん)》
  1. ○Chef(しぇふ)
  2. ○Ansible(あんしぶる/あんしぼぉ)
2. 《Orchestration(おーけすとれーしょん)》

《Blue-Green DeploymentとImmutable Infrastructure》

今年のインフラ業界の一番のトレンドは「Blue-Green Deployment」と「Immutable Infrastructure」となる気がしています。今までは、サーバの設定を変更する時は、運用中のサーバを変更していましたが、「Blue-Green Deployment」と「Immutable Infrastructure」の考え方は、運用中のサーバの変更するのではなく、新しくサーバ群を用意し、本番環境をそちらに切り替えるという手法を取っております。

手法自体は「Blue-Green Deployment」と「Immutable Infrastructure」も近いのですが、微妙に二つの考え方は違います。

※私は数時間前まで、この2つの考えがゴッチャになっていましたがヌーラボの中村さん・染田さんの解説記事を読んでスッキリしました。「はてブ」で話題になっている物よりも、こちらの解説記事を読むことをオススメします。

それでは、まずは「Blue-Green Deployment」から見てみましょう。

《Blue-Green Deployment(ぶるーぐりーん　でぷろいめんと)》

Blue-Green Deployment(ぶるーぐりーん　でぷろいめんと)とは、2つの環境を用意し、可動している環境をルータやロードバランサで切り替える手法です。具体的には、ブルーとグリーンという2つの環境を作成し、本番環境をルータやロードバランサで、どちらかの環境に割り振っておきます。わかりやすくするために、今回は「ブルー」の環境が割り振られているとします。

この時にブルーの環境に手を入れる場合は、直接ブルーのサーバをいじらず、割り振られていない「グリーン」の環境のサーバを変更し、それが終わった後ルータやロードバランサの振り向け先を「グリーン」にすることで環境を更新します。また、さらに「グリーン」を更新する場合は「ブルー」を更新し、再びルータやロードバランサを切り替えます。

この手法を利用することにより「ブルー」と「グリーン」を切り替えた時に問題が発生した場合は、また「ブルー」と「グリーン」を入れ替えるだけで「復旧」できるというメリットがあります。

[関連リンク]
・BlueGreenDeployment

《Immutable Infrastructure(いみゅーたぶる　いんふらすとらくちゃー)》

この「Blue-Green Deployment」の考えを一歩進めたのが「Immutable Infrastructure(いみゅーたぶる　いんふらすとらくちゃー)」です。Immutable Infrastructureとは「Immutable(不変な)」の意味通り「一度セットアップし運用中のサーバは変更をしない」という運用スタイルです。サーバの設定変更などをしたい場合は、現在運用している環境(サーバ群)を変更せずに、まったく新しい環境を用意し、環境の設定変更が終わったら、ルータやロードバランサ等で新しいサーバ群に切り替えるというものです。

「Blue-Green Deployment」が、新しくサーバの設定をする度に「ブルー」と「グリーン」の環境を入れ替えるのに対し、Immutable Infrastructureは、新しい環境(サーバ群)を立ち上げ切り替えた後は、元々可動していた環境は削除します。従来は、サーバが物理サーバだったため、サーバを用意・購入するだけでも大変だったのですが、近年はクラウドが普及し、即時に仮想サーバが利用でき、さらに「時間単位」でサーバを利用できるようになったため、サーバの即時起動と使い捨てが可能となりました。このため「Immutable Infrastructure」のように、環境(サーバ群)の使い捨てることができるようになったのです。

「Immutable Infrastructure」のメリットして「サーバを設定して変更しないので、長年使い続けて変更を重ねてきたサーバに対し、全てのサーバが同じ状態であることが保証される。」「テストした環境で問題が無ければ、そのまま公開できる。また、公開後に問題があった場合は戻せば良い」といったメリットがあります。

一方デメリットとしては「サーバの使い捨て」をするためにログが残らず、ログを集約化する必要があること、データベースやストレージなどを「使い捨てる」には、まだ難易度が高いということもあります。

ところで「Immutable Infrastructure」ですが非常に言いにくいですよね。先進的な人達には既に「II(あいあい)」という略称が広がっているようです。~~(私はあまり聞いたことがありませんが…)~~

・今さら聞けない Immutable Infrastructure – 昼メシ物語

・Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components – Chad Fowler

《Configuration(コンフィギュレーション)とOrchestration(オーケストレーション)》

昨年は「Chef(しぇふ)」の年だったと言っても過言では無いほどChefが~~ナウいヤング~~先進的な人達にとって話題となりました。ChefやAnsible(あんしぶる/あんしぼぉ)に代表されるConfiguration(こんふぃぎゅれーしょん)ツールは、「構成管理ツール」「サーバ管理ツール」とも呼ばれているもので、サーバの作成やパッケージのインストールなどを自動で行ってくれるツールです。

この「Configurationツール」の他に、最近では個々のサーバの設定だけでなく、大量のサーバの対してアプリケーションをインストールしたり設定を行う「Orchestration(おーけすとれーしょんつーる)」が登場しています。

ここでは主なConfigurationツール、Orchestrationツールをご紹介します。