目次


memcached を使用してサイトのパフォーマンスを高める

データベースやデータ・ソースからの読み取りを減らす

Comments

はじめに

memcached はアプリケーションの処理を高速化するために使われますが、この記事ではアプリケーションや環境の中で memcached を使用するためのベスト・プラクティスに焦点を絞ることにします。ベスト・プラクティスとして紹介する内容は、キャッシュに格納すべきものと格納すべきでないもの、柔軟に分散されたデータを扱う方法、memcached を使って格納されたデータの更新を制御する方法などです。また、IBM WebSphere® eXtreme Scale などの高可用性ソリューションのサポートについても説明します。

どのようなアプリケーションでも、情報をクライアントへ返すまでの速度を最適化する必要があります。このことは、特に Web アプリケーションの多くに言えることです。一方で、同じ情報が返される場合が頻繁にあります。そうした場合に、データ・ソース (データベースまたはファイルシステム) からデータをロードするのは非効率的であり、情報にアクセスするたびに結局のところ同じクエリーを実行するのであれば、なおさらのことです。

Web サーバーの多くは、キャッシュを使用して情報を返すように構成することができます。しかし大半のアプリケーションは動的であることから、そうしたキャッシュは効果的ではありません。このような場合に memcached が役立ちます。memcached によって提供される汎用的な記憶領域には、プログラミング言語のネイティブ・オブジェクトを始めとする、あらゆるものを格納することができます。格納された多種多様な情報には、さまざまなアプリケーションや環境からアクセスすることができます。

基本

memcached はオープンソースのプロジェクトであり、多くのサーバー上にある、使用されていない RAM を利用し、頻繁にアクセスされる情報に対するメモリー・キャッシュとして動作するように設計されています。ここで重要な点は、「キャッシュ」という言葉が使われていることです。つまり memcached は、別のところからロード可能な情報に対する一時的なストレージをメモリー内に提供します。

一例として、典型的な Web ベースのアプリケーションを考えてみてください。動的に情報を提供する Web サイトであっても、そのページの存続期間中、変わることのないコンポーネントや情報があるはずです。例えばブログの中で、ページを表示するたびに個々のブログ・ポスト用のカテゴリー・リストが必ず変化する、ということはありえません。ブログ・ページを表示する都度、カテゴリー・リストの情報をロードするためにデータベースに対してクエリーを実行するのはかなり無駄な作業です。データが変更されていない場合はなおさらのことです。図 1 を見ると、ブログ・ページのいくつかの部分はキャッシュ可能であることがわかります。

図 1. 典型的なブログ・ページの中でキャッシュ可能な要素
この図はキャッシュ可能なブログ・ページの要素と、その配置を示しています。最上部に Page Header (ページ・ヘッダー) があり、左側に Current post lists (最新の投稿リスト) があり、右側には上から順に About (このブログについて)、Post History (投稿履歴)、External Links (外部リンク)、Category list (カテゴリー・リスト) が配置されています。
この図はキャッシュ可能なブログ・ページの要素と、その配置を示しています。最上部に Page Header (ページ・ヘッダー) があり、左側に Current post lists (最新の投稿リスト) があり、右側には上から順に About (このブログについて)、Post History (投稿履歴)、External Links (外部リンク)、Category list (カテゴリー・リスト) が配置されています。

この構造には他にも、投稿者の情報、コメント、さらにはブログ・ポストそのもの、などのブログ要素があることを考えると、単にホームページのコンテンツを表示するだけのために 10 回から 20 回のデータベース・クエリーやフォーマット設定が行われる場合があることがわかります。それを毎日何百回もの、さらには何千回ものページ・ビューごとに繰り返すと、サーバーとアプリケーションはページのコンテンツを表示するために実行する必要のあるクエリーをはるかに上回る数のクエリーを実行することになります。

memcached を使用すると、データベースからロードされてフォーマット設定された情報を、Web ページに直接使用できる形式で格納することができます。そしてこの情報は RAM からロードされ、データベースや他の処理を介してディスクからロードされるわけではないため、情報へのアクセスはほとんど瞬時に行われます。

繰り返すと、memcached は頻繁に使用される情報を格納し、ディスクやデータベースといった低速ソースからの情報のロードや処理を減らすためのキャッシュです。

