楽天ラクマの組織とシステムをマイクロサービス化しようとした話
•Als PPTX, PDF herunterladen•
0 gefällt mir•81 views
現「ラクマ」が2012年にサービスインした「フリル」が「ラクマ」として2016年に楽天サービスの仲間入りをし、組織は急拡大しましたが2022年に至るまでシステムは一度もリアーキテクチャが行われていませんでした。 本体の機能に加えて、マーケティングツール、カスタマーサポート向け管理画面、出品事業者へのビジネスドメイン追加、ネットワーク広告など各分野の実装がメインの数リポジトリに継ぎ足されていき、システムの複雑化、対応スピードの低下、開発者体験の低下などの問題が徐々に顕在化してきました。 組織の拡大がサービスの成長と直結しづらくなっている状況を改善すべく、システム・組織の両面で小さく切り出すことを約1年挑戦してきた中で、組織の境界探しにフォーカスを当て、そこにチャレンジする上での難しさと乗り越える方法をお話します。
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie 楽天ラクマの組織とシステムをマイクロサービス化しようとした話
Ähnlich wie 楽天ラクマの組織とシステムをマイクロサービス化しようとした話 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
楽天ラクマの組織とシステムをマイクロサービス化しようとした話
- 1. 楽天ラクマの組織とシステムをマイクロサービス 化しようとした話 Aug 4, 2022 Hiroki Kishi EC Incubation Department > Rakuma Development Section Rakuten Group, Inc.
- 2. 2 略歴 〜2016年: ナビゲーションアプリの会社でバックエンドエンジニア • Javaエンジニアとして各種機能開発・運用保守を行う 2016年〜2018年: フリマアプリ「フリル」を運営する株式会社Fablicに入社 • Rubyエンジニアとして各種機能開発・運用保守を行う 2018年〜現在: 楽天への吸収合併に伴い現ラクマ開発課に転籍 • エンジニアリングマネージャとして各種エンジニア組織のマネジメントに 携わる • 拡大した組織に対して各種施策を立案、実施検討を行う 趣味 • マイホーム、マイカー、料理 自己紹介 岸 洋希
- 3. 3 本日のお話 2012年にベンチャー企業から「フリル」としてローンチされた現楽天ラクマは2022年現在、 ローンチ当初と比べ物にならないくらい大きく成長しました サービスの成長に合わせてシステム、組織両面でリアーキテクチャリングが必要な時期に差し 掛かっていると感じ、1年に渡りマイクロサービス化の道を探ってきました 本日は、私が組織面のリアーキテクチャを行うにあたって取り組んできたことをご紹介します （技術的な話は少し） その中で失敗したこと、そこから得られたことが少しでも皆さんのお役に立てば幸いです
- 4. 4 楽天ラクマについて
- 5. 5 楽天ラクマについて 出典: https://fril.jp 2022/08/02取得 出典: 記者発表資料より 出典: プレスリリース画像より
- 10. 10 マイクロサービス化推進体制
- 11. 11 推進体制 マネージャ 楽天ラクマを構成するドメイン構造や 組織体制の面から境界線を見つけ出す テクニカルスペシャリスト 技術的な概念検証を行い、 システムの切り出しを実現する 社外アドバイザリー
- 13. 13 参考: 技術的な分割方法の検討・PoC（Proof of Concept: 概念検証） Spotifyの提唱したモデルを参考に、最初からマイクロ サービスとして切り出さずモジュラーモノリスを経て切 り出すことを検討した • 実験しながら取り返しの付く方法 • DBまで分割すると取り返しが付きづらい 分散トランザクション、境界またぎ、マイクロサービス 間通信方法(REST, GraphQL, gRPC)など広く検討し、その 結果を1エンドポイントで検証した 出典: 社内資料より
- 14. 14 組織的な分割方法の検討
- 19. 19 たくさん売 り買いして もらいたい たくさん出品 して欲しい たくさん買っ て欲しい 個人に出品 して欲しい 業者に出品 して欲しい 的確に探し て欲しい キャンペー ンで注目を 集めたい システム1 システム2 システム3 システム4 KPIツリーで解釈する 各ノードに紐付いたシステムが独立してデプロ イできるようになると衝突が減る 開発・保守・運用効率をはじめとするDXが向 上し、システムトラブルが減りスピーディにデ リバリーが行えるようになる（理想論） ただ、システムの都合だけで分割してしまうと 引き続き衝突が発生する（とアドバイスを受けた） ので、切れ目を慎重に探すために、長期に渡っ て業務ヒアリングを行った
- 20. 20 領域選定の評価軸 Reach（範囲） • 領域の広さ・システムの大きさ • 関わるエンジニアの多さ • 関わるオペレーターの多さ • 影響を受けるユーザーの多さ Impact（効果） • 負の解消：課題の大きさと解消による効 果 • 発展性：今後の変化が大きいかの見通し Confidence（確度） • 期待効果が得られそうな期待値（逆効果 リスク） • チームメンバーのドメイン習熟度 Effort（大変さ） • 実行難易度
- 21. 21 領域選定の評価例 Reach（範囲） •領域の広さ・システムの大きさ •関わるエンジニアの多さ •関わるオペレーターの多さ •影響を受けるユーザーの多さ Impact（効果） •負の解消：課題の大きさと解消による効果 •発展性：今後の変化が大きいかの見通し Confidence（確度） •期待効果が得られそうな期待値（逆効果リ スク） •チームメンバーのドメイン習熟度 Effort（大変さ） •実行難易度 キャンペーン機能（配信） 大量の配信をスピーディに行う • 明らかに違う人が使ってるので切り離しやすい • 個別のパフォーマンスチューニングの必要がある • 切り離して言語を変えて個別にスケールするなどで きる • チームの習熟度が足りない • 突発対応が多い領域 • 領域自体が拡大 • 常にリソース難 • こぼれ球をうけとるチーム • 領域や関わるエンジニアやオペレータは多すぎる こともなく絞られている • 対象: リテンションを上げたいユーザー（多い） • インセンティブ付与のロジックが不十分だっ たり、配信したいボリュームに対するパ フォーマンスが追いついていないので、負の 解消効果は大 • 訴求の引き出しは無限にあるので発展性は大 領域としては良いが、今は始められない…
- 23. 23 反省とこれから
- 24. 24 反省とこれから ビジネス組織と対等に議論できるポジションが不在だった システム上の課題を事業課題として定量化して事業案件とのバランスを提案する土台を作れなかった また、開発組織全体をリードする存在も不在だったため、提案がポジショントークになっている可能性もあった マネジメント層がマイクロサービス化の検討にコストを割ききれなかった 広域を見渡す立場であるがゆえに、他にも多くの責任や役割を担っている これから イチからのヒアリングは効率が良くないので、まずは少数で叩きを作り、走り出しを効率化する 権限が伴った専任メンバーを付けたい
- 26. 26 まとめ
- 27. 27 まとめ • 10年間進化を続けているサービスはリアーキテクチャを施さないと、開発効率が落ちてしまう • リアーキテクチャはシステムに対してだけではなく、組織も同時に行うと良い（はず） • 事業のKPIツリーに対して、システムがきれいに紐付いている状態を目指す。 一過性で終わらず、将来に渡り継続する。 • ただし、現状=KPIツリーとシステムの複雑なひも付きを明らかにするだけでもめちゃくちゃ大変。 思いつきや片手間では無理。 • お店のメタファーやRICEフレームワークの他にも、たくさんの方法で概念化にトライしました • システム課題をビジネス課題として語ることができ、具体的なプランの策定・推進・将来に渡る維持ができ る体制が必要
- 28. 28 出典: 社外勉強会の参加レポート（社内）より One more thing… • マイクロサービス化に限らず、リアーキテクチャ・リファクタ・技 術的負債解消などのコードクリーンアップを事業計画に組み込みヘ ルシーなシステムを維持するのは開発組織の永遠の課題 • 相手に分かる語彙=説得力のある話を実現するためには、組織ミッ ションやKPI構造と、技術的・組織的なリアーキテクチャリング手法 に対して深い理解があり、それをベースとした現実的な計画を導き 出すことが必要（そういう意味では語彙だけでは無いですが） • それはつまり特定のビジネス領域に固定されず開発組織全体に向き 合って責任を持ち、ビジネス組織と調整可能なCTO的存在…？ To be continued…
- 29. ご静聴ありがとうございました
- 31. A story about an attempt to make Rakuten Rakuma's organization and its system microservices. Aug 4, 2022 Hiroki Kishi EC Incubation Department > Rakuma Development Section Rakuten Group, Inc.
- 32. 32 Biography ~2016: Backend Engineer at a navigation application company • Developed various functions and performed operation and maintenance as a Java engineer 2016-2018: Joined Fablic Co. • Developed various functions and performed operation and maintenance as a Ruby engineer 2018-present: • Transferred to the current Rakuma Development Section following the absorption merger with Rakuten, Inc. • Engaged in management of various engineering organizations as an engineering manager • Planning and implementing various measures for the expanded organization Hobbies • My home, my car, cooking About me Hiroki Kishi
- 33. 33 Today’s topics Launched in 2012 as "Fril" by a venture company, the current Rakuten Rakuma has grown so much that it is incomparable to the initial launch as of 2022! I personally felt that we were approaching a point where we needed to re-architect both the system and the organization to keep up with the growth of the service, and over the past year we have been exploring the path to microservices. Today, I would like to share with you some of the things I have been working on in the process of re- architecting the organizational aspects of the service (a little bit about the technical aspects). I hope that the mistakes we made and the things I learned from them will be useful to you!
- 35. 35 楽天ラクマについて Source: https://fril.jp As of 2022/08/02 Source: Press release Source: Press release
- 37. 37 Why we started considering microservices
- 38. 38 Mapping of systems and organizations A complex state of teams and systems from upstream to downstream of the product 出典: 社内資料より
- 39. 39 Why we started considering microservices Source: Internal document
- 41. 41 Microservice working group Managers Finding boundaries in terms of the domain structure and organizational structure that make up Rakuten Rakuma. Technical specialists Performs technical concept validation and achieve system cut-outs. Outside advisory
- 42. 42 FYI: Technical study of system microservicing
- 43. 43 FYI: Technical study of system microservicing Considering the model proposed by Spotify to not cut out as microservices from the beginning, but to cut out via modular monoliths, which is a method that can be rolled back while experimenting. If we split up to DB, it will be difficult to rolled back. We extensively studied distributed transactions, boundary straddling, communication methods between microservices (REST, GraphQL, gRPC), etc., and verified the results with a single endpoint. Source: Internal document
- 45. 45 Metaphors of shop stocker Vendor seller Individual seller Inventory Accounting Shipping Customer suppoer Information Display Sales Individual buyers Customer cultivation Maintenance of equipment Cashier
- 46. 46 System functionalities Listing functionalities Vendor seller Individual seller Item DB Search Engine Accounting functionalities Shipping Customer support Search Recommendation Display In-app campaign Individual buyers Campaign(distribution) SRE,Technology Infrastructure Payment
- 47. 47 各々にミッションがある Listing functionalities Store large numbers of products in the data store efficiently Vendor seller Individual seller Item DB Search Engine Fast search Can manage inventory for vendors Accounting Automation of manual tasks Accuracy Shipping Reduction of cumbersome packaging work Providing a variety of convenient shipping features Customer support Functionalities for staff to quickly resolve issues Development of features that step in to solve problems Search Recommendation Easy to find, precise Display A system that makes it easy for marketers to develop a variety of measures In-app campaign Individual buyers Campaign(distribution) Speedy delivery in large amounts SRE,Technology Infrastructure Stable handling of large amounts of traffic and large amounts of data, and deployment efficiency Payment Support a variety of payment methods Reduce fees to payment vendors
- 48. 48 Sell and buy a lot in Rakuma A lot of items sold A lot of items bought Sold by individuals Sold by businesses Items are found accurately Items are viewed through campaigns System1 System2 System3 Each node of the KPI tree that breaks down business goal targets has its own KPIs and system performance requirements, but when multiple teams develop on the same system, conflicts are more likely to occur, which in turn worsen DX. As a result, delivery slows down and system troubles occur frequently. Understanding in KPI tree
- 49. 49 Sell and buy a lot in Rakuma A lot of items sold A lot of items bought Sold by individuals Sold by businesses Items are found accurately Items are viewed through campaigns System1 System2 System3 System4 Understanding in KPI tree When systems are tied to each node and aredeployed independently, there should be fewer conflicts . DX, including development, maintenance, and operational efficiency, will improve, and delivery will be faster with fewer system problems (ideally). However, if we split the system only for the convenience of the system, conflicts would continue. So, we conducted interviews to their daily works over a long period in order to carefully search for a break in the system.
- 50. 50 Criteria of area selection to split out Reach • Size of area/system • Number of engineers involved • Number of operators involved • Number of users affected Impact • Debt repayment: magnitude of of issue and effect of resolution Confidence • Expected likely effect (risk of counterproductive effect) • Domain proficiency of team members Effort • Execution difficulty
- 51. 51 Example Campaign Functions(Distribution) Speedy mass distribution • Obviously different people are using it, so it's easy to disconnect. • Need separate performance tuning • Can be decoupled and scaled individuallywith different languages, etc. • Lack of team proficiency • Areas with many unexpected responses • Expansion of the area itself • Constant resource difficulties • Teams receiving spills • The domain and the engineers and operators involved are narrowed down without being too many. • Target: Users who want to increase retention (a lot) • The logic of incentivization is not sufficient or the performance is not keeping up with the volume you want to deliver, so the negative elimination effect is great • Development potential is great because there is no limit to the number of appeals that can be drawn out Good for the area choice, but difficult to start now... Reach • Size of area/system • Number of engineers involved • Number of operators involved • Number of users affected Impact • Debt repayment: magnitude of issue and effect of resolution • Developmental: Prospects for significant changes in the future Confidence • Expected likely effect (risk of counterproductive effect) • Domain proficiency of team members Effort • Execution difficulty
- 52. 52 Due to retirement* and parental leave of the promotion members, the working group could no longer continue, therefore microservicing was stopped. *This retirement was not because of this project.
- 54. 54 Retrospective and prospective Lack of a position to discuss with the business organization on an equal footing • Failed to create a foundation for quantifying system issues as business issues and proposing a balance with business projects • Also, there was no one to lead the entire development organization, so there was a possibility that proposals were positional talk. Management was not able to devote enough time and money to the consideration of microservices. • Because of their wide perspective, they have many other responsibilities and roles to play. Next action • As it is not efficient to conduct interviews from scratch, we will start with a small number of people to make the process more efficient. • We want to add a full-time member with authority.
- 56. 56 Wrap up
- 57. 57 Wrap-up • Services that have been evolving for 10 years will lose development efficiency if they are not rear-architected. • “Re-architect” is not only about the system, but also for the organization. • Aim for a state where the system is neatly connected to the KPI tree of the business. Don’t stop at only one trial. Continue for the future. • It is extremely difficult just to clarify the complicated linkage between KPI tree and the system. It cannot be done in your spare time. • We tried to conceptualize it in many ways besides the metaphors of shop and the RICE framework. • Need a role who can translate system issues into business issues and can develop, promote, and maintain specific plans for the future.
- 58. 58 One more thing… • Not only microservicing, it is an eternal challenge for development organizations to maintain a healthy system by incorporating code cleanup such as re-architecture, refactoring, and technical debt elimination into the business plan • To acquire vocabulary that others can understand = to be able to tell a convincing story, it is necessary to have a deep understanding of the organization's mission, KPI structure, and technical and organizational architectural methods, and to derive a realistic plan based on this understanding (in that sense, it is not just about vocabulary). • In other words, we need someone, who is not locked into a specific business area, but is responsible for the entire development organization, and can coordinate with the business organization. i.e. CTO…? To be continued... Source: Internal document
- 59. Thank you for listening