クラウドネイティブの5つの主要技術の詳細説明

[[443167]]

0. はじめに

クラウドネイティブ！ついに来ました。クラウドが将来のデジタル世界において最も重要かつ不可欠なインフラストラクチャになることは間違いありません。コードはクラウド上で実行される可能性が高いため、すべてのプログラマーはこれを理解する必要があります。次に、クラウド分野の関連知識を、主要なクラウドネイティブテクノロジー、マイクロサービス間の通信方法、サーバーレスアーキテクチャなどの側面から、わかりやすい言葉で一連のトピックで紹介します。目的はただ1つ、誰かが概念について話しているときに、それが実用的かどうかに関係なく、それを識別できるようにすることです。

1. クラウド ネイティブとは何ですか?

クラウド ネイティブは特定のテクノロジーではなく、動作と設計の概念です。クラウド リソースの使用率とアプリケーション配信の効率を向上できる動作や方法は、クラウド ネイティブと呼ぶことができます。クラウド ネイティブは、コンテナー、サービス メッシュ、マイクロサービス、不変のインフラストラクチャ、宣言型 API などの一連のテクノロジによってサポートされています。

2. クラウドネイティブの代表的な技術

2.1 コンテナ

コンテナの利点は、使用したことがある人なら誰でも知っているので、説明する必要はありません。コンテナを使用すると、アプリケーション サービスを基盤となるアーキテクチャから分離して、完全な移植性 (任意のオペレーティング システムまたは環境でアプリケーションを実行できる機能) を実現できます。アプリケーションが多数の独立したコンポーネントで構成されている場合、各コンポーネントにコンテナーを割り当てることができます。

2.2 マイクロサービス

マイクロサービスは、従来のモノリシック アプリケーションの欠点を解決するために作成されました。分散アーキテクチャ設計コンセプトです。アプリケーション内の特定の機能を分離し、「サービス」として抽象化します。マイクロサービスは、PAAS プラットフォーム上で独立してデプロイしたり、ホスト内で独立したプロセスとして実行したりできる独立したエンティティです。連携できるきめ細かいサービスの使用を促進するために、各サービスには独自のライフサイクルがあります。サービスには、ゲートウェイ API、RPC (リモート サービス呼び出し)、SideCar (以降の記事で紹介) など、複数の方法でアクセスできます。1 つのサービスを変更しても、他のサービスには影響しません。マイクロサービスについては、以前、記事「モノリスからマイクロサービスへ：ソフトウェアシステムを徐々に分離する方法」で詳しく紹介しました。

2.3 サービスメッシュ

サービス メッシュは、サービス間の通信を処理するために使用されるインフラストラクチャ レイヤーです。クラウドネイティブ アプリケーションには複雑なサービス トポロジがあります。サービス メッシュは、これらのトポロジ内でリクエストを確実に配信する役割を担います。実際には、サービス メッシュは通常、アプリケーションとともにデプロイされるが、アプリケーションに対して透過的な軽量ネットワーク プロキシのセットとして実装されます。

サービス メッシュは、サービス間通信を処理するための専用のインフラストラクチャ レイヤーです。最新のクラウド ネイティブ アプリケーションを構成するサービスの複雑なトポロジを通じて、リクエストを確実に配信する役割を担います。実際には、サービス メッシュは通常、アプリケーションが意識することなく、アプリケーション コードと一緒にデプロイされる軽量ネットワーク プロキシの配列として実装されます。"

- ウィリアム・モーガン

SideCar は、コントロール プレーンとデータ プレーンで構成されます。代表的なものはistioで、コントロールプレーンはenvoyを使用する。

サービスメッシュは特定の技術を指すのではなく、ある技術（SideCarなど）を適用することで生まれる形態を指します。サービス メッシュは、コンテナ間のネットワーク設定を使用して、アプリケーション内のさまざまなコンポーネント間の相互作用を制御または変更します。

緑は純粋なビジネスアプリケーションを表し、青はSideCarを表します

具体的な例を見てみましょう。

新しいバージョンの Nginx をテストし、Web アプリケーションと互換性があるかどうかを確認したいとします。新しい Nginx バージョンで新しいコンテナ (Container2) を作成し、現在のコンテナ (Container1) から現在の Nginx Web サーバー構成をコピーしました。ただし、Web アプリケーションを構成する他のマイクロサービス (各コンテナーが個別のマイクロサービスに対応していると仮定)、つまり MySQL データベース、Node.js フロントエンド、ロード バランサーなどには影響を与えたくありません。

