信頼性に関する推奨事項

[アーティクル]
12/23/2024

Azure Advisor を使用して、ビジネスに不可欠なアプリケーションの継続稼働を保証し、さらに向上させることができます。信頼性に関する推奨事項は、Advisor ダッシュボードの [信頼性] タブで得ることができます。

Azure Portal にサインインします。
任意のページから [Advisor] を検索して選択します。
Advisor ダッシュボードで、[信頼性] タブを選びます。

AgFood プラットフォーム

API Management

API Management サービスを stv2 プラットフォームに移行する

stv1 プラットフォームでホストされている API Management インスタンスのサポートは、2024 年 8 月 31 日で廃止される予定です。サービスの中断を避けるために、その前に stv2 ベースのプラットフォームに移行してください。

潜在的な利点: サービスの安定性を向上させ、新しいプラットフォーム機能を活用します

詳細については、「API Management stv1 プラットフォームの提供終了 - グローバル Azure クラウド (2024 年 8 月)」を参照してください

ホスト名証明書のローテーションに失敗しました

API Management サービスで Key Vault からホスト名証明書の更新を取得できず、その結果、古い証明書を使用しているサービスやランタイム API トラフィックがブロックされる可能性があります。証明書が Key Vault に存在し、API Management サービス ID にシークレットの読み取りアクセスが許可されていることを確認します。

潜在的な利点: サービス可用性を確保します

詳細については、「Azure API Management インスタンスのカスタムドメイン名を構成する」を参照してください

レガシポータルは 3 年前に非推奨となり、2023 年 10 月に廃止されました。ただし、ポータルのアクティブな使用は、無効にするとすぐにサービスの中断を引き起こす可能性があります。

引き続きサービスを楽しみ、新機能や改善点をご活用いただくには、できるだけ早く新しい開発者ポータルに移行することを強くお勧めします。

潜在的な利点: ビジネス継続性を確保します

詳細については、「新しい開発者ポータルへの移行」を参照してください

依存関係ネットワークの状態チェックに失敗しました

Azure API Management サービスの依存関係は使用できません。仮想ネットワークの構成を確認してください。

潜在的な利点: サービスの安定性を向上させます

詳細については、「Azure API Management インスタンスを仮想ネットワークにデプロイする - 内部モード」を参照してください

SSL/TLS の再ネゴシエーションがブロックされた

SSL/TLS 再ネゴシエーションの試行がブロックされました。セキュリティで保護された通信が失敗する可能性があります。クライアント証明書の認証シナリオをサポートするには、一覧に表示されているホスト名で [クライアント証明書のネゴシエート] を有効にします。ブラウザーベースのクライアントの場合、このオプションを使用すると、証明書を要求するメッセージがクライアントに表示されることがあります。

潜在的な利点: サービス可用性を確保します

詳細については、「API Management でクライアント証明書認証を使用して API を保護する方法」を参照してください

Azure API Management インスタンスを複数の Azure リージョンにデプロイしてサービスの可用性を高める

Azure API Management では複数リージョンの展開がサポートされているため、API 発行元は、リージョンの API ゲートウェイを既存の API Management インスタンスに追加することができます。複数リージョンのデプロイにより、地理的に分散した API コンシューマーによって認識される要求待ち時間が短くなり、サービスの可用性を向上できます。

潜在的な利点: リージョンの障害に対する回復性を高めます

詳細については、「複数の Azure リージョンに Azure API Management サービスインスタンスをデプロイする方法」を参照してください

運用環境のワークロードで API Management インスタンスの自動スケールを有効にして構成します。

運用サービスレベルの API Management インスタンスは、ユニットを追加および削除することでスケーリングできます。自動スケール機能では、手動による介入なしに負荷の変化に対応するために、API Management インスタンスのユニットを動的に調整できます。

潜在的な利点: スケーラビリティを向上させ、コストを最適化します。

詳細については、「Azure API Management インスタンスを自動的にスケーリングする」を参照してください

App Service

CPU 不足を避けるために App Service プランをスケールアウトします

CPU 使用率が高い場合、アプリケーションの実行時の問題が発生する可能性があります。お使いのアプリは過去数日間に 90% 超の CPU に達しました。 CPU 使用率を減らし、ランタイムの問題を回避するには、アプリケーションをスケールアウトします。

潜在的な利点: アプリを正常な状態に保ちます

詳細については、「Azure App Service のベストプラクティス」を参照してください

アプリのサービス正常性の問題を確認する

アプリのサービス正常性に関する推奨事項があります。 Azure portal を開き、アプリに移動し、[診断と解決] をクリックして詳細を確認します。

潜在的な利点: アプリを正常な状態に保ちます

詳細については、「Azure App Service のベストプラクティス」を参照してください

App Service リソースのバックアップデータベース設定を修正する

アプリケーションに無効なデータベース構成がある場合、そのバックアップは失敗します。詳細については、アプリケーション管理ページで、お使いのアプリのバックアップ履歴を参照してください。

潜在的な利点: ビジネス継続性を確保します

詳細については、「Azure App Service のベストプラクティス」を参照してください

App Service リソースのバックアップストレージ設定を修正する

アプリケーションに無効なストレージ設定がある場合、そのバックアップは失敗します。詳細については、アプリケーション管理ページで、お使いのアプリのバックアップ履歴を参照してください。

潜在的な利点: ビジネス継続性を確保します

詳細については、「Azure App Service のベストプラクティス」を参照してください

メモリの問題を回避するために App Service プラン SKU をスケールアップする

お使いのアプリを含む App Service プランは、メモリ割り当ての 85% 超に達しました。メモリ消費量が多いと、アプリケーションの実行時に問題が発生する可能性があります。問題のあるアプリケーションを見つけて、より多くのメモリリソースで上位のプランにスケールアップします。

潜在的な利点: アプリを正常な状態に保ちます

詳細については、「Azure App Service のベストプラクティス」を参照してください

App Service プランのスケールアウト

定期的なメンテナンスの間にコールドスタートの遅延とサービスの中断を回避するには、App Service プランを少なくとも 2 インスタンスにスケールアウトすることを検討します。

潜在的な利点: ユーザーエクスペリエンスと可用性を最適化します

詳細については、https://aka.ms/appsvcnuminstances を参照してください

ハンドルされない例外が原因でワーカープロセスがクラッシュしたため、アプリケーションコードを修正する

ハンドルされない例外が原因で、アプリケーションのワーカープロセスがクラッシュしました。根本原因を特定するには、クラッシュ時にメモリダンプと呼び出し履歴情報を収集します。

潜在的な利点: アプリを正常で可用性の高い状態に保ちます

詳細については、https://aka.ms/appsvcproactivecrashmonitoring を参照してください

App Service を Standard プランにアップグレードして、要求が拒否されないようにする

アプリケーションが共有 App Service プランの一部であり、複数回クォータに達している場合、受信要求が拒否される可能性があります。クォータに達すると、Web アプリケーションで受信要求を受け取ることができなくなります。クォータを削除するには、Standard プランにアップグレードします。

潜在的な利点: アプリを正常な状態に保ちます

詳細については、「Azure App Service プランの概要」を参照してください

App Service リソースを Standard 以上に移行し、デプロイスロットを使用する

アプリケーションが 1 週間に複数回デプロイされると、問題が発生する可能性があります。過去 1 週間に複数回アプリケーションをデプロイしました。運用 Web アプリケーションへのデプロイへの影響を軽減するには、App Service リソースを Standard (またはそれ以上) のプランに移動し、デプロイスロットを使用します。

潜在的な利点: 更新中にアプリを正常な状態に保ちます

詳細については、「Azure App Service でステージング環境を設定する」を参照してください

このサブスクリプション内の静的 Web アプリのホスティングプランを Standard SKU にアップグレードすることを検討してください。

このサブスクリプション内のすべての無料の SKU 静的 Web アプリで使用される帯域幅合計が、100 GB の月ごとの制限を超えています。調整を回避するために、これらのアプリを Standard SKU にアップグレードすることを検討してください。

潜在的な利点: 調整を回避することで、アプリの可用性を高めます。

詳細については、「Static Web Apps の価格」を参照してください

App Service リソースのデプロイスロットを使用する

アプリケーションが 1 週間に複数回デプロイされると、問題が発生する可能性があります。過去 1 週間に複数回アプリケーションがデプロイされました。変更を管理し、運用 Web アプリへのデプロイの影響を軽減するには、デプロイスロットを使用します。

潜在的な利点: 更新中にアプリを正常な状態に保ちます

詳細については、「Azure App Service でステージング環境を設定する」を参照してください

アプリケーションアーキテクチャを 64 ビットに変更することを検討する

App Service は 32 ビットとして構成されており、メモリ消費量は上限の 2 GB に近づいています。アプリケーションでサポートされている場合は、アプリケーションを再コンパイルし、App Service 構成を 64 ビットに変更することを検討してください。

潜在的な利点: アプリケーションの信頼性を向上させます

詳細については、「Azure での Web アプリのアプリケーションパフォーマンスに関するよくあるご質問」を参照してください

CX オブザーバーのパーソナライズされたレコメンデーション

潜在的な利点: NA

App Service 証明書

App Service 証明書の発行に必要なドメイン検証

現在、App Service 証明書が発行保留状態であり、ドメインの確認が必要です。ドメインの所有権を確認できない場合、証明書の発行は失敗します。 App Service証明書のドメイン証明書が自動化されていないので、アクションが必要です。最近ドメインの所有権を確認済みであり、証明書が発行されている場合は、このメッセージを無視してかまいません。

潜在的な利点: App Service 証明書の発行を確実に成功させます。

詳細については、「Azure App Service で TLS/SSL 証明書を追加および管理する」を参照してください

Application Gateway

SKU をアップグレードするか、インスタンスを追加する

2 つ以上の中規模または大規模なインスタンスをデプロイすると、計画済みまたは計画外のメンテナンスによる機能停止中のビジネス継続性 (フォールトトレランス) が確保されます。

潜在的な利点: アプリケーションゲートウェイの回復性によってビジネス継続性を確保します

詳細については、「マルチリージョンの負荷分散 - Azure リファレンスアーキテクチャ」を参照してください

サイトの整合性を確保するため、ホスト名を上書きしない

Application Gateway を構成するときは、ホスト名を上書きしないようにする。 Application Gateway のフロントエンドのドメインが、バックエンドへのアクセスに使用されるものと異なっていると、Cookie やリダイレクト URL が破損する可能性があります。バックエンドがドメインの違いに対応できることを確認するか、バックエンドに対してホスト名を上書きする必要がないように Application Gateway の構成を更新してください。 App Service と共に使用するときは、カスタムドメイン名を Web アプリにアタッチし、バックエンドに対して *.azurewebsites.net ホスト名を使用しないようにします。ここで留意すべきは、フロントエンドドメインが異なるとすべての状況で問題となるわけではないこと、そして REST API などの特定のカテゴリのバックエンドでは、一般に影響は比較的小さいことです。

