このページでは、Memorystore for Memcached を使用する際のベスト プラクティスを説明します。
キャッシュミスを処理するようにアプリケーションを構築する
キャッシュミスとサービスの非可用性に対処するために、キャッシュを設計し、標準的なキャッシュ設計のベスト プラクティスに従う必要があります。Memorystore for Memcached の稼働時間のコミットメントについては、サービスレベル契約をご覧ください。
キャッシュミスや一時的なサービス ダウンタイムが発生しても Memcached インスタンスでサポートされる基盤となるデータベースからのアプリケーションによるデータの取得が停止しないように、アプリケーションを設計してください。
また、キースペースを利用できない場合は、待機し、指数バックオフを使用して再試行してください。再試行を中止する時間制限を設定するようにしてください。
Memcached ノードへの接続
set、get、delete などのコマンドで Memcached ノードをクエリする場合は、ノードの IP アドレスに直接接続する必要があります。これらのコマンドは、Auto Discovery エンドポイントで実行できますが、アプリケーションのパフォーマンスの低下をもたらすため、おすすめしません。
自動検出を推奨
Memorystore for Memcached Auto Discovery サービスを使用することをおすすめします。このサービスは、クラスタにノードを追加または削除する際の、クラスタの IP アドレスの管理を自動化します。クラスタの自動検出の設定手順については、Auto Discovery サービスの使用をご覧ください。
max-item-size パラメータの適切な構成
このセクションでは、max-item-size パラメータの最適な構成方法について説明します。この構成パラメータを調整する手順については、Memcached インスタンスの構成をご覧ください。使用可能な Memcached 構成パラメータの完全なリストについては、Memcached の構成をご覧ください。
サポートされている値とデフォルト値
オープンソースの Memcached では、max-item-size の最小値は 1KiB、最大値は 1 GiB、デフォルト値は 1 MiB です。Memorystore for Memcached では、最小値は 512 KiB、最大値は 128
MiB、デフォルト値は 1 MiB です。また、この構成に設定する任意の値は、512 KiB で割り切れる必要があります。
構成された max-item-size より大きいエントリのキャッシュ保存
構成された max-item-size より大きいエントリをキャッシュ保存しようとすると、Memcached はオペレーションを失敗し、false を返します。可能であれば、ロジックをアプリケーションにビルドして、Memcached OS からのこのエラーを表示してデバッグできるようにします。構成された max-item-size より大きいエントリをキャッシュ保存しようとすると、インスタンスで高レイテンシが発生する可能性があります。
max-item-size を最大値に設定する
max-item-size パラメータを最大値に設定することで、いくつかの問題を解決できます。ただし、この方法はおすすめしません。本番環境でこの方法を使用しないでください。Memcached のメモリ管理はスラブに基づいており、スラブを超えるアイテムを保存すると、メモリの非効率的な割り当てにつながります。
max-item-size 構成の問題の回避
まず、キャッシュに必要な最大アイテムサイズを確認します。max-item-size を、念のためにマージンを取って、最も大きいアイテムサイズよりも少し大きいサイズに設定します。
キャッシュに書き込まれた値のサイズは、時間の経過とともにアプリケーション内で変更される可能性があるので注意してください。また、クラスタが誤って構成されている可能性もあります（たとえば、ある環境から別の環境に移行するとき）。実行できる追加の方法は、アプリケーションで最大アイテムサイズを検証することです。これにより、構成された設定を超えるアイテムをアプリケーションがキャッシュに保存しようとすると、リクエストが拒否されます。
バランスのとれていない Memcached クラスタのバランスをとる方法
バランスのとれていないクラスタが発生する仕組みとそれに関連するリスク
まれな状況として、Memcached インスタンスを作成するときに、ノードがリージョン内のゾーンに不均等に分散されることがあります。これは、クラスタのプロビジョニングをする時点でゾーンが使用できない場合に発生します。
バランスのとれていないクラスタでは、ノードが可能なようには均等に分散されないため、データ損失の可能性が高くなります。停止したゾーンがオンラインに戻ったときに、クラスタは自動的にリバランスしません。
クラスタをリバランスする方法
クラスタ内のノード数を一時的に増やしてから、ノード数を元のノード数までスケールダウンすることで、クラスタをリバランスできます。このスケールアップとスケールダウンのアクションにより、Memorystore for Memcached システムは使用可能なゾーン間で均等にノードを再分配できます。
クラスタをリバランスするためのこの方法の成否は、問題のゾーンの可用性に依存します。現時点では、Google Cloud は使用可能なゾーンと使用可能なゾーンを一覧表示していないため、スケーリング オペレーション時にノードが正しくバランスされている場合にのみ、ゾーンがオンラインであるかどうかを判断できます。
Cloud Monitoring のベスト プラクティス
キャッシュのパフォーマンスの推移をトラッキングするには、Cloud Monitoring を使用して、いくつかの重要な Memorystore for Memcached の指標をモニタリングする必要があります。
- メモリ使用量（
memcache.googleapis.com/node/cache_memory） - CPU 使用率（パーセント）（
memcache.googleapis.com/node/cpu/utilization）
この 2 つの指標の推移をトラッキングすると、クラスタがどれだけ効率に使用されているか、クラスタのサイズを増やすか下げする必要があるかを判断する際に役立ちます。
たとえば、指標がメモリ使用率と CPU 使用率が時間とともに 80% を超えて増加していることを示している場合、この傾向が続く可能性があります。その結果、アプリケーションのリソースの要件の増加に伴って、キャッシュに新しい値を保存する場所があるように、インスタンスのサイズを早期に増やすことが可能です。
メモリ使用量と CPU 使用率が 80% に達したときのためのアラートを設定することをおすすめします。
代わりに、これらの指標の推移をトラッキングすると、現在の容量と CPU リソースのすべてを使用しているわけではないことを示す可能性があります。この場合、クラスタのサイズを減らすと費用対効果が高くなります。
次のステップ
- Auto Discovery サービスの詳細を確認する。
- 変更可能な Memcached 構成パラメータを確認する。