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

ハッカーズチャンプルー2019（ http://hackers-champloo.org/2019 ）の発表資料です

Transcript

1. 開発者向けの基盤をつくる Building A Platform for Internal Developers
2. Taichi Nakashima @deeeet / @tcnksm
3. 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
4. https://www.amazon.co.jp/dp/4297107279 改訂2版出ます at 2019/8/1 @tenntennさんが私の章を引き継いてくれました !
5. Agenda
 • Why Microservices Platform? • How we build Platform? (Philosophy) • What we are building?
6. Why Microservices Platform? なぜMicroservices Platformが必要か?
7. Why Microservices Platform? Microservicesとは何か?
8. Listing Shipping Notification Purchase Login Search DB Monolith Review Listing DB User DB Item DB Shipping DB Timeline DB Microservices Timeline Search
9. Single Purpose 1つのことに集中しておりそ れをうまくやること 各サービスは関連する振る 舞いやデータをカプセル化 していること 各サービスは依存するサー ビスについて最小限のこと を知っていること Loosely Coupling High Cohesion
10. Loose couplingを満たさないと一 つのサービスの変更が他のサービ スに影響を与えることになる High cohesionを満たさないと分散 Monolithになる．一つの機能の開発 のために複数のサービスを変更しな いといけなくなる Single purposeを満たさないとそれぞ れのサービスは多くのことをやること になる．複数のMonolithが存在する ことになる
11. Why Microservices Platform? なぜMercariは複雑なMicroservices化をしているのか?
12. Scaling Organization 組織を再編し組織としてのアウトプットを最大化す るため Solving Technical Issues 技術的な課題を解決するため
13. Scaling Organization 組織を再編し組織としてのアウトプットを最大化す るため Solving Technical Issues 技術的な課題を解決するため
14. https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/
15. Listing Shipping Notification Purchase Login Search DB Monolith Review Backend team Timeline Search
16. Listing Shipping Notification Purchase Login Search DB Monolith Review Backend team Timeline Search
17. Listing Shipping Notification Purchase Login Search DB Monolith Review Backend team Timeline Search
18. Listing Shipping Notification Purchase Login Search DB Monolith Review Backend team Timeline Search 人が増えても一日にリリースできる回数に限界がきて いた...
19. Listing Shipping Notification Purchase Login Search DB Monolith Review Listing DB User DB Item DB Shipping DB Timeline DB Microservices Backend team Timeline Search
20. Listing Shipping Notification 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
21. Listing Shipping Notification 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日にリリー スできる数は飛躍的に増える = より速く機能を提供で きる!
22. Scaling Organization 組織を再編し組織としてのアウトプットを最大化す るため Solving Technical Issues 技術的な課題を解決するため
23. Scaling Organization 組織を再編し組織としてのアウトプットを最大化す るため Solving Technical Issues 技術的な課題を解決するため
24. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Review Search
25. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search
26. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search
27. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search
28. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search Scalability １つ機能をスケールさせるた めに全体をスケールさせる必 要がありリソースの無駄遣い
29. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search Scalability １つ機能をスケールさせるた めに全体をスケールさせる必 要がありリソースの無駄遣い
30. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search Scalability １つ機能をスケールさせるた めに全体をスケールさせる必 要がありリソースの無駄遣い
31. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability 1つのコンポーネントが死んだ ら全体が死ぬ... Review Search Scalability １つ機能をスケールさせるた めに全体をスケールさせる必 要がありリソースの無駄遣い Complexity 新しい機能を追加するのが難 しい... オンボーディングが難 しい
32. Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices
33. Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一 部のサービスを継続して動か せる
34. Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一 部のサービスを継続して動か せる
35. Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一 部のサービスを継続して動か せる
36. Listing DB Listing team User DB User team Item DB Item team Shipping DB Shipping team Timeline DB Timeline team Microservices Resilient 1つのサービスが死んでも一 部のサービスを継続して動か せる 出品はできなくても Timelineは閲覧できる
37. 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 サービスごとに独立してス ケールすることができリソース を最適化できる
38. 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 サービスごとに独立してス ケールすることができリソース を最適化できる
39. 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 サービスごとに独立してス ケールすることができリソース を最適化できる
40. 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 サービスごとに独立してス ケールすることができリソース を最適化できる Simplicity 小さなコンテキストで開発する ことにより新機能の追加が容 易になる
41. Scaling Organization 組織を再編し組織としてのアウトプットを最大化す るため Solving Technical Issues 技術的な課題を解決するため
42. Why Microservices Platform? なぜMicroservices Platformが必要か?
43. https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/
44. Develop Monolith Test Deploy Operate Software Lifecycle
45. Develop Monolith Test Deploy Operate QA team SRE team Monolith Team Responsibility Backend Team
46. 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
47. 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
48. 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を担う必要が ある
49. Develop Test Deploy Operate Prepare QA environment Setup CI Run integration testing Run load testing Provision infrastructure Setup automated delivery Prepare application configuration Prepare monitoring Prepare observability Prepare on-calling shift Too many things to do
51. Develop Test Deploy Operate Platform Platform Team
52. Backend Team Microservicesの 開発と運用に注力する 基盤やDevOpsツールの 開発と運用に注力する Microservicesのデザイン のレビューや移行戦略に注 力する Architect Team Platform Team
53. Number of microservices + teams Number of tools Platform No Platform 各チームが自分たちで Toolsetsを作ると似たような ツールが大量に作られコスト的にも無駄になる 基盤チームが専属的にツールの開発と 運用を担うことでツールの乱立を抑え， 基盤の改善のLeverageが効く
54. Agenda
 • Why Microservices Platform? • How we build Platform? (Philosophy) • What we are building?
