それでもすべきスケールアウト
さて，これまでボトルネックの調査について説明をしてきましたが，具体的にどのようにシステム増強の対応をすれば良いでしょうか。最近注目のシステムの増強方法は，スケールアウト型です。しかし，スケールアウト型の増強方法は設計が複雑になるだけでなく，実際にサービスを稼働させてからの運用なども煩雑になる可能性があります。
そのため，スケールアウト型のシステム増強を設計する際は，「簡単に運用することができるか」という点まで考慮をして検討するようにしたほうが良いでしょう。
スケールアウトをさせるときの注意
負荷分散のために，今まで1台で処理していたサーバを分けるとなると，データの確実な保存が課題になってきます。スケールアウトには，複数のサーバでのデータの保持がつきものになるため，避けては通れない問題といってよいでしょう。
実はこの問題に関しては，最適な解決策が場合によって変わってくるため最適な方法を提示はできません。しかし，「どこでどのようにデータを管理するのか」という点は常に意識しておくべきです。
Web/ApplicationサーバとDatabaseサーバの分離
最初は1台のサーバにすべてを処理させる構成になっているとします。まずそれぞれの役割ごとにサーバを分離させましょう。使用している言語がPHPなどであれば，Apache内で動作する部分になるので，WebサーバとApplication部分を分離させることができません。そこで，まずはDatabaseサーバを分離する構成にします（図1参照）。この構成によって，Web/ApplicationサーバとDatabaseサーバにかかっている負荷がそれぞれ2分割されます。
とくにDatabaseサーバは1つのサービスからだけでなく，複数のサービスから参照される可能性もあるため，サービスの規模が大きくなっていく予測が立っているとしたら，早々に分離しておくほうが良いと思います。
図1 Databaseサーバの分離
![図1 Databaseサーバの分離]( "図1 Databaseサーバの分離")
ドメインによる負荷分散
それでは，次にWeb/Applicationサーバの分離を検討してみましょう。
具体的に下記のURLでサービスを稼働させていると仮定します。
- 情報を更新する処理
http://foobar.com/register
- 情報を参照する処理
http://foobar.com/show
このURLのままでは，foobar.comを名前解決して，そのIPアドレスを持っているサーバへアクセスをしてしまいます。つまり，更新の処理も，参照の処理も同一のサーバでアクセスを受けることになってしまいます。
この場合，どのように解決すれば良いでしょうか。
方法の1つとして，それぞれの機能をサブドメインにしてしまい，アクセスを受けるサーバを分けてしまうという手があります。具体的には下記の用になります。
- 情報を更新する処理
http://register.foobar.com/
- 情報を参照する処理
http://show.foobar.com/
このようにドメインを分割することによって，それぞれの処理をサーバごとに分散させることができます（図2参照）。Databseサーバ自体は1台しかありませんので，2台のWeb/Applicationサーバから接続をする構成となっています。
図2 処理ごとにサーバを分割
![図2 処理ごとにサーバを分割]( "図2 処理ごとにサーバを分割")
ただし，ファイルのアップロードなどのファイル登録処理がある場合は，この構成では登録したファイルを参照することができません。
サービス用件次第ですが，即時反映でなければrsyncを使用して定期的に登録されたファイルを参照系のサーバに転送する処理で解決をすることができます。転送をすることによって，参照系のサーバの方をバックアップとして扱うこともできます。
しかし，実際は，細かくドメインを分けてしまうとそれだけIPアドレスが必要になってしまいます。つまり，IPアドレスの維持にコストがかかってしまうことになります。余計なコストをかけないために，分割をする際は，どの単位で分割をするのかという点に注意をしておきましょう。
Databaseの負荷分散
それではDatabaseの負荷分散の説明をします。Databaseの負荷分散には，先ほどのパターンと同様にDatabaseを更新と参照に分ける方法があります。
一般的に，Webサービスにおいては更新の処理（INSERT/UPDATE/DELETE）よりも参照の処理（SELECT）のほうが圧倒的に多いというケースがよく見受けられます。上記の点をふまえた上で，参照系を増やしていける構成を組んでいくのが良いでしょう。
そのときに使用できる技術が，Replication（レプリケーション）という技術です。MySQLでは比較的簡単にReplicationを設定することができます。
MySQL の レプリケーションは，一方向性の非同期複製のサポートを特徴とし，一つのサーバがマスタとして機能し，別のサーバがスレーブとして機能します。
http://dev.mysql.com/doc/refman/5.1/ja/replication.html
この機能を使用することで，処理によりDatabaseサーバをスケールアウトさせることができます（図3参照）。また，先ほどのWeb/Applicationサーバの分離と同様に，参照系の方をバックアップとして使用することもできます。
図2 ReplicationによるDBサーバのスケールアウト
![図2 ReplicationによるDBサーバのスケールアウト]( "図2 ReplicationによるDBサーバのスケールアウト")
より高度なスケールアウトへ
今回は基本的なスケールアウトの方法を紹介してきましたが，すべてを実行することが最適な方法とは言えません。重要なことは，今のボトルネックを見つけた上で，「何が最適な増強方法なのか」を見極めることです。システムの増強は多額のコストがかかる部分なので，正確に分析をした上で慎重に増強の方法を検討するようにしましょう。
次回は，より大規模なシステムにするための分散方法を紹介していきたいと思います。