memcached とのインターフェースはネットワーク接続によって提供されます。これはつまり、1 つの memcached サーバーを複数のクライアントで共有できるということです (または、この記事の後の方で説明するように、複数の memcached サーバーを複数のクライアントで共有することもできます)。このネットワーク・インターフェースは高速であり、また memcached サーバーはパフォーマンスを向上させるために、意図的に認証やセキュアな通信をサポートしていませんが、それによって memcached の使用方法が制限されることはないはずです。memcached サーバーはネットワークの内側部分に存在する必要があります。実用的なネットワーク・インターフェース、そして複数の memcached インスタンスを使用できるという手軽さのため、複数のマシン上にある、使用されていない RAM を活用し、全体としてのキャッシュ・サイズを大きくすることができます。

memcached では、多くの言語にあるハッシュや連想配列と似た、単純なキーワードと値のペアの形式で格納されます。memcached に情報を格納するためにはキーと値を提供し、また情報を取得するためにはキーを指定して情報を要求します。

情報がキャッシュに保持される期間は無期限ですが、以下のいずれかが発生した場合は別です。

  1. キャッシュ用に割り当てられたメモリーを使い切った場合 — この場合には、memcached は LRU (Least-Recently Used) の手法を使用してキャッシュから項目を削除します。最近使用されていない項目がキャッシュから削除され、最も古いものが最初に削除されます。
  2. 指定された項目が削除された場合 — 項目は、いつでもキャッシュから削除することができます。
  3. 項目の有効期限が切れた場合 — 個々の項目には有効期限を設定することができ、キーに対して格納されている情報が古すぎる可能性がある場合、その項目をキャッシュから削除することができます。

これらの条件をアプリケーションのロジックと組み合わせて使用することで、キャッシュの情報を確実に最新の状態に維持することができます。以上を念頭に、アプリケーションの中で memcached を最も効果的に使う方法を調べてみましょう。

どういう場合に memcached を使用するのか

memcached を使ってアプリケーションのパフォーマンスを向上させる場合、重要なプロセスやステップがいくつかありますが、そうしたプロセスやステップは変更が可能です。

情報をロードする場合の典型的なシナリオを図 2 に示します。

図 2. 情報をロードして表示するための典型的なシーケンス
この図はデータのフローを示しており、データのロード、データの処理とフォーマット設定、クライアントへのデータ送信、という順でデータが処理されることを示しています。

これらのステップを一般的に表現すると、以下のようになります。

  1. 1 つ以上のクエリーを実行し、データベースから情報をロードします。
  2. 表示 (あるいはその後の処理) に適した形式に情報のフォーマットを設定します。
  3. フォーマットが設定されたデータを使用または表示します。

memcached を使用する場合には、以下のようにアプリケーションのロジックを少し変更し、キャッシュを使用できるようにします。

  • 情報をキャッシュからロードするようにします。
  • キャッシュに情報がある場合には、キャッシュの情報を使用します。
  • キャッシュに情報がない場合には、以下の処理を行います。
    1. 1 つ以上のクエリーを実行し、データベースから情報をロードします。
    2. 表示や、その後の処理に適した形式に情報のフォーマットを設定します。
    3. その情報をキャッシュに格納します。
    4. フォーマットが設定されたデータを使用します。

以上を要約したものが図 3 です。

図 3. memcached を使用する場合の情報のロードと表示
この図は、要求されたデータがキャッシュの中にある場合、すべての処理ステップを省略して時間を節約できることを示しています。
この図は、要求されたデータがキャッシュの中にある場合、すべての処理ステップを省略して時間を節約できることを示しています。

つまり memcached を使用する場合にはデータのロードは最大で 3 段階のプロセスになり、データをキャッシュまたはデータベースからロードし、必要に応じてキャッシュに格納することになります。

このプロセスが初めて実行される場合、データはデータベースや他のソースから通常どおりロードされた後、memcached に格納されます。次にそのデータへのアクセスが行われると、そのデータはデータベースからロードされるのではなく、memcached から取得されるため、時間と CPU サイクルが節約されます。

