読者です 読者をやめる 読者になる 読者になる

dskst's diary

Life and Tech Blog

『Yahoo! JAPAN MEET UP』に参加してきた

勉強会

f:id:dskst9:20170219011321j:plain

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が決める。

大事なこと
  1. トラブル時の検知を徹底
    監視検知→監視検知→監視検知
  2. テストはしっかり書け
  3. テストをちゃんと書け
  4. テストをきちんと書け
利用技術

OSSの利用はかなり活発になってきていて、ライセンスさえ問題なければ自由に使える。 開発ツールは特に決まったものは無い、開発者が自由に選んでいい。
PJ体制はエンジニア、企画、デザイナーが基本構成だが、エンジニアがPJを引っ張っていくシーンが多い。

これからの技術チャレンジ

  • マルチビッグデータ活用事例
    注文履歴からのレコメンドで、注文履歴がない場合に、同じ検索ワードから別の人の購入履歴からレコメンドすることで購入率が 3-4 倍になった。
    データの活用方法はエンジニア次第。
  • XP
  • PaaS化
    Pivotal Cloud Foundry を採用している。デプロイ、ロールバック、監視、スケールアウトなど運用作業が圧倒的に楽になった。

最後に

ECはたくさんの技術要素が詰まっているというのは面白い業界。
WEBサービスの総合芸術ではないのか。

ゼロからわかるヤフオク

サーバー台数 5000台以上。200人以上の人々で運営している。

ヤフオク!のこれまで

米国ヤフーのシステムをローカライズして発足した。

  • ヤフオクのソフトウェア構成
  • 出品、入札
    • オークションファームに入る
    • データ中継サーバから各サーバにデータを非同期で送信する
  • 大量アクセスのポイント
    • 参照キャッシュ
    • サマリという概念で共有メモリで動かす
  • メッセージングシステム
    • 商品DBへの反映を非同期でやることでスピーディーに

2003年に今までの仕組みの限界値にきた。
5倍のアクセスに耐えれるように2005年で大規模リライト、リファクタリングを行った。

やったこと
  • カテゴリの分割
  • サマリの分割
  • 物理マシンから IaaS へ
  • etc

2014から大規模リファクタリング開始、現在もリファクタリング継続中

今取り組んでいること

並行開発をしづらい、リリースに時間がかかってしまうという問題。

ヤフオク!の開発を支える技術

1秒に590個で出品されている。

  • dev
  • Build & Unit Test
    • Jenkins
    • Screw driver
  • Functional Test
  • Deploy
    • Deploy system
    • Screw driver
    • Shef
    • Open stack
ヤフオクのCI

CIツールをJenkinsからScrewdriverを導入した。
知見はyamlファイルに蓄積されていく。

Deploy前に機能テストが行われる。
Selenium, Jenkins で機能テスト行われてチャット通知。 UI変更は影響を受けやすいというのはある。

PaaS への取り組み

Cloud Foundryの導入した。 Concourse と selemium だけでデプロイまでやっている。

疎結合でのボトルネックが起きるという問題はある。
疎にした上でkeepAliveなどでオーバーヘッドを抑える取り組みは行っている

進化を求めるヤフオク!アプリ開発

なぜ進化を求めるか?

  1. 最新情報をキャッチ
  2. 新しいtry
  3. 環境改善

最新情報のキャッチ方法

  • 知識のinput
    • 勉強会などに積極的に開催
  • 知識のoutput
    • 社内LTの開催
    • 社外セミナー登壇
    • 社内セミナー登壇

outputこそ最高のinput

Rollout.io

アプリ内のメソッドw指定して修正ができる。 お客様の手元にあるアプリに反映できる。 https://techblog.yahoo.co.jp/advent-calendar-2016/rollout/

アプリで起きていた課題

色んなAPIを呼び出していて通信コストがかかってしまっていたのでアプリ用APIを作った。 APIマッシュアップしたような感じ。 アプリ用APIGoLang が使われた。

