スケーリングとパーティション分割を最適化するためのアーキテクチャ戦略

この Azure Well-Architected Framework のパフォーマンス効率チェックリストの推奨事項に適用されます。

このガイドでは、ワークロードのスケーリングとパーティション分割に関する推奨事項について説明します。 スケーリングは、需要に基づいてワークロードに割り当てられたリソースを増減する機能です。 パーティション分割では、ワークロードをより小さく管理しやすい単位に分割して、データと処理を複数のリソースに分散します。 スケーリングやパーティション分割を行わないワークロードでは、需要の高い期間ではパフォーマンスが低下し、低需要期間では使用率が低い容量が発生する可能性があります。

定義

スケーリングとパーティション分割の両方が、リソースが効果的に使用され、ワークロードがさまざまな負荷を処理できるようにすることで、パフォーマンスの効率に貢献します。 これらのプラクティスは、変化する需要に柔軟かつ適応可能なアプリケーションが必要なクラウド環境で特に重要です。 スケーリングにより、増加する需要に合わせてワークロード容量を拡張できます。 パーティション分割を使用すると、タスクまたはデータを効率的に分割して、これらの増大するニーズに対応できます。 これらの両方のプロセスの基礎は、ワークロードのスケール ユニット設計です。 ワークロードの拡大とタスクの分散方法が決まります。 スケーリングとパーティション分割に信頼性の高い制御されたアプローチを組み込むことで、潜在的なワークロードの非効率性を回避できます。

スケーリングの最適化

スケーリングの最適化は、ワークロードの変動する需要に合わせてサーバー、インスタンス、またはリソースの数を調整するプロセスです。 これにより、パフォーマンスの低下やダウンタイムを経験することなく、ワークロードで増加するトラフィックや需要に対応できます。

スケーリング戦略を選択する

スケーリング戦略を選択するには、特定の要件に基づいてワークロードの容量を強化するために、垂直方向または水平方向の方法を決定する必要があります。 適切な戦略を選択すると、過剰な使用や無駄を生じさせることなく、ワークロードの需要に合わせてリソースが効率的に調整されます。 適切なスケーリング戦略を選択するには、垂直方向と水平方向のスケーリングのユース ケースと、それらがワークロードのニーズをどのように満たすかを理解する必要があります。

垂直方向のスケーリングについて理解します。 垂直方向のスケーリングを使用すると、より大きなサーバーまたはインスタンス サイズへのアップグレードなど、1 つのリソースの容量を増やすことができます。 垂直方向のスケーリングは、ワークロードが 1 つのインスタンス内の処理能力、メモリ、またはその他のリソースの増加の恩恵を受けることができる場合に便利です。 垂直方向のスケーリングは、小さな部分に簡単に分割されないワークロードや、アプリケーション アーキテクチャが水平スケーリングをサポートしていない場合に適しています。

水平スケーリングについて理解します。 水平スケーリングを使用すると、インスタンスやリソースを追加して、複数のサーバーにワークロードを分散させることができます。 水平スケーリングには、回復性の向上、容量の増加、トラフィックやワークロードの需要の増加に対処する機能などの利点があります。 これは、複数のノードで実行するように設計されたクラウドネイティブ アプリケーションに効果的です。 水平スケーリングは、独立して実行される小さな部分に分割できるワークロードに適しています。

ワークロードを理解します。 垂直方向または水平方向のスケーリングの適合性は、ワークロードの特定の特性と要件によって異なります。 次の領域での定期的なパフォーマンスの監視とテストは、時間の経過に伴うスケーリング戦略の最適化に役立ちます。

• 要件: リソースの需要、スケーラビリティのニーズ、ワークロードの制限などの要因を考慮して、ワークロードの特定の要件を理解します。

• スケール ユニット: 一緒にスケーリングすることが予想されるコンポーネントのスケール ユニット 設計を作成します。 たとえば、100 台の仮想マシンでは、追加のワークロードを処理するために 2 つのキューと 3 つのストレージ アカウントが必要な場合があります。 スケール ユニットは、100 台の仮想マシン、2 つのキュー、3 つのストレージ アカウントになります。 容量使用の変動が発生するすべてのコンポーネントを個別にスケーリングする必要があります。

• アーキテクチャ: アプリケーション アーキテクチャの設計を評価します。 一部のアプリケーションは、複数のインスタンスに簡単に分散できるステートレス コンポーネントを使用して、水平方向にスケーリングするように本質的に設計されている場合があります。 他のアプリケーションには、垂直方向のスケーリングをより適切にするステートフル コンポーネントまたは依存関係がある場合があります。 ワークロードのスケーラビリティと弾力性の要件を評価します。

スケーリングするインフラストラクチャを設計する

