7/31 と 8/1 の20時くらいから深夜0時過ぎくらいまで、当サイトへアクセスすると、
Service Temporarily Unavailable
と表示されて、何も閲覧状態できない状態が続いていました。
この時間帯にコンテンツを確認したかった方々にお詫び申し上げます。
実は、www.limber.jp は CMS として、WordPress を使っており、さくらのVPS
上にありますが、www.limber.jp 自体はリバース・プロキシだったりします。つまり、WordPress 自体はリバース・プロキシ(mod_proxy)の後ろに隠れており、別契約の さくらのVPS
上で MySQL とともに動いており、今回問題が生じていたサーバはバックエンド側の VPS でした。
絵にすると下記のようなイメージです。
契約は同一の さくらのVPS
ですが、RTT が 7, 8ms あるため、おそらく東京と大阪くらいは離れていると思います。
本当は同時に契約して同じデータセンター内の VPS にしておけばよかったのですが、バックエンド側の VPS は別用途に使っていたのを今回 WordPress に移行するにあたってバックエンドのアプリケーションサーバ兼データベースサーバに転用したと事情があります。
WordPress をフロント側にして、データベースをバックエンドにしても、RTT が 7ms もあると、データの取得に時間がかかってしまうので、このような構成になりました。
»メリットとデメリット
WordPress と MySQL をバックエンドに配置し、フロンエンドは単なるリバース・プロキシにすることにはメリットもあります。
リバース・プロキシとしては Apache2 に mod_proxy と mod_cache, mod_disk_cache を有効にして使っているため、.jpg や .png などの画像データや .html などの静的なデータなどをキャッシュ1 してくれるため、アクセス速度の向上が期待できます。
WordPress 側は WP Super Cache プラグインを使って、コンテンツをキャッシュしていますが、リバースプロキシ側ではそのデータをキャッシュしないので、二重のキャッシュによってコンテンツがいつまでも古いまま、という状態を防いでいます。
うん？ だったら、バックエンド側の WP Super Cache をやめて、リバース・プロキシ側でキャッシュすればいいじゃん、と思いますが、確かにそうなんですが WordPress 上でキャッシュをコントールしたかったので、こういう構成になりました。
そういったわけで、WordPress コンテンツのリバース・プロキシによるキャッシュには期待出来ず、Web アクセスのたびにフロントエンドとバックエンド間で通信が発生しますが、この通信量を減らすことが目的ではないため、今の所はこの状態にしています。
FYI…
なお、MySQL データベースは ServersMan@VPS
で借りている VPS にレプリケーションしてバックアップしています。月額490円で借りているので、こちらは VPS のバックアップデータを置くことに利用しています。（ほかにはセカンダリMTA などとしても利用中）
»障害原因
さくらインターネットへ本件を問い合わせたところ、7/31 と 8/1 の問題の時間帯に WordPress と MySQL が動いている VPS が収容されている物理マシン内の他の VPS が高負荷になっており、その影響により同一物理マシンに収容される VPS 全てに影響した、とのことでした。
今後はしきい値を変更するなどとして、高負荷になっている VPS を検出して速やかに対処するとの回答を頂き、実際 8/2 の夜には問題が発生せず、有言実行状態となっております。
さくらインターネットは技術力が高いので、安心してお任せできますね。
- データ自体はフロントエンド側にあったり、バックエンド側にあったりします。 [↩]
コメントを残す