MySQL Governor：個々のホスティング顧客のデータベースリソースを制限する

MySQL Governor が制限する内容

MySQL ガバナー これは、共有ホスティングサーバー向けのCloudLinuxコンポーネントであり、MySQLの一般的な機能ではありません。割り当てられたユーザーに基づいてデータベースの負荷を計測し、閾値を超えた場合に、Lightweight Virtual Environments（略称：LVE）を通じてクエリを制限することができます。 これにより、データベースサーバーの総負荷量だけを見るよりも、個々のホスティングアカウントごとの負荷をより詳細に把握することが可能になります。

焦点は CPUとハードディスクのI/O: ガバナーは、計算負荷および読み取り・書き込みのアクティビティを監視します。利用率が高くなる原因としては、インポート処理や頻繁に行われるショップのクエリなどが挙げられます。アカウントへの割り当てにより、この利用状況が可視化されますが、それが当該処理にとって適切かどうかは、その後、状況に応じて判断する必要があります。

これらのリソースに対するデータベース制限は、ストレージ容量の割り当てではありません。大規模で利用頻度の低いデータベースは、実行中のCPUやI/Oへの負荷をほとんど生じさせない場合があります。逆に、小規模なデータベースであっても、処理負荷の高いアクセスが頻繁に行われると、リソースに大きな負荷がかかることがあります。 また、接続制限も別の目的を果たしています。接続制限はアクセス数を制限するものではありますが、CPUやI/Oの制御を自動的に置き換えるものではありません。

クエリが制限されたからといって、必ずしもそれが誤りであるとは限りません。この制限は、他のアカウントを高い負荷から保護する一方で、正当なアプリケーションの処理を遅くしてしまうこともあります。データベースサービス、ハードウェア、その他のアプリケーションコンポーネントは、依然としてシステムの共有リソースであるため、応答時間が保証されるわけではありません。

勘定科目、仕訳、およびLVEの相互関係を理解するために、以下の補足的な概要が参考になります。 CloudLinux MySQL Governor によるデータベース負荷の抑制 別の入り口。具体的な設定においては、実際に構築された環境と、そこで適用されている設定が依然として決定的な要素となります。

エディションと互換性を確認する

データベースの制限を計画する前に、まず以下を確認してください 版とライセンス. メーカーによると、CloudLinux OS Admin には MySQL Governor は含まれていません。したがって、CloudLinux システムが導入されているという事実だけでは、選択したエディション向けに当該コンポーネントが利用可能であり、ライセンスが取得されており、サーバーにインストールされていることを証明するものではありません。

次に、CloudLinuxのバージョン、ガバナー・パッケージ、およびデータベースサーバーの組み合わせを確認します。MySQLとMariaDBは別々の開発ブランチであるため、MySQLのサポート対象バージョンが、同じ条件下で同バージョンのMariaDBが動作することを保証するものではありません。 また、使用しているコントロールパネルとその統合状況についても確認する必要があります。

最低要件を見ると、一律の承認では不十分な理由がわかります。MySQL 8.4 の場合、CloudLinux は MySQL Governor 1.2-129 以上を必須としています。 MariaDB 11.4 には、Governor のバージョン 1.2-122 以上が必要ですが、メーカーのドキュメントでは CloudLinux OS 7 でのサポートは記載されていません。これらの情報は記載されたブランチに関するものであり、その他の組み合わせの確認に代わるものではありません。

メーカーが挙げているインストール環境には、cPanel、Plesk、DirectAdmin、ISPmanager、InterWorxのほか、コントロールパネルなしのサーバーなどが含まれます。これとは異なるパネルや、独自に統合したパネルを使用する場合は、具体的なサポート内容、特にユーザー割り当てについて別途確認する必要があります。 記載されているデータベースのバージョンが、すべてのコントロールパネルとOSの組み合わせで動作することを保証するものではありません。

変更を行う前に、現在のバージョンとパッケージを確認し、計画している目標構成に関するドキュメントと照らし合わせてみてください。そうすることで、データベース名だけに基づいて既存のインストールが互換性があると判断するのではなく、まずコンポーネントの変更が必要かどうかを見極めることができます。

