QCon Tokyo 2009 に行ってきました。二日目のメモ

qcontokyo

QCon Tokyo ２日目午後のメモです。午前の分は手書きなので、書きおこす時間が取れませんでした。(でもすごくよかったですよ！)
正確性はまったくあてになりませんので、そのあたりご承知のうえ、だまされたつもりでご利用いただければ。
あとプレゼン資料のメモが多く、著作権的にフェアユースの範疇なのかちょっとよくわかりません。ご指摘あれば対応させていただこうかと考えています。

クラウドをプログラミング - プラットフォームとしてのインターネット / Gregor Hohpe

  • Internet as a Platform
  • The bad
    • Architects' dream
      • Loosely coupled
      • Extensible
      • Standards-based
      • Fault tolerant
      • Unlimited computing power
      • Ubiquitous
    • Developers' Nightmare
      • NO Call Stack
      • NO Transactions
      • NO Promises
      • NO Certainly
      • NO Ordering Constraints
  • ACID
    • before
      • Atomic
      • Consistent
      • Isolated
      • Durable
    • today
      • Associative
      • Commutative
      • Idempotent
      • Distributed
  • Starbucks Does not Use 2-phase Commit Either
    • start making coffe before customer pays
    • reduce latency
    • What happens if ...
      • Customer reject drink => Remake (retry)
      • Coffee maker breaks => Refund (compensation)
      • Customer cannot pay => Discard bevarage (write-off)
  • Google way
    • GFS: Distribute File System
    • BigTable: Distributed Shared Memory
      • 列は何でも入る
      • åž‹: string, counter, byte array
    • MapReduce
    • Sawzall: Parallel Log Processing
  • Tools
    • Make the cloud more accesible
    • Make the client more powerful
    • ...
  • Google App Engine
    • python / 最近Javaをサポートした
    • 書くのは一度、勝手にスケールする
    • proigramming platform
    • management console
    • 1年経った - cronなどいろいろ機能を追加
      • secure data connector: 会社のサーバにアクセスできる
  • Programming the Cloud
    • different run-time models
    • Parallel execution
    • Distributed data storage (RDBMSではなく)
    • ....
  • [感想] 『Googleを支える技術』を読んでいると理解が早い内容でした。これを噛み砕いてふつうの人に伝えるのは大変だなあ。Google App Engineはjavaサポートしたんですね。

Ebay / Randy Shoup

  • Partition Everything
    • Pattern: Functional Segmentation
    • Pattern: Horizontal Split
      • Load-balance processing
      • Split data along primary access path: partition by modulo of a key, range, lookup etc
    • Corollary: No Session State
      • User session flow moves through multiple application pools
      • absolitely no session state ni application layer
      • Session state maintained in cookie, URL, or database
  • Best Practice 2: Asynchrony Everywhere
    • Prefer asyncronous processing
      • Move as much processing as possible to asynchronous flows
      • Where possible, integrate components asyncronously
    • Motivations
      • Scalability: Can independently scale component A and B
      • Availability: Allows component A or B to be temporarily unavailable, Can retry operations
      • Latency: Can reduce user experience latency, Can allocate more time to processing than user would toralate
      • Cost
    • Pattern: Event Queue
      • Primary application write data and produces event
      • Consumers subscribe to event
      • At least once delivery, rahter than exactory once
      • No Guaranteed order, rather than in-order
      • Idempotency and readback: イベント自体にはデータが入っていないので、データはマスタから読み出す
    • Pattern: Message Multicast
      • Search Feeder publishes item updates
        • Read item updates from primary database
        • Publishes sequensed updates via multicast to search grid
      • Search engines listen to assigned subset of messages
        • Update in-memory index in real time
        • Request recovery when messages are missed
  • Best Practice 3: Automate Everything
    • Prefer Adaptive / Automated systems to Maunal Systems
    • Pattern: Adaptie configuration
      • Do not manually configure event consumers
      • Define SLA for a given consumer
        • ex. process 99% of events within 15 seconds
      • Each consumer dynamically adjusts to meet defined SLA
      • Consumers automatically adapt to changes in
        • load
        • Event processing time
        • Number of consumer instances
    • Pattern: Machine Learning
      • Dynamicaly adapt search experience
      • Feedback loop enables system to learn and improve over time
        • collect user behaveor
  • Best Practice 4: Remember Everythig Fails
    • Build all systems to be tolerant
    • Pattern: Failure Detection
      • Servers log all requests
        • Over 2TB of log messages over day
      • Listeners automate failure detection and notification
    • Pattern: Rollback
      • Absolutely no changes to the site which cannot be undone(!)
      • Every features has on/off state driven by central configuration
        • Features can be immediately turned off for operational or business reasons
        • Features can be deployed "write-off"
    • Pattern: Graceful Degradation
      • Application "marks down" a resource if it is unavailable or distressed
      • Application removes or ignores non-critical operations
      • Application retries critical operations or defers them to an asynchronous event
  • Embrace Inconsistency
    • Brewer's CAP Theorem
      • any shared-data system cannot have at most two of the following properties: Consistency/Availability/Partition-tolerance
    • This trade-off is fundamental to all distributed systems.
    • Chooose Appropriate Consistency Guarantees
      • Immediate Consistency: Bids, Purchases
      • Eventual Consistency: Search Engine, Billing system etc
      • No Consistency: Preferences
    • Avoid Distributed Transactions
      • no two-phase commit
      • Minimize inconsistency through state machines and careful ordaring of database operations
      • Reach eventual consistency
    • Availabilty はギブアップした
  • [感想] すごく実践的な内容で、大規模サイト構築の悩むポイントがつまっていました。午前中の丸山先生の講演でも出てましたが、CAP理論で「２つまでしか成立しない」と言っている部分へのそれぞれの会社の対応がすごく興味深いですね。

