翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

負荷を軽減する

応答時間を改善し、重要なワークフローに利用できるリソースを増やすには、無関係な負荷を取り除くことが必要になる場合があります。このセクションで取り上げるソリューションの多くは、トレードオフによる意思決定を伴います。これらはアプリケーションに影響を及ぼすため、慎重に検討する必要があります。以下の状況でこのソリューションを使う場合について検討してみましょう。

すぐに行うべき変更には、以下が含まれます。

上記のアクションを実行するときは、事前に、長期的なビジネス目標とリスクをふまえた評価を行います。

読み取りと書き込みのワークロードを分離する

MySQL を搭載したアプリケーションを実行するときの一般的なテクニックが、読み取りオペレーションをライター (プライマリ) データベースインスタンスから、1 つまたは複数の読み取り専用データベースレプリカにオフロードする方法です。読み取りオペレーションをオフロードすれば、プライマリデータベースインスタンスの全体的な負荷を軽減し、書き込み用にスペースを空けることができます。必ず、レプリカの書き込み直後の読み取り整合性に依存していない読み取りのみを対象にします。より効率的な方法は、すべての読み取りトラフィックをレプリカに移行し、レプリケーションが遅れた場合に書き込み後の読み取りを再試行するよう計画を立てることです。オフロード可能な独立した読み取りワークロードには、例えばレポートサービスなどがあります。他の読み取りでは、アプリケーションレベルでの変更が必要になります。ここでは、読み取りが発行された理由の背景事情は判明しています。

もう 1 つの方法は、アプリケーションとデータベースの仲介役としてデータベースプロキシソリューションを実装する方法です。これにより、アプリケーションを意識することなく、読み取り/書き込みの分割とクエリルーティングの機能を提供できます。MySQL 互換のプロキシソリューションを利用できる製品には、ProxySQL、MariaDB MaxScale、ScaleArc、Heimdall Data などがあります。これらの製品では、キャッシュや接続の多重化など複数の追加機能を利用できます。トラフィックが突然増加したときや、アプリケーションスタックに新しいテクノロジーを実装するときは、読み取り/書き込みクエリを分割する基本機能から使い始め、予期せぬ影響を引き起こす可能性のある追加機能は、基本機能の動作とパフォーマンスをテストした後に使用するとよいでしょう。

古いデータをアーカイブするか削除する

データベースのパフォーマンスを向上させるもう 1 つのテクニックが、過去のデータを別のテーブルか、データベース、または Amazon Simple Storage Service (Amazon S3) にオフロードする方法です。多くのデータベースが、アプリケーションの全履歴のデータをインラインで保持しています。一般的なユーザー向けアプリケーションでは、これのおかげでユーザーは自分の注文履歴をすべて閲覧することができます。需要が突然増加した場合、そのアプリケーションを利用しているユーザーの多くは、新規ユーザーか、新たに注文するために殺到したユーザーであると考えられます。履歴データが、数十億の行を含む単一のテーブルにオンラインで保存されていると、状況はいっそう悪化します。また、このテーブルには大量のインデックスが含まれている可能性があります。テーブルデータとインデックスは共にツリー構造で保存されます。テーブル内のエントリが増えるとツリーのレベルも増えることになり、行にアクセスするには、より多くの I/O オペレーションが必要になります。これにより、個々のレコードを検索するためのアクセス時間が長くなります。さらに重要なこととして、インデックスの大量の不要な要素がデータベースページキャッシュに滞留する原因となります (InnoDB バッファプール)。

古いデータを別のテーブル、別のデータベース、あるいは Amazon S3 にアーカイブすれば、エンドユーザーのアクセス時間を短縮でき、貴重なキャッシュを解放でき、アプリケーション全体のパフォーマンスを改善することができます。イベント前に古いデータをアーカイブすると (30 日のみまたは 90 日のみ保存するなど)、重要なテーブルの、テーブルとインデックスの容量が制限されます。この変更により、二次的な場所からの古いデータのクエリは、履歴データの閲覧を明示的に要求する一部のユーザーのみとするよう、アプリケーションを変更することが必要になります。

重要でない ETL プロセスを延期する

メインのデータベースシステムから ETL プロセスを抽出すると、ハイパースケール中に、トランザクションの多いワークロードや同時実行ワークロードの安定性が損なわれる可能性があります。ETL のプロセスには次のような特徴があります。

変動したり予測不能だったりする ETL プロセス (INSERT INTO ... SELECT FROM ...;) のようなクエリなど) は、負荷と競合の全体的な変動性を高め、安定上のリスクを高めます。

可能な場合は、重要な機能を果たしていない場合は特に、ETL プロセスの実行を遅らせるか実行頻度を減らします。重要な ETL プロセスについては、固定された行数でバッチ処理したり(LIMIT 句を使用するなど)、個別のトランザクションを使用したり、少量のデータを長期間プルして DB インスタンスのピーク時のリソース需要を減らしたりするなど、制限のある作業単位で実行するように修正します。

重要度の低いアプリケーションの機能をオフにする

急増するリクエストに対処するときは、ユーザーエクスペリエンスのグレードを適切に下げたり、最重要ではない機能を削除したりすると、データベースリソースを節約し、重要な機能に振り向けることができます。そのためには、カスタマーエクスペリエンスを若干変更する必要があるかもしれませんが、サイトがダウンするよりは別のフローの方が良いでしょう。データベース呼び出しを常に行うサイトのフロントページで、パーソナライゼーションを一時的に無効にしてもよいかもしれません。あるいは、ユーザーが製品を選んでいる間はリピーター専用のオファーの表示を停止するという方法もあります。機能を一時的にオフにすると、データベースにアクセスしなくてもページをキャッシュしたり配信したりできるようになります。

その他の例として、データベース呼び出しを必要とするデータ変更をチェックする、ポーリングのメカニズムを備えたフロントエンドがあります。ポーリングの頻度を減らすと、すぐにデータベース呼び出しの回数が減ります。ページ分割が必要なユーザーインターフェースや、ソートされた結果セットを上位の検索結果から遠く離れて取得するオプションを提供しているユーザーインターフェースでは、データベース呼び出しのコストは徐々に高くなります。最も高額なデータベース呼び出しからデータベースを保護するには、結果セットのページ数を制限します。アプリケーション層で機能フラグを使用すると、アプリケーションまたはデータベースの負荷が増加したときに、オペレーションチームが機能を無効にしたり、グレードを下げたりできるようになります。