スケーリングするインフラストラクチャの設計は、必要に応じてリソースを追加または調整することで、増加する需要とワークロードに対応できるアーキテクチャを作成するプロセスです。 これには、拡大に対応するために水平方向または垂直方向にスケーリングできるソリューションの計画と実装が含まれます。 戦略には、ボトルネックになる可能性があるシングルトンの回避や、独立したスケーラビリティを確保するためのアプリケーション コンポーネントの分離が含まれます。 ワークロードをスケーラブルに設計すると、ワークロードを複数のリソースに効果的に分散できるため、ボトルネックが回避され、リソース使用率が最大化されます。

シングルトンは避けてください。 ワークロード全体に対して単一の一元化されたリソースを使用しないようにする必要があります。 代わりに、スケーラビリティ、フォールト トレランス、パフォーマンスを向上させるために、ワークロードを複数のリソースに分散します。 ワークロード リソースのシングルトンを回避するために、いくつかの具体的な例と設計上の考慮事項について説明します。

• キューベースの負荷平準化: 1 つのキューに依存してメッセージを処理するのではなく、複数のキューにワークロードをパーティション分割して処理負荷を分散することを検討してください。 スケーラビリティと並列処理が向上します。

• データ処理: シングルトン パターンは、多くの場合、処理がファンアウトしないデータ処理シナリオで使用されます。実行時間の長いタスクを小規模なタスクに分割し、スケーリングを改善して複数のリソースにワークロードを分散し、並列処理を活用できます。

• 設計パターン: ファンアウト/ファンイン、パイプ、フィルターなどの設計パターンは、ワークフロー内のシングルトンを回避するのに役立ちます。 これらのパターンにより、複数のリソースに処理タスクを分散し、スケーラビリティと柔軟性を高めます。

コンポーネントを分離します。 アプリケーション コンポーネントの分離は、スケーラビリティのための設計において重要な側面です。 これには、特定のワークロード要件に基づいて独立して動作およびスケーリングできる、より小さな独立したコンポーネントにアプリケーションを分割することが含まれます。 たとえば、需要の増加により 1 つのコンポーネントに必要なリソースが増えた場合、他のコンポーネントに影響を与えることなく、そのコンポーネントをスケーリングできます。 この柔軟性により、効率的なリソース割り当てが保証され、ボトルネックが回避されます。 コンポーネントを切り離すことで、障害を分離し、アプリケーション全体への影響を最小限に抑えることができます。 1 つのコンポーネントで障害が発生した場合、他のコンポーネントは引き続き独立して機能できます。

分離されたコンポーネントは、保守と更新が容易になります。 1 つのコンポーネントに対する変更や更新は、独立しているため、他のコンポーネントに影響を与えずに行うことができます。 スケーラビリティのためにアプリケーション コンポーネントを分離するには、次のガイドラインに従います。

• 懸念事項の分離: アプリケーションの責任と機能を特定します。 特定のタスクに基づいて、責任を個別のコンポーネントに分割します。 たとえば、ユーザー認証、データ処理、UI 用に個別のコンポーネントがあるとします。

• 疎結合: 明確に定義されたインターフェイスとプロトコルを介して相互に通信するようにコンポーネントを設計します。 この設計により、コンポーネント間の依存関係が軽減され、個々のコンポーネントの交換やスケーリングが容易になります。

• 非同期通信: メッセージ キューやイベント ドリブン アーキテクチャなどの非同期通信パターンを使用して、コンポーネントをさらに分離します。 これらのパターンにより、コンポーネントは独自のペースで個別にタスクを処理でき、全体的なスケーラビリティが向上します。

• マイクロサービス: 特定のビジネス機能に重点を置く、小規模で独立したサービスであるマイクロサービスの実装を検討します。 各マイクロサービスを個別に開発、デプロイ、スケーリングできるため、柔軟性とスケーラビリティが向上します。

スケーリングするアプリケーションを設計する

ワークロードをスケーリングするときは、負荷を分散するようにアプリケーションを設計する必要があります。 インフラストラクチャ レベルでレプリカを追加できるからといって、アプリケーションでレプリカを使用できるわけではありません。 スケーリングするアプリケーションの設計は、リソース間でワークロードを分散することで、増加する需要に対応できるようにアプリケーションを構築することです。 可能であれば、1 つのインスタンスに対してクライアント アフィニティ、データ ロック、状態アフィニティを必要とするソリューションは避けてください。 使用可能な容量を持つリソースにクライアントまたはプロセスをルーティングする場合。 アプリケーションのスケーラビリティを設計するには、次の戦略を検討してください。

サーバー側のセッション状態を排除します。 可能な場合は、アプリケーションをステートレスに設計する必要があります。 ステートフル アプリケーションの場合は、サーバーの外部にある状態ストアを使用する必要があります。 セッション状態の外部化は、アプリケーション サーバーまたはコンテナーの外部にセッション データを格納する方法です。 セッション状態を外部化して複数のサーバーまたはサービスにセッション データを分散し、分散環境でのシームレスなセッション管理を可能にすることができます。 セッション状態を外部化する場合は、次の点を考慮してください。

