F5とコンテナ化

組織は常に、新しいビジネス機会を切り開くために技術的な変化を受け入れることと、新たな課題やリスクからビジネスを保護することの間で葛藤しています。この記事では、コンテナ化について、またF5製品へのこのテクノロジの採用がITプロフェッショナル、アーキテクト、ビジネス意思決定者にどのような影響を与えるかを検証します。

過去20年間で、仮想化によってサーバー コンピューティングは大きく変化し、1つのハードウェア プラットフォーム上で複数の別々のオペレーティング システムを実行することが可能になりました。さらに最新のアプローチとしてコンテナ化（またはオペレーティング システムの仮想化）があり、これによってホスト オペレーティング システムの単一インスタンス上で複数のアプリケーションを実行できます。各アプリケーション インスタンスは、単一のオペレーティング システム インスタンスにインストールされたバイナリやライブラリを共有します。図1は、これらのアプローチを比較したものです。

仮想マシン（VM）とは異なり、コンテナは同じオペレーティング システムを共有することができ、ハイパーバイザー レベルではなくOSレベルで仮想化できます。

アプリケーションの開発と導入、マイクロサービスの立ち上げが迅速かつ容易になるため、開発者がコンテナを好むのは当然のことです。また、コンテナ化によってポータビリティも向上します。コンテナ内のアプリケーションは、異なるオペレーティング システム、ハードウェア プラットフォーム、クラウド サービスに容易に導入できるからです。コンテナは、ベアメタルホストのオペレーティング システムや仮想マシン上で直接実行されるアプリケーションよりも消費するリソースが少なくて済みます。

一般的に、コンテナに関する議論（および文書）のほとんどは、プログラミングやDevOpsの観点に焦点を当てています。ITプロフェッショナル、システム アーキテクト、またはビジネス意思決定者は、コンテナ化がもたらす柔軟性を評価しつつも、この変化が環境内のアプリケーションやサービスの運営、管理、監視にどのように影響するかについて懸念を抱いているかもしれません。また、コンテナ化によってネットワークやアプリケーションのセキュリティに悪影響が及ばないようにしたいとも考えていることでしょう。

競争が激化する市場において、最新のITシステムは現実的なビジネス上のメリットを提供する必要があります。この要件を実現するには、IT部門がアプリケーション資本を拡大し、単にアプリケーションの数を増やすだけでなく、より高機能でユーザビリティが高く、統合が容易なアプリケーションを搭載したアーキテクチャを設計・構築することが不可欠です。

ITディレクターにとっての課題は、人員を増やすことなく、より高い機能を提供する必要があることです。生産性の向上は、人員を増やすことではなく、テクノロジと自動化の進歩によって、同規模のチームが管理する、顧客が利用可能なアプリケーションの数を増やすことで実現できるのです。

コンテナの導入を容易にすることは、さらなる課題となります。開発者は、アプリケーションを構築する際にスケールとセキュリティの両方を考慮するように教育や指導を受ける必要があり、ITプロフェッショナルは、それらのアウトプットを達成できるよう彼らを支援できます。ここでは、KubernetesやDockerなどのコンテナ プラットフォームが本番稼働に与える影響について考える必要があります。また、俊敏性を高める必要性により、セキュリティ対策の不備や本番稼働負荷の考慮不足から望ましくない結果がもたらされないようにするにはどうしたらよいかも考える必要があります。

ビジネス上のメリットを実現するための重要な要素は、価値創出までの時間を最小限に短縮することです。パフォーマンスやレイテンシといった要素は、導入のしやすさよりも後回しにされることが多くなっています。その結果、ほぼ同じ機能を持つ2つのコンポーネントがあったとして、一方のパフォーマンスが高く、もう一方が統合しやすい場合、組織は現在の環境に統合しやすいコンポーネントを選択する傾向があります。環境の複雑さが増すにつれて、この偏りは続く可能性が高くなります。

コンテナ化などのテクノロジを実装しようとする場合、この新しいアプローチがもたらす価値を測定する何らかの方法が必要です。価値に影響を与える要素には通常、適合性、機能、労力、およびコストが含まれます。次の式は、これらの要素に基づいて相対的な価値を割り当てる方法の一例を示しています。

式で使用する単位は関係なく、重要なのは、評価する項目ごとに単位が同じであるという点です。

