に行ってきた。
Yahoo! JAPAN MeetUp #9 （EC技術カンファレンス） (2017/02/18 14:00〜)
今回のテーマは「E-Commerce」です！ ECの成長を支えるため、各サービスが考えている技術戦略から、ヤフーの持つビッグデータ、データサイエンスの活用事例紹介など…ヤフーのEC事情がぎゅっと詰ま っています。 当日は現場のエンジニアやデザイナーもいるので、聞きたいこと・話したいことがあればなんでも聞いてください。
自分が仕事で担当してるサービスに取り込める何かを持ち帰るのが目的。
以下、発表や懇親会でYahoo!ショッピングのエンジニアさんに聞いて印象に残ったことのメモ。
いい買い物の日の受注集中による障害と対策
いい買い物の日とは
11/11に買い物すればポイント11倍 というキャンペーン
2015年のキャンペーンでは、 キャンペーン終了間際の23時頃から急激に受注が増え、一時的に決済サービスが応答不可になり、決済できなくなる障害が起きた。
アリババのエンジニアに相談して対策をうち、 2016年のキャンペーンを無事に乗り切った。
サーキットブレーカーを実装
- OSS は使わず、社内で簡易的に実装したのを使っている
- サービスごとに独自に実装してる
- 言語は PHP や C++
- アリババが実装してるサーキットブレーカーは高機能( ○% を絞る、みたいに段階的に調節する )
- アリババは OSS にする予定は無いとのこと
カード後決済
- 決済サービスが障害で応答しない場合、まず受注してしまう
- 復旧したあとでカード決済させる
- サーキットブレーカーで遮断された決済を、カード後決済させる
スロットリング
(※ スロットリングとは言ってなかったが、スロットリングのことだろうと解釈している ※)
(※ サーキットブレーカーは “リクエストする側” の対策。スロットリングは “リクエストされる側” の対策。という理解 ※)
- リクエスト元のクライアントを優先度で分類しておき、負荷が上がってきたら優先度の低いクライアントから、リクエストの応答をやめる(絞っていく)
- 優先度のルールは予めビジネス側の同意をとっておく
- アリババは、サーバーのリソース使用状況を監視して絞る比率を動的に調節している
テクニカルディレクターが現場に言ってる4つのこと
(※ テクニカルディレクターはペパボでいうところの CTL 的なポジション ※)
- トラブル検知の仕組み
- テストを書け!
- テストを書け!!
- テストを書け!!!
.
- トラブル(データ不整合等)を検知する仕組みが整っているかを最重視
- 数日経って発覚するなんてありえない
- 新しいコードはテストが無いとリリースさせない
- 全体のカバレッジは60〜70%くらい
- カバレッジの数字は指標にしていない
- 大事なところをしっかりテストできているかを重視している
感想
ちょうどサーキットブレーカーの必要性を感じていて PHP のライブラリを絶賛実装中ということもあり、どういう実装してるのかとても興味深かったが、担当したエンジニアさんが会場にいなくて細かい話を聞けなかったのがとても残念だった。
カード後決済の仕組みも気になっていたが、時間が足りなくて聞けなかったも残念。
でも学びもたくさんあって、カード後決済は目からウロコだったし、スロットリングの優先順位付けはなるほど〜と思った。
Yahoo!ショッピングは今年で18年とのこと。なんとなく、先進的な技術を取り入れて凄いことやってるイメージをもっていたが、LTではレガシーな部分と戦う様子を伺えたのが印象的だった。
コードベースも利用者も桁違いに多いので色々運用も大変なはず。なのに自分が担当しているサービスよりもイイ感じになってるのが少し悔しい。 もっと頑張ろう。
Yahoo!のみなさま、貴重な学びの機会をいただきありがとうございました！