2/18の午後だけ行ってきました。きちんと聞いてきたのは2講演です。
【18-B-3】Google 的分散コンピューティング
Gregor Horpe氏によるGoogleの分散コンピューティング技術の紹介と、その背景にある思想の話。
○Google内で使われている分散コンピューティング技術
GFS, Bigtable, MapReduce, Sawzallの紹介、Googleを支える技術 ~巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ)
Sawzallの発音が”ざうざーる”と言っているようでした、これまで”さうざーる”だと思い込んでた。
○Googleの分散システムの背景にある思想
8つに分けて、事例を交えて紹介してくれました。
- Shading
- Less is More
- Expect Failure
- Autonomy
- Enpower the Runtime
- Favor Stateless
- Separate Stateless from Stateful
- Precision vs Speed
1. Shading
分割して統治する。役割を分ける、機能を分ける、抽象化する。
例として挙げていたのはユーザアカウント管理に中小レイヤをかぶせるやつだった・・・かな? メモがなくスライドもまだ見れないのでうろ覚えです。
2. Less is More
機能を絞って特徴を引き出す。
Bigtableはトランザクションを始めとしたRDBMSの機能が無いが、その分スケールするように作ることができた。
3. Expect Failure
「エラーが起きるかどうか」ではなく「エラーはいつ起きるか」を考える。ifではなくwhen。
GFSもMapReduceもベースにエラー処理がきちんと組み込まれている。
GFSなら自動でマスタが切り替わる仕組みとか、MapReduceなら失敗したタスクの再スケジューリングとか処理対象からの除外とか。
4. Autonomy
とにかく自動化、人では介さない。
例として挙げられていたのはGFSのMaster/Slave構成。
Masterに障害が発生するとSlave同士が投票しあって次のMasterを決めるようになっている。
5. Enpower the Runtime
言いたかった事がうまく受け取れなかった。「役割を明確に決めないで柔軟にやってね」ってことだと理解しました。
6. Favor Statelessと7. Separate from Stateless from Stateful
状態を持たない。なぜなら状態を持つと途端にスケールしなくなるから。
状態を持つにしても、スケールする部分をきちんと切り分けておくことが大事。
8. Precision vs Speed
ソフトウェアではfaster is better。正確性を期するよりも、高速で大体の精度の予測で動く。
Googleのクラウドで正確な負荷とか測れても意味がない。大体の傾向がつかめればOK。
【18-C-4】ドッグフーディングとアジャイル開発
アトラシアン社の営業さんによる会社の紹介と、社内で行っているアジャイル開発の紹介。
アトラシアンはエンタープライズWiki(Confluence)や障害管理システム(JIRA)を主力商品としており、国内外で多くのユーザを抱えている。日本国内では今回が初めての公演ということで会場は超満員でした。
アトラシアン社は2002年にオーストラリアで設立された。3つの方針を掲げ、OSSの世界をはじめ多くのユーザを抱えている。
- いい製品を手ごろな価格で
- 伝統的な営業マンを持たない(電話をかけまくったり、会社訪問しまくる営業マン無し)
- エコシステムの構築に尽力(製品にプラグイン構成を持たせるなど)
アトラシアンの製品はショートリリースを基本としている。それはユーザからのフィードバックを得やすいからであって、サブスクリプションユーザに価値を提供するためでもある。またチームメンバの緊張感を適度に保ち、バグ修正に時間を割いて使うようにもなるメリットが有る。リリース期間が短いことから必然的にアジャイル開発の形態をとっており、社内で開発版を試す「ドッグフーディング」の文化も根付いている。会社設立時メンバが2人しか居らず、早急に事業を立ち上げるためアジャイル開発をとらざるを得なかったことも今の会社に影響しているかも知れないとのこと。
ドッグフード中のシステムは不安定で、Wikiなどはマイルストーンリリース時は1日1回ぐらい落ちるらしい。社員は不便を感じるが、それが客先で障害として発生するよりかはましという考え方をしている。バグ以外にフィードバックも社員から得られることもある。バグ情報やリクエストは社外に公開した障害管理システムで受け付けているとのこと。
最近ショートリリースのタイミングをさらに狭めたらしく、98日でイテレーションを回しているとのこと。98日のスケジュール詳細はDevelopers Summit 2010 Preso – Sean Osawa – アトラシアン ウィキから詳しく見ることができます。Googleの20%ルールに近い制度がアトラシアンにもあるらしく、開発者はイテレーション中の時間がある期間(Week 12 〜 Week 14あたりだったかな?)に直接の業務と関係が無いことも取り組んでいるらしい。
社内ではレビューを多用している。レビューには早期修正できるコスト削減効果や、開発者の教育効果がある。駄目なレビューでは単なるプレゼンになっていたり、熟練による支配が起きてしまう。
アトラシアン社員のレビューTIPSとして以下が挙げられてました。
- レビュー前にコードに関する課題、タスクに目を通す
- 変更構成を読む
- 機能が動いているかを確認する(確かに年に何回か動かない機能のコミットがある)
- 自分が変更するならどういう方針を取るかを考えてみる
- レビュー終了後に提案リストを優先順位をつけてまとめて送る
レビューのタイミングとしては頻繁に行うこと。朝でも昼でも、帰る前でも、まとめて行い、開発に割く時間をうまく確保するのもコツ。
見てもらうのは同僚が一番、同僚がだめならTech Lead(技術面の開発リーダかな?)がいいとのこと。ごもっとも。
Trackbacks /
Pingbacks