キャッシング

キャッシュとは、処理済みのデータを手元に保持して再利用することで、コストのかかるデータベースクエリの繰り返しを避けるためのデータの集まりです。

Moodle 2.4では、MUC（Moodle Universal Cache）が実装されました。この新しいシステムにより、Moodleの特定の機能（例：ストリングの取得）で、インストールされているさまざまなキャッシュサービス（例：ファイル、RAM、memcached）を利用できるようになりました。

今後のバージョンのMoodleでも、MUCを使用するMoodleの機能を引き続き増やしていく予定で、それによってパフォーマンスはさらに向上していきますが、すでにMUCを使用してサイトを改善し始めることができます。

このドキュメントはかなり長いため、パフォーマンスを向上させるためにMoodleに追加できるキャッシングオプションを知りたいだけの場合は、「キャッシュストアインスタンスの追加」またはパフォーマンスの推奨事項に進んでください。Moodleでのキャッシングの仕組みについて詳しく知りたい場合は、このまま読み進めてください。

パフォーマンステストの一般的なアプローチ

次のような全般的な戦略をとってください。

実際の本番環境のインスタンスにできるだけ近いテスト環境を構築します（例：ハードウェア、ソフトウェア、ネットワークなど）。
この環境から、制御できない変数（例：他のサービス）をできるだけ取り除きます。
ツールを使用して、現実的でありながらシミュレートされた、繰り返し可能な負荷をサーバにかけます（例：jmeterやselenium）。
データ（RAM、負荷、所要時間など）を取得してサーバのパフォーマンスを測定する方法を決めます。
負荷をかけて、基準となるパフォーマンスの結果を測定します。
一度に1つの変数だけを変更し、再度負荷をかけて、パフォーマンスが向上するか低下するかを確認します。必要に応じて繰り返します。
一貫してパフォーマンスが向上する設定が見つかったら、本番サイトに適用します。

Moodleのキャッシュ設定

Moodle 2.4以降、Moodleにはキャッシングプラグインフレームワークが用意されており、管理者はMoodleがキャッシュデータを保存する場所をコントロールできます。ほとんどのMoodleサイトではデフォルト設定で十分であり、設定を変更する必要はありません。複数のサーバを使用する大規模なMoodleサイトでは、管理者がキャッシュデータの保存にmemcached、mongodbなどのシステムを使用したい場合があります。キャッシュプラグイン画面では、管理者がどのキャッシュデータをどこに保存するかを設定できます。
Moodleのキャッシングは、Moodle Universal Cacheと呼ばれるものによってコントロールされています。一般にMUCと呼ばれます。

このドキュメントでは、MUCとは何かを簡単に説明してから、MUCが提供する概念と設定オプションについて詳しく説明します。

Moodleにおける基本的なキャッシュの概念

Moodleのキャッシングは、最初に見えるほど複雑ではありません。少し予備知識があるだけで、キャッシュ設定の仕組みを理解するのに大いに役立ちます。

キャッシュタイプ

まず、キャッシュタイプ（モードと呼ばれることもあります）から始めましょう。Moodleには、3つの基本的なキャッシュタイプがあります。

1つ目はアプリケーションキャッシュです。これは、コードで群を抜いて最もよく使用されるキャッシュタイプです。すべてのユーザがその情報を共有し、データはリクエスト間で保持されます。ここに保存される情報は、通常、次の2つの理由のどちらかでキャッシュされます。大部分のリクエストで必要となる情報で、キャッシュすることでデータベースとのやり取りを1回以上省けるか、あるいは、アクセスされる頻度は低いものの、生成に多くのリソースを必要とする情報であるかのどちらかです。
デフォルトでは、この情報はMoodleデータディレクトリ内の整理された構造に保存されます。

2つ目のキャッシュタイプはセッションキャッシュです。これは、すでにおなじみのPHPセッションとまったく同じで、デフォルトではPHPセッションを使用します。そもそもなぜこのキャッシュタイプがあるのか疑問に思うかもしれませんが、答えは簡単です。MUCは、リクエスト間で必要となる情報を保存および削除するための管理された手段を提供します。車輪の再発明をしなくても済むよう開発者が使用できるフレームワークを提供し、必要に応じてキャッシュを管理するためのコントロールされた手段を利用できるようにします。
このキャッシュタイプはあまり頻繁には使用されないことに注意することが重要です。デフォルトでは、セッションキャッシュのデータはPHPセッションに保存され、PHPセッションはデータベースに保存されるためです。セッションを肥大化させてデータベースに負担をかけたくないため、セッションキャッシュタイプの用途は小さなデータセットに限られます。