潜在的な利点: 回復性がある Application Gateway の構成により、サイトの整合性を確保し、Cookie やリダイレクト URL が壊れないようにします。

詳細については、「Application Gateway での App Service に関する問題のトラブルシューティング」を参照してください

Network Performance Monitor に ExpressRoute モニターを実装する

ExpressRoute 回線が Network Performance 上の ExpressRoute モニターによって監視されていない場合、オンプレミスから Azure リソース、および Azure からオンプレミスリソースへの損失、待機時間、およびパフォーマンスの通知に気付けません。エンドツーエンドの監視を実現するに、Network Performance に ExpressRoute モニターを実装してください。

潜在的な利点: ネットワーク内の問題の検出と緩和にかかる時間を短縮し、ExpressRoute を使用してネットワークパスに関する分析情報を提供します

詳細については、「ExpressRoute に使用する Network Performance Monitor の構成 (非推奨)」を参照してください

クロスプレミスの回復性のために Virtual Network に複数の ExpressRoute 回線を実装する

ExpressRoute ゲートウェイに関連付けられている ExpressRoute 回線が 1 つしかない場合、回復性の問題が発生する可能性があります。ピアリングの場所の冗長性と回復性を確保するには、1 つ以上の追加回線をゲートウェイに接続します。

潜在的な利点: ExpressRoute ピアリングの場所で障害が発生した場合の回復性を向上させます

詳細については、「ExpressRoute を使用した高可用性のための設計」を参照してください

可能であれば別のリージョンで、プロファイルに少なくとも 1 つ以上のエンドポイントを追加する

プロファイルには、エンドポイントの 1 つで障害が発生した場合に可用性を確保するために、複数のエンドポイントを設定する必要があります。また、それらのエンドポイントを異なるリージョンに配置することをお勧めします。

潜在的な利点: フェールオーバーを可能にすることで、回復性を向上させます

詳細については、「Traffic Manager エンドポイント」を参照してください

"[すべて (世界)]" に構成されたエンドポイントを追加する

地理的なルーティングの場合、トラフィックは、定義されているリージョンのエンドポイントにルーティングされます。リージョンで障害が発生した場合、定義済みのフェールオーバーはありません。 [リージョンのグループ化] で地理的なプロファイルが [すべて (世界)] に構成されたエンドポイントを配置すると、トラフィックのブラックホール化が回避され、サービスの可用性が保証されます。

潜在的な利点: トラフィックのブラックホールを回避することで、回復性を向上させます

詳細については、「エンドポイントを追加、無効化、有効化、削除、または移動する」を参照してください

あるエンドポイントを別の Azure リージョンに追加または移動する

この近接プロファイルに関連付けられているすべてのエンドポイントは、同じリージョンにあります。他のリージョンからのユーザーは、接続しようとするときの待機時間が長くなる場合があります。別のリージョンにエンドポイントを追加または移動すれば、近接ルーティングの全体的なパフォーマンスが向上し、1 つのリージョン内のすべてのエンドポイントで障害が発生した場合の可用性が高まります。

潜在的な利点: 別のリージョンへのフェールオーバーを可能にすることで、回復性を向上させます

詳細については、「パフォーマンスによるトラフィックルーティング方法の構成」を参照してください

Basic ゲートウェイから運用ゲートウェイ SKU への移行

Basic VPN SKU は、開発またはテストのシナリオ用の SKU です。運用環境に VPN ゲートウェイを使用している場合は、運用 SKU に移行してください。運用 SKU ではより多くのトンネルを使用できるほか、Border Gateway Protocol (BGP)、アクティブ/アクティブ構成、カスタム IPsec/IKE ポリシーがサポートされており、安定性と可用性を向上させることができます。

潜在的な利点: 使用可能な機能が追加され、安定性と可用性が向上します

詳細については、「VPN Gateway の構成設定について」を参照してください

冗長性を確保するためにアクティブ/アクティブゲートウェイを有効にする

アクティブ/アクティブ構成では、VPN ゲートウェイの両方のインスタンスが、オンプレミスの VPN デバイスへのサイト間 (S2S) VPN トンネルを確立します。計画メンテナンスまたは計画外のイベントが 1 つのゲートウェイインスタンスで発生すると、トラフィックはもう 1 つのアクティブな IPsec トンネルに自動的に切り替えられます。

潜在的な利点: 接続の回復性によってビジネス継続性を確保します

詳細については、「クロスプレミス接続と VNet 間接続用の高可用性ゲートウェイ接続を設計する」を参照してください

配信元グループに配信元が 1 つしかない場合に正常性プローブを無効にする

配信元が 1 つだけの場合、正常性プローブが異常な状態を報告した場合でも、Front Door は常にその配信元にトラフィックをルーティングします。正常性プローブの状態は、Front Door の動作変更に対しては何も行いません。このシナリオでは、正常性プローブには利点はありません。

潜在的な利点: 不要な正常性プローブのトラフィックを減らすことで、サービスの可用性を確保します

詳細については、「Front Door のベストプラクティス」を参照してください

マネージド TLS 証明書を使用する

Front Door で TLS 証明書を管理すると、運用コストが削減され、証明書の更新忘れにより発生する停止コストを回避できます。 Front Door では、マネージド TLS 証明書の発行と回転が自動的に行われます。

潜在的な利点: Front Door で証明書を管理およびローテーションすることで、サービスの可用性を確保します

詳細については、「Front Door のベストプラクティス」を参照してください

アウトバウンド接続用の NAT ゲートウェイを使用する

仮想ネットワークからの送信トラフィックに NAT ゲートウェイを使用して、送信元ネットワークアドレス変換 (SNAT) ポートの枯渇による接続エラーを回避します。 NAT ゲートウェイは動的にスケーリングされ、インターネットに向かうトラフィックに対してセキュリティで保護された接続を提供します。

潜在的な利点: NAT ゲートウェイにより送信接続エラーを防止します

詳細については、「送信接続での送信元ネットワークアドレス変換 (SNAT) を使用する」を参照してください

Availability Zones 間で Application Gateway をデプロイする

Application Gateway を複数の可用性ゾーンにデプロイすることで、ゾーンの冗長性を実現します。ゾーン冗長は、Application Gateway がさまざまな障害に耐え、1 つのゾーンが影響を受けた場合でも継続性を確保し、全体的な信頼性を高めることで、回復性を高めます。

潜在的な利点: Availability Zones を使用する場合に、Application Gateway の回復性が大幅に向上します。

詳細については、「Application Gateway v2 と WAF v2 のスケーリング」を参照してください

Application Gateway ユーザーの VNet アクセス許可を更新します

セキュリティを向上させ、Azure 全体でより一貫したエクスペリエンスを提供するために、すべてのユーザーは、仮想ネットワーク内にアプリケーションゲートウェイを作成または更新するためのアクセス許可チェックに合格する必要があります。ユーザーまたはサービスプリンシパルに最低限必要なアクセス許可は、Microsoft.Network/virtualNetworks/subnets/join/action です。

潜在的な利点: Application Gateway リソースの管理で中断が発生しないようにします

詳細については、「Application Gateway インフラストラクチャの構成」を参照してください

Front Door と配信元で同じドメイン名を使用する

ホストヘッダーを書き換えると、要求 Cookie と URL リダイレクトが中断する可能性があります。特に、Azure App Service などのプラットフォームを使用する場合、セッションアフィニティや認証や認可などの機能が正しく動作しない可能性があります。アプリケーションが正しく動作するかどうかを確認してください。

潜在的な利点: 元のホスト名を保持することにより、アプリケーションの整合性を確保します

詳細については、「Front Door のベストプラクティス」を参照してください

ExpressRoute 用にサイトの回復性を実装する

最大限の回復性を確保するために、Microsoft では、2 つのピアリング場所にある 2 つの ExpressRoute 回線に接続することをお勧めします。最大回復性の目標は、可用性を強化し、重要なワークロードの最高レベルの回復性を確保することです。

潜在的な利点: ExpressRoute における最大回復性は、Microsoft ネットワークパス内に単一障害点が存在しないことを保証するように設計されています。これは、ExpressRoute のサイト多様性のために、2 つの異なる場所にデュアル (2) 回線を提供することで実現されます。最大回復性の目標は、可用性を強化し、重要なワークロードの最高レベルの回復性を確保することです。

詳細については、「回復性に向けて Azure ExpressRoute を考案し設計する」を参照してください

ゾーン冗長 ExpressRoute ゲートウェイの実装

Azure Availability Zones でのゾーン冗長仮想ネットワークゲートウェイの実装。これにより、仮想ネットワークゲートウェイに回復性、スケーラビリティ、高可用性が提供されます。

潜在的な利点: ExpressRoute のゾーンの回復性と冗長性を提供します

詳細については、「可用性ゾーンにゾーン冗長仮想ネットワークゲートウェイを作成する」を参照してください

パフォーマンスと回復性を向上させるために自動スケールを使用する

Application Gateway を構成するときは、需要の変化に応じてスケールインおよびスケールアウトする自動スケーリングをプロビジョニングすることをお勧めします。これは、単一の障害コンポーネントの影響を最小限に抑えるのに役立ちます。

潜在的な利点: パフォーマンスと回復性を向上させます。

詳細については、「Application Gateway v2 と WAF v2 のスケーリング」を参照してください

ExpressRoute IP ルートが指定された制限に近づいています

ExpressRoute 回線が、IP ルートの制限に近づいています。これらの制限を超えると、接続が中断されます。ルートが制限内に戻ると、接続が再開します。提案: ルート数を定期的に監視します。 Virtual WAN RouteMap を調べて、アドバタイズされた IP ルートを減らします。

潜在的な利点: IP ルート数を監視することで、接続の問題を防ぎ、安定性が確保します。

詳細については、「Virtual WAN の FAQ」を参照してください

Front Door の背後に Traffic Manager を配置しない

ルーティングの問題を引き起こす可能性があるため、Traffic Manager を Front Door のオリジンの 1 つとして使用することはお勧めしません。高可用性アーキテクチャで両方のサービスが必要な場合は、常に Traffic Manager を Azure Front Door の前に配置します。

潜在的な利点: ワークロードの回復性を向上する

詳細については、「Front Door のベストプラクティス」を参照してください

少なくとも 2 つのオリジンを設定することを検討する

複数のオリジンは、アプリケーションの複数のインスタンスにトラフィックを分散して、冗長性をサポートします。 1 つのインスタンスが使用できない場合でも、他のバックエンドオリジンはトラフィックを受信できます。

潜在的な利点: ワークロードの回復性を向上する

詳細については、「Azure Front Door の Azure Well-Architected Framework のパースペクティブ」を参照してください。