データベースユーザーをホスティングアカウントに割り当てる

負荷をホスティング顧客に割り当てるためには、データベースユーザーとホスティングアカウントとの関連付けが正しく設定されている必要があります。パネル統合の場合、このために通常はファイル /etc/container/dbuser-map 管理されています。ガバナーは、統合ドキュメントに従って、この割り当ての変更を5分以内に反映します。

例を挙げましょう。あるホスティングアカウントで、オンラインショップと別のブログを運営しており、それぞれが独自のデータベースユーザーを使用しています。両方のユーザーが同じアカウントに割り当てられている場合、そのアカウントに対するデータベースの負荷を計測することができます。 いずれかのエントリが欠落しているか、あるいは誤ったアカウントを指している場合、表示される割り当ては顧客別の評価において信頼性のあるものとは言えません。

次の項目を確認してください ユーザーの割り当て したがって、これは初期インストール時だけのことではありません。データベースやユーザーの作成・移動後も、パネルは割り当てを正しく更新し続ける必要があります。変更直後に確認を行う際は、記録されている反映時間を考慮した上で、古い状態のまま「恒久的なエラー」と結論づけないようにしてください。

特に重要なのは、「Abusers」モードにおけるマッピングの欠如です。メーカーによると、このモードでは「Single」モードがエミュレートされるそうです。「Single」モードでは、制限対象のクライアントは、それぞれ独自のクライアントLVE内で制限されるのではなく、共通の制限付きLVEを共有することになります。 したがって、Abusersモードが有効になっているという事実だけでは、意図されたアカウントごとの制限が実際に適用されていることを証明するものではありません。

異常が検出された場合は、影響を受けるデータベースユーザー、設定済みのマッピング、および選択された運用モードを相互に照合してください。 マッピングが正しく行われていても、完全な分離が保証されるわけではありません。データベースサービスと基盤となるハードウェアは、引き続き共有されます。このマッピングは、顧客ごとのきめ細かな制御のための前提条件であり、キャパシティプランニングの代わりとなるものではありません。

動作モードの比較

動作モードによって、MySQL Governorがデータベースの負荷を単に監視するだけなのか、それとも制限された環境内でクエリを実行するのかが決まります。選択にあたっては、しきい値だけが重要なのではありません。データベースユーザーの割り当てや、どのクライアントが1つのLVEを共有するかといった点も、その効果に影響を与えます。

現状把握には、次のような方法が適しています オフ 注：観測された利用状況から、ガバナーがクエリを制限することなく、どのアカウントや期間をより詳細に調査すべきかがわかります。ただし、単一の瞬間的な高値だけでは、そのアカウントが恒常的に大きな負荷を発生させているのか、それとも正当なメンテナンス作業を行っているのかは判断できません。

時点では アブザーバー 制限されたデータベースクエリは、LVEのリソース予算を、同じアカウント内の他のプロセス（PHPなど）と共有します。そのため、制限によってクエリ時間が長引くだけでなく、プロセスが同じ限られたリソースを奪い合うことで、アプリケーションの応答速度が低下する可能性もあります。 逆に、すでに使用中のPHPリソース予算が、データベースの処理に影響を与える可能性もあります。

「Single」は時代遅れであり、主に既存の構成や、文書化されている代替動作に関連しています。つまり、複数の制限付きクライアントが1つの環境を共有し、そこで互いに競合する可能性があります。dbuser-mapが存在しない場合、Abusersがこの動作をエミュレートします。そのため、選択された設定のみからは、クライアント固有の制限があるとは判断できません。 また、「All」も非推奨となっており、新規インストールにおける標準的な推奨設定ではありません。

データベースの制限と時間枠の計画

MySQL Governor は、CPU 使用率と読み取り・書き込み I/O を区別します。ドキュメントに記載されている CLI では、CPU 使用率はパーセントで、I/O は MB/s で表示されます。読み取りと書き込みについては、それぞれ個別の値を設定できます。 これらの指標は異なる負荷を表しています。つまり、計算負荷の高い処理であっても、必ずしもストレージへの書き込み量が特に多いとは限りません。