この式から、テクノロジはシームレスに統合されなければならず、クラス最高レベルの機能や性能よりも、親しみやすさ（つまり、導入のしやすさ）が重要であることがわかります。その結果、導入の手間が全体的な価値の計算におけるバランス効果となり、性能の劣る製品の方が、導入の容易さゆえに顧客にとって魅力的となる結果になりかねません。

このような効果の例として、競合する2つの監視ソリューションがあるとします。製品Aはすばらしい仕様で、クラス最高レベルのロギングとレポート作成機能を備えています。また、軍用レベルのセキュリティを備え、管理性も高くなっています。しかし、独自のコマンドライン インターフェース、オープン スタンダードのサポートが不十分で、統合機能がないため、インストールが困難です。また、市場に出回っている他の多くの製品よりも高価となっています。

これに対し、製品Bは、許容できるレベルの監視やセキュリティを提供するものの、機能に関しては競合製品の足元にも及びません。しかし、コストとインストールのしやすさでは競合製品に勝っています。各製品のスコアを集計すると下表のようになります。1を最低、10を最高として、適合性、機能、インストールの手間について1〜10段階で評価しています。

これらの数値を上記の式に当てはめると、表の最下段に記載されている数値が算出されます。

半分の価格で5倍簡単にインストールできる、適合性と機能の低い製品が、最高クラスの競合製品と比較して、推定3倍の価値を提供することが分かります。多くの組織はこうした点を理解しており、新しいテクノロジを採用・導入する際に、インストールと統合の容易さを重要な要素として取り入れる傾向が強まっています。コンテナベースのアプローチは、導入の労力を大幅に削減し、コストを抑制すると同時に、適合性と機能の両方を維持することができます。

アプリケーションがますますビジネス価値を高める中、コンテナ化は、DevOpsを中心としたIT導入の実践における課題に対する論理的なソリューションを提供します。コンテナは、仮想マシンを実行する際の管理オーバーヘッドを伴わずに、実行するプラットフォームとコンテナ同士を分離することができます。開発者は、必要なバイナリやライブラリをすべて含み、必要なネットワーキングと管理施設を組み込んだアプリケーション環境を簡単に立ち上げることができます。また、コンテナ化により、アプリケーションのテストと導入が簡素化されます。

コンテナベースの環境は、サーバー上で実行可能なアプリケーション インスタンスの数を大幅に拡張することで、仮想コンピュータよりも優れたリソース使用率を実現します。ホストとゲストの両方のオペレーティング システムのオーバーヘッドがないコンテナ環境では、オペレーティング システムのカーネルを共有することで、プロセッサ時間とメモリ空間をより効率的に使用できます。また、コンテナ化により、基盤となるプラットフォームは仮想マシンまたは物理サーバーのいずれかになるため、アーキテクチャの柔軟性も高まります。Red Hatの製品戦略¹によると、将来的にアプリケーションをコンテナに導入するKubernetesの顧客の約半数は、コンテナ エンジンをベア メタル上で直接実行することになると示されています。

コンテナ化は、ハードウェアベースのコンピューティングから仮想化、マルチクラウドへの移行において次の進歩をもたらし、最大100％の自動化、1秒未満のサービス作成時間、秒単位で測定可能なサービス ライフタイムを可能にします。Docker、OpenShift、Kubernetesなどのコンテナ環境では、最新のITアーキテクチャ内でサービスやマイクロサービスのプロビジョニングとデプロビジョニングを即座に行うことができます。

重要なのは、コンテナ化によって、今日のマルチプラットフォームおよびマルチクラウド環境では欠かせない重要なメリットがもたらされることです。すなわち、アプリケーションをオンプレミスからクラウド、別のクラウド ベンダー、そして再びオンプレミスに、すべて基本コードを変更せずに移植できるのです。相互運用性はアーキテクチャの決定を支える重要な要素であり、このポータビリティによって、IT部門はアプリケーション サービスの導入における重要なマイルストーンを達成でき、組織目標の達成についてDevOpsチームをサポートできます。最近のIBMのレポート²では、アプリケーションの導入にコンテナを使用することで、企業はアプリケーション品質の向上、不具合の低減、アプリケーションのダウンタイムと関連コストの最小化を実現できることが取り上げられています。

