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

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

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

Ecb3acc2d246962361a4f8b3f7a6dd12?s=128

taichi nakashima

June 29, 2019
Tweet

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 1つ機能をスケールさせるた めに全体をスケールさせる必 要がありリソースの無駄遣い
  29. Listing Shipping Notification Purchase Login Timeline Search DB Monolith Availability

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

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

    1つのコンポーネントが死んだ ら全体が死ぬ... Review Search Scalability 1つ機能をスケールさせるた めに全体をスケールさせる必 要がありリソースの無駄遣い 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
  50. None
  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へアクセスするための インターフェースを提供する

  72. None
  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を実行している.
  92. None
  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

  108. None
  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に依頼するとス ピードが落ちる.開発者が自分たちでインフラを管理できる必要がある.どのよ うに実現しているか?

  120. None
  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