大規模サービス技術入門」というその名の通り大規模なWebサービスをどう運用していくかを説明している本です。理論的な説明だけではなく、実際にはてなで使われている運用方法などの「泥臭い」部分をかなり詳しく説明してくれているとても実践的な本でした。Engineのようなクラウドサービスを使おうと思ってしまいました。自分でここまでする気にはならないですね...。基本的にはパフォーマンスの問題はCPUかI/Oのどちらかがボトルネックになります。いう時は単順にtopやsarでどちらの問題か切り分けます。どのプロセスがCPUをどれくらい使ってるかとかI/Oの待ち時間がどれくらいあるのかとかを確認すれば、だいたい目星はつくでしょう。CPUがボトルネックの場合は以下のような解決方法があります。単純に計算量が足りないだけなので、比較的解決は簡単なようです。サーバを増やして処理を分散させる。この場合はDBと違ってデータのレプリケーションなども必要無いので、比較的簡単にスケールする。アルゴリズムを改善して計算量を減らすI/O側はCPUのように、サーバの台数を増やすだけでは簡単にスケーリングできないので対応が難しいようですね。Googleが独自の分散ファイルシステムやデータベースを持っているのもそれが理由でしょう。対応の仕方としては以下の方法があるそうです。できる限りキャッシュやメモリのヒット率を高めてディスクアクセスがないようにする。(メモリはディスクアクセスの10万倍以上高速)プログラム変更でメモリの利用が減らせるならそうする。足りなければメモリを増やす。できないならデータを複数サーバに分散させる。データベース側のスケーリングをする(最終手段)。マスタDB(書き込みを担当するDB)のスケールアウトはACIDが求められるため難しいが、テーブル毎やエントリー毎に別サーバにデータを分散させるようなトリッキーな事をすることもあるようです。TwitterもMySQLの分散とmemcachedで運用しているみたいですね。RDBの分散やデータの圧縮の話はとても面白いと思いました。JOINを使わずに複数回クエリを投げるプログラムを書いたりするらしいです。RDBではないですね。他にも、データ圧縮をI/Oを減らすためだけとかに使ったりとか、データをページキャッシュにのせるためにアプリケーションで使われる大規模データを一度catしたりとか、面白いノウハウが載っていました。いえば、僕のサポートしているシステムでもデータをキャッシュに入れるために、再起動するたびにウォームアップさせてるなぁなんて思いながら読みました。後半のインフラ系の話の部分はまだ読めていないので、また後日にでも。見た感じ、SSDを使った高速化とか面白そうだな。Labというイギリスのケンブリッジにあるスタートアップ企業でプロジェクトマネジメントやシステム設計から開発までしています。2007年に新卒でJPモルガン証券に入社し債券リサーチやリスク管理システムの開発に携わる。2012年4月からグリーでSNSアプリやMessengerアプリの開発に従事。2013年8月より現職。