その一方で、memcached に格納されている可能性がある情報を変更する場合、バックエンドの情報を更新すると同時に、memcached に格納されているバージョンも必ず更新します。すると図 4 の典型的なシーケンスが少し変更され、図 5 のようになります。

図 4. 典型的なアプリケーションでのデータの更新または格納
この図はデータのフローを示しており、データの更新、データの処理とフォーマット設定、更新されたデータのクライアントへの送信、という順でデータが処理されることを示しています。

図 5 は memcached を使用するように変更されたシーケンスを示しています。

図 5. memcached を使用する場合のデータの更新と格納
この図は拡張されたフローを示しており、データの更新、データの処理とフォーマット設定、memcached への格納、更新されたデータのクライアントへの送信、という順でデータが処理されることを示しています。

例えばブログをベースに考えると、ブログ・システムがデータベースの中にあるカテゴリー・リストを更新する場合、その更新は以下のシーケンスに従わなければなりません。

  1. データベースの中のカテゴリー・リストを更新します。
  2. 情報のフォーマットを設定します。
  3. その情報を memcached に格納します。
  4. その情報をクライアントに返します。

memcached の中でのストレージ操作はアトミックです。そのため、情報が更新される際にクライアントが部分的なデータしか取得できないということはなく、クライアントは古いバージョンを取得するか、あるいは新しいバージョンを取得します。

大部分のアプリケーションで注意しなければならない操作は、次の 2 つのみです。1 つは、人々が使用するデータにアクセスする操作であり、その場合は自動的にそのデータがキャッシュに追加されるようにします。もう 1 つは、データに変更を加える操作であり、その場合キャッシュに格納されているデータも自動的に更新されるようにします。

キー、名前空間、そして値

memcached を使用する場合には、キャッシュの中に格納するデータをどのように整理し、どのように名前を付けるかが、考慮すべき重要な事項としてあります。先ほどのブログの例から、一貫性のある命名構造を使用する必要があることは明らかなはずです。そうすることで、ブログのカテゴリーや履歴などの情報をロードした後、さらに情報をロードする (そしてキャッシュを更新する) 際に、あるいはデータを更新する (そしてキャッシュを更新する) 際に、既にロードされている情報を使用することができます。

具体的にどのような命名体系を使うかはアプリケーションによりますが、通常は既存のアプリケーションと同様の命名構造を使用することができます。おそらく、この構造は何らかの一意の ID をベースにしたものになるはずです。こうした命名構造が必要になるのは、データベースから情報を取得する場合、あるいは情報の集合を照合する場合などです。

ブログ・ポストの例を使うと、例えばカテゴリーのリストを category-list というキーのエントリーに格納することができます。値には、投稿 ID (blogpost-29 など) に対する 1 つの投稿に関連付けられた値を使用し、そのエントリーに対するコメントは、blogcomments-29 に格納します (29 はブログ・ポストの ID です)。このように、さまざまな接頭辞を使って情報を識別することで、膨大な種類の情報をキャッシュに格納することができます。

memcached のキーと値によるストアは単純である (しかもセキュリティーが施されていない) ため、同じ memcached サーバーを使用して複数のアプリケーションを同時にサポートしたい場合には、特定のアプリケーションに属するデータを識別するために、他の何らかの形式の修飾子を使うことを検討する必要があります。例えば、blogapp:blogpost-29 のようにアプリケーションの接頭辞を追加する方法があります。キーの形式は自由なので、キーの名前には任意のストリングを使用することができます。

値の格納に関しては、キャッシュに格納する情報が必ずアプリケーションに適しているようにする必要があります。例えばブログ・システムの場合、HTML の形で格納するのではなく、ブログ・アプリケーションがフォーマットを設定する対象となる投稿情報を格納する必要があるかもしれません。その方が、アプリケーションの複数の場所で同じ基本構造が使われている場合には、より実用的です。

Java™、Perl、PHP などを始めとする大部分の言語インターフェースは、言語オブジェクトをシリアライズして memcached の中に格納することができます。これにより、オブジェクトを完全なオブジェクトとしてメモリー・キャッシュに格納し、後で完全なオブジェクトとしてメモリー・キャッシュから取得することができるため、アプリケーションの中で手動でオブジェクトを再構築する必要がありません。オブジェクトの多くは (あるいはオブジェクトの多くで使用される構造は)、何らかのハッシュまたは配列構造をベースにしています。複数の言語が使われる環境 (例えば同じ情報を JSP 環境と JavaScript 環境とで共有する必要がある場合など) では、JSON (JavaScript Object Notation) や、さらには XML など、アーキテクチャーに依存しないフォーマットを使用することができます。

