---
title: "Managed Cloudコンテナにおける高可用性"
slug: "high-availability-in-managed-cloud-containers"
abstract: "Managed Cloudコンテナの各コンポーネントのSLAおよび可用性を説明します。"
---
# Managed Cloudコンテナにおける高可用性

高可用性(HA)とは、システムまたはシステムコンポーネントが望ましい長期間連続稼働できる能力と定義されます。Managed Cloudでは冗長性を導入することで実現され、インフラの高可用性はAzureプロバイダーによって保証されます。Managed Cloudコンテナ構成では、インフラコンポーネントの可用性を99.99%と目標としています。高可用性は同じ場所でのみ提供され、リージョン全体が障害を起こすシナリオはカバーしません。リージョン全体の障害は災害復旧シナリオで対処しなければなりません。

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

## Azure Kubernetesサービス(AKS)稼働時間SLA

AKSはデフォルト構成ではSLAを提供していませんが、無料であるため、Microsoftは *デフォルト設定で99.5%の稼働率*を確保するよう努めています。

稼働時間SLAは、可用性ゾーンを使用するクラスタではKubernetes APIサーバーエンドポイントの*99.95%* の可用性、可用性ゾーンを使用しないクラスタでは99.9%の可用性を保証します。AKSは、SLA要件の遵守を確保するために、アップデートドメインとフォールトドメイン間でマスターノードレプリカを使用します。

Uptime SLA付きのAzure Kubernetesサービス(AKS)についての詳細は [こちら](https://docs.microsoft.com/en-us/azure/aks/uptime-sla) をご覧ください。

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

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

詳細については、「 [Azure Kubernetesサービス(AKS)の利用可能ゾーン - Azure Kubernetesサービス](https://docs.microsoft.com/en-us/azure/aks/availability-zones)」をご覧ください。

既知の制限事項:

-   クラスタやノードプールが作成されたときにのみ可用性ゾーンを定義できます。
-   クラスタ作成後は可用性ゾーンの設定を更新できません。また、既存の非可用性ゾーンクラスターを可用性ゾーンに更新することもできません。
-   選択したノードサイズ(VM SKU)は、選択したすべての可用性ゾーンで利用可能でなければなりません。
-   可用性ゾーンが有効化されたクラスタは、ゾーン間での分散のためにAzure標準ロードバランサーの使用が必要です。このロードバランサータイプはクラスタ作成時にのみ定義可能です。詳細および標準ロードバランサーの制限については、 [Azureロードバランサー標準SKU制限](https://docs.microsoft.com/en-us/azure/aks/load-balancer-standard#limitations)を参照してください。
-   データ転送に追加料金が適用されることがあります。詳細は [「価格設定」参照 – 帯域幅 |Microsoft Azure](https://azure.microsoft.com/en-ca/pricing/details/bandwidth/)

関連項目 [:可用性ゾーン(出口および入口)間のデータ転送は支払われます](https://azure.microsoft.com/en-ca/pricing/details/bandwidth/)。

## SQLエラスティックプール

Azure SQL Databaseは、地域ごとの高可用性が組み込まれた完全管理型リレーショナルデータベースです。

Azure SQLマネージドインスタンスは少なくとも99.99%の可用性保証があります。これはビジネスクリティカル層と一般目的層の両方に適用されます。サービス層は3つあります:

1.  **汎用/標準** - 一般的な作業負荷用。
2.  **ビジネスクリティカル/プレミアム** - 低遅延と高いレジリエンスを必要とする高スループットのOLTPアプリケーション向け。
3.  **ハイパースケール** - 非常に大規模なOLTPシステム向けに、ストレージと計算の自動スケーリングを行います:
    -   ゾーン冗長展開として構成されたAzure SQLデータベースのビジネスクリティカルまたはプレミアムティアは、少なくとも99.995%の可用性保証があります。
    -   ゾーン冗長展開に設定されていないAzure SQL Database Business CriticalまたはPremiumティアは、少なくとも99.99%の可用性保証があります。
    -   Azure SQL、2つ以上のレプリカを持つデータベースの汎用、標準、ベーシック、またはハイパースケール層は、少なくとも99.99%の可用性保証があります。
    -   Azure SQL 1つのレプリカを持つデータベースのハイパースケールティアは、少なくとも99.95%、レプリカがゼロの場合は99.9%の可用性保証があります。
    -   ジオレプリケーションAzure SQL設定されたデータベースビジネスクリティカル層は、展開時間の100%に対して5秒の回復ポイント目標(RPO)を保証します。
    -   ジオレプリケーションで設定されたデータベースビジネスクリティカル層Azure SQL、展開時間の100%に対して30秒の回復時間目標(RTO)が保証されます。

## Search Stax(検索・スタックス)

高可用性は内蔵されています。稼働時間は99.5(ゴールド)から99.95(プラチナプラス)までの対応ティアによって異なります。

[マネージドSOLRの価格設定と機能](https://www.searchstax.com/solr-as-a-service-pricing/)の詳細については、こちらをご覧ください。

## 正面玄関

Azure少なくとも99.99%の確率でFront Door Service Azureクライアントの要望にエラーなく対応し、リクエストされたコンテンツを確実に届けることを保証します。

## Azure Container Registry(ACR)

マネージドレジストリが少なくとも99.9%の確率でレジストリ取引を正常に処理することを保証します。クラシックレジストリのSLAはAzureストレージを通じて提供されています。

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

[Azureのコンテナレジストリに関するSLA](https://www.azure.cn/en-us/support/sla/container-registry/)を参照してください。

## 判決

高可用性の判断は本番構成にも適用されます。

表1。高可用性ソリューションと潜在的な目標SLA

リソース

解決策

潜在的なターゲットSLA

コメント

AKS

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

99.95%は、Workload用のAvailability Zonesを有効にしてペアリングしています

サポートエリアのリストを確認してください。

Windowsノードプール

-   2つの可用性ゾーンを設定
-   2番目のノードプールを廃止する - 1つのノードプールを使う
-   Scale Setは少なくとも2つのノードで設定すべきです

99.99%は、設定済みの可用性ゾーンで

利用可能なゾーンがサポートされている公共支援の場所のリストを確認してください。

Linux ノードプール

-   2つの可用性ゾーンを設定
-   Scale Setは少なくとも2つのノードで設定すべきです

99.99%は、設定済みの可用性ゾーンで

利用可能なゾーンがサポートされている公共支援の場所のリストを確認してください。

SQLエラスティックプール

汎用ティア

99.99%

Search Stax(検索・スタックス)

プラチナティア

99.9%

正面玄関

高可用性はデフォルトで提供されます

99.99%

ACR

-   プレミアムティア
-   対になった位置へのジオレプリケーション
-   [ゾーン冗長性を有効にする](https://docs.microsoft.com/en-us/azure/container-registry/zone-redundancy)

99.9%

プロビジョニング期間中にすべての(sitecore + サードパーティ製)画像をローカルで取得してください

ストレージアカウント

LRSレプリケーション

99.9999999999%(11個の9)

Kubernetes ワークロード

水平にスケールできるロールは、少なくとも2つのポッドで設定する必要があります