Yahoo! JAPAN 紀尾井町オフィスにて『Yahoo! JAPAN MEET UP』に参加してきた。
ダイナミックな技術というよりも、サービスの向上の為にリファクタリングや開発環境の改善に、たくさんの労力をかけていたというのが印象的。
yj-meetup.connpass.com ※資料は後日 connpass で公開されると思われる。
Yahoo!ショッピングの技術のお話
ドキュメンタリー「eコマース革命」と「いい買い物の日」
eコマース革命
eコマース革命前のヤフーショッピングはひどかったとのこと。
2012年ににかけて前年割れをしてサービス存続の危機を迎えていたらしい。
そこで！ eコマース革命
- 毎月の出店料：無料
- 売上ロイヤリティ：無料
その結果、
- 商品数が3倍、店舗数16倍、140%成長
- サーバも7000−8000台
- エンジニアが倍以上
いい買い物の日
いい買い物の日とは？
11月に開催される大イベントで、11月11日はポイント全品11倍となる。300万商品のセールが開催される。
2015年
売上目標から負荷を見積もり、多分大丈夫そうだったが一応サーバー増やして構えてた。
結果、売上推移昼過ぎまでは予想通りだったが、20時移行爆発的に売上が上がってきた。
最終の24時に向けて駆け込み注文が大量にきて決済システムのDBが詰まってしまい、決済が一切できなくなってしまった。
2016年
2015年の教訓を活かし多々対策を行った。
中でもAlibaba社訪問は刺激的なものだったようだ。
Alibaba社にてアクセスの平準化のアイデアは？と聞くと、
平準化は必要なし、お客様の買いたい時に買えるようにするべき
確かに！サーバを守ることが仕事ではなく、お客様が気持ちよく買い物をしていただくことが目的だった。
（これは私自身もはっとした）
目指したのは、トラブルが起きても影響を少なくする。ということで下記を対応。
- カードの後決済
決済エラーが起きても注文完了はしてしまい、裏で後から決済を通すようにした。それによりお客様に購入直前でのエラーということがないようにした。 - サーキットブレーカー
商品PFの負荷が高い時にメイン導線意外を落とすような仕組み。これによりメイン導線を死守するようにした。
結果、ラスト五分でものすごい負荷が来たけど、カード後決済が発動して乗り切った。
絶対に落ちないシステムをつくるのは難しい。
でも、ちょっとした仕組みを工夫することでユーザ体験を良くすることができる。
技術の方針決定
ヤフー全体で技術スタンダードというガイドラインがある。
カンパニーごとの方針はTDが決める。
大事なこと
- トラブル時の検知を徹底
監視検知→監視検知→監視検知 - テストはしっかり書け
- テストをちゃんと書け
- テストをきちんと書け
利用技術
- 10年前
- いま
- これから
OSSの利用はかなり活発になってきていて、ライセンスさえ問題なければ自由に使える。
開発ツールは特に決まったものは無い、開発者が自由に選んでいい。
PJ体制はエンジニア、企画、デザイナーが基本構成だが、エンジニアがPJを引っ張っていくシーンが多い。
これからの技術チャレンジ
- マルチビッグデータ活用事例
注文履歴からのレコメンドで、注文履歴がない場合に、同じ検索ワードから別の人の購入履歴からレコメンドすることで購入率が 3-4 倍になった。
データの活用方法はエンジニア次第。 - XP
- ペアプログラミング
- TDD
- PaaS化
Pivotal Cloud Foundry を採用している。デプロイ、ロールバック、監視、スケールアウトなど運用作業が圧倒的に楽になった。
最後に
ECはたくさんの技術要素が詰まっているというのは面白い業界。
WEBサービスの総合芸術ではないのか。
ゼロからわかるヤフオク！
サーバー台数 5000台以上。200人以上の人々で運営している。
ヤフオク！のこれまで
米国ヤフーのシステムをローカライズして発足した。
- ヤフオクのソフトウェア構成
- 出品、入札
- オークションファームに入る
- データ中継サーバから各サーバにデータを非同期で送信する
- 大量アクセスのポイント
- 参照キャッシュ
- サマリという概念で共有メモリで動かす
- メッセージングシステム
- 商品DBへの反映を非同期でやることでスピーディーに
2003年に今までの仕組みの限界値にきた。
5倍のアクセスに耐えれるように2005年で大規模リライト、リファクタリングを行った。
やったこと
- カテゴリの分割
- サマリの分割
- 物理マシンから IaaS へ
- etc
2014から大規模リファクタリング開始、現在もリファクタリング継続中
今取り組んでいること
並行開発をしづらい、リリースに時間がかかってしまうという問題。
システムの分解
PaaS の導入
開発プロセスの見直し
- CI/CD
ヤフオク！の開発を支える技術
1秒に590個で出品されている。
- dev
- Build & Unit Test
- Jenkins
- Screw driver
- Functional Test
- Deploy system
- Selenium
- Deploy
- Deploy system
- Screw driver
- Shef
- Open stack
ヤフオクのCI
CIツールをJenkinsからScrewdriverを導入した。
知見はyamlファイルに蓄積されていく。
Deploy前に機能テストが行われる。
Selenium, Jenkins で機能テスト行われてチャット通知。
UI変更は影響を受けやすいというのはある。
PaaS への取り組み
Cloud Foundryの導入した。 Concourse と selemium だけでデプロイまでやっている。
疎結合でのボトルネックが起きるという問題はある。
疎にした上でkeepAliveなどでオーバーヘッドを抑える取り組みは行っている
進化を求めるヤフオク！アプリ開発
なぜ進化を求めるか？
- 最新情報をキャッチ
- 新しいtry
- 環境改善
最新情報のキャッチ方法
- 知識のinput
- 勉強会などに積極的に開催
- 知識のoutput
- 社内LTの開催
- 社外セミナー登壇
- 社内セミナー登壇
outputこそ最高のinput
Rollout.io
アプリ内のメソッドw指定して修正ができる。 お客様の手元にあるアプリに反映できる。 https://techblog.yahoo.co.jp/advent-calendar-2016/rollout/
アプリで起きていた課題
色んなAPIを呼び出していて通信コストがかかってしまっていたのでアプリ用APIを作った。 APIをマッシュアップしたような感じ。 アプリ用APIは GoLang が使われた。
ヤフオク！iOSチームが実践する新しい開発手法について
LEAN XP を導入した。
LEAN XP では下記の3つのロールがある。
エンジニアの役割は
1.事前確認
ストーリーの価値、粒度、技術的ハードル
2. 見積もり
じゃんけん見積もり
3. 実装
テスト駆動開発の考え方習得方法は工夫が必要。
ペアプログラミングで解消されている。
品質の良いコードが書けてテストでの手戻りが少なくなる。
以下は問題点
- 開発環境としてできる場がないと難しい
- フリーアドレスとかと反している
- 案件で途中で抜けるとか、周囲の理解が難しい
ショッピングのデータプラットフォームとデータ利用活用
利用者がデータ・ドリブン。
データから意思決定を行い、サービス改善や流通に貢献。
旧データフロー
Rowデータから Mart、レポートが1:1になっていた Mart間の数字が合わないという問題が発生
新データフロー
Rawデータからアクセス、広告などのFactで分けたので、データの矛盾が起きなくなった。
（どうしても要件が解決できない場合はサービスMartを個別でつくる）
Fact は Row とほぼ同じデータになっている。
Row と Fact の違い
データの一貫性と高スケーラビリティ、データドリブンの分析が可能な環境になった。
データ分析
メジャーKPIから詳細KPIへ深掘りできるようになった。
何が悪いかどうかがすぐに分かるようになる。
1レポートで提供できるというのがとても大事。
ビジネスの要求は無限、どうぞ自由に分析してくれという環境が必要。
そこから以下の改善プロセスが回るようになっている。
- KPI分析
- 仮説・データ分析
- ABテスト
- 効果測定
- 意思決定・リリース
Data Utilization
データの活用に陽の目があったいるが、
Data Preparation
データを支えるその裏側に9割以上の力を注ぐ必要がある
今後
- データプラットフォーム
- ユーザの行動属性強化
- データシームレス化
- バッチのストリーミング化
