F5製品およびサービスでのDockerコンテナ技術の活用
エグゼクティブサマリー
ITニーズの変化とアジャイルな開発・デプロイ戦略の登場により、「コンテナ化」が普及してきました。これは、アプリケーションを独自の実行環境とともにコンテナ内にカプセル化する、マシン全体の仮想化に代わる手法です。コンテナ化は、開発者がより迅速に反復開発を行える有用なソリューションです。また、仮想マシンに伴うオーバーヘッドを軽減するという利点もあり、Software-Defined Data Center（SDDC）におけるリソース使用率の向上につながります。
コンテナ化は新しい概念ではありませんが、Docker, Inc.が開発したDockerは、業界からの幅広い支持、標準化、包括的で多岐にわたる機能により、最適な実装として広く取り上げられています。同社によると、Dockerは「分散アプリケーションを構築、配布、実行するためのオープンプラットフォームです。プログラマー、開発チーム、運用エンジニアが、最新アプリケーションの分散型かつネットワーク化された特性を活用するために必要な共通のツールセットを提供します」。このように、Dockerは開発からデプロイまでのアプリケーションライフサイクル管理を簡素化し、アプリケーションの可搬性を実現します。アプリケーションには、パブリッククラウドやプライベートクラウドインフラストラクチャなど複数のホスティングオプションがあるため、この簡素化は企業にとって極めて重要です。
本書では、F5テクノロジーにおけるコンテナの活用と、アプリケーションデリバリおよびセキュリティを目的としたDockerのサポートに関するF5の方向性を概説します。この戦略について説明する前に、データセンターの課題と、次世代のエンタープライズアプリケーションデリバリにこれらのテクノロジーが不可欠である理由を理解することが重要です。
注：本書は、IT部門の意思決定者、アーキテクト、開発者を対象としています。読者が仮想化技術、ソフトウェア開発、リリースライフサイクルプロセスに関する予備知識を有していることを前提としています。
データセンターインフラストラクチャの課題
データセンターインフラの課題に関する最近の複数の調査から、データセンターの進化に必要な共通の要件が明らかになっています。
- アプリケーションをより迅速にデプロイする方法
- 改善されたワークフロー管理プロセス
- コンピューティングリソースの可用性と利用率の向上
- 必要に応じてワークロードを移動できる俊敏性の向上
アプリケーション開発に新たなトレンドが生まれる中、企業のお客さまは、アプリケーションライフサイクル管理モデルに対する考え方を次のように変えつつあります。
- 次世代アプリケーションでは、「クラウドファースト」を前提とした構築がますます進んでいます。
- Linuxは、クラウド開発における事実上の標準オペレーティングシステム（OS）となっています。
- 次世代クラウドアプリケーション：
- ステートレスになるよう設計され、疎結合のマイクロサービスアーキテクチャを採用しています。
- ソフトウェアのバージョンやサービスへの依存関係なしに、各サービスを独立して構築できるフレームワークを利用します。
- 企業では、ソフトウェアリリースの俊敏性を高めるため、構成管理ツール（Puppet、Chef、Ansibleなど）やDevOpsオーケストレーションを活用した自動化の導入が進んでいます。
- 企業が新しいアプリケーションを開発し、既存のアプリケーションをパブリッククラウドへ移行する際、ベンダーロックインを回避するにはポータビリティが重要です。仮想マシン（VM）テクノロジーは一定の抽象化を実現しますが、ハイパーバイザーごとに環境の実装が異なるため、完全なポータビリティは確保されません。
Dockerは、こうした課題への対応を目指しており、インフラストラクチャを仮想化するための有力かつ魅力的なテクノロジーとして台頭しています。
Dockerの概要
コンテナは、各アプリケーションをOSプロセスとして分離することで、OSレベルの仮想化を実現します。この概念は、BSDのJails、Oracle SolarisのZones、そして近年ではLinuxのLXCなど、さまざまな形でOSに採用されてきました。DockerはLXCを基盤とし、ハイパーバイザーを必要とせずに、開発者がクラウドインフラストラクチャ全体でアプリケーションを簡単にビルド、パッケージ化、デプロイできる仕組みを追加しています。
Dockerは、以下の機能によって他のコンテナ技術と差別化されています。
- アプリケーション間の分離とネットワークを管理する、OS上の軽量な抽象化レイヤー（Dockerエンジン）。
- Linuxベースのアプリケーションのデプロイを簡素化する、文書化されたアプリケーションプログラミングインターフェース（API）。
- 他のユーザーや開発者とアプリケーションを共有するためのDocker Registry。
- 物理、仮想、クラウドホスト型を問わず、Docker対応ホスト間でアプリケーションを移植できます。
- すべてのDockerコンテナに共通のファイルシステムを提供するユニオンファイルシステム。
- 付加価値サービスやソフトウェアを提供するパートナー企業のエコシステムにより、Dockerを多様な開発ワークスタイルにスムーズに統合できます。
ユニオンファイルシステムとは
ユニオンファイルシステムでは、基盤となるパスとファイル名が基盤ファイルと重複する場合でも、各コンテナがそのコンテナ固有のサービスを提供できます。たとえば、あるコンテナではPythonライブラリのバージョン2.6が必要で、別のコンテナではそれより新しいバージョンが必要になる場合があります。基盤となるファイルシステムがバージョン2.6を提供していれば、一方のコンテナの要件は満たされます。一方、新しいバージョンを必要とするコンテナは、そのバージョンをコンテナイメージの一部として提供できます。そのため、コンテナイメージには実行に不可欠なものだけを含めればよく、フットプリントを削減できます。
Dockerコンテナ化と仮想マシン技術の概要
図1の図は、VMおよびDockerによるアプリケーションのデプロイで使用されるコンポーネントを示しています。この例では、VM方式で2つのアプリケーションをサポートするために、2つのゲストOSが使用されています。一方、Dockerでは、同じアプリケーション密度を実現するために必要なホストOSは1つだけであり、当然ながらオーバーヘッドも低減されます。
次の表は、VMとDockerの機能を比較したものです。
仮想マシン上のDocker
前述のとおり、Dockerの主な目的は、アプリケーションのライフサイクル管理を簡素化することです。ベアメタル上でDockerを実行する構成は確かに魅力的な選択肢ですが、ハイパーバイザー上で実行することにも利点があります。たとえば、ゲスト全体のスナップショットを作成し、ライブマイグレーションを行うことができます。これらはいずれも、処理中の状態を失わずに災害復旧を行ううえで重要な要件となる可能性があります。
VMware vRealize SuiteやOpenStackなどの主要なインフラストラクチャ管理・オーケストレーションソリューション、およびAWSやAzureなどのパブリッククラウドは、いずれも各種ハイパーバイザー上でDockerをサポートするとともに、Dockerコンテナに共通の環境を提供します。これにより、環境を問わずアプリケーションのポータビリティを確保できます。このような異種混在型の導入モデルでは、基盤となるインフラストラクチャを変更することなくDockerの利用を開始し、より迅速に反復できるというメリットを得られます。
ホストごとにVMとOSを1つずつ配置する構成に移行すると、VM間でリソースを奪い合う必要がなくなるため、リソース面でもメリットが得られます。メモリとローカルディスクをその単一のOSに割り当てることができ、ハイパーバイザーが複数のOS間でリソースを調整する必要もなくなるため、効率が向上します。
Dockerネットワーキング技術概要
Networkingを使用すると、複数のホストにまたがる仮想ネットワークをDocker Engine内に作成できます。コンテナは場所を問わずこれらのネットワークに接続できるため、ネットワークトポロジーや、各コンテナが通信できる他のネットワーク要素を完全に制御できます。さらに、ネットワークを支えるシステムはプラグインで置き換えられるため、アプリケーションを変更することなく、任意のネットワークシステムと統合できます。
任意のホスト上で高密度のコンテナ配置に対応するには、各コンテナがネットワークに参加する仕組みを理解することが重要です。Dockerでは、デフォルトで各コンテナにプライベートアドレスが割り当てられます。このアドレスに直接アクセスできるのは、同じホスト上にある別のコンテナのみです。
別のホストからサービスがコンテナに到達するには、Dockerのiptablesベースのネットワークアドレス変換（NAT）機能を介してルーティングする必要があります。例を図2に示します。
ホストインターフェース（Eth0）は、別のアドレス（この場合は別のRFC1918アドレスである192.168.10.10）を使用して公開されます。各Dockerコンテナには、起動時に172.x.x/16のアドレス空間からアドレスが自動的に割り当てられます。コンテナがホスト外部のエンティティと双方向に通信するには、iptablesを通じて明示的なルールセットを割り当てる必要があります。
図2の例では、コンテナがIPアドレスとポートのマッピングを介して通信できるようにルールが設定されており、コンテナAは192.168.10.10/ポート80、コンテナBは192.168.10.10/ポート81として公開されています。ただし、コンテナCが他の2つのコンテナと通信する際に使用できるのは、172.17.0.xのアドレスのみです。
DockerはIPv6にも対応しており、完全にルーティング可能なアドレスを使用できます。これにより、アドレスマッピングを行わずに、異なるホスト上のコンテナ同士で通信できます。ただし、これはIPv6でのみ機能するため、環境によっては適用範囲が限られる場合があります。
SDNとDocker
多くのソフトウェア定義データセンターでは、ゲストを柔軟にデプロイするために、ソフトウェア定義ネットワーキング（SDN）の概念を採用しています。SDNでは、同じ物理ハードウェア上の独立したテナントごとに、分離されたネットワークトンネルを構成できます。また、本来は完全にルーティングされるクラウドデータセンター内で、トンネル化されたレイヤー2を提供する場合にも役立ちます。DockerネットワーキングはDocker Bridgeの概念を基盤としており、Open vSwitchに接続することで、VXLANやGREなどのテクノロジーとの相互運用が可能になります。
このようにOpen vSwitchを使用すると、マルチテナンシー向けにレイヤー2ネットワークを分離できるほか、他の仮想化環境に接続することも可能になります。たとえば、Dockerを利用するデータセンターでも、必要な専用リソースが明確で、それを確保すべき主要サービスには、引き続き仮想マシンが使用される可能性があります。これには、アプリケーションデリバリーサービスや、データベース、処理ノードなどの高性能リソースが該当します。あるテナントのトラフィックが別のテナントから見えないように、これらのリソースをVXLANやGREなどのテクノロジーを介してネットワークに接続できます。
この種の環境でアプリケーションをスケーリングするには、トンネリングプロトコルにネイティブで対応できるADCサービスが必要です。F5はマルチテナント対応のVXLANおよびGRE機能を提供しており、ロードバランシング、SSLオフロード、ファイアウォール、アプリケーションセキュリティ、NAT、DNSなどのサービスを、トンネル経由でネットワーク上のクライアントに提供できます。さらにF5は、802.1Q VLANを含む各種トンネルカプセル化方式間の相互運用性を提供します。
図3の例では、データベースなどのコアアプリケーション層が、Dockerインスタンスのホストに使用するリソースとはデータセンター内の別の場所に配置される場合があります。この場合、テナントネットワークではGREまたはVXLANを使用して、物理的に分離された2つのサブネットを隔離しながら接続できます。
BIG-IPインスタンス上にVXLANトンネルエンドポイント（VTEP）を作成することで、BIG-IPソリューションをテナントレベルでネットワークにシームレスに組み込むことができます。これにより、BIG-IPソリューションはテナントネットワークの一部となり、Dockerインスタンスおよび仮想マシンインスタンスに接続できるようになります。
バージョン1.7以降、Dockerは、SDNの概念を取り入れて基本的なDockerネットワーキング機能を拡張する、いくつかの試験的機能の提供を開始しました。このプラグインアーキテクチャにより、アプリケーションを認識するコンテナを使用した次世代ファイアウォール、コンテナフローの分析とポリシー適用、フロー単位のトラフィック管理など、さまざまな新しいユースケースにF5のネットワークおよびアプリケーションデリバリサービスを組み込める可能性が広がります。
Dockerコンテナ化に関するF5の方針
F5は、仮想化を実現するさまざまな製品を提供しています。業界で最も幅広いL4～L7のアプリケーションデリバリおよびセキュリティサービスのポートフォリオを擁するADC市場のリーダーとして、F5は革新的なテクノロジーを継続的に探求しています。また、共通の基盤フレームワークを採用しているため、これらのテクノロジーをBIG-IPプラットフォーム全体に展開しています。図4は、カスタムハードウェアからL4～L7サービス向けの包括的なクラウドベースのas-a-service製品まで、F5の幅広い製品ラインアップを示しています。BIG-IPプラットフォームは、Dockerコンテナ上で稼働するアプリケーションのサポートに適しています。
DockerによるF5プラットフォームの進化
前述のとおり、F5はさまざまなユースケースにおけるDockerのメリットを認識しています。しかし、コンテナ化されたインフラストラクチャへの導入はまだ初期段階にあり、サービスディスカバリ（Consul、etcd、Mesos-DNSなど）、オーケストレーション、コンテナサービスのライフサイクル管理（Mesos、OpenStack、Kubernetes、Docker、Cloud Foundryなど）には複数の選択肢があります。ネットワークサービスはこのエコシステムの重要な要素ですが、シームレスな導入を実現するには、オーケストレーション環境との緊密な統合が重要です。また、このような統合は、コンテナ化されたインフラストラクチャにマイクロサービスベースのアプリケーションを導入するユーザーが、L4～L7サービスを透過的に利用できるようにするうえでも不可欠です。F5のアプローチは、ベアメタル、仮想化、コンテナ化のいずれの導入環境でも、サービスと可視化に関して一貫したエクスペリエンスを提供することを目指しています。
この問題を解決するための第一歩は、ノースサウス（N-S）トラフィック（「クライアント側に面したマイクロサービス」のトラフィック）にネットワークサービスを提供することです。主要なオーケストレーションプラットフォームの多くは、コンテナ化されたサービスのデプロイやスケーリング、および外部との接続の公開を処理します。F5は、主要なコンテナオーケストレーションプラットフォームとの緊密な統合により、N-SマイクロサービスがBIG-IPシステムによって自動的に検出され、そのトラフィックを管理できるようにします。たとえば、Mesosphere MarathonとKubernetesには、サービスに「ラベル」を付けるオプションがあります。これらのラベルを使用して、起動、停止、またはスケーリングされたクライアント側に面したサービスを検出し、BIG-IPシステムにプールメンバーとして自動的に追加できます。
上記のアプローチをBIG-IPハードウェアまたはVirtual Edition（VE）で使用すると、ハードウェアアクセラレーションを活用して、次のような重要な機能を一元化できます。
- 証明書を一元管理するSSLオフロード。
- 圧縮、TCP最適化、SPDY/HTTP2などによる高速化。
- DoS防御機能を備えた高度なファイアウォール。
- アプリケーション層攻撃を阻止する、アプリケーションへの高度な対応力。
- すべての受信および送信ネットワーク接続を可視化。
- インテリジェントなログ記録と異常検知により、デバッグ機能が大幅に向上。
F5とDNSサポートによるIPv4からIPv6への変換
F5ソリューションは、コンテナ化されたアプリケーションをスケールする機能に加え、Dockerインフラストラクチャと外部ネットワークの間でIPv4からIPv6への変換およびDNS変換を行う機能を提供します。完全にルーティング可能なDockerコンテナインフラストラクチャを利用するには、効率的なIPv4からIPv6へのネットワーク変換機能だけでなく、DNSリクエストの変換にも対応する必要があります。Dockerコンテナインフラストラクチャは、IPv4から完全に分離されたIPv6のみの環境で動作しながら、IPv4接続へのシームレスな経路を維持できます。
図5に示す例では、NAT64およびDNS64サービスがプロビジョニングされています（ここでも、物理または仮想のいずれの形態でもかまいません）。Dockerコンテナは、www.example.comへの接続を試みますが、この例では、このドメインにIPv6アドレスは存在しません。
BIG-IPシステムは、Dockerプラットフォーム環境のDNSリゾルバーとして構成されています。DNSリゾルバー自体のIPv6アドレスに加え、IPv4からIPv6への変換に使用する特別なIPv6プレフィックスアドレス（赤色で表示）も設定されています。
BIG-IPデバイスはIPv6 DNSクエリを受信すると、まず再帰処理を実行し、IPv6アドレスが利用可能かどうかを確認します。ただし、この例では、www.example.comの権威DNSサーバーはAAAAリクエストに対して空のレコードを返します。次に、BIG-IPデバイスはIPv4クエリを実行し、DNS Aレコードを受信します。そのIPv4アドレスの先頭に特殊なプレフィックスアドレスを付加し、Dockerクライアントに返します。
これでDockerクライアントのアドレスが解決され、TCP接続が開始されます。Dockerが特殊なプレフィックスを使用しているため、NAT64機能はIPv6からIPv4への変換が必要であると認識します。
NAT64機能は、DockerのIPv6アドレス、このIPv4サーバー用の特殊なプレフィックスが付いたNAT64アドレス、およびIPv4サーバー間の接続に対するバインディングを作成します。接続要求はIPv4サーバーに送信されます。IPv4経由で応答するこのサーバーからのすべての応答は、DockerコンテナとIPv4サーバー間の接続を確立するために、NAT64機能によって変換されます。
F5と東西トラフィックフロー
緊密な統合を実現するための次の重要なステップは、ADCサービスを必要とするマイクロサービス間で受け渡されるデータ、すなわちEast-West（E-W）トラフィックにサービスを提供することです。数秒でサービスを起動する必要があることや、マイクロサービスが一時的な性質を持つことを考慮し、F5では軽量ADCを有効にするアプローチを採用しています。（認証やL7、アプリケーションレベルの保護などの高度なサービスについては、トラフィックがN-Sエッジ上のBIG-IPインスタンスにリダイレクトされます。）
マイクロサービスアーキテクチャでは、コンテナ化されたサービスの数が従来型アーキテクチャよりもはるかに多くなり、マイクロサービス間に複数の通信経路が存在します。このアーキテクチャでは複雑性が増し、パフォーマンス問題のトラブルシューティングが難しくなる可能性があります。たとえば、アプリケーションのパフォーマンスが低下している場合、N-Sエッジから各種サービスに至るまで、エンドツーエンドの可視性を確保することが重要です。そのため、N-SドメインのBIG-IPシステムとE-Wドメインの軽量ADCとの間のトラフィックパターンを関連付けられる一元的な可視化アプローチが、トラブルシューティングに不可欠です。
F5 BIG-IPソリューションのインスタンスをアプリケーション間に配置し、負荷分散サービスやセキュリティサービスを提供することで、E-Wトラフィックに関するセキュリティ上の懸念に対処することもできます。たとえば、あるコンテナからのトラフィックが別のコンテナに入る前に、分析のためBIG-IPシステムを経由するようDockerホストを構成できます。これは、アプリケーションを認識し、対象のコンテナが脆弱性の悪用などの攻撃を受けているかどうかを検知できるBIG-IP Application Security Manager™（ASM）を使用して実現できます。
Dockerサービスデリバリに対するF5の段階的アプローチ
現在、F5のお客さまによる多くの導入事例で、コンテナ化が大規模に活用されています。こうした組織は、金融、通信、SaaSプロバイダーなど、さまざまな業種にわたります。これらの環境におけるF5ソリューションの現在の役割には、高速でセキュアかつ可用性の高いアプリケーションを実現するためのADCサービスの提供が含まれます。これらのサービスを統合することで、アプリケーション所有者やDevOpsによるセルフサービスを可能にしたり、コンテナ管理システムを介してサービスをオーケストレーションしたりできます。
F5は、サービスディスカバリ、E-Wトラフィック管理、セキュリティに対応するため、これらのサービスをコンテナ化インフラストラクチャ自体へ拡張する予定です。また、製品スイート全体でコンテナ化を活用し、物理プラットフォームでこのテクノロジーを利用するほか、コンテナでソフトウェアサービスを提供し、F5 Silverline®クラウドベースサービスプラットフォーム内でコンテナ化アーキテクチャを使用することも計画しています。
以下の表では、F5が検討中または積極的に開発を進めている方向性の一端をご紹介します。
まとめ
Dockerは、物理環境かクラウド環境かを問わず、データセンターの効率を向上させる明確な機会をもたらします。同時に、Dockerを導入することで、アプリケーションを新しい環境へ移行できるという確信をより強く持てます。特に重要なのは、Dockerによってアプリケーション開発者のアジリティが高まり、アプリケーションをより迅速に市場へ投入できることです。DevOpsをDockerモデルへ移行する際には、開発者がアプリケーションを配置できる、小規模で標準化されたサービスを基盤とする新たなセルフサービス型ワークフローを導入する機会として活用するケースがよくあります。
Dockerでは、軽量なコンテナをインスタンス化することでアプリケーションを迅速にスケールでき、F5のアプリケーションデリバリ製品はこのような環境を完全にサポートします。F5 BIG-IPソリューションを使用することで、アプリケーションのライフサイクル全体をオーケストレーションできます。包括的なREST APIを通じて、VIPの作成と保守、SSL／証明書の一元管理、ファイアウォールサービス、マルチテナントアーキテクチャにおける高可用性を備えたアプリケーションセキュリティなど、重要な運用を実行できます。
Dockerは、パブリッククラウドやプライベートクラウドへの導入を含む、さまざまなモデルで利用できます。F5は、こうした環境の相互運用性とサポートを先進的に提供しており、OpenStack、VMware、Amazon AWSやMicrosoft Azureなどの主要クラウドプロバイダーに特化した主要機能を提供します。
Dockerを主要コンポーネントとする進化したDevOpsモデルへ移行するお客さまは、期待される運用改善を実現するには、拡張性、セキュリティ、高可用性を備え、新たなワークフローが求める俊敏性に対応できるプラットフォームが不可欠であると認識しています。F5の製品とサービスは、Dockerが掲げるビジョンを実現するため、業界で最も幅広いテクノロジーおよびテクノロジーパートナーと連携できるよう設計されています。Dockerに対するF5の取り組みは、確かなロードマップへの投資と継続的な製品改善によって支えられており、ソフトウェア定義データセンターにおける主要な導入モデルの1つになると見込まれるDockerの成功を後押しします。
公開日：2016年6月20日