敷居 current、short、middle、long 短期および長期にわたる使用状況を考慮しています。これらの値を超過すると、動作モードや構成に応じて制限が適用されます。これらは、保証されたスループットでもなければ、互いに独立して恒久的に厳格に適用される4つの性能保証でもありません。 実際にどの制限が適用されるかは、選択された方式やLVEリミットにも依存します。

インポートの例を見ると、その違いが明らかになります。書き込み負荷が一時的に上昇した後、再び低下する場合は、予定された処理の一環である可能性があります。一方、長時間にわたって高い状態が続く場合は、インポートがリソースを長時間占有していることになります。 判断にあたっては、ピーク値に加え、どのリソースが影響を受けているか、処理にどれくらいの時間がかかるか、そしてそれが繰り返し発生しているかを確認する必要があります。

低い 発動基準値 他の顧客を長期にわたる負荷から早期に保護できる一方で、正当なインポートやメンテナンス作業を妨げる可能性もあります。閾値を高く設定すると、こうした作業に余裕が生まれますが、同時に高い負荷が長期間続くことになります。恒久的な例外を設けるよりも、メンテナンスウィンドウを設けたり、意図的に計画された容量を確保したりする方が合理的である場合があります。

LVEリミットおよび実際に提供されている料金プランとのバランスを考慮して、ガバナー値を計画してください。 メーカーの推奨事項はこの関係を明確に考慮していますが、そこから普遍的に適用できる生産値を導き出すことはできません。観測された要求負荷、クエリ効率、および顧客業務の性質が、導入後に閾値を管理しながら調整するための基礎となります。

導入と料金上限の設定

インストールやアップグレードを行う前に、 データベースの完全バックアップ システムテーブルも含む。また、必要に応じてどのように復元を行うかについても計画を立てておくこと。メーカーは、データベースパッケージはCloudLinuxのリポジトリから更新できると指摘している。したがって、パッケージの変更は、インストール後に初めて確認すべきような、何の影響もない副次的な事象ではない。

その後、CloudLinuxのエディションとバージョン、ライセンス、データベースブランチ、ガバナーパッケージ、およびコントロールパネルの組み合わせを確認してください。サポート対象のデータベースバージョンがあるからといって、これらのコンポーネントのあらゆる組み合わせがサポートされているとは限りません。パッケージのバージョンやパネルとの統合に不整合がある場合は、作業に着手する前に具体的なサポート状況を確認する必要があります。

技術的な準備が完了したら、すぐに処理を制限するのではなく、まずは監視から始めましょう。 通常の営業時間と、既知のデータインポートやメンテナンスの時間帯を照らし合わせ、データベースユーザーが正しいホスティングアカウントに割り当てられているかを確認してください。確実な割り当てが行われていない場合、一見低いアカウント負荷から、実際のリソース要件を確実に推測することはできません。

この現状把握をもとに、限定的な導入計画を立ててください。対象となるアカウントや料金プランを特定し、苦情の受付方法を定め、どのような観察結果に基づいて設定を確認するかを明確にしてください。導入後は、制限値を超えたケースをすべて即座に不正行為とみなすのではなく、実際の運用状況と照らし合わせて確認してください。

CloudLinux Manager では、パケット単位でガバナー制限を管理できます。個々の顧客ごとに、これとは異なる値が適用される場合があります。そのため、変更を行うたびに、以下の内容を記録してください。 制限の由来: これはパッケージに組み込まれているものですか、それとも個別に設定されたものですか？そうすることで、後でどの顧客が料金プランの変更の対象となるか、またどの例外ケースを個別に確認する必要があるかを把握できるようになります。

現在の負荷と履歴を確認する

診断には、以下の両方が必要です。 スナップショット および時間的な推移についても確認できます。以下のコマンドは、MySQLコンソールではなく、CloudLinuxサーバーのターミナルで実行されます。これらは確認用であり、制限値を変更するものではありません。適切な分析を行うには、それぞれのツールをインストールし、関連するデータが利用可能である必要があります。

「」で同じ目立つ口座を ユーザーの割り当て および選択された動作モードによって異なります。マッピングにデータベースユーザーが含まれていない場合、ホスティングアカウントの可視負荷が不完全になる可能性があります。統合ドキュメントでは、マッピングファイルの変更が反映されるまで5分程度かかると記載されています。そのため、変更直後に確認した出力には、まだ新しい状態が反映されていない可能性があります。

