Webアプリケーションのスケーリングとは？負荷分散でトラフィックの増加に対応する方法

もしあなたが大規模なプロジェクトを開発中なら、まず正しいスケーリングを考えるというところから始めましょう。デザインに取り掛かる前です。プロジェクトが完成してからこの作業をすると、より多くの時間と作業が必要になるからです。

 

Webアプリケーションをスケーリングすることは、同じタスクを実行する機能モジュールの数を増やすことによって、プロジェクトの機能を高めるための能力です。

 

一般的に、現在のシステムが負荷に耐えられなくなった時、スケーリングが必要になってきます。特に、プロジェクトが大きくハイロードな、Facebookのようなソーシャルネットワーク、仮想通貨取引システムなどです。最もシンプルな解決策は、サーバーを強化することです。これをすると、プロバイダーからのハードウェアのアップデートをスムーズに行うことができます。しかし、これは短期的な解決策であって、グローバルな視点から見ると十分ではありません。

 

既存システムの再設計には、多くのリソースと作業が必要になります。したがってMerehead社は、作業に取り掛かる前に、スケーリングのオプションを検討することを推奨しています。これは、安定性と柔軟性があるWebアプリケーションの作成を実現させるでしょう。

 

各サイトにスタンダードアーキテクチャがありますが、多くの会社は、プロジェクトをいくつかのメインモジュールに分けることを好みます。基本的に、フロントエンド、バックエンド、そしてデータベースです。これは、さらなる発展の大きな強みになるでしょう。このアーキテクチャでは、ファイル間のナビゲーションがシンプルになり、そしてシステムにより柔軟性があります。加えて、必要な性能を提供する、最良のソフトウェア言語を使用することが望ましいです。

 

 

例えば、私たちの会社は、各httpリクエストを別工程としてプロセスする、Apache serverを好みます。これは、計算リソースと時間が必要になります。しかしハイロードの為、データベースが故障する恐れがあり、より多くのリソースが必要になってきます。安定したオペレーションを確実にする為に、データベースを別のサーバーに移動できます。これは、現在のWebアプリケーションのパフォーマンスを大いに向上させます。

 

第二段階で、バックエンドパートをスケールすることができます。これは、さらに著しいスピード向上に繋がります。通常、フロントエンドは最小ロードを使用し、その分離によってパフォーマンスが著しく向上することはない為、フロントエンドは同じサーバー上に残ります。また、別のサーバーにファイルストレージを置くことができ、メインサーバーの負荷を減らすことができます。

 

 

バックエンドスケーリング

 

通常、Amazonウェブサイトのような大規模なプロジェクトは、有能なバックエンドパートを持っています。それは複雑な計算を処理することに委ねられています。バックエンドの影響で、Webアプリケーションのオペーレーションのスピードが遅くなることが頻繁に見られます。複雑なプロジェクトの開発過程で、クエリーのオプティマイズとサーバーパフォーマンスの合理的使用に注意を払うべきです。

 

あなたのプロジェクトが素晴らしいバックエンドパートを持っていたとしても、負荷は存在し、作業の質を落とすことになります。そこで私たちは、スケーリングを開始することをお勧めします。もし負荷が短期的なものなら、サーバーの力を向上することができます。もしそうでなければ、バックエンドをいくつかのサーバーに分ける必要があります。それは、いくつかのスクリプトとモジュールを第二のサーバーに移行するのに十分です。その後で、それらの間でクエリーを均等に分配する必要があります。メインサーバーから負荷を取り除き、他のハードウェアにリダイレクトすることが可能になります。リダイレクトは主に、フロントエンド側で行われます。

 

 

データベースのスケーリング

 

もしデータベースに大量のデータがあり、別のサーバーをロードすると、このクラスターをスケールできます。データベースのスケーリングには2つの方法があります:

 

計算プロセスの分散・データベースを分割する

 

データベース内の計算プロセスの分散

 