VPN/Express Route 用に予約されているため、GatewaySubnet という名前の V1 ゲートウェイのサブネットを変更する

内部アップグレードが失敗したため、2024 年 10 月以降に Application Gateway が削除されるリスクがあります。これは、VPN/ExpressRoute 用に予約されている Gatewaysubnet という名前のサブネットが原因です。解決するには、サブネットを変更するか、V2 に移行してください。修正後にメッセージが消える日を許可する

潜在的な利点: Application Gateway V1 リソースの管理で中断が発生しないようにする

詳細については、「Application Gateway に関してよく寄せられる質問」を参照してください

現在のサブネットに NAT ゲートウェイが含まれるように V1 ゲートウェイのサブネットを変更する

内部アップグレードが失敗したため、2024 年 10 月以降に Application Gateway が削除される可能性があります。これは、専用サブネットがなく、NAT ゲートウェイが含まれているためです。解決するには、サブネットを変更するか、NAT ゲートウェイを削除するか、V2 に移行します。修正後にメッセージが消える日を許可する

潜在的な利点: Application Gateway V1 リソースの管理で中断が発生しないようにする

詳細については、「Application Gateway に関してよく寄せられる質問」を参照してください

サブスクリプションを再アクティブ化して V1 ゲートウェイの内部アップグレードのブロックを解除する

内部アップグレードが失敗したため、2024 年 10 月以降に Application Gateway が削除されるリスクがあります。これは、サブスクリプションが非アクティブ状態であるためです。これを修正するには、サブスクリプションをアクティブ化してください。問題が修正された後、このメッセージが消えるまで 1 日かかります。

潜在的な利点: Application Gateway V1 リソースの管理で中断が発生しないようにする

詳細については、「無効な Azure サブスクリプションを再度有効にする」を参照してください

Application Gateway for Containers

サポートされている AGC バージョンに移行します

Application Gateway for Containers のバージョンは、プレビューバージョンでプロビジョニングされており、運用環境ではサポートされていません。最新の API バージョンを使用して新しいゲートウェイをプロビジョニングしていることを確認します。

潜在的な利点: 運用ワークロードのサポート性と回復性を確保します

詳細については、「Application Gateway for Containers とは」を参照してください

Azure AI Search

標準の検索サービスを作成します (2GB)

ストレージクォータを超えると、インデックス作成の操作が停止します。 2 GB のストレージクォータを超えようとしています。ストレージがさらに必要な場合、標準の検索サービスを作成するか、パーティションを追加します。

潜在的な利点: より多くのデータを処理できます

詳細については、https://aka.ms/azs/search-limits-quotas-capacity を参照してください

Standard Search サービスの作成 (50MB)

ストレージクォータを超えると、インデックス作成操作の機能は停止します。 50 MB のストレージクォータを超えようとしています。操作を維持するには、Basic または Standard の検索サービスを作成します。

潜在的な利点: より多くのデータを処理できます

詳細については、https://aka.ms/azs/search-limits-quotas-capacity を参照してください

パーティションを追加して、使用可能なストレージクォータを超えないようにする

ストレージクォータを超過した場合、引き続きクエリを実行できますが、インデックス作成操作は機能しなくなります。使用可能なストレージクォータを超えようとしています。さらにストレージが必要な場合はパーティションを追加します。

潜在的な利点: 追加データのインデックスを作成できます

詳細については、https://aka.ms/azs/search-limits-quotas-capacity を参照してください

Azure Arc 対応 Kubernetes

Azure Arc 対応 Kubernetes の最新バージョンのエージェントにアップグレードする

Azure Arc 対応 Kubernetes の最適なエクスペリエンス、向上した安定性、新機能を得るには、エージェントを最新のバージョンにアップグレードしてください。

潜在的な利点: Arc 対応 K8s の最新のエージェントバージョン

詳細については、「Azure Arc 対応 Kubernetes エージェントをアップグレードする」を参照してください

Azure Arc 対応 Kubernetes 構成

Microsoft Flux 拡張機能を最新のメジャーバージョンにアップグレードする

Microsoft Flux 拡張機能にはメジャーバージョンのリリースがあります。継続的なサポートと新機能のために、すべての Azure Arc 対応 Kubernetes および Azure Kubernetes Service (AKS) クラスターについて、6 か月以内に Microsoft Flux の最新メジャーバージョンへ手動アップグレードすることを計画してください。

潜在的な利点: 継続的なサポートと新機能

詳細については、「Azure Arc 対応 Kubernetes クラスターで使用可能な拡張機能」を参照してください

Microsoft Flux 拡張機能の今後の互換性を破る変更

Microsoft Flux 拡張機能は、セキュリティと安定性に関する更新プログラムを頻繁に受け取ります。今後の更新プログラムは、OSS Flux プロジェクトに沿って、非推奨のフィールドを削除することで HelmRelease API と HelmChart API を変更します。ワークロードの中断を回避するには、必要なアクションが必要です。

潜在的な利点: 安定性とセキュリティの向上、および新機能

詳細については、「Azure Arc 対応 Kubernetes クラスターで使用可能な拡張機能」を参照してください

Microsoft Flux 拡張機能をサポートされているバージョンにアップグレードする

1 つ以上の Azure Arc 対応クラスターと Azure Kubernetes クラスター上の Microsoft Flux の現在のバージョンはサポートされていません。キュリティパッチ、バグ修正、および Microsoft サポートを取得するには、サポートされているバージョンにアップグレードします。

潜在的な利点: セキュリティパッチ、バグ修正、Microsoft サポートを取得できます

詳細については、「Azure Arc 対応 Kubernetes クラスターで使用可能な拡張機能」を参照してください

Azure Arc 対応サーバー

Azure Cache for Redis

断片化メモリ予約を増やす

断片化やメモリ負荷は可用性インシデントの原因となります。高いメモリ負荷で実行する際にキャッシュエラーを減らすには、[詳細設定] オプションで利用可能な maxfragmentationmemory 予約済み設定を使用して、断片化に備えてメモリの予約を増やします。

潜在的な利点: キャッシュにメモリの断片化が多い場合に可用性インシデントを開始します

詳細については、「Azure Cache for Redis の構成方法」を参照してください

アプリケーションの持続性を高めるために Cache for Redis インスタンスの geo レプリケーションを構成する

geo レプリケーションを使用すると、広範囲にわたるリージョン障害が万が一発生した場合でも、キャッシュデータのディザスターリカバリーが可能になります。これは、ミッションクリティカルなアプリケーションに必須な場合があります。 Premium Azure Cache for Redis インスタンスのパッシブ geo レプリケーションを構成することをおすすめします。

潜在的な利点: geo レプリケーションにより、キャッシュされたデータのディザスターリカバリーが可能になります。

詳細については、「Premium Azure Cache for Redis インスタンスのパッシブ geo レプリケーションを構成する」を参照してください

Azure Container Apps

Container Apps 環境を再作成して DNS の問題を回避

Container Apps 環境に潜在的なネットワークの問題があり、DNS の問題を引き起こす恐れがあります。新しい Container Apps 環境を作成し、新しい環境で Container Apps を再作成して古い Container Apps 環境を削除することをお勧めします。

潜在的な利点: Container Apps 環境で DNS エラーが発生しないようにします。

詳細については、「クイックスタート: Azure portal を使用して最初のコンテナーアプリをデプロイする」を参照してください

カスタムドメイン証明書を更新する

アップロードしたカスタムドメイン証明書の有効期限が間もなく切れます。サービスダウンタイムの恐れを回避するには、証明書を更新して Container Apps の新しい証明書をアップロードしてください。

潜在的な利点: 証明書の有効期限切れが原因でサービスが失敗することがなくなります。

詳細については、「Azure Container Apps のカスタムドメイン名と独自の証明書の持ち込み」を参照してください

マネージド証明書の更新を妨げている問題が検出されました。

コンテナーアプリで使用されているマネージド証明書が自動更新に失敗したことが検出されました。ドキュメントのリンクに従って、カスタムドメインの DNS 設定が正しいことを確認します。

潜在的な利点: 証明書の有効期限切れが原因のダウンタイムを回避できます。

詳細については、「Azure Container Apps のカスタムドメイン名と無料のマネージド証明書」を参照してください

コンテナ化されたアプリケーションの最小レプリカ数を増加

Azure Container Apps のコンテナ化されたアプリケーションに設定されたレプリカ数の最小値が低すぎると、回復性、スケーラビリティ、負荷分散の問題が発生する恐れがあります。可用性を高めるには、最小レプリカ数を増やすことを検討してください。

潜在的な利点: コンテナーアプリの可用性が向上します。

詳細については、「Azure Container Apps でスケーリングルールを設定する」を参照してください

Azure Cosmos DB

パーティションキーを使用して Azure Cosmos DB コンテナーを構成する

パーティション分割されていない Azure Cosmos DB コレクションがプロビジョニングされたストレージクォータに達すると、データを追加できなくなります。 Cosmos DB のパーティション分割されていないコレクションが、プロビジョニングされたストレージクォータに近づいています。サービスによって自動的にスケールアウトできるように、これらのコレクションをパーティションキーが定義された新しいコレクションに移行してください。

潜在的な利点: ストレージまたは要求頻度の増加に合わせてコンテナーをシームレスにスケーリングし、限界に到達しないようにします

詳細については、「Azure Cosmos DB でのパーティション分割と水平スケーリング」を参照してください

コード内で静的な Cosmos DB クライアントインスタンスを使用し、データベースとコレクションの名前をキャッシュします。

アカウントのメタデータ操作の数が多い場合、レート制限が発生する可能性があります。メタデータの操作には、システム予約済み要求ユニット (RU) の制限があります。コード内で静的 Cosmos DB クライアントインスタンスを使用し、データベースとコレクションの名前をキャッシュすることで、メタデータの操作によってレートが制限されないようにします。

潜在的な利点: RU の使用を最適化し、レート制限を回避します

詳細については、「Azure Cosmos DB と .NET SDK v2 のパフォーマンスに関するヒント」を参照してください

暗号化キーをホストしているリンクされた Azure Key Vault を確認します

Azure Cosmos DB アカウントが、暗号化キーをホストするリンクされた Azure Key Vault にアクセスできない場合、データアクセスとセキュリティの問題が発生する可能性があります。 Azure Key Vault 構成により、Cosmos DB アカウントがマネージド暗号化キーにアクセスするためにキーコンテナーに接続できなくなっています。キーローテーションを最近実行した場合は、以前のキーまたはキーのバージョンが引き続き有効であり、Cosmos DB でのローテーションが完了するまで使用可能であることを確認してください。以前のキーもしくはキーバージョンは、24 時間後、またはそのキーもしくはキーバージョンについて Azure Key Vault 監査ログに Azure Cosmos DB からのアクティビティが表示されなくなった後に無効にすることができます。