3つ目の、そして最後のタイプはリクエストキャッシュです。このキャッシュタイプに保存されたデータは、リクエストの存続期間中のみ保持されます。PHP開発者であれば、管理された静的変数のようなものと考えてください。
これは、3つのキャッシュタイプのうち群を抜いて使用頻度の低いものです。用途は多くの場合、同じリクエスト内で、通常は複数のコードのエリアから、何度もアクセスされる情報に限られます。キャッシュされた情報は、デフォルトではメモリに保存されます。

キャッシュタイプと複数サーバシステム

複数のフロントエンドウェブサーバを持つシステムの場合、アプリケーションキャッシュはサーバ間で共有する必要があります。つまり、アプリケーションキャッシュには高速なローカルストレージを使用できず、共有ストレージ、または共有memcachedのような他の形式の共有キャッシュを使用する必要があります。

セッションキャッシュにも同じことが当てはまります。ただし、「スティッキーセッション」の仕組みを使用して、ユーザがセッション内で常に同じフロントエンドサーバにアクセスするようにしている場合は除きます。

キャッシュバックエンド

キャッシュバックエンドは、データが実際に保存される場所です。これには、ファイルシステム、PHPセッション、Memcached、メモリなどが含まれます。
デフォルトでは、Moodle内ではファイルシステム、PHPセッション、メモリのみが使用されます。
サイトがMemcachedなどの他のシステムにアクセスできることは必須ではありません。そうしたシステムは、自分でインストールして設定する必要があります。
キャッシュバックエンドというときは、データを保存できるMoodle外部のシステムを思い浮かべてください。MongoDBサーバ、Memcachedサーバ、その他同様の「サーバ」アプリケーションです。

キャッシュストア

キャッシュストアは、Moodle内のプラグインタイプの1つです。キャッシュストアは、上で説明したキャッシュバックエンドにMoodleを接続するためのものです。標準のMoodleには、上記の3つのデフォルトのほか、Memcached、MongoDB、APCユーザキャッシュ (APCu)、Redisがあります。

その他のキャッシュストアプラグインは、プラグインデータベースで見つけることができます。

これらのコードは、Moodleディレクトリのルートのcache/stores内にあります。

Moodle内では、アーキテクチャに必要な数だけキャッシュストアを設定できます。例えば、複数のMemcachedサーバがある場合は、それぞれにキャッシュストアインスタンスを作成できます。デフォルトでは、Moodleには、他に何も設定していない場合に使用される3つのキャッシュストアインスタンスがあります。

ファイルストアインスタンスが作成され、すべてのアプリケーションキャッシュに使用されます。データはmoodledataディレクトリに保存されます。
セッションストアインスタンスが作成され、すべてのセッションキャッシュに使用されます。データはPHPセッションに保存され、PHPセッションはデフォルトではデータベースに保存されます。
静的メモリストアインスタンスが作成され、すべてのリクエストキャッシュタイプに使用されます。データは、リクエストの存続期間中のみメモリ内に存在します。

キャッシュ：コード内で起きていること

キャッシュはコード内で作成され、開発者がキャッシュする必要があると判断したデータを保存するために使用されます。
開発者ではない方もいると思われるので、このセクションは簡潔にとどめましょう。知っておく必要がある非常に重要な点が1つあります。
開発者には、データがどこにキャッシュされるかについての決定権はありません。開発者は、使用するキャッシュを作成するときに、次の情報を指定する必要があります。

必要なキャッシュのタイプ。
このキャッシュが属するコードのエリア（いわばAPI）。
キャッシュの名前。キャッシュに保存する内容を一語で表すために開発者が考えたものです。

開発者が指定できるオプションの要件や設定もいくつかありますが、現時点ではそれについて心配する必要はありません。
重要な点は、開発者はどのキャッシュバックエンドを使用するかを選択できず、上で詳しく説明した3つの中から必要なキャッシュのタイプを選択できるだけだということです。

全体の連携の仕組み

これは、組織内で果たす役割に関連付けて説明するのが最もわかりやすいでしょう。

システム管理者が、使用したいキャッシュバックエンド（Memcached、XCache、APCなど）をインストールします。
Moodleはこれらについて関知しません。これらはMoodleの範囲外であり、純粋にシステム管理者の責任です。
Moodle管理者が、サイトで利用する各バックエンドについて、Moodle内にキャッシュストアインスタンスを作成します。
各バックエンドに対して、キャッシュストアインスタンスは1つ以上存在できます。Memcachedなど一部のバックエンドには、1つのバックエンド内に分離された領域を作成するための設定があります。
開発者がコード内でキャッシュを作成し、それを使用してデータを保存しています。
開発者は、キャッシュがどのように使用されるかについて何も知りません。単に「キャッシュ」を作成し、どのタイプが最適かをMoodleに伝えるだけです。
Moodle管理者が、キャッシュストアインスタンスとキャッシュの間のマッピングを作成します。
このマッピングによって、開発者がキャッシュしたいデータを保存するために、指定したバックエンドを使用するようMoodleに指示します。

