F5アプリケーションサービスの自動化：実践ガイド
はじめに
アプリケーションデリバリおよびセキュリティデバイスの導入と構成管理の自動化は、ほぼ必須の取り組みとなっています。2017年のIDG FutureScape レポートでは、自動化とマルチクラウド管理が、2021年までにビジネスに影響を及ぼす主要な取り組みとして挙げられています。1 自動化により、アプリケーションに不可欠なセキュリティ、最適化、可用性の各サービスを大規模かつ確実に統合して導入できます。また、これらのサービスの提供を、アプリケーション導入の主流モデルになりつつある、オーケストレーションされたビルド、テスト、デプロイのワークフローに組み込むことができます。
新しい仮想サーバーやプールメンバーの追加といった基本的なタスクを簡単に自動化するだけでも、運用部門はアプリケーション所有者や他の自動化システムにセルフサービス機能を提供できるようになります。また、次世代の自動化ツールの構築など、より生産的な業務に充てる時間を確保できます。
組織がITサービスの提供に複数のクラウドプラットフォームを採用し始めると、自動化の必要性はさらに高まります。特性の異なるプラットフォームを使用して複数の拠点にサービスを展開する場合、自動化は、運用オーバーヘッドの増加による影響を軽減し、新しいプラットフォームに不慣れなことに起因するエラーを減らすのに役立ちます。
しかし、何をどのように自動化すればよいのでしょうか。運用モデル、インターフェース、言語が異なる中、自動化ソフトウェアは、単一デバイスのレイヤーで機能するものから、複数のシステムに対応するより複雑なツールまで多岐にわたります。Infrastructure-as-a-Service（IaaS）クラウドプラットフォームには、仮想インフラストラクチャとサービスを展開するための独自のネイティブツールが用意されています。さらに、F5はさまざまなインターフェースとオーケストレーションの選択肢を提供しています。こうした幅広いツールと選択肢により、組織に最適な方法で自動化できる一方、適切なツールの選定は容易ではありません。複雑化やツールの乱立というリスクも現実に存在します。
本書では、F5 BIG-IPアプライアンス（物理および仮想）の導入、管理、構成を自動化する方法の概要と、ビジネスに適した方法を選択するためのアドバイスをご紹介します。
自動化のライフサイクル
アプリケーションサービスを提供するライフサイクルには、自動化すべき重要なポイントがいくつかあります。インフラストラクチャモデルやアプリケーションのデプロイ方法によっては、そのすべてを開発する必要がある場合もあれば、一部のみでよい場合もあります。
大容量のマルチテナント対応の物理または仮想BIG-IPにサービスをデプロイする場合、BIG-IPがサポートする数百から数千のアプリケーションについて、アプリケーションサービス構成のデプロイ、監視、更新を行うことに比べ、ブートストラップやオンボーディングの優先度は高くありません。
各アプリケーションに専用のBIG-IPインスタンスを複数の環境で割り当てるデプロイモデルでは、テストやQAのためにオンデマンドで作成される一時的なインスタンスも含まれる可能性があります。この場合、ブートストラップとオンボーディングのプロセスの自動化は、アプリケーションサービス自体のデプロイと同様にクリティカルパスの一部となります。
環境や自動化が必要なプロセスの数にかかわらず、検討すべき重要なポイントがいくつかあります。
自動化における主な検討事項
自動化成熟度のスペクトラム
自動化には、さまざまな作業が含まれます。自動化成熟度の一方の端には、手動による構成作業を効率化するためにローカルで実行できる、Bash、TMSH、Pythonなどで記述された簡単なスクリプトの開発があります。もう一方の端には、ソースコード管理、ワークフローオーケストレーター、および複数の自動化ツール（使用する場合）を組み合わせた本格的な「Infrastructure as Code」システムがあります。このシステムでは、リポジトリ内のテキストファイルによってインフラストラクチャの構成を定義し、変更します。この両極の間には、BIG-IPプラットフォームの導入と構成の管理に役立つさまざまな選択肢があります。
ミュータブルとイミュータブル
現在のBIG-IP導入環境の多くは、可変と考えられます。つまり、その構成は時間の経過とともに変更されることが想定されます。これは、BIG-IPプラットフォームの多くが、複数のアプリケーションにサービスを提供するマルチテナントデバイスとして導入されているためです。新しいアプリケーションが導入された場合や、既存のアプリケーションがスケールしたり追加のサービスを必要としたりする場合、それに応じてBIG-IPの構成が更新されます。この導入方法により、インフラストラクチャチームは一元化されたインフラストラクチャ群を管理し、共通プラットフォームからアプリケーションにサービスを提供できます。
ただし、BIG-IPプラットフォームが独立したアプリケーションスタックの一部として導入され、特定のBIG-IPが提供するサービスが特定のアプリケーションまたはサービスに結び付けられる場合もあります。この場合、BIG-IPの構成はイミュータブルとして扱うことができます。つまり、構成は起動時またはソフトウェアイメージの一部としてインストールされ、BIG-IPインスタンスのライフサイクル中には変更されません。構成を変更するには、ソフトウェアイメージまたは起動エージェントスクリプトの内容を変更してから、再デプロイします。このモデルは一般に「nuke and pave」と呼ばれます。全体としてはあまり一般的ではありませんが、アプリケーション単位のインスタンスに対応する新しいBIG-IPライセンスモデル、高度なライセンスツール、F5 cloud libs（https://github.com/F5Networks/f5-cloud-libs）（クラウドでのBIG-IPのオンボーディングを支援するために設計されたNode.jsスクリプトおよびライブラリのセット）などのツールが利用可能になったことで、コードとインフラストラクチャの両方を密接に結び付けた分離スタックをアプリケーションに必要とする組織にとって、この導入モデルは現実的な選択肢となりつつあります。
命令型と宣言型
自動化インターフェースを利用者に公開する方法には、2つの概念モデルがあります。最も一般的な「第1世代」の自動化スキーマは、命令型モデルを採用する傾向があります。命令型の自動化モデルでは、通常、自動化の利用者は、達成したいことに加えて、そのための具体的な手順（通常はAPI呼び出し）も把握しておく必要があります。そのため、高度なサービスの設定内容を理解する負担だけでなく、サービスを自動化ツールと統合するための複雑さや作業も、利用者が担うことになりがちです。これは、サンドイッチを注文するだけで、作り手が必要な作業とその順序を理解していると期待するのではなく、サンドイッチを作るために必要な作業を一つひとつ指定して注文するようなものです。
これに対し、宣言型インターフェースでは、利用者（人間またはマシン）が求めるものを指定することでサービスを作成できます。自動化の対象には、求める結果に基づいて構成を作成するためのワークフローまたはサービステンプレートが事前に設定されているため、必要なすべての手順を詳しく把握する必要はありません。宣言型インターフェースでは初期設定がやや複雑になりますが、適切なサービステンプレートを構築した後は運用が簡素化されるため、その複雑さを補えます。そのため、一般に、自動化システムを構築する際に推奨される仕組みです。
直接または管理ツール経由
もう1つ検討すべき点は、自動化API呼び出しをサードパーティ製ツールから変更対象のデバイスに直接行うか、追加の管理ツールを介して行うかです。管理ツールを使用すると、運用を抽象化して簡素化できるほか、管理対象に直接接続する場合と比べて、制御やログ記録のレイヤーを追加できる可能性があります。ただし、迅速な変更が不可欠な状況に備え、管理レイヤーの高可用性を確保する必要があります。
API、スタートアップエージェント、CLIのどれを選ぶべきか
BIG-IPデバイスの自動化には、BIG-IPの機能の大部分を文書化されたスキーマを通じて公開するREST APIが最も一般的に使用されます。Ansibleなどの自動化ツール向けにF5が提供するモジュールでは、REST APIが広く活用されています。また、iControl LX機能を追加することで、1回のAPI呼び出しで複数ステップの処理を実行できる、ユーザー定義のAPIエンドポイントを作成できます。
BIG-IPの構成を自動化するもう1つの一般的な方法は、起動時に実行され、外部情報を取得してBIG-IPプラットフォームを構成できるスタートアップエージェントを使用することです。スタートアップエージェントは、デバイスを「オンボーディング」するための初期構成によく使用され、GitHubなどのサードパーティサイトや独自のリポジトリから追加のスクリプトや構成ファイルを取得できます。特に、アプリケーションごとに固定された構成を選択している場合は、スタートアップエージェントを使用してBIG-IPプラットフォームを完全に構成することもできます。
最も一般的な起動時設定はcloud-initです。Microsoft Azureを除くすべてのBIG-IP VEイメージで有効になっていますが、AWSおよびOpenStack環境へのデプロイに最適です。cloud-initに加えて、F5は起動時のBIG-IP設定を支援する一連のクラウド起動ライブラリを提供しています。
起動後にスタートアップエージェントを使用してプラットフォームを構成する場合は、障害管理に十分注意してください。外部ソースを使用する場合、特にスケーリングイベントの一環としてインスタンスが起動される可能性がある場合は、細心の注意が必要です。外部リソースを利用できない場合、システムはどのように動作するでしょうか。需要に対応しようとして、追加の「ゾンビ」デバイスが作成されることはないでしょうか。
場合によっては、自動化システムがユーザーとして動作し、CLIコマンドを実行できます。API呼び出しだけでは対応しきれない問題を解決できることもありますが、一般にサポートが難しく、ソリューションも脆弱になるため、この方法は最終手段としてください。
テンプレートとプレイブック
テンプレートとプレイブックを使用すると、デプロイを自動化し、一定程度標準化されたインフラストラクチャを構築できます。適切なレベルで標準化することで、インフラストラクチャの堅牢性とサポート性が向上します。適切に作成されたテンプレートは宣言型インターフェースを提供するため、リクエスト元のエンティティ（ユーザーまたはマシン）は、実装の詳細ではなく、必要なプロパティのみを把握すれば済みます。テンプレートのみを使用してデプロイし、テンプレートの修正によってのみ問題に対処することで、一般に問題の修正が一度で済むため、サービス品質の向上につながります。サービスは新しいテンプレートから再デプロイされ、テンプレートに加えた更新によって同じ問題の再発を防止できます。
プラットフォーム統合
プラットフォーム統合ツールは、BIG-IPサービスの設定を、プライベートクラウドやコンテナ管理システムなどのプラットフォームと連携させます。その仕組みはプラットフォームや実装によって異なりますが、一般に次の3つのモデルに分類されます。
- 既存のプラットフォーム構成要素へのF5サービスの組み込み
このモデルでは、既存のプラットフォーム構成要素を使用してF5サービスを組み込みます。たとえば、F5をOpenShift Container Platform Routerとして使用する場合や、F5をOpenStack Load Balancing as a Service (LBaaS)システムと併用する場合があります。プラットフォームネイティブのインターフェースを使用してサービスを構成し、付属のドライバーやその他のソフトウェアがプラットフォームの構成ディレクティブをF5の構成へシームレスに変換するため、これらの仕組みを使用しても運用手順をほとんど変更する必要はありません。ただし、容易に導入できるのは、プラットフォームネイティブのインターフェースから利用できる機能に限られる点に注意してください。 - プラットフォームイベントのサブスクライブ
もう1つの一般的な統合方法は、ソフトウェアモジュール（Container Connector for Kubernetes and for Mesosなど）がプラットフォーム内のイベントをサブスクライブし、そのイベントに基づいて構成を変更する方法です。サービスを提供する必要があるアプリケーションにタグまたはラベルを付け、必要なタグを持つイベントを監視するようにコネクターソフトウェアを構成することで、デプロイするイベントとサービスを選択できます。 - プラットフォーム管理ツールとの統合
多くのプライベートクラウドプラットフォームには、自動化を目的とした管理システムがあります。たとえば、VMwareには複数の管理・統合ツールがあり、その1つであるvRealize Orchestrator（vRO）には、BIG-IPの構成に対応するサードパーティ製プラグインがあります。ほかにも、OpenStack HEATテンプレートシステム用のプラグインなどがあります。
サービスディスカバリ
サービスディスカバリは完全な自動化ソリューションではありませんが、環境の変化に合わせてBIG-IPの構成を連携させるための、シンプルかつ強力な方法です。サービスディスカバリでは、APIを介してクラウドシステムを定期的にポーリングし、リソースの一覧を取得して、それに応じてBIG-IPの構成を変更します。バックエンドのコンピューティングリソースをスケーリングする際、ロードバランサーが新しいリソースを認識する必要があるため、リソースが自動スケーリンググループに構成されている環境では特に有用です。サービスディスカバリコンポーネントは、F5のクラウド自動スケーリングソリューション（AWSおよびAzure向け）に付属しています。
では、F5が推奨する自動化方式はあるのでしょうか。答えは、あるともないとも言えます。考慮すべき要素が非常に多いため、すべてを規定するような助言は役に立ちません。ただし、必要になるとF5が考える主要な構成要素を、連携する製品ファミリーとしてまとめています。
F5 Automation Toolchain
F5 Automation Toolchain製品ファミリーは、F5 BIG-IPプラットフォームをCI/CDツールチェーンなどの一般的な自動化パターンに統合するための、基本的な自動化およびオーケストレーションの構成要素で構成されています。
F5 Automation Toolchainには、以下の主要コンポーネントが含まれています
- Application Services 3 Extension（AS3）– 宣言型L4～L7 BIG-IPアプリケーションサービス
- Declarative Onboarding Extension (DO) – 宣言型L1～L3 BIG-IPオンボーディング
- Telemetry Streaming Extension (TS) – BIG-IPテレメトリを分析システムへ自動ストリーミング
- API Services Gateway (ASG) – カスタムiControl LX Extensions向けコンテナランタイム
Automation Toolchainファミリーは、クラウドテンプレートを使用したプラットフォームのデプロイから、オンボーディング、サービス構成、運用中のアプリケーションパフォーマンスを確保するための高度なテレメトリとロギングまで、アプリケーションサービスのデリバリーライフサイクルを管理できるように設計されています。
この拡充を続けるサポート対象ツール群は、F5アプリケーションサービスの自動化が今後進む方向性を示しています。ただし、ほかの統合が存在しない、またはサポートされていないという意味ではありません。詳しくは、本書の「その他の自動化ツール」セクションをご覧ください。
Application Services 3 Extension
F5 Applications Services 3 Extension（AS3）は、宣言型REST APIを介して、BIG-IPプラットフォーム上のレイヤー4～7のアプリケーションサービスのデプロイを自動化するための、シンプルで一貫性のある方法を提供します。AS3では、JSONドキュメントとして表現される、明確に定義されたオブジェクトモデルを使用します。宣言型インターフェースにより、F5アプリケーションサービスのデプロイを容易かつ確実に管理できます。
図：AS3アーキテクチャ
AS3拡張機能は宣言を取り込んで分析し、適切なiControl APIを呼び出して、対象のBIG-IP上に目的の最終状態を作成します。この拡張機能は、BIG-IPインスタンス上で実行することも、AS3 Extensionを実行してBIG-IPへの外部API呼び出しを行う独立したコンテナ／VMであるAS3 Containerを介して実行することもできます。
AS3の呼び出しは、BIG-IQ経由でも実行できます。BIG-IQは、BIG-IPプラットフォーム向けのライセンス管理、運用管理、可視化、アクセス制御を提供するほか、F5 Cloud Editionを支えています。F5 Cloud Editionは、強力な分析機能を備えたアプリケーション単位のBIG-IPインスタンスをオンデマンドで提供します。
Declarative Onboarding Extension
The Declarative Onboarding extensionは、初回起動直後のF5 BIG-IPプラットフォームを、アプリケーション向けのセキュリティおよびトラフィック管理を導入できる状態にするためのシンプルなインターフェースを提供します。これには、ライセンスやプロビジョニングなどのシステム設定、VLANやSelf IPなどのネットワーク設定、および複数のBIG-IPシステムを使用する場合のクラスタリング設定が含まれます。
オンボーディングプロセスが完了すると、選択した自動化プロセス（または手動プロセス）を使用してアプリケーションサービスをデプロイできます。
Declarative Onboardingは、AS3スキーマと整合するJSONスキーマを使用し、同様のアーキテクチャを採用しています。Declarative OnboardingはTMOSに依存しないRPMとして提供され、オンボーディングフェーズの最初のステップで、新たに起動したBIG-IPにインストールされます。
Telemetry Streaming Extension
BIG-IPは、アプリケーション、セキュリティ、ネットワークに関するテレメトリを生成する強力な基盤です。Telemetry Streaming拡張機能は、統計情報やイベントを次のようなサードパーティのコンシューマーにストリーミングするための設定を行える宣言型インターフェースを提供します。
- Splunk
- Azure Log Analytics
- AWS CloudWatch
- AWS S3
- Graphite
Automation Toolchainファミリーの他の製品と同様に、シンプルで一貫性のあるJSONスキーマを使用した宣言型インターフェースを通じて構成を管理します。
API Services Gateway
The APIサービスゲートウェイは、カスタムiControl LX拡張機能をTMOSに依存しないプラットフォーム上で実行できるDockerコンテナイメージです。個々のBIG-IPプラットフォームから管理操作を抽象化することで、F5環境の拡張と管理を支援します。
Cloud Templates — ソリューションの一部ですが、（まだ）製品ファミリーには含まれていません
クラウドテンプレートは、パブリッククラウドとプライベートクラウドのデプロイ自動化機能を使用して、BIG-IP仮想アプライアンスをプロビジョニングし、起動します。
F5は現在、以下のクラウド向けにサポート対象のテンプレートを提供しています。
- AWS – Cloud Formationテンプレート
- Azure – Azure Resource Managerテンプレート
- Google – Google Deployment Manager Templates
- VMware - vCenterテンプレート
- OpenStack – Heat Orchestration Templates
F5では、より幅広い導入シナリオに対応できるよう、クラウドテンプレートの開発を積極的に進めています。問題の報告やプルリクエストは、該当するgithubリポジトリから送信してください。
オーケストレーションおよびワークフローツールと継続的デリバリー／デプロイ
アプリケーションサービスは、アプリケーションを機能させるテクノロジースタックの一層にすぎません。アプリケーションをコードのコミットから本番環境へのデプロイと監視に移行するには、すべてのコンポーネントを統合、ビルド、デプロイする必要があります。その過程には、正しい順序で実行しなければならない依存関係のある多数のステップが含まれます。このプロセスを自動化するのがオーケストレーションツールです。連携するタスクとツールを組み合わせたワークフローパイプラインを構築します。
ほとんどのパイプラインは、アプリケーションのコード、テスト用コード、インフラストラクチャ構成を格納するソースコードリポジトリから始まります。
AS3、クラウドテンプレート、Declarative Onboardingなどのツールを使用すると、Applicationサービスの構築と設定に必要なすべての設定情報を、デプロイパイプラインの一部として保存できます。
マルチテナントで長期間稼働するBIG-IPハードウェアまたはソフトウェアプラットフォームを使用するアーキテクチャでは、アプリケーションのコードリポジトリの一部として管理する必要があるのは、AS3構成のみです。一方、デプロイプロセスの一環として専用インスタンスをオンデマンドで起動するシナリオでは、テンプレートとDeclarative Onboarding宣言をアプリケーションリポジトリの一部として管理する必要があります。
その他の自動化ツール：リソースガイド
考えられるすべての自動化ツールやオーケストレーションツールを網羅することはできませんが、F5のお客さまがよく利用しているツール、ユースケース、機能を以下にまとめます。
---------------
言語統合
言語
ステータス
例と出典
Python
F5提供
https://github.com/F5Networks/f5-common-python
Go
ユーザー投稿
https://github.com/f5devcentral/go-bigip
PowerShell
F5サポート対象
https://devcentral.f5.com/wiki/icontrol.powershell.ashx
構成管理およびインフラストラクチャ自動化ツール
ツール
ステータス
例と出典
Ansible
F5提供
https://github.com/F5Networks/f5-ansible
Terraform
F5提供
https://github.com/f5devcentral/terraform-provider-bigip
Puppet
F5によるコントリビューション
https://github.com/f5devcentral/f5-puppet
Chef
ユーザー提供
https://github.com/target/f5-bigip-cookbook
SaltStack
サードパーティ
https://docs.saltstack.com/en/latest/ref/runners/all/salt.runners.f5.html
インフラストラクチャテンプレートシステム
プラットフォーム
ステータス
例と出典
AWS
F5サポート対象
https://github.com/F5Networks/f5-aws-cloudformation
Azure
F5によるサポート
https://github.com/F5Networks/f5-azure-arm-templates
F5対応
https://github.com/F5Networks/f5-google-gdm-templates
OpenStack
F5サポート対象
https://github.com/F5Networks/f5-openstack-hot
------------------
スタートアップエージェントとクラウドスクリプト
Cloud-init
クラウドライブラリ
https://github.com/F5Networks/f5-cloud-libs
--------------------
プラットフォーム統合
コンテナ管理プラットフォーム
プラットフォーム
ステータス
例と出典
Kubernetes
F5によるサポート
https://github.com/F5Networks/k8s-bigip-ctlr
Pivotal Cloud Foundry
F5サポート対象
https://github.com/F5Networks/cf-bigip-ctlr
Marathon
F5サポート対象
https://github.com/F5Networks/marathon-bigip-ctlr
Red Hat OpenShift
F5対応
https://hub.docker.com/r/f5networks/k8s-bigip-ctlr (https://hub.docker.com/r/f5networks/k8s-bigip-ctlr) または
https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr (https://access.redhat.com/containers/?tab=tags#/registry.connect.redhat.com/f5networks/k8s-bigip-ctlr)
プライベートクラウドプラットフォーム
プラットフォーム
ステータス
例と出典
OpenStack (LBaaS)
F5サポート対象
https://github.com/F5Networks/f5-openstack-lbaasv2-driver
OpenStack (Heat)
F5対応
https://github.com/F5Networks/f5-openstack-hot
VMWare (vRO)
サードパーティ
https://bluemedora.com/products/f5/big-ip-for-vrealize-operations/
-----------------------
オーケストレーションツールとワークフローツールに関する注意事項
上記のツールと統合機能は、BIG-IPプラットフォームの導入と構成を自動化し、アプリケーションの可用性、セキュリティ、スケーリングの各サービスを提供する手段です。これらのサービスは不可欠ですが、フルスタックアプリケーションの導入を構成する一部にすぎません。サーバー、データ、コンパイル済みのアプリケーションコード、インフラストラクチャを連携させ、テスト済みの状態でフルアプリケーションスタックを構築するには、単純な自動化ツールだけでは不十分です。
より上位のオーケストレーションツールに加え、関連するワークフローや複数の自動化システムとの統合が必要です。こうしたツールは、継続的インテグレーション／継続的デリバリー（CI/CD）の実践で最も一般的に使用されます。CI/CDを実際に導入するうえで、自動化は事実上不可欠です。オーケストレーションツールはいくつもありますが、Jenkinsが最も一般的でしょう。また、ワークフローの例では、Jenkins、F5、Ansibleを使用して、F5のInfrastructure as Code機能をCI/CDワークフローに組み込む方法を紹介しています。ただし通常、オーケストレーションツールは、いずれかの構成自動化ツールを介して、実際の変更やサービスのデプロイを行います。
ライセンス
BIG-IPプラットフォームを機能させるにはライセンスが必要なため、自動化のクリティカルパスにライセンス付与を含めると効果的です。BIG-IP仮想デバイスの迅速なスケールアップやスケールダウン、またはテストおよび開発目的での作成が必要となる可能性がある、変化の激しい環境では、ライセンスモデルを慎重に検討する必要があります。
パブリッククラウドでは、クラウドマーケットプレイスで提供されているBIG-IPの従量課金版を利用する方法があります。従量課金インスタンスではライセンスが自動的に付与され、利用量または利用期間の契約に基づき、クラウドプロバイダーを通じて料金が請求されます。
もう1つの方法は、サブスクリプション（または永続ライセンス）として購入した再利用可能なライセンスプールを、F5 BIG-IQ License Managerと併用することです。これにより、プール内のライセンスを割り当てたり、取り消したりできます。
起動エージェントとAPI呼び出しを使用して、ライセンス付与の手順を自動化できます。その場合、F5ライセンスサーバーへのアウトバウンドインターネットアクセスが必要です（クラウドプラットフォームのユーティリティライセンスの場合も同様です）。
どのような場合に何を使用するか
組織の状況によっては、適切な自動化およびオーケストレーションツールの選定が非常に容易な場合もあれば、難しい場合もあります。他のコンポーネントですでにツールや手法を採用しており、BIG-IPをそのシステムに統合するだけであれば容易です。特定のツールと連携しない場合でも、豊富なiControl REST APIにiControl LXの機能とcloud-initを組み合わせることで、BIG-IPを既存の自動化ツールに比較的容易に統合できます（特に、1回のAPI呼び出しで複雑な構成も作成できるiAppテンプレートを併用する場合）。
ただし、ゼロから始める場合は、より複雑になることがあります。他のソリューションを選定する場合と同様に、まず要件を把握することが重要です。本書で要件リストを作成することはできませんが、評価に役立つ一連の質問と推奨事項を以下に示します。
自動化モデル： 宣言型モデルを採用すると、オーケストレーションの利用者ははるかに簡単に操作できます。利用者は、目的を達成するための手順をすべて把握する必要はなく、何を実現したいかを把握するだけで済みます。今後、グリーンフィールドサイトでは、F5 Automation Toolchainファミリーが「モデル」となる導入形態になります。
想定されるプラットフォームと環境：コンテナや各種クラウドプラットフォームがアプリケーションインフラストラクチャの重要な要素となることは避けられません。それを踏まえて計画してください。
スキル： 基盤となるテクノロジーの一部について、すでにスキルをお持ちでしょうか。こうしたスキルは、所属部門にはなくても、社内の別の部門に存在する可能性があります。その場合は、組織ですでに採用している言語を使用するツールを選ぶとよいでしょう。
サポート可能性： サポート可能なシステムのみを構築してください。当然のことに思えるかもしれませんが、成功の鍵は、組織内で対応できる複雑さのレベルを選ぶことです。これにより、過剰な運用負荷を生じさせることなく、自動化のメリットを最大限に引き出せます。
まとめ
ITシステムの自動化が進むことは避けられません。主要なアプリケーションデリバリおよびセキュリティサービスに戦略的に取り組むことで、組織が展開するアプリケーションのセキュリティと可用性を確保できます。また、自動化は、特に複数のプラットフォームやパブリッククラウドを利用する場合に、運用負荷の軽減にも役立ちます。
適切な自動化システムの選定は容易ではありません。利用可能なスキルセットと、構築するシステムをサポートする能力を考慮し、関係者が連携して包括的に取り組むことが理想的です。どのソリューションを選択しても、アプリケーションの展開場所を問わず、アプリケーションに不可欠なエンタープライズグレードのサービスを提供できるよう、BIG-IPプラットフォームとF5の専門知識が支援します。
F5のサポートに関する注意事項：F5は、複数のテンプレートとツールをサポートしていますが、すべてが対象ではありません。GitHubで提供されているソフトウェアについては、F5リポジトリ内の「supported」フォルダーにあるコードのみがサポート対象です。その他のソフトウェアについては、該当するREADMEファイルにサポートポリシーが記載されています。
2019年5月13日公開