開発者向けの基盤をつくる

by taichi nakashima

Slide 1

Slide 1 text

開発者向けの基盤をつくる Building A Platform for Internal Developers

Slide 2

Slide 2 text

Taichi Nakashima @deeeet / @tcnksm

Slide 3

Slide 3 text

2013年 Software Engineer at Service Development Team Tech Lead at Microservices Platform Team 2018年 Rakuten, Inc. 2017年 Software Engineer at SRE Team Mercari, Inc. 2015年 Software Engineer at Internal PaaS Team

Slide 4

Slide 4 text

https://www.amazon.co.jp/dp/4297107279 改訂2版出ます at 2019/8/1 @tenntennさんが私の章を引き継いてくれました !

Slide 5

Slide 5 text

Agenda  ● Why Microservices Platform? ● How we build Platform? (Philosophy) ● What we are building?

Slide 6

Slide 6 text

Why Microservices Platform? なぜMicroservices Platformが必要か?

Slide 7

Slide 7 text

Why Microservices Platform? Microservicesとは何か?

Slide 8

Slide 8 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Listing DB User DB Item DB Shipping DB Timeline DB Microservices Timeline Search

Slide 9

Slide 9 text

Single Purpose 1つのことに集中しておりそれをうまくやること各サービスは関連する振る舞いやデータをカプセル化していること各サービスは依存するサービスについて最小限のことを知っていること Loosely Coupling High Cohesion

Slide 10

Slide 10 text

Loose couplingを満たさないと一つのサービスの変更が他のサービスに影響を与えることになる High cohesionを満たさないと分散 Monolithになる．一つの機能の開発のために複数のサービスを変更しないといけなくなる Single purposeを満たさないとそれぞれのサービスは多くのことをやることになる．複数のMonolithが存在することになる

Slide 11

Slide 11 text

Why Microservices Platform? なぜMercariは複雑なMicroservices化をしているのか?

Slide 12

Slide 12 text

Scaling Organization 組織を再編し組織としてのアウトプットを最大化するため Solving Technical Issues 技術的な課題を解決するため

Slide 13

Slide 13 text

Scaling Organization 組織を再編し組織としてのアウトプットを最大化するため Solving Technical Issues 技術的な課題を解決するため

Slide 14

Slide 14 text

https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/

Slide 15

Slide 15 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Backend team Timeline Search

Slide 16

Slide 16 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Backend team Timeline Search

Slide 17

Slide 17 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Backend team Timeline Search

Slide 18

Slide 18 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Backend team Timeline Search 人が増えても一日にリリースできる回数に限界がきていた...

Slide 19

Slide 19 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Listing DB User DB Item DB Shipping DB Timeline DB Microservices Backend team Timeline Search

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Listing Shipping Notiﬁcation Purchase Login Search DB Monolith Review Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Backend team Timeline Search 各チームが独立してリリースを行えれば 1日にリリースできる数は飛躍的に増える = より速く機能を提供できる!

Slide 22

Slide 22 text

Scaling Organization 組織を再編し組織としてのアウトプットを最大化するため Solving Technical Issues 技術的な課題を解決するため

Slide 23

Slide 23 text

Scaling Organization 組織を再編し組織としてのアウトプットを最大化するため Solving Technical Issues 技術的な課題を解決するため

Slide 24

Slide 24 text

Listing Shipping Notiﬁcation Purchase Login Timeline Search DB Monolith Review Search

Slide 25

Slide 25 text

Listing Shipping Notiﬁcation Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだら全体が死ぬ... Review Search

Slide 26

Slide 26 text

Listing Shipping Notiﬁcation Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだら全体が死ぬ... Review Search

Slide 27

Slide 27 text

Listing Shipping Notiﬁcation Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだら全体が死ぬ... Review Search

Slide 28

Slide 28 text

Listing Shipping Notiﬁcation Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだら全体が死ぬ... Review Search Scalability １つ機能をスケールさせるために全体をスケールさせる必要がありリソースの無駄遣い

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices

Slide 33

Slide 33 text

Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一部のサービスを継続して動かせる

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一部のサービスを継続して動かせる出品はできなくても Timelineは閲覧できる

