小規模のサービスを如何にスモールスタートするか、そのために各コンポーネントをどうやって配置するのがいいのかという話。個人的な考えも含めて。 efficent_server_operarion.png

大まかな構成は昨年のnekokakさんのYAPC::Asiaでの発表、省サーバ運用と大体同じです。Web/Appに使うサーバ2台、データベース2台です。あとはLBが別にあればそれを、なかったらもう一台(組)必要となります。

Web/Appサーバには、Reverse Proxy、Application Serverがまず配置されます。あとは必要に応じてmemcached、Job Queueのworkerを動かします。ここまでのコンポーネントは2台のサーバ両方に配置し、Active-Activeで動作し冗長性がとれるよう構築します。cronについては、両方のサーバで動かしても問題がない状態が理想ですが、そうでない場合、Web/Appの1台目で動かすというルールを決めて運用します。DAVはおまけで、画像等アップロードする必要がある場合、ここにDAVサーバをたてGreenBucketsなどで管理します。このように、Web/Appサーバには2台以上で動かすことにより冗長性がとれるものを中心に配置していきます。

データベースサーバは、MySQLのMaster-Backupの構成が基本です。backup側をslaveとして参照を行うことは可用性を下げるだけなので行いません。Kyoto Tycoonは主にsession管理用に使います。Web/Appサーバのmemcachedがスケールアウト/インによって追加削除されて行くのにたいして、Kyoto Tycoonは1台のmasterとbackupの構成をとってデータの永続化をします。Kyoto Tycoon以外でも永続性の必要なデータはここに載せて行くとWeb/AppとDBで運用上のメリハリがつきます。

サーバを増やす際にも、データベースなど永続性が重要なコンポーネントと、複数のサーバで動かすことにより冗長性が確保できるものはわけて配置しましょう。メリハリがついているとサーバ障害の際にどう対応すべきかがはっきりとし、復旧の速度もあがると思いまふ。もふもふ

このブログ記事について

このページは、Masahiro Naganoが2011年6月 3日 16:38に書いたブログ記事です。

ひとつ前のブログ記事は「memcached を使ったアプリケーションの設計について」です。

次のブログ記事は「Webアプリケーションにおける Job Queue システムの構成例と Worker を作る際に気をつけること」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

OpenID対応しています OpenIDについて
Powered by Movable Type 4.27-ja