社内のデジタルトランスフォーメーションは、社外向けのデジタルトランスフォーメーションを実現するうえで不可欠です。社内のデジタルトランスフォーメーションを支える基盤要素の1つが自動化であり、その多くをコントロールプレーンに依存しています。コントロールプレーンは、自動化が行われる場所です。かつてのコンピューティング環境では、これを「管理ネットワーク」と呼び、SNMPなどのプロトコルを使用して監視、構成、制御を行っていました。
現在でも、少なくとも理論上は、コントロールプレーンを介して同じタスクを実行するための媒体として、管理ネットワークが存在しています。コントロールプレーンは、API、マスターノード、さらにはメッセージキューまでが混在する複雑な領域です。これらにより、複雑な分散システム内の個々のコンポーネントは、（ほぼ）自動的に自己管理できます。コントロールプレーンではイベント駆動型への移行が進んでおり、主に命令型の管理モデルに依存していた従来の一元的な指揮統制モデルから、発想を転換する必要があります。つまり、従来は中央システムが特定のAPI呼び出しを行い、変更を発生させることで、コンポーネントに暗黙的に指示していました。一方、現在の環境では、各コンポーネントに自己変更の責任を分散する宣言型モデルが採用されています。
この傾向が最も顕著に表れるのが、コンテナ化された環境です。外部から見ると、このようなシステムはほとんど統制が取れていないように見えます。メッセージやイベントが無秩序に発行・送出され、誰が、あるいは何がそれらに反応すべきかを指示する統括者も存在しません。コントロールプレーンの役割は、もはや制御そのものよりも、旧来の管理システムに見られるハブ＆スポーク型アーキテクチャではなく、メッシュに近いプレーン全体への分散にあります。従来の環境では、APIやプロトコルを使用してコンポーネントに変更をプッシュしていました。一方、デジタル化されたコンテナ環境では、コンポーネントが自らを変更するために必要な情報をAPIでプルします。
この新しい世界では、従来のコントロールプレーンにおける命令型（API駆動）モデルを避け、状況に応じて動作します。代わりに、よりオープンな宣言型モデルを採用し、望ましい最終状態への自動移行を実現します。
これは驚くことではありません。DevOps、クラウド、NFVの名の下に、あらゆるものにソフトウェア主導のアプローチを採用する動きが進む一方で、運用規模の大幅な拡大にも対処する必要が生じています。ハブ＆スポーク型の命令的な管理モデルでは、すべての変更に伴う負荷が中央コントローラーに集中します。このコントローラーは、複雑に入り組んだ多数のAPIを介して、ほぼ無数のコンポーネントと通信しなければならないため、効率的に拡張できません。これは、マネージャー（コントローラー）が影響を受ける各コンポーネントに変更をプッシュする「プッシュ」モデルです。コントローラーがボトルネックとなり、システム全体の成否を左右します。
スケーラビリティを確保し、コントローラーの負荷を軽減するには、コンポーネントによるプルに依存するイベント駆動型モデルが必要です。そのため、このコントロールプレーンに参加するコンポーネントは、宣言型構成モデルに対応できなければなりません。コンテナの普及により、API経由で変更をプッシュする命令型の方式ではなく、宣言型構成を通じて変更をプルする方式への移行が進んでいるためです。オープンソースか商用かを問わず、コンポーネントプロバイダーには、変更を適切にサブスクライブしたうえで、その変更を直ちに実装するために必要な情報をプルする責任があります。
これがInfrastructure as Codeのように聞こえるなら、その認識で間違いありません。宣言型構成は基本的にコード、少なくともコード成果物です。自動化は、構成をサービスから切り離すという前提にますます依存しています。理想的なモデルでは、こうした宣言型構成は特定の製品やベンダーにまったく依存しません。つまり、そのサービスをサポートするあらゆるベンダー（商用またはオープンソース）の製品で読み取れるということです。たとえば、適切なサービス（仮想サーバー）と、そのリソースプールを構成するアプリを記述した宣言型構成を、サービスXまたはサービスYに取り込んで実装できるようになります。
Kubernetesリソースファイルは、望ましい状態として「何を」実現するかを記述する一方で、それを「どのように」実現するかは一切規定しない宣言型構成モデルの好例です。これは、望ましい結果を実現する「方法」について、実装側が時には詳細に把握していることを求めるインフラストラクチャAPI依存のシステムとは大きく異なります。
宣言型モデルでは、インフラストラクチャを家畜のように扱うこともできます。1つに障害が発生しても、それを破棄して新しいインスタンスを起動するだけです。必要な設定はすべてリソースファイルに含まれているため、「作業内容を保存しないと失われます」というボタンはありません。そもそも失われる作業がないからです。これはほぼイミュータブルであり、まさに使い捨て可能なインフラストラクチャです。障害の影響を最小限に抑えるには、分単位、場合によっては秒単位で変化するシステムに不可欠です。
大規模なシステム、そしてあえて言えばセキュリティの自動化が進むにつれ、アプリケーションデータパスを構成する無数のデバイスやサービスの管理には、宣言型モデルを採用する必要があります。そうしなければ、手作業による統合と自動化で積み上がる運用上の負債に押しつぶされかねません。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
F5 Application Study Tool：OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版：リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。