潜在的な利点: カスタマーマネージドキーを引き続き使用してデータにアクセスするように構成を更新します

詳細については、「Azure Key Vault で Azure Cosmos DB アカウントのカスタマーマネージドキーを構成する」を参照してください

Azure Cosmos DB コンテナーで整合インデックス作成モードを構成する

遅延インデックス作成モードで構成された Azure Cosmos コンテナーは非同期的に更新され、書き込みパフォーマンスが向上しますが、クエリの鮮度に影響を与える可能性があります。コンテナーは、Lazy インデックス作成モードで構成されています。クエリの鮮度が重要な場合は、インデックスの即時更新で整合インデックス作成モードを使用します。

潜在的な利点: クエリ結果の整合性と信頼性を向上させます

詳細については、「Azure Cosmos DB でインデックス作成ポリシーを管理する」を参照してください

修正プログラム - Async Java SDK v2 の 2.6.14 バージョンまたは Java SDK v4 にアップグレードする

バージョン 2.6.13 (以前) の Azure Cosmos DB Async Java SDK v2 には、グローバル論理シーケンス番号 (LSN) が最大整数値に達するとエラーが発生するという重大なバグがあります。このエラーは、Azure Cosmos DB コンテナーの有効期間中に大量のトランザクションが発生した後、サービスによってユーザーに対して透過的に発生します。注: これは Async Java SDK v2 の重要な修正プログラムですが、引き続き Java SDK v4 に移行することを強くお勧めします。

潜在的な利点: 対処しないと、作成、読み取り、更新、削除のすべての操作が、NumberFormatException で失敗し始める可能性があります

詳細については、「NoSQL 用 API 向けの Azure Cosmos DB Async Java SDK (レガシ) のリリースノートとリソース」を参照してください

重要な問題 - 現在推奨されているバージョンの Java SDK v4 にアップグレードする

バージョン 4.15 以前の Azure Cosmos DB Java SDK v4 には、グローバル論理シーケンス番号 (LSN) が最大整数値に達するとエラーが発生するという重大なバグがあります。これは、Azure Cosmos DB コンテナーの有効期間中に大量のトランザクションが発生した後、サービスによってユーザーに対して透過的に発生します。現在推奨されているバージョンの Java SDK v4 にアップグレードして、この問題を回避してください。

潜在的な利点: 対処しないと、作成、読み取り、更新、削除のすべての操作が、NumberFormatException で失敗し始める可能性があります

詳細については、「NoSQL 用 API 用の Azure Cosmos DB Java SDK v4: リリースノートとリソース」を参照してください

新しい 3.6 以降のエンドポイントを使用して、アップグレードされた MongoDB アカウント用 Azure Cosmos DB の API に接続する

お使いのアプリケーションの一部で、アップグレードされた MongoDB アカウント用 Azure Cosmos DB の API に接続するために、レガシ 3.2 エンドポイント <アカウント名>.documents.azure.com が使用されています。新しいエンドポイント <アカウント名>.mongo.cosmos.azure.com (または、ソブリン、政府機関向け、制限されたクラウドでそれに相当するもの) を使用してください。

潜在的な利点: MongoDB 用 Azure Cosmos DB の API のバージョン 3.6 以降の最新機能を利用できます

詳細については、「Azure Cosmos DB for MongoDB (4.0 サーバーバージョン): サポートされる機能と構文」を参照してください

Azure Cosmos DB の MongoDB 用 API アカウントを v4.2 にアップグレードして、クエリとストレージのコストを削減し、新機能を利用する

お使いの Azure Cosmos DB の MongoDB 用 API アカウントは、バージョン 4.2 にアップグレードできます。 v4.2 にアップグレードすると、新しいストレージ形式を利用することで、ストレージコストを最大 55%、クエリコストを最大 45% 削減できます。また、v4.2 には、マルチドキュメントトランザクションなど数多くの追加機能が含まれています。

潜在的な利点: 向上した信頼性、クエリとストレージの効率、パフォーマンス、および新しい機能

詳細については、「Azure Cosmos DB for MongoDB アカウントの API バージョンをアップグレードする」を参照してください

Azure Cosmos DB の MongoDB 用 API アカウントでサーバー側の再試行 (SSR) を有効にする

アカウントが 16500 エラーコードで TooManyRequests エラーをスローしている場合、サーバー側の再試行 (SSR) を有効にすると、問題の軽減に役立ちます。

潜在的な利点: 調整を防止し、クエリの信頼性とパフォーマンスを向上させます

Azure Cosmos DB の運用ワークロードに 2 番目のリージョンを追加する

Azure Cosmos DB の運用ワークロードが単一リージョンで実行されると、可用性の問題が発生する可能性があります。これは、Cosmos DB アカウントの一部が当てはまるようです。少なくとも 2 カ所の Azure リージョンが含まれるように構成することで、可用性が向上します。注: リージョンを追加すると、追加コストが発生します。

潜在的な利点: 運用ワークロードの可用性を向上させます

詳細については、「Azure Cosmos DB for NoSQL の高可用性 (信頼性)」を参照してください

古い Azure Cosmos DB SDK を最新バージョンにアップグレードします

古いバージョンの SDK を使用する Azure Cosmos DB アカウントには、最新の修正および改良が行われていません。 Azure Cosmos DB アカウントで、古いバージョンの SDK が使用されています。最新の修正、パフォーマンスの向上、新機能を入手するために、最新バージョンにアップグレードします。

潜在的な利点: 向上した信頼性とパフォーマンス、および新機能

詳細については、「Azure Cosmos DB のドキュメント」を参照してください

古い Azure Cosmos DB SDK を最新バージョンにアップグレードする

古いバージョンの SDK を使用する Azure Cosmos DB アカウントには、最新の修正および改良が行われていません。 Azure Cosmos DB アカウントで、古いバージョンの SDK が使用されています。最新の修正、パフォーマンスの向上、新機能を入手するため、最新バージョンにアップグレードすることをお勧めします。

潜在的な利点: 向上した信頼性とパフォーマンス、および新機能

詳細については、「Azure Cosmos DB のドキュメント」を参照してください

Cosmos DBアカウントのサービス管理フェールオーバを有効にする

Cosmos DBアカウントのサービス管理フェールオーバを有効にして、アカウントの高可用性を確保します。サービス管理フェールオーバは、プライマリリージョンが停止した場合に、書き込みリージョンをセカンダリリージョンに自動的に切り替えます。これにより、ダウンタイムなしでアプリケーションが機能し続けます。

潜在的な利点: Azure のサービスマネージドフェールオーバー機能は、フェールオーバープロセスの自動化、ダウンタイムの短縮、回復性の向上によって、システムの可用性を向上させます。

詳細については、「Azure Cosmos DB for NoSQL の高可用性 (信頼性)」を参照してください

運用ワークロードの HA を有効にする

一貫性のあるワークロードを持つ多くのクラスターでは、高可用性 (HA) が有効になっていません。予期しないノード障害が発生した場合のデータベースのダウンタイムを防ぎ、SLA 保証を受けるために、Azure Portal の [スケーリング] ページから HA をアクティブにすることをお勧めします。

潜在的な利点: HA をアクティブ化して、予期しないノード障害が発生した場合にデータベースのダウンタイムを回避します

詳細については、「Azure Cosmos DB for MongoDB 仮想コアクラスターのスケーリングと構成」を参照してください

複数地域のCosmos DBアカウントのゾーン冗長性を有効にする

この推奨事項では、複数地域のCosmos DBアカウントに対してゾーン冗長性を有効にして、高可用性を向上させ、地域的な障害発生時のデータ損失のリスクを軽減することを提案します。

潜在的な利点: 高可用性の向上とデータ損失リスクの軽減

詳細については、「Azure Cosmos DB for NoSQL の高可用性 (信頼性)」を参照してください

別のAzureリージョンに少なくとも1つのデータセンターを追加する

Azure Managed Instance for Apache Cassandraクラスタは実稼働クラスタとして指定されていますが、現在は単一のAzureリージョンに展開されています。実稼働クラスタの場合は、ディザスタリカバリシナリオを防ぐために、別のAzureリージョンに少なくとも1つのデータセンターを追加することをお勧めします。

潜在的な利点: ディザスターリカバリーに備えて、アプリケーションに別のリージョンを確保します

詳細については、「高可用性とディザスターリカバリーのベストプラクティス」を参照してください

コントロールプレーン操作のレート制限を回避する

リソースプロバイダーを通じて、お客様のアカウントで多数のコントロールプレーン操作が検出されました。記載されている制限を超える要求が、連続する 5 分間にわたって継続的なレベルで行われる場合、Azure Cosmos DB リソースに対する要求の調整が失敗または不完全な操作になる可能性があります。

潜在的な利点: コントロールプレーン操作を最適化し、レート制限による操作の失敗を回避します

詳細については、「Azure Cosmos DB サービスのクォータ」を参照してください

Azure Data Explorer

Virtual Network に関する問題を解決する

仮想ネットワーク (VNet) の問題が原因でサービスのインストールまたは再開に失敗しましたこの問題を修正するには、トラブルシューティングガイドの手順に従ってください。

潜在的な利点: 信頼性、可用性、パフォーマンス、新機能を強化します

詳細については、「仮想ネットワーク内の Azure Data Explorer クラスターのアクセス、インジェスト、操作に関するトラブルシューティング」を参照してください

"Microsoft.Kusto/clusters" のサブネット委任を追加する

サブネットが委任されていない場合、関連付けられている Azure サービスは、その中で動作できなくなります。サブネットに必要な委任がありません。 [Microsoft.Kusto/clusters] のサブネットを委任します。

潜在的な利点: 信頼性、可用性、パフォーマンス、新機能を強化します

詳細については、「サブネットの委任とは」を参照してください

Azure Database for MySQL

高可用性 - 現在主キーがないテーブルに主キーを追加する。

内部監視システムによって、高可用性スタンバイサーバーにおけるレプリケーションの大幅な遅延が確認されました。この遅延の主な原因は、主キーがないテーブルのリレーログがスタンバイサーバーで再生されていることです。この問題に対処してベストプラクティスに従うために、すべてのテーブルに主キーを追加することをお勧めします。これを完了させた後、高可用性を無効にしてから再度有効にすることで問題を軽減してください。

潜在的な利点: この方法を実施すると、テーブルに主キーがないことで発生する大規模なレプリケーション遅延の悪影響からスタンバイサーバーが保護されます。この方法にはフェールオーバー時間を短縮できる効果があり、最終的にはビジネス継続性を維持するという目標のサポートに役立ちます。

詳細については、「Azure Database for MySQL - フレキシブルサーバーのレプリケーション待機時間のトラブルシューティング」を参照してください

レプリケーション - 現在主キーがないテーブルに、主キーを追加する

