25
ISUCON1,2のハナシ 問題ふりかえり編 ISUCON Makers Casual Talks 長野雅広 kazeburo

Isucon makers casual talks

Embed Size (px)

Citation preview

ISUCON1,2のハナシ問題ふりかえり編

ISUCON Makers Casual Talks長野雅広 kazeburo

ISUCON1

ISUCON1

• 簡易ブログシステム• インデックスページ(ページングなし)

• 記事ページ• 記事投稿とコメント投稿• サイドバー

ISUCON1

サイドバー

「新着コメントエントリ」をコメントが投稿される度に全てのページで更新する必要がある

サイドバーの攻略• 割と重めなクエリをキャッシュしたい

• ページまるごとキャッシュはNG

• 1秒で”どこか”のページに確認が行われる

• キャッシュの”単位”を考える

SELECT a.id, a.title FROM comment c INNER JOIN article a ON c.article = a.idGROUP BY a.id ORDER BY MAX(c.created_at) DESC LIMIT 10

実際のサービスでは

<!--#include -->

Apache/mod_ssiPlack::Middleware::SSI

SSI

記事/index サイドバー

SSI + memcached

memcached

AppPOST時にcache更新

SSI Engine

Routerinternal request

POST

requ

estはバイパス

フロントキャッシュ戦略

• Reverse Proxyでcacheへのアクセスを行ってSSIを処理すればより高速

• nginx + memcached

• varnish(ESI)

ISUCON2

ISUCON2

• チケット販売サイト• 会場と座席の種類を選択し、購入• 座席表が表示される• サイドバーあり

ISUCON2

ボトルネックは2つ

• 座席表のHTML出力

• 購入トランザクション• (サイドバーはそれほど問題にならない)

座席表1席1マス384KB

座席表HTML出力戦略• キャッシュは役に立たない

• 購入処理は秒間数十~数百件• 静的書き出し

• Workerを別途起動し、1秒毎にHTML

を生成し、静的ファイルの配信にする

座席表HTML出力戦略nginx

App

Worker

HTML HTML HTML

HTML生成

購入処理

1秒に1回

購入トランザクション$dbh->begin_work;$dbh->query('INSERT INTO order_request (member_id) VALUES (?)',$member_id);my $order_id = $dbh->last_insert_id;my $rows = $dbh->query( ‘UPDATE stock SET order_id = ? WHERE variation_id = ? AND order_id IS NULL ORDER BY RAND() LIMIT 1', $order_id, $variation_id,);if ($rows > 0) { my $seat_id = $dbh->select_one( 'SELECT seat_id FROM stock WHERE order_id = ? LIMIT 1', $order_id, ); $dbh->commit;} else { $dbh->rollback;}

わざと複雑に書いた

購入トランザクション1.購入履歴テーブルへのinsert。

auto_incrementのidがorder_idとなる

2.在庫テーブルをORDER BY RAND() LIMIT 1で更新

3. order_idを使い在庫テーブルから席番号を引く

トランザクションを無くす• Redisを使う

1. order_idは INCR で生成

2. 予めランダムに並べられた席番号リストから LPOP

3. MySQLの 購入履歴テーブル、在庫テーブルの更新

ISUCON1,2の問題をふりかえって

データの量

データの量と難易度• ISUCON1

• 記事数 3,000、コメント数 16万

• dumpデータが129MB

• ISUCON2

• 座席数(=在庫数) 40960

• 同時購入処理 200

データの量と難易度• データ量が少なければ問題とはならない

• 実際のサービスと同じ

• データ量を変えながら、問題の難しさをある程度調整していた

• 開催直前にデータ量を変更し、特別賞のラインが想定とずれることも

• 参加者の方に楽しんで貰えるように

いじょうです