55. How We Build Platform? どのように基盤を構築しているか ?
56. Infrastructure Developer Experience Platform Developers Customers Productivity & flexibility Innovative product Team Mission
57. Productivity 生産性を向上させることで 仮説検証のループを高速に回すこと を可能にする Flexibility 柔軟性を提供することで 新たなビジネスに対応したり 新たな技術やサービスの検証や導入 を可能にする
58. Productivity 生産性を向上させることで 仮説検証のループを高速に回すこと を可能にする Flexibility 柔軟性を提供することで 新たなビジネスに対応したり 新たな技術やサービスの検証や導入 を可能にする
59. Productivity = Output Input Product, Service, Function GMV Customer satisfactions Engineering efforts Develop time Test time Deploy time Operate time ...
60. https://itrevolution.com/book/accelerate/ Delivery lead time 企画から実際に機能やサービスをリリースするまでにかかった か? Deployment frequency どれくらいの頻度でコードをリリースしているか ? Time to restore service インシデントが発生してから普及までどれだけの時間がかかった か? Change rate fail どれくらいの頻度で変更が失敗したか ?どれくらいの頻度で Rollbackしたか?
61. Develop Test Deploy Operate Productivityの向上は高速な仮説 検証のループを回すことが可能に なる 仮説検証を繰り返すことによって Innovationを駆動することが可能 になる = Productivityの向上は Innovationを駆動する
62. Productivity 生産性を向上させることで 仮説検証のループを高速に回すこと を可能にする Flexibility 柔軟性を提供することで 新たなビジネスに対応したり 新たな技術やサービスの検証や導入 を可能にする
63. Productivity 生産性を向上させることで 仮説検証のループを高速に回すこと を可能にする Flexibility 柔軟性を提供することで 新たなビジネスに対応したり 新たな技術やサービスの検証や導入 を可能にする
64. Flexibility = Technical choices Programing Language Frameworks Databases Runtimes Cloud Services ...
65. Junior developers Experienced developers Platform より速く機能を出すことに集中したい 新たな技術やサービスの検証を進めたい
66. Productivity Innovation chance Productivityのみに注力しすぎる と新たな技術やサービスの検証や 導入を阻害してしまう可能性があ る = Productivityに注力しすぎると Innovationの駆動は減衰する ProductivityとFlexibilityの両方を 提供しバランスを取る必要がある
67. Infrastructure Developer Experience Platform Developers Customers Productivity & flexibility Innovative product Team Mission
68. Agenda
 • Why Microservices Platform? • How we build Platform? (Philosophy) • What we are building?