レプリカサーバーが主キーがないテーブルでリレーログを再生しているため、レプリカサーバーでのレプリケーションの大幅な遅延が内部監視で確認されました。レプリカサーバーがプライマリサーバーと効果的に同期し、変更をすぐさま反映できるようにするには、プライマリサーバーのテーブルに主キーを追加し、レプリカサーバーを再作成します。

潜在的な利点: この方法を実施すると、レプリカサーバーがプライマリサーバーと緊密に同期した状態を実現できます。

詳細については、「Azure Database for MySQL - フレキシブルサーバーのレプリケーション待機時間のトラブルシューティング」を参照してください

Azure Database for PostgreSQL

非アクティブな論理レプリケーションスロットを削除する (重要)

非アクティブな論理レプリケーションスロットにより、先書きログ (WAL) ファイルが保持され、スナップショットファイルが蓄積されることで、サーバーのパフォーマンスが低下したり、使用できなくなったりする可能性があります。 Azure Database for PostgreSQL フレキシブルサーバーに非アクティブな論理レプリケーションスロットがある場合があります。これには即時の対応が必要です。非アクティブなレプリケーションスロットを削除するか、このスロットから変更の処理を開始することで、スロットのログシーケンス番号 (LSN) を進めてサーバーの現在の LSN に近づけます。

潜在的な利点: 非アクティブな論理レプリケーションスロットを削除することで、PostgreSQL の可用性を向上させます

詳細については、「Azure Database for PostgreSQL - フレキシブルサーバーでの論理レプリケーションと論理デコード」を参照してください

非アクティブな論理レプリケーションスロットを削除する

Orcas PostgreSQL フレキシブルサーバーに非アクティブな論理レプリケーションスロットがあると、先書きログ (WAL) ファイル保持とスナップショットファイルの蓄積により、サーバーのパフォーマンス低下したり、利用できなくなったりする恐れがあります。これには即時の対応が必要です。非アクティブなレプリケーションスロットを削除するか、このスロットから変更の処理を開始することで、スロットのログシーケンス番号 (LSN) を進めてサーバーの現在の LSN に近づけます。

潜在的な利点: 非アクティブな論理レプリケーションスロットを削除することで、PostgreSQL の可用性を向上させます

詳細については、「論理デコード」を参照してください

geo 冗長バックアップストレージを構成する

GRS を構成して、障害や災害が発生した場合でもデータベースが可用性と耐久性に関する目標を確実に達成するようにします。

潜在的な利点: リージョンの障害や災害から確実に回復できるようにします。

詳細については、「Azure Database for PostgreSQL (フレキシブルサーバー) でのバックアップと復元」を参照してください

低ピーク時間帯に行うカスタムメンテナンス期間を定義する

メンテナンススケジュールの設定を指定する場合、曜日と時間帯を選択できます。指定しない場合、システムでは、サーバーのリージョンの時刻で午後 11 時から午前 7 時までの時間が選択されます。使用量が少ない日時を選択します。

潜在的な利点: メンテナンス期間を構成すると、システムのピーク時のメンテナンスを回避できます。

詳細については、「Azure Database for PostgreSQL での予定メンテナンス - フレキシブルサーバー」を参照してください

Azure IoT Hub

Microsoft Edge デバイスランタイムを IoT Hub でサポートされているバージョンにアップグレード

Edge デバイスが古いバージョンを使用すると、パフォーマンスの低下が発生する恐れがあります。サポートされている最新バージョンの Azure IoT Edge ランタイムにアップグレードすることをお勧めします。

潜在的な利点: Edge デバイスでサポートされている最新のバージョンを使用してビジネス継続性を確保します

詳細については、「IoT Edge を更新する」を参照してください

デバイスクライアント SDK を IotHub のサポートされているバージョンにアップグレードする

デバイスが古い SDK を使用すると、パフォーマンスの低下が発生する恐れがあります。一部またはすべてのデバイスは古い SDK を使用しています。サポートされている SDK バージョンにアップグレードすることをお勧めします。

潜在的な利点: デバイスでサポートされている SDK を使用してビジネス継続性を確保します

詳細については、「Azure IoT Hub SDK」を参照してください

IoT Hub で潜在的なデバイスストームが検出された

これは、2 台以上のデバイスにより、IoT Hub への接続時に同じデバイス ID の資格情報が使用されている場合のことです。 2 台目のデバイス (B) が接続されると、1 台目のデバイス (A) は切断されます。次に、(A) により、再接続が試行されます。これにより、(B) が切断されます。

潜在的な利点: デバイスの接続性を向上させます

詳細については、「Azure IoT Hub エラーを理解して解決する」を参照してください

Device Update for IoT Hub SDK をサポートされているバージョンにアップグレードする

Device Update for IoT Hub インスタンスで以前のバージョンの SDK を使用すると、最新のアップグレードが取得されません。最新の修正、パフォーマンス向上、新機能を入手するには、最新の Device Update for IoT Hub SDK にアップグレードしてください。

潜在的な利点: サポートされている SDK を使用してビジネス継続性を確保します

詳細については、「Device Update for IoT Hub とは?」を参照してください

IoT ハブユニットを追加するか、SKU レベルを引き上げる

IoT ハブが 1 日のメッセージクォータを超えると、操作とコストの問題が発生する恐れがあります。今後円滑な運用を実現するには、ユニットを追加するか、SKU レベルを上げます。

潜在的な利点: IoT Hub が再びメッセージを受信できるようになります。

詳細については、「Azure IoT Hub エラーを理解して解決する」を参照してください

Azure Kubernetes Service (AKS)

システムノードプールの自動スケーリングを有効にする

負荷が高い時間帯でもシステムポッドがスケジュールされるようにするには、システムノードプールで自動スケーリングを有効にします。

潜在的な利点: システムノードプールのオートスケーラーを有効にすると、システムポッドがスケジュールされ、クラスターが機能できるようになります。

詳細については、「Azure Kubernetes Service (AKS) でのクラスターオートスケーラーを使用する」を参照してください

システムノードプールに少なくとも 2 つのノードがあります

システムポッドの信頼性を確保するために、システムノードプールに少なくとも 2 つのノードがあることを確認します。 1 つのノードを使用すると、ノードまたはハードウェア障害が発生した場合にクラスターが失敗する可能性があります。

潜在的な利点: ノードが 2 つがあることで、ノード障害に対する回復性が確保されます。

詳細については、「Azure Kubernetes Service (AKS) でシステムノードプールを管理する」を参照してください

専用システムノードプールを作成する

専用システムノードプールのないクラスターの信頼性は低下します。システムノードプールは、重要なシステムポッドのみを提供するために専用にすることをお勧めします。これにより、システムポッドと競合するユーザーポッド間のリソース不足を防ぐことができます。プール上で CriticalAddonsOnly=true:NoSchedule テイントを使用してこの動作を強制する。

潜在的な利点: コアシステムポッドのリソース不足を防ぐことで、クラスターの信頼性を確保します

詳細については、「Azure Kubernetes Service (AKS) でシステムノードプールを管理する」を参照してください

B シリーズの仮想マシン (VM) が運用環境で使用されていないことを確認する

クラスターに、非推奨のバースト可能な VM SKU を使用するノードプールが 1 つ以上ある場合、vCPU 機能が 100% 完全になることは保証されません。 B シリーズの VM が運用環境で使用されていないことを確認します。

潜在的な利点: 一貫したパフォーマンスを実現するためのベストプラクティス

詳細については、Bv1 シリーズのサイズに関するページを参照してください

Azure NetApp Files

Azure Netapp Files AD コネクタ用に AD DS サイトを構成する

Azure NetApp Files が割り当てられた AD DS サイトドメインコントローラーに到達できない場合、ドメインコントローラーの検出プロセスでは、すべてのドメインコントローラーに対してクエリが実行されます。到達できないドメインコントローラーを使用すると、ボリュームの作成、クライアントクエリ、認証、AD 接続の変更に関する問題が発生する可能性があります。

潜在的な利点: Azure Netapp Files により DNS 接続を最適化します

詳細については、「Active Directory Domain Services サイトの設計と Azure NetApp Files の計画に関するガイドラインを理解する」を参照してください

Microsoft.NetApp の委任されたサブネットに割り当てられたロールにサブネットの読み取りアクセス許可があることを確認する

Azure NetApp Files リソースの管理に必要なロールには、Microsoft.NetApp に委任されるサブネットに対する "Microsoft.network/virtualNetworks/subnets/read" アクセス許可が必要です。ロールがカスタムか組み込みかにかかわらず、このアクセス許可を持っていない場合、ボリュームの作成は失敗します

潜在的な利点: サブネット/読み取りアクセス許可を確実に持つようにすることで、ボリューム作成の失敗を防ぎます

Azure NetApp Files で使用されるタイムアウト値については、SAP 構成を確認してください

Azure NetApp Files で使用されている SAP の高可用性は、アプリケーションの中断を防ぐために適切なタイムアウト値を設定する必要があります。 [詳細] リンクを確認して、構成がドキュメントに記載されているタイムアウト値を満たしていることを確認します。

潜在的な利点: ANF 上の SAP アプリケーションの回復性を向上させます

詳細については、「Azure を使用して SAP ワークロードシナリオをホストして実行する」を参照してください

Azure NetApp Files リソースのディザスターリカバリー戦略を実装します

リージョンまたはゾーンの障害が発生中のデータや機能の損失を回避するには、リージョン間レプリケーションや Azure NetApp Files ボリュームのクロスゾーンレプリケーションなどの一般的なディザスターリカバリー手法を実装します。

潜在的な利点: Azure NetApp Files レプリケーション機能を使用してディザスターリカバリーを簡単に管理します

詳細については、「Azure NetApp Files のデータ保護とディザスターリカバリーのオプションについて」を参照してください

Azure NetApp Files - SMB ボリュームの継続的な可用性を有効にする

継続的可用性の場合は、Azure Netapp Files のサーバーメッセージブロック (SMB) ボリュームを有効にすることをお勧めします。

潜在的な利点: SMB ボリュームの継続的可用性を有効にして、アプリケーションの中断が発生しないようにします

詳細については、「既存の SMB ボリュームで継続的可用性を有効にする」を参照してください

Azure Site Recovery

Recovery Services コンテナーの論理的な削除を有効にする

論理的な削除は、削除後の一定期間に Recovery Services コンテナー内にバックアップデータを保持して、完全に削除される前に取得するチャンスを得られます。

潜在的な利点: 誤って削除された場合のバックアップデータの回復に役立ちます

詳細については、「Azure Backup の論理的な削除」を参照してください

Recovery Services コンテナーのリージョン間の復元を有効にする

リージョン間の復元 (CRR) を使用すると、Azure VM をセカンダリリージョン (Azure にペア設定されているリージョン) で復元できるようになり、ディザスターリカバリーに役立ちます。