また、同レポートでは、コンテナベースの環境に特化したアプリケーションとして、データ分析、Webサービス、データベースなどを挙げています。ここで重要な要素はパフォーマンスですが、その他に考慮すべき関連要素は、アプリケーションが複数の環境で実行される可能性があるかどうか、複数のDevOpsチームが並行して作業するためにマイクロサービスを使用しているかどうかです。コンテナを使用すれば、ステートレス アーキテクチャ設計を実装し、大規模なアプリケーション サービスを提供することを前提に、アプリケーションのインスタンスを増やすだけでパフォーマンスの問題に対処できます。

コンテナには導入上の課題がまったくないわけではなく、まだ若いテクノロジであるため、仮想化のような成熟したレベルには至っていません。次のセクションでは、コンテナがもたらす課題をいくつかご紹介します。

1. キー管理 - コンテナ間のキー管理は、特にコンテナの主なメリットがポータビリティであることから、問題になる可能性があります。キー管理環境は、オンプレミス ホスト間でのコンテナの移動や、クラウド間の移動に対応できるものである必要があります。
2. ネットワーキング - コンテナは、スピンアップとスピンダウンが高速なため、従来のネットワーキング モデルにとって課題となります。その結果、静的なネットワーク アドレスは、このような環境では機能しなくなります。また、Dynamic Host Configuration Protocol（DHCP）などのアドレス指定メカニズムは、物理ホストや仮想マシンではうまく機能しましたが、コンテナのワークロードは、コンテナのIPアドレスが登録されてコンテナ自体が検出可能になる前に現れたり消えたりする可能性があります。コンテナベースのソフトウェアディファインド ネットワーキング（SDN）を使用して物理ネットワーク ハードウェアから分離することは、オンプレミスからプライベートおよびパブリック クラウド環境へコンテナ トポロジ全体を移行できるようにする上で不可欠です。ほとんどのコンテナ環境では、この機能を実現するために、何らかの形でContainer Network Interface（CNI）を実装しています。
3. 複数のコンテナ テクノロジ - 皆さんの組織では、すでに複数の異なるコンテナ テクノロジが環境内に実装されている可能性があります。このような実装を行ったとしても、スタッフはこれらの環境すべてを技術的に深く理解していない可能性があります。トレーニングによりチームはこれらの異なるコンテナの実装に慣れる時間を得ることができるため、トレーニングが重要となります。また、複数のコンテナ技術を管理することは、よりコストがかかることでもあります。しかし、特に最新のKubernetesリリースでは管理性が向上しているため、組織は最も簡単で最も利用されている環境で標準化を行う傾向にあります。
4. デフォルト構成のリスク - アプリケーションをコンテナで開発するようになると、コンテナの構成ミスのリスクが高まります。その一例が、コンテナをデフォルト構成のまま導入することです。Palo Alto³のUnit 42グローバル脅威インテリジェンスでは、最近、デフォルト構成設定の4万台を超える独自のコンテナ デバイスが特定されました。もちろん、これらのインスタンスすべてが悪用される可能性があるわけではありませんが、基本的な構成ミスの慣例が広まっており、これらの組織がさらなる悪用のターゲットになっていることを浮き彫りにしています。

コンテナ化で重要な設計基準は、図2に示すように、性能、密度、信頼性の3つのベクトル間のバランスです。

F5のアプローチは、システムレベルではなく、コンポーネントレベルでのコンテナ化に焦点を当てることです。このアプローチは、以下のようないくつかの利点をもたらします。

• 未使用のネットワーク機能にメモリを割り当てないことで、各コンテナのメモリ フットプリントを削減。
• ホストCNIへの依存を最小限にすることで、ネットワーキング性能の問題を回避。
• 障害領域を加入者/ユーザー レベルまで落とし込んだ小型軽量コンポーネントの実装。

コンポーネントレベルのコンテナ化により、分解、スケジューリング、オーケストレーションを通じて、この3方向のバランスを実現することができます。そして、コンテナを実装するF5製品は、これらの機能を利用して、コンテナ化のメリットを最大化します。

F5では、コンテナベースのテクノロジを採用する組織をサポートするために、オープンソースのコンテナ統合サービスであるF5® Container Ingress Servicesを提供しています。Container Ingress Servicesは、自動化、オーケストレーションのほか、ルーティング、SSLオフロード、HTTPルーティング、堅牢なセキュリティなどのネットワーキング サービスを提供します。重要なのは、さまざまなBIG-IPサービスを、KubernetesやRed Hat OpenShiftなどのネイティブ コンテナ環境と統合していることです。

