https://www.youtube.com/watch?v=jQNCuD_hxdQ
1 comment | 0 points | by WazanovaNews 約4時間前 edited
PinterestのMarty Weinerによる goto; conference 2014の講演。
などを語った45分のビデオですが、goto; conferenceのサイトからスライドのPDFをダウンロード(初日の10:20のコマです。)できるので、そちらを見ていただいてもわかりやすいかと。
「サイトが落ちてしまうのである意味自然に学ぶことができてしまった。」とのことですが、「これを聞いてくれてる皆さんが自分たちと同じ失敗をしないために。」というのが、Martyが伝えたいポイントです。
テクノロジーを選択するときに自問すべきことは、
- 自分たちのニーズを満たすのか。
- そのテクノロジーは成熟しているのか。
- 「成熟 = 血と汗が注がれたボリューム ÷ 複雑さ 」である。つまり、開発に世の中の人の多くの時間が費やされたテクノロジーでも、その進化に伴い複雑さが解消していかないと、「成熟した」とは言いがたい。MongoDBは流行っていたので手を出して、確かに多くの人が取組んでいたが、(自分たちにとっての複雑さが解消されず、使いこなせなかったので)自分たちにとっては失敗だった。
- 一般的によく使われているのか。そのテクノロジーの経験のある人を雇うことができるか。
- 例えば、MySQLの経験者なら、Palo Altoの街中で大きな声で呼びかければ、周りにゴロゴロいる。
- そのテクノロジーのデベロッパーコミュニティは盛り上がっているか。
- デベロッパーコミュニティに質問を投げかけたときに、すぐにレスがあるか。
- 深夜2時にサイトが落ちて、孤立無縁のとき、ググるとたくさんの記事を見つけることができたり、Stackoverflowで盛り上がっていると、問題の解決の大きな助けになる。
- 障害耐性 and/or 障害復旧の考慮がされているか。
- うまくスケールできるか。自分のサービスがそのテクノロジーの最大ユーザになっても不安はないか。
- デバッグツールは充実しているか。プロファイラーは?バックアップのソフトはあるか?
- コストに見合うか?
もし時計の針を戻して、Pinterestをつくり直すことができるのであれば、
- 初日からやるべきだったのは、
- ログは取得する。全てのリクエスト、イベント、ユーザ登録など。
- 基本的な分析ツールやnagiosでのアラートなど。
- 障害からのデータ復旧のことを考慮してつくる。
- もっとタイミングを早めるべきだったのは、
- MySQLのシャーディング。スレーブからの読込みに頼るようになった時点で、将来の障害の時限爆弾のカウントダウンがはじまっていると考えるべき。
- オペレーションエンジニアの採用タイミング。
- Chef / Puppet
- ビルドにJenkinsを利用してのユニットテスト
- A/Bテスト。段階的なリリースやすぐにロールバックできる仕組み。