新しい OSI ネットワーク スタック: コンテナとハーフレイヤー

1983 年、私がまだ Apple ][e のハードウェアを覗き見る方法を学んでいた頃、コンピューター業界と通信業界の志を同じくする人々が集まり、Open Systems Interconnection (OSI) と呼ばれる詳細な仕様を作成しました。 実際のインターフェースを徹底的に検討する取り組みとして始まったものが、最終的には共通の参照モデルへと変化し、IETF などの他者がインターフェースを開発するために使用できるようになりました。 これらのインターフェースは最終的に標準になる可能性があります。 IP、TCP、HTTP など 

この参照モデルは、大学でコンピュータサイエンスの授業を苦労して受けた私たちのほとんどに教えられてきました。 私たちは「OSI の 7 つの層」について学びましたが、現実世界では、実際の実装が OSI ネットワーク モデルにきれいにマッピングされることはほとんどないことがわかりました。

それでも、十分にマッピングされているため、当初の目的どおりの参照モデルとして引き続き使用できます。 ほとんどの人は、レイヤー 4 が TCP、レイヤー 7 が HTTP、レイヤー 2/3 が IP とイーサネットを指すことを理解しています。 それらはほぼ互換性があります。

数年前には、SDN と仮想ネットワークに関連するオーバーレイ プロトコルが正確にどこに属するかについて議論が交わされました。 それらは実際にはレイヤー 2 ではありませんでしたが、厳密にはレイヤー 3 でもありませんでした。 彼らはどちらかというと中間的な存在でした。

私たちは、ほとんどの場合、それを無視することができ、2 つのレイヤーを漠然と無視して、単に「オーバーレイ ネットワーキング」と呼んでいました。 誰もが私たちの言っていることを理解していましたが、クラウドの定義や DevOps が企業に適しているかどうかなど、他にも議論すべきことがありました。

コンテナ、より正確にはコンテナ ネットワークの登場です。 コンテナ オーケストレーション環境 (COE) の非常に不安定で自動化された世界では、ネットワーク スタックにさらに多くのレイヤーが必要になるようになりました。

オーバーレイ ネットワーキングと同様に、OSI モデルに新しいレイヤーを作成することには消極的です。これは、現時点では標準リファレンスであり、標準の変更には長い時間がかかる可能性があるためです。 平行。 長さ。 時間。 しかし、オーバーレイ ネットワーキングと同様に、これらのレイヤーはネットワーク スタック内の実存的なインターフェイスとして依然として存在します。 また、オーバーレイ ネットワーキングと同様に、これらは COE のネットワーキングの将来にとって非常に重要であるため、私はこれらに「半分の」レイヤーを与える傾向があります。

レイヤー4.5: サービスメッシュ

最初の「半音」はレイヤー 4 と 5 の間にあります。 ここで、サービス メッシュの実行と自動化が役立ちます。 簡単に言えば、サービス メッシュは、すべてのリクエストをインターセプトするサイドカー デプロイ プロキシから構築されます。 これにより、コンテナ環境全体のサービスに対してドメイン固有のルーティングを実行できるようになります。 低次のプロトコルが存在することを前提とし、それを効果的に拡張します。 これが必要なのは、その下のすべてのネットワーク層が接続とルーティングが IP アドレスのみに基づいていることを前提としているためです。 最終的には、コンテナ環境内でパケットが移動されるのはこのような方法ですが、特定のリクエストをどのIP アドレスとポートに送信するかの決定は、その情報に基づいて行われるわけではありません。 これは、サービスとアプリケーションのステータスおよび場所に関連するさまざまな変数に基づいています。 基本的には、リクエストに関するメタ情報を調べ、それを使用してルーティング方法を決定します。 このメタ情報は、各サービスの可用性とスケールを保証する「メッシュ」を確立するために重要です。 

レイヤー 7.5: サービスタグ

2 番目の「半音」は、レイヤー 7 より上の上部近くに配置されます。 「人間層 (レイヤー 8)」に関するジョークはさておき、COE は実際に、コンテナ化された環境でのスケールを実現するための「接着剤」を提供するメタデータのレイヤーをアプリケーションの上に配置します。 これらは、COE が自動スケールを提供する個別のサービスを識別するために使用されるアプリケーションまたはサービスの「タグ」です。 タグがなければ、アプリを区別することはほぼ不可能です。 これは、OSI スタックのすべてのレイヤーが、IP アドレスやポートなどの特定の構成要素によって識別できるためです。 環境外部の構造 (仮想サーバーとホストベースのネットワーク) を共有することに依存するアーキテクチャ実装については長い間理解されてきましたが、コンテナーは環境内で同じ問題を引き起こしてきました。 ポートと IP アドレスを共有すると、必要な速度でサービス間の区別が難しくなります。

コンテナ化された環境のレイヤー 7.5 に「タグ」を追加すると、ネットワーク サービス (負荷分散やルーティングなど) はリソースを一意に識別し、同時にスケールと可用性を確保できるようになります。

新しい「コンテナ レイヤー」により、環境をネットワーク構造から切り離すことができ、その過程で、ネットワーク スタック内の他のレイヤーに密接に結びついていた以前のテクノロジよりも優れた移植性が保証されます。 「ハーフレイヤー」で動作し、従来のレイヤーの存在を前提とすることで、コンテナ化された環境は特定のネットワーク スキームやアーキテクチャから独立し、開発とテスト、テストと本番、オンプレミスとクラウドの間を同じように簡単に移動できるようになります。