コンテナ／マイクロサービスが機能する鍵は「DNS」：Dockerコンテナとネットワーク（後編）

コンテナを動的に立ち上げてマイクロサービスとして機能させるには、各コンポーネントが相互にリンクしていなければならない。そのために必要なものとは？

[Daniel Robinson，Computer Weekly]

　前編（Computer Weekly日本語版　10月17日号掲載）では、Dockerを巡るネットワーク事情について基礎からKubernetesおよびCNIまで解説した。

　後編では、前回紹介しきれなかった「VMware NSX」その他のCNIをサポートするツールと、ネットワーク関係でさらに考慮すべき事項について解説する。

Computer Weekly日本語版　11月7日号無料ダウンロード

本記事は、プレミアムコンテンツ「Computer Weekly日本語版　11月7日号」（PDF）掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

• Computer Weekly日本語版　11月7日号：意外な所に潜む コンプライアンス違反

なお、同コンテンツのEPUB版およびKindle（MOBI）版も提供しています。

VMware NSX＆その他のツール

　CNIをサポートするプラットフォームの一つに「VMware NSX」がある。NSXは、既存の物理イーサネットに複数の仮想ネットワークを作成して管理できるSDNシステムで、基本的には仮想ネットワークトラフィックを転送するためのパケット転送バックプレーンとしてそのインフラを使用する。これらの仮想ネットワークは、それぞれが独自のIPアドレス範囲やその他の特性を保持することができる。

　実際のNSXには2つのバージョンがある。一つは「NSX-V」とも呼ばれ、「VMware vSphere」と密接に統合されている。もう一つのバージョン「NSX-T」は「KVM」などの他のハイパーバイザーと連動するように開発されていて、これは「Linux」や「OpenStack」をサポートするために重要になる。

　どちらのバージョンも、同じノードで実行されているVMやコンテナ間のトラフィックに直接対処する仮想スイッチとして機能する。対象が別のノードで実行されているVMやコンテナの場合、仮想ネットワークパケットは標準のイーサネットパケットにカプセル化されて、そのノードで実行されている仮想スイッチに送信される。

　この他にも同様の機能を備えるプラットフォームがある。Microsoftは「Windows Server 2016」からSDN機能を組み込んでいて、例えば各ノードで実行される「Hyper-Vネットワーク仮想化」や、3つのHyper-V VMのクラスタで実行される一元的な管理サービス「ネットワークコントローラー」がある。

　OpenStackは「Neutron」というネットワークサービスにより、ユーザーがネットワーク接続性を設定、定義することを可能にするAPIを提供する。このサービスはNeutronサーバと、サーバノードで実行されるエージェントで構成される。また「Open vSwitch」、Midokuraの「ミドネット」、Juniper Networksの「OpenContrail」、Cisco Systemsの「NX-OS」、NSXなどのネットワークプラットフォームとNeutronが連動できるプラグインも備える。OpenStackはKubernetesの他にも「Magnum」サービスを通じて別のコンテナオーケストレーションツールもサポートする。ただし、NeutronもCNIに準拠している。

　セキュリティもコンテナの導入における重要な要素の一つで、さまざまなスケールで実行される場合は特に重要になる。物理ネットワークと同様、あの手この手でインフラに侵入しようとする攻撃からアプリケーションを保護するため、ファイアウォールやその他のセキュリティポリシーを実装する必要がある。だがコンテナ間のトラフィックが全く保護されていないことがよくある。

　コンテナを相互接続する仮想ネットワークは複雑なので、コンテナネットワークトラフィック内で起きる事象を監視するのにオーケストレーション層やSDN層が最適になる。

　SDNベンダーはセキュリティも考慮に入れている。例えばVMwareは、ネットワークの仮想化と同様にインフラ保護の点でもNSXを売り込んでいる。各コンピューティングノードで実行される分散ファイアウォールを効果的に提供するNSXは、外部からのパケットと同じくらい容易にインフラ内のトラフィックをフィルタリングできる。

軽量なコンポーネント

　マイクロサービスに話を戻す。このアーキテクチャの主な特徴は、コンポーネントが軽量で、通常は単一の機能を実装することだ。こうしたコンポーネントが相互にリンクされて完全なアプリケーション機能を提供する。つまりコンテナ内のコードは、他のサービスを検出してそのサービスが仮想ネットワークのどこに存在するかを特定できなければならない。

　そのための方法は多数あるが、DNSを使ってIPアドレスではなく名前でサービスを検索するのが一般的な方法の一つだ。これによりIPアドレスの変更が可能になる。IPアドレスはコンテナインスタンスが稼働／廃棄されるときに変更される。事実、Docker 1.10以降およびKubernetes 1.11以降は、この目的のためだけにEmbedded DNS Serverが実装されている。

　他に負荷分散という要素もある。マイクロサービスアーキテクチャの目的は、特定機能の別のインスタンスを生み出してアプリケーションを拡張できるようにすることだ。その後インフラは、トラフィックを各インスタンスに確実にルーティングしなければならない。Kubernetesは、負荷分散を行うために同一のサービスのコピーにラウンドロビン方式でパケット転送する「kube-proxy」モジュールを使用する。だがこれだけでは確実に十分といえず、「HAProxy」「nginx」「Istio」などの他ソフトウェアのツールを使って負荷分散を実装しなくてはならない場合がある。

厄介ごと

　コンテナのネットワークサポートは少々厄介だ。コンテナベースのDevOps導入が大掛かりになるにつれてその複雑さは増す。従って多くの企業が、コンテナベースのインフラを稼働させるために必要なほとんどの機能、または全ての機能を統合する既製のプラットフォームを利用している。

　「Red Hat OpenShift」などのコンテナをサポートするPaaSからPivotal Softwareの「Pivotal Container Service」（PKS）といったプラットフォームまで、その選択肢は多岐にわたる。PKSにはNSX-TやKubernetes、そしてプラットフォーム全体の監視とライフサイクル管理を実行する「BOSH」というツールが含まれている。ただしコンテナの運用に特化しているため、開発者向けの機能は充実していない。一方、OpenShiftは最初からDevOps向けの継続的な統合サポートを提供している。

　自身で統合するか、複雑な作業のほとんどをプラットフォームに任せるかは自由だ。いずれにしても、あらゆるコンテナとマイクロサービス戦略では、ソフトウェア制御下で構成／再構成できるネットワークが不可欠になっていくだろう。

別冊Computer Weekly　Chrome OS＆Chromebookのススメ

Googleの戦略転換により、Chrome OSとChromebookの企業利用は加速するのか。Windows に対するChrome OSのアドバンテージ、Windows PCをChromebook化する方法、Pixelbook の長期レビューをまとめた。

• Chrome OS＆Chromebookのススメ