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. ネットワーキング– コンテナは起動と停止の速度が速いため、従来のネットワーキング モデルに挑戦します。 その結果、静的ネットワーク アドレスはこのような環境では機能しなくなります。 また、動的ホスト構成プロトコル (DHCP) などのアドレス指定メカニズムは物理ホストと仮想マシンでは正常に機能しましたが、コンテナの IP アドレスが登録され、コンテナ自体が検出可能になる前に、コンテナのワークロードが表示されたり消えたりすることがあります。 コンテナ ベースのソフトウェア定義ネットワーク (SDN) を使用して物理ネットワーク ハードウェアから分離することは、コンテナ トポロジ全体をオンプレミスからプライベート クラウド環境およびパブリック クラウド環境に移行できるようにするために不可欠です。 ほとんどのコンテナ環境では、この機能を実行するために何らかの形式のコンテナ ネットワーク インターフェイス (CNI) を実装しています。
3. 複数のコンテナ テクノロジ- 組織では、すでに環境内に複数の異なるコンテナ テクノロジが実装されている場合があります。 これらの実装があっても、スタッフがこれらすべての環境について深い技術的理解を欠いている可能性があります。 トレーニングは重要であり、チームがこれらのさまざまなコンテナ実装に慣れるための時間を与えることも重要です。 これらの複数のコンテナ テクノロジの管理もコストがかかります。 ただし、特に最新の Kubernetes リリースでは管理性が向上したため、組織は最も簡単で最も使用されている環境に標準化する傾向があります。
4. デフォルト構成のリスク- アプリはコンテナ内で開発されるため、コンテナの構成ミスのリスクが高まります。 一例として、コンテナをデフォルト構成でデプロイすることが挙げられます。 パロアルトにおける Unit 42 のグローバル脅威インテリジェンス³最近、デフォルトの構成設定を持つ 40,000 を超える固有のコンテナ デバイスが特定されました。 もちろん、これらすべてのインスタンスが悪用される危険性があるわけではありませんが、基本的な誤った構成慣行が蔓延しており、これらの組織がさらなる悪用の標的になっていることが浮き彫りになっています。

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

F5 のアプローチは、システム レベルではなくコンポーネント レベルでのコンテナ化に重点を置いています。 このアプローチには、次のようないくつかの利点があります。

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

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

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

アーキテクチャ的には、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 は、Universal Resource Identifier (URI) パス、バッキング サービス名、その他の構成情報などの要素を制御する Ingress リソース ルールを使用して、外部ネットワークから Kubernetes ポッドへのアクセスを提供する Kubernetes 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 ネイティブ実装を提供します。 重要なのは、Container Ingress Services を使用してより深いレイヤー 7 機能をプロビジョニングし、F5 ベースのイングレス メカニズムと連携できることです。

アーキテクチャ的には、Aspen Mesh はサイドカー プロキシ モデルを活用して、コンテナ化されたアプリケーションに機能とセキュリティのレベルを追加します (図 5 を参照)。