Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

taichi nakashima

June 29, 2019
Tweet

More Decks by taichi nakashima

Other Decks in Technology

Transcript

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

    View Slide

  2. Taichi Nakashima
    @deeeet / @tcnksm

    View Slide

  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

    View Slide

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

    View Slide

  5. Agenda

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

    View Slide

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

    View Slide

  7. Why Microservices Platform?
    Microservicesとは何か?

    View Slide

  8. Listing
    Shipping
    Notification
    Purchase
    Login
    Search
    DB
    Monolith
    Review
    Listing
    DB
    User
    DB
    Item
    DB
    Shipping
    DB
    Timeline
    DB
    Microservices
    Timeline Search

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  15. Listing
    Shipping
    Notification
    Purchase
    Login
    Search
    DB
    Monolith
    Review
    Backend team
    Timeline Search

    View Slide

  16. Listing
    Shipping
    Notification
    Purchase
    Login
    Search
    DB
    Monolith
    Review
    Backend team
    Timeline Search

    View Slide

  17. Listing
    Shipping
    Notification
    Purchase
    Login
    Search
    DB
    Monolith
    Review
    Backend team
    Timeline Search

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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日にリリー
    スできる数は飛躍的に増える = より速く機能を提供で
    きる!

    View Slide

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

    View Slide

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

    View Slide

  24. Listing
    Shipping
    Notification
    Purchase
    Login
    Timeline Search
    DB
    Monolith
    Review
    Search

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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は閲覧できる

    View Slide

  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
    サービスごとに独立してス
    ケールすることができリソース
    を最適化できる

    View Slide

  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
    サービスごとに独立してス
    ケールすることができリソース
    を最適化できる

    View Slide

  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
    サービスごとに独立してス
    ケールすることができリソース
    を最適化できる

    View Slide

  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
    小さなコンテキストで開発する
    ことにより新機能の追加が容
    易になる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  44. Develop
    Monolith
    Test Deploy Operate
    Software Lifecycle

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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を担う必要が
    ある

    View Slide

  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

    View Slide

  50. View Slide

  51. Develop Test Deploy Operate
    Platform
    Platform Team

    View Slide

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

    View Slide

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

    View Slide

  54. Agenda

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

    View Slide

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

    View Slide

  56. Infrastructure
    Developer
    Experience
    Platform
    Developers Customers
    Productivity & flexibility Innovative product
    Team Mission

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  66. Productivity
    Innovation chance
    Productivityのみに注力しすぎる
    と新たな技術やサービスの検証や
    導入を阻害してしまう可能性があ

    = Productivityに注力しすぎると
    Innovationの駆動は減衰する
    ProductivityとFlexibilityの両方を
    提供しバランスを取る必要がある

    View Slide

  67. Infrastructure
    Developer
    Experience
    Platform
    Developers Customers
    Productivity & flexibility Innovative product
    Team Mission

    View Slide

  68. Agenda

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  83. What is Kubernetes?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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が死んだときに
    自動で復旧する

    View Slide

  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への接続す
    る方法を提供する

    View Slide

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

    View Slide

  92. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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
    様々なワークロードにあった抽象化を実
    装する

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  108. View Slide

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

    View Slide

  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

    View Slide

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

    View Slide

  112. Mercari PaaS
    Abstraction
    App App
    App App
    Various
    Abstraction
    Platform
    Various
    Application
    App App
    App App
    App App
    App App

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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など
    をセットアップする

    View Slide

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

    View Slide

  120. View Slide

  121. GitHub PR Workflow

    View Slide

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

    View Slide

  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
    のチェックを行う

    View Slide

  124. Develop Test Deploy Operate
    Toolsets

    View Slide

  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

    View Slide

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

    View Slide

  127. Conclusion

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

    View Slide

  128. We’re Hiring

    View Slide