WHITE PAPER

F5とコンテナ化

はじめに

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

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

図1 - 仮想マシンとコンテナの比較

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

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

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

現代のIT課題への対応

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

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

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

 

Kubernetesは、コンテナ化されたサービスやワークロードを管理するためのオープンソースのプラットフォームです。Kubernetes自体は、Googleのコンテナ スケジューリングおよびオーケストレーション システムとして生まれ、その後同社はCloud Native Computing Foundationに寄付し、ソース コードを誰でも利用できるようにしました。Dockerも同様のオープンソースのアーキテクチャとディストリビューションを提供し、Software as a Service(SaaS)とPlatform as a Service(PaaS)を組み合わせたスイートで構成されています。

価値創出までの時間の計算

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

価値の決定

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

 

F5とコンテナ化

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

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

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

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

 

 

製品A

製品B

適合性

10

4

機能

10

2

インストールの手間

10

2

費用

$1,000

$500

価値

20

60

 

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

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

なぜコンテナの普及が進んでいるのか?

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

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

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

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

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

コンテナの課題

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

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

図2 - バランスの取れたコンテナ化の実現

バランスの取れたコンテナ化

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

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

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

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

F5 Container Ingress Services

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

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

 

 

図3 - F5 Container Ingress Services

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

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

NGINX Kubernetes Ingress Controller

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

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

 

 

図4 - NGINX Ingress Controller for Kubernetes

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

Aspen Mesh

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

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

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

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

 

 

図5 - Aspen Meshのアーキテクチャ

F5とコンテナ導入

F5は、コンテナ導入の最前線に立ち、シンプルなワークロードと大規模な業界固有のワークロードの両方でアプリケーション サービスを拡張する、信頼性、安全性、パフォーマンスの高いコンテナ化アプリケーション環境の稼働能力を組織に提供します。コンテナ テクノロジは、サーバーレス実装、サービス メッシュ アーキテクチャ、モバイル エッジ セキュリティなど、将来のアプリケーション開発および導入環境において重要な実現手段となるでしょう。F5では、コンテナの自社開発研究と商用実装の両方を用いて、お客様のビジネスに変化をもたらすアプリケーションとサービスを推進・開発しています。

私たちは既存製品の仮想化と同様に、管理者にとってはすぐに明らかにならないかもしれませんが、エンド ユーザーにとっては全体的に透明性の高い方法でコンテナ テクノロジを組み込んでいます。お客様には、パフォーマンス、柔軟性、セキュリティの向上を実感していただけると思います。私たちがこれらの新しいアプリケーションやサービスをシームレスに実装することで、お客様は必要な機能を確保することに専念できます。

また、私たちは、最高クラスのオープン ソース ソリューションを製品に導入し、これらのオープン ソース プラットフォームが提供するサービスを拡張して、コンテナ環境の機能を強化することにも取り組んでいます。私たちの目標は常に、より簡単に導入でき、より早く既存のネットワークに統合でき、より信頼性が高く、より安全な製品を作ることです。

コンテナ導入戦略を実行するために、私たちは以下のアプローチに注力しています。

  • 提供する非セキュリティ アプリケーション サービスの範囲を拡張します。ここでは、アプリケーションのパフォーマンス管理、ロギングとトラッキング、デバッグの強化、アプリケーション全体の健全性監視など、コンテナ環境の観測性と管理性を高める優れたツールの提供に注目します。
  • コンテナに非データプレーン指向のセキュリティ サービスを追加します。ここでは、実行中のコンテナに対する攻撃対象を減らすセキュリティ サービスを提供することで、革新を実現します。
  • F5製品におけるサードパーティ コンテナのホスティングを可能にします。この統合オプションにより、現在および将来のF5製品において、お客様が開発したアプリケーションやサードパーティ アプリケーションを柔軟なコンテナ ランタイム インターフェース内で実行することができます。このアプローチにより、F5は、既製またはカスタム開発されたさまざまなコンテナやアプリケーションを含むターンキー ソリューションを作成できるようになり、相互運用性が大幅に改善されます。
  • オープンソース ツールを使用して、既存のアプリケーション サービスのパッケージングを提供します。このオプションにより、レガシー環境と新規構築環境との間で一貫したサービス ポリシーを提供する機会が生まれます。
  • コンテナのアプリケーション スケールとセキュリティ サービスを自動化し、これらをサポートするために割り当てられるリソースを含めながら、管理下のアプリケーションを増やします。

コンテナの未来

F5は、多くの未来のアプリケーション サービス テクノロジのための基礎的な導入メカニズムとして、コンテナが認識される未来を目指しています。これらのテクノロジには、サーバーレス、サービス メッシュ、モバイル エッジなどが含まれますが、現在開発中の、あるいはまだ想定されていないその他のアプローチが含まれる可能性もあります。私たちは、効果的なネットワーク管理の重要な側面に影響を与えることなく、コンテナをソリューションに組み込めるよう、製品群の設計を見直しています。

仮想化と同様に、コンテナ自体も、コンテナ エンジンが動作しているハードウェアの基盤となる能力をより認識するようになります。マルチスレッド、メモリ速度、ストレージ アクセス、ネットワークは、各コンテナで実行されるアプリケーションに対する透明性がますます高まり、それによってリソースの使用率がさらに向上します。

私たちは、コンテナは仮想化に取って代わるものではなく、仮想化を補完するものと考えています。そのため、コンテナのライフタイムは少なくとも仮想化と同等であり、共存が継続すると考えています。また、仮想化とコンテナの両方と共存する、さらなる抽象化レベルの出現も期待しています。

私たちは、お客様にとって常に重要な関心事はセキュリティであることを理解しています。そのため、F5では、ハードウェアおよびソフトウェア アプライアンス、ファイアウォール、ネットワークに関する経験を活かし、すべての製品で可能な限り厳重なセキュリティを引き続き提供していきます。

まとめると、F5では、既存のコンテナ関連テクノロジに加え、今後もF5製品群にコンテナを組み込んでいく予定であり、これにより、アップデートしたアプリケーションや将来のアプリケーションで、より多くの統合オプション、高い信頼性、パフォーマンスの向上、導入時間の短縮を実現することができます。

F5とアプリケーションのコンテナ サポートの詳細については、f5.com/solutions/bridge-f5-with-container-environmentsをご覧ください。

1ベアメタルKubernetesサーバーの登場、Container Journal、Mike Vizard、2019年
2 コンテナベースのアプリケーション開発の現状、IBM Cloud Report、2018年
3 設定ミスと露出:コンテナ サービス、Palo Alto Networks、Nathaniel Quist、2019年

Updated June 23, 2022
  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share to email
  • Share via AddThis

Connect with F5

F5 Labs

The latest in application threat intelligence.

DevCentral

The F5 community for discussion forums and expert articles.

F5 Newsroom

News, F5 blogs, and more.