スケーリングとパーティション分割を最適化するための推奨事項
この Azure Well-Architected Framework パフォーマンス効率チェックリストの推奨事項に適用されます。
| PE:05 | スケーリングとパーティション分割を最適化します。 信頼性の高い制御されたスケーリングとパーティション分割を組み込みます。 ワークロードのスケール ユニット設計は、スケーリングとパーティション分割の戦略の基礎です。 |
|---|
このガイドでは、ワークロードのスケーリングとパーティション分割に関する推奨事項について説明します。 スケーリングは、需要に基づいてワークロードに割り当てられたリソースを増減する機能です。 パーティション分割では、ワークロードをより小さく管理可能な単位に分割して、データと処理を複数のリソースに分散します。 スケーリングまたはパーティションを使用しないワークロードでは、需要の高い期間ではパフォーマンスが低下し、低需要期間では使用率の低い容量が発生する可能性があります。
定義
| 期間 | 定義 |
|---|---|
| 自動スケール | 定義済みの構成に基づいてサービスの容量制限を自動的に調整し、必要に応じてスケールアップまたはスケールダウンできるようにする機能。 |
| 容量 | 特定のサービスまたは機能の上限または最大容量。 |
| クライアント アフィニティ (セッション アフィニティ) | 一貫性のあるセッション管理を確保するために、1 つのクライアントから 1 つのサーバー インスタンスへの要求の意図的なルーティング。 |
| 整合性 (分散データベース) | 分散データベース内の複数のノード間でのデータの均一性により、すべてのレプリカが特定の時点で同じデータを持つことが保証されます。 |
| 整合性 (リレーショナル データベース) | データベースを有効な状態から別の状態に持ち込み、データの整合性を維持するトランザクションの プロパティ。 |
| 整合性レベル | 分散データベース システムでデータをレプリケートする方法とタイミングを定義し、整合性とパフォーマンスのトレードオフを決定する構成。 |
| データロック | 同じデータに対する同時更新を防ぐために使用されるメカニズム。 |
| 水平スケーリング | 特定の種類のリソースのインスタンスを追加するスケーリング アプローチ。 |
| オプティミスティック コンカレンシー | 従来のロック メカニズムではなく、スナップショットを使用して更新を行うデータベースを更新するためのアプローチ。 |
| パーティション分割 | データを個別のデータ ストアに物理的に分割するプロセス。 |
| スケーラビリティ | ワークロードの容量制限を動的に変更して、さまざまなレベルの需要に対応する機能。 |
| スケール ユニット | 比例してスケーリングされるリソースのグループ。 |
| 状態アフィニティ | 同じサーバーが同じクライアントからの後続の要求を処理できるように、単一サーバー上のクライアント セッション データのストレージ。 |
| 垂直方向のスケーリング | 既存のリソースにコンピューティング容量を追加するスケーリング アプローチ。 |
主要な設計戦略
スケーリングとパーティション分割はどちらも、リソースが効果的に使用され、ワークロードがさまざまな負荷に対処できるようにすることで、パフォーマンスの効率に貢献します。 これらのプラクティスは、変化する需要に柔軟かつ適応可能なアプリケーションが必要なクラウド環境で特に重要です。 スケーリングにより、増加する需要に合わせてワークロード容量を拡張できます。 パーティション分割を使用すると、タスクまたはデータを効率的に分割して、これらの増大するニーズに対応できます。 これらのプロセスの基盤は、ワークロードのスケール ユニット設計です。 ワークロードの拡大とタスクの分散方法が決まります。 スケーリングとパーティション分割に信頼性が高く制御されたアプローチを組み込むことで、潜在的なワークロードの非効率性を回避できます。
スケーリングを最適化する
スケーリングの最適化は、ワークロードの変動する需要に合わせてサーバー、インスタンス、またはリソースの数を調整するプロセスです。 これにより、パフォーマンスの低下やダウンタイムが発生することなく、ワークロードでトラフィックや需要の増加に対応できるようになります。
スケーリング戦略を選択する
スケーリング戦略を選択するには、特定の要件に基づいてワークロードの容量を拡張するための垂直または水平の方法を決定する必要があります。 適切な戦略を選択すると、過剰な使用や無駄を伴わずにワークロードの需要に合わせてリソースが効率的に調整されます。 適切なスケーリング戦略を選択するには、垂直方向と水平方向のスケーリングのユース ケースと、それらがワークロードのニーズをどのように満たすかを理解する必要があります。
垂直方向のスケーリングについて理解する。 垂直方向のスケーリングを使用すると、より大きなサーバーまたはインスタンス サイズへのアップグレードなど、1 つのリソースの容量を増やすことができます。 垂直方向のスケーリングは、ワークロードが 1 つのインスタンス内の処理能力、メモリ、またはその他のリソースの増加の恩恵を受けることができる場合に便利です。 垂直方向のスケーリングは、小さな部分に簡単に分割されないワークロードや、アプリケーション アーキテクチャで水平スケーリングがサポートされていないワークロードに適しています。
水平スケーリングについて理解する。 水平方向のスケーリングを使用すると、複数のサーバーにワークロードを分散させるために、インスタンスまたはリソースを追加できます。 水平方向のスケーリングには、回復性の向上、容量の増加、トラフィックやワークロードの需要の増加に対処する機能などの利点があります。 これは、複数のノードで実行するように設計されたクラウドネイティブ アプリケーションに効果的です。 水平方向のスケーリングは、個別に実行される小さな部分に分割できるワークロードに適しています。
ワークロードを理解する。 垂直方向または水平方向のスケーリングの適合性は、ワークロードの特定の特性と要件によって異なります。 次の領域での定期的なパフォーマンスの監視とテストは、時間の経過に伴うスケーリング戦略の最適化に役立ちます。
要件: リソースの需要、スケーラビリティのニーズ、ワークロードの制限などの要因を考慮して、ワークロードの特定の要件を理解します。
スケール ユニット: 一緒にスケーリングすることが想定されるコンポーネントのスケール ユニット設計を作成します。 たとえば、100 台の仮想マシンで、追加のワークロードを処理するために 2 つのキューと 3 つのストレージ アカウントが必要になる場合があります。 スケール ユニットは、100 台の仮想マシン、2 つのキュー、3 つのストレージ アカウントになります。 容量使用の変動が発生するすべてのコンポーネントを個別にスケーリングする必要があります。
アーキテクチャ: アプリケーション アーキテクチャの設計を評価します。 一部のアプリケーションは、複数のインスタンスに簡単に分散できるステートレス コンポーネントを使用して、水平方向にスケーリングするように本質的に設計されている場合があります。 他のアプリケーションには、垂直方向のスケーリングをより適切にするステートフル コンポーネントまたは依存関係がある場合があります。 ワークロードのスケーラビリティと弾力性の要件を評価します。
スケーリングするインフラストラクチャを設計する
スケーリングするインフラストラクチャの設計は、必要に応じてリソースを追加または調整することで、増加する需要とワークロードに対応できるアーキテクチャを作成するプロセスです。 これには、成長に対応するために水平方向または垂直方向にスケーリングできるソリューションの計画と実装が含まれます。 戦略には、ボトルネックになる可能性があるシングルトンの回避や、独立したスケーラビリティを確保するためのアプリケーション コンポーネントの分離が含まれます。 ワークロードをスケーラブルに設計すると、ワークロードを複数のリソースに効果的に分散できるため、ボトルネックを回避し、リソースの使用率を最大化できます。
シングルトンは避けてください。 ワークロード全体に対して単一の一元化されたリソースを使用しないようにする必要があります。 代わりに、スケーラビリティ、フォールト トレランス、パフォーマンスを向上させるために、ワークロードを複数のリソースに分散します。 ワークロード リソースのシングルトンを回避するために、いくつかの具体的な例と設計上の考慮事項について説明します。
キューベースの負荷平準化: 1 つのキューに依存してメッセージを処理するのではなく、複数のキューにワークロードをパーティション分割して処理負荷を分散することを検討してください。 スケーラビリティと並列処理が向上します。
データ処理: シングルトン パターンは、多くの場合、処理がファンアウトしないデータ処理シナリオで発生します。実行時間の長いタスクを小規模なタスクに分割します。このタスクは、ワークロードを複数のリソースに分散させ、並列処理を活用するために、より適切にスケーリングできます。
設計パターン: ファンアウト/ファンイン、パイプ、フィルターなどの設計パターンは、ワークフロー内のシングルトンを回避するのに役立ちます。 これらのパターンにより、複数のリソースにわたる処理タスクの分散が可能になり、スケーラビリティと柔軟性が向上します。
コンポーネントを分離します。 アプリケーション コンポーネントの分離は、スケーラビリティのための設計の重要な側面です。 これには、特定のワークロード要件に基づいて独立して動作およびスケーリングできる、より小さな独立したコンポーネントにアプリケーションを分割することが含まれます。 たとえば、需要の増加に伴って 1 つのコンポーネントでより多くのリソースが必要な場合は、他のコンポーネントに影響を与えることなく、そのコンポーネントをスケーリングできます。 この柔軟性により、効率的なリソース割り当てが保証され、ボトルネックが防止されます。 コンポーネントを分離することで、障害を分離し、アプリケーション全体への影響を最小限に抑えることができます。 1 つのコンポーネントが失敗した場合、他のコンポーネントは独立して機能し続けることができます。
分離されたコンポーネントは、保守と更新が容易になります。 1 つのコンポーネントに対する変更や更新は、独立しているため、他のコンポーネントに影響を与えずに行うことができます。 スケーラビリティのためにアプリケーション コンポーネントを分離するには、次のガイドラインに従います。
懸念事項の分離: アプリケーションの責任と機能を特定します。 責任を特定のタスクに基づいて個別のコンポーネントに分割します。 たとえば、ユーザー認証、データ処理、UI 用に個別のコンポーネントがあるとします。
疎結合: 適切に定義されたインターフェイスとプロトコルを介して相互に通信するようにコンポーネントを設計します。 この設計により、コンポーネント間の依存関係が減り、個々のコンポーネントの交換やスケーリングが容易になります。
非同期通信: メッセージ キューやイベント ドリブン アーキテクチャなどの非同期通信パターンを使用して、コンポーネントをさらに分離します。 これらのパターンにより、コンポーネントは独自のペースでタスクを個別に処理でき、全体的なスケーラビリティが向上します。
マイクロサービス: 特定のビジネス機能に重点を置く小規模で独立したサービスであるマイクロサービスの実装を検討してください。 各マイクロサービスは個別に開発、デプロイ、スケーリングできるため、柔軟性とスケーラビリティが向上します。
スケーリングするアプリケーションを設計する
ワークロードをスケーリングするときは、負荷を分散するようにアプリケーションを設計する必要があります。 インフラストラクチャ レベルでレプリカを追加できるからといって、アプリケーションでレプリカを使用できるわけではありません。 スケーリングするアプリケーションの設計は、ワークロードをリソース間で分散することで、増加する需要に対応できるようにアプリケーションを構築することです。 可能であれば、1 つのインスタンスに対してクライアント アフィニティ、データ ロック、または状態アフィニティを必要とするソリューションは避けてください。 使用可能な容量を持つリソースにクライアントまたはプロセスをルーティングする場合。 アプリケーションのスケーラビリティを設計するには、次の戦略を検討してください。
サーバー側のセッション状態を排除します。 可能な場合は、アプリケーションをステートレスに設計する必要があります。 ステートフル アプリケーションの場合は、サーバーの外部にある状態ストアを使用する必要があります。 セッション状態の外部化は、アプリケーション サーバーまたはコンテナーの外部にセッション データを格納する方法です。 セッション状態を外部化してセッション データを複数のサーバーまたはサービスに分散し、分散環境でのシームレスなセッション管理を可能にすることができます。 セッション状態を外部化する場合は、次の点を考慮してください。
セッション要件を評価します。 格納および管理する必要があるセッション データについて理解します。 セッション属性、セッション タイムアウト、およびセッション レプリケーションまたは永続化に関する特定の要件を検討してください。 セッション状態のサイズと、読み取り操作と書き込み操作の頻度を決定します。
ソリューションを選択します。 パフォーマンスとスケーラビリティのニーズに合わせたストレージ ソリューションを選択します。 オプションには、分散キャッシュ、データベース、またはセッション状態サービスの使用が含まれます。 選択するときは、データの一貫性、待機時間、スケーラビリティなどの要因を考慮してください。
アプリケーションを設定する。 選択したセッション状態ストレージ ソリューションを使用するようにアプリケーションを更新します。 外部ストレージ サービスに接続するには、アプリケーションの構成ファイルまたはコードの変更が必要になる場合があります。
ロジックを更新します。 アプリケーションのセッション管理ロジックを変更して、外部ストレージ ソリューションからセッション データを格納および取得します。 セッション状態を管理するには、ストレージ ソリューションによって提供される API またはライブラリを使用する必要がある場合があります。
クライアント アフィニティを排除します。 クライアント アフィニティは、セッション アフィニティまたはスティッキー セッションとも呼ばれます。 クライアント アフィニティを排除すると、クライアントから同じレプリカにすべての要求をルーティングすることなく、複数のレプリカまたはサーバーにクライアント要求を均等に分散できます。 この構成では、使用可能なレプリカで要求を処理できるようにすることで、アプリケーションのスケーラビリティとパフォーマンスを向上させることができます。
負荷分散アルゴリズムを確認します。 負荷分散アルゴリズムを使用すると、1 つのバックエンド インスタンスに送信される要求が多すぎる場合に、意図しない、人工的なクライアントのピン留めが発生する可能性があります。 ピン留めは、常に同じユーザーから同じインスタンスに要求を送信するようにアルゴリズムが設定されている場合に発生する可能性があります。 また、要求が互いに似ている場合にも発生する可能性があります。
データ ロックを排除します。 データ ロックは一貫性を確保しますが、パフォーマンス上の欠点があります。 ロックエスカレーションが発生し、コンカレンシー、待機時間、可用性に悪影響を及ぼす可能性があります。 データ ロックを排除するには、 オプティミスティック コンカレンシーを実装する必要があります。 非リレーショナル データベースでは、 オプティミスティック コンカレンシー制御を 使用し、適切な 整合性レベルを持つ必要があります。 データパーティション分割戦略では、コンカレンシーのニーズもサポートする必要があります。
動的サービス検出を使用します。 動的サービス検出は、分散システム内のサービスを自動的に検出して登録するプロセスです。 これにより、クライアントは、特定のインスタンスに密に結合されることなく、使用可能なサービスを検出できます。 クライアントは、ワークロード内の特定のインスタンスに直接依存することはできません。 これらの依存関係を回避するには、プロキシを使用してクライアント接続を分散および再配布する必要があります。 プロキシは、クライアントとサービスの仲介役として機能し、クライアントに影響を与えずにサービスを追加または削除できる抽象化レイヤーを提供します。
バックグラウンド タスクを使用します。 アプリケーションをスケーリングすると、増加するワークロードまたはより多くの同時実行要求を処理できます。 集中的なタスクをバックグラウンド タスクとしてオフロードすると、メイン アプリケーションは、リソースを集中的に消費する操作を必要とせずに、ユーザー要求を処理できます。 タスクをバックグラウンド タスクとしてオフロードするには、次の手順に従います。
オフロードできるアプリケーションで、CPU を集中的に使用するタスクと I/O 集中型タスクを見つけます。 通常、これらのタスクには、大量の計算や、データベースやネットワーク操作などの外部リソースとの対話が含まれます。
バックグラウンド タスクをサポートするようにアプリケーションを設計します。 集中的なタスクをメインアプリケーション ロジックから切り離し、バックグラウンド タスクを開始および管理するためのメカニズムを提供します。
適切なテクノロジまたはフレームワークを使用してバックグラウンド タスク処理を実装します。 非同期プログラミング、スレッド処理、タスク キューなど、プログラミング言語またはプラットフォームによって提供される機能を含めます。 個別のタスクまたはスレッドに集中的な操作が含まれています。これらのタスクは、同時に実行することも、特定の間隔で実行するようにスケジュールすることもできます。
バックグラウンド タスクの多くがある場合、またはタスクにかなりの時間やリソースが必要な場合は、バックグラウンド タスクを配布します。 考えられる解決策の 1 つについては、競合コンシューマー パターンに関するページを参照してください。
スケーリングを構成する
スケーリングの構成は、ワークロードの需要に基づいてリソースを動的に割り当てるためにパラメーターを設定および調整するプロセスです。 これには、自動スケーリング機能の使用、サービスのスケーリング境界の理解、意味のある読み込みメトリックの実装などの戦略が含まれます。 適切な構成により、アプリケーションはさまざまな要求に対応しながら、効率を最大化できます。 スケーリングを構成する場合は、次の方法を検討してください。
自動スケーリングでサービスを使用する。 自動スケーリング機能は、需要に合わせてインフラストラクチャを自動的にスケーリングします。 組み込みの自動スケーリング機能を備えたサービスとしてのプラットフォーム (PaaS) オファリングを使用します。 PaaS でのスケーリングの容易さは、大きな利点です。 たとえば、仮想マシンをスケールアウトするには、別のロード バランサー、クライアント要求処理、外部に格納された状態が必要です。 PaaS オファリングは、これらのタスクのほとんどを処理します。
自動スケーリングを制限する。 自動スケーリングの制限を設定して、不要なコストが発生する可能性があるオーバースケーリングを最小限に抑えます。 スケーリングの制限を設定できない場合があります。 このような場合は、コンポーネントが最大スケール制限に達し、オーバースケールされたときに通知するようにアラートを設定する必要があります。
サービススケーリングの境界について理解する。 サービスのスケーリングの制限、増分、制限を理解している場合は、サービスを選択するときに、情報に基づいた意思決定を行うことができます。 スケーリング境界は、選択したサービスが予想されるワークロードを処理し、効率的にスケーリングし、アプリケーションのパフォーマンス要件を満たすことができるかどうかを決定します。 考慮すべきスケーリング境界は次のとおりです。
スケーリングの制限: スケーリングの制限は、場所またはサービスが処理できる最大容量です。 これらの制限を把握しておくことは、サービスが予想されるワークロードに対応し、パフォーマンスを低下させることなくピーク使用量を処理できるようにするために重要です。 すべてのリソースには上限があります。 スケール制限を超える必要がある場合は、ワークロードをパーティション分割する必要があります。
スケーリングの増分: サービスは、定義された増分でスケーリングされます。 たとえば、コンピューティング サービスはインスタンスとポッドによってスケーリングされ、データベースはインスタンス、トランザクション ユニット、仮想コアによってスケーリングされる場合があります。 リソースの割り当てを最適化し、リソースのフラッピングを防ぐために、これらの増分を理解することが重要です。
スケーリングの制限: 一部のサービスではスケールアップまたはスケールアウトが可能ですが、自動的にスケールを反転させる機能は制限されます。 手動でスケールインする必要があるか、新しいリソースを再デプロイする必要がある場合があります。 これらの制限は、多くの場合、ワークロードを保護するために行われます。 スケールダウンまたはスケールインは、ワークロードの可用性とパフォーマンスに影響を与える可能性があります。 サービスでは、ワークロードが効果的に動作するのに十分なリソースを確保するのに役立つ、特定の制限または制約が適用される場合があります。 これらの制限は、特に分散システムのデータの一貫性と同期に影響を与える可能性があります。 サービスには、スケールアップまたはスケールアウト中にデータ レプリケーションと整合性を処理するためのメカニズムが用意されている場合がありますが、スケール ダウンまたはスケールインに対して同じレベルのサポートが提供されない場合があります。
意味のある読み込みメトリックを使用します。 スケーリングでは、スケーリング トリガーとして意味のある読み込みメトリックを使用する必要があります。 意味のある読み込みメトリックには、CPU やメモリなどの単純なメトリックが含まれます。 また、キューの深さ、SQL クエリ、カスタム メトリック クエリ、HTTP キューの長さなど、より高度なメトリックも含まれます。 スケーリング トリガーとして、単純な読み込みメトリックと高度な読み込みメトリックの組み合わせを使用することを検討してください。
バッファーを使用します。 バッファーは、需要の急増を処理するために使用できる未使用の容量です。 ワークロードの予期しないスパイクに対する適切に設計されたワークロード 計画。 水平方向と垂直方向のスケーリングのスパイクを処理するバッファーを追加する必要があります。
フラッピングを防ぎます。 フラッピングとは、1 つのスケール イベントが反対のスケール イベントをトリガーし、継続的な前後スケーリング アクションを作成するときに発生するループ条件です。 たとえば、 のスケーリングによってインスタンスの数が減ると、残りのインスタンスで CPU 使用率が上昇し、スケールアウト イベントがトリガーされる可能性があります。 スケールアウト イベントにより、CPU 使用率が低下し、プロセスが繰り返されます。
フラッピングを回避するには、スケールアウトしきい値とスケールインしきい値の間に十分なマージンを選択することが重要です。 CPU 使用率に大きな違いをもたらすしきい値を設定することで、頻繁で不要なスケールインおよびスケールアウトアクションを防ぐことができます。
デプロイ スタンプを使用します。 ワークロードのスケーリングを容易にする手法があります。 デプロイ スタンプ パターンを使用すると、1 つ以上のスケール ユニットを追加することで、ワークロードを簡単にスケーリングできます。
リスク: スケーリングは、需要に合わせて容量を調整することでコストを最適化するのに役立ちますが、高需要の長期間にわたって全体的なコストが増加する可能性があります。
スケーリングのテスト
スケーリングのテストでは、制御された環境のさまざまなワークロード シナリオをシミュレートして、ワークロードがさまざまなレベルの需要にどのように対応するかを評価する必要があります。 これにより、ワークロードが効率的にスケーリングされ、さまざまな負荷の間のパフォーマンス効率が最大化されます。
実際の条件下でワークロードが効率的にスケーリングされるようにする必要があります。 運用環境のセットアップを反映する環境でロード テストとストレス テストを実行することが不可欠です。 非運用環境で行われるこれらのテストを使用すると、垂直方向と水平方向の両方のスケーリング戦略を評価し、パフォーマンスを最も効果的に最適化するものを決定できます。 スケーリングをテストするための推奨されるアプローチを次に示します。
ワークロード シナリオを定義します。 ユーザー トラフィックの増加、同時要求、データ ボリューム、リソースの使用など、テストする必要がある主要なワークロード シナリオを特定します。
運用環境に似たテスト環境を使用します。 インフラストラクチャ、構成、データの観点から運用環境によく似た別のテスト環境を作成します。
パフォーマンス メトリックを設定します。 応答時間、スループット、CPU とメモリの使用率、エラー率など、測定するパフォーマンス メトリックを定義します。
テスト ケースを開発する。 さまざまなワークロード シナリオをシミュレートするテスト ケースを開発し、負荷を徐々に増加させ、さまざまなレベルでパフォーマンスを評価します。
テストの実行と監視。 定義されたテスト ケースを使用してテストを実行し、各ロード レベルでパフォーマンス データを収集します。 ワークロードの動作、リソース消費、パフォーマンスの低下を監視します。
スケーリングを分析して最適化する。 テスト結果を分析して、パフォーマンスのボトルネック、スケーラビリティの制限、または改善のための領域を特定します。 構成、インフラストラクチャ、またはコードを最適化して、スケーラビリティとパフォーマンスを向上させます。 スケーリングが完了するまでに時間がかかるため、スケーリング遅延の影響をテストします。
依存関係に対処します。 潜在的な依存関係の問題を見つけます。 ワークロードの 1 つの領域でスケーリングまたはパーティション分割すると、依存関係のパフォーマンスの問題が発生する可能性があります。 ワークロードのステートフルな部分 (データベースなど) は、依存関係のパフォーマンスの問題の最も一般的な原因です。 データベースでは、水平方向にスケーリングするための慎重な設計が必要です。 データベースのスループットを向上させるために、 オプティミスティック コンカレンシー やデータ パーティション分割などのメジャーを検討する必要があります。
調整後に再テストします。 最適化を実装した後にスケーラビリティ テストを繰り返して、改善点を検証し、ワークロードが予想されるワークロードを効率的に処理できるようにします。
トレードオフ: ワークロードの予算の制約とコスト効率の目標を検討します。 垂直方向のスケーリングでは、より大きく強力なリソースが必要なため、コストが高くなる可能性があります。 水平方向のスケーリングでは、必要に応じて追加または削除できる小さなインスタンスを使用することで、コストを削減できます。
パーティション ワークロード
パーティション分割は、大規模なデータセットまたはワークロードをパーティションと呼ばれる、より管理しやすい小さな部分に分割するプロセスです。 各パーティションには、データまたはワークロードのサブセットが含まれており、通常は個別に格納または処理されます。 パーティション分割により並列処理が可能になり、競合が軽減されます。 ワークロードを小さなユニットに分割すると、アプリケーションは各ユニットを個別に処理できます。 その結果、リソースの使用が向上し、処理時間が短縮されます。 パーティション分割は、複数のストレージ デバイスにデータを分散させ、個々のデバイスの負荷を軽減し、全体的なパフォーマンスを向上させるのにも役立ちます。
パーティション分割について
使用する特定のパーティション分割方法は、使用しているデータまたはワークロードの種類と、使用しているテクノロジによって異なります。 パーティション分割の一般的な方法は次のとおりです。
水平パーティション分割: この方法では、データセットまたはワークロードは、値の範囲や特定の属性など、特定の条件に基づいて分割されます。 各パーティションには、定義された条件を満たすデータのサブセットが含まれています。
垂直パーティション分割: この方法では、データセットまたはワークロードは、特定の属性または列に基づいて分割されます。 各パーティションには列または属性のサブセットが含まれているので、必要なデータに効率的にアクセスできます。
機能パーティション分割: この方法では、実行する必要がある特定の関数または操作に基づいてデータまたはワークロードが分割されます。 各パーティションには、特定の関数に必要なデータまたはコンポーネントが含まれており、最適化された処理とパフォーマンスが可能になります。
パーティション分割を計画する
パーティション分割の際には、データの分散、クエリ パターン、データの増加、ワークロードの要件などの要因を考慮することが重要です。 パーティション分割の有効性を確保し、パフォーマンス効率を最大化するには、適切な計画と設計が不可欠です。 パーティション分割に後から対処する場合は、保守するライブ ワークロードが既に存在するため、より困難です。 データ アクセス ロジックの変更、パーティション間での大量のデータの分散、データ配布中の継続的な使用のサポートが必要になる場合があります。
パーティション分割を実装する
使用するパーティション分割の種類を決定するときは、データの特性、アクセス パターン、コンカレンシー要件、スケーラビリティの目標を分析することが重要です。 パーティション分割の種類ごとに、独自の利点と考慮事項があります。 パーティション分割の種類ごとに考慮すべきいくつかの要因を次に示します。
水平方向のパーティション分割 は、スケーラビリティとパフォーマンスを向上させるために複数のリソースまたはサーバーにデータを分散する場合に適しています。 ワークロードを並列化し、各パーティションで個別に処理できる場合に有効です。 複数のユーザーまたはプロセスがデータセットに同時にアクセスまたは更新できる必要がある場合は、水平方向のパーティション分割を検討してください。
垂直方向のパーティション分割 は、特定の属性または列に頻繁にアクセスする一方で、アクセス頻度が低い場合に適しています。 垂直パーティション分割を使用すると、不要なデータ取得を最小限に抑えることで、必要なデータに効率的にアクセスできます。
関数のパーティション分割 は、異なる関数がデータの異なるサブセットを必要とし、個別に処理できる場合に適しています。 機能パーティション分割では、各パーティションが特定の操作に集中できるようにすることで、パフォーマンスを最適化できます。
パーティション分割をテストして最適化する
パーティション分割スキームをテストして、戦略の有効性と効率を確認して、パフォーマンスを向上させるための調整を行うことができます。 応答時間、スループット、スケーラビリティなどの要因を測定します。 結果をパフォーマンス目標と比較し、ボトルネックや問題を特定します。 分析に基づいて、潜在的な最適化の機会を特定します。 パーティション間でデータを再配布したり、パーティション サイズを調整したり、パーティションの条件を変更したりする必要がある場合があります。
データ スキュー: パーティション分割によってデータ スキューが発生する可能性があります。特定のパーティションでは、他のパーティションと比較して、データまたはワークロードの量が不釣り合いになります。 データ スキューにより、パフォーマンスの不均衡が発生し、特定のパーティションでの競合が増加する可能性があります。
クエリのパフォーマンス: 適切に設計されていないパーティション構成は、クエリのパフォーマンスに悪影響を及ぼす可能性があります。 クエリが複数のパーティション間のデータにアクセスする必要がある場合は、パーティション間の追加の調整と通信が必要になり、待機時間が長くなる可能性があります。
Azure ファシリテーション
スケーリングの最適化。 Azure には、垂直方向と水平方向のスケーリングをサポートするインフラストラクチャ容量があります。 Azure サービスには、SKU と呼ばれるさまざまなパフォーマンスレベルがあります。 SKU を使用すると、垂直方向にスケーリングできます。 Azure のリソースの多くは、自動スケーリングやその他のインプレース スケール オプションをサポートしています。 一部のリソースでは、スケーリング動作の微調整をサポートするために、高度なメトリックまたはカスタム入力がサポートされています。 Azure のほとんどのスケーリング実装では、制限を設定し、変更を警告するために必要な監視機能をサポートできます。
Azure Monitor を使用すると、アプリケーションとインフラストラクチャのさまざまなメトリックと条件を監視できます。 Monitor を使用すると、定義済みのルールに基づいて自動スケーリング アクションをトリガーできます。 たとえば、Azure Kubernetes Service (AKS) では、Monitor を使用して、ポッドの水平自動スケーリング (HPA) とクラスターの自動スケーリングを有効にすることができます。 モニターの監視とアラート機能を使用すると、Azure でのスケーリングを効果的に容易にし、アプリケーションとインフラストラクチャが需要に合わせて動的に調整できるようにします。
Azure でカスタム自動スケーリングを構築することもできます。 アラートは、自動スケーリング機能を持たないリソースの監視で使用できます。 これらのアラートは、クエリベースまたはメトリックベースに設定でき、Azure Automationを使用してアクションを実行できます。 Automation は、Azure、クラウド、オンプレミスの環境全体で PowerShell と Python コードをホストして実行するためのプラットフォームを提供します。 オンデマンドまたはスケジュールに基づいて Runbook をデプロイする、実行履歴とログ記録、統合されたシークレット ストア、ソース管理の統合などの機能を提供します。
スケーリングするアプリケーションの設計: Azure がアプリケーションのスケーリング設計を容易にする方法をいくつか次に示します。
データ ロックの排除: Azure SQL Database では、最適化されたロックを有効にして、厳密な一貫性を必要とするデータベースのパフォーマンスを向上させることができます。
バックグラウンド タスクの使用: Azure では、バックグラウンド ジョブを実装するためのサービスとガイダンスが提供されます。 詳細については、「 バックグラウンド ジョブ」を参照してください。
負荷分散の実装: Azure には、クライアント アフィニティを必要としないロード バランサーが用意されています。 これらのロード バランサーには、Azure Front Door、Azure Application Gateway、Azure Load Balancerが含まれます。
ワークロードのパーティション分割: Azure には、さまざまなデータ ストアに対してさまざまなパーティション分割戦略が用意されています。 これらの戦略は、データを複数のパーティションに分散することで、パフォーマンスとスケーラビリティを向上させるのに役立ちます。 詳細については、「 データ パーティション戦略」を参照してください。
関連リンク
- データをパーティション分割する理由
- 自動スケーリングのベスト プラクティス
- Azure での自動スケーリング機能の概要
- 水平、垂直、および機能データのパーティション分割
- アプリケーション設計に関する考慮事項
パフォーマンス効率のチェックリスト
推奨事項の完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示