Slide 37

Slide 37 text

Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一部のサービスを継続して動かせる Flexible Scale サービスごとに独立してスケールすることができリソースを最適化できる

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Item Item Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一部のサービスを継続して動かせる Flexible Scale サービスごとに独立してスケールすることができリソースを最適化できる

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Scaling Organization 組織を再編し組織としてのアウトプットを最大化するため Solving Technical Issues 技術的な課題を解決するため

Slide 42

Slide 42 text

Why Microservices Platform? なぜMicroservices Platformが必要か?

Slide 43

Slide 43 text

https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/

Slide 44

Slide 44 text

Develop Monolith Test Deploy Operate Software Lifecycle

Slide 45

Slide 45 text

Develop Monolith Test Deploy Operate QA team SRE team Monolith Team Responsibility Backend Team

Slide 46

Slide 46 text

Service A Team QA team SRE team Develop Service A Test Deploy Operate Service B Team Develop Service B Service C Team Develop Service C Microservices Bad Team Responsibility

Slide 47

Slide 47 text

Service A Team Develop Service A Test Deploy Operate Service B Team Develop Service B Service C Team Develop Service C Test Deploy Operate Test Deploy Operate Microservices Ideal Team Responsibility

Slide 48

Slide 48 text

Service A Team Backend Engineers Frontend Engineers SREs QA Service B Team Backend Engineers QA SREs Service C Team Backend Engineers Cross Functional Teams 重要なサービスであれば Responsibilityごとに専門のRole が存在する (e.g., Embedded SRE) サービスによってはBackend Engineerのみで開発から運用までのResponsibilityを担う必要がある

Slide 49

Slide 49 text

Develop Test Deploy Operate Prepare QA environment Setup CI Run integration testing Run load testing Provision infrastructure Setup automated delivery Prepare application conﬁguration Prepare monitoring Prepare observability Prepare on-calling shift Too many things to do

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

Develop Test Deploy Operate Platform Platform Team

Slide 52

Slide 52 text

Backend Team Microservicesの開発と運用に注力する基盤やDevOpsツールの開発と運用に注力する Microservicesのデザインのレビューや移行戦略に注力する Architect Team Platform Team

Slide 53

Slide 53 text

Number of microservices + teams Number of tools Platform No Platform 各チームが自分たちで Toolsetsを作ると似たようなツールが大量に作られコスト的にも無駄になる基盤チームが専属的にツールの開発と運用を担うことでツールの乱立を抑え，基盤の改善のLeverageが効く

Slide 54

Slide 54 text

Agenda  ● Why Microservices Platform? ● How we build Platform? (Philosophy) ● What we are building?

Slide 55

Slide 55 text

How We Build Platform? どのように基盤を構築しているか ?

Slide 56

Slide 56 text

Infrastructure Developer Experience Platform Developers Customers Productivity & ﬂexibility Innovative product Team Mission

Slide 57

Slide 57 text

Productivity 生産性を向上させることで仮説検証のループを高速に回すことを可能にする Flexibility 柔軟性を提供することで新たなビジネスに対応したり新たな技術やサービスの検証や導入を可能にする

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Productivity = Output Input Product, Service, Function GMV Customer satisfactions Engineering efforts Develop time Test time Deploy time Operate time ...

Slide 60

Slide 60 text

https://itrevolution.com/book/accelerate/ Delivery lead time 企画から実際に機能やサービスをリリースするまでにかかったか? Deployment frequency どれくらいの頻度でコードをリリースしているか ? Time to restore service インシデントが発生してから普及までどれだけの時間がかかったか? Change rate fail どれくらいの頻度で変更が失敗したか ?どれくらいの頻度で Rollbackしたか?

Slide 61

Slide 61 text

Develop Test Deploy Operate Productivityの向上は高速な仮説検証のループを回すことが可能になる仮説検証を繰り返すことによって Innovationを駆動することが可能になる = Productivityの向上は Innovationを駆動する

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Flexibility = Technical choices Programing Language Frameworks Databases Runtimes Cloud Services ...

Slide 65

Slide 65 text