その後、制限が適用された時点と、観察された使用状況とを照らし合わせて確認してください。個別の数値が高い場合でも、インポートに起因する可能性があり、それ自体では恒常的な過剰使用の証拠とはなりません。その MySQLガバナーレポートの読み方ガイド 表示されている指標の分類を補足する。

流量制限とその原因の見分け方

ウェブサイトの動作が遅くなった場合は、まずその時点で制限が適用されていたかどうか、またどのような理由が表示されているかを確認してください。この結果を具体的な状況と照らし合わせてください。チェックアウトの遅延と、同時に実行されているインポートには関連性がある可能性もありますが、必ずしもそうとは限りません。 時間的な一致がなければ、ガバナーを唯一の原因として早計に断定することになります。

「Abusers」モードでは、割り当てられたアカウントのLVE内で制限付きのデータベースクエリが実行されます。そこで、それらは 資源予算 PHPなどの他のアカウント処理プロセスとの競合。したがって、不具合が発生した場合は双方の側面を考慮してください。データベースを多用する処理がPHPとリソースを奪い合う可能性があります。逆に、すでに使用されているLVEの容量が、制限されたクエリに影響を与える可能性もあります。

ショップ機能で負荷が繰り返し発生する場合は、該当するクエリとその 照会計画 適切なデータベース統計情報と併せて。インデックスの欠如や不適切さは考えられる原因の一つですが、唯一の原因ではありません。制限をかけることで、共有リソースへの影響を軽減することはできますが、実行計画やアプリケーションのロジックそのものを修正するものではありません。

CloudLinuxによると、シングルおよびアブザーバーの場合、使用量がしきい値を下回ってから1分経過すると制限が解除されるとのことです。ただし、一時的な負荷の軽減を理由に、すぐに恒久的な解決策であると結論づけるのではなく、実際に設定されている制限処理と、自身のシステムにおける時間的な推移を必ず確認してください。 再起動したタスクが、後で再び閾値を超える可能性があります。

制限値の再調整またはアーキテクチャの変更

調整を行う際は、まず、観測されたピークが予想されるタスクに起因するものか、それとも定期的に運用に支障をきたしているものかを検討することから始めます。 予定されているインポートは、メンテナンス時間帯に延期できる可能性があります。その際、単発の変動から恒久的な料金体系の変更を導き出す前に、所要時間、影響を受けるリソース、およびアプリケーションへの影響を把握してください。

その時間枠では不十分な場合は、的を絞った 賃金協定の例外 すべての顧客に対して一律に上限を引き上げるよりも、より適切な対応となる場合があります。再検討の理由、担当窓口、および再検討の実施日時を記録してください。また、現在の上限値がパッケージに由来するものか、個別に設定されたものかも明記してください。CloudLinux Manager は、パッケージごとの制限値と個別の例外設定の両方をサポートしています。

変更後は、一定期間にわたって、対象となる処理がよりスムーズに実行されるようになったか、また他の箇所で制約や不具合が発生していないかを確認してください。その際、ガバナーのしきい値をLVEの制限値と照らし合わせて検討してください。 しきい値を高く設定すると、潜在的により長い時間、より多くの負荷を許容できるようになりますが、これはスループットの保証でも、特定の応答時間を約束するものでもありません。

もう一つの調整要素は、 原因の解消: クエリの最適化、適切なインデックスの設定、あるいはキャッシュを活用することで、繰り返し発生する処理を単にその影響を軽減するだけでなく、削減することができます。一方、データベース側の接続制限は同時アクセスを制限するものであり、ガバナーによるCPUおよびI/O制御を自動的に置き換えるものではありません。

顧客の要件が共有ホスティングと恒久的に大きく異なる場合、専用のデータベースインスタンスや専用サーバーの導入が有効となる場合があります。ただし、これにより、個別の閾値に基づく判断から、容量の計画、保守、運用といった段階へと判断の焦点が移ることになります。 また、このような分離であっても、完全な分離や一定の応答時間を保証するものとして一概に捉えるべきではありません。