東京大学 メディアコンテンツ特別講義I
サービス開発速度に着目したソフトウェアアーキテクチャ成田 一生 クックパッド株式会社 執行役 CTO2018/06/15ϝσΟΞίϯςϯπಛผߨٛ*
View Slide
ాҰੜ ͳΔ͍͍ͨͬͤ!NJSBLVJΫοΫύουגࣜձࣾࣥߦ$50ੜ·ΕѪݝग़
4/4ࡱӨ˞ൃදࢿྉࣄޙެ։͠·͢γϟολʔԻ✔✔✗͝Μ ✔
今日話すこと• サービスを素早く開発し、 長く運用するということ• サービスや組織の成長に合わせて どのような技術投資をしてきたか
毎日の料理を楽しみにするMake everyday cooking fun !Since 1997
ྉཧϨγϐߘɾݕࡧαʔϏε
શੈք ݄ؒར༻ऀઍສ༗ྉձһສਓҎ্˞݄࣌!"#! શੈքສϨγϐ
会員事業 広告事業Revenue sources（ユーザー向け：月額280円） （クライアント向け）˞੫ൈ͖
100ヶ国でNo.1を目指して
英語
インドネシア語
スペイン語
アラビア語
食文化の数=言語の数？
スペイン語が公用語25%以上の割合で話されている10 - 20%の割合で話されている5 - 9.9%の割合で話されているスペイン
食文化の数≠言語の数• 国や地域が異なれば 気候 / 食材 / 味の好み / 信仰 などが異なる
23言語 / 68か国対応※2018年6月時点
歴史
%$
ΤϯδχΞͷมભ############################## ########## #################### ########## #################### ########## #################### ਓ ਓ͘Β͍ ਓ͘Β͍
JapanIndonesiaLebanonHungarySpainUSCookpad Developers are in:UKTaiwanand more…GreeceIndiaRussia݄࣌
ೖࣾ࣌ɺΤϯδχΞਓఔ
μΠχϯάςʔϒϧͰશһू·ΕΔ
ࠓਓఔ ʢܙൺणΦϑΟεʣ
શһͷ੮ͳ͍
શੈքઍສϢʔβ݄
組織・サービスの成長と技術の関係？
「開発しやすさ」への投資
初期から 「素早い開発サイクル」を 経営レベルで重視していた→なぜ？
サービス開発は 難しい
サービス開発はとにかく難しい
サービス開発の難しさゴールが分からないϢʔβͷཉٻຊਓΛؚΊͯ୭ʹΘ͔Βͳ͍Ϣʔβͷཉٻ࣌ؒͱͱʹมΘ͍ͬͯ͘今いる場所がわからない։ൃऀࣗͷαʔϏεΛਖ਼͘͠ཧղͰ͖ͳ͍
ΰʔϧ͕نఆͰ͖Δઃܭΰʔϧ͕نఆͰ͖ͳ͍αʔϏε։ൃ
MeasureLearnproductideadataBuild仮説から プロダクトにプロダクト からデータにデータから仮説にBML ループ
サービス開発の必殺技は無いけど、 学びのサイクルを仕組みにすることは できる→いかに高速に失敗できるか
技術選定
サービス開発と技術選定(1)早く作って早くリリースできること実際のユーザに当てない事には、仮説の価値は分からない
サービス開発と技術選定(2)コードの寿命が長い作って終わりではなく、長い改善の道環境の変化への追従（技術、人）技術的負債になりにくくするには？
サービス開発と技術選定(3)組織・事業継続性来年もその技術って存在するの？エンジニアに嫌われる技術を選ぶことの意味
サービス開発に必要な技術速く書けて、みんなが読めて、 長期間のメンテがしやすい言語/フレームワーク
そんなのあるのか
Ruby on Railsはギリギリそう
Rails?当時は事例も少なく、 そこまで流行っているわけではなかったが…記述量が少なく、可読性が高い アジャイル開発に向いているとされていた現在ではコミュニティが成熟し、定番に
「レールに乗る」
IUUQTCBTFDBNQDPN
IUUQTTQFBLFSEFDLDPNB@NBUTVEBUIFSFDJQFGPSUIFXPSMETMBSHFTUSBJMTNPOPMJUI
恒例の rake stats ൛+----------------------+-------+-------+---------+---------+-----+-------+| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |+----------------------+-------+-------+---------+---------+-----+-------+| Controllers | 32806 | 26480 | 311 | 2746 | 8 | 7 || Helpers | 13384 | 10888 | 17 | 1234 | 72 | 6 || Models | 74920 | 59022 | 1303 | 6642 | 5 | 6 || Mailers | 1727 | 1389 | 40 | 170 | 4 | 6 || Workers | 0 | 0 | 0 | 0 | 0 | 0 || Chanko units | 6401 | 5333 | 2 | 160 | 80 | 31 || Libraries | 33764 | 28140 | 381 | 2463 | 6 | 9 || Feature specs | 44276 | 35545 | 0 | 177 | 0 | 198 || Request specs | 781 | 615 | 0 | 0 | 0 | 0 || Routing specs | 406 | 328 | 0 | 0 | 0 | 0 || Controller specs | 49339 | 40751 | 6 | 77 | 12 | 527 || Helper specs | 4152 | 3431 | 0 | 9 | 0 | 379 || Model specs | 65320 | 53596 | 2 | 55 | 27 | 972 || Worker specs | 0 | 0 | 0 | 0 | 0 | 0 || Chanko unit specs | 3012 | 2400 | 0 | 1 | 0 | 2398 || Library specs | 16327 | 13544 | 17 | 78 | 4 | 171 |+----------------------+-------+-------+---------+---------+-----+-------+| Total |346615 |281462 | 2079 | 13812 | 6 | 18 |+----------------------+-------+-------+---------+---------+-----+-------+Code LOC: 131252 Test LOC: 150210 Code to Test Ratio: 1:1.1
1,300 models
でかいと何が起こるのか起動に時間がかかるテストに時間がかかる静的解析系ツールが動かないライブラリが動かないデプロイが大変レールに乗れない
コードや環境の老朽化
ͳͥਓ全部書き直しͨ͘ͳΔͷ͔
2010頃全リニューアル計画
リニューアル計画 (2010)• エンジニア15人くらい• コードが巨大・複雑すぎて、新機能の実装が困難• そもそも今のサービスはこれでいいのだろうか？• コードもサービスも理想的な状態にした、 俺たちの考えた最高のクックパッドにしようw Α͠ϑϧεΫϥονͰॻͧ͘
リニューアル大失敗
何が起こったのか「サービスのコアバリューを抽出する」「綺麗なコードでイチから書き直す」の両方を同時にやろうとしたˠ͍ͭ·Ͱܦ࣮͕ͬͯऴΘΒͳ͍
仕様の整理とリファクタリングを同時にやらない方がいいֶͼ
手遅れになってからやらないֶͼ
2007年の Rails 移行は なぜうまくいったのかエンジニア5人Rails に詳しい社員 0人それほど日本で流行ってない
当時の関係者の証言• サービスの機能がまだ少なかった• すでにぼろぼろだったから、 それ以上失敗しようがなかった• そもそもそんなに成功していなかった‣ （移行はしたが、当初かなり不安定だった）• 若かった
ではどうすればいいのか
本当に欲しいものは 何だったのか？
なぜ書き直したかったのか• サービスの継続的な改善がしたかった‣ 謎の複雑なレガシーコードが多すぎて 機能の改善や追加が困難
ϨΨγʔίʔυΛ શ෦ॻ͖͞ͳͯ͘ ։ൃΛམͱͣ͞ ܧଓతͳվળ͕Ͱ͖ΔΑ͏ʹ͢Ε͍͍ͷͰ
ϦχϡʔΞϧࣦഊ͕ੜΈग़ͨ͠Chanko
Chanko本番環境でのトライ&エラーを 支援する Rails 用 gemUnit という単位で既存コードへのパッチを記述IUUQTHJUIVCDPNDPPLQBEDIBOLP
৽σβΠϯ
既存コードの書き換え• レガシーコードをいじるリスク• 雑に書くと予期しないエラーになる場合があるかも• 新デザインを気軽に検証したいだけなのに！
" #既存のコード A を、スタッフユーザのみに対してベータ版のコード B に置き換えたいただし、B は冒険的な実装なので、例外が発生するかもしれない既存の Controller のコード ベータ版のコード
ελοϑͳΒ##Ͱྫ֎͕ى͖ͨΒ"ελοϑҎ֎ͳΒ"ϑϥάͰذ͍ͤͯ͘͞ͱίʔυ͕ԚΕ͍ͯ͘
ベータ機能の Unit既存の Controller のコード"#Chanko では、Unit というファイルにベータ機能のロジックを記述するinvoke 条件を満たした場合に、既存ロジック (A) の代わりに Unit (B) が実行されるB が例外を起こした場合は、元の A が実行されるため、ユーザにはエラーが返らないJOWPLF݅
無事に価値が認められたら本番の品質のコードに仕上げる既存コードを書き換え、Unit ファイルを消す （通称 Un-chanko）
Chanko• 既存のコードをほぼ汚さずに機能の置き換え実験ができる（Chanko Unit）• もし Unit 内で例外が起きたら、既存のコードが実行される• Chanko Unit は汚く書いてもいいけど、Un-chanko 時にはリファクタリングしようね、という運用
MeasureLearnproductideadataBuildプロダクト からデータにデータから仮説にBML ループ仮説から プロダクトに
Chanko で実現したこと• 本番環境をステージングのように 使えるようになった• 本物のデータ、本物のユーザ• 「スタッフ限定」「10%限定」で サービスの価値検証
すばやく開発しつつすぐに本番で検証しかもコードは汚れにくい（消しやすい）
コード品質
コード品質はビジネスに影響するか？
クックパッドの答え:YES
コードの品質• 可読性• メンテナンス性• バグの有無• セキュリティ
コードの品質が影響するもの• 開発効率• 属人性w ίʔυͷण໋
どこまでやるべきか？やりすぎない「綺麗なコード」を書くこと自体が目的ではない事業フェーズにとって必要な品質までを目指す
コードレビュー質の高いコードレビューがコード品質をある程度担保する負の遺産を残しにくくなる
コードレビューアンチパターン• 些細な文法の好みで揉める‣ インデント、括弧など‣ とにかく不毛
コード規約があるとコードレビューの効率が良くなるֶͼ
IUUQTHJUIVCDPNDPPLQBETUZMFHVJEF
特徴そんなんどっちでもいいだろというのも結構決めてる
3年くらい運用してみて• 最初は反対意見も多かった（僕も）• ビジネスのコードレビューなのに文法のしょうもない論争が展開される、 みたいなのを見かけなくなった‣ 文法の論争はスタイルガイドの方で やればよい• あってよかったスタイルガイド
J04"OESPJEͰࣗಈίʔυϨϏϡʔCPU %BOHFSΛར༻IUUQEBOHFSTZTUFNT
自動レビューbot• コーディングスタイルの Lint• 静的解析によるバグ検知• OSSライセンス情報のチェック• アプリのビルド• deploygate 等への配信
˞݄࣌ࠓिͷϨϏϡʔίϝϯτࠓिͷ13
コードレビューの 生産性は 開発効率において 死活問題
効率よく開発しつつメンテナンス性を保てるようにするための工夫
マイクロサービス
「モノリシック」な サービス
サービス分割のイメージAPI
API認証ユーザ基盤
API認証ユーザ基盤決済
API認証ユーザ基盤決済動画基盤レシピデータ
API認証ユーザ基盤決済動画基盤レシピデータWeb
マイクロサービス# #決済動画基盤Web## # ##αʔϏεΛҙຯͷ͋Δ୯ҐͰׂ͢Δ͜ͱͰҰͭҰͭখ͘͞ɺ։ൃ͘͢͠ͳΔ
メリット• 小さなアプリケーションとして 開発できる• メンテナンスしやすい• 責任感が持ちやすい• 組織のスケーラビリティ
デメリット• 結合テストが困難• システム全体が爆発的に複雑に‣ 障害の伝播問題‣ 管理の困難さ‣ 監視、可視化
世の中の流れはマイクロサービスへ• Docker を中心としたエコシステムが急速に発達• 技術的な「定石」ができつつある
サービスメッシュ• マイクロサービス同士を 適切に連携させて、 うまく制御する技術
&$4UBTLLTQPEサービスAサービスB サービスCαʔϏε͝ͱʹϓϩτίϧΛ࣮͢Δඞཁ͕͋ͬͨίϯςφ
αΠυΧʔͱͯ͠ಈ࡞ͤ͞Δɺ ϚΠΫϩαʔϏε͚ϓϩΩγ
&OWPZͰαʔϏεؒͷ௨৴ΛநԽɾαʔΩοτϒϨʔΧʔɾϩΪϯάɺࢹͷڞ௨ԽサービスAサービスB サービスC
1SPNFUIFVTQSPNWJ[ʹΑΔαʔϏεؒ௨৴ͷՄࢹԽʢ࣌ؒʹ༨༟͕͋ΕσϞʣ
進捗
rake stats+----------------------+-------+-------+---------+---------+-----+-------+| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |+----------------------+-------+-------+---------+---------+-----+-------+| Controllers | 53487 | 43106 | 578 | 4326 | 7 | 7 || Helpers | 16467 | 13482 | 19 | 1544 | 81 | 6 || Models |109238 | 86118 | 1938 | 9700 | 5 | 6 || Mailers | 2259 | 1821 | 47 | 209 | 4 | 6 || Workers | 797 | 678 | 23 | 38 | 1 | 15 || Chanko units | 12737 | 10967 | 20 | 373 | 18 | 27 || Libraries | 52295 | 43235 | 649 | 3954 | 6 | 8 || Feature specs | 56569 | 45583 | 0 | 192 | 0 | 235 || Request specs | 46276 | 39906 | 0 | 18 | 0 | 2215 || Routing specs | 614 | 495 | 0 | 0 | 0 | 0 || Controller specs | 64188 | 53000 | 6 | 128 | 21 | 412 || Helper specs | 84918 | 70300 | 3 | 71 | 23 | 988 || Model specs |163524 |135337 | 5 | 130 | 26 | 1039 || Worker specs | 1156 | 959 | 0 | 1 | 0 | 957 || Chanko unit specs | 9214 | 7596 | 0 | 11 | 0 | 688 || Library specs | 26054 | 21809 | 25 | 125 | 5 | 172 |+----------------------+-------+-------+---------+---------+-----+-------+| Total |699793 |574392 | 3313 | 20820 | 6 | 25 |+----------------------+-------+-------+---------+---------+-----+-------+Code LOC: 199407 Test LOC: 374985 Code to Test Ratio: 1:1.9
rake stats+----------------------+-------+-------+---------+---------+-----+-------+| Name | Lines | LOC | Classes | Methods | M/C | LOC/M |+----------------------+-------+-------+---------+---------+-----+-------+| Controllers | 32806 | 26480 | 311 | 2746 | 8 | 7 || Helpers | 13384 | 10888 | 17 | 1234 | 72 | 6 || Models | 74920 | 59022 | 1303 | 6642 | 5 | 6 || Mailers | 1727 | 1389 | 40 | 170 | 4 | 6 || Workers | 0 | 0 | 0 | 0 | 0 | 0 || Chanko units | 6401 | 5333 | 2 | 160 | 80 | 31 || Libraries | 33764 | 28140 | 381 | 2463 | 6 | 9 || Feature specs | 44276 | 35545 | 0 | 177 | 0 | 198 || Request specs | 781 | 615 | 0 | 0 | 0 | 0 || Routing specs | 406 | 328 | 0 | 0 | 0 | 0 || Controller specs | 49339 | 40751 | 6 | 77 | 12 | 527 || Helper specs | 4152 | 3431 | 0 | 9 | 0 | 379 || Model specs | 65320 | 53596 | 2 | 55 | 27 | 972 || Worker specs | 0 | 0 | 0 | 0 | 0 | 0 || Chanko unit specs | 3012 | 2400 | 0 | 1 | 0 | 2398 || Library specs | 16327 | 13544 | 17 | 78 | 4 | 171 |+----------------------+-------+-------+---------+---------+-----+-------+| Total |346615 |281462 | 2079 | 13812 | 6 | 18 |+----------------------+-------+-------+---------+---------+-----+-------+Code LOC: 131252 Test LOC: 150210 Code to Test Ratio: 1:1.1
NPEFMT NPEFMT
分割方針• 開発が活発な部分を切り出す• サービスとして再利用性が高い部分を切り出す• チームの境界で切り出す• 完璧より実利を目指す
おわりに
おわりに (1/5)• 開発効率への技術的投資を クックパッドは 組織的・戦略的に行ってきた• （ただし失敗もある）
おわりに (2/5)• クックパッドは「毎日の料理を楽しみにする」サービス開発の会社• サービス開発はめちゃくちゃ難しい• 最高の道具を使ってやっと 打席に立てる程度
おわりに (3/5)• サービスに「完成」はなく、 事業が続く限り ずっと開発し続けるものである‣ BML ループ• そのために必要なことはなにか？
おわりに (4/5)• サービス開発の技術選定で大事な要素‣ 早く作って、早くリリースできる‣ 捨てやすい‣ スケーラビリティ （組織、トラフィック）͓ΘΓ
おわりに (5/5)• マイクロサービス？‣ 組織のスケーラビリティのために やむを得ない選択‣ 世の中のインフラがマイクロサービス 前提になりつつあり、いいタイミング͓ΘΓ
IUUQTUFDIMJGFDPPLQBEDPN
ԠืకΊΓΫοΫύουɹΠϯλʔϯ
mirakui
comucal
hygradme
aki_iinuma
shibuiwilliam
kenchan
orgachem
kgsi
kojira
h1kita
fedepaol
sat
yoshidashingo
jmmastey
philhawksworth
mraible
skipperchong
brianwarren
zenorocha
lara
palkan
addyosmani
quramy
trallard
geeforr