クラウドネイティブの不変インフラストラクチャ

著者: Yu Leichun、PaaS 製品部門、中国モバイルクラウド機能センター

前回の記事では、コンテナとコンテナオーケストレーションテクノロジーについて説明しました。この記事では、上記のレイヤーである不変インフラストラクチャについて簡単に整理したいと思います。

01不変インフラストラクチャとは何ですか?どう理解すればいいですか?

クラウドネイティブに詳しい人は、クラウドネイティブには現在、コンテナー、サービスメッシュ、マイクロサービス、不変インフラストラクチャ、宣言型 API という 5 つの代表的なテクノロジーがあることを知っています。その中でも、不変インフラストラクチャは他の 4 つの概念よりも理解するのが困難です。

インターネット上の不変インフラストラクチャにはさまざまな定義があります。より代表的な説明は次のとおりです。

不変のインフラストラクチャとは、展開後に変更されないサーバー (または VM) を指します。

人生には、不変のインフラストラクチャの例が数多くあります。不変のインフラストラクチャとそれに対応する可変のインフラストラクチャについて説明するために、「水」を例に挙げてみましょう。

現実には、農村地域や比較的後進的な山岳地帯に住んでいる場合、水資源を入手することは比較的困難です。私たちは水資源の使用にもっと注意を払うつもりです。米をといだ水は野菜を洗うのに使い、野菜を洗った後の水はモップを洗うのに使い、モップを洗った後の水はトイレを流すのに使うといった水資源の使い方も考えられます。この種の水資源の利用は可変的なインフラストラクチャと見なされます。都市に住んでいると、水は不変のインフラとして使われます。蛇口をひねると、使用済みの水は直接下水道に流れます。このような水資源の使用は再利用されません。

現実からコードに戻ると、実は、コード内の不変インフラストラクチャと可変インフラストラクチャについても多くの考えがあります。

図1

開発者は、コーディング時に不変のインフラストラクチャが必要となるシナリオに遭遇する可能性もあります。 Java や C++ などの言語では、パラメータを渡す場合を含め、変数を変更不可能にする機能が提供されています。制限が課せられている場合、変数を変更するときにコンパイルエラーが発生します。不変データを変更する場合は、別の変数を宣言して不変データの変更をサポートする必要があります。経験豊富な開発者は、不変データによってコードロジックが明確になり、エラーが減り、同時実行がシンプルになることを知っています。並行プログラミングでは、変数が読み取り専用として宣言されている場合、並行して変更するときに制御のために変数をロックする必要はありません。これは並行性における不変性の考え方です。

実は、「イミュータブル・インフラストラクチャ」という言葉が初めて登場したのは2013年のことでした。その後、Dockerがもたらした「コンテナ時代」やk8sが主導する「クラウドネイティブ時代」によって、イミュータブル・インフラストラクチャという概念はますます普及していきました。共通サーバー、仮想マシン、コンテナはすべてインフラストラクチャと呼ばれます。

02不変インフラストラクチャの利点と特徴は何ですか?どうやって変身するの？

周知のとおり、クラウドコンピューティングの登場により、環境標準化のコストは削減されましたが、ビジネス提供のコストは依然として非常に高くなっています。

クラウドネイティブテクノロジーのアーキテクチャを以下に示します。

図2

不変インフラストラクチャに対応するのは可変インフラストラクチャです。従来の開発では、ソフトウェア開発が完了したら、テストまたは正式な展開のためにサーバーに展開する必要があります。開発担当者や運用・保守担当者は、インストールや展開の作業を実行するために、クライアントを介してサーバーに接続する必要があります。また、複数ノードのサーバー展開を考慮すると、対応する設定項目（環境変数など）は、各ノードの設定パラメータを一つずつ変更する必要があります。その後のアップグレードで、電子商取引での頻繁な更新や反復など、各ノード環境の変更が必要になる場合、これらの環境で発生する一部の操作が完全に解決されることはほとんどなく、その後の変更でさまざまな奇妙な問題が発生することがよくあります。インフラストラクチャは非常に脆弱かつ敏感になり、比較的小さな変更でも予測できない結果につながる可能性があります。これは非常に頭の痛い問題です。トラブルシューティングには豊富な技術的蓄積が必要であり、長い時間がかかります。

開発者の観点から見ると、時間と空間における不変のインフラストラクチャの一貫性は、特にビジネス側の問題のトラブルシューティングを行うときに非常に役立ちます。時間の認識に関しては、アプリケーションが特定のサーバーにデプロイされ、一定期間（たとえば 100 日間）実行される場合、サーバーの状態はまったく同じままであるため、トラブルシューティングの効率を大幅に高めることができます。スペースの面では、アプリケーションが R&D 領域またはテストドメインに展開されていても、Linux または Windows に展開されていても、スペースは一貫しています。

可変インフラストラクチャに関するよくある質問:

