リポジトリと標準化がネットワーク自動化の統合課題の解決を支援

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

インテグレーションは、その実装プロジェクトに苦しむ人々の歯ぎしりや嘆きを想起させるという意味で、常に忌み嫌われる言葉でした。実際、IT意思決定者の59%が「インテグレーションは自組織の『アキレス腱』である」と回答しています。（The Connected Business Integration 2018 Report）

一見すると、統合は「アプリケーション間でデータを共有するにはどうすればよいか」という単純な前提から始まります。モノリシックなアプリケーションでさえ、単独では存在できないからです。少なくとも1つのデータを別のアプリケーションと共有していないアプリケーションを、私はこれまで見たことがありません。

業界では、これまで統合のあり方が幾度も変遷してきました。ハブ＆スポークモデルからエンタープライズサービスバス、メッセージキューに至るまで、統合は常にエンタープライズアプリケーション戦略に不可欠な要素です。

今ではEnterprise Application Integration（EAI）とは呼びません。若い世代を怖がらせ、古参の私たちを激怒させてしまうからだと私は思います。しかし、「インテグレーション」という言葉は今も使われています。しかも、アプリケーション開発以外の分野でも使われる機会が増えています。そもそもCIは、継続的インテグレーションを意味します。インテグレーションは、デプロイ（本番環境）側でも重要です。また、ネットワークの自動化に取り組む際、統合されたツールがないことに不満を抱く人々が指摘しているように、アプリケーション開発者と同じくらい大きなフラストレーションを感じています。

運用には統合が必要です。プロセスは必然的に複数のシステム、サービス、デバイスにまたがり、それぞれが独自の運用ドメインとツールセットを持つ可能性が高いため、統合なしではプロセスを自動化（すなわちオーケストレーション）できません。統合なしではパイプラインを構築できず、パイプラインがなければ、オンデマンドで頻繁にデプロイする必要性が高まるにつれて、運用部門は対応しきれなくなります。

そこで役立つのが、Infrastructure as Codeとリポジトリです。リポジトリは、構成ファイル、Pythonプログラム、スクリプト、テンプレートなど、ほぼあらゆる種類の成果物を保存するだけの場所ではありません。（統合された）デプロイパイプラインの一部として、能動的な役割を果たすことができます。

リポジトリは単なる保管庫ではない

リポジトリは、単にアーティファクトを保存する場所ではありません。もちろん、それが主な目的ですが、今では単なる保管庫をはるかに超える役割を担っています。現在、GitLabやGitHubなどのリポジトリは、自動化パイプラインの主要なコンポーネントになり得ます。トリガーやイベントを利用することで、リポジトリはアーティファクトの保存場所としてだけでなく、より大きなツールチェーンを構成するツールとしても機能します。コミットによってジョブが開始され、そのジョブが完了するとWebhookが呼び出され、パイプラインの次のステップがトリガーされます。

Webhookとは？

「リバースAPI」と呼ばれることもあるWebhookを使用すると、リポジトリなどのアプリケーションから別のアプリケーションへ、URL/APIを介してリアルタイムでデータを送信できます。たとえば、ロードバランサーの新しい設定がコミットされると、リポジトリがWebhookをトリガーします。これにより、設定またはそのURIがアプリケーション（またはロードバランサー）に直接送信され、新しい設定が読み込まれます。

基本的には、かつてエンタープライズサービスバスを使用していたのとほぼ同じ方法でリポジトリを使用し、データを共有するとともに、さまざまなアプリケーションやサービスでアクションを開始して、1つの「プロセス」を完了させています。ビジネスの現場では、そのプロセスは顧客からの注文を完了することであり、顧客情報システム（CIS）、受注処理システム、請求、サプライチェーンの各要素が関与する場合があります。

運用の現場では、このプロセスは、アプリケーションやポリシーのデプロイを実行するためのインフラストラクチャ、ネットワーク、セキュリティの各サービスにまたがります。

最大の課題として「スキル」を挙げた方にとって、さらに期待できる点は、リポジトリのほぼすべての操作をコマンドラインから実行できることです。しかも、ほとんどのNetOps担当者がすでに持っているスキルをそのまま活用できます。少しのbashとPERL*、curl経由のAPIがあれば、できあがりです。

ただし、これだけではデバイス層における統合という、より根本的なニーズには対応できません。ベンダーソリューションの不足に対する不満は、このニーズの表れです。結局のところ、リポジトリに保存され、Webhookによって処理が開始される構成や構成変更は、依然として各デバイスが理解できる形式に変換する必要があります。

そこで重要になるのが、標準化とソリューションです。

標準化で運用統合の負担を軽減

現在、F5では多くのメンバーが自動化に注力しています。そのために開発したソリューションの1つが、F5 Automation Toolchainです。これは、F5 Application Services 3 Extension（AS3）、F5 Declarative Onboarding（DO）、F5 Telemetry Streaming、F5 API Services Gatewayで構成されています。これらをリポジトリと組み合わせることで、アプリケーションの高速性、セキュリティ、可用性を維持するためにアプリケーションとビジネスが必要とするアプリケーションサービスを展開するためのパイプラインを、組織が構築できるようになります。

でもロリ、それでは自動化して統合する必要があるほかのすべてのデバイスやサービスには役立たない、と思われるでしょう。

そのとおりです。共通のアプリケーションサービスプラットフォームに標準化することで、この課題の解決に役立ちます。幅広いアプリケーションサービスで同じプラットフォーム（BIG-IP）を使用するため、自動化ツールチェーンを利用して、WAF、ロードバランサー、アクセス制御、DDoS対策などを導入できます。使用するプラットフォームを可能な限り少数に標準化すれば、ネットワーク、インフラストラクチャ、セキュリティの各運用における統合の負担が軽減され、価値が高まります。

これは、データセンター内でもマルチクラウド環境でも当てはまります。アプリケーションサービスとクラウド環境全体で単一のプラットフォームに標準化することで、場所を問わずアプリケーションを導入する際に、より短期間で価値を実現できます。

F5 Automation Toolchain（すべて無料）は、以下の場所から入手できます。

• On GitHubで
• On Docker Hubで
• F5 Ansible Modules

リポジトリは、単なる保管場所ではありません。自動化のための有用なツールであり、パイプラインを構成するさまざまな要素の自動化に役立ちます。アプリケーションサービスプラットフォームと併せてリポジトリを標準化することで、厄介な「統合」に伴う運用負荷を大幅に軽減できます。

※「PERL」は、Pythonなど、実際に使えるスクリプト言語に読み替えてください。PERLを挙げたのは、単に「curl」と韻を踏む唯一の言語だからです。「wget」と韻を踏む適切な言葉は見つかりませんでした。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事