• セッション要件を評価します。 保存および管理する必要があるセッション データについて説明します。 セッション属性、セッション タイムアウト、およびセッション レプリケーションまたは永続化に関する特定の要件を考慮してください。 セッション状態のサイズと、読み取り操作と書き込み操作の頻度を決定します。

• ソリューションを選択します。 パフォーマンスとスケーラビリティのニーズに合ったストレージ ソリューションを選択します。 オプションには、分散キャッシュ、データベース、またはセッション状態サービスの使用が含まれます。 選択するときは、データの整合性、待機時間、スケーラビリティなどの要因を考慮してください。

• アプリケーションを設定します。 選択したセッション状態ストレージ ソリューションを使用するようにアプリケーションを更新します。 外部ストレージ サービスに接続するには、アプリケーションの構成ファイルまたはコードの変更が必要になる場合があります。

• ロジックを更新します。 外部ストレージ ソリューションからセッション データを格納および取得するように、アプリケーションのセッション管理ロジックを変更します。 場合によっては、ストレージ ソリューションによって提供される API またはライブラリを使用して、セッションの状態を管理する必要があります。

クライアント アフィニティを排除します。 クライアント アフィニティは、セッション アフィニティまたはスティッキー セッションとも呼ばれます。 クライアント アフィニティを排除すると、クライアントから同じレプリカにすべての要求をルーティングすることなく、複数のレプリカまたはサーバーにクライアント要求を均等に分散できます。 この構成では、使用可能なレプリカで要求を処理できるようにすることで、アプリケーションのスケーラビリティとパフォーマンスを向上させることができます。

負荷分散アルゴリズムを確認します。 負荷分散アルゴリズムを使用すると、1 つのバックエンド インスタンスに送信される要求が多すぎる場合に、意図しない、または人為的なクライアントのピン留めが発生する可能性があります。 ピン留めは、同じユーザーから同じインスタンスに常に要求を送信するようにアルゴリズムが設定されている場合に発生する可能性があります。 また、要求が互いに類似しすぎる場合にも発生する可能性があります。

データ ロックを排除します。 データ ロックは一貫性を確保しますが、パフォーマンス上の欠点があります。 ロックのエスカレーションが発生し、コンカレンシー、待機時間、可用性に悪影響を及ぼす可能性があります。 データ ロックを排除するには、 オプティミスティック コンカレンシーを実装する必要があります。 非リレーショナル データベースでは 、オプティミスティック コンカレンシー制御 を使用し、適切な 整合性レベルを持つ必要があります。 データパーティション分割戦略では、コンカレンシーのニーズもサポートする必要があります。

動的サービス検出を使用します。 動的サービス検出は、分散システムでサービスを自動的に検出して登録するプロセスです。 これにより、クライアントは、特定のインスタンスに密に結合されることなく、使用可能なサービスを検出できます。 クライアントは、ワークロード内の特定のインスタンスに直接依存することはできません。 これらの依存関係を回避するには、プロキシを使用してクライアント接続を分散および再配布する必要があります。 プロキシは、クライアントとサービスの仲介役として機能し、クライアントに影響を与えずにサービスを追加または削除できる抽象化レイヤーを提供します。

バックグラウンド タスクを使用します。 アプリケーションをスケーリングすると、増加するワークロードまたはより多くの同時要求を処理できます。 集中型タスクをバックグラウンド タスクとしてオフロードすると、メイン アプリケーションはリソースを大量に消費する操作を必要とせずにユーザー要求を処理できます。 タスクをバックグラウンド タスクとしてオフロードするには、次の手順に従います。

1. オフロードできるアプリケーションで、CPU を集中的に使用するタスクと I/O 集中型タスクを見つけます。 通常、これらのタスクには、大量の計算や、データベースやネットワーク操作などの外部リソースとの対話が含まれます。

2. バックグラウンド タスクをサポートするようにアプリケーションを設計します。 集中的なタスクをメイン アプリケーション ロジックから切り離し、バックグラウンド タスクを開始および管理するためのメカニズムを提供します。

3. 適切なテクノロジまたはフレームワークを使用してバックグラウンド タスク処理を実装します。 非同期プログラミング、スレッド処理、タスク キューなど、プログラミング言語またはプラットフォームによって提供される機能を含めます。 個別のタスクまたはスレッドに集中的な操作を含めます。これらのタスクは、同時に実行することも、特定の間隔で実行するようにスケジュールすることもできます。

4. バックグラウンド タスクの多くがある場合、またはタスクにかなりの時間またはリソースが必要な場合は、分散します。 考えられる 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) とクラスターの自動スケーリングを有効にすることができます。 Monitor の監視とアラート機能を使用すると、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 の自動スケール機能の概要
• 水平、垂直、および機能データのパーティション分割
• アプリケーションの設計に関する考慮事項

パフォーマンス効率チェックリスト

推奨事項の完全なセットを参照してください。