前回は、1000台のシステムは何が変わるのか 「大規模サービス技術入門」の全体像についてまとめた。ここでは、メモリとディスク、Webアプリと負荷といった大規模データ処理入門について解説する。
１ はてなブックマークのデータ規模
はてなブックマークを例に見る大規模データ
はてなブックマークのあるエントリのキーワードは3億5千万レコードある。このテーブルに「select * from relword」というクエリを投げると応答はなかなか返ってこない。
はてなブックマークのデータ規模
- entryテーブル：1,520万エントリ、3GB
- bookmarkテーブル：4,500万エントリ、5.5GB
- tagのテーブル：5,00万タグ、4.8GB。HTML：200GB
- relwordキーワード用テーブル：10GB
大規模データへのクエリ
インデックスを効かせていないと、データ処理に時間がかかる。
２ 大規模データ処理の難所
大規模データは何が難しいのか
大規模データの難しさはメモリ内で計算できないところである。そのためディスクにあるデータを検索する必要がある。しかし、ディスクは遅いためI/O（Input/Output）に時間がかかる。この問題にどう対処するかが課題である。
メモリとディスクの速度差
メモリはディスクの10の5乗〜10の6乗倍（10万倍〜100万倍）以上高速である。
ディスクはなぜ遅いのか
ディスクではヘッドの移動と円盤の回転という2つの物理的な移動が必要になるため、メモリよりも探索速度がかかる。探索に使われるのがCPUのキャッシュに乗りやすいアルゴリズムやデータ構造だと、より高速になってナノ秒（10−9乗秒）単位で処理できる。
OSレベルの工夫
OSは連続したデータを同じようなところにまとめ、データを4KB（kilobytes）くらいを一気に読むといった工夫をしている。
転送速度、バスの速度差
転送速度とは、見つけたデータをディスクからメモリ、メモリからCPUなどに計算機内部で転送するための速度である。hdparmというLinuxのツールを使うとその速度差がわかる。メモリとディスクの転送速度には100倍以上の差があり、メモリが7.5GB/秒に対し、ディスクは58MB/秒である。
３ スケーリングの要所
スケーリング、スケーラビリティ
Webサービスでは高価で速いハードウェアを買って性能を上げる「スケールアップ」戦略よりも、安価で普通の性能のハードウェアをたくさん並べてシステム全体としての性能を稼ぐ「スケールアウト」戦略が主流である。
スケーリングの要所—CPU負荷とI/O負荷
Webアプリケーションは後述するサーバ構成のうち、プロキシやAPサーバ（application server）が担当する。一方、DBサーバにはI/O負荷がかかる。
Webアプリケーションと負荷の関係
Webアプリケーションの三層構造には、プロキシ、APサーバ、DBがある。Webアプリケーションにリクエストが来てDBに到着、I/Oが発生して、I/Oが発生して返ってきたコンテンツを書き換えてクライアントに返す。基本的にAPサーバにはI/Oの負荷がかからない。DB側にI/Oの負荷がかかる。APサーバにはCPU負荷しかかからないので分散が簡単であり、リクエストの均等分散もロードバランサ（load balancer）装置が行ってくれる。一方でI/O負荷にはデータの同期をどうするのかという問題がある。
DBのスケーラビリティ確保は難しい
このように大規模環境では、I/O負荷を抱えるサーバはそもそも分散させるのが難しい上に、ディスクI/Oをたくさん発生するような構成であると速度差の問題が出てくるのである。
４ 大規模データを扱うための基礎知識
プログラマのために大規模データの基礎
以下の2つの観点から整理する。
- プログラムを作る上でのコツ
- 1.の前提知識
大規模データを扱う3つの勘所
- いかにしてメモリで済ませるか：ディスクのシーク回数を最小化する、局所性を活かした分散が実現できる
- データ量の増加に強いアルゴリズム、データ構造：線形探索→二分探索、O(n)→O(log n)
- データ圧縮、情報検索技術
大規模データを扱う3大前提知識
- OSのキャッシュ層（大きなデータを効率良く扱うための手法 OSのキャッシュと分散参照 3/20更新）
- 分散を考慮したRDBMSの運用（分散を考慮したMySQLの運用 DBのスケールアウト戦略参照 3/21更新）
- アルゴリズムとデータ構造（アプリケーション開発の要所 大規模データ処理実践入門参照 3/22更新）
コラム：『サーバ/インフラを支える技術』
１．Linux単一ホストの負荷
単一ホストの性能を引き出すためには、以下の3点を考慮する必要がある。
- 「推測するな、計測せよ」単一ホストの性能を引き出す
- ボトルネックを見極める：ロードアベレージを見る（topやuptimeなどのコマンド）。CPU、I/Oのいずれがボトルネックかを探る（topやsar、ps、straceやoprofile）
- OSのチューニングとは負荷の原因を知り、それを取り除くこと
２．二種類の負荷とWebアプリケーション
一般的に、負荷にはCPU負荷とI/O負荷の2つに大きく分類される。例えば大規模な科学計算を行うプログラムはCPUに負荷がかかるものであり、ディスクに保存されたデータから任意のドキュメントを探し出す検索プログラムはI/Oに負荷がかかる。
- マルチタスクOSと負荷：WindowsやLinuxなどのマルチタスクOSは同時に複数の異なるタスク（処理）を実行することができる。非常に短い時間間隔で複数のタスクを切り替えながら処理を進めることでマルチタスクを実現している
- ロードアベレージが報告する負荷の正体：処理を実行したくても実行できなくて待たされているプロセスがどのぐらいあるかであり、より具体的にはCPUの実行権限が与えられるのを待っているプロセスと、ディスクI/Oが完了するのを待っているプロセスである
３．ロードアベレージの次はCPU使用率とI/O待ち率
- sarでCPU使用率、I/O待ち率を見る：sar（System Activity Reporter）はシステム状況のレポートを閲覧するためのツール
- I/Oバウンドな場合のsar：ロードアベレージが高く、かつ%iowait（I/O待ち率）の値が高い場合は負荷の原因がI/Oであると判断できる
- マルチCPUとCPU使用率：マルチCPUが搭載されていてもディスクは1つしかない場合、CPU負荷は他のCPUに分散できてもI/O負荷は分散できない。その偏りがsarの結果となって現れる
４．sarコマンドでOSが報告する各種指標を参照する
sarは過去の統計データにさかのぼってアクセスする（デフォルト）、過去のデータを周期的に確認するという2つの使い方がある。sarはオプション指定で、CPU使用率以外にも以下のように様々な値を参照できるようになっている。
- sar -u：CPU使用率を見る
- sar -q：ロードアベレージを見る
- sar -r：メモリの利用状況を見る
- sar -W：スワップ発生状況を見る
５．I/O負荷軽減とページキャッシュ
ページキャッシュは一度ディスクから読み出したデータは可能な限りメモリにキャッシュして、次回以降のディスクリード（disk read）が高速に行われるよう調整するというLinuxの特徴のことである。Linuxは可能な限り空いているメモリをページキャッシュに回そうとするというポリシーを持つ。
- ページキャッシュによるI/O負荷の軽減効果：完全にデータがメモリに載るだけの容量があれば、ほぼすべてのアクセスはメモリから読み出しを行うことになるので、プログラムでメモリ上にファイルの内容をすべて展開した場合と変わらない速度が期待できる
- ページキャッシュは一度readしてから：DBがロックし、サービス不能になる可能性があるため
最後に
一般的に、負荷にはCPU負荷とI/O負荷の2つに大きく分類される。CPU負荷はサーバ増設で負荷を分散させることができるが、I/O負荷を抱えるサーバはそもそも分散させるのが難しい。最後に『サーバ/インフラを支える技術』要点も5回にわたってまとめた。
次回は、大きなデータを効率良く扱う OSのキャッシュと分散について解説する。
 |
[Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB DB PRESS plusシリーズ) |