ヤフオク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割以上の力を注ぐ必要がある

今後

  • データプラットフォーム
  • ユーザの行動属性強化
  • データシームレス化
  • バッチのストリーミング化

認定スクラムマスター(CSM)研修を振り返る

Scrum

認定スクラムマスター研修

認定スクラムマスター研修を受けてきた。
研修を受けて、心構え、世界観が大きく変わった。
講師の ebacky さん ありがとうございます。とても刺激的で楽しかったです。

今後スクラムマスターとして活躍できるかは自分次第なので、
自身の復習のために学んだことをまとめていこうと思う。

内容としては 各種Ceremony、 Team・Scrum Master・Product Ownerの役割、Scrum Master の心得・スキル、など 19のルール とともにまとめていこうと思う。
※Scrum 初心者のため間違いがあったら是非ツッコミを入れていただけるとうれしい。

初回は Scrum の概要と19のルールについて。

Scrum とは

Scrumとは プロジェクトの現状を把握するためのフレームワーク である。

問題を解決するのではなく、問題を発見するのである。

Scrum は1993年に Ken SchwaberJeff Sutherland によって発案された。

組織論、集団心理の要素から提唱されており、 Scrum Team 全員が現状を把握できるようになる。
Scrum は確認する、プロダクトで計る。
“Say it’s done” 終わっているというけど… じゃあ見せて。と言った感じに。

Scrum でプロジェクトの何%が把握できるのか

過去と現在は 100% 把握できる。
未来も含めても、なんと 98 %

近い未来を仮説で把握するので、遠いい未来は把握できない。
そもそも、遠い未来なんて誰がどんなことをしてもわからないから、 Scrum は早いサイクルで価値のあるプロダクトを提供していくのである。

Scrum ≠ Agile

Scrum = Agile と思ってしまうのは、よくある勘違い。(私もスクラムマスターをやる前はそう思っていた一人…)
アジャイルは概念である。方法、手法ではないのだ。

“Be” Agile, Don’t Do Agile.

Agileとは。そう、青春と同じように振り返ると Agile だったと言えるような、過去でしか評価できないものなのだ。
Scrum は Agile Software Development のフレームワークの1つということになる。

アジャイルソフトウェア開発宣言

アジャイルの基本原則と価値 (Jeff Sutherland 著)

Scrum 3つの柱

Scrum は下記を三本の柱として考えられている。

  • Transparency (透明)
  • Inspect (検証)
  • Adapt (適用)

Scrum の全てはこの3つの柱のどれかが含まれる。

Scrum Overview

Scrum は前述の3つの柱含めて、19個のルールで構成されている。(2017/01 時点、 Scrum は常にアップデートしていく)

  • Product
    • Potentialy
    • Shippable
    • Product Increment
  • Product Owner
  • Scrum Master
  • Team (7+-2)
  • Product Backlog
  • Acceptance Criteria
  • Sprint Backlog
  • Done
  • Sprint (1-4 weeks)
  • Sprint Planning
  • Sprint Retrospective
  • Daily Scrum
  • Product Backlog Refinement
  • Sprint Review
  • Impediment List
  • Sprint Stop

Scrum Overview では下図のように表されている。
(研修でもお世話になった Odd-e 社の図を拝借)

f:id:dskst9:20170211125235p:plain

19個のルール以外は Scrum のルールではなく、 Scrum と親和性の高いプラクティスなので注意。Working Agreement もプラクティスである。

3つの柱とルールは全て相互に関係しており、下表が作れる。
ここに今までのプロジェクトで登場していた要素(結合試験、要件定義書とか)は全て下表のどれかに属すことになる。

Product Backlog Sprint Review
Transparency
Inspect
Adapt

ということは、今までのプロジェクト(WFなど)でやってきたことは、すべて Scrum ではフォローできている。
Scrum にしたからあれができなくなるなんてことはない。

