スケールアウト事始め、とクラウドの話Apache

今年も残すところ僅かとなりました。
ボブです。

システムの絡んだWebサイトの性能問題に対面した時、最終的にはスケールアップやスケールアウトといった形でサーバを増強していく事になります。今回はLAMP環境を想定してその概要をまとめたいと思います。

なお、挙げている例はあくまで性能問題に対する構成例ですので可用性を得るためのHA構成などは省略しています。

99%のケース

Web+DBサーバ1台構成

最も多い構成で世の中の90%のサイトはこれで事足ります。90%という数字は数値的な根拠は無く体感です。1台のサーバにWebサーバもDBサーバも積んだ最もシンプルな状態です。

Webサーバ1台+DBサーバ1台構成

1台のマシンでやってきてアプリケーション側の主なボトルネックも解消され、後はもうサーバリソースを増やすしか無いという段階で一番容易に対応出来る構成です。両サーバをスケールアップ、設定のチューニングをしていく事で残りの9%のサイトに対応する事が出来ます。ただし2台のマシンのどちらも単一障害点のため、どちらかが故障するとサイトがダウンするといったデメリットはあります。

Webサーバ2台+DBサーバ1台構成

画像など静的コンテンツの配信負荷が高い場合、画像のみ別のWebサーバに配置するという負荷対策もあります。(負荷対策以外の理由で分離される場合もありますが割愛)
こういったケースでは予算次第ですがCDNの利用等も選択肢になります。

残る1%

ここまでは単純にサーバを増やすだけで対応していける範囲ですが、それでも性能問題に直面する場合にはスケールアウトを意識したアプリケーション設計にする必要があります。

Webサーバのスケールアウト

ロードバランサー等が必要になります。比較的高価なハードウェアロードバランサー、OSSを利用した安価なソフトウェアロードバランサー、等色々な選択肢があります。DNSラウンドロビンでロードバランスする方法もありますが、携帯端末(一部？)やVista以降のIEでは利用出来ないそうなので、注意が必要です。

PHPで構築している場合Webサーバが複数台になるとセッションをどこに保存するのか、という問題にも直面します。選択肢としてはDBをセッション保存に利用する、KVS(Key Value Store)を利用する等、状況によって最適解は異なってきます。

参照系DBサーバのスケールアウト

MySQLの場合Read負荷が問題であればレプリケーションで参照専用サーバを増やしていく事で対応する事が出来ます。或いはmemcachedのようなRDBよりもパフォーマンスの高いKVSをDBキャッシュサーバとして利用する事も出来ます。

ただしアプリケーション(Webサーバ)からどのDBサーバへ接続しにいくのか、という問題を解決する必要があります。参照系DBと更新系DBのどちらに接続するか、という制御はアプリケーションフレームワークで行うのが一般的でしょう。(KVSをDBキャッシュとして利用する場合の制御も)

参照系DBの中でどのサーバを見に行くか、という問題はアプリケーションと参照系DBサーバの間にロードバランサーを挟む事で解決する手法もあります。

MySQL の負荷分散に LVS + keepalived を使う

この構成であればアプリケーションから見た参照系DBサーバが1台に見えるので、アプリケーション側で楽をする事が出来ます。

次にWrite負荷が問題になるケースですが、RDBMSで対応する場合にはDBを分割(sharding)していく必要があります。ただしこれをやってしまうと通常、DB設計の変更や管理などが非常に大変になってしまうため、頻繁な機能追加や変更が想定される場合には特に注意が必要です。いっその事MySQLよりも更新性能の高い別のDBMSを用いるといった選択もあるので検討が必要でしょう。ただKVSをストレージとして利用する場合、RDBであればDBMSが面倒を見ていてくれていた整合性維持の問題等をアプリケーション側で解決する必要があります。

DBの垂直分割(Level1分散)

例えばブログ機能とニュース機能を持ったサイトで、ブログ機能専用DB、ニュース機能専用DBに分割するようなイメージです。或いはユーザテーブルを基本情報テーブルと拡張情報テーブルに分割する等。

DBの水平分割(Level2分散)

例えばユーザテーブルであれば、ユーザID10000番台だけほ保存するテーブル、ユーザID20000番台だけを保存するテーブル、といった形で分割していく手法です。上記のレンジ分割、ハッシュ分割などの手法があります。

これまでのスケールアウトとこれからのスケールアウト

色々と端折っていますが、以上がLAMP環境でのスケールアウトの概要になります。最後に少しだけ今話題になっている「クラウド」についても、触れておきます。

Amazon型クラウド(EC2)

Amazon型クラウドではサーバの追加が非常に容易です。このためスケールアウトを前提にした設計になっている場合、急な負荷増加に素早く対応する事が出来ます。またリソース課金に近いのも特徴です。既存のLAMP環境でのノウハウもそのまま活用する事が出来ます。

Google型クラウド(GoogleAppEngine)

ここまで説明して来た技術とは異色で、そもそもスケールアウトしやすい技術しか用いずWebサイトを構築する、というアプローチです。このためスケールアウトしにくいRDBMSは使えずGoogleが用意しているオブジェクトストアと呼ばれる物に、GQLという問い合わせ言語でアクセスする事になります。リソース課金のためCPUや帯域を使えば、使っただけ請求が来るという特徴があります。

言語の制約(現在はPythonかJAVA、又はJAVA上で動作する言語)等もあり、既存のLAMP環境でのノウハウが全てそのまま活かせるわけでは無いというハードルの高さがありますが、適用ケースによってはコストメリットがあるのではないでしょうか。