Azure Fundamentals · レッスン

デプロイスロットとスワップ

Q: 「デプロイ スロットとスワップ」レッスンは無料ですか？

はい。「デプロイ スロットとスワップ」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Azure Fundamentalsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Azure Fundamentalsコースには全4レッスンが含まれています。

Q: 「デプロイ スロットとスワップ」で何を学びますか？

ブルーグリーン デプロイ用のステージング スロットを作成し、ステージング スロットで新しいリリースをウォームアップして、ダウンタイムなしで本番環境にスワップします。 ブラウザで直接実行するハンズオンコードでAzure Fundamentalsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

ブルーグリーンデプロイ用のステージングスロットを作成し、ステージングスロットで新しいリリースをウォームアップして、ダウンタイムなしで本番環境にスワップします。

「デプロイスロットとスワップ」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

デプロイスロットとは

デプロイスロットは、App Service Web アプリ用の稼働中の独立した環境です。それぞれに固有のホスト名（例: myapp-staging.azurewebsites.net）があります。スロットは本番スロットと同じ App Service プランおよびリソースを共有しますが、独立して実行されます。これによりブルーグリーンデプロイが可能になります。ステージングスロットで新しいリリースを検証し、その後、ダウンタイムなしで本番環境にスワップできます。スロットはStandard レベル以上で利用できます。

デプロイスロットの作成

Azure portal または CLI を使用して、Web アプリに新しいデプロイスロットを追加します。各スロットには固有の URL、アプリケーション設定、接続文字列が割り当てられます。Standard では最大5 個のスロット、Premium レベルでは最大20 個のスロットを作成できます。一般的なスロット名には、リリースパイプラインの段階を表すstaging、canary、hotfix、integrationなどがあります。

# Create a staging deployment slot
az webapp deployment slot create \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging

# Deploy code to the staging slot
az webapp deploy \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --src-path app.zip

# The staging slot is live at:
# https://MyUniqueWebApp-staging.azurewebsites.net

ステージングスロットのウォームアップ

スワップの前に、ステージングスロットをウォームアップして新しいバージョンを完全に初期化することが重要です。コールド状態の App Service インスタンスでは、ランタイムの初期化中に最初の要求への応答が遅くなるため、本番環境では許容できません。Auto Swapを有効にするか、ステージングスロットへウォームアップ用の HTTP 要求を手動で送信します。App Service では、スロットが準備完了と見なされる前に 200 を返す必要があるウォームアップパスを定義するための applicationInitialization 構成もサポートされています。

# web.config snippet for warm-up (IIS/Windows)
# <system.webServer>
#   <applicationInitialization>
#     <add initializationPage='/health' hostName='MyUniqueWebApp-staging.azurewebsites.net'/>
#   </applicationInitialization>
# </system.webServer>

# Or use a startup probe via the App Service health check
az webapp config set \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --generic-configurations '{"healthCheckPath": "/health"}'

スロットのスワップ

スワップによって、ステージングスロットと本番スロットがアトミックに入れ替わります。スワップ中、App Service はまず新しいコードを実行しているステージングインスタンスへトラフィックを振り分け、インスタンスの初期化を待ちます。その後、すべての本番トラフィックを新しいインスタンスへ振り分け、以前の本番インスタンスを新しいステージングスロットにします。これにより、もう一度スワップするだけで元に戻せるため、ロールバックが簡単になります。

# Swap staging into production
az webapp deployment slot swap \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --target-slot production

# Rollback: swap production back to staging
az webapp deployment slot swap \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot production \
  --target-slot staging

スロット固定設定と非固定設定

アプリケーション設定には、固定（スロット固有）または非固定（スワップ可能）の印を付けられます。非固定設定はスワップ時にデプロイスロットとともに移動するため、ステージングデータベースの接続文字列もコードとともに本番環境へ移動します。固定設定はスワップに関係なくスロットに留まるため、本番環境では常に本番データベースの接続文字列が使用されます。「deployment slot setting」チェックボックスまたは CLI を使用して、設定を固定として指定します。

# Mark a setting as sticky (slot-specific) -- it won't swap
az webapp config appsettings set \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --slot-settings DATABASE_URL='postgresql://staging-db/...'

# Set a non-sticky setting (it WILL travel with a swap)
az webapp config appsettings set \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --settings FEATURE_FLAG_NEW_UI=true

カナリアリリースのトラフィック分割

App Service はトラフィック分割をサポートしています。完全なスワップを実行せずに、本番トラフィックの一部を非本番スロットへ振り分ける機能です。これによりカナリアリリースが可能になり、新しいリリースへの信頼が高まるにつれて、トラフィックを 5%、10%、50% のように段階的に移行し、各段階でエラー率を監視できます。カナリアスロットにアクセスしたユーザーには固定 Cookie が付与され、セッションの一貫性を保つため同じバージョンが継続して提供されます。

