1. Managed Cloudコンテナ

Managed Cloud Containersでの高可用性

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

高可用性 (HA) は、システムまたはシステムコンポーネントが望ましいほど長い時間、継続的に動作し続ける能力として定義されます。Managed Cloudでは、冗長性を導入することでこれを実現し、インフラストラクチャの高可用性はAzureプロバイダーによって保証されます。Managed Cloud Containers構成では、インフラストラクチャ コンポーネントの可用性を99.99% と目標としています。高可用性は同じ場所内でのみ提供され、リージョン全体に障害が発生するシナリオはカバーされません。リージョン全体の障害は、ディザスター リカバリー シナリオで対処する必要があります。

高可用性は、サービス ベンダーの組み込み機能のサポートによって実装されます。

Azure Kubernetes Service (AKS) アップタイムSLA

AKSは無料であるため、既定の構成ではSLAを提供しませんが、Microsoftは99.5% uptime with the default configurationを提供するよう努めています。

アップタイムSLAは99.95% Availability Zonesを使用するクラスターのKubernetes APIサーバーエンドポイントの可用性と、Availability Zonesを使用しないクラスターの99.9% の可用性を保証します。AKSは、更新ドメインと障害ドメイン間でマスター ノード レプリカを使用して、SLA要件が満たされていることを確認します。

アップタイムSLAを使用したAzure Kubernetesサービス (AKS) の詳細については 、こちら をお読みください。

AKSワークロードの可用性ゾーン

Managed Cloudデプロイ モデルでは、アベイラビリティ ゾーンを使用する場合、特定のアベイラビリティ ゾーン内のノードが、別のアベイラビリティ ゾーンで定義されたノードから物理的に分離されます。クラスター全体に複数の可用性ゾーンが構成されてデプロイされたAKSクラスターは、ハードウェア障害や計画メンテナンス イベントから保護するためのより高いレベルの可用性を提供します。

詳細については、「 Azure Kubernetes Service (AKS) - Azure Kubernetes Serviceで可用性ゾーンを使用する」を参照してください。

既知の制限事項:

  • 可用性ゾーンは、クラスターまたはノード プールの作成時にのみ定義できます。

  • 可用性ゾーンの設定は、クラスターの作成後に更新することはできません。また、既存の非可用性ゾーン クラスターを更新して可用性ゾーンを使用することもできません。

  • 選択したノード サイズ (VM SKU) は、選択したすべての可用性ゾーンで使用できる必要があります。

  • 可用性ゾーンが有効になっているクラスターでは、ゾーン間での分散にAzure Standard Load Balancerを使用する必要があります。このロード バランサーの種類は、クラスターの作成時にのみ定義できます。Standard Load Balancerの詳細と制限事項については、「 Azure Load Balancer Standard SKUの制限事項」を参照してください。

  • データ転送には追加料金を適用できます – 価格を見る – 帯域幅 |Microsoft Azure   

「Availability Zones(EgressとIngress)間のデータ転送は有料です」も参照してください。

SQLエラスティック プール

Azure SQL Databaseは、リージョンの高可用性が組み込まれたフル マネージド リレーショナル データベースです。

Azure SQL Managed Instanceは、99.99% 以上の可用性が保証されています。これは、Business CriticalレベルとGeneral Purposeレベルの両方に適用されます。次の3つのサービス階層があります。

  1. General Purpose/Standard - 一般的なワークロード用。

  2. Business Critical/Premium - 低遅延と高耐障害性を必要とする高スループットOLTPアプリケーション向け。

  3. ハイパースケール - 非常に大規模なOLTPシステムの場合、ストレージとコンピューティングの自動スケーリングを実行します。

    • ゾーン冗長デプロイメントとして構成されたDatabase Business CriticalまたはPremium Azure SQLレベルは、99.995% 以上の可用性が保証されています。

    • Azure SQL Database Business CriticalまたはPremiumレベルでは、ゾーン冗長デプロイ用に構成されていない場合、99.99% 以上の可用性が保証されます。

    • Azure SQL Database General Purpose、Standard、Basic、または2つ以上のレプリカを持つハイパースケール レベルでは、少なくとも99.99% の可用性が保証されています。

    • Azure SQLつのレプリカを持つDatabase Hyperscaleレベルでは、少なくとも99.95% の可用性が保証され、レプリカが0の場合は99.9% になります。

    • geoレプリケーションで構成されたDatabase Business CriticalレベルAzure SQL、デプロイされた時間の100% に対して5秒の目標復旧時点 (RPO) が保証されます。

    • geoレプリケーションで構成されたDatabase Business CriticalレベルAzure SQL、デプロイされた時間の100% に対して30秒の目標復旧時間 (RTO) が保証されています。

Searchスタックス

高可用性が組み込まれています。稼働時間は、99.5 (ゴールド) から99.95 (プラチナプラス) までの対応するレベルによって異なります。

Managed Solrの価格と機能の詳細については、こちらをご覧ください。

フロントドア

Azureは、99.99% 以上の時間において、Azure Front Door Serviceがクライアント要求に応答し、要求されたコンテンツをエラーなく配信することを保証します。

Azure Container Registry(ACR)

マイクロソフトは、99.9% 以上の時間において、Managed Registryがレジストリ トランザクションを正常に処理することを保証します。クラシック レジストリのSLAは、Azure Storageを通じて提供されます。

パブリックイメージを使用している場合は、SLOに合わせてコンテナレジストリにインポートすることを検討してください。そうしないと、イメージが予期しない可用性の問題を抱える可能性があります。これらの問題は、必要なときにイメージが利用できない場合、運用上の問題を引き起こす可能性があります。

AzureからのContainer RegistryのSLAを参照してください。

決定

高可用性の決定は、運用構成に適用されます。

テーブル 1.高可用性ソリューションと潜在的な目標SLA

資源

解決

潜在的なターゲットSLA

コメント

AKSの

本番環境のデプロイでデフォルトで稼働時間SLA機能を有効にする

99.95% (ワークロードの有効なアベイラビリティーゾーンとの組み合わせ)

サポートされている場所の一覧を確認します。

Windowsノード プール

  • 2つの可用性ゾーンを構成する

  • 2番目のノード プールを削除する - 1つのノード プールを使用します

  • スケール セットは、少なくとも2つのノードで構成する必要があります

99.99% (アベイラビリティーゾーンが設定されている場合)

可用性ゾーンがサポートされている、パブリックでサポートされている場所の一覧を確認します。

Linuxノード プール

  • 2つの可用性ゾーンを構成する

  • スケール セットは、少なくとも2つのノードで構成する必要があります

99.99% (アベイラビリティーゾーンが設定されている場合)

可用性ゾーンがサポートされている、パブリックでサポートされている場所の一覧を確認します。

SQLエラスティック プール

General Purposeレベル

99.99%

Searchスタックス

プラチナティア

99.9%

フロントドア

デフォルトで提供される高可用性

99.99%

ACRの

99.9%

プロビジョニング中にすべての (Sitecore + サードパーティ) イメージをローカルにプルする

ストレージ アカウント

LRSレプリケーション

99.999999999999%(11ナイン)

Kubernetesワークロード

水平方向にスケーリングできるロールは、少なくとも2つのポッドで構成する必要があります



この記事を改善するための提案がある場合は、 お知らせください!