以前に大規模構成について、アプリ側からのカスタマイズについて書いていきましたが、今回はインフラ側のお話です。

まずは「なぜ」インフラでの対応を行うのか。
もちろん、

「どれだけアプリ側をチューニングしても、結局はハードが追いつかなければ意味がない」
とか、
「アプリ側のチューニングを行うよりも、ハードのスペックを上げた方が手っ取り早い」
などの理由はありますが、最大の理由は

アプリのカスタマイズだけでは冗長化が十分に実現できず、耐障害性が非常に低い

ことです。
大規模なサイトになればなるほど、落ちないシステムを作ることが重要になります。

エスキュービズムでは、

　　web：2台＋DB：2台＋LB

といった標準的な構成のほかにも、

　　web：2台＋DB：1台＋LB

といった、小さめの構成

　　web：3台＋DB：4台＋LB

といった大きめの構成など、さまざまなパターンで、複数台での構築が可能です。

まだ、最近ホットな仮想化の技術や、ソフトウェアロードバランサなどを用いることで、物理的なマシンの台数を抑え、コスト効率の良い構成もご提案することが可能です。

「こんな大規模サイト、EC-CUBEで動くの？」と思ったら、ぜひ一度お問合わせください。

大規模化の際に使用する技術などについては追い追い紹介していきたいと思います。

前回「塵も積もれば…」的な話をしましたが、
正直それだけでは「普通に買い物ができるくらい」までには至りませんでした。

そこで（というよりは並行して）調査してみたところ、
どうやら「購入処理」が行なわれたタイミングで、
DBのCPU使用率が異様に増えてしまう…という傾向がみられました。

ただ―――
(続きを読む…)