Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
マイクロサービス宣言から8年 振り返りとこれから / Eight Years After th...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Eisuke Oishi
January 24, 2023
Technology
2k
3
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
マイクロサービス宣言から8年 振り返りとこれから / Eight Years After the Microservices Declaration A Look Back and A Look Ahead
2023/1/24 ディップ×Cookpad×SmartHR「開発現場のリアルを話す会」
Eisuke Oishi
January 24, 2023
More Decks by Eisuke Oishi
See All by Eisuke Oishi
レシピサービスにおける持続的な プロダクト開発プロセスについて / Sustainable Product Development Process in Cookpad
eisuke
0
3.6k
20191127_financier.pdf
eisuke
3
4.6k
kuroko2の近況とクックパッドのバッチ周りの概況
eisuke
4
12k
クックパッドの管理アプリケーションの近況報告
eisuke
1
460
Other Decks in Technology
See All in Technology
Slack上でインフラをトラブルシュートする! Agentic Platform Engineeringの第一歩
teru0x1
5
1.8k
EventBridge に「合流」はない ― サーバーレスのワークフローを育てるということ / No Join in EventBridge
yusukeshimizu
2
140
AI 時代のスタートアップエコシステ厶から考究する技術的負債との向き合い方
m3m0r7
PRO
3
2.2k
目の前の楽しいが人生を変える - コミュニティの螺旋の歩き方と楽しむコツ / change your life
soudai
PRO
5
640
What the customer really needed
kawaguti
PRO
3
210
AIに任せた品質は、誰が見立てるのか - AI時代のテストマネジメント
nakanao
3
2.1k
空間オーディオで過去の 自分(ゴースト)と競うランニング 〜HealthKitのルートを足音に変える実装〜
nao_randd
0
230
え、こんなに早く改修できるの?──新人エンジニアとスクラムマスターの2人が語る、AI×アジャイル開発の現場
ysasago
2
430
SREへの勘違いに気づいた後の話
tomodakengo
0
110
アプリをもっと"iOSアプリっぽく"する小さな工夫 / Small Touches That Make Your App Feel More Like an iOS App
matsuji
2
950
2026-09-11 【Snowflake World Tour Tokyo 2026】Snowflakeを起点に、AI Agentが自律稼働し続ける未来へ / Driving AI Agents with Snowflake
civitaspo
0
700
Azure Serverless 2026:Production-ready な AI エージェント基盤 / Azure Serverless 2026: Production-Ready AI Agent Platform
miyake
2
210
Featured
See All Featured
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
1k
Bootstrapping a Software Product
garrettdimon
PRO
306
120k
Google's AI Overviews - The New Search
badams
0
1.6k
Navigating Team Friction
lara
192
16k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
SEOcharity - Dark patterns in SEO and UX: How to avoid them and build a more ethical web
sarafernandez
0
280
Rails Girls Zürich Keynote
gr2m
96
14k
Code Review Best Practice
trishagee
74
20k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
700
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.9k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
330
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
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
ご清聴ありがとうございました