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 コレクション サイズ] を選択し、[集計] ボックスで [最大] を選択します。
選択した期間の最大データ収集サイズが表示されます。 必要に応じて、[時間範囲] を変更します (例: "過去 30 分" から "過去 48 時間" に)。
数式を使用して、必要な 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 の概要については、次を参照してください。
FHIR® は HL7 の登録商標であり、HL7 の許可を得て使用しています。