1983年、私がまだApple ][eでハードウェアを直接読み書きする方法を学んでいた頃、コンピューター業界と通信業界の志を同じくする人々が集まり、Open Systems Interconnection（OSI）と名付けた詳細な仕様を策定しました。当初は実際のインターフェースについて議論を重ねる取り組みでしたが、やがて共通参照モデルへと発展し、IETFなどの組織がインターフェースを開発する際に利用できるようになりました。そうして開発されたインターフェースは、最終的にIP、TCP、HTTPなどの標準になり得るものであり、実際に標準となりました……
この参照モデルは、大学でコンピューターサイエンスの授業に苦労して取り組んだ多くの人が学んだものです。「OSIの7階層」について学んだものの、実際の環境では、実装がOSIネットワークモデルにきれいに対応することはほとんどありません。
それでも十分に対応しているため、当初の意図どおり、現在も参照モデルとして使用されています。一般に、レイヤー4はTCP、レイヤー7はHTTP、レイヤー2/3はIPとEthernetを指すものと理解されており、これらの用語はほぼ同じ意味で使われています。
数年前には、SDNや仮想ネットワークに関連するオーバーレイプロトコルが厳密にはどのレイヤーに属するのか、議論になったことさえあります。レイヤー2とは言い切れず、かといってレイヤー3でもなく、その中間のような位置付けでした。
その点はほとんど気にせず、2つのレイヤーを漠然と指して、単に「オーバーレイネットワーキング」と呼ぶことで済ませられました。誰もがその意味を理解していましたし、クラウドの定義や、DevOpsがエンタープライズに適しているかどうかなど、ほかにも議論すべきことがあったからです。
そこに登場したのがコンテナ、より正確にはコンテナネットワーキングです。変化が激しく自動化されたコンテナオーケストレーション環境（COE）の世界では、ネットワークスタックにさらに多くのレイヤーが必要になっています。
オーバーレイネットワーキングと同様に、OSIモデルに新しいレイヤーを設けることには消極的です。というのも、OSIモデルは今や標準的な参照モデルであり、標準の変更には長い時間がかかるからです。本当に、途方もなく長い時間がかかります。しかし、オーバーレイネットワーキングと同じく、これらのレイヤーはネットワークスタック内に実在するインターフェースとして存在しています。そして、COEにおけるネットワーキングの将来にとって非常に重要であるため、オーバーレイネットワーキングと同様に「半分」のレイヤーとして位置付けたいと考えています。
レイヤー4.5：サービスメッシュ
最初の「半ステップ」は、レイヤー4と5の間にあります。ここでサービスメッシュの実行と自動化が機能します。簡単に言えば、サービスメッシュは、すべてのリクエストをインターセプトするサイドカーとしてデプロイされたプロキシで構成されます。これにより、コンテナ環境全体でサービスに対するドメイン固有のルーティングを実行できます。サービスメッシュは下位プロトコルの存在を前提とし、実質的にそれらを拡張します。これは、その下位にあるすべてのネットワークレイヤーが、接続とルーティングはIPアドレスのみに基づくことを前提としているため必要です。コンテナ環境でパケットが移動する仕組みは、最終的にはIPアドレスに基づいていますが、特定のリクエストを送信する送信先のIPアドレスとポートは、その情報に基づいて決まるわけではありません。サービスやアプリケーションの状態と場所に関連するさまざまな変数に基づいて決まります。つまり、リクエストに関するメタ情報を参照し、それを使用してルーティング方法を決定します。このメタ情報は「メッシュ」の構築に不可欠であり、そのメッシュによって各サービスの可用性とスケーラビリティが確保されます。
レイヤー7.5：サービスタグ
2つ目の「半ステップ」は、レイヤー7より上の最上部付近に位置します。「人間レイヤー（レイヤー8）」にまつわる冗談はさておき、COEは実際にアプリケーションの上位にメタデータのレイヤーを配置します。これは、コンテナ化された環境でスケーリングを機能させる「接着剤」の役割を果たします。これが、COEによる自動スケーリングの対象となる個々のサービスを識別するための、アプリケーションまたはサービスの「タグ」です。タグがなければ、アプリケーションを相互に区別することはほぼ不可能です。OSIスタックの各レイヤーは、IPアドレスやポートなどの特定の構成要素によって識別されるためです。こうした構成要素を環境の外部で共有するアーキテクチャ実装（仮想サーバーやホストベースのネットワーク）については以前から理解されてきましたが、コンテナによって同じ問題が環境の内部にも生じています。ポートやIPアドレスを共有すると、求められる速度でサービスを区別することが難しくなります。
コンテナ化環境のレイヤー7.5に「タグ」を追加することで、ロードバランシングやルーティングなどのネットワークサービスはリソースを一意に識別し、スケーラビリティと可用性を同時に確保できるようになります。
新たな「コンテナレイヤー」により、環境をネットワーク構成要素から切り離すことができ、その結果、ネットワークスタックの他のレイヤーと密接に結び付いていた従来のテクノロジーよりも高い可搬性を確保できます。「ハーフレイヤー」で動作し、従来のレイヤーの存在を前提とすることで、コンテナ化環境は特定のネットワーク方式やアーキテクチャに依存せず、開発環境とテスト環境、テスト環境と本番環境、オンプレミスとクラウドの間を同じように容易に移行できます。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。