キャパシティプランニングとスケーラビリティの確保
キャパシティプランニングとスケーラビリティの確保に関する対応策とリソース使用状況の把握について解説します。(LinuCレベル2 主題:2.13.2)
このセクションでは、キャパシティプランニングとスケーラビリティの確保に関する対応策と、リソース使用状況の把握について学びます。
キャパシティプランを作成するために把握すべきシステムリソース
システムのキャパシティを見積もるためには、主に以下のようなリソースの消費状況を確認する必要があります。
処理能力
CPUの使用率などを監視ソフトウェアなどで継続的に監視します。
大規模アクセスが発生するサービスを支えるサーバーでは、データベースへの同時アクセスが急上昇すると、CPU使用率が100%に達してしまうことがあります。こうなると処理が追いつかず、例えばウェブページが表示されない、スマホアプリにリクエストへのレスポンスが返らないというようなトラブルが発生します。そこで、定期的にCPU使用率をモニターし、CPUの搭載数を増やす、サーバーの台数を増やしてCPU数を増やす、などの対策が必要となります。
メモリ
オペレーティングシステムが消費するメモリ量と、アプリケーションが消費するメモリ量の合計が、メモリの消費量になります。
そして、この合計がハードウェアメモリの容量を超えると、メモリ容量を物理的なメモリ容量よりも大きく使えるようにする仮想メモリの仕組みによって、ディスクのスワップ領域へのアクセスが発生し、急激にシステムのパフォーマンスが低下します。
システムが快適な動作をするためにはできるだけスワップ領域へのアクセスを少なくすることが必要です。各メモリの消費量はtopコマンドなどで確認が可能です。
Webサーバーへの集中アクセスが発生するとWebサーバーの子プロセスが多数起動され、メモリを使い果たしてしまうことがあります。この場合は、前述したように、メモリを増設したりCPUを高速化したりするスケールアップや、Webサーバーを複数台設置してロードバランシングするスケールアウトなどの対策が採られます。
ディスク容量
メモリやCPUがいくら高速でもハードディスク領域を使い果たしてしまうと、システムが停止してしまいます。ハードディスクが満杯にならないように、消費状況をモニターし、溢れそうな気配があれば増設する準備を進めておく必要があります。ディスクの空き容量は、dfコマンドで確認できます。
ユーザー数
システムを利用するユーザー数と同時接続数を、データベース上のユーザーテーブルやWebサーバーのログから確認しておきましょう。使用しているOSやアプリケーションで許諾されているユーザーライセンス数を超えると、利用ができなくなる場合があります。
リソースを増減させる方法と必要な対応
サービスが停止しないようにリソースを増減させる方法には、
- メモリを増設する、転送速度の高速なタイプに換装する(スケールアップ)
- サーバーの台数を増やす(スケールアウト)
- CPUを増設する。コア数の多いものに換装する(スケールアップ)
- ディスクを増設する(スケールアップ)
などの対応が考えられます。
スケールアップの方式
スケールアップは先に述べたように単一のサーバーのリソースを増強するものです。増強可能なものとしては、
- CPUの個数を増やす、コア数が多いものに換装する
- メモリの容量を増やす、転送速度が高速なものに換装する
- ディスクの増設、大容量のディスクへの換装、転送速度が速いディスクを選択する
- ネットワークインターフェースを高速なタイプに換装する
などが考えられます。
スケールアウトの方式
スケールアウトは単一のサーバーではなく、サーバーを複数台構成に(水平方向に)拡張してCPU負荷や、メモリやディスクなどの消費量を抑えて、サービス停止を防止するための工夫です。
例えば、大学の履修登録や企業のキャンペーンなどが発生すると、Webアクセスが集中することでWebサーバーのメモリを使い果たしてしまい、応答時間が長くなったりWebページがホワイトアウトしたりしてしまう場合があります。このような時には、Webサーバーを多重化して、各Webサーバーのメモリ消費量やCPU消費量を低減させて、安定的にWebページの配信を行えるようにします。
さらに外部から1台のサーバーにアクセスしているように見せるために
- DNSラウンドロビンを用いてランダムにアクセスを振り分ける
- ロードバランサを用いてサーバー負荷の監視を行い、できるだけ負荷の少ないサーバーノードにアクセスを振り分ける
など、ロードバランシングと呼ばれる工夫をします。
DNSラウンドロビンを用いると特定のホスト名に送信されてきたリクエストを、複数の異なるIPアドレスが付与されたWebサーバーにランダムに割り振って、負荷の分散を図ります。
例えば、DNSサーバーのゾーンファイル上で同じホスト名に対して複数のIPアドレスを割り当てます。すると同じURLにアクセスしようとした場合に、クライアントのウェブブラウザーには登録されているIPアドレスが順番に(ラウンドロビンに)返されます。それによって、アクセスを登録したIPアドレスの個数分のサーバーにアクセスを分散させることができます。
ロードバランサソフトウェアや、専用装置(アプライアンス)を用いると、各ノードの負荷を監視して、より負荷の低いマシンにリクエストを振り分けたり、同じセッションのリクエストを同一のノードで処理したりするように、クライアント(Webブラウザーなど)からのリクエストや通信を振り分けます。
ロードバランサはネットワーク機器ベンダーが提供する専用アプライアンス、ソフトウェアベースのロードバランサ、クラウドサービスにおける仮想ネットワークデバイスなどの選択肢があります。
例えば、オープンソースのロードバランサには、haproxyなどがあります。また、SPoF(単一障害点)を減らすために、ロードバランサを複数台並べて、死活監視を行い、ロードバランサ間でフェイルオーバーしたり、障害が発生したノードを停止したりすることもあります。haproxyを使用する場合には、サーバーを冗長化するkeepalivedでロードバランサを切り替え、システム停止を回避することができます。
スケールアウトに対応できるアプリケーション構成
アプリケーションの構成でスケールアウトに対応できるようにするためには、
- Webサーバー、ミドルウェアを動作させるサーバー、データベースサーバーを分離する
まずは、HTTPアクセスの処理、アプリケーションの実行、データベースアクセスの負荷を分散するために、Webサーバー(NginxやApache)、ミドルウェア(PHPやJava EEサーバーなどのアプリケーションサーバー)、データベースサーバーのそれぞれを1台で構成します。
- 続いて、それぞれのノードの負荷が増大した場合
- Webサーバーを複数台構成にしてロードバランシングする(先頭にロードバランサを配置する)
- データベースサーバーを複数台構成にしてデータを複数台で保持するデータベースクラスタリングを行う
などの対策を考えます。
- アプリケーションをステートレスな構成にする。
- セッションが複数サーバーで利用できるよう、共有領域に保持するようにアプリケーションを開発したり、設定ファイルで指定したりできるようにする。
- ロードバランサによっては同一セッションを同じマシンに処理させるセッション親和性(セッションアフィニティ)機能を搭載しているデバイスもあります。
- アプリケーションが用いるデータを共有ディスクに保持する。これにより、データの整合性が保持されます。
- データベース設計を疎結合に対応できるように工夫する。リレーションを厳しくし過ぎないでデータベースを複数に分割できるように構成しておく。参照系と更新・挿入系のデータベースを分ける
など複数台で運用することを想定したアプリケーション構成にしておくことも有効な場合があります。
構成管理ツールや仮想マシンイメージを使ったスケールアウト
手動で仮想マシンを追加すると、ApacheやNginxなどのWebサーバーソフトウェアをインストールして設定したり、MySQLなどのデータベースサーバーソフトウェアをインストールして初期化する、などの初期設定作業が必要になります。こうした初期設定作業はプロビジョニングと呼ばれています。しかし、台数が増えてくると作業者の負担が大きくなり、設定ミスが発生したりするリスクが発生します。
そこで、構成管理ツールを使用してあらかじめサーバーに組み込むソフトウェアや設定などの情報をプロビジョニング設定ファイルに記述しておき、コマンドから読み込むことで一連のプロビジョニング作業を自動的に行うと、前述のリスクを低減させることができます。
構成管理ツールには、2.04.6で解説したようなAnsibleなどが使用されています。
執筆者紹介
・太田 俊哉
・井上 博樹
このドキュメントは、LinuCレベル2の学習用の教材から抜粋して作成されたものです。教材全体は以下のPDFファイルをご覧ください。
LinuCレベル2学習教材