Tokyo TyrantによるHAなセッションストレージ 1 検討篇
2年前にPHPのセッション管理に使う箱選び 4で、セッションストレージとしてはMySQLのInnoDBを使用するのが良いと結論付けた。
当時は主にセッション数が増えていった場合のパフォーマンスについて調べて結論を出したものの、実際にMySQLをセッションストレージとして使用すると、さらに負荷が高くなった場合のパフォーマンスや可用性の部分にちらほら課題が見えてくる。
つまり、大規模なセッションストレージとして使うにはMySQLは高機能過ぎて重く、さらに冗長構成になっていても障害発生時の対応は手動が基本になってしまう。(自動化できないわけではないと思う)
MySQL :: MySQL 5.6 リファレンスマニュアル :: 17.3.6 フェイルオーバー中にマスターを切り替える
セッションデータの集中管理をやめる*1というのも手だけれど、それはそれで大変なので別のセッションストレージにする方向で検討してみようと思う。
要件は
- 1000qps/1000コネクション以上の環境で動作可能
- セッション数/接続数が増えてもスループットが低下しない
- 有効期限の切れたセッションは自動で削除
- 冗長化が可能
- フェイルオーバーが自動
- 任意のタイミングで停止せずにマスタの切り替えが行える
- 書き込み直後に読み込みを行っても常に一貫した情報が取得できる
- 構成がシンプル
が上記要件のいくつかを満たせそうだ。
repcached
- デュアルマスタ構成可能
- 非常に高速
- 有効期限設定可能
- memcachedなので揮発性
- 使用できる容量は割り当てメモリまで
セッションストレージとして使われている話もよく聞くrepcached。memcached互換プロトコルなのでクライアントライブラリにも困らなそう。
しかし、オペレーションミスなどの"最悪な事態"を考慮すると、揮発性メモリだけにデータを置くのは怖い。キーを打つ手が震える。
Flare
- マスタ スレーブ構成可能
- スレーブをマスタに昇格可能
- パーティショニング可能
- 有効期限設定可能(らしい)
- Tokyo Cabinetに格納
- スケールアウト
- 情報少なめ
FlareはファイルベースのTokyo Cabinetにデータを置く分散ストレージ。memcached互換プロトコル。データの保存を行う複数のノードと、ノードを管理するインデックスサーバで構成。インデックスサーバがノードを監視していて自動的にフェイルオーバーも行えるらしい。
機能は申し分無いものの、恐らく構成としてはマスタ、スレーブとインデックスサーバの3台が必要になり、またクライアント側にproxyノードを置いた方が良いみたいで、そうすると構成が複雑になってしまいうれしくない。
パーティショニングが必要になる規模になったら使ってみたい。
Tokyo Tyrant
- デュアルマスタ構成可能
- 有効期限は拡張スクリプトで実現
- Tokyo Cabinetに格納
- スケールアップ
Tokyo Tyrantは、データベースライブラリTokyo Cabinetのネットワークインターフェース。memcached互換、HTTPと独自のプロトコル。有効期限を使用するような場合は専用クライアントが必要。拡張スクリプトで機能追加を行える。マスタ スレーブ構成とデュアルマスタ構成が可能。構成は比較的シンプル
mixiではサーバ1台で10000qps/10000コネクションを処理しているらしい。
というわけで、今回はタイトルからもわかる通り、要件を満たせる度合いが高そうなTokyo Tyrantにセッションデータ保存する方法を考えてみたい。
つづく
- 検討篇
- PHPから利用する篇
- デュアルマスタ篇
