小規模のサービスを如何にスモールスタートするか、そのために各コンポーネントをどうやって配置するのがいいのかという話。個人的な考えも含めて。
大まかな構成は昨年の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で運用上のメリハリがつきます。
サーバを増やす際にも、データベースなど永続性が重要なコンポーネントと、複数のサーバで動かすことにより冗長性が確保できるものはわけて配置しましょう。メリハリがついているとサーバ障害の際にどう対応すべきかがはっきりとし、復旧の速度もあがると思いまふ。もふもふ
大まかな構成は昨年の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で運用上のメリハリがつきます。
サーバを増やす際にも、データベースなど永続性が重要なコンポーネントと、複数のサーバで動かすことにより冗長性が確保できるものはわけて配置しましょう。メリハリがついているとサーバ障害の際にどう対応すべきかがはっきりとし、復旧の速度もあがると思いまふ。もふもふ