まとめ

意外にルールは19個しかないんだなー。
でもでも奥が深い!

ただ概要を書いているだけだけど、まだまだ理解していないことがたくさんあると改めて。
次はセレモニーでも書くかな。

World Enable

We

最後に紹介してもらったスクラム入門資料を添えて。

追記

CSM研修を受けるか迷っている方へ

是非受けることをおすすめする。
ここでしか経験できない本当に腹落ちしたスクラムルールや、今まで味わったことのない異様な集中力で過ごす研修はかけがえないのない経験になると思う。

格安SIMを使ってみた評価(mineo)

日常

格安SIMを半年使ってみた、

結論、まだ大手キャリアを使っている人は今すぐ格安SIMに変えたほうがいい。

f:id:dskst9:20161125235106p:plain

格安SIMをすすめる理由

何よりも安い。
そして、通信は安定しているし、全く不満がない。
正直、大手キャリアを使う理由が全く見つからない。

2年縛りがある?そんなもの2ヶ月で元が取れる。
端末代金分割割引が残ってる?そんなもの10ヶ月で元が取れる。

繰り返しだが、大手キャリアと使っている人は今すぐ変えた方がいい。
私の場合、月額5,000円くらいの節約になった。

大手キャリア:6,500 ~ 7,000円/月
格安SIM:1,625円/月(電話番号を捨てれば980円とかになる)

大手キャリアはポイントを還元とか言っているが、月額5,000円の現金還元には到底勝てない。

格安SIMの選定

色々調べたが、私は mineo に落ち着いた。
正直、大手キャリアから脱却できればどこに変えてもいいと思っているが、選定するなら下記に重点を置くのがいいと思った。

  • 最新OSへの対応スピード
    格安SIMでは最新OSが出ても動作担保がすぐに取られない。
    アップデートして使えなくなったということは殆どないと思うが、動作確認は早いほうがいい。
  • 実測での通信速度と安定さ
    ググれば色々な情報がでてくる。嘘か本当かわからない情報もあるのでここでは深く言及しないが、色んな口コミを見てみたほうがいい。
  • すぐに辞めても違約金取られない
  • 挑戦をしている
    競争の激しい格安SIM業界で生き残るために、本当に価値あるサービスを、チャレンジをしている会社がいいだろう。
    フットワークが軽いほうが競争に追従していくので。

mineo に決めた理由

  • ユーザー掲示板で最新OSでの動作確認結果がすぐに投稿される
    この掲示板非常に便利で、ちょっと困ったことは検索すると大抵のことは解決する。
  • au回線、docomo回線が選択できる
  • (当初)050 の電話番号が無料で使えた
    2017年から月額とられるが、無料050を使えたのはでかい。050がいらなければお金はかからない。
  • フリータンクという無料パケットが便利すぎる
    フリータンクという場所に余ったパケットを入れることができ、引き出すことができる。
    それを全mineoユーザーで共有しているので、実質1GBが毎月無料で使うことも可能。ちょっと今月足りないってときは重宝する。
  • なんか色々やっている&やろうとしている
    前述のフリータンクなどチャレンジをしている、その姿勢が素敵!

私は au系 iPhone 6S、妻が auiPhone 5S で使っているが、問題なく使用可能。
妻は変更した当初、なぜか圏外なることがあったが、掲示板に載っていたおまじないをしたら治った。
iPhone 5S はどの格安SIMでも不安定らしいが、おまじないの後は約半年問題なく使えている。

mineo を使いたい人は、下記で申し込むとAmazonギフト券1000円がもらえるのでどうぞ。私ももらえる(・∀・)
mineo.jp

さいごに

格安SIMは全く問題なく、安く使えてますよ!というのを伝えたかったので、急に格安SIMの記事を書いてみた。
まだ大手キャリアを使っている人がいっぱいいるので、そんな人が格安SIMに乗り換えるきっかけになればいいなと。