潜在的な利点: 復元オプションの 1 つである、リージョンをまたがる復元 (CRR) を使用すると、セカンダリリージョン (Azure のペアになっているリージョン) で Azure VM を復元できます。

詳細については、「Azure portal で Azure VM データを復元する方法」を参照してください

Azure Spring Apps

Application Configuration Service を Gen 2 にアップグレードする

2024 年 4 月までにサポートが終了する Application Configuration Service Gen1 を引き続き使用していることがわかります。 Application Configuration Service Gen2 は、Gen1 と比較してパフォーマンスが向上し、Gen1 から Gen2 へのアップグレードはダウンタイムがないため、できるだけ早くアップグレードすることをお勧めします。

潜在的な利点: 安定性と可用性の向上

詳細については、「Application Configuration Service for Tanzu を使用する」を参照してください

Azure SQL データベース

SQL Database のリージョン間のディザスターリカバリーを有効にする

リージョン間の障害が発生した場合、ビジネス継続性のために Azure SQL データベースのリージョン間ディザスターリカバリーを有効にします。

潜在的な利点: ディザスターリカバリーを有効にすると、プライマリデータベースに対して、継続的に同期される読み取り可能セカンダリデータベースが作成されます。

詳細については、「Azure SQL Database によるビジネス継続性の概要」を参照してください

Azure SQL Database のゾーン冗長性を有効にして、高可用性と回復性を実現します。

高可用性と回復性を実現するには、SQL データベースまたはエラスティックプールのゾーン冗長性を有効にして可用性ゾーンを使用し、データベースまたはエラスティックプールのゾーン障害に対する回復性を確保します。

潜在的な利点: ゾーン冗長を有効にすると、Azure SQL Database はゾーンのハードウェアとソフトウェアの障害に対して回復性を持つようになり、回復がアプリケーションに対して透過的になります。

詳細については、「ゾーン冗長による高可用性 - Azure SQL Database」を参照してください

Azure Stack HCI

Arc により有効になった最新バージョンの AKS にアップグレードする

新機能と安定性の向上のため、Azure Arc により有効になっている AKS の最新バージョンの API/SDKにアップグレードします。

潜在的な利点: 新機能と向上した安定性を備えた、Azure Arc によって有効化された最新バージョンの AKS。

詳細については、https://azure.github.io/azure-sdk/releases/latest/index.html を参照してください

Arc により有効になった最新バージョンの AKS にアップグレードする

新機能と安定性の向上のため、Azure Arc により有効になっている AKS の最新バージョンの API/SDKにアップグレードします。

潜在的な利点: 新機能と向上した安定性を備えた、Azure Arc によって有効化された最新バージョンの AKS。

詳細については、https://azure.github.io/azure-sdk/releases/latest/index.html を参照してください

クラシックデプロイモデルのストレージ

アクションが必要: 2024 年 8 月 30 日までにクラシックストレージアカウントを移行します。

クラシックストレージアカウントを Azure Resource Manager に移行して、ビジネス継続性を確保します。 Azure Resource Manager では、すべての同じ機能に加えて、一貫した管理レイヤー、リソースのグループ化、新機能と更新プログラムへのアクセスが提供されます。

潜在的な利点: 従来のストレージアカウントを移行することで、データを確実に管理できるようにします

クラシックデプロイモデルの仮想マシン

2024 年 8 月 31 日より前に Cloud Services (クラシック) から移行する

Cloud Services (クラシック) は廃止されます。データやビジネス継続性が失われるのを避けるため、2024 年 8 月 31 日より前に移行してください。

潜在的な利点: サービスの継続性

詳細については、「Azure Cloud Services (クラシック) を Azure Cloud Services (延長サポート) に移行する」を参照してください

Cognitive Services

アプリケーションをアップグレードして Azure OpenAI から最新の API バージョンを使用する

古い API バージョンの Azure OpenAI リソースには、最新の機能がありません。最新の REST API バージョンを使用することをお勧めします。

潜在的な利点: 新しい API バージョンには、最新かつ最高の機能が含まれています。

詳細については、「Azure OpenAI Service REST API リファレンス」を参照してください

このリソースのクォータ超過、ブロック解除の待機またはアップグレード

リソースのクォータを超えると、リソースはブロックされます。まもなく自動的にクォータが補充されるのでそれまで待つこともできますが、リソースをすぐに再使用する場合は、有料 SKU にアップグレードしてください。

潜在的な利点: 有料 SKU にアップグレードすると、今すぐリソースを再使用できます。

詳細については、「Azure AI Studio のコストを計画および管理する」を参照してください

Container Registry

主要な運用ワークロードにプレミアムレベルを使用する

プレミアムレジストリは、含まれているストレージが最も大きく、同時実行操作数とネットワーク帯域幅も最大であり、大容量シナリオに対応できます。プレミアムレベルでは、geo レプリケーション、可用性ゾーンのサポート、コンテンツ信頼、カスタマーマネージドキー、プライベートエンドポイントなどの機能も追加されます。

潜在的な利点: Premium レベルでは、最高のパフォーマンス、スケール、回復性のオプションが提供されます

詳細については、「Azure Container Registry のサービスレベル」を参照してください

geo レプリケーションで回復性が有効になっていることを確認する

geo レプリケーションを使用することで、ワークロードはリージョン間で単一のイメージ、タグ、レジストリ名を使用でき、ネットワーク上の近い場所のレジストリへのアクセス、データ転送コストの削減、リージョンの障害が発生した場合のリージョンレジストリの回復性が提供されます。この機能は、プレミアムサービスレベルでのみ使用できます。

潜在的な利点: 回復性とプルパフォーマンスの向上、レジストリ管理の簡素化、データ転送コストの削減

詳細については、「Azure Container Registry の geo レプリケーション」を参照してください

Content Delivery Network

Edgio から Azure CDN、マネージド証明書の更新に失敗しました。追加の検証が必要です。

Edgio の Azure CDN では、CNAME 委任を使用して、マネージド証明書の更新のために DigiCert で証明書を更新します。 DigiCert による自動更新プロセスを成功させるには、カスタムドメインが azureedge.net エンドポイントに解決されることが不可欠です。カスタムドメインの CNAME および CAA レコードが正しく構成されていることを確認します。より詳しいアシストが必要な場合は、Azure にサポートケースを送信して更新のリクエストを再度試行します。

潜在的な利点: サービス可用性を確保します。

サービスの中断を回避するために、期限切れの Azure Front Door 顧客証明書を更新する

Azure Front Door Standard プロファイルと Premium プロファイルの顧客証明書の有効期限が切れると、サービスの中断が発生する可能性があります。サービスの中断を回避するために、証明書の有効期限が切れる前に証明書を更新してください。

潜在的な利点: サービス可用性を確保します。

詳細については、「Azure portal を使用して Azure Front Door カスタムドメインで HTTPS を構成する」を参照してください

Azure Front Door マネージド証明書を更新するためにドメインの所有権を再検証する

ドメインが AFD エンドポイントにマップされている CNAME ではないため、Azure Front Door (AFD) はマネージド証明書を自動的に更新できません。マネージド証明書が自動的に更新されるように、ドメインの所有権を再検証してください。

潜在的な利点: 未定義

詳細については、「Azure portal を使用して Azure Front Door でカスタムドメインを構成する」を参照してください

Azure Front Door 顧客証明書のシークレットバージョンを ‘最新’ に切り替える

Azure Front Door (AFD) の顧客証明書のシークレットを "最新" に構成すると、AFD が Azure Key Vault の最新のシークレットバージョンを参照できるようになり、シークレットを自動的にローテーションできるようになります。

潜在的な利点: "最新" バージョンを自動的にローテーションできます。

詳細については、「Azure portal を使用して Azure Front Door カスタムドメインで HTTPS を構成する」を参照してください

DNS TXT レコードを DNS プロバイダーに追加してドメインの所有権を検証する

DNS TXT レコードを DNS プロバイダーに追加してドメインの所有権を検証します。 TXT レコードを使用してドメインの所有権を検証すると、セキュリティが強化され、ドメインを適切に制御できます。

潜在的な利点: サービス可用性を確保します。

詳細については、「Azure portal を使用して Azure Front Door でカスタムドメインを構成する」を参照してください

2025 年 1 月 15 日までに Edgio の Azure CDN から移行する

Edgio プラットフォームのシャットダウンが予定されている 2025 年 1 月 15 日より前に、Edgio による Azure CDN Standard/Premium から移行します。互換性のために Azure Front Door に移行することをお勧めします。別の方法として、Azure Marketplace で入手できる Azure Traffic Manager または Akamai CDN の使用を検討してください。

潜在的な利点: ダウンタイムを防止してビジネスの継続性を確保します。

詳細については、Azure の更新に関するページを参照してください

Data Factory

Azure Data Factory でリージョン間冗長性のための BCDR 戦略を実装する

BCDR 戦略を実装すると、高可用性が向上し、データ損失のリスクが軽減される

潜在的な利点: 高可用性を向上させ、データ損失リスクを軽減します

詳細については、「Azure Data Factory と Azure Synapse Analytics のパイプラインでの BCDR - Azure アーキテクチャセンター」を参照してください

SHIR で自動アップグレードを有効にする

セルフホステッド統合ランタイムの自動アップグレードが無効になりました。セルフホステッド統合ランタイムの最新の変更とバグ修正が適用されていないことを確認してください。それらを確認して SHIR の自動アップグレードを有効にする

潜在的な利点: セルフホステッド統合ランタイムの最新の変更とバグ修正を取得します

詳細については、「セルフホステッド統合ランタイムの自動更新と期限切れ通知」を参照してください

Fluid Relay

Azure Fluid Relay クライアントライブラリをアップグレードする必要があります

Azure Fluid Relay サービスが古いクライアントライブラリで呼び出されると、アプリケーションの問題が発生する可能性があります。アプリケーションを引き続き動作させるには、お使いの Azure Fluid Relay クライアントライブラリを最新バージョンにアップグレードしてください。アップグレードすると、最新の機能が提供され、パフォーマンスと安定性が向上します。

潜在的な利点: 信頼性の向上

詳細については、「Fluid Framework リリースとのバージョンの互換性」を参照してください

HDInsight

HDInsight クラスターを削除して再作成することにより、緊急更新プログラムを適用 (証明書ローテーションラウンド 2)

HDInsight サービスは、実行中のクラスターにクリティカルな証明書の更新プログラムの適用を試行しました。ただし、一部のカスタム構成の変更により、すべてのクラスターに更新プログラムを適用できません。クラスターが異常な状態になって使用できなくなることを回避するには、クラスターを削除して再作成してください。

潜在的な利点: クラスターの正常性と安定性を確保します

詳細については、「HDInsight で Apache Hadoop、Apache Spark、Apache Kafka などを使用してクラスターを設定する」を参照してください

