iControl REST と AS3 の違いは何ですか？

AS3 は iControl REST の上で動作する宣言型のラッパーです。iControl REST が「どのように」(段階的な作成) を管理する必要があるのに対し、AS3 は「何を」(望ましい最終状態) 定義することを可能にし、F5 がシーケンスとクリーンアップを処理します。

AS3 への部分的な移行のリスクは何ですか？

最大の課題は状態管理です。AS3 を使用している間に誰かが GUI を介して手動で変更を加えると、次の AS3 宣言でそれらの手動変更が上書きされます。Git を唯一の真実の情報源として確立し、GUI/CLI アクセスをロックダウンする必要があります。

VLAN や NTP のようなシステムレベルの設定に REST/AS3 を使用できますか？

TMSH を使用してローカルユーザーを設定できますが、最新のアプローチは Declarative Onboarding (DO) 拡張機能を使用することです。これにより、VLAN、DNS、Self-IP、ユーザーアカウントなどのシステムレベルの設定を単一の JSON 宣言で管理できます。

既存の TMSH 設定を AS3 に変換するツールはありますか？

はい、BIG-IP Visual Studio Code 拡張機能が強く推奨されます。これには「AS3 Schema Validator」と「TMSH to AS3」コンバーターが含まれており、既存の設定を JSON 宣言に変換することで移行を迅速に進めるのに役立ちます。

AS3 JSON ペイロードはどこに送信するのですか？

AS3 エンドポイントは通常、管理インターフェースの /mgmt/shared/appsvcs/declare でホストされます。高負荷環境では、REST フレームワークのパフォーマンス向上を利用するために、BIG-IP バージョン 15.1 以降を実行していることを確認してください。

AS3 はマルチクラウド展開をどのように処理しますか？

レガシーデータセンターの場合、ローカルの BIG-IP iSeries または rSeries が推奨されます。クラウド環境の場合、同じ AS3 宣言が AWS、Azure、GCP の BIG-IP Virtual Editions で同一に機能するため、ハイブリッドクラウドのアプリケーションデリバリに最適なツールとなります。

F5 BIG-IP TMSH から REST/AS3 へ: 2026年移行計画

F5 BIG-IP を命令型の従来の TMSH スクリプトや脆い Expect ベースの自動化で管理する時代は終わりました。もし未だに VIPRION や iSeries シャーシに SSH 接続して tmsh create ltm virtual を実行しているのであれば、流行に遅れているだけでなく、2026 年の自動化ロードマップを破綻させる技術的負債を蓄積しています。業界は Application Services 3 (AS3) 宣言型モデルへと明確に移行しており、命令型の iControl REST API から F5 Automation Toolchain を使用した純粋な GitOps ワークフローへの移行は、大規模なネットワークエンジニアリングにとって選択肢ではなくなりました。

命令型 TMSH の構造的欠陥

TMSH (Traffic Management Shell) は機械のためではなく、人間のために設計されました。iControl SOAP および初期の iControl REST インターフェースは橋渡しとなりましたが、「操作順序」の悪夢に苦しみました。典型的な TMSH スクリプトでは、プールから削除する前にノードを削除しようとしたり、仮想サーバーにアタッチされている間にプールを削除しようとすると、トランザクションが失敗します。これにより、エンジニアはオブジェクトの依存関係を追跡するために複雑なエラー処理ロジックを記述する必要がありました。

さらに、TMSH は一括操作には非常に遅いことで知られています。シリアル化された SSH セッションは、HTTPS を介した RESTful 呼び出しにはないレイテンシを発生させます。さらに重要なことに、TMSH にはネイティブな状態検証がありません。指示を出すと、それが試行され、途中で失敗すると、「半端な」設定が残り、監査するのに苦労します。REST および最終的には AS3 に移行することで、べき等な設定が可能になります。これは、達成するまでの手順ではなく、最終的な結果が定義される状態ベースの管理です。

フェーズ 1: TMSH から iControl REST へのマッピング

AS3 に飛び込む前に、基盤となる REST API が長年使用してきたコマンドにどのようにマッピングされるかを理解する必要があります。F5 iControl REST API は予測可能な URI 構造 /mgmt/tm/ltm/... に従います。たとえば、ノードを作成するための標準的な TMSH コマンドは次のとおりです。

tmsh create ltm node 10.1.1.50 address 10.1.1.50 description "WebSrv01"

これは、JSON ペイロードを含む /mgmt/tm/ltm/node への POST リクエストに変換されます。

{
  "name": "10.1.1.50",
  "address": "10.1.1.50",
  "description": "WebSrv01"
}

これは SSH のオーバーヘッドを解決しますが、完全なスタック (ノード -> プール -> 仮想サーバー) を構築するには依然として複数の呼び出しが必要です。ここで、2026 年のプレイブックは F5 Automation Toolchain、特に App Services Extension への移行を要求します。

フェーズ 2: 宣言型モデル (AS3) への移行

AS3 (Application Services 3 Extension) は、F5 自動化の業界標準です。アプリケーションを構築するために複数のエンドポイントを呼び出す代わりに、単一の JSON 宣言を /mgmt/shared/appsvcs/declare エンドポイントに送信します。AS3 は、依存関係ロジック、操作順序、および未使用リソースのクリーンアップを処理します。

