大規模システムリプレイスへの道
•
6 j'aime•4,853 vues
ULTRA Beer Bash「大規模システムリプレイスへの道」講演資料
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à 大規模システムリプレイスへの道
Similaire à 大規模システムリプレイスへの道 (20)
Plus de Recruit Lifestyle Co., Ltd.
Plus de Recruit Lifestyle Co., Ltd. (20)
大規模システムリプレイスへの道
- 2. 提供 2
- 4. Agenda • リクルートライフスタイルの紹介 • ホットペッパービューティーについて – 事業について – システムについて • なぜ、リプレイスを進めることにしたのか • アーキテクチャ設計と組織設計 • 苦労したこととナレッジポイント • まとめ 4
- 5. ⾃⼰紹介 ＜略歴＞ • 〜2012年 – 受託系開発会社でCS -> PG -> SE -> MGRとして勤務 • 2012年5⽉〜 – 株式会社リクルートに転職 – 新規⽴ち上げ、サービス運⽤改善に携わる • 2015年4⽉〜 – ネットビジネス本部 グループマネジャー就任 – 新規開発、スマホアプリ開発、ホットペッパービューティー開発の部署を担当 5 ⼩川 健太郎 ネットビジネス本部 ビューティー事業ユニット プロダクト開発G グループマネジャー
- 6. 今回のお話スコープ • ホットペッパービューティーというサービスに着任してからおこなってきた システムのリプレイスについてお話します • 事業、システムの紹介から始まり、どのように思考して取り組んできたか、 アーキテクチャをどういう組み合わせで⾏ってきたかということを話します • 実際のサービス開発ではシステムのリプレイス以外にも沢⼭の案件が ⾛っていて、その中でリプレイスについて取り上げるという形になります 6
- 9. RLSの事業領域
- 13. ベンチャーマインドがあるが歴史ある企業 1960 2017 ⼤学新聞広告社創業 2000 「Hot Pepper」創刊 「じゃらんNet」サービス開始 2005 「HotPepper.jp」 （現・「ホットペッパーグルメ」）サービス開始 2007 「ホットペッパービューティー」サービス開始 〜省略〜 2012 （社員エンジニア採⽤し始める） 紙の会社 WEBの会社
- 15. ホットペッパービューティーとは • 国内最⼤級のヘアサロン リラク＆ビューティーサロン検索 予約サイト 15
- 17. クライアント向けサイト17
- 18. 事業の成⻑数値 ＜2017年9⽉更新＞ 18 （美容） ヘアサロン （キレイ） リラク・ビューティーサロン 参画サロン数 34,084 32,633 スタイル・ フォトギャラリー写真数 2,404,079 845,589 ブログ投稿数 6,239,796 4,303,704 スタイリスト数 148,249 - 年間予約数 41,666,855 26,811,192 ⼝コミ投稿数 2,161,002 1,797,737
- 19. ホットペッパービューティーを⽀えるシステム • 関連システムを加えるとカオス状態 • 開発者数 150名以上 • 年間機能追加件数 650件以上 • Java6 + 独⾃FW + オンプレ環境 • 10年物のシステム • システムも体制もとにかく⼤きい 19
- 21. ビジネスと開発の成⻑速度の話 • ビジネスの成⻑がめざましく、どんどん機能追加要望がでる • いつのまにか、 品質 << 速度 という形で早くすることになる 21 早く！早く！ くぉー！！
- 24. ビジネスと開発の成⻑速度の話 • 気づいたら、もう、どうしようもない状態になっていた • このまま増加傾向になっていくのを⾒ていくしかないのか… 24 2年前 現在 2年後 N⼈⽉ 2.5倍 2.5倍のまま？ 3倍？ 4倍？ とある案件の例
- 26. ビジネスと開発の成⻑速度の話 • 右肩上がりで成⻑してきた事業 • 未来を描き、それを実現するために機能を ひたすら追加していきたい • ガンガン機能追加して伸ばしてきた⼿法 • でも、できない… 26
- 27. ビジネスと開発の成⻑速度の話 • 学習コストが異常に⾼く、⾼スキル⼈材でもすぐに活躍できない – システム規模 – アーキテクチャ構成 – 技術的、要件的負債が多い • 改善するには⾼スキル⼈材が必要だが、その⼈材が確保しづらい状態… 27 ⾼スキル⼈材 システム理解 罠を知る 特性を知る 事業特性を知る アーキが古い 活躍できるまでのリードタイムが⻑い
- 29. 現実をちゃんとみて、ひとつずつ課題をだしていく29 課題 案件 負債 ・改善⼯数とってない ・不要案件を削ってない ・改善⼯数を明⽰化 ・開発プロセス再設計 密結合 ・ロジック密結合 ・ドメイン分離などがない ・アーキテクチャ再設計 ・徐々に作り直し バッチ 依存 ・なんでもバッチ ・適切なデータフロー設計 ・キューイングなど導⼊ API 負債 ・APIらしい設計ではない ・アーキテクチャ再設計 ・作り直し インフラ ・新規ミドル導⼊しづらい ・オートスケール不可 ・交渉 ・⼀部クラウド化 打ち⼿ • 課題が循環参照している • 例：改善⼯数とってプロセス 変えつつ、密結合を解消に…など • アプリケーションに近い層から テコ⼊れすることを検討 アプリケーション ⾔語/FW ミドルウェア データベース インフラの箱
- 30. ホットペッパービューティーのサービスを⼤きく3つにわける30 最も⼤切にすること 規模 スマホアプリ 新しい価値提供 中 カスタマ機能 新しい価値提供 ⼤ クライアント機能 安定稼働させること 特⼤
- 31. リプレイスをするのか、リファクタリングとするのか31 リプレイス リファクタリング イメージ メリット デメリット 壊す → 建て直し リフォーム ・基礎部分から⼿がはいる ・技術⼊れ替えやすい ・アーキ再設計しやすい ・現状の延⻑線での対応 ・時間がかからない ※ リプレイスに⽐べて ・時間がかかる ・難易度が⾼い ・破壊的な変更しづらい
- 32. リプレイスをするのか、リファクタリングとするのか • それぞれを選択した場合に何を得ることができるか • リプレイス – ⾔語レベルまで変更する – アーキテクチャの枠組み⾃体を変える • リファクタリング – EOSL対応のみ – ユニットテストを書く⽂化つくる 32
- 33. スマホアプリとカスタマ機能はリプレイスの道に33 最も⼤切にすること 規模 対応⽅針 対応内容 スマホアプリ 新しい価値提供 中 リプレイス Swift化、Kotlin化 カスタマ機能 新しい価値提供 ⼤ リプレイス Rails化、Spring化 APIアーキテクチャへ クライアント機能 安定稼働させること 特⼤ 検討中 検討中
- 34. 事業責任者と課題認識を共有する • なぜこうなってしまっているのか、どうしていくべきなのかを伝える • 『事業成⻑のため』という⽬的はみんな⼀緒。優先度をどう考えるかだけ 34 みんなの責任や
- 36. サービスごとの対応⽅針36 最も⼤切にすること 規模 対応⽅針 対応内容 進め⽅ スマホアプリ 新しい価値提供 中 リプレイス Swift化、Kotlin化 機能追加を⽌めて、 ⼀括でリプレイスする カスタマ機能 新しい価値提供 ⼤ リプレイス Rails化、Spring化 APIアーキテクチャへ 機能追加は⽌めず優先順位など をつけて順次リプレイスする クライアント機能 安定稼働させること 特⼤ 検討中 検討中 検討中
- 37. スマホアプリのリプレイス • iOSはObjective-CからSwiftへの変更とMVCPへの移⾏ • AndroidはJavaからKotlinへの変更とCealnArchitectureへの移⾏ • それぞれフルリプレイスを実⾏ 37 Obj-C
- 38. iOSのアーキテクチャ詳細 • Swift化 • MVCPアーキテクチャ採⽤ • 分析要件などの組み込みに よる腐敗を防ぐために Presenter層を設置 38
- 39. Androidのアーキテクチャ詳細 • Kotlin化 • Clean Architecture + MVP • Activityへのコード集約を避ける • コンポーネントを分離させて ユニットテストを可能に 39
- 40. なぜ、Kolinを採⽤できたのか？ • 採⽤を決めたのは2017年3⽉ – 公式未サポート • リプレイスしたコードベースで5年以上 戦うことを想定した場合にこのタイミングで やるべきではという声があがった • 社内前例なしで⼤規模サービスへの導⼊に 慎重となる声があったが徹底したメリデメ整理 とリスクへの対策⽬処がたって採⽤に⾄る 40
- 43. API カスタマ機能のリプレイス • Java6(独⾃フレームワーク)から、Ruby(Rails) + Java8(Spring Boot)へ • APIアーキテクチャを採⽤することでフロントに近い部分だけ⾼速に 43 BFFMonolithic 独⾃FW ViewとLogicを分離
- 46. 技術選定の話 • モノリシックなサービスの⽅が性能がでてしまうケースがある • その中で、開発速度やフロントエンドとバックエンドの分離という メリットを享受するためにバランスを取った構成とした • サービスとして、『守らなければいけない数値』や『勝ち得たいもの』を 定量的に定義することで選択に踏み切ることができた – 1秒あたりのPV数、レスポンスタイムなど 46
- 47. アプリケーション層発信でインフラへのテコ⼊れも • 従来までのJava6 + 独⾃FW構成を脱却するという中で、 OSやミドルウェアも刷新することができた 47 アプリケーション ⾔語/FW ミドルウェア データベース インフラの箱 APIアーキテクチャ化 Nginx導⼊、Fluentd導⼊、Redis導⼊ など Ubuntu化、Infrastructure as Code化 Ruby(Rails) + Java8(Spring Boot)導⼊ この他に監視系システムの ⼀新もしています
- 48. 組織体制も変更 • フロントエンドからバックエンドまでワンチーム • SRE(Site Reliability Engineering)チームも新規で⽴ち上げ、 共にスクラム開発をおこなう 48 開発T インフラT Goal Goal 依頼 開発 インフラ Goal 協業 リプレイスT ワンチーム化
- 53. 仕様書がなく、正解がわからない • 要件が正しいかわからない 53 if 条件A else if 条件B else if 条件C else 条件Cって、 まだ必要なのかな… • ドキュメントは最⼩限にという 前提を⼀部壊す • 膨⼤な量に向き合うために各種の ⼯夫を検討していっている • 正攻法：企画者、開発者が作成 → クオリティは⾼いが納期とコストが問題 • QAT作成 → 企画者、開発者確認
- 54. ユニットテストがない、⼯数もとられていない • ユニットテストがなく、改修のためのテスト⼯数があがりがち 54 リファクタリング したいんだけど不安… • カバレッジルールを決めて、 ユニットテスト⼯数を積む • すぐに効果はでないもので、 ⼀時的に⽣産性は落ちるので ⽅針を上が決めることが⼤切
- 59. まとめ • システム – ⽣産性は現時点で2倍程度になっている – いままでブラックボックスだった部分が多少明るくなった – OS、⾔語、FWなどチャレンジポイントを無事達成していっている • ヒト – いいヒトが集まってきた – ⾃発的に改善活動が⽣まれるようになってきた 59
- 60. まとめ • やってよかったの？ に対しては明確にYesと⾔える • しかし、やり⽅だったり登り⽅というものは常に反省がつきまとう • 技術的負債というキーワードに逃げるのではなく、 事業に向き合い、組織/案件負債というものも含めてリプレイスすべき • 正解はひとつじゃない。サービスの数だけ 60
- 61. ⼼構えの話 • 競合、商況、世論、様々なものが不確実である • その不確実性にエンジニアリングで⽴ち向かうのがエンジニアの仕事 • “不確実性をエンジニアリングでリデザインする” ということを胸に、 取り組んでいます 61
- 62. 仲間を募集しています！！62
- 63. ご清聴ありがとうございました