Rubykaigi Reception
- 6. about me
• RubyKaigi2009 実行委員
– 受付/オペレーション担当
• RubyKaigi2009 LT
– 「ローカル環境向けKey-Valueストアの紹介」
• 東京Ruby会議01 スピーカー
– 「オフィスで踏み出すRubyの世界」
- 9. outline
• RubyKaigi2009の「受付」
1. requirement
2. ext-design
3. int-design
4. implement
5. test
6. production
- 17. ①一般・認証キュー
一般・
一般・認証キュー 認証
受付
1階~階段に並んでもらう?
・将棋倒し防止のため流量制御必須
・ピーク時は1階を蛇行
・広さはどれぐらい?
- 18. ②一般・認証受付
一般・認 名札
一般・認証受付
証キュー 取り
• 受付トランザクション流入数:1~5位
• 「みどりの窓口」パターン
• 台帳は全員が同じものを持つ
– ○:スケーリングと縮退が楽
– ×:チケット複製をすぐには発見できない
– △:全文検索に時間が掛かる
– ×:業務後バッチで統合(いつやろうか)
- 19. 認証時の参加者の流れ
受付
①認証待ち ②空いたら受付 要員
受付
要員
受付
要員
③名札へ
- 20. スループットを上げたい
• 仮定:1受付要員:1分:3人
– 5受付要員時:20分:300人
• 20分待ちで第1回一般チケットの人さばける
• 台帳検索速度が多分ボトルネック
– 探しやすいインデックス
– めくりやすいインデックス
• 大き目なインデックスシール
• PC投入
– todo:何にインデックスを張るかを決める
- 21. 認証
• 通常系
– 参加者からの「提示物」で台帳サーチ
• 「提示物」
– チケット画面
– PayPalメール
– PayPalで使ったメールアドレス
• サーチキー:メールアドレス?
– 認証:ハッシュ値突き合わせ?
• todo:例外処理
– 提示物が無い時
– 台帳に無い時
- 23. todoまとめ
1. 台帳のサーチ/インデックスキーを何にするか
– メールアドレス以外にいいのがあるか?
2. どんな属性を使って認証するか
– ハッシュ値利用?
– メールアドレスがあればいい?
3. 認証時の例外処理
– 対応手順を決める必要がある。まず案出し。
4. スピーカー、スポンサー、プレス等の受付要員数
– 1人で足りる? スポンサー専用受付ある方がいい?
5. 台帳統合バッチを実施するタイミング
– どうにかします
6. どこに何列で並んでもらおうか
7. 名札はどこに置く?