Contenu connexe
Similaire à Riakmeetup2forupload
Similaire à Riakmeetup2forupload (20)
Riakmeetup2forupload
- 5. RTB
媒体
広告主
SSP
DSP
ROI
収益
最大化
AdEx
(取引所)
• SSP
は「媒体側の収益最大化」が目的
• Supply
Side
Platform
• DSP
は「広告主の投資対効果(ROI)最大化」が目的
• Demand
Side
Platform
• ２つの事業者間で、入札による取引が行われている
• Real
Time
Bidding
(RTB)
RTB概略
- 9. RTB
媒体
広告主
SSP
AdEx
DSP
• ０.１秒
=
SSP
がrequestを投げ、DSPがresponseを返し切るまで
• RTB
は
TCP
の RoundTripTime
(RTT)
を含んだ時間
• SSP
は複数あり、多くの同時多発的リクエストが発生する
• 同時多発的なリクエストを
DSP
は出来るだけ吟味する必要
RTB
and
FreakOut
- 22. • 性能
• [Tokyo|Kyoto]
[Tyrant|Tycoon]
は高速
• 50ms
or
die.
を支えるためには速度が必要
• スケーラビリティ
• クライアントサイドのアルゴリズム分散のため、スケールし
にくい
• 「10台じゃ足りない!!
11台目を追加しよう」が簡単にできない
• 運用
• 通常運用では高負荷な状況でも実績がある
• データ検索したりできない(踏み込んだデータ活用に難有)
[Tokyo¦Kyoto] [Tyrant¦Tycoon] の課題
FreakOut
のサーバインフラ
- 24. • Perl
• アプリケーションはほぼ全て
Perl
• Perl
<-‐>
Riak
のやり取りを受け持つモジュールが必要
• KVS
• 既存の
TT/KT
へのアクセスは
Cache::Memcached::Fast
• Memcached
クライアントを使っている
• 運用
• メトリクス収集
-‐>
CloudForecast
• 監視
-‐>
Nagios
FreakOutのシステム
Riak
and
FreakOut
- 25. • Riak
Client
for
Perl
• Net::Riak,
Riak::Light,
Data::Riak,
AnyEvent::Riak
• REST
だけ
or
PurePerl
の Protobuf
サポート
• 残念ながら遅い
• Memcached
クライアントとインターフェース互換がない
• 既存の処理に組み入れにくい
• ないなら作るしかない
• Riak::PBC
<-‐
Protobuf
のオブジェクト
• Riak::Lite::PBC
<-‐
実際に Riak
とやり取りする
client
Riak
and
FreakOut
Perl と Riak
- 26. • その他のモジュールとの比較
• https://gist.github.com/myfinder/5232845
• 結果
• 3000%
over
faster
• 現状
Perl
の世界では(たぶん)最速
• memcached
like
interface
• Cache::Memcached::Fast
使ってる人には使いやすい
Riak
and
FreakOut
作った module の性能
- 27. • Test::riak
• https://github.com/myfinder/p5-‐test-‐riak
• 動作
• テスト実行時に、空きポートを
bind
して Riak
を起動
• テスト終了時に、Riak
を終了してくれる
• テスト重要
• 継続的に運用していくシステムにおいて”テストができる”こ
とはマスト要件
Riak
and
FreakOut
単体テストモジュール
- 29. • Engine
Yard
方式
• アプリケーションと Riak
の間に haproxy
を配置
Riak
and
FreakOut
運用構成
app
Riak
Riak
Riak
Riak
Riak
Riak
Riak
Riak
app
haproxy
app
- 30. • 監視方法
• stats
で取得可能なデータを cloudforecast
でグラフ化
• 死活監視は Nagios
で
port
を叩く
Riak
and
FreakOut
運用構成
スクショ参照
- 32. RTB
媒体
広告主
SSP
AdEx
DSP
約０.１秒
おさらい
Riak
and
FreakOut
- 37. • Redirect
がつらい
• haproxy
で分散しているので、redirectが起こりやすい
• スループットが上がらない
• Set
が詰まるとつらい
• Set
が詰まり始めると、worker
の
busy
率が上がる
• 書き込みの非同期化が必要
• もう一歩踏み込んだ対策が必要
Riak
and
FreakOut
50ms or die.的な見地からの課題
- 38. • キャッシュ層を設ける
• hot
な
key
については memcached
に任せる
• データの
origin
を Riak
に持つ
• -‐>
実装済み
Riak
and
FreakOut
スループット向上のために
app
Riak
Riak
Riak
Riak
Riak
Riak
app
app
Riak
Riak
memd
haproxy
- 39. • hash
から
partition
を特定する
• Riak
の持っている partition
情報を
RPC
経由で取得
• bucket
/
key
から
hash
を取得して、収容
partition
を特定
• @itawasa++
• partition
に所属するノードに直接getしに行く
• Riak::Lite::PBC
でサポート予定
• -‐>
今後の課題
Riak
and
FreakOut
スループット向上のために
- 40. • 素のままでは50ms or die.的に厳しめ
• 構成の工夫が必要
• 但しスループットを上げる手はある
• スケーラビリティの問題を克服できるメリッ
トは大きい
• サーバを足すだけ に運用を落とし込める
ここまでのまとめ
![Riak and FreakOut
Riak をプロダクションに投下 [した¦している] 話
Riak Meetup Tokyo #2 7/10 19:00 ‒ 19:45](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)