赤いラクダは3倍早い！ピーク時毎分1400件を捌くための決済処理のチューニング紹介 - pixiv inside
こんにちは、4月からBOOTH部になったorekyuuです。 この記事では、転属後の一番大きな成果である、BOOTHで発生する大量の注文(ピーク毎分約1400件)を整合性を取りつつ高速にさばく改善について解説します。 BOOTHが抱えていた課題 まずはBOOTHが抱えていた課題について説明します。 BOOTHでは販売開始時刻が事前に予告されていた場合などの理由で瞬間的に決済が集中し、サーバーが大量の注文に耐えきれないケースが度々ありました。 その原因は在庫の処理にありました。擬似コードですが、注文の処理は以下のようになっていました。 def checkout! ActiveRecord::Base.transaction do 商品の悲観的ロック # 在庫数を同時に編集しないようにロックを取る 商品の在庫の減算処理 注文を確定済みにする 決済の請求APIを叩く end end 上記のコード
敢えて制約を与えたほうがスピードが出せる
マネジメントなんて少なければ少ないほうが良いと思っていたのですが、最近考え方がガラッと変わって、会社の長期目標を達成するための組織設計を意識するようになりました。 思考実験もし「好きに目標立てていいし何でもやっていいけど成果出してね」みたいなマネジメント（？）をしたとします。 そうすると、メンバーは自分で考えてチームや会社にとって良さそうな何かを持ってきます。 自主性はとても大事なこと。まさに狙い通りです。メンバーがやりたいことを叶えてあげるためにマネージャーが環境を整えてあげます。 最初のうちはこれで良かったのですが、環境を整えるにも時間や労力がかかります。マネージャーがいちいちやってると手に負えないので、メンバーが使えるものは何でも使って（時には社内の誰かに頼んだりして）いい感じにやり始めます。 問題は主に2つです。コミュニケーションとはコストがかかるものであるということと、会社という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