memcached にデータを格納し、memcached を使う

オープンソースの製品として、また、元々は既存のオープンソース環境の中で使うために開発された製品として、memcached は広範な種類の環境やプラットフォームでサポートされています。memcached サーバーと通信するためのインターフェースは数多くあり、多くの場合、すべての言語に対して複数の実装があります。一般的なライブラリーやツールキットに関しては「参考文献」を参照してください。

サポートされ、提供されているインターフェースや環境をすべて挙げることはできませんが、それらのインターフェースや環境はすべて、memcached プロトコルで提供される基本 API をサポートしています。以下の説明は単純化してあり、言語が異なると表示されるエラーの値は異なる場合があるという前提で見てください。主な関数は以下のとおりです。

  • get(key) — 指定されたキーの情報を memcached から取得します。そのキーが存在しない場合にはエラーを返します。
  • set(key, value [, expiry]) — データを識別するためのキーを使って、指定された値をキャッシュに格納します。既にキーが存在する場合には、そのキーの値が更新されます。expiry で指定される有効期限は秒単位であり、その値が 30 日 (30*24*60*60) よりも小さい場合には相対時間と見なされ、30 日以上の場合には絶対時間 (エポック) と見なされます。
  • add(key, value [, expiry]) — キーが存在しない場合にはキャッシュにキーを追加し、既にキーが存在している場合にはエラーを返します。これは新しいキーを明示的に追加したい場合で、キーが既に存在している場合にはそのキーの値が更新されるのを避けたい場合に便利です。
  • replace(key, value [, expiry]) — 指定されたキーの値を更新し、キーが存在しない場合にはエラーを返します。
  • delete(key [, time]) — キーと値のペアをキャッシュから削除します。時間を指定すると、その指定された時間はこのキーを使って新しい値を追加しようとしてもブロックされます。指定された時間が経過すると、必ずデータ・ソースから再度値が読み取れるようになります。
  • incr(key [, value]) — 指定されたキーの値を 1、もしくは指定された値だけインクリメントします。使用できる値は数値のみです。
  • decr(key [, value]) — 指定されたキーを 1、もしくは指定された値だけデクリメントします。使用できる値は数値のみです。
  • flush_all — 現在キャッシュの中にあるすべての項目を無効 (つまり期限切れ) にします。

例えば Perl では、memcached の基本操作はリスト 1 のように扱われます。

リスト 1. Perl での memcached の基本操作
use Cache::Memcached;

my $cache = new Cache::Memcached {
    'servers' => [
                   'localhost:11211',
                   ],
    };

$cache->set('mykey', 'myvalue');

Ruby で同じ基本操作を行う場合には、リスト 2 のようになります。

リスト 2. Ruby での memcached の基本操作
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'

memc["mykey"] = "myvalue"

どちらの例にも、同じ基本構造があることがわかります。つまり memcached サーバーを設定してから、値の割り当てや設定を行っています。Java 技術で使われるインターフェースを始めとし、インターフェースは他にもあり、そうしたインターフェースを利用することで WebSphere アプリケーションの中で memcached を使うことができます。memcached のインターフェース・クラスを利用すると、Java オブジェクトを直接 memcached の中にシリアライズすることができるため、複雑な構造を格納し、ロードすることができます。WebSphere のような環境で使用する場合、非常に重要なことが 2 つあります。1 つはサービスのレジリエンシー (そして memcached が利用できない場合にどうするか) で、もう 1 つは複数のアプリケーション・サーバーを使用する場合、あるいは WebSphere eXtreme Scale のような環境を使用する場合に、どのようにキャッシュのストレージを増やしてパフォーマンスを向上させるか、です。この 2 つの問題の両方について、次のセクションで調べてみましょう。

レジリエンシーと可用性

