NetOps自動化に宣言型モデルが重要な理由

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

あらゆるものを自動化するなら、宣言型のアプローチが適しています。その理由をご説明します。

自動化、特にNetOpsとアプリケーションサービスについて語る際、私たちは以前から宣言型アプローチの重要性を繰り返し訴えてきました。しかし、なぜ重要なのか、どのようなメリットがあるのかについては、まだ十分に掘り下げていません。そこで今回は、この点を詳しく説明します。

おさらいすると、現在、あらゆるものの構成とデプロイを自動化するために、2つのモデルが使用されています。

1つ目は命令型です。これは、実行したい処理の具体的な手順を対象システムに指示する方式です。システムへのSSHトンネルを開き、CLIで特定のコマンド一式を入力したことがあれば、命令型モデルで構成を行ったことになります。

2つ目（推奨される方式）は宣言型です。これは、対象システムに実行する内容を指示しますが、実行方法までは指定しません。ほとんどのネットワーク自動化ソリューションがこのモデルを採用しているのには、いくつかの理由があります。なかでも大きな理由は、特定の環境に存在し得る数百ものデバイスやシステムについて学習し、統合するには、膨大なコストと時間がかかることです。

つまり、命令型モデルでは、システムの構成に必要な各コマンド（またはAPI呼び出し）を個別に指定する必要があります。一方、宣言型モデルでは、通常、求める状態を表すキーと値のペアを指定するだけで、その状態を実現するためのコマンドは別のシステムに任せます。

とても簡単です。

では、なぜこれが重要なのかを説明します。あらゆるものの自動化を進める際に宣言型モデルを採用すると、主に4つのメリットがあります。

1. ヒューマンエラーを削減

本番環境で発生する停止インシデントの約22%は、人的ミスが原因であることがわかっています。ここでは改めて詳しく触れませんが、かなり注目を集めたインシデントの中にも、単純な人的ミスが直接の原因と判明したものがあります。API呼び出しに依存する命令型モデルでは、その一つひとつがインシデントにつながる可能性をはらんでいます。変数の検証を怠ったり、エラーコードの確認を忘れたりするなど、考えられるさまざまな状況によって、職務経歴書を更新する羽目になるかもしれません。これは望ましいことではありません。

宣言型モデルは、何らかのテンプレートまたは構成ファイルを基盤とします。これらは、API呼び出しによる処理の実行前に解析および検証されます。もちろん、構成ファイルやテンプレートでミスをする可能性はありますが、必要なコードが減るため、その機会は限られます。一般に、コードが少なければ、ミスをする機会も少なくなります。

2. 技術的負債の削減

技術的負債とは、開発の世界から取り入れた興味深い比喩であり、私たちの選択が長期的にもたらすコストを思い起こさせるものです。命令型モデルでは、さまざまな形で技術的負債が積み上がります。まず、スクリプトが対象システムのAPIに密結合します。そのAPIがほかのものをサポートする可能性は低いため、システムごとにスクリプトを開発することになります。また、構成手順もアプリごとに異なる可能性があります。すべてがHTTPというわけではなく、HTTPベースのアプリケーションでも、まったく同じサービス構成が必要とは限りません。その結果、アプリごと、システムごとにスクリプトを作成することになります。これは膨大な数のスクリプトを生み、その選択によって多くの負債が積み上がることを意味します。

一方、宣言型の手法では、同じデプロイプロセスのスクリプトとシステムを使用できます。テンプレートや構成はアプリケーションおよびシステムごとに異なる可能性がありますが、単一のファイルにまとめられます。これにより、スクリプトの複雑さと数が減り、技術的負債を大幅に削減できます。どのような選択にもある程度の負債は伴うため、それを最小限に抑えることが目標です。

3. バージョンの競合を解消

構成とデプロイのプロセスをAPIに結び付けると、そのAPIの特定のバージョンに依存することになります。インターネット上の多くのコミュニティでは、APIの変更や、それに伴うアプリの修正作業について、開発者が怒りをあらわにして不満を述べています。同じことは、ネットワークサービスやアプリケーションサービスでも起こり得ます（そして実際に起こります）。つまり、APIの1つのバージョンに依存している状態で何かが変更されると、どうなるでしょうか。延々とスクリプトを更新（場合によっては書き直し）することになります*。

しかし、宣言型モデルを採用していれば、APIに変更があっても影響を受けずに済む可能性が高くなります。APIを使ってサービスをどのようにデプロイするかをシステムに指示するのではなく、何をデプロイする必要があるかだけを伝えるためです。

4. ドメインに関する専門知識の要件を軽減

現実問題として、ネットワークサービスやアプリケーションサービスのAPIを使用するには、そのシステムを理解しておく必要があります。仮想IPと仮想サーバーの違いが分からなければ、ノードとメンバーの違いを考える以前に、すでに問題に直面しています。命令型のAPIベースの手法では、対象システムの設定を適切に操作できる程度に、そのシステムを理解しておく必要があります。

宣言型モデルを使用すると、対象システムに関する専門知識が少なくて済むため、開発者もDevOps担当者も、この方法を利用してアプリケーションをセルフサービスで提供しやすくなります。もちろん専門家は引き続き必要ですが、サービス利用者に求められる知識やスキルは軽減され、プロビジョニングとデプロイの負担をより幅広い関係者に分散できます。

NetOpsの自動化に宣言型モデルを採用する理由はほかにもありますが、特に説得力があるのはこの4つです。これらはNetOpsとビジネスに加え、アプリケーションの高速化とセキュリティ強化を支えるネットワークおよびアプリケーションサービスへのセルフサービスアクセスを必要とする、幅広い関係者にメリットをもたらします。

著者について

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

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

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