# Route 10% of traffic to the staging slot (canary)
az webapp traffic-routing set \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --distribution staging=10

# View current traffic distribution
az webapp traffic-routing show \
  --name MyUniqueWebApp \
  --resource-group MyRG

# Reset all traffic to production
az webapp traffic-routing clear \
  --name MyUniqueWebApp \
  --resource-group MyRG

Auto Swap

Auto Swapを使用すると、ステージングスロットに新しいコードがデプロイされるたびに、そのスロットが自動的に本番環境へスワップされます。デプロイが成功するたびにすぐに公開したい CI/CD パイプラインに適しています。Auto Swap は、スワップを完了する前にステージングスロットの HTTP 要求が 200 を返すことを確認します。ポータルまたは CLI でスロットごとに有効化できますが、デプロイと本番反映の間に手動承認のゲートがないため、慎重に使用してください。

# Enable Auto Swap for the staging slot
az webapp deployment slot auto-swap \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --auto-swap-slot production

# Disable Auto Swap
az webapp deployment slot auto-swap \
  --name MyUniqueWebApp \
  --resource-group MyRG \
  --slot staging \
  --disable

デプロイスロットのベストプラクティス

デプロイスロットでは、次のベストプラクティスに従ってください。必ず本番環境へスワップする前にステージングで検証し、ステージングから本番へのデータベース接続を分離するために固定設定を使用します。デプロイ後はステージングスロットの URL に対してスモークテストを実行し、バージョンに問題がある場合に App Service がスワップを完了しないよう正常性チェックパスを構成します。また、各スロットでどのコミットが稼働しているか追跡できるよう、デプロイにタグを付けてください。

CI/CD パイプラインでのスロット

一般的な CI/CD パイプラインでは、ビルド段階でコードをコンパイルしてテストし、デプロイ段階で成果物をステージングスロットへプッシュし、統合テスト段階でステージング URL に対して自動テストを実行します。そしてスワップ段階でステージングを本番環境へスワップします。必要に応じて、手動承認を必須にすることもできます。このパターンは、Azure Pipelines と GitHub Actions のどちらでも、App Service deploy アクションを使用してネイティブにサポートされています。

# GitHub Actions step: deploy to staging slot
# - name: Deploy to Staging Slot
#   uses: azure/webapps-deploy@v2
#   with:
#     app-name: MyUniqueWebApp
#     slot-name: staging
#     publish-profile: ${{ secrets.AZURE_STAGING_PUBLISH_PROFILE }}
#
# - name: Swap to Production
#   uses: azure/CLI@v1
#   with:
#     inlineScript: |
#       az webapp deployment slot swap \
#         --name MyUniqueWebApp \
#         --resource-group MyRG \
#         --slot staging

スワップの正常性の監視

スロットのスワップ中およびスワップ後は、Azure Monitorで主要なメトリックを監視し、新しいバージョンが正常であることを確認します。HTTP 5xx エラー、平均応答時間、CPU/メモリ使用率の急増に注意してください。エラー率がしきい値を超えた場合に起動するメトリックアラートを設定すると、すぐに再スワップするための兆候を得られます。Application Insights のスマート検出では、デプロイ後の異常を自動的に通知できます。

# Create an alert rule for HTTP 5xx errors post-swap
az monitor metrics alert create \
  --name 'HighErrorRate' \
  --resource-group MyRG \
  --scopes '/subscriptions/.../providers/Microsoft.Web/sites/MyUniqueWebApp' \
  --condition 'avg Http5xx > 10' \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action-group MyActionGroup

スロットと複数のアプリの比較

ステージングと本番用に完全に別の App Service アプリを管理するよりも、デプロイスロットを使用する方が適しています。スロットは同じプランを共有するため追加コストがなく、ワンクリックのスワップとロールバック、トラフィック分割をサポートし、同じ App Service リソースの下で管理できます。ステージングに大きく異なるプラン SKU、分離要件、または完全に分離された課金が必要な場合に限り、別のアプリを使用してください。

クイックチェック

このレッスンで学んだ Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、デプロイスロットが分離された環境を提供し、ブルーグリーンデプロイを可能にすること、スロット固定設定によってデータベース URL などの環境固有の構成をコードではなくスロットに関連付けられること、そしてトラフィック分割によって本番トラフィックの一部を新しいバージョンへ振り分け、カナリアリリースを実現できることを学びました。次は、オートスケーリングとカスタムドメインについて説明します。

よくある質問