Azure IoT Hub は、クラウドでホストされるマネージド サービスであり、IoT アプリケーションとその接続されたデバイス間の通信のための中央メッセージ ハブとして機能します。
Azure を使用する場合、 信頼性は共有責任です。 Microsoft では、回復性と回復性をサポートするさまざまな機能を提供しています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。
この記事では、一時的な障害、可用性ゾーンの停止、リージョンの停止など、さまざまな障害や問題に対する IoT Hub の回復性を確保する方法について説明します。 また、バックアップを使用して他の種類の問題から復旧する方法についても説明し、IoT Hub サービス レベル アグリーメント (SLA) に関するいくつかの重要な情報を強調します。
一時的な障害に対する回復性
一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションが一時的な障害に対処できることが重要です。これは通常、影響を受けた要求を再試行することで対処します。
クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、「一時的な障害を処理するための推奨事項」を参照してください。
IoT Hub は、かなり高いアップタイム保証を提供しますが、分散コンピューティング プラットフォームで一時的な障害が発生する可能性があります。 一時的な障害を処理するには、クラウド アプリケーションと対話するコンポーネントで適切な 再試行パターン を構築します。
可用性ゾーンの障害に対する回復性
可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。
IoT Hub では、次の 2 種類の可用性ゾーンのサポートがサポートされています。
データのゾーン冗長性。デバイス ID レジストリとデバイスからクラウドへのメッセージを格納する基になるストレージ コンポーネントの複数の可用性ゾーン間でデータが自動的にレプリケートされます。
コンピューティングのゾーン冗長性。デバイスの管理とメッセージのルーティングを担当するコンポーネントの回復性を提供します。
リージョンのサポート
IoT ハブの可用性ゾーンのサポートの種類は、デプロイされているリージョンによって異なります。
| リージョン | データのゾーン冗長性 | コンピューティングのゾーン冗長性 |
|---|---|---|
| オーストラリア東部 |
|
|
| ブラジル南部 |
|
|
| カナダ中部 |
|
|
| インド中部 |
|
|
| 米国中部 |
|
|
| 米国東部 |
|
|
| フランス中部 |
|
|
| ドイツ中西部 |
|
|
| 東日本 |
|
|
| 韓国中部 |
|
|
| 北ヨーロッパ |
|
|
| ノルウェー東部 |
|
|
| カタール中部 |
|
|
| 米国中南部 |
|
|
| 東南アジア |
|
|
| 英国南部 |
|
|
| 西ヨーロッパ |
|
|
| 米国西部 2 |
|
|
| 米国西部 3 |
|
|
この一覧にないリージョンで作成する IoT ハブは、ゾーンの停止に対する回復性がありません。
費用
IoT Hub を使用したゾーン冗長性に対する追加コストは発生しません。
可用性ゾーンのサポートを設定する
IoT Hub リソースは、サポートされているリージョンにデプロイされると、ゾーンの冗長性 を自動的にサポートします。 それ以上の構成は必要ありません。
すべてのゾーンが正常な場合の動作
このセクションでは、IoT Hub リソースがゾーン冗長用に構成され、すべての可用性ゾーンが運用可能な場合に想定される内容について説明します。
ゾーン間のデータ レプリケーション: データのゾーン冗長性をサポートするリージョンに IoT ハブがデプロイされると、データの変更が可用性ゾーン間で自動的にレプリケートされます。 レプリケーションは同期的に行われます。
ゾーン間のトラフィック ルーティング: IoT ハブがコンピューティング コンポーネントのゾーン冗長をサポートするリージョンにデプロイされると、要求は可用性ゾーンの 1 つのサービスのプライマリ インスタンスにルーティングされます。 Azure では、アクティブなインスタンスとゾーンが自動的に選択されます。
ゾーン障害時の動作
このセクションでは、IoT Hub リソースがゾーン冗長用に構成されていて、可用性ゾーンの停止が発生した場合に想定される内容について説明します。
- 検出と応答: IoT Hub サービスは、可用性ゾーンでの障害を検出する役割を担います。 ゾーンのフェールオーバーを開始するために何もする必要はありません。
- 通知: ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、 Azure Resource Health を 使用して個々のリソースの正常性を監視したり、 Resource Health アラート を設定して問題を通知したりすることはできます。 また、Azure Service Health を使用して、ゾーンの障害を含むサービスの全体的な正常性を把握し、問題を通知する Service Health アラートを設定することもできます。
アクティブな要求: ゾーン障害時に、アクティブな要求が削除される可能性があります。 クライアントとデバイスには、一時的な障害を処理するための十分な 再試行ロジック が実装されている必要があります。
予想されるデータ損失: IoT ハブが、データのゾーン冗長性をサポートするリージョンにデプロイされている場合、ゾーンの障害によってデータが失われることはありません。
予想されるダウンタイム: コンピューティング コンポーネントとデータ コンポーネントの両方のゾーン冗長性をサポートするリージョンに IoT ハブがデプロイされている場合、ゾーン障害によって IoT Hub リソースにダウンタイムが発生することはありません。
トラフィックの再ルーティング: IoT Hub がコンピューティング コンポーネントのゾーン冗長性をサポートするリージョンにデプロイされると、IoT Hub はゾーンの損失を検出します。 その後、すべての新しい要求は、正常な可用性ゾーンのいずれかのサービスの新しいプライマリ インスタンスに自動的にリダイレクトされます。
ゾーンの回復
可用性ゾーンが復旧すると、IoT Hub は可用性ゾーン内のインスタンスを自動的に復元し、インスタンス間のトラフィックを通常どおりに再ルーティングします。
ゾーンエラーのテスト
IoT Hub はゾーン障害のトラフィック ルーティング、フェールオーバー、フェールバックを完全に管理するため、可用性ゾーンの障害プロセスを検証したり、それ以上入力したりする必要はありません。
リージョン全体の障害に対する回復性
IoT Hub は、単一リージョンのサービスです。 リージョンが使用できなくなった場合、IoT Hub リソースも使用できなくなります。
ただし、リソースが ペアになっているリージョンにある場合、IoT ハブのデータはペアになっているリージョンにレプリケートされます。
次のシナリオでは、IoT ハブがペアのリージョンにフェールオーバーされる場合があります。
顧客が開始したフェールオーバー: リージョンでダウンタイムが発生しているかどうかに関係なく、ペアになっているリージョンへの手動フェールオーバーを自分でトリガーできます。 この方法を使用して、計画されたフェールオーバーと訓練を実行できます。
Microsoft によって開始されるフェールオーバー: リージョンが失われた場合、Microsoft は、ペアになっているリージョンへの IoT ハブのフェールオーバーを開始できます。 ただし、Microsoft は、大幅な遅延とベスト エフォートベースを除き、フェールオーバーを開始する可能性はほとんどありません。 IoT Hub リソースのフェールオーバーは、他の Azure サービスのフェールオーバーとは異なるタイミングで発生する可能性があります。 このプロセスは既定のオプションであり、ユーザーの介入は必要ありません。
リソースが ペアになっていないリージョンにある場合、Microsoft はリージョン間で構成とデータをレプリケートせず、リージョン間フェールオーバーも組み込まれません。 ただし、複数のリージョンに個別のリソースをデプロイできます。 このシナリオでは、レプリケーション、トラフィック分散、およびフェールオーバーを管理する必要があります。
IoT ハブがペアになっていないリージョンにある場合、または既定のレプリケーションとフェールオーバーの動作がニーズを満たしていない場合は、 回復性のためにカスタムマルチリージョン ソリューション を使用して、フェールオーバーを計画および開始できます。
リージョンのサポート
既定のレプリケーションとフェールオーバーは、ペアになっているリージョンでのみサポートされます。
要求事項
ペアリージョンのレプリケーションとフェールオーバーのオプションは、すべての IoT Hub レベルで使用できます。
考慮事項
顧客が開始したフェールオーバーを使用して、Azure のペアになっているリージョン間でハブを永続的に移行しないでください。 一般に、デバイスはハブのプライマリ リージョンの近くに配置されます。 ハブをセカンダリ リージョンに移動すると、デバイスとセカンダリの場所にある IoT ハブ間の操作の待機時間が長くなります。
費用
ペアになっているリージョン内のハブの場合、リージョン間のデータ レプリケーションまたはフェールオーバーに追加コストはかからなくなります。
IoT ハブがペアになっていないリージョンにある場合、考えられるコスト情報については、 回復性に関するカスタムマルチリージョン ソリューション を参照してください。
レプリケーションの構成とフェールオーバーの準備
既定では、リージョン間データ レプリケーションは、ペアになっているリージョンに IoT ハブを作成するときに自動的に構成されます。 このプロセスは既定のオプションであり、ユーザーの介入は必要ありません。 ブラジル南部および東南アジア (シンガポール) を除くリージョンでは、顧客データは、サービス インスタンスをデプロイする地域の外部に保存または処理されません。
IoT ハブがブラジル南部または東南アジア (シンガポール) リージョンにある場合は、データ レプリケーションを無効にしてフェールオーバーをオプトアウトできます。 詳細については、「 ディザスター リカバリー (DR) を無効にする」を参照してください。
IoT ハブがペアになっていないリージョンにある場合は、独自のリージョン間レプリケーションとフェールオーバーアプローチを計画する必要があります。 詳細については、「 回復性のためのカスタム マルチリージョン ソリューション」を参照してください。
すべてのリージョンが正常な場合の動作
このセクションでは、リージョン間のレプリケーションとフェールオーバー用に IoT ハブが構成されていて、プライマリ リージョンが動作している場合に想定される内容について説明します。
リージョン間のデータ レプリケーション: データは、ペアになっているリージョンに自動的にレプリケートされます。 レプリケーションは非同期的に行われます。これは、フェールオーバーが発生した場合に一部のデータ損失が予想されることを意味します。 ペアになっていないリージョン内の IoT ハブのリージョン間のデータ レプリケーションはありません。
リージョン間のトラフィック ルーティング: 通常の操作では、トラフィックはプライマリ リージョンにのみ流れます。
リージョン障害時の動作
このセクションでは、リージョン間のレプリケーションとフェールオーバーのために IoT ハブが構成されていて、プライマリ リージョンで障害が発生した場合に想定される内容について説明します。
検出と応答: プライマリ リージョンでの停止を検出して対応する責任はさまざまです。
顧客が開始したフェールオーバー: リージョンの損失を検出し、フェールオーバーするタイミングを決定する責任があります。 ペアになっているリージョン間で顧客が開始したフェールオーバーを実行する方法の詳細については、「 IoT ハブの手動フェールオーバーを実行する」を参照してください。
顧客が開始したフェールオーバーまたはフェールバックを実行できる頻度には制限があります。
ユーザーは、1 日に 2 回のフェールオーバー操作と 2 回の成功したフェールバック操作を実行できます。
バックツーバックフェールオーバーまたはフェールバック操作は許可されません。 これらの操作の間に 1 時間待機する必要があります。
Microsoft によって開始されるフェールオーバー: Microsoft は、プライマリ リージョンが失われた場合にフェールオーバーを実行することを決定できます。 このプロセスは、プライマリ リージョンの損失後に数時間かかる場合もあれば、一部のシナリオではさらに長くなる場合があります。 IoT Hub リソースのフェールオーバーは、他の Azure サービスと同時に発生しない可能性があります。
アクティブな要求: フェールオーバー中にプライマリ リージョンが処理している要求はすべて失われる可能性があります。 クライアントは、フェールオーバーの完了後に要求を再試行する必要があります。
予想されるデータ損失: ペアになっているリージョンの場合、データはペアになっているリージョンに非同期的にレプリケートされます。 その結果、フェールオーバー後に一部のデータ損失が予想されます。 このプロセスは、Microsoft が管理するフェールオーバーとカスタマー マネージド フェールオーバーの両方に適用されます。 次の表は、IoT ハブが格納する各種類のデータの 目標復旧ポイント (RPO) または予想されるデータ損失の概要を示しています。
データの種類 RPO ID レジストリ 0 ~ 5 分のデータ損失 デバイス ツイン データ 0 ~ 5 分のデータ損失 クラウドからデバイスへのメッセージ 1 0 ~ 5 分のデータ損失 親 1 およびデバイス ジョブ 0 ~ 5 分のデータ損失 デバイスからクラウドへのメッセージ すべての未読メッセージが失われる クラウドからデバイスへのフィードバック メッセージ すべての未読メッセージが失われる 1 クラウドからデバイスへのメッセージと親ジョブは、顧客が開始したフェールオーバーの一部として復旧されません。
予想されるダウンタイム: リージョンのフェールオーバー中に予想されるダウンタイムは、フェールオーバーの種類によって異なります。
顧客が開始したフェールオーバー: リージョンが失われたときから、ペアになっているリージョンでリソースが運用されている場合まで、約 10 分から 2 時間のダウンタイムが予想されます。 フェールオーバー対象の IoT ハブ インスタンスに対して登録されたデバイスの数は、復旧時間に影響します。 約 100,000 台のデバイスをホストするハブの復旧時間は約 15 分と予想できます。
Microsoft によって開始されるフェールオーバー: リージョンが失われたときから、ペアになっているリージョンでリソースが使用可能になったときまで、約 2 ~ 26 時間のダウンタイムが予想されます。
復旧時間が長いのは、Microsoft がそのリージョンの影響を受けるすべての顧客に代わってフェールオーバー操作を実行する必要があるためです。 重要なシステムの場合は、ダウンタイムを短縮するために、顧客が開始したフェールオーバーを使用する必要があります。 ただし、ほぼ 1 日のダウンタイムを維持できる重要度の低い IoT ソリューションを実行する場合は、Microsoft が開始するオプションに依存して、IoT ソリューションの全体的な DR 目標を満たすことが可能な場合があります。
どちらのフェールオーバーの種類でも、IoT ハブ インスタンスの完全修飾ドメイン名はフェールオーバー後も同じままです。つまり、接続文字列も同じままです。 ただし、基になる IP アドレスが変更されるため、クライアントは、フェールオーバー後に IoT ハブにアクセスする前に、ドメイン ネーム システム (DNS) レコードが更新されるのを待つ必要があります。
Von Bedeutung
IoT Hub SDK では、IoT ハブの IP アドレスはキャッシュされません。 SDK とやり取りするユーザー コードも、IoT ハブの IP アドレスをキャッシュしないでください。
これらの要因により、フェールオーバー プロセス後に IoT Hub インスタンスに対して実行されるランタイム操作が完全に動作する時間は、次の関数を使用して表すことができます。
回復時間 = RTO [顧客が開始したフェールオーバーの場合は 10 分から 2 時間、Microsoft が開始したフェールオーバーの場合は 2 ~ 26 時間] + DNS 伝達遅延 + キャッシュされた IoT ハブ IP アドレスの更新にクライアント アプリケーションが要する時間
トラフィックの再ルーティング: フェールオーバー プロセス中に、IoT Hub は、ペアのリージョンを指す DNS レコードを更新します。 後続のすべての要求は、ペアになっているリージョンに送信されます。
IoT ハブのフェールオーバー操作が完了した後、デバイスとバックエンド アプリケーションのすべての操作は、手動による介入を必要とせずに動作し続ける必要があります。 この継続性により、デバイスからクラウドへのメッセージが引き続き機能し、デバイス レジストリ全体が損なわれないようにします。 Azure Event Grid を介してイベントを生成する場合、それらの Event Grid サブスクリプションが引き続き使用できる限り、以前に構成したのと同じサブスクリプションを介してイベントを使用できます。 カスタム エンドポイントにそれ以上の処理は必要ありません。
フェールオーバー後の構成が必要
IoT ハブのメッセージをルーティングする場所によっては、フェールオーバーの完了後に追加の手順を実行することが必要になる場合があります。
Azure Event Hubs: フェールオーバー後に、IoT ハブの組み込みイベント エンドポイントの Event Hubs 互換の名前とエンドポイントが変更されます。 この変更は、Event Hubs クライアントが IoT Hub イベントを可視化していないために発生します。
Event Hubs クライアントまたはイベント プロセッサ ホストを使用して組み込みエンドポイントからテレメトリ メッセージを受信する場合は、 IoT ハブの接続文字列を使用 して接続を確立します。 この方法により、フェールオーバー後に手動による介入を必要とせずに、バックエンド アプリケーションが引き続き動作するようになります。
アプリケーションで Event Hubs 互換の名前とエンドポイントを直接使用する場合は、フェールオーバー後に 新しい Event Hubs 互換エンドポイントをフェッチ して操作を続行する必要があります。 エンドポイントと名前を取得するには、Azure portal または .NET SDK を使用します。
Azure portal: ポータルを使用して Event Hubs 互換エンドポイントと Event Hubs 互換の名前を取得する方法の詳細については、「 組み込みエンドポイントへの接続」を参照してください。
.NET SDK: IoT Hub 接続文字列を使用して Event Hubs と互換性のあるエンドポイントを再キャプチャするには、 サンプル コードを使用します。 このコード例では、接続文字列を使用して新しい Event Hubs エンドポイントを取得し、接続を再確立します。 Visual Studio がインストールされている必要があります。
Azure Functions と Azure Stream Analytics: Azure Functions または Stream Analytics を使用して組み込みのイベント エンドポイントに接続する場合は、前の箇条書きで説明したのと同じプロセスに従って、関数またはジョブが接続する Event Hubs エンドポイントを更新する必要があります。 フェールオーバー後にイベント ストリームオフセットが無効になるため、 再起動 アクションを実行します。
Azure Storage: Azure Storage にルーティングするときは、最初に BLOB またはファイルを一覧表示します。 次に、それらを反復処理して、パーティション分割を想定せずにすべての BLOB またはファイルが読み取られるようにします。 パーティションの範囲は、Microsoft が開始したフェールオーバーまたは顧客が開始したフェールオーバー中に変更される可能性があります。 List Blobs API を使用して、BLOB の一覧を列挙するか、ファイルの一覧の Azure Data Lake Storage API を列挙できます。 詳細については、 ルーティング エンドポイントとしての Azure Storage に関するページを参照してください。
リージョンの復旧
プライマリ リージョンにフェールバックするには、フェールオーバー アクションをもう一度手動でトリガーします。 フェールオーバーの頻度に関する制限事項を覚えておく必要があります。
元のプライマリ リージョンの拡張停止から復旧するために元のフェールオーバー操作が実行された場合は、プライマリ リージョンが障害から復旧した後、プライマリ リージョンへのフェールバックを実行します。
リージョン障害のテスト
リージョンの停止中に障害をシミュレートするには、IoT ハブの手動フェールオーバーをトリガーします。 ただし、リージョンフェールオーバーはダウンタイムとデータ損失の両方を引き起こすので、非運用環境でのみテスト フェールオーバーを実行する必要があります。 詳細については、「 リージョン障害時の動作」を参照してください。 計画されたフェールオーバー オプションを定期的に開始するように、テスト IoT Hub インスタンスを設定することを検討してください。 定期的なテストは、実際の災害が発生した場合にエンド ツー エンド のソリューションを効果的に復元して運用する能力に自信を持てるのに役立ちます。
回復性のためのカスタム マルチリージョン ソリューション
IoT Hub のリージョン間フェールオーバー機能は、次のシナリオには適していません。
IoT ハブはペアになっていないリージョンにあります。
ビジネスアップタイムの目標は、組み込みのフェールオーバー オプションによって提供される復旧時間またはデータ損失によって満たされません。
プライマリ リージョンのペアではないリージョンにフェールオーバーする必要があります。
個々のデバイスに合わせて調整されたリージョン間フェールオーバー ソリューションを設計できます。 IoT ソリューションでのデプロイ トポロジの完全な処理は、この記事の範囲外ですが、複数リージョンのデプロイ モデルを検討できます。 このモデルでは、プライマリ IoT ハブとソリューション バックエンドは、主に 1 つの Azure リージョンで実行されます。 セカンダリ IoT ハブとバックエンドは、別の Azure リージョンにデプロイされます。 プライマリ リージョンの IoT ハブで障害が発生した場合、またはデバイスからプライマリ リージョンへのネットワーク接続が中断された場合、デバイスはセカンダリ サービス エンドポイントを使用します。
予想されるダウンタイム: この方法のダウンタイムは 1 分未満ですが、実装が複雑になる可能性があります。
予想されるデータ損失: データ損失の量は、使用する特定のデータ ストアと、それらの間の geo レプリケーションを構成する方法によって異なります。
費用： この方法では、少なくとも 1 つの追加の IoT ハブをプロビジョニングする必要があります。これにより、全体的なコストが増加します。
大まかに言うと、IoT Hub を使用してリージョンのフェールオーバー モデルを実装するには、次の対策を行う必要があります。
セカンダリ IoT ハブとデバイス ルーティング ロジック: プライマリ リージョンのサービスが中断された場合、デバイスはセカンダリ リージョンへの接続を開始する必要があります。 関係するほとんどのサービスの状態に対応する性質のため、ソリューション管理者は通常、リージョン間フェールオーバー プロセスを手動でトリガーします。 プロセスの制御を維持しながら新しいエンドポイントをデバイスに通信する最善の方法は、コンシェルジェ サービスで現在アクティブなエンドポイントを定期的にチェックしてもらう方法です。 コンシェルジェ サービスは、 Azure Traffic Manager などの DNS リダイレクト手法を使用してレプリケートされ、到達可能な状態を維持する Web アプリケーションにすることができます。
注
Traffic Manager には、IoT Hub のサポートが組み込まれていません。 各 IoT ハブのカスタム Traffic Manager エンドポイントを構成できます。 IoT ハブのエンドポイントを使用するように Traffic Manager エンドポイントの正常性プローブを構成します。
ID レジストリ レプリケーション: 使用できるようにするには、セカンダリ IoT ハブに、ソリューションに接続できるすべてのデバイス ID が含まれている必要があります。 ソリューションでは、デバイス ID の geo レプリケート バックアップを保持し、セカンダリ IoT ハブにアップロードしてから、デバイスのアクティブなエンドポイントを切り替える必要があります。 IoT Hub のデバイス ID エクスポート機能は、この点で役に立ちます。 詳細については、「IoT Hub の ID レジストリを理解する」を参照してください。
マージ ロジック: プライマリ リージョンが再び使用可能になったら、セカンダリ リージョンで作成されたすべての状態とデータをプライマリ リージョンに移行する必要があります。 状態とデータは主にデバイス ID およびアプリケーション メタデータと関連しており、プライマリ IoT ハブとマージする必要があります。また、プライマリ リージョンにある他のアプリケーション固有のストアとのマージが必要になることもあります。
この手順を簡略化するには、"べき等" 操作を使用します。 べき等操作により、最終的に一貫性のあるイベント分布だけでなく、イベント重複や順不同配信の副次的な影響を最小限に抑えられます。 また、アプリケーション ロジックは、潜在的な不整合や少し古い状態を許容するように設計する必要があります。 このシナリオは、RPO に基づいてシステムの回復にかかる時間が長いために発生する可能性があります。
バックアップと復元
IoT Hub サービスを使用すると、一括エクスポート操作が可能になります。これにより、IoT ハブの ID レジストリ全体をエクスポートできます。 このデータは、Shared Access Signature を使用して Azure Storage BLOB コンテナーに転送されます。 このメソッドでは、制御対象の BLOB コンテナーにデバイス情報のバックアップを確実に作成することができます。 詳細については、「 IoT Hub デバイス ID を一括でインポートおよびエクスポートする」を参照してください。
既存の IoT ハブの Azure Resource Manager テンプレート (ARM テンプレート) をエクスポートして、IoT ハブの構成のバックアップを作成することもできます。 詳細については、「 ARM テンプレートを使用して IoT ハブを手動で移行する」を参照してください。
ほとんどのソリューションでは、バックアップのみに依存しないでください。 代わりに、このガイドで説明されている他の機能を使用して、回復性の要件をサポートします。 ただし、バックアップでは、他の方法では行わないリスクから保護されます。 詳細については、「冗長性、レプリケーション、バックアップとは」を参照してください。
サービス水準合意書
Azure サービスのサービス レベル アグリーメント (SLA) には、各サービスの期待される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について記載されています。 詳細については、 オンライン サービスの SLA を参照してください。