Amazonで購入する大規模サービスの運営、大変だということは分かっていても、じゃあ実際にどういうふうに大変なのか。実際に体験してみないとこの大変さはわからないと思います。実際に大規模サービスの開発・運営に携わることになったら!?本書は、はてなで実際に運用されているサービスを元に、大規模サービス技術のノウハウを解説しています。実際にはてなのインターンシップで講義資料として使われているものがベースになっているので、分かりやすくかつ、実用的です。サービスはいつユーザ数が爆発するかわからないという面白さがある一方、きちんとサービスのノウハウがないとシステムダウンにすぐに繋がってしまうという怖さがあります。サービス開発エンジニアにおすすめです。本書で本質的な知識を得て、準備万端にしておくと良いと思います。大量のアクセスがあるサービスでは、サーバ1台では処理しきれない負荷を同処理するかが一番の問題です。ここ10年のトレンドとしてはいわゆる「スケールアウト」がこの問題に対する戦略の基礎になります。大量のアクセスのある大規模サービスでは、スケーラビリティの確保と負荷分散が重要な問題になります。ハードウェアが安くなってきた最近では、高価なハードウェアを購入するよりもコストを削減できます。その代わりに考えないといけないことも増えます。複数のハードウェアを効率良く使うための負荷分散のしくみや、データの同期の問題、ネットワークのレイテンシ(遅延時間)をどうするか。冗長性スケールアウトでサーバを複数台用意すると、サーバの故障率は高くなります。どこかのサーバが1台故障したからといって、サービスが停止してしまうことは避けなければなりません。省力運用サーバ台数が増えてくると、それぞれのサーバの状況を把握することが困難になってきます。セキュリティ設定、ソフトウェアのバージョンなど、管理しなければならないことも増えてきます。監視用ソフトウェアを使って自動化を行ったとしても実際に確認するのは人間の役目になります。手間を掛けずに健康状態を維持するか。大規模サービスになると、当然そのサービスに携わる人は増えてきます。効率化を図るための標準化や標準ツールの策定、教育やマネージメントなどの必要性が出てきます。大規模Webアプリケーションを運用するにあたっての苦労の多くは、この大規模データの扱いに集約されます。データが小さいうちは、とくに工夫をしなくてもすべてメモリで処理できますし、複雑なアルゴリズムを使うよりもナイーブなアルゴリズムのほうがオーバーヘッドがないため早い、なんてこともままあって、I/O負荷などはまず問題となりません。サービスがある程度以上の規模になるとデータは増加します。このデータ量が分水域を超えたところで問題が顕在化します。その対策は、応急処置ではなかなかに難しい。ここが大規模サービスの難所です。ミニマムスタートと、変化を見込んだ管理と設計サービスが小規模の時には、あれこれ考えて早過ぎる最適化を行うのはよくありません。いって、何も考えずにシステムを設計するのもまたよくありません。サービス設計時にある程度のキャパシティ管理とデータが莫大に増加してしまわないような設計を行った上で、ミニマムスタートをきる。それがサービスを開始するときのコツです。大規模データ処理の難しいポイントは、メモリ内で計算ができないことです。コンピュータはメモリとディスクとで、105〜106倍以上の探索速度の差があります。メモリとディスクの転送速度では、メモリが約7.5GB/秒ほど出るのに対して、ディスクは58MB/秒ほどしかでません。記憶装置が出てきたことで探索速度の差は縮まってきていますが、転送速度の差は埋めることがまだ出来ていない状況です。「負荷分散」と言う言葉から思い浮かべるのは、多くの場合、複数のホストに処理を担当させる文字通りの「分散」です。そもそも1台で処理できるはずの負荷をサーバ10数台で分散するのは本末転倒です。単一のサーバの性能を十分に引き出すことができてはじめて、複数サーバでの負荷分散が意味をなします。ボトルネック見極め作業の基本的な流れ推測するな、計測せよロードアベレージを見るCPU、I/Oのいずれがボトルネックかを探るCPUの場合、ディスクやメモリはボトルネックになっていないかを確認。プログラムのバグも確認するI/Oの場合、スワップが発生していないかを確認。