サービスに対する頻繁かつ継続的な変更により、サービス運用に多くの中間状態が導入され、ソフトウェアのエントロピーが増加し、未知のリスクが増加します。
障害が発生した場合、展開中に高可用性ノードに依存する新しいサービスレプリカを迅速に構築することは困難です。
標準化が難しく、納品や運用のプロセスが非常に面倒です。 Ansible や Puppet などのデプロイメントツールを通じて提供することはできますが、基盤となるさまざまな異機種環境に対する適切なサポートを保証することは難しく、バージョンドリフトの問題がいつでも発生する可能性があります。たとえば、数か月前にインストールしたときにはソフトウェアパッケージが正常に動作していたのに、新しい環境にインストールしたら正常に動作しなくなる、といった状況に遭遇することがよくあります。

不変のインフラストラクチャも別のアイデアです。デプロイ後は読み取り専用状態となり、変更することはできません。更新または変更が必要な場合は、新しい環境またはサーバーを使用して古いものを置き換えます。不変のインフラストラクチャは、可変のインフラストラクチャで発生する一般的な問題の多くを回避します。

不変インフラストラクチャの特徴

一貫性

一貫性が最も明白な特徴です。不変のインフラストラクチャは、同じバージョンと構成で一貫性があり、同じマシンを管理するのと同じように大規模なクラスターを管理します。

単純

すべてのマシンとインスタンスは同じであり、拡張と破壊の 2 つの状態のみを持ちます。すべてのシステムは、これら 2 つの状態のみを処理する必要があります。

安全性

すべてのインスタンスは拡張後も変更されず、拡張前に完全にテストできます。セキュリティ担当者はコードをスキャンして、アプリケーションインスタンスに関連するデータがテストされ、安全であることを確認できます。

❖ 従来のアプリケーションは不変のインフラストラクチャにどのように適応するのでしょうか?どのような変更が必要ですか?

従来のアプリケーションの動作環境は、仮想マシンイメージやコンテナイメージなどの特定のサーバーに組み込まれ、プログラムを実行できます。
アプリケーションを実行すると、さまざまな出力が表示されます。アプリケーションの出力タイプを分析して、サーバーから独立させます。

⚠ 注意: これはサーバーとは何の関係もありません。

ローカルストレージに依存するキャッシュを分散ストレージに移動します。
ローカルストレージに依存するファイルを分散ストレージに移動して、ローカルサーバーの再起動や損失の影響を受けないようにします。
ローカルストレージに依存したログ情報は標準出力に転送され、ログ収集サイドカーが収集して要約します。

実際の作業では、不変の機能を完全に実装することは依然として困難です。いくつかのトレードオフが可能です:

ログをディスクに書き込むことができない場合、一部のプログラムを変更するコストが非常に高くなります。 ELK や EFK などのテクノロジーを使用してリアルタイムで同期し、ログが失われないようにすることができます。
分散キャッシュのみに依存するとパフォーマンスに過度の負担がかかる場合、分散キャッシュとローカルキャッシュ間の自動同期メカニズムを確立して、再起動後もローカルキャッシュの損失を修復できるようにします。

まとめると、インフラストラクチャ上のアプリケーションによって生成されたデータがいつでも失われる可能性がある限り、アプリケーションはある程度ステートレスになり、不変のインフラストラクチャを実装できます。不変のインフラストラクチャは概念です。その具体的な実装は、依然としてコンテナや仮想マシン、および分散ストレージなどのサポート機能に比較的依存しています。単一の技術標準に従って実装されているわけではありません。現状を総合的に分析し、この方向で選択的に最適化する必要があります。不変のインフラストラクチャには利点と欠点があります。クラウドネイティブのシナリオでは、利点が欠点を上回ります。分析は次のとおりです。

クラウドネイティブの不変インフラストラクチャはコンテナイメージに基づいており、バイナリコンテンツだけでなく、プログラムの動作に必要な依存環境、基本ライブラリ、システム環境なども含まれており、比較的完全です。
アプリケーション配信の効率を向上できます。不変のインフラストラクチャに基づくアプリケーション配信は、コードまたはオーケストレーションテンプレートによって設定できるため、GIt などの制御ツールを使用してアプリケーションを管理し、環境を維持できます。インフラストラクチャ環境の一貫性により、アプリケーションが開発およびテスト環境、リリース前環境、オンライン運用環境で一貫して実行されることが保証され、開発およびテスト中は正常に実行されてもリリース後に失敗するということが頻繁に発生しなくなります。
水平方向に迅速かつ確実に拡張できます。不変インフラストラクチャの構成テンプレートに基づいて、既存のインフラストラクチャ環境と一貫性のある新しいインフラストラクチャ環境を迅速に作成できます。
インフラストラクチャの迅速な更新とロールバックを保証できます。同じインフラストラクチャテンプレートのセットに基づいて、環境が変更された場合でも、すぐにロールバックして復元できます。すべての環境を更新およびアップグレードする必要がある場合は、インフラストラクチャテンプレートを更新し、古い環境を置き換える新しい環境を作成するだけです。

03K8S はどのようにして不変のインフラストラクチャを実現するのでしょうか?

不変のインフラストラクチャを実現するには、以下に示すようにいくつかの条件を満たす必要があります。

図3