それに加えて、さらに踏み込んだ設定もできます。

多数のキャッシュを1つのキャッシュストアインスタンスにマップできます。
複数のキャッシュストアインスタンスを、優先度（主 ... 最終）を付けて1つのキャッシュにマップできます。
キャッシュストアインスタンスを、特定のマッピングが他にない、特定のタイプのすべてのキャッシュに使用されるデフォルトストアとしてマップできます。

Moodle Universal Cacheについて読むのが初めての場合は、かなり複雑に聞こえるかもしれませんが、心配はいりません。Moodleでのキャッシングの設定方法を順を追って見ていく中で、さらに詳しく説明します。

高度な概念

これらの概念は、ほとんどのサイトでは知る必要も気にする必要もないものです。

ここを見始めるべきなのは、共有キャッシュバックエンドを持つクラスタ化されたサービス上で動作する大規模サイトや、同じくサイト間で情報が共有されるマルチサイトアーキテクチャで、パフォーマンスを最大化しようとしている場合のみです。

ロッキング

ロッキングの考え方は目新しいものではありません。同時実行の問題を避けるためにアクセスをコントロールするプロセスです。

MUCには2つ目のタイプのプラグインがあります。キャッシュが必要とする場合に使用されるキャッシュロックプラグインです。現在までのところ、これを必要としたキャッシュはありません。キャッシュは本質的に揮発性のものであり、真にミッションクリティカルな情報は、より永続的なデータストア、おそらくはデータベースに保存すべきです。

それでも、キャッシュ定義がオプション内で要求できるロッキングシステムがあり、キャッシュストアインスタンスとやり取りする際に適用されます。

共有

キャッシュに保存されるデータにはすべて、計算された一意のキーが関連付けられています。
デフォルトでは、そのキーの一部はサイト識別子であり、キャッシュに保存されたコンテンツは、それを保存したサイトに固有のものになります。ほとんどのサイトでは、まさにこれが望ましい動作です。
しかし、状況によっては、複数のサイトや何らかの形で関連付けられたサイトがキャッシュデータを共有できるようにすると有益です。
もちろん、すべてのキャッシュを共有できるわけではありませんが、確実に共有できるものもあり、共有することで、リソースの利用を最大化し、負荷をさらに減らしてパフォーマンスを向上させることができます。

これは高度な機能です。共有を設定する場合は、慎重に行ってください。

共有を利用するには、まず情報を共有したいサイトに同一のキャッシュストアインスタンスを設定し、次に各サイトで、そのキャッシュの共有を同じ値に設定する必要があります。

同じサイトIDのサイト: これはデフォルトで、同じサイトIDを持つサイトがキャッシュ情報を共有できるようにします。最も制限が厳しいものの、すべてのキャッシュで機能します。その他のオプションにはすべて、ある程度のリスクが伴います。キャッシュの情報が、それにアクセスするすべてのサイトに当てはまることを確認する必要があるためです。
同じバージョンで動作しているサイト: バックエンドにアクセスする、Moodleのバージョンが同じすべてのサイトが、このキャッシュがキャッシュストアに保存した情報を共有できます。
カスタムキー: 共有に使用するキーを手動で入力します。その後、情報を共有したい他のサイトにも、まったく同じキーを入力する必要があります。
すべて: キャッシュデータは、そのデータにアクセスする他のすべてのサイトからアクセスできます。このオプションでは、判断を完全にMoodle管理者に委ねることになります。

例えば、APCがインストールされたサーバ上で、すべて同じバージョンの複数のMoodleサイトを実行している場合、言語キャッシュをAPCストアにマップし、同じバージョンで動作しているすべてのサイトで共有するよう設定することができます。
同じバージョンのサイトの言語キャッシュは、多くの状況で安全に共有でき、ほぼすべてのページで使用され、APCは非常に高速です。これら3つの点から、サイトのパフォーマンスがちょっとばかり向上する可能性があります。
言語キャッシュについて考慮すべき重要な点は、サイト間で共有すると、言語のカスタマイズ内容もすべて共有されることです。

キャッシュ設定画面

キャッシュ設定画面は、Moodleでキャッシングを設定するためのワンストップの窓口です。
キャッシングが現在サイトでどのように設定されているかの概要を示し、特定のニーズに合わせてキャッシングを設定するために実行できるすべての操作へのリンクを提供します。

キャッシュ設定画面へのアクセス

キャッシュ設定画面には、moodle/site:configケイパビリティを持つユーザのみがアクセスできます。デフォルトでは、これは管理者のみです。
ログイン後、設定画面はサイト管理 > プラグイン > キャッシング > 設定にあります。

インストール済みキャッシュストア

