PloneのZEOクラスタやってみた

Ploneに関わってから、ずーっとスタンドアロンで動かしていたんですが、とうとうユーザさんの業務にもストレスが出てしまう状況になってしまい、なんとか対応を検討。

英語ならいっぱい情報はあるのかもしれませんが、勉強会などで情報交換をすることも難しく、なんだか手さぐり状態でZEOクラスタ化に取りかかりました。

（やっぱり実際に動かしてみないと仕組みが理解できない人間です...）

それでも、MLやtweet、チャットなどでご助言下さった皆様、ありがとうございます！

ちなみに、クラスタ化するには、それなりにサーバのスペックを上げないといけません。実は、意外とネックだったのが、『ただのCMSにそんなにリソース要るの？？』という認識を変えてもらわないといけなかったことでした(^^;
この点は、少しずつPloneの利用を進めて行き、「みんな使うようになったし、遅いとこまるでしょ～」みたいな戦略？で、インフラチームからのリソース捻出を図って行きました…。

ZEO化するにあたっては、こちら (単一インスタンスを ZEO クラスターに変更する ）を参考にさせていただきました。

もっと最適な方法もあるのかと思いますが、現在こんな状況、という図を載せてみます。

* * *

シングル構成でいろいろプロダクトを追加している状態だったことと、blobstorage化していたこ

ともあり、ZEO化用の設定方法がうまくできずに四苦八苦...。

やっとZEO化できたにしても、ユーザは1つのURLをめがけてリクエストを投げてくるので、どうやって処理を分担すればいいのか全くわかりません...。

ハードウェアは全く専門外なのでハードウェアバランサはNG。（調達能力ももちろん無し）

URLを別々にするのはユーザに負担を強いるし絶対無理。

どうしようと悩んでいたら、Apache2.x系はソフトウェアバランサの機能が使えることが分かりました。

mod_proxy_balancer, Ploneをキーワードにしていくと、数件MLなどで例が出ていたので、ヘッダ等を調整して、なんとかなんちゃってZEOクラスタ化の環境が出来上がりました。

* * *

さて、パフォーマンスの件ですが、CPU数を追加し、それに見合ったプロセスを立ち上げることで、『劇的！』ではないのですが、リクエストを分散できる分、ユーザさんを待たせる状況は減った模様です。

ただし、プロセスを複数立ち上げるので、それなりにメモリも必要になってきます。

さらに、前のエントリに書いたように、いつのまにかメモリの使用量が増加してしまい、放っておいたらメモリ使い切ってしまう、という状況になりました。

こちらは原因と理由に納得したため、運用でカバーする方針としました。
また、おかげ様で、クラスタ化の効果が見えたことで、少しメモリも追加していただきました。

* * *

課題はいろいろあって、「ほんとにそもそもこんな感じの構成って良いのかしら？」ということが一番です。こちらは、皆さんにご指摘、ご意見いただければ幸いです。
（こんなへなちょこじゃダメ！というのでも）

また、ZOPE間のメモリレプリケーションはできないと認識しているので、キャッシュを有効にできるようにStickySessionを利用していますが、このへんもちょっと怪しいです。

たまたま重い処理の多いユーザが同居するインスタンスに接続した人は、損をしてしまいそうな気がして、微妙なところです。

個人的には、スケールアウトの方法が分かったのと、メンテナンス作業をしやすくなったのが幸いかな、と思っています。

まだこちらはPlone3.3.5の環境なので、Plone4もできれば試してみたいと思っています。