memcached に関する最も一般的な質問の 1 つが、「キャッシュが利用できない場合にはどうなるのか」という質問です。ここまでのセクションで明らかなはずですが、キャッシュの中にある情報が唯一の情報ソースであってはなりません。キャッシュに格納されたデータは、どこか他の場所からロードできる必要があります。

実際には、キャッシュの情報にアクセスできない場合、アプリケーションのパフォーマンスは低下するかもしれません。しかしそれによってアプリケーションが機能停止するようなことがあってはなりません。起こりうるシナリオとしては以下に示す内容が考えられます。

  1. memcached サービスが利用できなくなった場合、アプリケーションは memcached を使用しないときの状態に戻り、元のデータ・ソースから情報をロードし、その情報を必要に応じてフォーマット設定して表示する必要があります。またアプリケーションは、memcached からの情報のロードと memcached への情報の格納を継続的に試みる必要があります。
  2. memcached サーバーが再度利用可能になった場合には、アプリケーションは自動的にデータの格納を試みる必要があります。キャッシュされたデータを強制的にリロードする必要はなく、標準的なアクセス方法でキャッシュから情報をロードし、また情報をキャッシュに格納します。最終的に、最もよく使われるデータがキャッシュに再度格納されます。

繰り返すと、memcached は情報のキャッシュであり、唯一の情報ソースではありません。memcached サーバーが使えなくなった場合、memcached サーバーが復帰するまでパフォーマンスが低下するかもしれませんが、アプリケーションが使えなくなるようであってはなりません。実際には、memcached サーバーはかなり単純です。クラッシュしないとは言えませんが、単純さからエラーは稀にしか発生しません。

キャッシュを分散する

memcached サーバーは、ネットワークを介してキーに対する値を格納するキャッシュにすぎません。複数のマシンがある場合、使われていないマシンのすべてに memcached のインスタンスを設定し、ネットワーク化された大量の RAM キャッシュ・ストレージを提供したくなります。

この概念を考える場合、キーと値のペアをマシン間にコピーする何らかの分散メカニズムまたは複製メカニズムが必要であると考えがちですが、この考えに基づく方法の問題は、実際には利用可能な RAM キャッシュは増加せず、減少してしまうことです。図 6 を見ると、3 つのアプリケーション・サーバーがあり、それぞれが memcached のインスタンスにアクセスしていることがわかります。

図 6. 複数の memcached インスタンスを不適切に使用している例
この図には独立した 1 GB の memcached インスタンスが 3 つあり、3 つのアプリケーション・サーバーをサポートすることで、それぞれが 1 GB のキャッシュ空間を実現しています。
この図には独立した 1 GB の memcached インスタンスが 3 つあり、3 つのアプリケーション・サーバーをサポートすることで、それぞれが 1 GB のキャッシュ空間を実現しています。

各 memcached インスタンスのサイズはそれぞれ 1 GB (合計で 3 GB の RAM キャッシュ) ですが、各アプリケーション・サーバーがサーバー自身のキャッシュしか持たない場合には (または memcached インスタンス間でデータの複製があった場合には)、システム全体では相変わらず 1 GB のキャッシュが各インスタンス間で重複しているにすぎません。

memcached はネットワーク・インターフェースを介して情報を提供するため、クライアントは、そのクライアントからアクセス可能な任意の memcached インスタンスのデータにアクセスすることができます。各インスタンスの間でデータがコピーされたり重複したりしていなければ、各アプリケーション・サーバーで 3 GB の RAM キャッシュを利用できることになります (図 7)。

図 7. 複数の memcached インスタンスを適切に使用した例
この図には相互にやり取りする 1 GB の memcached インスタンスが 3 つあり、3 つのアプリケーション・サーバーをサポートすることで、全体として 3 GB の共有キャッシュ空間を実現しています。
この図には相互にやり取りする 1 GB の memcached インスタンスが 3 つあり、3 つのアプリケーション・サーバーをサポートすることで、全体として 3 GB の共有キャッシュ空間を実現しています。

この方法では、キーと値のペアを格納する対象となるサーバーを選択する方法と、値を取得したい場合、どの memcached サーバーと通信するのかをどのように決定するのか、という点が問題になります。この問題に対する解決策は、ルックアップ・テーブルのような複雑なことは無視するか、memcached サーバーが自動的にプロセスを処理してくれるのを期待することですが、memcached クライアントは単純に考える必要があります。