69. What we are building? 何を構築しているのか ?
70. Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするための インターフェースを提供する
71. Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするための インターフェースを提供する
73. Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?
74. Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?
75. https://blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/
76. Continuous Deliveryのプラクティスを成功させるための最も重要な要素は 新しいコードを恐れなく本番に出せることである ”Continuous Delivery With Spinnaker”, chapter 7
77. Immutable Infrastructure 一度デプロイしたインスタンスやコンテナには決して手を加えず 機能を追加したり修正をする場合は インスタンスやコンテナから作り直す
78. Deterministic Deployment CanaryやBlue-Greenにより安全にRolloutすることができる 問題が起こったときに安全にRollBackすることができる 環境間の差異を最小限にすることができる（問題の再現が容易）
79. Container vs. VM 高速なビルドと起動・ Portabilityの高さ・Utilizationの高さ
80. https://dzone.com/articles/migration-from-vms-to-containers-1
81. Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?
82. Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?
83. What is Kubernetes?
84. Human SSH！ シンプル・余計なツールが 必要ないが人間に依存して 再現性がないしスケールし ない k8s, Mesos, Nomad スケジューリングは自動化 され再現性がありスケール もするが複雑で・新しいツー ルやトレーニングが必要に なる Ansible, Chef, Puppet 理解しやすい・再現性があ るがスケジューリングがマ ニュアルでありスケールもし ない Script Orchestrator
85. etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B
86. etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative configuration Container Aを3 CPUsと1G Memで 3つ起動する
87. etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative configuration Container Aを3 CPUsと1G Memで 3つ起動する Scheduling リソースの余裕のある Nodeを探して Containerを配置する Container A Container A Container A
88. etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative configuration Container Aを3 CPUsと1G Memで 3つ起動する Scheduling リソースの余裕のある Nodeを探して Containerを配置する Container A Container A Container A
89. etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative configuration Container Aを3 CPUsと1G Memで 3つ起動する Scheduling リソースの余裕のある Nodeを探して Containerを配置する Container A Container A Container A Self healing Containerが死んだときに 自動で復旧する
90. etcd API server Scheduler Controller Manager kubelet Master Node kubelet Node Container B Declarative configuration Container Aを3 CPUsと1G Memで 3つ起動する Scheduling リソースの余裕のある Nodeを探して Containerを配置する Container A Container A Container A Self healing Containerが死んだときに 自動で復旧する Load balancing クラスタ内の他のContainerへの接続す る方法を提供する
91. etcd API server Scheduler Controller Manager kubelet Container A Master Node kubelet Node Container A Container A Container B Controller Kubernetesでは大量の独立した Controllerが動いておりそれぞれが Reconciliation loopを実行している．
93. Desired state Container Aを3つ動かしたい
94. Desired state Container Aを3つ動かしたい Current state Container Aは2つ動いている
95. Desired state Container Aを3つ動かしたい Current state Container Aは2つ動いている Action Container Aを1つ起動する
96. Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?
97. Extensibility 拡張性の高さにより 自分たちの環境に合わせて使いやすくしたり 様々なworkloadに対応することができる Ecosystem Ecosystemの広さにより 拡張が容易に行える
98. Extensibility 拡張性の高さにより 自分たちの環境に合わせて使いやすくしたり 様々なworkloadに対応することができる Ecosystem Ecosystemの広さにより 拡張が容易に行える
99. Kubernetes does Deploymentリソースによって安全なRolloutをする ReplicaSetリソースによってSelf-healingをする ServiceリソースによってLoad balancingをする HolizontalPodAutoscalerリソースによってAuto Scalingをする
100. Kubernetes does NOT ソースコードからImageをBuildする LoggingやMonitoring，Alertの仕組みを提供する Applicationサービス (e.g., message busやSpark) を提供する Configuration languageを提供する
101. Kubernetes vs. PaaS 伝統的なPaaS providerが提供してきたのは Kubernetes does NOTの部分． PaaSを使うかKubernetesを使うかはPaaSがbuilt-inで提供してくれる仕組み に 「乗れるか乗れないか」「必要十分か否か」
102. Stateless Batch ML Secure Stateful Various Business Various Application Stateless Batch ML Secure Stateful
103. Kubernetes Extensibility Custom Controllerにより自分たち専用のタスクを行う Custom Resource DefinitionによりAPIを拡張する Admission webhookにより専用のValidationやMutationを行う Device pluginによりGPUやFPGAといったHWを使えるようにする
104. 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 様々なワークロードにあった抽象化を実 装する
105. Extensibility 拡張性の高さにより 自分たちの環境に合わせて使いやすくしたり 様々なworkloadに対応することができる Ecosystem Ecosystemの広さにより 拡張が容易に行える
106. Extensibility 拡張性の高さにより 自分たちの環境に合わせて使いやすくしたり 様々なworkloadに対応することができる Ecosystem Ecosystemの広さにより 拡張が容易に行える
107. https://github.com/kubernetes/community/blob/master/contributors/devel/architectural-roadmap.md
109. https://speakerdeck.com/thockin/dockercon-2018-kubernetes-extensibility?slide=62
110. 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
111. Mercari PaaS Abstraction App App App App Various Abstraction Platform Various Application App App App App App App App App ML workload Abstraction
112. Mercari PaaS Abstraction App App App App Various Abstraction Platform Various Application App App App App App App App App
113. Extensibility 拡張性の高さにより 自分たちの環境に合わせて使いやすくしたり 様々なworkloadに対応することができる Ecosystem Ecosystemの広さにより 拡張が容易に行える
114. Why Container? なぜContainerを採用したのか? なぜVMではないのか? Why Kubernetes? なぜKubernetesを採用したのか? なぜPaaSではないのか? なぜNomadやMesosではないのか?
115. Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするための インターフェースを提供する
116. Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするための インターフェースを提供する
117. Develop Test Deploy Operate Prepare QA environment Setup CI Run integration testing Run load testing Provision infrastructure Setup automated delivery Prepare application configuration Prepare monitoring Prepare observability Prepare on-calling shift Too many things to do
118. 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など をセットアップする
119. How to provision Infra? Microservicesを作るたびにインフラのセットアップを Platformに依頼するとス ピードが落ちる．開発者が自分たちでインフラを管理できる必要がある．どのよ うに実現しているか?
121. GitHub PR Workflow
122. PR Plan & Apply microservices-terraform CircleCI Service A Team Service A Team Service A Team PR PR
123. 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 のチェックを行う
124. Develop Test Deploy Operate Toolsets
125. 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
126. Infrastructure Microservicesを動かすための土台を提供する Developer Experience 複雑なInfrastructureへアクセスするための インターフェースを提供する
127. Conclusion
 • Why Microservices Platform? • How we build Platform? (Philosophy) • What we are building?
128. We’re Hiring