Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
マイクロサービス宣言から8年 振り返りとこれから / Eight Years After th...
Search
Eisuke Oishi
January 24, 2023
Technology
3
1.4k
マイクロサービス宣言から8年 振り返りとこれから / Eight Years After the Microservices Declaration A Look Back and A Look Ahead
2023/1/24 ディップ×Cookpad×SmartHR「開発現場のリアルを話す会」
Eisuke Oishi
January 24, 2023
Tweet
Share
More Decks by Eisuke Oishi
See All by Eisuke Oishi
レシピサービスにおける持続的な プロダクト開発プロセスについて / Sustainable Product Development Process in Cookpad
eisuke
0
3.1k
20191127_financier.pdf
eisuke
3
4.3k
kuroko2の近況とクックパッドのバッチ周りの概況
eisuke
4
11k
クックパッドの管理アプリケーションの近況報告
eisuke
1
360
Other Decks in Technology
See All in Technology
Automated Promptingを目指すその前に / Before we can aim for Automated Prompting
rkaga
0
110
事業者間調整の行間を読む 調整の具体事例
sugiim
0
1.5k
君は隠しイベントを見つけれるか?
mujyun
0
290
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
9
120k
物価高なラスベガスでの過ごし方
zakky
0
380
プロダクトチームへのSystem Risk Records導入・運用事例の紹介/Introduction and Case Studies on Implementing and Operating System Risk Records for Product Teams
taddy_919
1
170
小規模に始めるデータメッシュとデータガバナンスの実践
kimujun
3
590
よくわからんサービスについての問い合わせが来たときの強い味方 Amazon Q について
kazzpapa3
0
220
AWSコンテナ本出版から3年経った今、もし改めて執筆し直すなら / If I revise our container book
iselegant
15
4k
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
180
Java x Spring Boot Warm up
kazu_kichi_67
2
490
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
kakehashi
1
150
Featured
See All Featured
A designer walks into a library…
pauljervisheath
202
24k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
664
120k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
Building Adaptive Systems
keathley
38
2.2k
A Modern Web Designer's Workflow
chriscoyier
692
190k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
The Language of Interfaces
destraynor
154
24k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
What's in a price? How to price your products and services
michaelherold
243
12k
Writing Fast Ruby
sferik
626
61k
Transcript
マイクロサービス宣言から8年 振り返りとこれから 2023/1/24 ディップ×Cookpad×SmartHR「開発現場のリアルを話す会」 クックパッド株式会社 レシピサービス開発部 大石英介
自己紹介 2014年にクックパッドに入社 クックパッドの決済基盤やユーザー基盤の開 発・運用を担当する。ユーザー・決済基盤部 長、技術部長を経て2022年よりレシピサービ ス開発部 副部長を務め、cookpad.com の技 術領域全体のマネジメントを担当。
クックパッドについて
None
None
None
None
今日話すこと クックパッドは2014年頃からマイクロサービスへの取り組みを行ってきました。 果たしてその技術選択は正しかったのかということについて、技術的・組織的なふり かえり、そして今後の取り組みについて話します。 一般化することはまだ経験が足りていないので、あくまでもクックパッドにおける事例 としてお聞きください。
原典である James Lewis/Martin Fowler の"Microservices" でも確信はない言及がある これらの肯定的な経験にも関わらず、私たちはマイクロサービスこそがソフトウェアアーキテクチャの未来の方向性であるということに確 信をもって議論しているわけではありません。現在の私たちの経験からいってモノリシックアプリケーションに比べて好ましいですが、自 信を持って完全に判定を下すには時間がまだ経過していません。 しばしばアーキテクチャ決定の本当の結果は、構築してから数年経った後に実証されるものです。モジュール化の強い欲求がある良い
チームが、年を経て衰退するモノリシックアーキテクチャを構築した複数のプロジェクトを見てきました。多くの人々が、サービス境界が明 確であり、そこかしこにつぎはぎするのが難しいため、そのような衰退はマイクロサービスにより少なくなるのではないかと考えていま す。しかし十分な時を経た十分な数のシステムをまだ見ていないので、私たちはどうマイクロサービスアーキテクチャが成熟するか本当 に判断することはできません 。 原文: https://martinfowler.com/articles/microservices.html (2014) 訳: https://kimitok.hateblo.jp/entry/2014/11/09/211820
マイクロサービスの戦略から得たもの
開発環境の進化が加速した • Docker運用、インフラ・環境の構築、デプロイ環境の自動化 • 分散トレーシング、サービスメッシュ、エラー監視 • 自動で構築されるログ、モニタリング環境 • コスト監視 •
継続的インテーグレーション、 CI環境の改善 • 分散データ管理の知見 ◦ 結果整合性 ◦ メッセージングシステム • 障害設計、レジリエンシー、SLI/SLO • 境界について強制的に意識せざるを得ないことによる強い設計の知見 • 参考: ◦ Cookpad Tech Kitchen #20 クックパッドのマイクロサービスプラットフォーム現状 ◦ Web アプリケーションを把握するためのコンソール ◦ Cookpad Lounge #4 クックパッド SRE座談会
組織への良い影響 • クロスファンクショナルなチーム運営がスタンダードに ◦ エンジニア (iOS, Android, バックエンド)、デザイナ、プロダクトマネージャーが一つのチームでプ ロダクト開発を行う組織 •
セルフサービス: 運用も開発部門に移譲される文化、責任と自由 • 逆コンウェイ戦略を用いた成功例 ◦ payment, authz/authn サービス • 既存の技術基盤を利用した新規サービスの立ち上げやすさ ◦ Cookpad Mart、その他新規サービス
マイクロサービスの戦略の中での失敗
技術負債をマイクロサービスで解決しようとした こと • クソデカモノリスシステムをリソース単位や機能単位で分割しようとした • コードはきれいになり、ちゃんとしているように見えるが運用・開発コストが上が る ◦ 機能開発の観点においてなぜ別サービスになっているかの理由が薄い ◦
運用するチーム、機能開発の視点が欠けていた • 基本的にはこの観点でサービスを分けることはやらないほうがいい • やるとしても分割の粒度を慎重に設計する必要がある • 運用コスト・開発コストのことを考慮するべき ◦ 運用コストは確実にあがる (当たり前だけど考慮できないバイアスがある ) ◦ モジュール分割と同等に扱うべきではない
アーキテクトの重要性の認識がずれてしまった こと • アーキテクチャ設計における難易度があがる ◦ アーキテクトに求められるスキルが高くなる ◦ アーキテクチャだけを設計するのではく、その後の運用や開発体制についても考慮する必要があったが考 慮できないことが多かった ◦
プロジェクトベースの開発が発生し、そこでマイクロサービスの戦略をとって失敗 • とりあえず分ける、脳死マイクロサービスをやってしまった ◦ とりあえず分ける => 開発が大変すぎてやめる or そのままになってあとで運用が大変になる • 粒度の細かいサービスは基本的にアンチパターン • 結果として、一つの機能を開発するために複数のサービスを触らなければいけないこと がよく発生した ◦ コンテキストスイッチが多く開発効率はよくない
組織構造・ビジネス遂行組織が変わることへの 考慮・対応ができなかった • 組織の構造はそのときのスナップショットでしかない • コンウェイの法則との戦い => システムとは一致しないことが突如起こる ◦ 大規模組織改編
◦ 課題ベースでチームが組まれることがある ◦ 例: 3年前に大規模サービスコンセプトチェンジが起き、結果的に大量のマイクロサービスが一 つのチームに集約されてしまった ▪ 運用負荷が大変なことになった • 組織が無くなったときの対応 ◦ 既存システムの撤収・整理ができていなかった
クックパッドにおけるマイクロサービスに対 する今後のスタンス
マイクロサービスは用法用量を守って正しく使う • 得たものはかなりあった。そして失敗によって我々は賢くなれた ◦ マイクロサービスの文脈に限ったものではなく、「良い開発環境とは」ということに目を向けることができた ◦ 選択肢として捨てたわけではないが慎重に検討するべき ◦ 基本的には大きな粒度で分割、あるいは新規サービスや共通に利用される基盤システムにおいて有用性 がある
◦ そのときの組織構造だけにとらわれずにコアドメインを見分ける • 技術面だけではなく、組織・運用が考慮できる体制が必要 ◦ アーキテクチャ設計は組織やプロダクトにおいてかなり重要なことである認識をする ◦ ただ分ける、だけではなにも良いことがなかった ◦ 事業責任者と一緒にアーキテクチャを設計する、アーキテクトがプロダクト開発全体を考えることができる のが理想
これからの戦略
システムを統合・リアーキテクトしていく • 分かれすぎたサービスを組織ではなくプロダクトのコアドメインに従ってサービスを集約する ◦ cookpad_all というクソデカモノリスを繰り返さない方法の模索 • 具体的なリアーキテクトの一部については先日の Cookpad TechConf
にて発表 ◦ 「 巨大なレシピサービスのアーキテクチャを最高にしたい」 ◦ プラットフォーム (iOS, Android, Web Frontend) で共通で利用する単一のゲートウェイ層を導入しようとしている ◦ プラットフォームごとに層を作ることが教科書どうりだがこれも開発コストが高いためこういったアプローチを選択 ◦ このゲートウェイ層を起点にバックエンドの集約・リアーキテクトを進めていく • 機能開発と共存しながら、機能開発を行うエンジニアの開発スピード、運用コストを下げることが目的 ◦ リアーキテクトが目的ではない • アーキテクチャについての戦略・理解を浸透させていく • 次のクックパッドの開発環境・戦略を描いていく
組織と技術を乖離させない • 持続的に開発できる状況を組織として維持する責任を持つ ◦ エンジニアはプロダクトやサービスに関することに最大限の関心を持ち影響していく ▪ 元々クックパッドはそういった文化 ▪ アーキテクチャに限ったことではない ◦
組織やプロダクト開発方法についてデメリットがあるなら率直に責任者にフィードバックする ◦ 技術戦略はプロダクト開発におけるエンジン • 機能開発と運用、開発環境の整備が乖離しないようにする ◦ 例: スクラム導入 ▪ プロダクトバックログアイテムにリアーキテクト、開発持続性に関することと機能開発が共存 ◦ 詳細は CookpadTech で発表しました
最後に • クックパッドはサービスとして成熟したわけでも、運用フェーズでも全然ない ◦ 多くの人に使ってもらっているが保守的ではない。「毎日の料理を楽しみにする」ために常に新しいことを やり続けている ▪ 非常にチャレンジングなこと。すごく面白い ▪ 多くの人にすでに貢献しているプロダクトをアップデートをしていく難しさと楽しさ
▪ 様々な能力、姿勢をもった仲間がいる • 駆け足で振り返ったので、いまの開発体制や技術基盤について気になる点があれば遠 慮なくお声がけください • 一緒にやっていく人募集しています ◦ https://cookpad.careers/ ◦ https://speakerdeck.com/cookpadhr/cookpad-recipe-service-developers
ご清聴ありがとうございました