WEBが重い？サーバーについてちょっとだけ考える

ついこの間納品したWEBサービスのシステムで、「WEBサイトが重いんだけど〜」という連絡が納品先の担当者の方からチャットが飛んできました。 チャットが飛んできたと言ってもスーパーマンのように飛んでくるわけではなく、申し訳無さそうに、いつもチャットで伝えてくれる優しい方なのですが・・・ また、WEBサイトが重いと言っても、持ち上げられないぐらいの重力があるワケでもないです。 え？そんな事は分かっているって？・・・確かにこのブログを読んでいる人であれば、こんなバカげたネタに付き合ってもらうのも烏滸がましいですが、このサイトが重いっていう状態ってWEBサーバーで何が起きているかをWEBエンジニアじゃないとなかなか理解し辛いという事がわかったので、改めて「WEBの重い」を考えてみたいと思います。

WEBサービスのポイント

サーバーに限らず、パソコンの速度を一番表す方法は、CPUのクロック数とコア数です。 3.7GHzでクアッドコアとあると、非常に高価なワークステーションですが、ノートPCなどの場合は1.2GHZなどの低いクロック数の方がバッテリーの消耗が緩やかになるため致し方なく搭載している事もありますが、コア数って単純に掛け算で考えないほうがいいという話をします。 3GHzで1コアの最大スペックは、3×1 = 3 1GHzで4コアの最大スペックは、1×4 = 4 高魅せられて1GHzのPCを買う人は少ないでしょう。 もちろん、高スペックなPCじゃないと仕事などに影響する場合は少しでもクロック数の高いPCを購入することをオススメしますが、インターネットと、何か1つの計算アプリぐらいしか使わないという用途であれば、低クロック数でも十分でしょう。 では、サーバーに適切なスペックってどういう状態がいいのでしょう？ 高クロック数になると、電気消費量が増えるので、コストが高くなります。 AI系や、集計などを行なうWEBサーバーであれば、クロック数の高いものを使うのがいいのですが、アクセスユーザー数が多いだけのサービスであれば、クロック数よりもコア数を重視した方がいいんですね。 何でもかんでも数値の高いものをチョイスしがちな人は、今一度コスト感覚を見直す事で色々と恩恵が有ることを理解しましょう。 低いスペックでも便利になる場合もあるんですよ。

クラウドサービスは分かりづらい・・・

AWSなどのクラウドサービスは、基本的にデフォルトスペックではCPUは1つの場合がほとんどなのですが、スペックを上げると値段も反比例的に上がっていくので、もはやクラウドがお得なのか、オンプレがお得なのか、わからない状態になってきます。 AWSのEC2のノーマルスペックで下記コマンドを実行してみます。 $ grep cpu.cores /proc/cpuinfo | sort -u cpu cores : 1 OSで認識しているCPUのコア数を表示するコマンドですが、値は1と出るので、コア数1だと考えがちですが・・・クラウドサービスは1であって1出ない場合がほとんどであることを理解しましょう。 基本的にクラウドサーバーのサービスというのは、1台のサーバー内に複数の仮想OSを立ち上げて対応しているという事を考えると、コア数以上のOSを抱え込んでしまった場合、理論的なコア数は、搭載OS数÷CPUコア数と考えなければいけません。 例えば、4コアCPUで10個のOSが搭載されているクラウドサービスは、「4÷10=0.4コア」と考えなければいけないのでしょうか？ 実際には、全てのユーザーが同時にCPUを利用している可能性を考えると、同時利用している人数でコア数を割ったのがリアルなその時のスペックで考えなければいけません。 要するに、表示するレベルではなく、少し重い処理をして、時間のかかるCPU処理をするユーザーが物理コア数を上回った時に、遅延が生じますが、こうした事象を考慮するのが非常に難しく、明確な把握をするのはほぼ無理という状態でしょう。 でも、AWSサービスが世の中のWEBサービスを圧巻しているのは、色々な機能優位点もあるのですが、一昔前のように、サーバーにOSを詰め込むのではなく、複数サーバーに分散した状態でのクラウドOS搭載なども行っているため、実際は4コアの低スペックPC10台などの分散になっているとしたら、コアの総数は40個もある計算になります。 もはや、ここではコア数って意味が無いかもしれませんね。 ・・・でも、OSで認識しているコア数は"1"です。

サーバーコア数が1の場合の悲しいサービス現状

少しサービス側の事を考えると、クラウドでもオンプレでも、コア数が"1"という事は、1つの処理が完了するまで、次の処理は順番待ちになってしまうという事です。 もちろん時間がかかりすぎる処理の場合は、タイムアウトになる事もあり、こうしたWEBサービスをリヨ王するユーザーにとっては、ストレスかかりまくりサービスになってしまって、よろしくはない状態ですよね。 コストは高くしたくないが、こうしたストレスを無くしたいという人は、サーバー処理を分散する設計をするといいでしょう。 ネットワークを利用したサービスでもっとも主流なのが「アプリサーバーとDBサーバー」の2台構成にして、データベースを複数のサーバーで共有する方式です。 一般的にWEBサービスで処理が重いのはデータ処理の部分であると考えられるため、データベースを外部CPUに任せてしまえるというのは、論理的でもあります。 また、セキュリティ対策を重視するという観点においても合理的ですよね。 そして、これだけでは充分でない場合は、アプリサーバーも分散処理するケースが多く、「フロントサーバーとバックサーバー」に分けて、表示処理をするサーバーと、集計などの処理をするサーバーを物理的に分けるという手法です。 ここで重要視しているのは、フロントサーバーとしているのは、アクセスユーザーのブラウザに表示をすることを目的にした処理を一手に行うことで、表示遅延をさせないという役割を果たせてメデタシメデタシという事です。

あとがき

実はここでの落とし穴は、フロントサーバーは、データ処理をされないと表示されないというデメリットも有るので、ボトルネックがDBサーバーというような遅延障害も多々発生します。 もちろん、これの解消法として、データベース・サーバーの分散化であったり、処理アルゴリズムの解消などを行なうべきなのですが、このあたりは、設計の経験値に依存するので、サーバー設計を行う場合でもスキルが必要ということがよく分かります。 「自分の管理しているサーバーは、AWSにまかせているから大丈夫・・・」としか考えていない初心者エンジニアは、アクセス数が増えた時に必ずこうしたサーバーのスペックに一度は泣かされると思いますよ。 僕は個人的に、この試練を経験したことがあるかも重要なその人のスキルであると判断して、採用基準にしていた事もあります。 AWSの前に、自分でオンプレサーバーを作ってみることをオススメします。