Junior developers Experienced developers Platform より速く機能を出すことに集中したい新たな技術やサービスの検証を進めたい

Slide 66

Slide 66 text

Productivity Innovation chance Productivityのみに注力しすぎると新たな技術やサービスの検証や導入を阻害してしまう可能性がある = Productivityに注力しすぎると Innovationの駆動は減衰する ProductivityとFlexibilityの両方を提供しバランスを取る必要がある

Slide 67

Slide 67 text

Infrastructure Developer Experience Platform Developers Customers Productivity & ﬂexibility Innovative product Team Mission

Slide 68

Slide 68 text

Agenda  ● Why Microservices Platform? ● How we build Platform? (Philosophy) ● What we are building?

Slide 69

Slide 69 text

What we are building? 何を構築しているのか ?

Slide 70

Slide 70 text

Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするためのインターフェースを提供する

Slide 71

Slide 71 text

Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするためのインターフェースを提供する

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?

Slide 74

Slide 74 text

Slide 75

Slide 75 text

https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/

Slide 76

Slide 76 text

Continuous Deliveryのプラクティスを成功させるための最も重要な要素は新しいコードを恐れなく本番に出せることである ”Continuous Delivery With Spinnaker”, chapter 7

Slide 77

Slide 77 text

Immutable Infrastructure 一度デプロイしたインスタンスやコンテナには決して手を加えず機能を追加したり修正をする場合はインスタンスやコンテナから作り直す

Slide 78

Slide 78 text

Deterministic Deployment CanaryやBlue-Greenにより安全にRolloutすることができる問題が起こったときに安全にRollBackすることができる環境間の差異を最小限にすることができる（問題の再現が容易）

Slide 79

Slide 79 text

Container vs. VM 高速なビルドと起動・ Portabilityの高さ・Utilizationの高さ

Slide 80

Slide 80 text

https://dzone.com/articles/migration-from-vms-to-containers-1

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

What is Kubernetes?

Slide 84

Slide 84 text

Human SSH！シンプル・余計なツールが必要ないが人間に依存して再現性がないしスケールしない k8s, Mesos, Nomad スケジューリングは自動化され再現性がありスケールもするが複雑で・新しいツールやトレーニングが必要になる Ansible, Chef, Puppet 理解しやすい・再現性があるがスケジューリングがマニュアルでありスケールもしない Script Orchestrator

Slide 85

Slide 85 text

etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B

Slide 86

Slide 86 text

etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative conﬁguration Container Aを3 CPUsと1G Memで 3つ起動する

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative conﬁguration Container Aを3 CPUsと1G Memで 3つ起動する Scheduling リソースの余裕のある Nodeを探して Containerを配置する Container A Container A Container A Self healing Containerが死んだときに自動で復旧する

Slide 90

Slide 90 text

Slide 91

Slide 91 text

etcd API server Scheduler Controller Manager kubelet Container A Master Node kubelet Node Container A Container A Container B Controller Kubernetesでは大量の独立した Controllerが動いておりそれぞれが Reconciliation loopを実行している．

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

Desired state Container Aを3つ動かしたい

Slide 94

Slide 94 text

Desired state Container Aを3つ動かしたい Current state Container Aは2つ動いている

Slide 95

Slide 95 text

Desired state Container Aを3つ動かしたい Current state Container Aは2つ動いている Action Container Aを1つ起動する

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Extensibility 拡張性の高さにより自分たちの環境に合わせて使いやすくしたり様々なworkloadに対応することができる Ecosystem Ecosystemの広さにより拡張が容易に行える

Slide 98

Slide 98 text

Slide 99

Slide 99 text

Kubernetes does Deploymentリソースによって安全なRolloutをする ReplicaSetリソースによってSelf-healingをする ServiceリソースによってLoad balancingをする HolizontalPodAutoscalerリソースによってAuto Scalingをする

Slide 100

Slide 100 text

Kubernetes does NOT ソースコードからImageをBuildする LoggingやMonitoring，Alertの仕組みを提供する Applicationサービス (e.g., message busやSpark) を提供する Conﬁguration languageを提供する

Slide 101