大規模なデータベースではなく、サーバーに負荷をかける複雑な計算が多数ある場合は、計算プロセスを分けることをお勧めします。したがって、各サーバーはデータベースの完全なコピーを保持し、独自の限られた作業領域のみを実行します。これは、実装する為の取り組みを必要とする、より複雑なものです。まず第一に、これはデータベースのすべてのコピーを最新の状態に保つための、サーバー間のデータの同期によるものです。

 

以下がこの問題に対するいくつかの解決策です:

 

• アプリケーションレベルの同期

この場合、スクリプトはデータベースの各コピーに対する変更を自動的に記録します。しかし、障害が発生するとデータの同期が妨げられる可能性があるため、この方法には多くのリスクがあります。

 

• レプリケーション

メインサーバーに変更を加えると、その後他のサーバーにも自動変更が行われます。

 

• マルチマスタレプリケーション

レプリケーションと、とてもよく似ていますが、この場合のみスクリプトは、どのサーバーにもアクセスすることができます。レプリケーションは他のサーバーにも拡張されます。

 

データベースを分割する

 

もし多くの計算方法がなく、データベースが多くのアイテムから成り立っている場合（多くの場合、このような問題には大きなEコマースWebサイトがあります）、データベースをいくつかのサーバーに分ける必要があります。各サーバーは、いくつかのデータを保持し、他のサーバーとも関わりを持つでしょう。

 

以下の、いくつかのデータ配信方式があります:

 

• バーティカルパーティショニング

この方式の本質は、一部のテーブルが別のサーバーに移動されることです。この場合、複雑なSQLクエリーを作成する方法がないため、柔軟性が失われます。基盤を正しく論理分割すると、この問題を最小限に抑えることができます。

 

• ホリゾンタルパーティショニング

この方式では、データベースは1つの同じテーブルを格納し、異なる部分のみを含みます。 たとえば、1億のユーザーアイテムを含むテーブルがあります。 私たちはそれを2つのサーバーに分割しました。1つのサーバーには男性用のアイテムのみが格納され、2つ目のサーバーには女性のみが格納されます。 この場合、サーバー間で要求を正しく分散するためにバックエンドに変更を加える必要があります。

 

 

サーバー間のリクエストの分割

 

複数のサーバーが揃うと、今度は、サーバー間のリクエストの正しい分割の問題に直面することでしょう。リクエストを分割する（バランスをとる）方法は2つあります:

 

• ノードのバランス

これはリクエスト間の負荷を分割するシンプルな方法です。クライアントは、リクエストをプロセスするためにどのサーバーに接続するかを独自に決定するメインサーバーと関わります。全てのロジックが一点にある為、主な問題は、この方法の信頼性です。もしこのノードが壊れたら、全てのシステムの流れを止めることになります。

 

• クライアント側とのバランス

安全で柔軟性がある、サーバー間のリクエストの分割方法。アイデアは、ユーザーパラメータを取得することです。この後で、このデータをもとにリクエストは自動的に分けられます。多くの場合、IPとユーザーの国が主な価値観として使用されます。これを知って、ユーザーは必要なサーバーに自動的にリダイレクトします。この方式は、FacebookやGoogleのような大規模なプロジェクトによって使用されます。

 

ハイロードの大規模なプロジェクトは、確かな知識と経験が必要になってきます。プロジェクトをスケーリングするということは、デザインを始める前に考慮しなければならない複雑なプロセスです。これは、長い目で見ると、お金と時間を節約することに繋がります。一般に、スケーリングには、フロントエンド、バックエンド、そしてデータベースなどの多くの方式と方法があります。これらは、毎月何億ものユーザーと連携する構造を開発する機会を提供します。

 

高品質の結果を取得するということは、適切なアーキテクチャを開発し、信頼性の高いサーバーを使用する必要があります。規模の拡大に対応できるプロジェクトには、Amazon Elastic Compute Cloud (Amazon EC2)をお勧めします。プロフェッショナルなWeb開発会社のみに信頼をおきましょう。私たちの会社、Mereheadは、ハイロードで複雑な規模の拡大に対応できるプロジェクトを開発した経験があります。