サーバ選び7つの基準

サーバーの選び方を、Googleウェブマスターアカデミーの、7つの考慮点に沿って解説します

エックスサーバー

ロードバランサー(100対0)を入れているのに、アクセス集中でサイトが停止してしまいました

      2015/10/17

ロードバランサーを入れているのに、アクセス集中でサイトが停止してしまいました。プロバイダーに確認すると、設定が100対0になっていると言っています。よく意味がわからないのですが、どういうことでしょうか?

レンタルサーバー屋の中の人が回答します。

100対0の設定ということは、ロードバランサの導入目的が負荷分散ではなく、冗長化であると考えられます。

ロードバランサとは

ご回答をする前に、ロードバランサについて簡単に説明しておきましょう。

ロードバランサとは、ウェブサイトへのアクセスを、複数台あるサーバーへ振り分ける装置のことです。

メジャーな使い方は負荷分散

最もメジャーな使い方は、負荷分散です。

WEBサーバーを複数台用意して、ユーザーからのアクセスをロードバランサーによって各サーバーに振り分けます。そうすることで、サーバー1台あたりの負荷が減っていきます。

論理的には1台より2台、2台より3台と台数を増やせば増やすだけ、より大きな負荷に耐えることができるインフラを構築することができます。

負荷分散では、台数を増やせば増やすだけ許容量が増えるよ。

100対0は冗長化

一方でご質問があった100対0のバランシングというものは、冗長化を目的として使います。

WEBサーバーを2台用意して、ユーザーからのアクセスをロードバランサによって振り分けます。このとき、振り分けの重みづけを100対0にすることができます。つまり、各サーバーへ振り分けるのではなく、1つのサーバーのみにアクセスさせるのです。

アクセスさせていたサーバーが物理的な故障等で応答しなくなってしまった場合に、ロードバランサは0に重みづけをしていたサーバーへ振り分けます。そうすることで、サイトの停止を最小限にしようという考え方です。

100対0のロードバランシングは、アクティブ・スタンバイ構成ということもあります。

アクティブ・スタンバイ構成では、台数が増えても許容量は増えないんだね。

冗長化目的から、負荷分散を目的とした設定変更を

質問に戻ってみると、今回のケースではロードバランサの設定を100対0にしているとプロバイダーから回答を受けています。

このサーバー構成のロードバランサの目的は、負荷分散ではなく、アクティブ・スタンバイの冗長化だったということが推測されます。冗長化ということはアクセス集中に対して、2台のサーバーで対応するのではなく、1台のサーバーで対応することになります。

仮にアクセス集中でアクティブなサーバーの許容量を超えてしまい、スタンバイ側へ振り先が変わったとしても、ウェブサイトとしての許容量は変わりがありません。負荷分散では1足す1で2の許容量になるのに対して、冗長化では、1足す1で1の許容量を保証している形になります。

今回の事象を機械に、ロードバランサの導入目的を、冗長化から負荷分散へ見直しててみてはいかがでしょうか?

負荷分散時の注意事項

負荷分散構成にするにあたり、注意すべき点をまとめておきます。

セッション情報の共有

ECサイトなどの場合、ユーザーのログイン情報やカート情報をサーバー側で保持しておく必要があります。データベース保持していれば問題ありませんが、サーバーのメモリ上に保存している場合は注意が必要です。

ロードバランサーの設定によっては、アクセスするたびに利用するサーバーが変更になってしまいます。当然複数台のサーバー間では、メモリ情報の共有はされていないので、アクセスしたタイミングによってはログインしていない状態になってしまう可能性があります。

購入途中でエラーがでてきたら、買う気がなくなってしまうわね。

本来であればアプリケーションの改修をして、サーバー構成に依存しないものにするのが最も良い方法ですが、改修をせずに接続するサーバーを固定する方法があります。、ロードバランサーのセッション維持機能を利用する方法です。

接続元IPによって接続を維持するパーシステンス

接続を維持するためには、接続元が同一ユーザーであると識別する必要があります。接続元IPアドレスをもとにユーザーを識別する機能がパーシステンスです。

パーシステンスを有効にし維持時間を500秒と設定すると、同一IPからの接続は500秒間同じサーバーへ振り分けつづけることができます。

ECサイトなどであれば、購入開始から終了までにかかる時間等を踏まえて設定するといいでしょう。

IPアドレスをもとに判別する場合問題があります。購入途中でIPアドレスが変わってしまう可能性があるのです。特にスマートフォンなどからのアクセスでは、Docomoやau、softbankなどのキャリアの都合で接続元のIPアドレスが変わってしまうことがあります。

スマートフォンだと接続元のIPアドレスが変わってしまうことがあるのね。

Cookieを利用して接続を維持するStickySession

IPアドレスが変わってしまう問題を解決できるのが、StickySessionという機能です。StickySessionでは、ロードバランサが自動的にcookieに値を設定します。そのcookie情報をもとに振り先の接続を維持することができます。

cookieはブラウザへ設定する機能なため、接続元のIPアドレスが変更になったとしても、同じブラウザを利用している限り同一サーバーへ接続を維持させることができます。

ブラウザのシークレットモードはcookieが無効になっているので要注意ね。

ファイル共有の方法

ファイルの共有についても注意しておく必要があります。同一機能を持ったウェブサーバーが複数台に増えるので、それぞれの画像やシステムファイルの内容を同一にすべきです。

コンテンツやシステムファイルなどであれば、管理者が全てのサーバーへ更新をかけることも可能です。しかし、ユーザーがアップロードする可能性があるサイトの場合はそうはいきません。

マスターのサーバーを決めて、同期させる

ユーザーからのファイルアップロードがない場合は、マスタサーバーからスレーブサーバーへデータ同期を取るのがオススメです。

lsyncdなどを利用して、ファイルの同期をほぼリアルタイムで行うことが可能です。サイト管理者がファイルを転送する、または管理画面からアップロードする場合に、マスタとしたサーバーへアクセスさせます。

そのさいに、hostsファイルを利用すると便利です。

lcynsdはリアルタイム同期が可能。
スレーブサーバーのファイルを更新してしまうとデータ不整合になるので気をつけよう。

ファイル共有を行う

いずれかのサーバーをNFSサーバーとして、ファイル共有をするのもおすすめです。ファイル共有をすることで、全てのサーバーが同一の領域を見ることになります。つまり、どのサーバーからファイルがアップロードされても、同じような見え方になります。

便利なNFSですが、NFSサーバーが停止した場合には、全てのウェブサーバーに影響がでてしまうのが注意点です。

便利な反面、障害時に他のサーバーへ影響がでてしまうのがNFS

まとめ

  • 100対0のロードバランサ設定は冗長化目的
  • 負荷分散目的で利用する場合は、セッションやファイルの共有の仕方を検討が必要

参考になりましたでしょうか?

 -

↑他の質問も検索する↑