ネットワークインフラは、イミュータブルなものになれるのか？

Please find the English language post, by Lori MacVittie, from which this was adapted here.

イミュータブルインフラストラクチャ、私は使い捨て可能なインフラストラ チャと呼んだ方がふさわしいと思うのですが、この1年でDockerとコンテナ化技 術の成功によって再び注目を浴びました。また、DevOpsは、自動化と関連する 使い捨て可能なインフラストラクチャの概念と、取得から構成までのすべてを 自動化して、アプリケーションデータパスのあらゆるものを提供する「テンプ レート」の使用を復活させるうえで役割を果たしてきました。

技術トレンドが、昨今のビジネスの核であるアプリケーション開発から、アプ リケーションデータパスの終点であるネットワークに必然的に移行しているた め、ネットワーク インフラストラクチャがイミュータブル(”不変”)である かどうかを考えるのは当然のことです。結局、SDNのようなトレンドによって、 まったく反対の方向、つまり、変わりやすく、非常に活力的な方向に進むこと が目標であることがわかるため、ネットワークのあらゆるものに不変性を適用 することは直感に反することのように思えます。

この問題に答える前に、イミュータブルインフラストラクチャが何を意味する のかについてちょっと考えてみる(場合によっては、再考する)必要があります。

シェフのジュリアン・ダン氏が書いたブログ「イミュータブル インフラストラ クチャ:実用的であるかないか?」を引用しながらお答えします。

イミュータブルインフラストラクチャは一般的に、一度構築し(仮想マシンの イメージ、コンテナのイメージなど)、1つまたは多数のインスタンスを実行し たら、再び変更することはないスタックとして定義されています。開発モデル は、インスタンス/コンテナを終了した後、新しいイメージを構築して、古いイ ンスタンスを捨てるという最初の手順をもう一度やり直すことです。

しかし、なぜそんなことをするのか疑問に思っているかもしれません。よく考 えれば、実際には、時間による変化によって発生した乱雑さが原因だとわかる でしょう。

理由は、エントロピーです。

ソフトウェアエントロピーの法則は、イヴァー・ヤコブソン氏およびその他によ る著書『オブジェクト指向ソフトウェア工学:Use Caseによるアプローチ』で説 明されています。

熱力学の第2法則には、原則として、断熱系の乱雑さは減少することはなく、変 化しないか、増大するだけであると記述されています。この乱雑さの基準がエ ントロピーです。システムを変更すると、その乱雑さ、つまりエントロピーは 常に増大するとされているため、この法則は、ソフトウェアシステムに対して 妥当だとも思えます。これは、ソフトウェアエントロピーとして知られてい ます。

この法則は、ファームウェアまたはシステムレベルの更新を適用しなければな らないシステムに対しても当てはまります。システムには、ホットフィックス やパッチが導入されます。また、緊急の構成変更が必要な場合でも、理想の世 界では、厳密に守られた変更管理プロセスを通してのみ変更しなくてはなりま せん。イミュータブル(使い捨て可能な)インフラストラクチャが解決しよう としている問題は、システムに導入する変更が多いほど、より乱雑になり、不 安定さが増すように見えることです。乱雑で、無秩序なエントロピーです。

それでは、使い捨て可能なインフラストラクチャの概念を考えてみましょう。 稼働中のシステムを変更しないという前提に基づくと、使い捨て可能なインフ ラストラクチャは、パッチやアップグレードとして構成を変更する必要がある 場合、新しいイメージを構築して、既存のものを展開する際に最初に使用した 同じプロセスでそれを展開する必要があると言われています。

そして、古いものを破棄します。

いったいなぜ、そんなことをするのでしょう。

既知のプロセスに従って、インフラストラクチャを作成して展開することが前 提なので、ボブが手動で/etc/resolv.confを編集したかどうかや、外部から新 しいライブラリを追加したかどうかを気にする必要はありません。ボブがそれ を行ったとしても、展開プロセスのコンテキスト内で行っているので、それは インフラストラクチャの既知の状態に含まれています。

これは、インフラストラクチャの外在的な既知の状態を維持するという重要な 概念です。聞き覚えがある場合は、それがSDNの概念とデータプレーンからの制 御の分離と密接な関係があり、ネットワーク全体の状態がわかる集中型のコマ ンドと制御モデルを作り上げているからです。ネットワーク内の個々のノード を変更することはないため、ノードが複雑になることや、アリスがある晩遅く に問題を修正するために追加したルートについて心配する必要はありません。 すべてはネットワークのコントローラで監視されています。

チャド・ファウラ氏は、この概念を「サーバを捨て、コードを焼き付けろ:イ ミュータブル インフラストラクチャとディスポーザブルコンポーネント」でう まく説明しています。

