Google Cloud Marketplace を見ていると、とてもバリエーションが豊富で様々なソリューションが有ります。
前回行った、WordPress プラグインの W3 Total Cache の導入の際に memcached を扱いましたが、今回はこのMarketplaceにある Memcached packaged by Bitnami ソリューションを用いて専用インスタンスを稼働させる記事です。
Memcached packaged by Bitnami の構成
2022-11-22 時点での本ソリューションの主たる状態
| OS/Software | Version |
|---|---|
| Debian | 11 |
| memcached | 1.6.17 |
今回の目的
W3 Total Cache の導入の際に行った、WordPressが稼働している W3 Total Cache の memcached のホストを localhost 127.0.0.1 から別のホスト・インスタンスへと切り替えてみます。
localhost で稼働している memcached は停止することを前提とします。
# systemctl stop memcached
WebServer上で memcached プロセスが稼働していることによるシステム負荷はそれほど高くなさそうなのでコスト見合いな部分もありますが、興味の範疇でもあるためチャレンジしてみます。
アクセス数が多い高負荷な状態のWordPressを運用している場合などは、memcachedを外出しにすることで負荷分散が行えるためそれなりの効果は出てくるであろうと予想できます。
nginx, PHP, MariaDB 等が稼働している同一インスタンスWebServerの役割の中で少しでも負荷を下げることにはなるでしょう。なので、こういったソリューションが存在しているとも言えますね。
また、GCPの同一VPC内でインスタンスを稼働させることによりネットーワークトラフィックを最小限に留めます。
これは、WebServerインスタンス内部にあったmemcachedを別インスタンスに移したことによって発生するインスタンス間通信のレイテンシを最小限にすることです。
memcachedの特性として、グローバルIPでの利用は避けたほうが良いでしょう。特にポート開放は危険が伴うこともありますが、レイテンシ的な観点からも外部IPアドレスでの運用は行うべき構成ではなく、避けたほうが無難です。
もし、同一VPC内ではない場合などは VPCネットーワークピアリング という方法で可能な限り低レイテンシを目指したほうが良さそうです。
※ localhost にインストールしていて使われなくなった memcached は依存関係のある不要なライブラリごと削除しておいた方が良いでしょう。
# apt-get purge --auto-remove memcached*
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'memcached' for glob 'memcached*'
Package 'memcached' is not installed, so not removed
The following packages will be REMOVED:
libevent-2.1-7*
0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
After this operation, 462 kB disk space will be freed.
Do you want to continue? [Y/n] Y
(Reading database ... 64174 files and directories currently installed.)
Removing libevent-2.1-7:amd64 (2.1.12-stable-1) ...
Processing triggers for libc-bin (2.31-13+deb11u5) ...
インスタンススペックの選定
インスタンスのスペックは用途に応じて慎重に検討する必要がありますが、マシンタイプ（コア数、メモリ）は設定変更が容易なため、検証の段階で最小限の規模で立ち上げても特に問題は無いかと思います。
ソリューションを立ち上げるときには共有コアの最小スペックが提示されていましたが、今回は e2-small（0.5〜2vCPU, 2GBメモリ）としてみました。
Memcached packaged by Bitnami インスタンスの諸設定
インスタンスが起動し、内容確認のためにSSHコンソールからmemcachedの存在を確認してみました。
# systemctl status memcached
Unit memcached.service could not be found.
あれ、動いていない。
ここは、bitnamiの専用ソリューションですので、systemctl の管理下では無さそうです。
Memcached packaged by Bitnami のマニュアルを見てみると、丁寧に記載されていました。
# /opt/bitnami/ctlscript.sh status
memcached already running
ctlscript.sh でみてみると確かに動作していました。プロセスも稼働中です。
# ps ax | grep memcached
6054 ? Ssl 2:48 memcached -u memcached -p 11211 -v -m 1024 -c 4096 -t 4 -d -P /opt/bitnami/memcached/tmp/memcached.pid
8448 pts/1 S+ 0:00 grep memcached
localhost に対してポートスキャンを実施。既定の11211 ポートはopenとなっていました。
# nmap -p 1-65535 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-23 03:07 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000030s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 65531 closed ports
PORT STATE SERVICE
22/tcp open ssh
11211/tcp open memcache
20201/tcp open unknown
20202/tcp open ipdtp-port
稼働したmemcachedインスタンスはエフェメラルでのグローバルIPが割当されますが、他のインスタンスからmemcachedインスタンスのグローバルIPに対しても同様にポートスキャンを実施してみます。
# nmap -p 1-65535 34.84.xxx.xxx
Starting Nmap 7.80 ( https://nmap.org ) at 2022-11-23 12:17 JST
Stats: 0:01:17 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 67.77% done; ETC: 12:19 (0:00:37 remaining)
Nmap scan report for xxx.xxx.84.34.bc.googleusercontent.com (34.84.xxx.xxx)
Host is up (0.00056s latency).
Not shown: 65533 filtered ports
PORT STATE SERVICE
22/tcp open ssh
3389/tcp closed ms-wbt-server
Nmap done: 1 IP address (1 host up) scanned in 104.20 seconds
sshポートのみがopenされていることを確認。（万が一、11211ポートがopenとなっていた場合には閉じたほうが良いでしょう）
特に設定を施さずに、memcachedの専用インスタンスが使える状態となっている様子です。
表向きには内部IPでのアクセスが出来る状態だと言うことが分かるだけなので、実際には他の WordPressインスタンス側からの設定ができるか、またはサンプルプログラムを動作させて確認するのが良さそうです。
WordPressインスタンスの Memcached username, passwordの設定
本ソリューション Memcached packaged by Bitnami では、初期状態として SASL認証が有効となって設定された状態になっています。
これは、ソリューションを起動したときに初期設定される
- Admin user : root
- Admin password (Temporary) : password
の設定がされていました。
下記のコマンドにより、既に設定されているユーザーが一覧されますがパスワードは “userPassword” として一律表示されるだけで、本来設定されているパスワードは表示されません。
また、下記の例の様に username@memcached-1-vm といったような表記であり、@以降はインスタンス名が表示されていました。（最初はこの表記が理解できず戸惑いましたが）
# /usr/sbin/sasldblistusers2 -f /opt/bitnami/memcached/conf/sasl2/memcachedsasldb
kworks@memcached-1-vm: userPassword
root@memcached-1-vm: userPassword
root ではなく他のユーザーを追加することも出来ました。
上記は kworks と root が存在している一覧です。
詳しいマニュアルはこちら Add or List Users
しかし、2022-11-23 時点 WordPress (6.1.1) の W3 Total Cache ( 2.2.7)ではどうしてか username, password を設定しても「テスト失敗」となり接続が確立出来ない様子です。
これを検証するために、サンプルプログラムを用いて、WordPressのインスタンスから、memcachedインスタンスへPHPでの接続を試みてみます。
サンプルプログラムの動作
こちらに、example.php というサンプルを動作させるマニュアルが掲載されています。
curl -o php-memcache-sasl-master.zip 'https://codeload.github.com/hull-graveyard/php-memcache-sasl/zip/master'
unzip php-memcache-sasl-master.zip
今回の環境に合わせて example.php の内容を書き換えて実行してみます。
addServer('10.146.0.30', '11211');
setSaslAuthData('root', 'passoword'); // password は初期設定されたもの
<?php
include('MemcacheSASL.php');
$m = new MemcacheSASL;
$m->addServer('10.146.0.30', '11211');
$m->setSaslAuthData('root', 'password');
var_dump($m->add('test', '123'));
$var = $m->get('test');
$m->delete('test');
print "$var";
php example.php
結果としては、SASL認証はこのサンプルプログラム上では問題なく動作している様子で、上述により結果が返ってきていることが分かりました。
123
では、何故 WordPress W3 Total Cache では「テスト失敗」となるのか。
少し調べてみましたが、Memcached test using SaslAuth として報告が上がっていたので、バグなのか何れにしても未対応の様子です。example.php では接続確立が出来ていそうなので、仕様上では実現出来ているはずですが…
それ以外には情報が見当たらず W3 Total Cache も無償版を使っていることもあり、余力もなかったので現時点では memcached の SASL認証の無効化をしてみることにしました。
W3 Total Cache 不具合なのかは定かでは有りませんが、ここは目先の回避策を講じます。
かろうじて同一VPC内でのコネクションとなるため、SASL認証を無効化しても問題は無さそうだと判断しました。
SASL認証が有効な状態で接続が行えないことはWordPress側の不具合かとも思われるため一旦は様子見で、必要に応じてSASL認証は戻した方が無難だと思われます。
SASL認証の無効化
このSASL認証を無効にするためのマニュアルがこちらです。 Start Memcached Without SASL Authentication
sasl2 ファイルを別名にして memcachedを再起動させればOKのようです。
sudo mv /opt/bitnami/memcached/conf/sasl2 /opt/bitnami/memcached/conf/sasl2.disabled
sudo /opt/bitnami/ctlscript.sh restart
WordPress Memcachedホストの変更
これまで、W3 Total Cache のホスト名に localhost である 127.0.0.1:11211 を設定していた箇所を、memcached インスタンスの内部IPアドレスへ設定し直します。
複数のサーバーを利用可能です、と注釈がある通り 127.0.0.1:11211,10.146.0.30:11211 と指定してみましたところ、動作している様子でした。 厄介なのは、これらがどの様に取り回されるのかを正確に理解していない点です。 データベースレプリケーションの様なことかな？と想像しながら、複数にすることで逆に負荷が高まることも懸念されるため、単一ホスト指定にしました。
ページキャッシュ、圧縮、データベースキャッシュ、オブジェクトキャッシュ、と4箇所の設定を全て下記のように変更。
設定し直して「テスト合格」となった様子。
単純に、ブラウザアクセスでの体感はしにくい高速化に対する構成のリビルドですが、なかなか面白いと思っています。
高負荷なWordPressを運用している状況では有効に働いてくれそうです。
キャッシュの中を確認
libmemcached-tools をインストールします。
# apt-get install libmemcached-tools
memcdump コマンドで、キーの一覧を見てみます。
途中を端折っていますが、膨大に表示されました。
# memcdump localhost:11211
w3tc_2098600461_0_pgcache__key_version
w3tc_2098600461_0_dbcache_singletables_key_version
.....
w3tc_2098600461_k.works_0_object_f1bd82e23190428aa4632f823aaea403
w3tc_2098600461_k.works_0_object_fcd55ed28228bdbe5b269adb242b738c
.....
w3tc_497066697__0_pgcache_b618f5cf271c2254a10256a1daa5e00b
w3tc_497066697__0_pgcache_eb7bc41a4f1d727b782f63f307fd83fb
.....
memcdump を例として、
こんな感じで memc….. というコマンド類が色々あります。
https://manpages.debian.org/jessie/libmemcached-tools/index.html
man memcdump
MEMDUMP(1) libmemcached MEMDUMP(1)
NAME
memdump - libmemcached Documentation
Dump a list of keys from a server.
SYNOPSIS
memdump [options]
DESCRIPTION
memdump dumps a list of "keys" from all servers that it is told to fetch from. Because memcached does not guarentee to provide all keys it is not
possible to get a complete "dump".
OPTIONS
For a full list of operations run the tool with option:
--help
HOME
To find out more information please check: http://libmemcached.org/
AUTHOR
Brian Aker, <brian@tangent.org>
SEE ALSO
memcached(1) libmemcached(3)
AUTHOR
Brian Aker
COPYRIGHT
2011-2013, Brian Aker DataDifferential, http://datadifferential.com/
1.0.18 February 09, 2014 MEMDUMP(1)
複数のWebServerインスタンスから memcachedインスタンスへ
今回は同一VPC内にある、2台のWordPressから W3 Total Cache を通して、memcachedインスタンスへホストするようにしてみました。
[インスタンス1] ┓
┣[memcachedインスタンス]
[インスタンス2] ┛
opsエージェントをインストールした memcached インスタンスの状態を見ても、それほど高負荷にはならずにいるようです。
これが高負荷のWordPress運用の状況では異なってくるのかとは思いますが．．．
bitnami の 設定を変更してみる
memcached の conf が多種用意されているようでしたので、マニュアルには記載のないものですが、試してみました。
root@memcached-1-vm:/opt/bitnami/memcached/conf# ls -la
total 16
drwxrwxr-x 4 root root 4096 Nov 22 15:07 .
drwxr-xr-x 8 root root 4096 Nov 9 22:10 ..
drwxr-xr-x 2 root root 4096 Nov 9 22:10 bitnami
lrwxrwxrwx 1 root root 26 Nov 22 15:07 memory.conf -> bitnami/memory-small.conf
drwxrwxr-x 2 root root 4096 Nov 22 09:40 sasl2.disabled
root@memcached-1-vm:/opt/bitnami/memcached/conf# ls -la bitnami/
total 32
drwxr-xr-x 2 root root 4096 Nov 9 22:10 .
drwxrwxr-x 4 root root 4096 Nov 22 15:07 ..
-rw-r--r-- 1 root root 201 Nov 9 22:10 memory-2xlarge.conf
-rw-r--r-- 1 root root 199 Nov 9 22:10 memory-large.conf
-rw-r--r-- 1 root root 199 Nov 9 22:10 memory-medium.conf
-rw-r--r-- 1 root root 197 Nov 9 22:10 memory-micro.conf
-rw-r--r-- 1 root root 198 Nov 9 22:10 memory-small.conf
-rw-r--r-- 1 root root 200 Nov 9 22:10 memory-xlarge.conf
初期設定では、memory-small.conf がリンクされており、MEMCACHED_CACHE_SIZE=512 として設定されるようです（512MB）
memory-medium.conf へ変更してみます。（1024MB）
# ln -snf bitnami/memory-medium.conf memory.conf
シンボリックリンクの再設定後にmemcachedを再起動します。
# /opt/bitnami/ctlscript.sh restart
上述の通り、本インスタンスは 2GBメモリで構成しているため、これでも余裕があるとは思いますが、WordPressからのアクセスの状況、メモリ消費量などを監視して調整することで最適な運用が行えるかと思います。
今回は、Memcached packaged by Bitnami を用いてみましたが、なかなか素晴らしいソリューションだと思います。
ソリューション費用は無償ですが、もちろん GCPのインスタンス費用はプラスONされます。
素のWordPress運用からは明らかに表示が「爆速」と言える状態に近づいてきました。
男子たるもの高速なモノには興味が尽きないわけですが、昨今ガソリン代も高騰していますし、車ではなく別な趣味としてGCPインスタンスでWordPressを高速化して楽しんでみるのも良いかもしれませんね。
記事の内容が古くなっているものもあり、適宜アップデートされる場合がございます。