アジャイル開発を始めるために / Henrik Kniberg

  • 平鍋さん: Henrikのミッションは「企業の文化を変える」
    • Agile は 変化に対応するだけではない、変化に対応して自分たちが変わること
  • Optimizeing, debugging and refactoring organizations.
  • Agile transitioning
    • easiest to lean: learnig by examples
    • この本ではちょっと違うアプローチで
  • Case 1 Bootstrap agile teams
    • First ask "Why change?"
      • Typical answers
        • faster delivery
        • Higher quality
        • Increased motivation and work pride
        • Clearer roles
    • Rough transitioning plan
      • typical pattern:
      • A: interviews: 1w? (人数による) クロスセクションでみんなに聞く
      • B: Training; 1day?
      • C: Workshops: 1week?
      • D: Preparation: 1week?
      • E: Launch: 1day?
      • F: Folow up & phase out: a few months?
    • Interviews
      • ホワイトボードでピア議論
      • 組織の関係とかを聞く。たまに人ごとに違っていたりする
    • Root cause analysis
      • このなかで最初になおす部分をきめていく
    • Problem: Teams grouped by component
    • Half-day training
      • 1 対 たくさん
    • Half-day workshops
      • グループごと
    • Goal: Feature teams
      • 機能ごとのチームをつくる
      • 機能を横断する職能のバーチャルチーム
    • preparation
      • Transitining Team: タスクリストを作る ( Transitioning backlog ) - Status/What to do/Definition of done
    • Who defines the teams?
      • Option1: Teams defines centrally
      • Option2: Teams form themselves from scratch
      • Option3: 1+2: 自己組織化を許す
    • Self-organizing to form new teams
      • Preliminary team allocation => After a week in the kitchen
    • Co-locate each team & launch sprint
    • Case 1 - key points
      • Look before you leap - Interviews - Coach learns / Traning - Coach teaches / Workshop - coach facilitate
      • Involve people
      • Incremental process improvement
  • Case 2: Speeding up product development
    • Process cycle efficiency = value add time / cycle time
    • 職能でまわしているとパイプラインが長くなり、出力が遅くなる
      • Scrum にする
      • カンバンを導入して在庫を減らす
    • リスク
      • Games out of date = Missed market windows / Demotivated teams / Overhead costs
    • Case 2 - Key points
      • Speed up product develomnent is usually a matter of improving the process rather than adding people.
      • Value stream mapping is a great tool for spotting people.
      • Push scheduling + too much WIP (work in progress) is usually root cause
      • Beware suboptimization!
  • change
    • まずあなたが変わる。
  • [感想] Henrikの虜になりました。たぶんしばらくいろいろ考えないと、感想が書けません。

