F5 iApps：アプリケーションデリバリをネットワークの先へ
はじめに
今日の企業では、ネットワーク内のアプリケーションをより深く把握し、管理することが求められています。データセンターはアプリケーションやサービスを提供するために構築されていますが、依然として大規模なネットワークとして管理され、個々のネットワークコンポーネントも孤立した単一ポイントのデバイスとして扱われています。たとえば、従来型のルーターは、あたかも他との関係を持たず、単にIPトラフィックをルーティングするだけのものとして管理されています。しかし、アプリケーションが期待どおりに動作するには、そのルーターが不可欠です。現在、ほとんどの企業では、組織やデータセンターのネットワークを、個別のグループが管理する一連の独立したオブジェクトとして捉えています。一方で、各コンポーネントが相互に、またインフラストラクチャの他の部分とどのように関連しているのか、さらに、すべてのコンポーネントがどのように連携してユーザーにアプリケーションを提供しているのかを俯瞰する視点がありません。
インフラストラクチャ全体を個別のコンポーネントとして管理すると、IT部門の業務に支障をきたします。ユーザーやデータセンター内の他のサービスへのアプリケーションデリバリを適切に管理、制御するには、複数の部門にまたがる多数の要素を連携させる必要があるためです。その結果、IT部門では、ネットワークレベルで各コンポーネントが何をしているかを詳しく記載した複雑なスプレッドシートを使用していることが少なくありません。しかし、各コンポーネントとアプリケーションとの関連性についての情報はありません。インフラストラクチャのコンポーネントがどのように連携してアプリケーションを提供しているかを把握できないため、このように複雑で分断されたインフラストラクチャの捉え方は、データセンターの管理やトラブルシューティング、セルフサービスプロビジョニングなどのアジャイルモデルにとって課題となります。
アプリケーション重視への転換
多くの組織では、こうした旧来のデータセンター観が依然として管理に影響を及ぼしていますが、アプリケーションは進化し、中心的な役割を担うようになっています。この変化により、企業のIT部門は、デバイスやオブジェクトを起点にコンポーネントを組み合わせてアプリケーションを提供するのではなく、アプリケーション中心の視点で管理することを迫られています。この変化の主な要因は、クラウドコンピューティングとSoftware as a Service（SaaS）の導入が進み、アプリケーションが最も重要な要素となる一方で、インフラストラクチャがコモディティ化していることです。
しかし、今日のアプリケーション管理は、わずか5年前と比べてもはるかに複雑になっています。バックエンドでは、アプリケーションを企業のデータセンター内外を問わず、どこにでも配置できるようになりました。管理者は、異なるクラウドプロバイダー間にアプリケーションを展開したり、SaaSアプリケーションとして運用したり、さらには異なる大陸のデータセンターに地理的に分散させたりできます。また、仮想化に伴い、データセンターはサーバーとアプリケーションが1対1で対応するモデルから移行しつつあります。リソースが縮小する一方で、サービスは増え続けています。アプリケーション自体も、より多くのデータを扱うモデルへと移行し、APIを介したアプリケーション間通信への依存が高まっているため、システムとネットワークに求められるリソースも増加しています。しかし、アプリケーションが中心となるエンタープライズITのコンシューマライゼーションが急速に進んでいるにもかかわらず、基盤となるインフラストラクチャはそれに適応できていません。アプリケーションデリバリの管理では、ネットワークコンポーネントだけでなく、コンテキストを把握し、ユーザーがアプリケーションをどのように利用しているかをリアルタイムで理解することも重要です。
iApps：アプリケーションの時代
F5 iAppsは、データセンターにおけるアプリケーションデリバリのアーキテクチャをより適切に設計できる、BIG-IPシステムの強力な新機能群です。iAppsは、データセンターの内部、外部、さらにその先でアプリケーションを管理、配信する方法に対する、包括的かつアプリケーション中心のアプローチに基づいています。iAppsテクノロジーは、ビジネスを支えるアプリケーションサービスについて、コンテキストに応じたビューと高度な統計情報を提供するフレームワークをBIG-IPシステム内に構築します。これにより、アプリケーション、セキュリティ、ネットワーク、システム、運用の各担当者は、アプリケーションデリバリサービスを統合、簡素化し、より効果的に制御できます。
iAppsは、アプリケーションの配信に必要な多数の個別コンポーネントを抽象化し、特定のアプリケーションに関連付けられたテンプレートにこれらのリソースをまとめます。これにより、管理者がネットワーク上の個々のコンポーネントを管理する必要性が軽減されます。
ほとんどの企業のIT部門では、ネットワークの各領域に関する管理責任を複数のチームに分担させています。IPアドレス、ルーティング、DNSはネットワークチームが、物理サーバーと仮想サーバー、OSビルド、ウイルス対策はサーバーチームが、API連携、アプリケーション標準、アクセス権はアプリケーションチームとセキュリティチームがそれぞれ管理します。そのため通常、IT部門内には「組織でメールを配信するために必要なコンポーネントは何か、また各コンポーネントはどのように構成されているか」という問いに答えられる単一のチームが存在しません。連携されていない構成要素があまりにも多いためです。
iAppsは、アプリケーションを中心とした視点ですべてを管理することで、この状況を変えます。iAppsを使用すると、ノード、アプリケーションモニター、プールといったアプリケーションデリバリサービスのコンポーネントをまとめ、アプリケーションワークフローの一部として管理できます。主要な管理タスクを自動化することで、アプリケーション管理者とネットワーク管理者は、アプリケーションの提供に必要なインフラストラクチャコンポーネントを容易に定義できます。
iAppsは、アプリケーションデリバリサービスの構成と管理に加え、アプリケーションデリバリリソースの追加展開などの自動化タスクを定義できます。iAppsは、AAAセキュリティインフラストラクチャにF5のiRulesエンジンを介して負荷分散ルールを適用することから、F5のお客さま向けサポートポータルであるiHealthにアプリケーションの診断データと可視化データを公開することまで、BIG-IPシステムのさまざまな機能を活用して、アプリケーションデリバリのあらゆる側面を管理します。
iAppsでは、アプリケーションデリバリサービスのすべてのコンポーネントが1つにまとめられ、アプリケーションの拡張機能として扱われます。たとえば、新しいSharePointアプリケーションには、SharePointのWebフロントエンド、検索、データベースの各コンポーネントの状態を確認する専用のヘルスモニターが必要です。従来は、これらのコンポーネントを個別に割り当てて管理する必要があり、エラーが発生する余地が生じるだけでなく、導入時間も大幅に増加していました。SharePoint用のiAppを使用すると、これらすべてがアプリケーション自体のコンポーネントとなり、1か所で一元的に導入および管理できます。
統合されたiAppsコンポーネント
内部では、iAppsは複数の独立したコンポーネントで構成され、それぞれがアプリケーションデリバリーインフラストラクチャの一部を管理します。これらのコンポーネントが連携することで、統合されたBIG-IP Application Delivery Controller（ADC）の一部として機能します。
iApps Application Services
iAppsは、配信時にアプリケーションのあらゆる部分に適用できるiApps Application Servicesを作成し、アプリケーションコンポーネントをまとめて配信します。たとえば、SharePoint向けのiApps Application Serviceには、最初にBIG-IP Local Traffic Manager (LTM)ポリシーとSSL関連のiRules一式を関連付けることができます。その後、管理者はiAppsのチェックボックスを1つオンにするだけで、BIG-IP Access Policy Manager (APM)のアクセスポリシーを同じSharePoint向けiApps Application Serviceに関連付け、ネットワーク全体に再配布できます。iApps Application Servicesは、アプリケーション配信インフラストラクチャ全体を可視化し、アプリケーションとネットワークの依存関係を1つの統合システムにまとめることで、運用コストを削減します。
オブジェクト指向プログラミングがアプリケーションの記述方法を変えたように、iApps Application Servicesは、一般的なアプリケーションデリバリサービスをアプリケーションの「前段」に配置するという従来の考え方を変革します。iApps Application Servicesは、デリバリ中の任意の時点で、アプリケーションデリバリチェーンのどの部分にも適用できます。これにより組織は、コンテキストに基づいて、どのサービスコンポーネントを、アプリケーションのどの部分に、いつ適用するかを選択できます。iAppsポリシーは、負荷分散構成の作成だけに限定されません。BIG-IP統合ADCプラットフォーム全体の一部として、iAppsポリシーには、BIG-IP APMを使用してアプリケーションにユーザーアクセスポリシーを割り当てるなど、高度なBIG-IPシステムモジュールおよび機能の構成設定も含めることができます。
iAppsテンプレート
テンプレートを利用できることは、iAppsの特に大きなメリットの1つです。アプリケーションテンプレートはバージョン10以降のBIG-IP LTMで利用できましたが、新しいアプリケーションの初期導入フェーズに用途が限られていました。また、後から稼働中の設定を変更するために使用することはできませんでした。
iApps Templatesは柔軟で使いやすく、アプリケーションサービスの導入と管理に役立ちます。すべてのBIG-IPシステムモジュールにわたって、アプリケーションの構築、管理、監視を行うための一元的なインターフェイスとして機能します。管理者が既存のテンプレートを使用して新しいiApps構成を作成すると、その構成はデバイスサービスクラスター内のすべてのBIG-IPデバイスで使用され、F5 Analyticsに必要な情報を提供します。
iApps Templatesでは、BIG-IPシステムの構成と管理に加え、IT部門内の複数のグループが、アプリケーションの提供と管理に必要なすべての設定を定義できます。部門横断型のアーキテクトチームは、IPアドレス情報を提供するネットワークチーム、キャッシュおよび圧縮ポリシーを構成するアプリケーションチーム、ユーザーおよび地域のアクセスポリシーを定義するセキュリティチームと連携してアプリケーションパラメーターを定義し、展開手順をiApps Templateに組み込むことができます。その後、テスト環境または本番環境のBIG-IPデバイスに導入できるよう、テンプレートをIT運用部門に引き渡せます。作成したiApps Templatesは、ビジネスおよびITのニーズの変化に応じて、該当するグループが変更し、組織全体で再利用できます。
iAppsのもう1つの大きなメリットは、ADCやインフラストラクチャ全体に新しいアプリケーションを導入する際の「専門知識を持つ担当者」への依存を解消できることです。アプリケーション所有者は、可用性を確保するために個別のBIG-IP LTMデバイスを導入したり、セキュリティを確保するためにBIG-IP ASMデバイスを導入したりする必要がなくなります。iAppsでは、アプリケーション所有者がiAppsのアプリケーション構成にこれらのサービスを追加するだけで、BIG-IPプラットフォームが適切なサービスと、それに関連するすべての構成要素を導入します。通常、アプリケーション所有者は、BIG-IPシステムアプライアンスを介して配信するアプリケーションの構成に多くの時間を費やします。iApps Templatesを使用すれば、この初期作業を組織全体で再利用できます。カスタマイズ可能なiApps Templatesでは、アプリケーションポリシーの調整とテストを一度行うだけで済みます。その構成をエクスポートし、追加のBIG-IPデバイスや他のIT部門と共有して再利用できるため、組織の運用コスト削減に役立ちます。
iAppsエコシステム
iApps構成ポリシーは、BIG-IPシステム間およびユーザー間で移行できるように設計されています。iApps Templatesはアプリケーション単位でエクスポートし、アプリケーションネットワーク全体で再利用できます。また、F5のコミュニティサイトであるDevCentralのiApps Ecosystemを通じてエクスポートおよび共有することもできます。そこでは、BIG-IPシステムの管理者や開発者が、他のアプリケーション向けに独自のiApps Templatesを作成、変更、共有したり、既存のiApps Templatesを調整したりできます。
F5は、新しいアプリケーション向けの公式iApps Templatesを、DevCentralのiApps Ecosystemを通じて定期的にリリースしています。これにより、Microsoft、IBM、OracleなどのF5パートナーが新しいアプリケーション向けに行ったエンジニアリング作業に加え、金融、政府、医療などの業種に特化したアプリケーションテンプレートも活用できます。
F5 Analytics
iAppsポリシーの大部分は、アプリケーションの配信に必要なトラフィック管理コンポーネントを構成するためのものです。一方、BIG-IPプラットフォームには、アプリケーションを監視するためのツールも含まれており、アプリケーションのパフォーマンス統計をリアルタイムで提供します。また、アプリケーション全体、仮想サーバー、プール、ノードについて、アプリケーション応答時間、ネットワーク遅延、接続統計など、診断やトラブルシューティングに役立つ情報も提供します。
従来の監視ツールとは異なり、F5 Analyticsはアプリケーションレベルでパフォーマンスデータを収集し、個々のインフラストラクチャコンポーネントではなく、アプリケーション自体に情報を関連付けます。アプリケーション所有者は、アプリケーションからアプリケーションサーバー、さらにネットワークに至るまで、パフォーマンスを監視できます。これにより、組織はアプリケーションの応答、ネットワークの状態、ユーザーコンテキストに基づいて、アプリケーションのパフォーマンスをリアルタイムで正確に監視できます。
F5 Analyticsは、BIG-IPシステムの統計データとログデータを活用します。これらのデータをJSONオブジェクトとして整形し、F5 BIG-IQなどのデータコンシューマーやSplunkなどのアプリケーションで利用できるようにエクスポートします。
F5 Analyticsでは、エクスポートするデータのカテゴリを複数設定できます。Splunkなどのデータコンシューマー向けに、データの送信先となるネットワークエンドポイントも設定できます。
デバイスサービスクラスター
データセンターのハードウェアデバイスは通常、Active/Standby（一方のシステムがすべての処理を担い、もう一方のシステムは、稼働中のシステムがオフラインになった時点でその処理を引き継ぐ）またはActive/Active（両方のシステムがデバイス間でワークロードを分散する）のいずれかの冗長ペアで運用されます。どちらの冗長構成も、ミッションクリティカルなハードウェアを導入する際のベストプラクティスですが、重大な設計上の欠陥が1つあります。この冗長アーキテクチャは、デバイス全体の障害を前提としている点です。
より優れたアプローチは、デバイス全体が稼働中か停止中かではなく、アプリケーション配信中の各時点でデバイスが実行している処理に基づいて、フォールトトレラントなアーキテクチャを構築することです。BIG-IPデバイスでは、アプリケーションレベルでスケーラブルかつフォールトトレラントなアーキテクチャを実現し、デバイス間のアプリケーション構成をフェイルオーバーによって保護できます。BIG-IPデバイスサービスクラスターは、Sync-OnlyモードとSync-Failoverモードという2つの構成オプションで動作します。
Sync-Only
BIG-IPデバイスサービスクラスターのSync-Onlyモードでは、複数のBIG-IPハードウェアアプライアンスとソフトウェアアプライアンス間で、アプリケーション固有の配信設定とテンプレートを動的に共有できます。これにより、変更が発生するたびに管理者がデバイス設定全体を手動で更新する必要がなくなります。BIG-IPのアプリケーションポリシーはハードウェア設定から分離されているため、管理者はBIG-IPの設定ファイル全体を複製する代わりに、アプリケーションとネットワークの情報をデバイス間で同期できます。これにより、IT部門は異なる設定のBIG-IPデバイスを運用しながら、各アプリケーション固有の設定とポリシーをデバイス間で同期できます。たとえば、各デバイス上の他のアプリケーションポリシーに影響を与えたり、セキュリティチームが個々のBIG-IP ASMポリシーを各デバイスに手動でインストールしたりすることなく、BIG-IP Application Security Manager（ASM）ポリシーをBIG-IPデバイス間で同期できます。
Sync-Failover
デバイス間の同期に加えて、アプリケーション構成では、稼働中のリアルタイムなアプリケーショントラフィックをデバイス間でフェイルオーバーできるため、Active/Activeの概念をアプリケーションレイヤーにまで拡張できます。BIG-IPデバイスサービスクラスタのSync-Failoverモードは、Active/Activeの1:1という概念をN:1に拡張します。これにより、リソースの制約と可用性に応じて、必要な数のアクティブデバイスでアプリケーション負荷を分担できます。これはRAID 5のストライピングの考え方とよく似ており、必要性と冗長性に基づいてディスク数を決定できます。
アプリケーションデリバリリソースの追加が必要になった場合、管理者はアクティブなBIG-IPデバイスをデバイスサービスクラスターに追加できます。クラスターは、新しいデバイスがオフラインになった場合に備えて専用のスタンバイデバイスをもう1台追加することなく、アプリケーションデリバリ全体の負荷の一部を担います。BIG-IPデバイスサービスクラスターでは、グループに新しく追加された各デバイスが、いずれかのデバイスがオフラインになった際に追加のアプリケーション負荷を引き受けられるため、一定の冗長性を担います。デバイスサービスクラスターに参加するBIG-IPデバイスが増えるほど、利用可能なすべてのデバイスにアプリケーション負荷をより効率的に分散できます。
戦略的な制御ポイント
iAppsの2つの重要な原則は、可視性と制御です。iAppsはインフラストラクチャ全体にわたり、これまでにないレベルの可視性と制御を提供します。ただし、その実現度は、ユーザー、アプリケーション、データの間にある連携された仲介レイヤーを通じて、すべての双方向アプリケーショントラフィックにあらゆるアプリケーションデリバリーロジックを動的に適用できる戦略的なポイントに配置されているかどうかに左右されます。このレイヤーは、アプリケーションやデータの現在の場所を問わず、すべてのアプリケーションとデータに利用できる一貫したインターフェースと一連のサービスを提供します。誰が、どこから、何に、なぜアクセスしているのかというコンテキストをインテリジェントに把握し、ユーザー、アプリケーション、データ間の最適な接続を決定します。さらに、コンテキストを詳細に把握することで、基盤となるアプリケーションとデータの各要素に現在のリソース要件を伝え、アプリケーションとデータへのアクセスを最適化できるよう、インフラストラクチャにリアルタイムでの適応を指示します。
この戦略的なアプリケーション情報の流れは、iApps構成の一部となります。iApps Templateによる初期構成は、理想的なアーキテクチャでアプリケーションをどのように配信すべきかに基づきます。アプリケーションは、配信ライフサイクル全体を通じてiApps TemplatesとBIG-IPデバイスサービスクラスターによって管理され、「何を」「どこで」に関する情報が提供されます。F5 Analyticsは「なぜ」に関する情報を提供し、分析用としてIT部門に報告します。iAppsは戦略的な制御ポイントに配置されており、このようにきめ細かく広範なアプリケーション配信管理を実現できる唯一の場所です。
まとめ
組織がよりモジュール化されたクラウドおよびSaaSモデルへ移行するにつれ、インフラストラクチャの構築よりもアプリケーションの管理が重要になっています。よりアジャイルなモデルへの移行によるメリットの多くは、インフラストラクチャの管理によって得られるものではありません。しかし、アプリケーションが依然としてインフラストラクチャに結び付いているため、クラウドおよびSaaS環境でアプリケーションのデプロイ、パフォーマンス、可用性を管理することは容易ではありません。iAppsは、アプリケーションの制御、可視化、管理を、データセンターの外部でそれらのアプリケーションやサービスを提供するために必要なインフラストラクチャに結び付けます。
iAppsは、分離したコンポーネントで構成される静的なリソースとしてのネットワークを、アプリケーションやサービスに直接関連付けられた、統合性、柔軟性、レジリエンスを備えたリソースプールへと変革するアーキテクチャをサポートします。この変革により、アプリケーション層でネットワークを迅速に導入、統合、管理し、可視化できるようになります。iAppsは、ネットワークをアプリケーションに適応させることで、アプリケーションデリバリインフラストラクチャ全体を完全に制御できるようにします。その結果、迅速な導入と一元化された機能によって運用コストを削減できます。F5 iAppsを使用すると、組織は戦略的な制御ポイントに、セキュリティ、アクセラレーション、可用性サービスの共通かつ再利用性の高いカタログを作成し、F5 BIG-IPデバイスに関する組織の俊敏性と効率を大幅に向上させることができます。
2017年12月14日公開