ここには、インストールされているキャッシュストアプラグインの一覧が表示されます。
各プラグインについて、使用する準備ができているか（PHPの要件がすべて満たされているか）、このサイトにすでにいくつのストアインスタンスが存在するか、このストアを使用できるキャッシュタイプ、サポートしている機能（高度）、このストアに関して実行できる操作をすばやく確認できます。

多くの場合、利用できる操作は新しいストアインスタンスの作成のみです。
ほとんどのストアは複数のインスタンスをサポートしていますが、すべてではありません。セッションキャッシュと静的リクエストキャッシュはサポートしていないことがわかります。これら2つのストアでは、複数のインスタンスを持つことに意味がありません。

設定済みストアインスタンス

ここには、このサイトのキャッシュストアインスタンスの一覧が表示されます。

ストア名: 識別できるように、このキャッシュストアインスタンスの作成時に付けられた名前です。任意の名前を付けることができ、ストアインスタンスを識別するためだけに使用されます。
プラグイン: このインスタンスの元となるキャッシュストアプラグインです。
準備完了: PHPの要件がすべて満たされ、接続やセットアップの要件も確認されると、チェックマークが表示されます。
ストアマッピング: このストアインスタンスが明示的にマップされているキャッシュの数です。デフォルトマッピング（後述）による使用は含まれません。
モード: このキャッシュストアインスタンスが対応できるモードです。
サポート: このキャッシュストアインスタンスがサポートする機能です。
ロッキング: ロッキングは、データが上書きされるのを防ぐために、キャッシュデータへのアクセスを一度に1つのプロセスに制限する仕組みです。ロッキング方法によって、ロックの取得および確認の方法が決まります。
操作: このキャッシュストアインスタンスに対して実行できる操作です。

既知のキャッシュ定義

キャッシュ定義の考え方については、ここではまだ説明していません。これは開発者がコントロールするものです。開発者がキャッシュを作成する方法は2つあり、1つ目はキャッシュ定義を作成する方法です。これは基本的に、作成したキャッシュについてMoodleに伝えることです。2つ目の方法は、アドホックキャッシュを作成することです。開発者には常に1つ目の方法を使用することが推奨されています。管理者がマップしてさらに設定できるのは、定義を持つキャッシュのみです。アドホックキャッシュは、デフォルト設定のみを使用します。
通常、アドホックキャッシュが許可されるのは、キャッシュが小さく、デフォルトを超えて設定しても管理者にとってメリットがない場合のみです。要するに、管理者はそれについて気にする必要はない、と言っているようなものです。

ここに表示される各キャッシュについて、次の情報が得られます。

定義: このキャッシュの簡潔な説明です。
モード: このキャッシュが対象とするキャッシュタイプです。
コンポーネント: キャッシュが関連付けられているコードコンポーネントです。
エリア: このキャッシュがコンポーネント内で対応するコードのエリアです。
ストアマッピング: このキャッシュに使用される1つまたは複数のストアです。
共有: このサイトで共有がどのように設定されているかです。
操作: キャッシュに対して実行できる操作です。通常は、キャッシュストアインスタンスのマッピングの編集、共有の編集、キャッシュのパージを行えます。

このテーブルの一番下には、「定義を再スキャンする」というタイトルのリンクもあります。このリンクをクリックすると、Moodleはすべてのコアコンポーネントとインストール済みプラグインをチェックして、キャッシュ定義の変更を探します。
これはデフォルトでアップグレード中に行われ、新しいキャッシュ定義が見つかった場合にも行われます。ただし、探しているキャッシュが見つからない場合は、試してみる価値があるかもしれません。
開発者にとっても、キャッシュを扱う際に変更をすばやく適用できるので便利です。キャッシュ定義を微調整して最適な設定を見つける際に役立ちます。

特定のキャッシュ定義に関する情報は、キャッシュ定義ページにあります。

キャッシュロックインスタンスの概要

前述のとおり、キャッシュロッキングはMUCの高度な概念です。
ここのテーブルには、MUCで利用可能な、設定済みのロッキング機構に関する情報が表示されます。デフォルトでは、ファイルロッキングという単一のロッキング機構のみが利用可能です。現在、これを利用するキャッシュはないため、ここではこれ以上説明しません。

マッピングが存在しない場合に使用されるストア

このテーブルには、特定のマッピングがない場合に、各キャッシュタイプにどのキャッシュストアインスタンスが使用されるかが簡潔に表示されます。
簡単に言えば、各タイプのデフォルトのキャッシュストアが表示されます。

一番下には「マッピングを編集する」というリンクがあり、これを設定できるページに移動します。

キャッシュストアインスタンスの追加

デフォルト設定はすべてのサイトで機能しますが、さまざまなキャッシングバックエンドや手法を利用することで、サイトのパフォーマンスを向上させられる場合があります。まず最初に行うのは、セットアップしたキャッシュバックエンドに接続して使用するよう設定したキャッシュストアインスタンスを追加することです。