Slide 101 text

Kubernetes vs. PaaS 伝統的なPaaS providerが提供してきたのは Kubernetes does NOTの部分． PaaSを使うかKubernetesを使うかはPaaSがbuilt-inで提供してくれる仕組みに「乗れるか乗れないか」「必要十分か否か」

Slide 102

Slide 102 text

Stateless Batch ML Secure Stateful Various Business Various Application Stateless Batch ML Secure Stateful

Slide 103

Slide 103 text

Kubernetes Extensibility Custom Controllerにより自分たち専用のタスクを行う Custom Resource DeﬁnitionによりAPIを拡張する Admission webhookにより専用のValidationやMutationを行う Device pluginによりGPUやFPGAといったHWを使えるようにする

Slide 104

Slide 104 text

Serverless Abstraction ML workload Abstraction Mercari PaaS Abstraction App App App App Various Abstraction Platform Various Application App App App App App App App App Productivity Mercariのワークフローにあった抽象化を入れることで生産性を上げる ! Flexibility 様々なワークロードにあった抽象化を実装する

Slide 105

Slide 105 text

Slide 106

Slide 106 text

Slide 107

Slide 107 text

https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

https://speakerdeck.com/thockin/dockercon-2018-kubernetes-extensibility?slide=62

Slide 110

Slide 110 text

Mercari PaaS Abstraction App App App App Various Abstraction Platform Various Application App App App App App App App App Serverless Abstraction ML workload Abstraction

Slide 111

Slide 111 text

Mercari PaaS Abstraction App App App App Various Abstraction Platform Various Application App App App App App App App App ML workload Abstraction

Slide 112

Slide 112 text

Mercari PaaS Abstraction App App App App Various Abstraction Platform Various Application App App App App App App App App

Slide 113

Slide 113 text

Slide 114

Slide 114 text

Slide 115

Slide 115 text

Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするためのインターフェースを提供する

Slide 116

Slide 116 text

Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするためのインターフェースを提供する

Slide 117

Slide 117 text

Slide 118

Slide 118 text

Namespace: Service A Kubernetes GCP Project: Service A Service A Team Spanner Container A Container A Container A Kubernetes setup 専用のnamespaceを準備する GCP Setup 専用のProjectを準備してDatabaseなどをセットアップする

Slide 119

Slide 119 text

How to provision Infra? Microservicesを作るたびにインフラのセットアップを Platformに依頼するとスピードが落ちる．開発者が自分たちでインフラを管理できる必要がある．どのように実現しているか?

Slide 120

Slide 120 text

No content

Slide 121

Slide 121 text

GitHub PR Workﬂow

Slide 122

Slide 122 text

PR Plan & Apply microservices-terraform CircleCI Service A Team Service A Team Service A Team PR PR

Slide 123

Slide 123 text

PR Plan & Apply Platform Team microservices-terraform CircleCI Service A Team Setup Service A Team Service A Team PR PR Automation Terraformの実行やStateの管理を行う．Lintにより機械的なReviewやPolicy のチェックを行う

Slide 124

Slide 124 text

Develop Test Deploy Operate Toolsets

Slide 125

Slide 125 text

References  ● Kubernetes manifests management and operation in Mercari ○ https://speakerdeck.com/b4b4r07/kubernetes-manifests-management-and-operation-in-mercari ● Continuous Delivery for Microservices with Spinnaker at Mercari ○ https://speakerdeck.com/tcnksm/continuous-delivery-for-microservices-with-spinnaker-at-mercari ● Securing microservices continuous delivery using grafeas and kritis ○ https://www.slideshare.net/VishalBanthia1/securing-microservices-continuous-delivery-using-grafeas-and -kritis ● How we monitor microservices at Mercari microservices platform team ○ https://speakerdeck.com/spesnova/how-we-monitor-microservices-at-mercari-microservices-platform-tea m

Slide 126

Slide 126 text

Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするためのインターフェースを提供する

Slide 127

Slide 127 text

Conclusion  ● Why Microservices Platform? ● How we build Platform? (Philosophy) ● What we are building?

Slide 128

Slide 128 text

We’re Hiring