パネルディスカッション

  • パネリスト
    • H: Henrik Kniberg @ Scrum Coach
    • G: Gregor Hohpe @ Google
    • R: Randy Shoup @ eBay
    • D: Dylan Schiemann @ Dojo
    • F: Floyd Marinescu
  • Henrik: 北欧では、アジャイルプロセスとしてScrumを採用する事例が多い
    • そうすると
      • 開発チームとビジネス側のコミュニケーションが改善する
    • そこで、別の問題がわかってくる
      • XPのプラクティス、たとえばTDDなどが必要になる
      • Leanの Value Stream Mappingとか
    • 景気悪化の影響: 以前は改善の話だけだったが、もっと大幅な変革が、すぐに、必要になっている
  • Hohpe: 既に知っていることをリサイクルことがよくある
    • クラウドとか
    • それは、新しいものだろうか？昔からあるものに、新しい名前を付けただけではないのか？
      • どちらもある
    • 本質的なアイデアは、また戻ってくる
      • 実証済みのアイデアなので、また使えるから: すべて新しくなくてもいい
      • 他の技術にも転用できるコンセプトを学ぶべき: 基本となるアイデアに集中する。次に現れたときに転用できるだろう
    • 最近は、ランタイムの重要性に注目があつまっている
      • コア
      • 分散
      • エージェント
      • ディスカバリ
    • ソフトウェアを書く、というのは一部でしかない
      • 分散の世界では、コードを書いても、デプロイするまで、わからない
  • Randy: スタートアップのコンサルを何件かしているが、
    • 当初から分散とかスケールアップの話が出る時代になった
    • 複数の言語／インフラでやろうとする mix環境
      • Java, .NET: 仕事によってベストなツールを選ぶ
    • デプロイメント: クラウドコンピューティング
  • Dylan
    • 90年代から、Javaがどんどん大きくなった。
      • そして大きくなりすぎた
    • OSSは細分化
      • Rails + merb
      • Dojo <- tibcoのなんか?
  • Martin Fowler が 北京のパネルで言っていたこと
  • Rod が 北京のパネルで言っていたこと
    • Empowerment
      • ツールがアジャイル化。リーンになっている。特定用途向けのツール
  • Floyd
    • Web 2.0
      • オープンプラットフォームから、アプリケーション・プラットフォームへの変化
    • クラウド/RIA
    • Java
      • 飽きてきた？: いや、Javaがつまらなくなったのではなく、タスクが安定してきた
    • Webにも Google Apps ã‚„ App Engine などでてきた
    • クラウド
      • 中小企業にも効果的に低コストでできるようになった: データセンターのことを考えなくてよいので
  • Hohpe
  • Rod
    • Grails <- Javaコミュニティのすごい進展
    • SpringSourceもクラウド対応の製品の発表がひかえている
  • Hohpe
    • Javaが新しくないことは、現在の技術で作る、という仕事上はいいこと
      • Javaは世界のFortran, COBOLになったかも
    • 新しいパッチをあてる作業よりも、新しいことに集中できる
  • 聴衆
    • 聴衆にWeb系以外の人がほとんどいないのは残念だ
  • Randy
    • EBayのバックエンドはWeb系ではない
    • 外から見ればWebサイトだけど、裏には関係ない処理がたくさんある
  • Hohpe
    • Webの定義によるけど、例えばバックエンドのコンポーネントを作っている人も、httpに苦労していたりとかするよね
  • Randy
    • 多くの作業は http とは全く関係ない。解析系とか
    • 非Web的なオペレーションがある
  • 聴衆
    • Scalaはどうっすか
  • ???
    • 関数系で、Erlangとかは 分散処理に適しているから、アプリが出てきている
  • Hohpe
    • 分散処理がうまくできる言語が欲しい
    • 人はどれくらいライブラリを使いこなすことができるだろうか？
      • Microsoft の LINQ とかは、SQLによる囲い込みを越えて、コア言語で直接使えるようになる
  • Henrik
    • いろんなツールを使えなければならない
    • ジェネラリストが必要。道具を判断できることが必要
  • Hohpe
    • デザインコンセプトを知っているか必要がある
    • ベストプラクティスを作るのは時間がかかる作業
      • Javaは10年かかった
    • 最大の制約は人間の学習能力
  • Dylan
    • 最適なツールを教えてくれるツールを開発してくれるといいのだけれど
      • コンサルいらなくなるね
  • 聴衆
    • テストはあまり変わっていないように思える
  • Hohpe
    • テストは２つの作業
      • 挙動の確認のためのテスト
      • 開発の一部としてのテスト: BDD
    • ツールの問題ではなく、ツールを作る人の進化
      • JUnitができてはじめて、いろいろなアイデアが出てきた。
      • こういうのは時間がかかる
    • ランタイム
      • ここでもテストしたい
  • Henrik
    • 開発者とテスタの境界が曖昧に。
    • テスタは自動テストできないところをテストできるかどうかが重要
    • ビジネス側との距離: Leanで近づいている
  • Hohpe
    • こないだ、僕がSpec書いた
  • Randy
    • Ebayでうまくいった案件は、ビジネスと開発者が近かったケース。
    • 逆にうまくいかなかったのは、分離したケース
  • Hohpe
    • 10年前のベストケースは現場でマクロを書いたケース
      • ニーズがわかっている人が書いていた
      • そこで解決できていないのは、分散処理とかクラウドとか。:AppEngineとかでまたできるようになるかも
  • [感想] すごくいい「ふりかえり」になりました。Henrik が 「いろんなツールを使えなければならない。道具を判断できることが必要」と言うところに涙しました。多くの道具を理解し、作っている人と使いこなしている人をリスペクトしないと、プロジェクトは成立しないと思います。思います。思います。