Azure API for FHIR の自動スケーリング

  • [アーティクル]

マネージド サービスとしての Azure API for FHIR を使用すると、顧客は高速ヘルスケア相互運用性リソース (FHIR®) 準拠のヘルスケア データを保持し、サービス API を介してそれを安全に交換できます。 さまざまなトランザクション ワークロードに対応するために、顧客は手動スケーリングまたは自動スケーリングを使用できます。

Azure API for FHIR は、データベースとコンピューティング レベルでスケーリング機能を提供します。

データベース レベルでの自動スケーリング

既定では、Azure API for FHIR はデータベーススケーリングのために手動に設定されています。 このオプションは、トランザクション ワークロードが既知で一貫性がある場合に適しています。 お客様は、ポータルを通じて最大 100,000 のスループット RU/s を調整し、制限を引き上げる要求を送信できます。

自動スケーリング機能は、ワークロードに応じてデータベース のスループットを含む Azure リソースを自動的にスケーリングするように設計されており、データ レイヤーのボトルネックが解消されます。

次のセクションでデータベース レベルで自動スケーリングを有効にする方法について説明します

自動スケーリングを有効にするガイダンス

一般に、ワークロードが大幅に変化し、予測できない場合、顧客は自動スケーリングを検討する必要があります。

自動スケーリング機能を有効にするには、お客様が 1 回限りのサポート チケットを作成して、Azure portalを通じて要求する必要があります。 Microsoft サポート チームは、サポートの優先順位に基づいて自動スケーリング機能を有効にします。

注意

自動スケーリング機能は、Azure portal からは利用できません。

RU/秒の自動スケーリング

自動スケーリングが有効になっている場合、システムは初期の Tmax 値を計算して設定します。 スケーラビリティは、最大スループット RU/s 値または Tmax によって制御され、0.1 *Tmax (または 10% Tmax) から Tmax RU/s の間でスケーリングされます。 合計データ サイズが大きくなると、Tmax が自動的に増加します。 スケーラビリティを最大限に高めるために、Tmax 値はそのままにしておく必要があります。 ただし、お客様は値を Tmax 値の 10% から 100% の間に変更するように要求できます。

最大 RU/s または Tmax 値を引き上げて、サービスによってサポートされる上限まで高くすることができます。 サービスがビジー状態の場合、スループット RU/s は Tmax 値にスケールアップされます。 サービスがアイドル状態の場合、スループット RU/s は 10% Tmax 値にスケールダウンされます。

RU/s または Tmax の最大値を減らすこともできます。 最大 RU/s を引き下げる場合、設定できる最小値は MAX (4000, highest max RU/s ever provisioned / 10, current storage in GB * 400) であり、最も近い 1000 RU/s に丸められます。

  • 例 1: 1 GB のデータを持っており、プロビジョニングされた最大 RU/s は 10,000 です。 最小値は Max (4000, 10,000/10, 1x400) = 4000 です。 最初の数値 4000 が使用されます。
  • 例 2: 20 GB のデータを持っており、プロビジョニングされた最大 RU/s は 100,000 です。 最小値は Max (4000, 100,000/10, 20x400) = 10,000 です。 2 番目の数値 100,000/10 =10,000 が使用されます。
  • 例 3: 80 GB のデータを持っており、プロビジョニングされた最大 RU/秒は 300,000 です。 最小値は Max (4000, 300,000/10, 80x400) = 32,000 です。 3 番目の数値 80x400=32,000 が使用されます。

有効な数値で、100,000 RU/sを超えない場合は、ポータルで最大値RU/sまたはTmax値を調整できます。 サポート チケットを作成して、100,000 を超える値を要求 Tmax できます。

注意

データ ストレージが大きくなると、システムは、そのレベルのストレージをサポートできる次に高い RU/秒に最大スループットを自動的に増やします。

コンピューティング レベルでの自動スケーリング

FHIR サービス コンピューティング レベルに対して定義された自動スケーリング ポリシーは、次のように構成されます。

  • スケーリング トリガー

スケーリング トリガーでは、サービスのスケーリングが実行されるタイミングについて説明します。 トリガーに定義された条件が定期的にチェックされ、サービスをスケーリングする必要があるかどうかが決定されます。 現在サポートされているすべてのトリガーは、平均 CPU、最大ワーカー スレッド、平均 LogWrite、平均データ IO です。

  • スケーリング メカニズム

スケーリングメカニズムは、スケーリングが必要であるとトリガー チェックによって判断された場合に適用されます。 さらに、スケーリングトリガーは、スケーリング間隔の有効期限が切れるまで再評価されません。これは、Azure API for FHIR の場合は 1 分に設定されます。

可能な限り最良の結果を得るために、すべての要求を一度にプッシュするのではなく、予想されるプッシュレートに合わせて徐々に要求率を上げることをお勧めします。

よく寄せられる質問

必要なスループット RU/秒を見積もる方法

データ サイズは、手動スケールと自動スケーリングに必要な合計スループット RU/秒を計算する際に使用されるいくつかの要因の 1 つです。 データ サイズは、[監視] の [メトリック] メニュー オプションを使用して確認できます。 新しいグラフを開始し、[メトリック] ドロップダウン ボックスで [Cosmos DB コレクション サイズ] を選択し、[集計] ボックスで [最大] を選択します。

metrics_new_chart のスクリーンショット

選択した期間の最大データ収集サイズが表示されます。 必要に応じて、[時間範囲] を変更します (例: "過去 30 分" から "過去 48 時間" に)。

cosmosdb_collection_size のスクリーンショット

数式を使用して、必要な RU/秒を計算します。

  • 手動スケール: GB 単位のストレージ * 40
  • 自動スケーリング: GB 単位のストレージ * 400

これはデータ サイズに基づく見積もりのみで、必要な RU/秒に影響するその他の要因があることに注意してください。

自動スケーリングを有効にした場合、手動でスケーリングに移行するにはどうすればよいですか?

自動スケーリングを手動スケールに変更し、スループット RU/秒を指定するには、サポート チケットが必要です。 設定可能な手動スケールの最小値は MAX (400, highest max RU/s ever provisioned / 100, current storage in GB * 40) で、最も近い 1000 RU/s の位に丸められます。 ここで使用する数値は、自動スケーリングで使用されるものとは異なります。

変更が完了すると、新しい課金レートは手動スケールに基づいて行われます。

自動スケーリングのコストへの影響

自動スケーリング機能では、プロビジョニングされたスループット ユニットが自動的に管理されるため、コストが発生します。 実際のコストは時間単位の使用量によって異なりますが、予約済みスループット RU/秒について、Tmax の 10% の最小コストがかかることに注意してください。 ただし、このコストの上昇は、ストレージとランタイムのコストには適用されません。 価格の詳細については、「Azure API for FHIR の価格」をご覧ください。

次のステップ

このドキュメントでは、Azure API for FHIR の自動スケーリング機能について説明しました。 Azure API for FHIR の概要については、次を参照してください。

Azure API for FHIR について

FHIR® は HL7 の登録商標であり、HL7 の許可を得て使用しています。