したがって、サービス メッシュを使用すると、テストのために Web サーバー マイクロサービスのみを Container2 (新しい Nginx バージョンのもの) にすぐに変更できます。たとえば、Web サイトとの互換性の問題が発生するなどの理由で機能しないと判断した場合は、サービス メッシュを呼び出して、元の Container1 にすばやく切り替えます。これらすべてにおいて、他のコンテナの構成変更は必要ありません。これらの変更は他のコンテナに対して完全に透過的です。

サービス メッシュがなければ、これはコンテナにとって面倒な作業になります。他のすべてのコンテナの構成を 1 つずつ変更し、それらに含まれるサービスを Container1 から Container2 にポイントし、テストが失敗した後にすべてを元に戻す必要があるためです。

2.4.不変のインフラストラクチャ

K8s の不変インフラストラクチャは Pod であり、コンテナ テクノロジーは不変インフラストラクチャの具体的な実装です。 2013 年に Chad Fowler によって提案された将来を見据えた概念: このモデルでは、インフラストラクチャのインスタンス (サーバー、コンテナー、その他のハードウェアとソフトウェアを含む) は、作成されると読み取り専用になり、変更できなくなります。一部のインスタンスを変更またはアップグレードする必要がある場合、唯一の方法は、それらを置き換える新しいインスタンスのバッチを作成することです。

つまり、不変のインフラストラクチャとは、自己完結型で自己記述型であり、異なる環境間で完全に移行できるものなのです。

2.5.宣言的設計

宣言型（宣言型設計）は、命令型または手続き型（手続き型設計）に関連します。宣言モードでは目標状態を記述し、命令モードでは一連のアクションを記述します。この一連のアクションが正しくスムーズに実行されれば、最終結果として、物事は期待する目標状態に到達します。 SQL は実際には、開発者が必要なデータを指定できるようにする一般的な宣言型の「プログラミング言語」です。

次の 2 つのコマンドを見てみましょう。

 docker サービスの作成  --name nginx --replicas 2 nginx  
 docker サービスの更新  --image nginx:1.7.9 nginx  

Docker Swarm を使用して 2 つの Nginx コンテナ インスタンスが起動されました。最初の create コマンドは 2 つのコンテナを作成し、2 番目の update コマンドはそれらを新しいイメージに「ロール」します。

では、K8s で 2 つの Nginx コンテナを作成して更新するにはどうすればよいでしょうか?

まず、Deployment yaml ファイルをローカルに記述する必要があります。

 APIバージョン: アプリ/v1
種類: デプロイメント
メタデータ:
名前: nginx-deployment
セレクタ：
一致ラベル:
アプリ: nginx
レプリカ: 2
テンプレート：
メタデータ:
ラベル:
アプリ: nginx
仕様:
コンテナ:
 -名前: nginx
画像: nginx
ポート:
 - コンテナポート: 80

次に、kubectl apply コマンドを使用してデプロイメントを作成します。

 kubectl を適用 -f nginx.yaml

このようにして、Nginx デプロイメントが作成されます。次に、nginx.yaml で定義されているイメージを変更します。

 ...
仕様:
コンテナ:
 -名前: nginx
イメージ: nginx:1.7.9

yaml ファイルを変更した後、次の kubectl apply コマンドを引き続き実行します。

 kubectl を適用 -f nginx.yaml

この時点で、K8s はこのデプロイメントの「ローリング アップデート」を直ちにトリガーします。 kubectl apply は、元の API オブジェクトに対して PATCH 操作を実行することと同じです。要約すると:

いわゆる「宣言型」とは、期待する状態を「宣言」するために、定義された API オブジェクトを送信するだけでよいことを意味します。希望する状態を実現するための具体的な操作は、ツールによって内部的に実装されています。

「宣言型」API を使用すると、複数の API 作成者が、ローカルの元の YAML ファイルの内容を気にすることなく、PATCH 方式で API オブジェクトを変更できます。

3. クラウド ネイティブは何をもたらすのでしょうか?

クラウド ネイティブの利点は明らかです。

• アジャイル
• 信頼性のある
• 高い弾力性
• 拡張が簡単
• 障害分離保護
• 業務を中断することなく継続的に更新

これにより、R&D の効率が向上し、日々の反復が加速され、新しいテクノロジの実装が迅速化され、自動テストが容易になり、運用および保守コストが削減されます。同時に、クラスター リソースを最も効率的に使用できるマイクロサービス設計と動的リソース管理に重点を置いています。