ファイルキャッシュ

キャッシュ設定画面のインストール済みキャッシュストアテーブルにファイルキャッシュプラグインが表示されているので、「インスタンスを追加する」をクリックして、ファイルキャッシュストアインスタンスの追加を開始します。

ファイルキャッシュを作成するときに必須のパラメータは、実は1つだけで、ストア名です。ストア名は、設定インタフェースでファイルストアインスタンスを識別するために使用され、サイト内で一意である必要があります。任意の名前を付けることができますが、ファイルストアの使用目的を表す名前にすることをお勧めします。

次のプロパティを指定して、ファイルキャッシュの場所と動作をカスタマイズすることもできます。

キャッシュパス: ファイルシステムにキャッシュデータを保存するときに使用するディレクトリを指定できます。当然ながら、ウェブサーバを実行しているユーザには、このディレクトリへの読み書きアクセス権が必要です。デフォルト（空白）では、Moodledataディレクトリが使用されます。
自動ディレクトリ作成: 有効にした場合、キャッシュの初期化時に、指定したディレクトリが存在しなければ、Moodleがそのディレクトリを作成します。これが指定されていて、ディレクトリが存在しない場合、キャッシュは準備ができていないとみなされ、使用されません。
単一ディレクトリストア: デフォルトでは、ファイルストアはデータを保存するためのサブディレクトリ構造を作成します。データキーの最初の3文字がディレクトリとして使用されます。これは、ファイルシステムにディレクトリあたりの最大ファイル数がある場合に、ファイルシステムの制限を回避するのに役立ちます。このオプションを有効にすると、ファイルキャッシュはデータの保存にサブディレクトリを使用しません。これによりフラットな構造になりますが、ファイルシステムの制限に達する可能性が高くなります。注意して使用してください。
ディレクトリを事前スキャンする: ファイルキャッシュが提供する機能の1つに、キャッシュの初回使用時にストレージディレクトリを事前スキャンする機能があります。これにより、詳細な読み込みを犠牲にして、ファイルのチェックが高速になります。

ファイルキャッシュストアは、アプリケーションキャッシュに使用されるデフォルトのストアで、デフォルトではmoodledataディレクトリがキャッシュに使用されます。負荷が高まっているときには、ファイルアクセスがリソースに大きな負担をかけることがあります。以下は、パフォーマンスを向上させるために代わりのファイルストアを設定する際のアイデアです。

まず、サーバで使用できる、より高速なファイルシステムがあるかどうかです。
例えば、SSDが搭載されているものの、容量が貴重なためmoodledataディレクトリには使用していない場合があります。
SSD上にディレクトリまたは小さなパーティションを作成し、Moodleデータディレクトリの代わりにそれを使用するファイルストアを作成することを検討してください。

次に、より高速なドライブは利用できないものの、空き容量は十分にある場合です。
試してみる価値があるかもしれないのは、搭載されているドライブ上に、パフォーマンス重視のファイルシステムを使用する小さなパーティションを作成することです。
例えば、最近の多くのLinux環境ではEXT4が使用されています。EXT4は優れたファイルシステムですが、ジャーナリングなどによるオーバーヘッドがあります。
パーティションを作成し、パフォーマンス向けに最適化されたファイルシステムを使用することで、求めていたちょっとした性能向上が得られるかもしれません。キャッシュは揮発性であることを前提に設計されており、キャッシュ用のファイルシステムの選択は、サーバ用のファイルシステムの選択とは別の判断であることを覚えておいてください。
最後に、手間を惜しまず、サーバに豊富なメモリがある場合は、ramdisk/tmpfsを作成し、ファイルストアをそこに向けることを検討できます。純粋にメモリ上に置かれるため、キャッシュとまったく同じように揮発性であり、ファイルシステムのパフォーマンスとしてはこれ以上はほとんど望めないでしょう。
もちろん、容量は限られ、実質的にサーバからそのリソースを奪うことになります。

これらのアイデアはすべて、あくまでアイデアにすぎないことを覚えておいてください。
何を選ぶにしても、テスト、テスト、テストを重ね、決定に確信を持ってください。

Memcached

まず、アクセスできるMemcachedサーバがあり、サーバにMemcached PHP拡張モジュールがインストールされ、有効になっている必要があります。

Memcachedストアの設定には、2つの必須パラメータがあります。

ストア名: 設定インタフェースでストアインスタンスを識別するために使用され、サイト内で一意である必要があります。
サーバ: このキャッシュストアで使用したいサーバです。詳細は以下を参照してください。

サーバは1行に1つずつ追加し、各行にはコロンで区切った1～3個のプロパティを含めることができます。

サーバのURLまたはIPアドレス（必須）
サーバが待ち受けているポート（オプション）
このサーバに与える重み（オプション）