システムが自動で作成され、作成されたときからまったく変更されていないこ とが明らかである場合には、これまでに述べてきた問題の大部分は該当しませ ん。アップグレードする必要がありますか。問題ありません。新しい、アップ グレードされたシステムを構築し、古いシステムを破棄しましょう。新しいバー ジョンのアプリが必要ですか。同じことです。新しいバージョンのサーバ(ま たはイメージ)を構築し、古いものを破棄しましょう。

では、目の前にある問題、つまりネットワークインフラストラクチャはイミュー タブル(使い捨て可能な)インフラストラクチャになり得るか、という問題に 戻ります。

答えは、なり得ます。

次に、海外の有名な‘難しい’クイズ番組「64,000ドルの質問」レベルの最高 難度の問題です。このような使い捨て可能なネットワークインフラストラク チャを、仮想化またはコンテナ化する必要があるでしょうか。

これはちょっと難しい問題です。このようなインフラストラクチャが、大規模 なシステムの一部ではなく、それ自体を展開し破棄できる自己完結型のエン ティティであると仮定した場合、答えはイエスです。逆に巨大ネットワーク上 のサービスの構成ファイルを集めたものを使い捨て可能なインフラストラク チャと呼ぶことはできません。なぜなら、それは使い捨てではない大規模なシ ステムの一部であるからです。インフラストラクチャは自己完結型でなければ ならず、真に使い捨て可能なエンドツーエンドのアプリケーションインフラス トラクチャが求められているのなら、仮想化またはコンテナ化されたソフト ウェアが最適です。

考えなければならない理由

ネットワークインフラストラクチャがイミュータブルかそうでないかを考える 理由は、インフラストラクチャとアプリが近いほど、つまりインフラストラク チャとアプリとの親和性が高いほど、そのインフラストラクチャコンポーネン トを変更した場合にアプリに影響を与える可能性が高くなるということです。 たとえば、負荷分散によってアプリケーションの動作が大きく変わることがあ ります。負荷分散サービスのパッチやアップグレードがアプリに影響を与える 可能性があります。同様に、HTTPベース攻撃を検知して停止させるスクリプト やパフォーマンスを向上させるTCP最適化など、上流サービスは問題に対応する ために外部チャネルで最初に「微調整」されることがよくあります。そのため、 相対的にさらに上流に位置するサービスよりも、エントロピーの悪影響を受け やすくなります。

したがって、アプリ(計算)インフラストラクチャを使い捨てにしようと考え る理由は、上流のインフラストラクチャサービスにも当てはまります。(アプリ ケーションサービス インフラストラクチャを含む)アプリケーションアーキテ クチャスタック全体でのエントロピーの悪影響を抑制するためです。

これはロードバランサを、ネットワークに挿入したハードウェアブリックのペ アとして考えるのを止め、仮想化されているかソフトウェアをベースとする、 クラスタ化の進んだ、アプリごとの、サービスベースのアプローチについての 検討が始められた理由の1つです。このようなアプリケーションサービスの仮想 化/ソフトウェアインスタンスの使い捨てはさらに簡単であり、外在的で自動化 されたプロセスのプロビジョニング、および使い捨て可能なインフラストラク チャアプローチを可能にする展開に適合しやすくなります。

そうすると、これを実用的インフラストラクチャのように、つまりSDNによって 実現されるもののように考えるかもしれません。「v1」の破棄を無視してまった く新しい「v2」を選択した場合、基本的には同じことになります。この場合、 問題は破棄の追加手順によってインフラストラクチャエントロピーが抑制され るかどうかということになります。また、これは利用しているインフラストラ クチャで実際に行われた変更の量に応じて、自分だけが答えを出せる質問でも あります。前提は、変更の量が多いほど、エントロピーも増大するということ です。これまでの変更量によって答えは変わります。

要約すると、ネットワークインフラストラクチャは使い捨て可能(イミュータ ブル)にすることができ、アプリケーションのアプリケーションサービスとの 親和性が高いほど、そのようなインフラストラクチャが使い捨て可能であるこ とから恩恵を受ける可能性が高くなります。DevOpsを採用してアプリケーショ ンインフラストラクチャを実用化している場合は、自分で認識していようとい まいと、使い捨て可能なアプローチに移行中である可能性が高くなります。

では、完全に使い捨て可能なインフラストラクチャを完成させることはできる でしょうか。現実的には問題が発生する可能性があるため、おそらくできませ ん。しかし、本格展開、アップグレード、および計画された変更を管理する方 法から考えて、最終的にアプリケーションインフラストラクチャの一部を使い 捨て可能にすることは十分に可能です。

最終更新日:2015年2月23日