Azure Service Fabric

解決する課題

多数のサービスを多数のサーバーへ安定して配置し、障害時の再配置やローリング更新を自前で書かずに運用できます。

• 多数のマイクロサービスを多数のノードへ配置し、ノード障害時に自動で別ノードへ再配置したい
• アプリの状態（セッション、集計値、キューなど）をクラスタ内で複製し、外部 DB なしでも高可用にしたい
• バージョン更新をローリングで行い、問題時に自動ロールバックしたい
• コンテナと、コンテナを使わない実行ファイル（ゲストプロセス）の両方を同じ基盤で動かしたい
• Kubernetes ではなく、ステートフルな実行モデルを標準で備えたオーケストレーターが欲しい

主要概念と用語

• クラスタ（Cluster）: 相互接続されたノード（VM）の集合。アプリはこのクラスタ上に配置される
• ノード（Node）: クラスタを構成する 1 台。多くはノードタイプごとの仮想マシンスケールセットに対応する
• ノードタイプ（Node Type）: 同一構成のノード群。プライマリノードタイプはシステムサービスを載せる
• アプリケーション／サービス: デプロイ単位。1 つのアプリは複数のサービスを含む
• ステートレスサービス: 状態を内部に持たないサービス。外部ストアに状態を逃がす一般的な形
• ステートフルサービス: 状態をReliable Collections としてクラスタ内に保持・複製するサービス
• パーティション: サービスの状態を分割する単位。スケールアウトの基本単位になる
• レプリカ: パーティションの実体。プライマリ 1 + セカンダリ複数で複製し、可用性を担保する
• プログラミングモデル: Reliable Services、Reliable Actors、ゲスト実行ファイル、コンテナを選べる
• Cluster Resource Manager: サービスをノードへ最適配置し、障害時に再配置する内部スケジューラ

仕様・制限・クォータ

• クラスタは Windows / Linux のどちらでも構成でき、コンテナとゲスト実行ファイルの両方を実行できる
• ノードは通常仮想マシンスケールセットとして構成し、ノードタイプ単位で VM サイズや台数を設計する
• プライマリノードタイプはシステムサービスを載せるため、本番では推奨される最小台数を満たす必要がある
• ステートフルサービスはパーティション × レプリカで構成し、レプリカ数で可用性、パーティション数でスケールを決める
• クラスタの VM 台数やコア数は、サブスクリプション／リージョンのクォータの範囲で、引き上げ申請が可能
• 具体的なクォータ数値や推奨台数は変動するため、計画時は対象リージョンの最新値を確認する

内部の仕組み

Service Fabric は、クラスタ上にシステムサービス（命名、フェイルオーバー管理、Cluster Resource Manager など）を常駐させた分散オーケストレーターです。利用者はアプリケーションとサービスを宣言し、Service Fabric が各サービスのインスタンスやレプリカを空きノードへ配置します。

• Cluster Resource Manager が負荷とノード障害を見ながらサービスを再配置し、特定ノードへの偏りをならす
• ステートフルサービスでは、プライマリレプリカが書き込みを受け、セカンダリレプリカへ複製する。プライマリ障害時はセカンダリが昇格してフェイルオーバーする
• 状態は Reliable Collections（信頼性のあるディクショナリ／キュー）として保持され、複製とトランザクションがフレームワークに組み込まれている
• アップグレードはアップグレードドメイン単位で順に進むローリング更新で行われ、ヘルスチェックに失敗すると自動でロールバックできる
• ノードの健全性はヘルスモデル（ノード・アプリ・サービス・パーティション・レプリカの階層）で集約・評価される

設計パターン / ベストプラクティス

• まずステートレス + 外部ストアを基本形にし、ステートフルは状態の局所性が必要な箇所に限定する
• ステートフルサービスはパーティション設計を先に固める。後からのパーティション数変更は容易でないため、将来のスケールを見込んで決める
• アップグレードはアップグレードドメインごとのローリングとヘルスポリシーを設定し、失敗時の自動ロールバックを効かせる
• アプリとサービスのバージョン管理を徹底し、差分のみを更新する構成にして無停止更新の範囲を広げる
• 新規開発で Kubernetes エコシステムや運用最小化を重視するなら、AKS／Container Apps を併せて評価する

運用・監視

• メトリクスとログは Azure Monitor / Log Analytics に集約し、ノード・サービス・レプリカの健全性とリソース使用率を監視する
• クラスタの状態は Service Fabric Explorer（Web UI）でノード、アプリ、パーティション、レプリカの階層を可視化して調査する
• サービスが配置されない／再配置が頻発する場合は、ノードタイプの容量、配置制約、Cluster Resource Manager のメトリクスを確認する
• アップグレードが止まる場合は、ヘルスポリシーとアップグレードドメインの進行状況、失敗したヘルスイベントを確認する
• デプロイ・運用は az sf CLI や Service Fabric SDK、各種パイプラインから自動化する

コスト

Service Fabric のランタイム自体に追加料金はなく、課金対象はクラスタを構成する VM（スケールセット）・ストレージ・ネットワーク・ロードバランサーなどの基盤リソースです。

• コントロールプレーン的なシステムサービスを維持するため、常時ゼロ台にはできない点が Container Apps との大きな違い
• 定常的に稼働する VM 分は予約インスタンスや Savings Planで単価を下げられる場合がある（要計測）

セキュリティ

• ノードから他リソースへのアクセスはマネージド IDを用い、接続文字列やキーのハードコードを避ける（AWS の IAM ロール相当）
• 秘密情報は Key Vault で管理し、アプリのパラメータやスクリプトに平文で埋め込まない
• クラスタの管理エンドポイントと Service Fabric Explorer は証明書ベースの認証と Microsoft Entra ID で保護し、公開範囲を絞る
• ネットワークは仮想ネットワークにクラスタを配置し、ネットワークセキュリティグループで管理／アプリのポートを制限する
• ノード間通信とクライアント通信は TLS で暗号化し、証明書のローテーション運用を整える

関連サービス・比較

新規のコンテナワークロードでは、運用を最小化できる Azure Container Apps や、Kubernetes エコシステムをそのまま使える AKS が主流です。Service Fabric はステートフルな実行モデルを標準で備える点に独自性があり、既存資産の継続運用やその要件で選ばれます。

ハンズオン / CLI例

# Service Fabric CLI 拡張とリソースグループを準備
az extension add --name sf --upgrade
az group create --name demo-rg --location japaneast

# テスト用クラスタを作成（証明書はキー コンテナーへ自動生成）
# 本番では台数・VM サイズ・ノードタイプを設計したテンプレートを使う
az sf cluster create \
  --resource-group demo-rg \
  --location japaneast \
  --cluster-name demo-sf \
  --cluster-size 3 \
  --vm-password "<安全なパスワードを指定>" \
  --certificate-output-folder ./certs \
  --certificate-password "<証明書パスワード>" \
  --certificate-subject-name demo-sf.japaneast.cloudapp.azure.com

# クラスタの状態を確認
az sf cluster show \
  --resource-group demo-rg \
  --cluster-name demo-sf

# クラスタに接続して（証明書を指定）アプリの状態を確認
sfctl cluster select \
  --endpoint https://demo-sf.japaneast.cloudapp.azure.com:19080 \
  --pem ./certs/demo-sf.pem --no-verify
sfctl application list