例えば、サーバ上で2つのMemcachedインスタンスを実行していて、1つはデフォルトのポート、もう1つは11212番ポートに設定されている場合は、次のようにします。 127.0.0.1 127.0.0.1:11212

Memcachedストアを作成するときに設定できるオプションのパラメータもいくつかあります。

圧縮を使用する: デフォルトはtrueですが、必要に応じて無効にできます。
シリアライザを使用する: Memcachedサーバと通信するときに使用するシリアライザを選択できます。デフォルトでは、Memcached拡張モジュールとPHPはシリアライザを1つしか提供していませんが、探せばインストールできるものが他にもいくつかあります。例えば、https://github.com/igbinary/igbinary にあるigbinaryがあります。
接頭辞キー: サーバとやり取りする前に、すべてのキーの先頭に付加する文字を設定できます。
ハッシュメソッド: ここでは、デフォルトでMemcached拡張モジュールが提供するハッシュメソッドが使用されます。ただし、必要に応じて代替のものを使用するよう選択できます。http://www.php.net/manual/en/memcached.constants.php には、利用可能なオプションに関する情報が少しだけ記載されています。なお、必要であれば、php.ini内でPHPが使用するデフォルトのハッシュ関数をオーバーライドすることもできます。
バッファ書き込み: デフォルトでは無効になっていますが、それには十分な理由があります。バッファ書き込みを有効にすると、I/O処理をバッファリングすることで、Memcachedサーバとのやり取りを最小限に抑えます。その欠点は、同時実行のあるシステムでは、最初にリクエストしたときに誰もデータをMemcachedサーバにプッシュしていないため、複数のリクエストが結局データを生成することになる可能性が高いことです。これを有効にすると、例えば、複数回のやり取りがネットワークリソースに負担をかけるような、ケイパビリティでコントロールされたエリアでのみアクセスされるキャッシュには有利な場合があります。ただし、それは間違いなく、極端なチューニングの領域の話です。

実装に関する重要な注意事項

Memcached拡張モジュールには、一連のエントリを削除する手段がありません。単一のエントリを削除するか、すべてのエントリを削除するかのどちらかです。

このため、Moodle内でMemcachedストアをパージすると、Memcachedサーバ内のすべてのエントリが削除されることに注意することが重要です。Moodleに関連するエントリだけではありません。
そのため、専用のMemcachedサーバを使用し、他のソフトウェアが同じサーバを使用するよう設定しないことを強くお勧めします。そうすると、パフォーマンスの低下や悪影響につながる可能性があります。

同様に、Moodleでキャッシングとセッションの両方にMemcachedを使用したい場合は、2つのMemcachedサーバを使用することが不可欠です。1つはセッション用、もう1つはキャッシング用です。そうしないと、Moodleでキャッシュをパージしたときにセッションもパージされてしまいます！

MongoDB

MongoDBは、オープンソースのドキュメント指向NoSQLデータベースです。詳しくは、ウェブサイト www.mongodb.org をご覧ください。

ストア名: 設定インタフェースでストアインスタンスを識別するために使用され、サイト内で一意である必要があります。
サーバ: 使用したいサーバの接続文字列です。カンマ区切りのリストで複数のサーバを指定できます。
データベース: 使用するデータベースの名前です。
ユーザ名: 接続時に使用するユーザ名です。
パスワード: 接続に使用するユーザのパスワードです。
レプリカセット: 接続先のレプリカセットの名前です。これを指定した場合、シードに対してismasterデータベースコマンドを使用してマスタが決定されるため、ドライバは一覧に記載されていないサーバに接続することもあります。
使用: 有効にした場合、挿入、取得、削除の各処理中にusesafeオプションが使用されます。レプリカセットを指定した場合は、いずれにしても強制的に有効になります。
安全値を使用する: use safeに使用する特定の値を指定できます。これにより、処理が完了したとみなされるまでに、処理を完了する必要があるサーバの数が決まります。
拡張キーを使用する: 有効にした場合、プラグインを操作するときに完全なキーセットが使用されます。これはまだ内部では使用されていませんが、必要に応じてMongoDBプラグインを手動で簡単に検索および調査できるようになります。有効にすると若干のオーバーヘッドが加わるため、必要な場合にのみ有効にしてください。

Redis

Redisは、開発元によって「数百万の開発者がデータベース、キャッシュ、ストリーミングエンジン、メッセージブローカーとして使用している、オープンソースのインメモリデータストア」と説明されています。アプリケーションキャッシュとセッションキャッシュの保存に使用できる優れたキャッシングオプションです。詳しくは公式サイト https://redis.io をご覧ください。インストール手順や、Moodleとの具体的な連携についての詳細を探している場合は、こちらのWikiページRedisキャッシュストアをご覧ください。

