はじめに
Azure Service Fabric は、Azure SQL DB, Event Hub, Microsoft Teamsなどの Azure のコアインフラストラクチャやミッションクリティカルなサービスを提供する基盤テクノロジとしても利用されている Azure サービスになります。
2020/9/28 に Azure Service Fabric Managed Clusterが Public Previewとなりました。
今回は実際にリソースを作成して既存の Service Fabricとの違いなどを整理していきたいと思います。
Service Fabric Managed Cluster とは
Service Fabric は VM Scaleset を中心にディスクや仮想ネットワークやロードバランサーといった各種 Azure リソースが組み合わされて提供されるサービスです。
そのため従来では、そういった関連リソースの管理についてもユーザが担う必要があり、例えば Azure Resource Manager テンプレートなどで Service Fabric をデプロイし、構成更新などをおこなう場合、全ての関連リソースの定義を矛盾なく定義する必要があり、かなりのコストが必要でした。
Service Fabric Managed Cluster では、ユーザは"Managed Cluster"という単一のリソースに集約して管理することで関連する各 Azure リソース をユーザが管理する必要がなくなりました。
従来の Service Fabric では、関連リソースを含めるとシンプルな構成でも 1000 行近い定義を記述する必要がありましたが、Managed Cluster では 100 行ほどに圧縮されます。
Service Fabric のトラブルの多くが関連リソースに対する不適切な構成や操作を起因したもので"Managed Cluster"という抽象化レイヤーを挟むことで管理を簡潔化し不要なトラブルを軽減できることを見込んでいます。
以下は概念図となります。従来は各種 Resource Provider (RP) 毎の操作をユーザが管理する必要がありましたが、Managed Cluster では Service Fabric RP を経由した操作になり直接構成リソースを操作することがないため不適切な構成や操作のリスクを軽減できます。
** 従来の Service Fabric Cluster **
** Service Fabric Managed Cluster **
Service Fabric の Tech Community では次のようなポイントが Managed Cluster の特徴として挙げられていました。クラスター証明書の更新が完全 Managed になったのもうれしいですね。
-
Encapsulated Resource Model
クラスターを構成する個別のリソース (VM、ストレージ、ネットワーク構成など) をすべて定義しなくてもクラスターを作成できます。 -
Storage backed by managed disks
VM に付属する一時記憶域のサイズに制限されなくなりました。これで、アプリケーションのニーズを満たすストレージの量を簡単に選択できるようになりました。 -
Fully managed cluster certificates
クラスター証明書は Azure によって完全に管理されるようになったので、期限切れのクラスター証明書などの心配が必要ありません。 -
Single step cluster operations
以前に複数のステップが必要なノード・タイプの除去などの操作を、単一ステップで完了できるようになりました。Service Fabric の管理対象クラスターは、要求を満たすために必要な変更を自動的に行い、プロセス中のエラーをより適切に処理します。 -
Enhanced cluster safety
クラスター操作は、Service Fabric リソース プロバイダーによって検証され、安全に実行できることを確認します。 -
Simplified Cluster SKUs
テスト環境と実稼働環境の作成に役立つ 2 つの新しいクラスター SKU (基本、標準)。標準 SKU を使用する場合、クラスター内の使用可能なリソースを最大限に活用するために、耐久性と信頼性の値が自動的に調整されます。
テンプレート
Azure Powershell などからもデプロイが可能ですが、今回はリソース構成を正確に把握したいので ARM Template を使ってデプロイしようと思います。サンプルテンプレートが提供されているのでこちらを使いますが、ちょっとazuredeploy.json の中身を見てみます。
|
|
Microsoft.ServiceFabric/managedclusters と Microsoft.ServiceFabric/managedclusters/nodetypes のリソースをデプロイするだけのテンプレートとなっており非常にシンプルです。全体でも130行程度しかありません。
なお、この2つのリソース定義については、こちらにリファレンスがあります。
ちなみに nodetypes は、Service Fabric に関連付けられた仮想マシンのコレクション(VM Scaleset)を表します。なので OS Imageの種別や VM サイズやディスクサイズなど VM に関するパラメータを持っているんですね。
Microsoft.ServiceFabric/managedclusters では従来 NRP (Network Resource Provider) や CRP (Compute Resource Provider)で定義されていたロードバランサーの設定や各ノードの管理者アカウント情報の設定が含まれているところが特徴的です。これらの設定を元にユーザが定義する必要なくロードバランサーや VM リソースが作成されていきます。
リソース構成
このテンプレートを使って実際に Managed Cluster をデプロイしてみました。
※デプロイ時には Service Fabric Explorer などに接続する際に利用するクライアント証明書が必要です。今回は検証用にCN=<デプロイするクラスタ名>.<リージョン>.cloudapp.azure.comの自己証明書を作成しておきthumprintをデプロイパラメータに指定しました。
デプロイしたリソースグループを見てみると、マネージド Service Fabric クラスターという見慣れない種類のリソースが作成されています。※keyvaultは証明書用に別途作成したリソースでテンプレートとは無関係
この managedsf というリソースを選択してみましょう。…まだポータルからはデプロイ時に指定した細かな構成などは確認できず最低限の情報しか見れないようですね。
Resource Explorerだと細かい構成値が見えるようです。ここらへんは一般提供時には拡充されているでしょう。
次に Service Fabric Cluster の本体となるロードバランサーや VM Scaleset です。これまでの Service Fabric だと Service Fabric Clusterと同一のリソースグループにすべてのリソースが共存していましたが、Managed Cluster ではどうやらSFC_
配下のリソースなどを確認すると Microsoft.ServiceFabric/managedclusters と Microsoft.ServiceFabric/managedclusters/nodetypes で設定した値に沿って関連リソースが作成されていることがわかります。
おわりに
実際に Service Fabric Managed Cluster をデプロイしてみましたが、まだまだポータル操作などは制限が多いようですので実際にノードのスケール操作などを試すのであれば Powershell などコマンドラインからとなりそうです。 ノードのディスク構成周りも既存の Service Fabric と変わっているみたいなので、機会があればそちらもまとめてみたいと思います。
参考資料
Azure Service Fabric managed clusters are now in public preview
Azure Resource Manager テンプレートを使用して Service Fabric マネージド クラスター (プレビュー) をデプロイする