Immutable InfrastructureとBlue-green Deployment 第03回 16年09月 / 最終更新：2016.09.01
みなさん、こんにちは。エンジニアの古庄道明です。
今回は、前回のお話しにありました「daemonのバージョンアップにある程度追随できる手法」についてお話しをさせていただければ、と思います。
特にクラウドに限らない手法としては、構成管理ツール(サーバ設定ツール)というものがありまして。
「Chef」「Ansible」「Puppet」「Fabric」などが存在します。
厳密には、上述のうちFabricのみ「冪等性」がないのですが(冪等性を授けるライブラリが存在します)、基本的には構成管理ツールは、大体「冪等性」を謳っています。
冪等とは本来的には数学の用語で「同じ動作を何回やっても同じ結果になる」事を意味しますが、構成管理ツールの世界でも意味合いとしては同じになります。
これが、口で言うのは簡単なのですが、サーバのインストールの世界観で「きっちり」やろうとすると、あちこちの「依存ライブラリ」やらなにやらの関係で、案外と面倒な配慮が必要な事も少なくありません。
上述の構成管理ツール達はその辺りを「頑張って」はいるのですが。
例えばChefですとcookbookというのが「設定を記述したもの」になるのですが、これを自作すると、冪等性を配慮しないと「うまくいかない」事もあり、色々と悩ましいところです。
ただ、冪等性がないと、場合によっては「本番サーバAと本番サーバBが、同じバッチを流しているはずなのに違う構成になってしまっている！」という可能性が出てくるために、インフラエンジニアの方々は、色々と悩んだり苦労をされたりしている状況も、少なからず。
その辺りから「Immutable Infrastructure」という概念が出てきました。直訳すると「不変な基盤(サーバ)」といった感じでしょうか。
端的には「サーバにupdateかけるから難しいのであって、常に『新しいサーバを新規に作れば』その辺を気にしなくてもいいじゃないか」という発想です。
つまり「updateしない ＝ 変更を加えない ＝ 不変」という訳ですね。
daemonをバージョンアップしたい時は「サーバを新しく作って、古いのを破棄する(updateしないで、deleteしたあとnewする)」という方法になります。
言い方を変えると「サーバの使い捨て」です。
物理サーバでこんな事をしたらいくらかかるのかとても不安なところではあるのですが、クラウドですと「新しいインスタンス作ってインストールして」「サーバを置き換える」ですむので、比較的簡単にImmutable Infrastructureを行う事ができます。
ちなみに、Immutable Infrastructureの「新しいサーバを作る」レシピについては、上述の「構成管理ツール」をうまく使ってあげると色々と楽で便利なので、特に相反する概念ではない、という事を書いておきます。
Immutable Infrastructureだと冪等性は必要ないので、Fabricでも普通に問題無くいけます。
まずは「１台」新しいdaemonなりプログラムなりを入れたサーバを作って、まずは「適当なテスト環境」で動かしてみるとよいでしょう。
問題がなかったら、可能であれば一旦「そのマシンのマシンイメージ」を作成しておくと後の作業が楽ですね。
ここから「本番環境のdaemonのupdate」を考えてみましょう。
上述のImmutable Infrastructureの概念に加えて、「Blue-green Deployment」と呼ばれる手法があるので、簡単に解説をしていきます。
まず前提として「今動いている本番サーバ群」がある、とします。これを「Blue環境」とまとめて呼称しましょう。
daemonをバージョンアップして適宜テストをして通って「新しくなった」、入れ替えたいサーバ群があります。これを「Green環境」と呼称します。
端的には
・「新しい」サーバ群である「Green環境」のサーバインスタンスを一式、用意する
・ユーザが見るサーバを、Blue環境からGreen環境にスイッチする
・念のために少し監視。問題があったらBlue環境に切り戻しをする
・問題がなければ、Blue環境のインスタンスを全て破棄する
という、非常にざっくりした、アグレッシブな方法でdaemonのアップデートを行います。
この方法ですと
・万が一の時にも比較的簡単に切り戻しが出来る
・Immutable Infrastructureのメリットが享受できるので「サーバによって微妙に構成が違う可能性」などを完全に排除できる
などのメリットがあります。
ちなみに「どうやってBlue環境からGreen環境にスイッチするのか？」というあたりですが。
・LB(ロードバランサー)などでそういった機能があると楽にできます
・DNSを切り替える。DNSサーバの負荷の問題、TTLの問題や「徐々に入れ替わる」という些か微妙な点はありますが、どの環境でも可能な方法です
のどちらか、が多いと思われます(クラウドサービスによっては、他にも「より便利な機能」が提供されている可能性があります)。
些か、前回の繰り返しになりますが。
daemonのバージョンアップのうち一定割合は「セキュリティフィックス」だったりします。また、内容によっては「ごくまれな一部機能の一部ケース」だったりしますが、内容によっては「かなりシリアス」だったりもします。
もちろん「ごくまれな一部機能の一部ケース」であれば「放置」という選択肢もありだと思いますが、それが「シリアスなセキュリティ問題」であれば、ある程度早急な対応が必要である事もあると思います。
そんな時に。
クラウドであれば、比較的ローコスト、かつシンプルな手法で「daemonのアップデートが出来る」方法があるので。
一度、利用を検討してみてもよいのではないでしょうか。
さて。
今まではどちらかというと「Webサーバ」よりのお話しをさせていただいてました。
ですので、次回はRDBを含む、database周りについて少しお話しをさせていただければ、と思います。
サービス・ソリューション
