F5とコンテナ化
はじめに
組織は、新たなビジネス機会を切り開くために技術革新を取り入れることと、新たな課題やリスクから事業を守ることの両立に常に苦慮しています。本書では、コンテナ化について解説するとともに、F5製品へのこの技術の導入がIT担当者、アーキテクト、ビジネス上の意思決定者に与える影響を考察します。
過去20年間で、仮想化はサーバーコンピューティングを大きく変え、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つのコンポーネントがあり、一方はパフォーマンスに優れ、もう一方は統合が容易な場合、組織は現在の環境に統合しやすいコンポーネントを選ぶ傾向があります。環境の複雑さが増すにつれて、この傾向は今後も続くと考えられます。
価値の判断
コンテナ化などのテクノロジーの導入を検討する際は、この新しいアプローチがもたらす価値を測定する方法が必要です。通常、価値に影響する要因には、適合性、機能、労力、コストなどがあります。次の式は、これらの要因に基づいて相対的な価値を算出する方法の一例です。
式で使用する単位の種類は問いません。重要なのは、評価する各項目で同じ単位を使用することです。
この式は、テクノロジーをシームレスに統合できることが不可欠であり、使い慣れていること（つまり、導入のしやすさ）が、最高水準の機能やパフォーマンスよりも重要になり得ることを示しています。そのため、全体的な価値を算出する際には導入に要する労力が均衡をもたらす要因となり、機能面で劣る製品でも、導入しやすいという理由でお客さまにとってより魅力的になる場合があります。
この効果は、競合する2つの監視ソリューションを例にすると分かりやすいでしょう。製品Aは優れた仕様を備え、ログ記録機能とレポート機能は業界最高水準です。軍用レベルのセキュリティを採用し、管理性にも優れています。しかし、独自のコマンドラインインターフェース、オープン標準への対応不足、統合機能の欠如により、導入は容易ではありません。また、市場にある他の大半の製品よりも高価です。
これに対して、製品Bは許容できるレベルの監視機能とセキュリティを備えているものの、その能力は競合製品に遠く及びません。しかし、コストと導入の容易さでは、いずれも競合製品を上回っています。各製品について、適合性、能力、導入作業の負担を1～10点（最低1点、最高10点）で評価し、表にまとめると以下のようになります。
これらの数値を上記の式に代入すると、表の最下行に示すバリュースコアが算出されます。
適合性と機能性では劣る製品でも、価格が半分で、インストールが5倍容易であれば、最高水準の競合製品と比べて推定3倍の価値をもたらすことがわかります。多くの組織がこうした点を理解し、新しいテクノロジーを採用・導入する際に、インストールや統合の容易さを重要な判断要素とする傾向が強まっています。コンテナベースのアプローチなら、適合性と機能性を維持しながら、導入作業を大幅に削減し、コストを抑えることができます。
コンテナの人気が高まっている理由
アプリがビジネス価値を生み出すうえでますます重要になる中、コンテナ化は、DevOpsを中心としたIT実装手法の課題に対する合理的な解決策となります。コンテナは、仮想マシンの運用に伴う管理負荷を生じさせることなく、実行基盤や他のコンテナから分離された環境を提供します。開発者は、必要なバイナリとライブラリをすべて含み、必要なネットワーク機能と管理機能が組み込まれたアプリ環境を容易に立ち上げることができます。また、コンテナ化により、アプリケーションのテストとデプロイも簡素化されます。
コンテナベースの環境では、1台のサーバーで実行できるアプリケーションインスタンスの数を大幅に増やせるため、仮想マシンよりもリソース使用率が向上します。ホストとゲストの両方のオペレーティングシステムに伴うオーバーヘッドがなく、OSカーネルを共有することで、プロセッサー時間とメモリ領域をより効率的に使用できます。また、基盤となるプラットフォームには仮想マシンと物理サーバーのいずれも使用できるため、コンテナ化によってアーキテクチャの柔軟性も高まります。Red Hat Product Strategy1 によると、今後アプリケーションをコンテナにデプロイするKubernetesユーザーの半数近くが、コンテナエンジンをベアメタル上で直接実行する見込みです。
コンテナ化は、ハードウェアベースのコンピューティングから仮想化、さらにマルチクラウドへと進化する道のりにおける次のステップです。最大100%の自動化、1秒未満でのサービス作成、秒単位のサービス存続期間を実現できます。Docker、OpenShift、Kubernetesなどのコンテナ環境により、最新のITアーキテクチャ内でサービスやマイクロサービスを即座にプロビジョニングおよびプロビジョニング解除できます。
重要なのは、コンテナ化によって、今日のマルチプラットフォームおよびマルチクラウド環境に不可欠なメリットが得られることです。基盤となるコードを変更することなく、アプリをオンプレミスからクラウドへ、さらに別のクラウドベンダーへ移行し、再びオンプレミスへ戻すことができます。相互運用性がアーキテクチャ上の意思決定を支える重要な要素となる中、この可搬性により、IT部門はアプリサービスの導入における重要なマイルストーンを達成でき、DevOpsチームによる組織目標の達成も支援されます。IBMの最新レポート2では、アプリの導入にコンテナを使用することで、企業がアプリの品質を向上させ、不具合を減らし、アプリケーションのダウンタイムとそれに伴うコストを最小限に抑えられることも示されています。
同レポートでは、コンテナベースの環境に特に適したアプリケーションとして、データ分析、Webサービス、データベースも挙げています。ここで重要な要素はパフォーマンスですが、アプリケーションが複数の環境で実行される可能性があるか、また、複数のDevOpsチームが並行して作業できるようにマイクロサービスを使用しているかも考慮する必要があります。ステートレスなアーキテクチャ設計を実装し、アプリケーションサービスを大規模に提供することを前提に、コンテナではアプリケーションのインスタンスを追加で起動するだけで、パフォーマンスの問題に対処できます。
コンテナの課題
コンテナの導入には課題がないわけではなく、まだ新しい技術であるため、仮想化と同等の成熟度には達していません。次のセクションでは、コンテナに伴う主な課題を取り上げます。
- 鍵管理 – コンテナの主な利点の1つは可搬性であるため、コンテナ間の鍵管理が問題になる場合があります。鍵管理環境は、オンプレミスのホスト間だけでなく、クラウドへの移行やクラウドからの復帰にも対応できる必要があります。
- ネットワーキング – コンテナは短時間で起動・停止するため、従来のネットワークモデルでは対応が困難です。そのため、このような環境では静的ネットワークアドレスは実用的ではありません。また、Dynamic Host Configuration Protocol（DHCP）などのアドレス割り当てメカニズムは、物理ホストや仮想マシンでは問題なく機能していましたが、コンテナワークロードは、コンテナのIPアドレスが登録され、コンテナ自体が検出可能になる前に出現・消失する可能性があります。コンテナトポロジ全体をオンプレミス環境からプライベートクラウドおよびパブリッククラウド環境へ移行できるようにするには、コンテナベースのSoftware-Defined Networking（SDN）を使用して物理ネットワークハードウェアから分離することが不可欠です。ほとんどのコンテナ環境では、この機能を実現するために何らかのContainer Network Interface（CNI）が実装されています。
- 複数のコンテナ技術 – 組織内の環境には、すでに複数の異なるコンテナ技術が導入されている場合があります。しかし、導入済みであっても、担当者がこれらすべての環境について高度な技術知識を備えていない可能性があります。トレーニングに加え、チームが各コンテナ実装に習熟するための時間を確保することが重要です。また、複数のコンテナ技術を管理すると、コストも増加します。ただし、特に最新リリースのKubernetesでは管理性が向上しているため、組織では最も使いやすく広く利用されている環境に標準化する傾向があります。
- デフォルト設定のリスク – コンテナでアプリを開発するにつれて、コンテナの設定ミスによるリスクが高まります。その一例が、デフォルト設定のままコンテナをデプロイすることです。Palo AltoのUnit 42グローバル脅威インテリジェンス3 は最近、デフォルト設定のまま使用されている固有のコンテナデバイスを40,000台以上特定しました。もちろん、そのすべてが悪用される脆弱性を抱えているわけではありません。しかし、基本的な設定ミスが広く見られ、それによってこれらの組織がさらなる攻撃の標的になり得ることが浮き彫りになっています。
バランスの取れたコンテナ化
図2に示すように、コンテナ化における重要な設計基準は、パフォーマンス、密度、信頼性という3つの要素のバランスです。
F5のアプローチでは、システムレベルではなく、コンポーネントレベルのコンテナ化に重点を置いています。このアプローチには、次のような利点があります。
- 使用されていないネットワーク機能にメモリを割り当てないことで、各コンテナのメモリ使用量を削減します。
- ホストCNIへの依存を最小限に抑えることで、ネットワークパフォーマンスの問題を回避します。
- 小型で軽量なコンポーネントを実装し、障害ドメインを加入者／ユーザーレベルまで縮小します。
コンポーネントレベルのコンテナ化により、分離、スケジューリング、オーケストレーションを通じて、この3つの要素のバランスを実現できます。コンテナを実装するF5製品では、これらの機能を活用してコンテナ化のメリットを最大限に引き出します。
F5 Container Ingress Services
組織によるコンテナベースのテクノロジー導入を支援するため、F5はオープンソースのコンテナ統合ソリューションであるF5® Container Ingress Servicesを提供しています。Container Ingress Servicesは、自動化、オーケストレーションに加え、ルーティング、SSLオフロード、HTTPルーティング、堅牢なセキュリティなどのネットワークサービスを提供します。特に、F5の幅広い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アプリケーションサービスは、すぐに利用できるポリシーとロールベースのアクセス制御（RBAC）に加え、エンタープライズグレードのサポート、DevCentralのカスタマーコミュニティおよびオープンソースコミュニティを提供します。
NGINX Kubernetes Ingress Controller
ネイティブKubernetesでは、複雑さを増すことなく最新のコンテナアプリを開発し、スケールさせることが課題となります。パフォーマンスや信頼性に制約が生じる可能性があるほか、Kubernetesコンテナへのフロントドアとなるサービスの実装に一貫性がない場合があり、デプロイや構成に多くの統合作業が必要になります。
こうした課題を解決するのがNGINX Kubernetes Ingress Controllerです。Kubernetesアプリ向けの配信サービスを提供し、基本的なKubernetes環境を強化します。通常、Kubernetes Podは同じクラスター内の他のPodとのみ通信できます。図4は、Kubernetes Ingress Controllerが外部ネットワークからKubernetes Podへのアクセスを提供する仕組みを示しています。このアクセスは、Uniform Resource Identifier（URI）パス、バックエンドサービス名、その他の構成情報などを制御するIngressリソースルールによって管理されます。利用できるサービスは、NGINXとNGINX Plusのどちらを使用するかによって異なります。
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クラスターにデプロイされ、プライベートクラウド、パブリッククラウド、またはオンプレミスで実行できます。特に、Container Ingress Servicesを使用して、より高度なレイヤー7機能をプロビジョニングすることで、F5ベースのイングレスメカニズムと連携できます。
アーキテクチャの観点では、Aspen Meshはサイドカープロキシモデルを活用し、図5に示すように、コンテナ化されたアプリケーションの機能とセキュリティを強化します。
F5とコンテナ導入
F5はコンテナ導入をリードし、シンプルなワークロードから業界固有の大規模ワークロードまで、アプリケーションサービスを拡張できる、信頼性、安全性、パフォーマンスに優れたコンテナ化アプリケーション環境を運用するための機能を組織に提供しています。コンテナ技術は、サーバーレス実装、サービスメッシュアーキテクチャ、モバイルエッジセキュリティなど、将来のアプリケーション開発・導入環境を実現するうえで重要な役割を果たします。F5は、自社の開発研究とコンテナの商用実装の両方を活用し、お客さまのビジネスに変革をもたらすアプリケーションやサービスの推進・開発に取り組んでいます。
既存製品の仮想化と同様に、F5は、管理者にはすぐには分からない場合がある一方、エンドユーザーにはまったく意識させない形でコンテナ技術を組み込みます。これにより、パフォーマンス、柔軟性、セキュリティが向上します。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レポート、2018年
3 設定ミスと外部公開：コンテナサービス, Palo Alto Networks、Nathaniel Quist、2019年
公開日：2022年6月23日