Azure Spring Apps

解決する課題

• 既存の Spring Boot / Spring Cloud アプリを、作り直さずにマネージド基盤へ載せたい
• サービス検出（Eureka）・構成サーバー（Config Server）・ゲートウェイといった Spring Cloud の定番部品を自前で運用したくない
• JVM のチューニングや OS のパッチ適用に手間をかけず、アプリのコードに集中したい
• マイクロサービス間の通信や設定の一元管理を、プラットフォーム側に任せたい
• 仮想マシンや素の Kubernetes を自分で運用するほどの制御は要らないが、PaaS の手軽さは欲しい

主要概念と用語

• Service インスタンス: Spring Apps の最上位リソース。複数のアプリと共有設定（ネットワーク・監視先など）を束ねる境界
• アプリ（App）: デプロイ単位。1つの Spring Boot アプリに対応し、複数のデプロイを持てる
• デプロイ（Deployment）: アプリの実体となるバージョン。本番用とステージング用を併存させ、Blue/Green 的に切り替えられる
• Config Server（構成サーバー）: Git リポジトリ上の設定を集中管理し、各アプリへ配布する Spring Cloud Config のマネージド版
• Service Registry（サービスレジストリ）: アプリ同士が名前で呼び合うためのサービス検出。Eureka 相当をマネージドで提供
• ビルドサービス: ソースコードや JAR から、Buildpacks を使ってコンテナイメージを自動生成する仕組み
• プラン: 提供形態の区分。基本的な Spring 部品を備えた標準系と、VMware Tanzu のコンポーネントを含む Enterprise 系がある

仕様・制限・クォータ

• デプロイの単位は アプリごとの vCPU・メモリ割り当てで、インスタンス数を増減して水平スケールする
• JAR / WAR・ソースコード・コンテナイメージなど複数の成果物形態からデプロイできる（プランにより対応範囲が異なる）
• Config Server・Service Registry などの Spring Cloud 部品は基盤側が提供し、利用者がクラスタを構築する必要はない
• サブスクリプション / リージョンごとに、アプリ数やコア数などのクォータがあり、引き上げ申請ができる
• 具体的な上限やプランごとの機能差は変動するため、断定せず最新の公式情報で確認すること

内部の仕組み

Azure Spring Apps は、利用者から見えないマネージドな実行基盤の上で各アプリを動かす PaaS です。利用者はアプリと割り当てリソース・インスタンス数を宣言し、OS のパッチ適用・ロードバランシング・スケールはプラットフォーム側が担います。

Spring Cloud の代表的な部品である Config Server（構成）と Service Registry（サービス検出）は基盤側のマネージドサービスとして提供されます。利用者がこれらを別途デプロイ・運用する必要はなく、アプリは設定の取得やサービス呼び出しを通常の Spring の流儀で行うだけで済みます。

成果物のデプロイ時は、ビルドサービスが Buildpacks を使ってソースや JAR からコンテナイメージを生成し、実行基盤へ配置します。スケールアウトすると同じアプリが複数インスタンスで動くため、アプリはステートレスに設計し、状態はアプリ外（データベースや Redis など）へ逃がすのが前提になります。

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

• アプリはステートレスに保ち、状態は外部（データベース・Blob・Azure Cache for Redis）へ逃がす
• 設定はコードに埋め込まず Config Server（Git バック）で一元管理し、環境ごとの差分を構成で吸収する
• サービス間連携はサービスレジストリ経由の名前解決で疎結合に保ち、ホスト名を直書きしない
• リリースはステージング用デプロイで検証してから切り替え、問題時はすぐ戻せるようにする
• バックエンド（DB など）との通信は仮想ネットワーク統合で閉域化する

運用・監視

• Application Insights を有効化し、要求数・応答時間・例外・依存関係や分散トレースを可視化する
• プラットフォームのメトリクスとログは Azure Monitor / Log Analytics に集約し、アラートを設定する
• 起動失敗時は、アプリのログストリームでスタートアップログや JVM・依存関係の整合を確認する
• スケールが追従しない場合は、アプリの割り当てリソースと最大インスタンス数・自動スケール条件を見直す
• デプロイ後に不調なら、まず直前の安定デプロイへ切り替えて戻すことを第一の対応にする

コスト

• 課金は基本的に アプリへ割り当てた vCPU・メモリ × インスタンス数 × 稼働時間に対して発生する
• インスタンスを確保したままだとアイドルでも課金されるため、需要に応じて台数を調整する
• プランによって機能と価格帯が異なるため、必要な Spring 部品の範囲に見合うプランを選ぶ
• 自動スケールで需要に追従させ、過剰な常時インスタンスを避けるとコスト効率が上がる
• 具体的な料金はプラン・リージョンで変わるため、断定せず公式の料金ページで見積もる

セキュリティ

• マネージド ID をアプリに付与し、Key Vault やデータベースへ資格情報なしでアクセスする（AWS の IAM ロール相当）
• シークレットは Key Vault から注入し、設定ファイルやイメージへの平文埋め込みを避ける
• 仮想ネットワーク統合 / プライベートエンドポイントで受信・送信の経路を閉域化する
• 認証・認可は Entra ID と連携し、アプリ側の独自実装を減らす
• ビルドに使うベースイメージや依存ライブラリを更新し、脆弱性のある JAR を持ち込まない

関連サービス・比較

最も近い比較対象は Azure Container Apps です。Spring 専用の部品を基盤が提供してくれる手厚さが Spring Apps の利点ですが、提供終了が案内されている現在は、汎用のコンテナ基盤である Container Apps へ寄せるのが基本方針になります。

ハンズオン / CLI例

# 拡張機能とリソースグループを準備
az extension add --name spring --upgrade
az group create --name demo-rg --location japaneast

# Spring Apps の Service インスタンスを作成
az spring create \
  --name demo-spring \
  --resource-group demo-rg \
  --location japaneast

# アプリを作成（外部公開・パブリックエンドポイント有効）
az spring app create \
  --name api \
  --service demo-spring \
  --resource-group demo-rg \
  --assign-endpoint true

# ビルド済み JAR をデプロイ
az spring app deploy \
  --name api \
  --service demo-spring \
  --resource-group demo-rg \
  --artifact-path ./target/demo-0.0.1-SNAPSHOT.jar

# インスタンス数を増やして水平スケール
az spring app scale \
  --name api \
  --service demo-spring \
  --resource-group demo-rg \
  --instance-count 3

# 公開 URL を確認
az spring app show \
  --name api \
  --service demo-spring \
  --resource-group demo-rg \
  --query properties.url -o tsv