「アプリケーション」をデリバリの最小単位と見なしてみましょう。AS3 では、「仮想サーバー」を管理するのではなく、「テナント」と「アプリケーション」を管理します。LTM ポリシーと WAF プロファイルを備えた標準的な HTTPS VIP の典型的な AS3 宣言は次のようになります。

{
    "class": "ADC",
    "schemaVersion": "3.0.0",
    "id": "TechLeague_Migration_01",
    "Tenant_Web": {
        "class": "Tenant",
        "App_Secure": {
            "class": "Application",
            "template": "https",
            "serviceMain": {
                "class": "Service_HTTPS",
                "virtualAddresses": ["192.168.10.100"],
                "pool": "web_pool",
                "serverTLS": "tls_common"
            },
            "web_pool": {
                "class": "Pool",
                "monitors": ["http"],
                "members": [{
                    "servicePort": 80,
                    "serverAddresses": ["10.10.1.10", "10.10.1.11"]
                }]
            }
        }
    }
}

この宣言は一度に送信されます。プールが既に存在すれば、AS3 がそれを更新します。メンバーを削除する必要があれば、AS3 がそれを削除します。これが、AS3 が生の REST よりも優れている理由です。それは真にべき等だからです。

フェーズ 3: CI/CD パイプライン (GitOps) の構築

現代の F5 管理はソフトウェア開発に似ているべきです。「真実の源」は、デバイス上の /config/bigip.conf ファイルではなくなり、Git リポジトリ内の YAML または JSON ファイルとなります。すべてのプルリクエストでトリガーされる GitLab または GitHub Actions ワークフローを推奨します。

1. Linting: AS3 スキーマバリデータを使用して、JSON が構文的に正しいことを確認します。
2. staging: 開発ラボで実行されている BIG-IP VE (Virtual Edition) に宣言をプッシュします。
3. Validation: staging VIP に対して自動化された curl または Postman テストを実行します。
4. Production: 承認後、CI ランナーが本番 F5 クラスターに POST リクエストを発行します。

F5 BIG-IP Next パターンを早期に活用することで、組織は F5 ハードウェア (rSeries) の次世代に備えることができます。これは完全にこれらの REST/AS3 基盤の上に構築されています。古い rSeries ハードウェア (r5000/r10000) は、F5OS レイヤーとテナントレイヤーが分離されているため、特にこの恩恵を受け、スケーリングのための自動化が必須となります。

テレメトリと可視性: SNMP を超えて

TMSH からの移行は設定だけではありません。オブザーバビリティに関するものです。F5 の監視に未だに SNMP ポーリングを使用している場合、きめ細かなデータを見逃しています。Automation Toolchain の一部である Telemetry Streaming (TS) 拡張機能を使用すると、AS3 に似た宣言型モデルを使用して、リアルタイムのメトリックを Splunk、ELK、または Datadog にプッシュできます。

show ltm virtual 出力を解析するためにカスタムの Perl スクリプトを書くのはやめましょう。代わりに、TS コンシューマを設定して、プールメンバーのヘルス、SSL ハンドシェイクのレイテンシ、スループットのメトリックを直接ストリーミングします。これにより、SOC は F5 ログとアプリケーションサーバーログを単一の画面で相関させることができます。

レガシーなパーシステンスと iRule の処理

TMSH から REST への移行における共通の摩擦点は、複雑な iRule の処理です。TMSH では、何百行もの Tcl コードがあるかもしれません。AS3 では、iRule を参照したりインラインで定義したりできる「BigIP」オブジェクトとして扱います。ただし、可能な限り iRule から LTM ポリシーへとロジックを移行することを提案します。ポリシーは AS3 スキーマでネイティブにサポートされており、iRule よりもはるかに優れたパフォーマンスを発揮します。これは、ポリシーが TMM (Traffic Management Microkernel) バイトコードに効率的にコンパイルされるためです。

残す必要のある iRule については、AS3 の base64 エンコーディング機能を使用して、特殊文字や改行が JSON ペイロードを壊さないようにします。これにより、Git リポジトリをクリーンで読みやすい状態に保つことができます。

2026 年の結論: パフォーマンスとコスト

TMSH/SSH を介して BIG-IP エコシステムを運用することは、人員に比例してスケールします。より多くの VIP を管理するには、より多くのエンジニアが必要です。AS3 と GitOps を介して運用することは対数的にスケールします。単一のエンジニアが、20 のグローバルクラスターにわたって 500 以上の仮想サーバーを、5 つを管理するのと同じ労力で管理できます。iSeries 5800 や新しい rSeries r10900 のようなハードウェアは、10 万ドルから 20 万ドル以上の費用がかかる場合がありますが、自動化を怠ると、投資の持つ生のスループットとマルチテナンシー機能を無駄にすることになります。

私たちは Fortune 500 の金融企業向けにこれらのパターンを実装し、「Time-to-VIP」を 5 日 (手動チケット) から 4 分 (自動化された PR) に短縮しました。現在の F5 自動化の成熟度をベンチマークしたり、カスタム AS3 スキーマ設計が必要な場合は、techleague.io のプロフェッショナルサービスをご覧ください。