2023/1/24 ディップ×Cookpad×SmartHR「開発現場のリアルを話す会」
マイクロサービス宣言から8年振り返りとこれから2023/1/24 ディップ×Cookpad×SmartHR「開発現場のリアルを話す会」クックパッド株式会社 レシピサービス開発部大石英介
View Slide
自己紹介2014年にクックパッドに入社クックパッドの決済基盤やユーザー基盤の開発・運用を担当する。ユーザー・決済基盤部長、技術部長を経て2022年よりレシピサービス開発部 副部長を務め、cookpad.com の技術領域全体のマネジメントを担当。
クックパッドについて
今日話すことクックパッドは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
ご清聴ありがとうございました
eisuke
tsujiba
gawa
yukihiromori
motsuhiro131
miyakemito
murahigeas
prashantspol
mochico
n1ru4l
shotatsuge
oracle4engineer
picardparis
lara
zenorocha
chrisshort
jeffersonlam
holman
brianwarren
lauravandoore
paulrobertlloyd
addyosmani
keithpitt
bryan