まず、最も基本的な条件はコンテナ化です。アプリケーションをミラーリングする必要があります。依存関係と構成は、Dockerfile、つまりイメージの説明に反映される必要があります。環境と依存関係も、追加のアプリケーションオーケストレーションテンプレートによって明確にオーケストレーションされる必要があります。コンテナ化は不変の施設の基礎です。一般的に、不変のインフラストラクチャはクラウドネイティブの状況でのみ実現できます。これは、コンテナ化を通じてのみ、拡張と縮小全体の効率と一貫性を保証できるためです。

2 番目の条件は、スケーリングを十分に簡単にすることです。スケーリングと置換のプロセスを自動化する必要があります。自動化では、インスタンスが障害を起こす可能性があること、ノードが異常である可能性があること、インスタンスの障害が通常の発生であることを認識する必要もあります。アプリケーションのスケーリングと置き換えの自己修復プロセスを非常にシンプルにする必要があります。最後に、インフラストラクチャの一貫性を確保し、アプリケーションインスタンスファイル自体へのその場での変更を禁止するメカニズムが必要です。ここでのその場での変更には適切なトレードオフが必要であり、インスタンスの生存時間を制御する必要があります。インスタンスが実行されている限り、手動による変更を含め、何らかの変更が (操作プロセス中に) インスタンスに行われます。変更があった場合にソフトウェアシステムのエントロピーが変化する限り、不整合が発生します。

不変のインフラストラクチャにおける k8S の働きはどのように現れるのでしょうか?まず、以下に示すように、k8s でコンテナのステータスを調べる必要があります。

図4

図5

K8s のアプリケーションインスタンスはポッドと呼ばれます。ポッドには複数のコンテナを含めることができます。 Pod は、K8s では不変の基本単位と呼ばれます。アプリケーションインスタンスは、アプリケーションロードコントローラーによって管理されます。アプリケーションロードでは通常、アプリケーションインスタンステンプレートが提供されます。テンプレートでは、アプリケーションインスタンスのメタデータのほか、仕様、イメージ、イメージ名を定義できます。

図6

K8s で不変のインフラストラクチャを実装する主な方法は、ローリングリリースです。ローリングリリースの主なプロバイダーはデプロイメントであり、これはワークロードとも呼ばれるコントローラーです。デプロイメントには、ReplicaSet と呼ばれるワークロードもあります。各 ReplicaSet には、同じイメージ名と同じイメージ構成を持つポッドのコレクションがあります。リリース前は、ReplicaSet V1 のバージョンは 1 つしかありません。リリースプロセス中に、追加の ReplicaSet V2 が作成され、新しい V2 ReplicaSet の容量が拡張されます。拡張された容量は、新しいコンテナオーケストレーション構成を持つポッドです。リリースプロセスはシンプルで、新しい ReplicaSet V2 でのスケールアップと古い ReplicaSet V1 でのスケールダウンに重点を置いています。リリース後、デプロイメントには ReplicaSet が 1 つだけ存在し、プロセス中にポッドの拡張と縮小のみが発生します。これは、k8s で不変のインフラストラクチャを確保するための実装プロセス、つまりリリースと拡張と縮小です。

K8s はクラウドネイティブにおける最良のアプリケーションプラクティスです。ただし、不変のインフラストラクチャを実現するための K8s のローリングアップグレードの適用シナリオには、一定の制限があります。金融業界や伝統産業など、一部のビジネスでアプリケーション IP を保持する必要がある場合、または大企業で大規模なプロモーションシナリオがある場合、特にアプリケーションインスタンスポッドに複数のコンテナーがあり、一部のコンテナーを変更したくない場合は、k8s のローリングリリースではニーズを満たすことができません。

不変インフラストラクチャに対しては、ポッドのインプレースアップグレード機能の再構築、履歴ポッドの定期的な再構築、移行ドリル、アプリケーションインスタンスのエントロピーが大きすぎないことの確認 (定期的な削除) など、実行する必要があることがまだたくさんあります。一貫性を確保するために、不変のインフラストラクチャをより多くのシナリオに適用できます。クラウドネイティブの不変インフラストラクチャの概念を探求し実践する際には、k8s 以外の関連コンテンツも探求する必要があります。 Alibaba のオープンソース Open kruise プロジェクトを参照できます。

04K8Sローリングアップグレードによる不変インフラの実用化の実証

4.1 デプロイメントとレプリカセットのデモンストレーション

nginx のデプロイメントを例に挙げます。

図7

RS の DESIRED: ユーザーが期待する Pod レプリカの数 (spec.replicas の値)。
CURRENT in RS: 現在実行状態にあるポッドの数。
DEPLOY の UP-TO-DATE: 現在最新バージョンの Pod の数。いわゆる最新バージョンとは、Pod の Spec 部分がデプロイメント内の Pod テンプレートの定義と完全に一致していることを意味します。
DEPLOY で利用可能: 現在利用可能な Pod の数、つまり、実行中状態、最新バージョン、準備完了 (ヘルスチェックが正しい) 状態にある Pod の数。

❖ 拡張および縮小操作を実行します。

図8