アーキテクチャ的には、Container Ingress Servicesは、コンテナ化されたアプリケーションとの関係で次のような位置を占め、フロントドアのIngressコントローラ サービスを追加し、BIG-IPを通じて可視化と分析を可能にします。

Container Ingress Servicesは、この記事で明らかにしたスケーラビリティとセキュリティという2つの重要な課題に対応しています。コンテナ ワークロードに合わせてアプリケーションを拡張し、セキュリティ サービスを有効にしてコンテナ データを保護することができます。BIG-IPプラットフォームの統合により、オーケストレーション環境内でセルフサービスのアプリケーション パフォーマンスを実装できます。また、Container Ingress Servicesを使用すると、テンプレートベースの導入とアップグレードにHelmチャートを使用することにより、開発者がKubernetesコンテナをデフォルト設定で実装する可能性が低くなります。

さらに、Container Ingress Servicesは、高度なコンテナ アプリケーションの攻撃保護とアクセス制御サービスによるセキュリティを実現します。構成に不慣れなアプリケーション開発者やDevOpsプロフェッショナル向けに、F5アプリケーション サービスは、DevCentralのお客様およびオープンソース コミュニティに加え、すぐに使えるポリシーとロールベースのアクセス制御（RBAC）をエンタープライズグレードのサポートとともに提供します。

ネイティブKubernetesに関連する課題は、複雑さを増すことなく最新のコンテナ アプリケーションを開発し、スケーリングすることに関連するものです。パフォーマンスと信頼性に制約がある場合や、Kubernetesコンテナへのフロントドアを提供するサービスが一貫して実装されいない場合は、導入と構成において大規模な統合作業が必要となります。

これらの課題に対するソリューションは、Kubernetesアプリケーションのデリバリ サービスを提供することで基本的なKubernetes環境を強化するNGINX Kubernetes Ingress Controllerです。通常、Kubernetesポッドは、同じクラスタ内の他のポッドとしか通信できません。図4は、外部ネットワークからKubernetesポッドへのアクセスを提供するKubernetes Ingress Controllerを示したものです。これはUniversal Resource Identifier（URI）のパスやバッキング サービス名、その他の構成情報などの要素を制御するIngressリソース ルールを使用して管理されます。利用可能なサービスは、NGINXとNGINX Plusのどちらを使用するかによって異なります。

NGINXを使用する企業は、ロード バランシング、SSLまたはTLS暗号化ターミネーション、URIリライト、アップストリームSSLまたはTLS暗号化などの機能を利用できます。NGINX Plusは、ステートフル アプリケーション用のセッション パーシスタンスとJSON Web Token（JWT）API認証などの追加機能を提供します。

開発者の俊敏性とクラウドネイティブなスケーラビリティを引き出すためにマイクロサービスを導入した組織は、組織の能力がテクノロジに追いつくまでの間、学習が必要になります。このような組織は、カスタマ エクスペリエンスを支える安定性を維持しながら、マイクロサービスのメリットを迅速に引き出したいと考えています。

Aspen Meshは、オープン ソースのIstioサービス メッシュの完全サポート版で、企業はマイクロサービスやKubernetesを大規模に導入して、マイクロサービス アーキテクチャの観測性、制御性、安全性を確保できます。Aspen Meshは、サービスのステータスや健全性を簡単に可視化して理解できるユーザー インターフェイス、きめ細かいRBAC、コンテナ化アプリケーションで望ましい動作を容易に実現するポリシーと構成機能など、主要なサービス メッシュのエンタープライズ機能を追加します。

Aspen MeshはKubernetesネイティブの実装を提供し、お客様のKubernetesクラスタに導入され、お客様のプライベートまたはパブリック クラウド、あるいはオンプレミスで動作させることができます。重要なのは、F5ベースのイングレス メカニズムと協調して動作し、Container Ingress Servicesを使用してより深いレイヤ7機能をプロビジョニングできる点です。

アーキテクチャ的には、Aspen Meshは、図5に示すように、サイドカー プロキシ モデルを利用して、コンテナ化アプリケーションに機能性とセキュリティのレベルを追加します。