翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
接続の管理
アプリケーションの需要が高まると、フロントエンドのトラフィックが増加します。一般的なシナリオでは、こうした受信トラフィックの爆発的増加に対処する場合、アプリケーション層に自動スケーリングが設定されます。それにより、アプリケーション層は自動スケーリングを開始し、トラフィックの増加に対応するためにアプリケーションサーバー (インスタンス) がさらに追加されます。すべてのアプリケーションサーバーでは、データベース接続プールの設定が事前に完了しているため、データベースが受信する接続の数は、新たにデプロイされたインスタンスの数に比例して増加します。
例えば、データベース接続の件数が 200 件ずつに設定されているアプリケーションサーバーが 20 台ある場合、合計 4,000 件のデータベース接続がオープンすることになります。アプリケーションプールが 200 インスタンスまでスケールアップされると (ピーク時など)、接続の合計数は 40,000 件に達します。一般的なワークロードでは、こうした接続の大半はアイドル状態である可能性が高いです。ただし、接続が突然増加すると、Amazon Aurora MySQL 互換エディションのデータベースのスケーリング能力が制限されることがあります。これは、接続がアイドル状態であっても、メモリや、ファイル記述子などのその他のサーバーリソースが使用されるためです。Aurora MySQL 互換が使用するメモリの量は、通常、同じ数の接続を維持するため MySQL Community Edition よりも少なくなります。ただし、接続がアイドル状態のときのメモリ使用量は、やはりゼロではありません。
設定変数
2 つの主要なサーバー設定変数、max_connections と max_connect_errors を使用すると、データベースに許可される受信接続の数を制御することができます。
設定変数 max_connections
設定変数 max_connections は、各 MySQL インスタンスのデータベース接続の上限数を設定します。ベストプラクティスは、各データベースインスタンスでオープンすることが見込まれる接続の最大数より、若干高めに設定しておくことです。
併せて performance_schema も有効にする場合は、max_connections 設定に特に注意が必要です。Performance Schema のメモリ構造は、サーバー設定変数 (max_connections など) に基づいて自動的にサイズが設定されます。変数を高く設定すれば Performance Schema が使用するメモリの量も増えます。極端な場合、それによって小規模なインスタンスタイプでメモリ不足の問題が生じる可能性があります。Performance Insights を有効にすると Performance Schema が自動的に有効になることに注意してください。
設定変数 max_connect_errors
設定変数 max_connect_errors は、所定のクライアントホストからの、連続して中断した接続リクエストを、何件許可するかを決定します。クライアントホストが、失敗した接続試行の、指定された連続回数を超えると、サーバーはその接続を遮断します。そのクライアントからさらに接続しようとするとエラーが発生します。
Host 'host_name' is blocked because of many connection errors. Unblock with
'mysqladmin flush-hosts'
「ホストがブロックされている」エラーが発生した場合は、 max_connect_errors変数の値を増やさないでください。代わりに、aborted_connects ステータス変数と host_cach テーブルにあるサーバーの診断カウンターを調べます。そこで収集した情報を使って、接続の問題が発生しているクライアントを特定し、修正します。また、このパラメータは、skip_name_resolve が 1 (デフォルト) に設定されている場合は無効になるため注意しましょう。
以下に関する詳細は、MySQL のリファレンスマニュアルを参照してください。
接続プールを実装する
スケーリングイベントによってアプリケーションサーバーが増えると、その結果、DB サーバーが、完全にロードされたアクティブな接続件数を超える可能性があります。アプリケーションサーバーとデータベースの間に接続プールまたはプロキシレイヤーを追加すると、ファネルのように機能して、データベース上の接続の合計数が減少することになります。プロキシの主な目的は、多重化を用いてデータベース接続を再利用することです。
プロキシは、一方では接続数が制限されているデータベースに接続します。もう一方では、アプリケーションの接続を受け入れます。また、クエリキャッシュ、接続バッファリング、クエリの書き換えとルーティング、ロードバランシングなどの追加機能も提供します。接続プール層は、データベースへの最大接続数が完全にロードされたときの数を下回るように設定する必要があります。Amazon RDS Proxy
Aurora MySQL 互換で使用できる以下のサードパーティーのプロキシもご覧ください。
コネクションストームを回避する
データベースのオーバーロードや、レプリカのプライマリノードからの大幅な遅れなどが発生した場合に、接続プールをどのように機能させるかを検討します。プロキシサーバーや接続プールを設定するときは、データベースの応答が遅いこと (基盤となるハードウェアかストレージの問題または DB リソースの制約が原因) を理由に、接続プール全体をリセットすることのないようにします。
突然、何百件もの接続が開始されると、データベースへの接続を求める大量のリクエストがすべて同時に接続を始めることになるため、コネクションストームが発生します。コネクションストームはリソースを大量に消費します。MySQL で新しいデータベース接続を作成することは、コストのかかる操作です。バックエンドで初回のハンドシェイクのために複数のネットワークパケットを交換したり、新しいプロセスを生成したり、メモリを割り当てたり、認証を処理したりするためす。短時間のうちに大量のリクエストが届くと、データベースが応答していないように見えることがあります。
MySQL には、こうした急激な接続リクエストに対処するためのメカニズムがあります。back_log 変数は、MySQL が新規リクエストへの応答を一時的に停止するまでの、短時間の間にスタックできるリクエストの数に設定することができます。この値は接続処理スレッドによって適用されるため、スレッドそれ自体がコネクションストームに対応できなくなる可能性があります。詳細については、「MySQL リファレンスマニュアル
データベースの動作が遅いときはリセットするように接続を設定しておくと、このサイクルが何度も繰り返されます。同様に、日中の特定の時間帯 (株式市場の開始直後など) にデータベーストラフィックの急増が予想される場合は、接続プールを事前に実行しておき、トラフィックの負荷の急増と、多数の接続のオープンが同時に発生しないようにします。