memcached クライアントは通信相手となるサーバーを決定するのではなく、情報を格納する際に指定されるキーに対し、単純なハッシュ・アルゴリズムを使用します。一連の memcached サーバーに情報を格納する場合、あるいは一連の memcached サーバーから情報を取得する場合、memcached クライアントは一貫したハッシュ・アルゴリズムを使用することで、キーから数値を引き出します。例えば、mykey というキーは 23875 という値に変換されます。情報を格納するのか取得するのかとは無関係に、常に同じキーを一意に決まる ID として使用し、memcached サーバーからロードします。そのため、mykey は必ず、23875 という値のハッシュを取得します (これはこの例の場合での話です)。

2 つのサーバーがある場合、memcached クライアントはこの数値を取得し、その数値に対して単純な計算を実行し (例えばモジュロを計算し)、1 番目に構成された memcached インスタンスにその値を格納するのか、あるいは 2 番目に構成された memcached インスタンスに格納するのかを判断します。

値を格納する場合、クライアントは、キーおよびそのキーの格納に使われるサーバーの情報からハッシュ値を判断します。値を取得する場合、クライアントはキーから同じハッシュ値を判断し、同じサーバーを選択して情報を取得します。

すべてのアプリケーション・サーバーで同じサーバー・リストを (同じ順序で) 使用する場合、同じキーを格納または取得するように指示されると、すべてのアプリケーション・サーバーは同じサーバーを選択します。ここでは、同じ 1 GB の空間を複製として利用するのではなく 3 GB の memcached 空間として共有しているため、より多くのキャッシュを使うことができ、ほとんどの場合、より多くのユーザーに対応できるようにアプリケーションのパフォーマンスを向上させることができます。

このプロセスには複雑な部分がありますが (サーバーが利用できない場合にどうなるか、など)、memcached のドキュメントには詳しい説明がされています (「参考文献」を参照)。

memcached を使ってはならない場合

memcached は単純ですが、memcached のインスタンスを想定外の方法で使ったり、また場合によると望ましくない方法で使ったりしたくなる場合があります。

memcached はデータベースではない

memcached の誤った使い方として最もよくあるのは、キャッシュとしてではなく、データ・ストアとして使用する使い方です。memcached の一番の目的は、memcached を使わない場合には他のソースから取得したり、取得して組み立てたりすることになるデータに対し、そのデータを取得するまでの時間を短縮することです。その一例は、データベースから情報を取得する場合で、特に、取得した情報をフォーマット設定したり、操作したりしてからユーザーに表示する場合などです。memcached は、こうして加工された情報をメモリーに格納しておくことで、データが必要になるたびにそのタスクを繰り返し実行する必要がないように作られています。

アプリケーションを実行するための唯一の情報ソースとして memcached を使ってはいけません。memcached に含まれるデータは、いつでも他のソースから取得できる必要があります。また、memcached はキーと値の単なるストアにすぎないことを頭に入れておく必要があります。memcached に含まれているデータに対してクエリーを実行したり、memcached の内容を繰り返し処理して情報を抽出したりすることはできません。memcached は、何度も使用する必要のあるデータのブロックやオブジェクトを保存するために使用すべきものです。

データベースの行やファイルをキャッシュしない

データベースからロードされた何行ものデータを格納するのに memcached を使うことはできますが、その使い方は実際にはクエリー・キャッシュであり、大部分のデータベースには専用のクエリー・キャッシュ・メカニズムが用意されています。同じことは、画像やファイルシステムのファイルなど、他のオブジェクトにも言えます。多くのアプリケーションや Web サーバーには、そうした種類の作業のために、十分に最適化されたソリューションが既に用意されています。

情報をロードしてフォーマット設定した後、memcached を使って情報の全ブロックを格納すると、使い勝手とパフォーマンスを向上させることができます。ブログの例の場合、情報を格納するのに最も適したタイミングは、ブログのカテゴリーをオブジェクトとしてフォーマット設定した時点、あるいは HTML のフォーマットにした後です。するとブログ・ページの作成は、コンポーネント (ブログ・ポスト、カテゴリー・リスト、投稿履歴など) を memcached からロードし、完成した HTML をクライアントに書き戻すだけでよくなります。