キャッシュのストアインスタンスへのマッピング

ストアインスタンスをキャッシュにマップすると、そのキャッシュとやり取りする際にそのストアインスタンスを使用するようMoodleに指示します。これにより、Moodle管理者は情報が保存される場所をコントロールでき、最も重要なこととして、サイトで利用可能なリソースを最大限に活用してサイトのパフォーマンスを最適化できます。

マッピングを設定するには、まずキャッシュ設定画面に移動します。
既知のキャッシュ定義テーブルを探し、その中でマップしたいキャッシュを見つけます。「操作」カラムで「マッピングを編集する」リンクを選択します。

表示される画面では、このキャッシュで使用する1つ以上のキャッシュストアインスタンスをマップできます。
1つ以上をマップできるドロップダウンがいくつか表示されます。マップされたキャッシュはすべてやり取りの対象になります。「主ストア」は、キャッシュとやり取りする際に最初に使用されるストアです。マップされた「最終ストア」は、最後にやり取りされるキャッシュストアです。
このやり取りがどのように行われるかは、以下で説明します。

キャッシュにストアがマップされていない場合は、デフォルトのストアが使用されます。デフォルトのストアの変更については、以下のセクションを参照してください。

単一のストアインスタンスがキャッシュにマップされている場合は、次のようになります。

キャッシュからデータを取得する: Moodleがキャッシュにデータの取得を依頼します。キャッシュはストアからデータの取得を試みます。ストアにデータがあれば、ストアはそれをキャッシュに渡し、キャッシュはMoodleがデータを使用できるようにそれをMoodleに渡します。ストアにデータがない場合は失敗が返され、Moodleはデータを生成する必要があり、多くの場合、その後データをキャッシュに送ります。
キャッシュにデータを保存する: Moodleがキャッシュにデータの保存を依頼し、キャッシュはそれをキャッシュストアに渡します。

複数のストアインスタンスがキャッシュにマップされている場合は、次のようになります。

ストアからデータを取得する: Moodleがキャッシュにデータの取得を依頼します。キャッシュは最初のストアからデータの取得を試みます。最初のストアにデータがあれば、ストアはデータをキャッシュに返し、キャッシュはそれをMoodleに返します。最初のストアにデータがない場合は、2番目のストアからデータの取得を試みます。2番目のストアにデータがあれば、それを最初のストアに返し、最初のストアはそれを自身に保存してからキャッシュに返します。ない場合は、次のストアが使用されます。これは、データが見つかるか、チェックするストアがなくなるまで続きます。
キャッシュにデータを保存する: Moodleがキャッシュにデータの保存を依頼し、キャッシュは保存のためにマップされたすべてのキャッシュストアにそれを渡します。

複数のストアを割り当てる主な利点は、キャッシュの冗長性を導入できることです。もちろん、これによりオーバーヘッドが生じるため、本当に必要な場合にのみ使用してください。以下は、複数のストアをマップすることでメリットが得られる例です。

シナリオ：
Moodleサイトと他のサイトを置いているウェブサーバがあります。
また、Moodleを含む複数のサイトで使用されているMemcachedサーバもあります。

Memcachedのキャッシュサイズには限りがあり、いっぱいになった状態でさらに情報の保存をリクエストされると、使用頻度の最も低いキャッシュエントリを削除して領域を解放します。

Memcachedは高速なのでMoodleサイトに使用したいものの、利用の多いMemcachedサーバであるため、キャッシュミスが増える可能性があることを認識しています。

解決策：
これを回避するために、Memcachedを使用したいキャッシュに2つのストアをマップします。
Memcachedを主ストアにし、デフォルトのファイルストアを最終キャッシュストアにします。

説明：
こうすることで冗長性が生まれます。何かがリクエストされると、Moodleはまず（最速のストアである）Memcachedからそれを取得しようとし、そこにない場合はファイルキャッシュのチェックに進みます。

さらに、いくつか注目すべき点があります。

複数のキャッシュをマップするとオーバーヘッドが生じます。マップするキャッシュが多いほど、オーバーヘッドも大きくなります。
マップしようとしているキャッシュストアについて考慮してください。一度設定されたデータがそこに残り続けるのであれば、その後にさらにストアをマップする意味はありません。この手法は主に、設定後にデータが残ることが保証されていない状況で有効です。
必ず設定をテストしてください。パフォーマンス情報の表示を有効にしてから、キャッシュをトリガするような方法でMoodleを操作したときに、どのストアが使用されるかを確認します。

マッピングが存在しない場合に使用されるストアの設定

これは実質的に、キャッシュタイプに対して特定のマッピングが作成されていない場合に使用されるデフォルトのストアを設定するものです。

