sql >> データベース >  >> RDS >> PostgreSQL

MoodlePostgreSQLデータベースのスケーリングの課題

    Moodleは最も人気のある学習管理システム(LMS)であり、教育者は学習を拡張するコースやコンテンツを使用して独自のWebサイトを作成できます。これらの種類のプラットフォームは、従来の教育システムが利用できない場合、またはそれを補完するものとしてリモートで学習を継続できるようにするためにますます重要になっているため、トラフィックまたはユーザーの増加により、応答を低くするために環境を拡張する必要があります。時間。

    スケーラビリティは、リソースを追加することで増大する需要を処理するシステム/データベースの特性です。データベースをスケーリングする必要がある方法に応じて、データベースをスケーリングするために利用できるさまざまなアプローチがあります。本番環境では、おそらく長いダウンタイムは望ましくないため、これも考慮に入れる必要があります。

    このブログでは、利用可能なスケーリングオプションと、実行中のシステムに影響を与えることなく簡単な方法でMoodlePostgreSQLデータベースをスケーリングする方法について説明します。

    水平スケーリングと垂直スケーリング データベースを拡張する主な方法は2つあります。

    • 水平スケーリング(スケールアウト):データベースクラスターを作成または増加するデータベースノードを追加することによって実行されます。
    • 垂直スケーリング(スケールアップ):既存のデータベースノードにハードウェアリソース(CPU、メモリ、ディスク)を追加することで実行されます。

    水平スケーリングの場合 、スタンバイノードとしてデータベースノードをさらに追加できます。これは、ノード間のトラフィックのバランスをとる読み取りパフォーマンスを向上させるのに役立ちます。この場合、ポリシーとノードの状態に応じて、トラフィックを正しいノードに分散するためにロードバランサーを追加する必要があります。また、単一障害点を回避するために2つ以上のロードバランサーノードを追加し、可用性を確保するために「キープアライブ」などのツールを使用することを検討する必要があります。 Keepalivedは、サーバーのアクティブ/パッシブグループ内で仮想IPアドレスを構成できるようにするサービスです。この仮想IPアドレスは、アクティブなサーバー(アクティブなロードバランサー)に割り当てられます。このサーバーに障害が発生した場合、IPアドレスは自動的に「セカンダリ」パッシブサーバーに移行され、システムに対して透過的な方法で同じIPアドレスを引き続き使用できるようになります。

    垂直スケーリングの場合 、PostgreSQLが新しいまたはより優れたハードウェアリソースを使用できるように、いくつかの構成パラメーターを変更する必要がある場合があります。 PostgreSQLのドキュメントからこれらのパラメータのいくつかを見てみましょう。

    • work_mem:一時ディスクファイルに書き込む前に、内部ソート操作とハッシュテーブルによって使用されるメモリの量を指定します。複数の実行中のセッションがそのような操作を同時に実行している可能性があるため、使用されるメモリの合計はwork_memの値の何倍にもなる可能性があります。
    • maintenance_work_mem:VACUUM、CREATE INDEX、ALTER TABLE ADDFOREIGNKEYなどの保守操作で使用されるメモリの最大量を指定します。設定を大きくすると、バキューム処理とデータベースダンプの復元のパフォーマンスが向上する可能性があります。
    • autovacuum_work_mem:各autovacuumワーカープロセスで使用されるメモリの最大量を指定します。
    • autovacuum_max_workers:一度に実行できる自動真空プロセスの最大数を指定します。
    • max_worker_processes:システムがサポートできるバックグラウンドプロセスの最大数を設定します。バキューム、チェックポイント、その他のメンテナンスジョブなどのプロセスの制限を指定します。
    • max_parallel_workers:システムが並列操作でサポートできるワーカーの最大数を設定します。並列ワーカーは、前のパラメーターによって確立されたワーカープロセスのプールから取得されます。
    • max_parallel_maintenance_workers:単一のユーティリティコマンドで開始できる並列ワーカーの最大数を設定します。現在、並列ワーカーの使用をサポートする唯一の並列ユーティリティコマンドは、CREATE INDEXであり、Bツリーインデックスを作成する場合のみです。
    • effective_cache_size:単一のクエリで使用できるディスクキャッシュの有効サイズに関するプランナーの仮定を設定します。これは、インデックスを使用するコストの見積もりに考慮されます。値が大きいほどインデックススキャンが使用される可能性が高くなり、値が低いほどシーケンシャルスキャンが使用される可能性が高くなります。
    • shared_buffers:データベースサーバーが共有メモリバッファに使用するメモリの量を設定します。良好なパフォーマンスを得るには、通常、最小値よりも大幅に高い設定が必要です。
    • temp_buffers:各データベースセッションで使用される一時バッファーの最大数を設定します。これらは、一時テーブルへのアクセスにのみ使用されるセッションローカルバッファです。
    • effective_io_concurrency:PostgreSQLが同時に実行できると予想する同時ディスクI/O操作の数を設定します。この値を上げると、個々のPostgreSQLセッションが並行して開始しようとするI/O操作の数が増えます。現在、この設定はビットマップヒープスキャンにのみ影響します。
    • max_connections:データベースサーバーへの同時接続の最大数を決定します。このパラメータを増やすと、PostgreSQLはより多くのバックエンドプロセスを同時に実行できるようになります。

    ここでの課題は、Moodleデータベースをスケーリングする必要があるかどうか、そしてどのようにスケーリングする必要があるかを知る方法であり、答えはモニタリングです。

    Moodle用のPostgreSQLの監視

    データベースのスケーリングは複雑なプロセスであるため、いくつかのメトリックをチェックして、データベースをスケーリングするための最適な戦略を決定できるようにする必要があります。

    CPU、メモリ、およびディスクの使用状況を監視して、構成に問題があるかどうか、または実際にデータベースを拡張する必要があるかどうかを判断できます。たとえば、サーバーの負荷が高く、データベースアクティビティが低い場合、おそらくスケーリングする必要はありません。構成パラメータをチェックするだけで、ハードウェアリソースと一致させることができます。

    データベースごとにPostgreSQLノードが使用するディスク容量を確認すると、さらにディスクが必要か、テーブルパーティションが必要かを確認するのに役立ちます。データベース/テーブルが使用するディスク容量を確認するには、pg_database_sizeやpg_table_sizeなどのPostgreSQL関数を使用できます。

    データベース側から、以下を確認する必要があります:

      接続量 クエリの実行 インデックスの使用 膨張 レプリケーションラグ

    これらは、データベースのスケーリングが必要かどうかを確認するための明確な指標になる可能性があります。

    スケーリングおよび監視システムとしてのClusterControl

    ClusterControlは、前述の両方のスケーリング方法に対処し、スケーリング要件を確認するために必要なすべてのメトリックを監視するのに役立ちます。

    ClusterControlをまだ使用していない場合は、インストールし、現在のPostgreSQLデータベースをデプロイまたはインポートして、[インポート]オプションを選択し、手順に従って、バックアップなどのClusterControlのすべての機能を利用できます。自動フェイルオーバー、アラート、監視など。

    水平スケーリング

    水平スケーリングの場合、クラスターアクションに移動して[レプリケーションスレーブの追加]を選択すると、新しいレプリカを最初から作成するか、既存のPostgreSQLデータベースをレプリカとして追加できます。

    新しいレプリケーションスレーブの追加が非常に簡単な作業になることを見てみましょう。

    画像でわかるように、マスターを選択するだけで済みますサーバーに、新しいスレーブサーバーのIPアドレスとデータベースポートを入力します。次に、ClusterControlにソフトウェアをインストールさせるかどうか、およびレプリケーションスレーブを同期にするか非同期にするかを選択できます。

    このようにして、必要な数のレプリカを追加し、ClusterControlで実装できるロードバランサーを使用してそれらの間で読み取りトラフィックを分散できます。

    これで、クラスターアクションに移動して[ロードバランサーの追加]を選択すると、新しいHAProxyロードバランサーをデプロイするか、既存のロードバランサーを追加できます。

    次に、同じロードバランサーセクションにキープアライブを追加できます高可用性環境を改善するためにロードバランサーノードで実行されるサービス。

    ロードバランサーを追加した後、またはキープアライブサービスを備えた仮想IPを使用した後場所では、新しいデータベースエンドポイントを使用するためにMoodle設定を更新する必要があります。このためには、Moodleルートディレクトリに移動し、config.phpファイルを新しいIPアドレスで変更します:

    $CFG->dbhost    = 'IP_ADDRESS';
    
    $CFG->dbname    = 'moodle';
    
    $CFG->dbuser    = 'mdluser';
    
    $CFG->dbpass    = '********';
    
    $CFG->prefix    = 'mdl_';
    
    $CFG->dboptions = array (
    
      'dbpersist' => 0,
    
      'dbport' => PORT,
    
      'dbsocket' => '',
    
    );

    ロードバランサーまたは仮想IPアドレスを介してデータベースにアクセスできることを確認してください。または、pg_hba.confPostgreSQLファイルを更新して許可する必要がある場合。

    垂直スケーリング

    垂直スケーリングの場合、ClusterControlを使用すると、オペレーティングシステム側とデータベース側の両方からデータベースノードを監視できます。 CPU使用率、メモリ、接続、上位クエリ、実行中のクエリなど、いくつかのメトリックを確認できます。ダッシュボードセクションを有効にすることもできます。これにより、より詳細でわかりやすい方法で指標を確認できます。

    ClusterControlから、ホストの再起動、再構築などのさまざまな管理タスクを実行することもできます。ワンクリックでレプリケーションスレーブ、またはプロモートスレーブ。

    結論

    Moodle PostgreSQLデータベースのスケーリングは、スケーリングの必要性とシステムに影響を与えずに行う方法を知る必要があるため、難しい作業になる可能性があります。優れた監視システムを持つことは、Moodleデータベースをいつどのようにスケーリングする必要があるかを知るための最初のステップです。ロードバランサーを追加すると、不要なダウンタイムを回避でき、LMS環境の高可用性も向上します。

    私たちが言及したこれらすべてのことは、作業を容易にするClusterControlを使用して行うことができます。 ClusterControlは、監視、アラート、自動フェイルオーバー、バックアップ、ポイントインタイムリカバリ、バックアップ検証、スケーリングなど、さまざまな機能を提供します。


    1. 更新:バグによりMicrosoftOffice365ビルド2105がアクセスアプリケーションを中断する

    2. unixODBCドライバーマネージャーの非システムバージョンでのRStudioの使用

    3. MySQLでのSUBSTR()関数のしくみ

    4. MySQLクエリでタイムスタンプを日付に変換する