非 ESP ABFS クラスター [全ユーザーが読み取り可能なクラスターのアクセス許可]

非 ESP ABFS クラスターに、Hadoop 以外のグループユーザーがストレージ操作用に Hadoop コマンドを実行することを制限する変更を導入する予定です。この変更は、クラスターのセキュリティ体制を改善するためのものです。お客様は、2023 年 9 月 30 日より前に、更新を計画する必要があります。

潜在的な利点: この変更により、クラスターのセキュリティ態勢が改善されます

詳細については、「Azure HDInsight リリースノート」を参照してください

Kafka クラスターディスクでブローカーを再起動します

HDInsight クラスターで Kafka ブローカーが使用するデータディスクがほぼ満杯になると、Apache Kafka ブローカープロセスは開始できず、失敗します。軽減するには、すべてのトピックの保持時間を見つけて、古いファイルをバックアップしてブローカーを再起動してください。

潜在的な利点: Kafka ブローカーの問題を回避します

詳細については、「シナリオ: ブローカーが異常であるか、またはディスク領域不足の問題のために再起動できない」を参照してください

クラスター名の長さの更新

クラスターのセキュリティ態勢向上のために、クラスター名の最大長が 59 文字から 45 文字に変更されます。この変更は、2023 年 9 月 30 日までに実装されます。

潜在的な利点: HDInsight のセキュリティ態勢の改善

詳細については、「Azure HDInsight リリースノート」を参照してください

クラスターを最新の HDInsight イメージにアップグレード

1 年前に作成されたクラスターには、最新のイメージのアップグレードは適用されていません。お使いのクラスターは 1 年前に作成されました。ベストプラクティスの一環として、最新の HDInsight イメージを使用し、オープンソース更新プログラム、Azure 更新プログラム、セキュリティ修正プログラムを最良の状態で活用することをお勧めします。クラスターのアップグレードに推奨される最大期間は、6 か月未満です。

潜在的な利点: 最新の修正プログラムと機能を入手します

詳細については、「クラスターの作成を開始する前に、次の点を考慮してください」を参照してください。

HDInsight クラスターをアップグレードする

最新のイメージを使用していないクラスターには、最新のアップグレードは適用されていません。お使いのクラスターでは最新のイメージが使用されていません。最新バージョンの HDInsight イメージを使用し、オープンソース更新プログラム、Azure 更新プログラム、セキュリティ修正プログラムを最大限に活用することをお勧めします。 HDInsight のリリースは 30 〜 60 日ごとに行われます。

潜在的な利点: 最新の修正プログラムと機能を入手します

詳細については、「Azure HDInsight リリースノート」を参照してください

ゲートウェイまたは仮想マシンに到達できない

ネットワーク障害が検出されました。これは、到達不可なゲートウェイまたは仮想マシンを示しています。すべてのクラスターホストの可用性を確認します。仮想マシンを再起動して復旧します。さらにサポートが必要な場合は、Azure サポートにお気軽にお問い合わせください。

潜在的な利点: 可用性の向上

VM エージェントは 9.9.9.9 です。クラスターをアップグレードする。

このレコードは、クラスターの 1 つ以上が 2022 年 2 月以前のイメージ (イメージバージョン 2202xxxxxx 以前) を使用していることを示しています。 2022 年 2 月以前の日付のイメージを使用する HDInsight クラスターには、潜在的な信頼性の問題があります。最新のイメージを使用してクラスターをリビルドすることを検討してください。

潜在的な利点: スケーリングとネットワーク接続の信頼性を向上させます

Media Services

メディアサービスのクォータまたは制限を増やす

メディアアカウントがクォータ制限に達すると、サービスの中断が発生する恐れがあります。サービスの中断を回避するには、資産、コンテンツキーポリシー、ストリームポリシーの現在の使用状況を確認し、制限に近いエンティティのクォータ制限を増やしてください。チケットを開いて関連する詳細を追加することにより、クォータ制限の引き上げを要求できます。ポイント: 上限を引き上げる試みとして、追加の Azure Media アカウントを作成しないでください。

潜在的な利点: 顧客がクォータ制限を超過したことによるサービスの中断を回避します。

詳細については、「Azure Media Services のクォータと制限」を参照してください

Service Bus

Service Bus Premium レベルを使用して回復性を向上させる

重要なアプリケーションを実行する場合、Service Bus Premium レベルでは、CPU レベルとメモリレベルでのリソース分離が向上し、可用性が向上します。また、geo ディザスターリカバリー機能もサポートされているため、アプリケーション構成を変更しなくても、地域の災害からの復旧が容易になります。

潜在的な利点: Service Bus Premium レベルでは、CPU とメモリリソースの分離および geo ディザスターリカバリーにより、より優れた回復性が提供されます

詳細については、「Service Bus Premium メッセージング層」を参照してください

Premium レベルの Service Bus 自動スケーリング機能を使用して回復性を向上させる

重要なアプリケーションを実行する場合、オートスケール機能を有効にすることで、アプリケーションの負荷を処理するのに十分な容量が得ることができます。適切な量のリソースを実行すると、調整が減り、ユーザーエクスペリエンスが向上します。

潜在的な利点: 自動スケーリングを有効にすると、ユーザーは容量の制約を受けなくなります

詳細については、「Azure Service Bus 名前空間のメッセージングユニットを自動的に更新する」を参照してください

Azure Virtual Machines における SQL Server

仮想マシンで SQL の Azure Backup を有効にする

SQL AG 統合によるゼロインフラストラクチャバックアップ、ポイントインタイムリストア、一元管理の利点を実現するため、Azure Backup を使用して仮想マシン上の SQL データベースのバックアップを有効にします。

潜在的な利点: バックアップ用インフラストラクチャが不要で、一元管理、AG 統合、ポイントインタイムリストアを実現する SQL 対応バックアップ

詳細については、「Azure VM での SQL Server Backup について」を参照してください

Storage

容量の上限に近づいているストレージアカウントでのマネージドディスクの使用

ストレージアカウント内の Premium SSD アンマネージドディスクが Premium Storage の容量制限に達しそうになると、エラーが発生する可能性があります。この制限に達したときに発生するエラーを回避するために、アカウントの容量制限のないマネージドディスクに移行してください。この移行はポータルを使用して 5 分以内に完了できます。

潜在的な利点: アカウントが容量制限に達した場合のスケーリングの問題を回避します

詳細については、「Standard Storage アカウントのスケーラビリティとパフォーマンスのターゲット」を参照してください

BLOB バックアップの作成

Azure BLOB バックアップにより、偶発的または悪意のある削除からデータを保護できます。 BLOB バックアップを構成することをお勧めします。

潜在的な利点: 偶発的または悪意のある削除からデータを保護します

詳細については、「Azure Blob バックアップの概要」を参照してください

サブスクリプション

Azure Backup を有効にして、データのシンプルで信頼性が高く、コスト効率の高い保護を実現する

Azure の堅牢な、ワンクリックのバックアップを使用して、情報とアプリケーションを安全に維持します。 Azure Backup をアクティブ化して、VM、SQL データベース、アプリケーション、ファイル共有などの、広範なワークロードに対してコスト効率の高い保護を実現します。

潜在的な利点: ビジネスクリティカルなアプリケーションを確実に保護し続けます

詳細については、Azure Backup のドキュメント - Azure Backup に関する記事を参照してください

Azure サービス正常性アラートの作成

Azure Service Health アラートは、4 つの領域 (サービスに関する問題、計画メンテナンス、セキュリティアドバイザリ、正常性の勧告) の問題と勧告に関する情報を常に通知します。これらのアラートは、選択した Azure リージョンおよびサービスに対する中断や潜在的な影響について通知するようにパーソナライズされています。

潜在的な利点: 4 つの領域 (サービスの問題、計画メンテナンス、セキュリティアドバイザリ、正常性アドバイザリ) にわたる問題とアドバイザリに関する情報を常に把握できます

詳細については、「Azure portal を使用してサービスの通知でアクティビティログアラートを作成する」を参照してください

Virtual Machines

Managed Disks を使用してデータの信頼性を改善する

ストレージアカウントまたはストレージスケールユニットを共有するディスクを使用する可用性セット内の仮想マシンは、停止時のストレージスケールユニットの単一障害に対する回復性がありません。 Azure Managed Disks に移行すると、可用性セット内の異なる VM のディスクが十分に分離され、単一障害点が回避されます。

潜在的な利点: データの回復性によってビジネス継続性を確保します

詳細については、https://aka.ms/aa_avset_manageddisk_learnmore を参照してください

仮想マシンのレプリケーションを有効にして、リージョンの障害からアプリケーションを保護する

仮想マシンは、別のリージョンへのレプリケーションが有効になっている場合、リージョンの停止に対する回復性があります。 Azure リージョンの停止時のビジネスへの悪影響を軽減するために、ビジネスクリティカルなすべての仮想マシンのレプリケーションを有効にすることをお勧めします。

潜在的な利点: Azure リージョンで障害が発生した場合にビジネス継続性を確保します

詳細については、「クイックスタート: Azure VM のセカンダリ Azure リージョンへのディザスターリカバリーの設定」を参照してください

送信接続プロトコルを Azure Site Recovery 用のサービスタグに更新する

IP アドレスベースの許可リストは、ファイアウォールの送信接続を制御する方法としては脆弱であり、サービスタグはその代替手段として適しています。サービスタグを使用し、マシンに対して Azure Site Recovery サービスへの接続を許可することを、強くお勧めします。

潜在的な利点: ハードコーディングされた IP アドレスより優れたセキュリティ、安定性、回復性が保証されます

詳細については、「Azure VM ディザスターリカバリーのネットワークについて」を参照してください

Premium 対応 VM に接続されている Standard ディスクを Premium ディスクにアップグレードする

Premium VM で Standard SSD ディスクを使用すると、パフォーマンスが最適化されなくなり、待機時間の問題が発生する可能性があります。 Standard ディスクから Premium ディスクへのアップグレードを検討することをお勧めします。すべてのオペレーティングシステムディスクとデータディスクに Premium Storage を使用している単一インスタンスの仮想マシンでは、99.9% 以上の仮想マシン接続が保証されます。アップグレードする場合、考慮すべき要因が 2 つあります。 1 つ目の要因は、アップグレードには VM の再起動が必要であり、再起動が完了するまでに 3 から 5 分かかるということです。 2 つ目として、リストにある VM がミッションクリティカルな運用 VM である場合には、向上する可用性と、Premium ディスクのコストを比較してください。

潜在的な利点: すべてのディスクが Premium の場合にのみ利用可能な単一 VM の SLA により可用性が向上します

詳細については、「Azure マネージドディスクの種類」を参照してください

追加コストなしで VM を Premium Unmanaged Disks から Premium Managed Disks にアップグレードする