マッピングを設定するには、まずキャッシュ設定画面に移動します。
マッピングが存在しない場合に使用されるストアテーブルを探します。
テーブルの後に「マッピングを編集する」リンクがあるので、これをクリックします。

表示される画面では、対応するタイプのキャッシュが初期化され、そのキャッシュに明示的なマッピングがない場合に使用するストアを、キャッシュタイプごとに1つ選択できます。

なお、このインタフェースのドロップダウンには、そのタイプへのマッピングに適したストアインスタンスのみが含まれます。すべてのインスタンスが表示されるとは限りません。表示されないストアインスタンスがある場合、そのストアインスタンスは、存在するすべてのキャッシュ定義に適しているわけではありません。
そのストアインスタンスをデフォルトにすることはできないため、代わりに、使用したい（使用できる）各キャッシュに明示的にマップする必要があります。

サイトのキャッシング設定

ここが本当に難しいところで、残念ながら、これに関するステップバイステップのガイドはありません。

サイトのキャッシングを最適に設定する方法は、完全にそのサイトと、サイトで利用可能なリソースによって決まります。

ここで提供できるのは、検討のきっかけとなり、場合によっては作業の助けとなるアイデアを紹介するヒントやコツです。

このドキュメントを読んで、サイトでのキャッシング設定について何かを学んだ場合は、ここに項目を追加して学んだことを共有してください。

計画を立ててください。複雑なものです。サイトを理解し、システムを理解し、ユーザがそれらすべてをどのように使用するかをよく考えてください。
小規模なサイトでは大きな効果は期待できませんが、大規模なサイトでは、これを適切に設定することでパフォーマンスが大幅に向上する可能性があります。
キャッシュバックエンドを検討する際は、それぞれの長所と短所をよく調べてください。検討する際は、サイトのことを念頭に置いてください。サイトによっては、1つのキャッシュバックエンドだけではサイトのニーズ全体を満たせず、いくつかのバックエンドを使えるようにしておくと有益な場合があります。
通常、キャッシュバックエンドをインストールしてそれを使用するだけで済むほど単純ではありません。設定に注意を払い、システムに合わせて最適化するようにしてください。Moodleに設定する前に、個別にテストしてそのパフォーマンスを把握しておいてください。キャッシュによって、データベースから負荷を移し、ページリクエストの処理を減らすことができます。
例えば、Memcachedをインストールしていても、接続がそれに合わせて最適化されていない場合、MemcachedサーバをMoodleに設定する前から、逆効果になっている可能性もあります。
デフォルトのストアインスタンスを検討する際は、それらがさまざまなサイズと頻度のデータセットを扱わなければならないことに留意してください。大規模なサイトの場合、各キャッシュ定義を確認して、それに含まれるデータとアクセス頻度に最も適したストアにマップするのが最善の方法です。
キャッシュ定義については、キャッシュ定義に記載されています。
繰り返しになりますが、ストアインスタンスをキャッシュにマップする際は、マップするキャッシュについてよく考え、サイトについて理解していることと、キャッシュについて知っていることに基づいて判断してください。
キャッシュ定義については、キャッシュ定義に記載されています。
設定をテストしてください。ストレステストができればなお良いでしょう。パフォーマンス情報を有効にすると、Moodleは画面の一番下にキャッシュアクセス情報も出力します。これを使用して、キャッシュが期待どおりに使用されているかを目で確認でき、ミスなどがどこで発生しているかの目安も得られます。
バックエンドに注意を払ってください。Moodleにはキャッシュバックエンドを監視する手段がなく、それは必ず注意しておくべき点です。例えばMemcachedは、いっぱいになると、新しいエントリのための領域を確保するために使用頻度の最も低いデータを削除します。一方、APCはいっぱいになるとデータの受け入れを停止します。どちらも、いっぱいになるとパフォーマンスに影響し、ミスが発生することになります。ただし、APCはいっぱいになるとひどい状態になりますが、はるかに高速です。

パフォーマンステストに関する詳細情報

自分のサーバでのパフォーマンステストを検討している人に役立つかもしれない2つのリンクです。

負荷分散されたウェブサーバのパフォーマンスに関するアドバイス

Moodle 2.4以降で負荷分散されたウェブサーバを使用している場合は、共有ネットワークドライブ上のmoodledataにデータを保存するデフォルトのキャッシングオプションを使用しないでください。代わりにmemcachedを使用してください。Tim Huntの記事 http://tjhunt.blogspot.de/2013/05/performance-testing-moodle.html を参照してください。
Moodle 2.6以降では、config.phpで$CFG->localcachedirを（各ノードの）ローカルディレクトリに必ず設定してください。これにより、テーマ、JavaScript、ライブラリなど、MUCの外部で行われるディスクキャッシングの一部が高速化されます。

詳細情報

MUCの理解に役立つかもしれない、キャッシュ関連のフォーラムディスカッション：

Documentation