memcached はセキュアではない

memcached は確実に最高のパフォーマンスが得られるようにするために、認証であれ、暗号化であれ、どんな形のセキュリティーも提供していません。これはつまり、アプリケーションをデプロイした環境と同じプライベート側のゾーンに memcached サーバーを配置して memcached サーバーへのアクセスを処理する必要があり、またセキュリティーが必須の場合には UNIX® のソケットを使用し、現在のホスト上にあるアプリケーションのみが memcached サーバーにアクセスできるようにする必要がある、ということです。

そうした対策により、柔軟性やレジリエンシーが多少失われ、またネットワークを介して複数のマシンで RAM キャッシュを共有することができなくなりますが、memcached のデータをセキュアにする必要がある場合には、上記の方法が唯一のソリューションです。

限定的に考えすぎない

memcached のインスタンスを使ってはならない場合を理解する必要はありますが、memcached の柔軟性を無視すべきではありません。memcached はアーキテクチャー上、アプリケーションと同じレベルにあるため、アプリケーションに memcached を統合したり、アプリケーションから memcached に接続したりするのは簡単です。また、memcached を利用するようにアプリケーションを変更するのも複雑ではありません。さらに、memcached は単なるキャッシュであるため、問題が発生した場合もアプリケーションが実行を停止してしまうことはないはずです。memcached は、適切に使用すれば、(データベースやデータ・ソースからの読み取りを減らすことで) サーバー・インフラストラクチャーの他の部分の負荷を下げることができます。つまり、ハードウェアを追加しなくても、より多くのクライアントをサポートできるということです。

ただし、memcached は単なるキャッシュにすぎないことを忘れないでください。

まとめ

この記事では、memcached について、また memcached の最も効果的な使い方について説明しました。具体的には、情報の格納、適切なキーの選択、格納する情報の選択などの方法について説明しました。また、memcached を使用する場合に誰もが経験する重要な問題として、複数のサーバーを使う場合や、memcached のインスタンスが異常終了した場合にどうすべきか、そしておそらく最も重要な事項として、memcached を使ってはならない場合などについても見てきました。

非常に単純な目的を持つオープンソースのアプリケーション memcached の強力さと使いやすさはその単純さからもたらされています。情報用に大量の RAM ストアを提供し、その RAM ストアをネットワーク経由で利用できるようにすることで、多種多様なインターフェースや言語で利用できるようになることから、非常にさまざまなシステムに memcached を統合することができます。


ダウンロード可能なリソース


関連トピック

  • memcached の使い方に関する MySQL のドキュメントには、データベースがデプロイされる典型的な環境の中で memcached を使う方法について、大量の情報が用意されています。
  • IBM による商用のキャッシュ・ソリューション、solidDB® について学ぶために、IBM の solidDB 製品ファミリーについて調べてください。
  • developerWorks podcasts ではソフトウェア開発者のための興味深いインタビューや議論を聞くことができます。
  • developerWorks を Twitter でフォローしてください。
  • developerWorks の Open source ゾーンをご覧ください。オープンソース技術を使った開発や、IBM 製品でオープンソース技術を使用するためのハウ・ツー情報やツール、プロジェクトの更新情報など、豊富な情報が用意されています。また最も人気の高かった記事とチュートリアルの一覧もご覧ください。
  • My developerWorks コミュニティーは広範な話題を網羅した全般的なコミュニティーとして成功している一例です。
  • memcached.org には、memcached に関する情報や、memcached のダウンロード方法やインストール方法が説明されています。
  • Perl 用の Cache::Memcached インターフェースは充実したインターフェースです。
  • Java 技術には com.danga.MemCached クラスを使用することができます。このクラスには、他にもフェールオーバーや複数インスタンスのための拡張機能が用意されています。
  • IBM 製品の評価版をダウンロードするか、あるいは IBM SOA Sandbox のオンライン試用版で、DB2®、Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品を試してみてください。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, XML
ArticleID=516799
ArticleTitle=memcached を使用してサイトのパフォーマンスを高める
publish-date=08032010