Googleを支える技術

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)

Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)


やべぇ。googleやばすぎる。。。参考に、なるかもしれないが
レベル高すぎてついて行けません。てのが印象。なんだかすごすぎて笑います。
あと丁寧な記述でとても得るところの多いよい本だと思います。すぐ読めるし。
以下メモ。引用形式だけど多分に思い出しなので違うはず。

概論ぽい2章ぐらい

処理に上限値があるように設計する=>分散化が可能。

スケーリングが必要な用途はあんまりないかもしれないけど日常生活でも大事
なことなのかもしれない、とか思う

分散ファイルシステムとかクローラの下り

スケールがすごいデスね、独自システムすげーと感嘆の声を上げるだけ。やばすぎて縁はなさそう。ファイル読み書きの信頼性について

OSのチェックサムはエラーが多くて信頼できないから独自実装しました

GFSっていうGoogleさんのファイルシステムはファイルの書き換えとかのサポートがちょっ
と特殊らしくてまぁ、基本appendってスタイルみたい。

機能を絞り込むことで単純化する=>基本的には高速化するとも思うし。

思ったのは機能を絞り込むって時に既存(たとえばここではのファイルシステ
ム)の常識をいったん疑わないとダメなのかも、それが難しそうだ。やもす
れば追加、追加で複雑化するんだろうなぁとか、思う。疑ってない常識とか
実装の経緯とか歴史とかを知ってれば対象の機能が存置/廃棄の選択肢のあ
るものだってわかるからね。闇雲に当たり前になってることってのがネック
なんだろ(認識論的に?)要するに考えながら日々踊っていくしかないんだろうなぁ。。。

電力とか設備の下り

エクストリーム過ぎる。。。電力設備効率はうまくやると2倍違うそうです。

  • 処理内容によってpen3>pen4処理と電気代を含めたコストとか

CPU効率もpen3がいいって時もあるのね。

  • 電源をもディファイ

PC電源はレガシーな物も含めていらない電圧変換がついてて効率を下げてるそうです。
電源を要らない電圧の変換をキャンセルしたら電源効率が70=>95%ってのが驚き。

  • データセンターレベルでピークを抑えるサーバーの処理分担

時間帯とかでCPUピーク=電圧ピークを色々パズルすると。

  • パワーキャッピング

電圧で処理速度をリミットすると。すんごいねぇ

  • ハードが市販レベルと同じものものなんだって

普通にPen3とかのマシンだったみたい。(今はデュアルのメインストリームな
やつらしい)そのとき入手できるコストパフォーマンスのよいものを選ぶんと
のこと。で、それってはてなと同じ?で、はてなは落ちまくっていてGoogle
障害知らずとか思ったけど昔はgoogleも落ちてたか。スケールの関係でユー
ザーに障害が見えるかどうかってことなのかのしれないし自前の単一サービ
ス(予測ができるgoogle)と外部とのコミュニケーションがあるアプリケーショ
ンサービス(hatena)のちがいかねぇ。知らん。たぶん違う。障害はダメです。
スケールだけだろ。

  • HDDディスクの話
    • 故障率は稼働時間と関係がない
    • 使用頻度と関係がない
    • 温度は40度ぐらいが実は最適なのでは?
    • SMART値のエラーで関係ないものも多いし関係あるものでも故障率の説

明力としては信頼仕切れるものではない。

HDDは「当たり外れ」につきる。

ちょっとびっくりです。

開発関連

堅い、ベーシックな仕組みをちゃんとやってるんだなぁって印象

  • コードレビューを徹底
  • 20%ルール=>社内デモ=>正規プロジェクト
  • ドキュメント作成を徹底(公式文書の元になるのだから思いついたそのときに書いて置けってのは書きやすいかもしれん。ドキュメントだけ書くからたぶん破綻する)
  • メーリングリスト!、ブログ、SCM(メーリングリストはやっぱりよいものですね。googleはソースもThunderbirdを独自拡張を入れたやつで書くとか聞いたことある。だよなぁ。自分の所に届くからなぁ。楽だよなぁ)
  • 週次報告。
  • OSはlinux(日本語イランならlinuxでよいねぇ)、既存のRDB使うならMySQLC++,java,Python
  • テストはちゃんとするし分散化を含めて性能のことは早いうちから気にする文化圏。
  • 他もいろいろ。思い出せたのはここまで


この本おもしろい。おすすめ