Azure Managed Disks では、高い回復性、簡素化されたサービス管理、より高いスケーリング目標、および複数のディスクの種類での多くの選択肢が提供されます。 VM は Premium Unmanaged Disks を使用しています。このディスクは、追加コストなしで、ポータルを通じて 5 分以内に Managed Disks に移行できます。

潜在的な利点: Managed Disks の高い回復性やその他の利点を活用できます

詳細については、「Azure マネージドディスクの概要」を参照してください

非推奨の仮想マシンイメージを新しいイメージにアップグレードする

サブスクリプション内の仮想マシン (VM) が、非推奨になる予定のイメージで実行されています。イメージが非推奨になると、非推奨のイメージから新しい VM を作成することはできません。ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。 (VMRunningDeprecatedImage)

潜在的な利点: VM ワークロードに対する潜在的な中断を最小限に抑えます

詳細については、「非推奨の Azure Marketplace イメージ - Azure Virtual Machines」を参照してください

仮想マシンイメージを新しいオファーにアップグレードする

潜在的な利点: VM ワークロードに対する潜在的な中断を最小限に抑えます

詳細については、「非推奨の Azure Marketplace イメージ - Azure Virtual Machines」を参照してください

仮想マシンイメージを新しい SKU にアップグレードする

サブスクリプション内の仮想マシン (VM) が、非推奨になる予定のイメージで実行されています。イメージが非推奨になると、非推奨のイメージから新しい VM を作成することはできません。ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。

潜在的な利点: VM ワークロードに対する潜在的な中断を最小限に抑えます

詳細については、「非推奨の Azure Marketplace イメージ - Azure Virtual Machines」を参照してください

仮想マシンスケールセットを代替イメージバージョンにアップグレードする

サブスクリプション内の VMSS が、非推奨になる予定のイメージで実行されています。イメージが非推奨になると、仮想マシンスケールセットのワークロードはスケールアウトされなくなります。ワークロードの中断を防ぐために、新しいバージョンのイメージにアップグレードしてください。

潜在的な利点: 仮想マシンスケールセットワークロードに対する潜在的な中断を最小限に抑えます

詳細については、「非推奨の Azure Marketplace イメージ - Azure Virtual Machines」を参照してください

仮想マシンスケールセットを代替イメージオファーにアップグレードする

サブスクリプション内の VMSS が、非推奨になる予定のイメージで実行されています。イメージが非推奨になると、仮想マシンスケールセットのワークロードはスケールアウトされなくなります。ワークロードの中断を防ぐには、新しいオファーのイメージにアップグレードしてください。

潜在的な利点: 仮想マシンスケールセットワークロードに対する潜在的な中断を最小限に抑えます

詳細については、「非推奨の Azure Marketplace イメージ - Azure Virtual Machines」を参照してください

仮想マシンスケールセットを代替イメージ SKU にアップグレードする

サブスクリプション内の VMSS が、非推奨になる予定のイメージで実行されています。イメージが非推奨になると、仮想マシンスケールセットのワークロードはスケールアウトされなくなります。ワークロードの中断を防ぐには、新しい SKU のイメージにアップグレードしてください。

潜在的な利点: 仮想マシンスケールセットワークロードに対する潜在的な中断を最小限に抑えます

詳細については、「非推奨の Azure Marketplace イメージ - Azure Virtual Machines」を参照してください

Azure Virtual Desktop 環境に必要な URL へのアクセスを提供する

セッションホストが Windows Virtual Desktop (WVD) に適切にデプロイおよび登録されるようにするには、VM が制限された環境で実行される場合に備えて、'許可リスト' に URL のセットが必要です。許可リストに含まれていない特定の URL については、アプリケーションのイベントログでイベント 3702 を検索してください。

潜在的な利点: Windows Virtual Desktop サービスを使用しているときに、デプロイとセッションホストの機能が正常に動作するようにします

詳細については、「Azure Virtual Desktop に必要な FQDN とエンドポイント」を参照してください

リソースとリソースグループの場所を合せる

リージョン停止の影響を出来るかぎり軽減するため、リソースグループと同じリージョンにリソースを配置してください。これにより、Azure Resource Manager は、グループ内のすべてのリソースに関連するメタデータを 1 つのリージョンに格納します。同じリージョンに配置することで、リージョンが利用不可になった場合に影響を受けるリスクを減らすことができます。

潜在的な利点: リージョンの停止による書き込みエラーを減らします

詳細については、「Azure Resource Manager とは」を参照してください

Availability Zones を使用して回復性と可用性を向上させる

Azure の Availability Zones (AZ) は、アプリケーションとデータをデータセンターの障害から保護するのに役立ちます。それぞれの AZ は、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。ゾーン VM を使用するソリューションを設計することで、他のゾーンで障害から VM を分離できます。

潜在的な利点: ゾーン VM を使用すると、他のゾーンにおけるゾーンの停止からアプリが保護されます。

細については、「Azure の単一インスタンス VM をリージョンからゾーンのターゲット可用性ゾーンに移動する」を参照してください

Azure Virtual Machine Scale Set (VMSS) アプリケーションの正常性監視を有効にする

Application Health 拡張機能またはロードバランサーの正常性プローブを使用して仮想マシンスケールセットのアプリケーション稼働状況の監視を構成すると、Azure プラットフォームでアプリケーション正常性の変化に応じてアプリケーションの回復性を向上させることができます。

潜在的な利点: アプリケーションの正常性を Azure に公開することで回復性を高めます

詳細については、「Virtual Machine Scale Sets でアプリケーションの正常性拡張機能を使用する」を参照してください

Virtual Machines でバックアップを有効にする

ご利用の仮想マシンに対するバックアップを有効にし、データをセキュリティで保護します。

潜在的な利点: Virtual Machines の保護

詳細については、「Azure Backup サービスとは」を参照してください

Azure 仮想マシンスケールセット (VMSS) で自動修復ポリシーを有効にする

インスタンスの自動修復を有効にすると、正常なインスタンスのセットを維持することで、高可用性を実現できます。 Application Health の拡張機能または Load Balancer 正常性プローブによって異常なインスタンスが見つかった場合、インスタンスの自動修復は修復アクションをトリガーしてインスタンスの復旧を試行します。

潜在的な利点: 障害が発生したインスタンスの修復を自動化することで回復性を高めます

詳細については、「Azure Virtual Machine Scale Sets の自動インスタンス修復」を参照してください

メトリックに基づいて仮想マシンスケールセットの自動スケーリングを構成する

メトリックに基づいたカスタム自動スケーリングにより、リソース使用率を最適化し、コストを削減し、アプリケーションパフォーマンスを向上させます。 CPU、メモリ、ディスク操作などのリアルタイムメトリックに基づいて、仮想マシンインスタンスを自動的に追加します。コスト効率を維持しながら高可用性を確保します。

潜在的な利点: コスト効率を維持しながら高可用性を確保します

詳細については、「Azure Virtual Machine Scale Sets を使用した自動スケーリングの概要」を参照してください

ゾーン冗長ストレージ (ZRS) を有効にした Azure ディスクを使用して回復性と可用性を高める

ZRS を有効にした Azure ディスクでは、リージョン内の 3 つの可用性ゾーン間でデータの同期レプリケーションが行われ、アプリケーションを中断することなく、ゾーンの障害に対する耐性をディスクに提供します。回復性と可用性を高めるために、LRS から ZRS にディスクを移行してください。

潜在的な利点: ZRS ディスクを使用するようにアプリケーションを設計することで、データが 3 つの Availability Zones にレプリケートされ、ゾーンの停止に対するディスクの回復性が向上します

詳細については、「LRS から ZRS にディスクを変換する」を参照してください

DNS サーバーは Virtual Network レベルで構成する必要がある

仮想ネットワークレベルで VM の DNS サーバーを設定して、環境全体で一貫性を確保します。プライマリネットワークインターフェイスの構成では、DNS サーバーの設定は仮想ネットワークから継承するように設定する必要があります。

潜在的な利点: 一貫性と信頼性の高い名前解決を保証します

詳細については、「Azure 仮想ネットワーク内のリソースの名前解決」を参照してください。

Virtual Machine Scale Sets Flex への移行

ゾーン間または同じゾーン内の異なる障害ドメイン間でのデプロイ用に、仮想マシン (VM) から Virtual Machine Scale Sets Flex にワークロードを移行します。プラットフォームでは、可用性セットが非推奨になる予定です。

潜在的な利点: ゾーン間または異なる障害ドメイン間での可用性

詳細については、「フレキシブルオーケストレーションでデプロイとリソースを Virtual Machine Scale Sets に移行する」を参照してください。

ワークロード

多目的 SQL サーバーの Always On 可用性グループを構成します

Always On 可用性グループを持つ MPSQL サーバーの可用性が向上します。 MPSQL サーバーは、Epic システムの共有インフラストラクチャ内で Always On 可用性グループの一部として構成されていません。 Always On 可用性グループでは、データベースの可用性とリソースの使用が向上します。

潜在的な利点: データベースの可用性とリソースの使用が向上します

詳細については、「Always On 可用性グループとは」を参照してください

Citrix VDI サーバーでローカルホストキャッシュを構成して、シームレスな接続ブローカー操作を保証する

Citrix VDI サーバーにローカルホストキャッシュが構成されていないことが確認されました。ローカルホストキャッシュ (LHC) は、障害が発生したときに接続ブローカー操作を続行できる Citrix Virtual Apps とデスクトップの機能です。LHC は、サイトデータベースに 90 秒間アクセスできない場合に関与します。

潜在的な利点: シームレスな接続ブローカー操作

3 つのゾーン用に構成された仮想マシンスケールセット Flex の一部としてハイパースペース Web サーバーをデプロイする

仮想マシンスケールセット Flex 設定のハイパースペース Web サーバーが、選択したリージョン内の 3 つのゾーンに分散されていないことが確認されました。高可用性と大規模なスケールを必要とする Epic システムのハイパースペース Web のようなサービスの場合、サーバーを仮想マシンスケールセット Flex の一部としてデプロイし、3 つのゾーンに分散することをお勧めします。 Azure ではフレキシブルオーケストレーションを使用することで、Azure VM エコシステム全体で統合されたエクスペリエンスを実現できます。

潜在的な利点: Epic DB の Hyperspace Web サーバーの高可用性とオンデマンドの大規模化

詳細については、「可用性ゾーンを使用する仮想マシンスケールセットを作成する」を参照してください

SAP ワークロードの ASCS HA セットアップで Azure Load Balancer のアイドルタイムアウトを 30 分に設定する

ロードバランサーのタイムアウトを防ぐには、すべての Azure 負荷分散規則の "アイドルタイムアウト (分)" が最大値の 30 分に設定されていることを確認します。ロードバランサーを開き、[負荷分散規則] を選択し、規則を追加または編集して設定を有効にします。