20180920 DevOps on Merpay Microservices

Merpayで構築中のMicroservices基盤におけるDevOpsの取り組みについて発表します。

Transcript

1. JDDStudy #3
   Merpay SRE @tjun
   DevOps on
   Merpay Microservices
   

   View Slide

2. 2
   自己紹介
   Copyright © Merpay, Inc. All Rights Reserved.
   @tjun
   SRE Team at Merpay
   

   View Slide

3. DevOpsを振り返る
   7
   

   View Slide

4. Dev psってなんだっけ
   Dev psとは（自分の3年前くらいの理解）
   ● 開発と運用が協力する
   ● 運用にもソフトウェア開発のノウハウを用いて、デプロイの自動化や
   インフラのコード化を行う
   ● それによって、開発とリリースを効率よく回す
   Dev ps以前: 運用担当がサーバにsshして必要パッケージを
   install/update、コードをscpして実行
   Dev ps以後: chefやansibleなどを使ってInfraを管理、自動化
   8
   

   View Slide

5. Dev psの変化
   3年前に比べると
   - Cloud化
   - コンテナ化、サーバレス化
   - Dev psを実現するツールが増えた
   単純なインフラ運用作業(toil)が減ってきた。
   Developerがある程度 psもできる時代に
   9
   

   View Slide

6. 今のDev psとは
   yftの att(Envoyの作者の人)の定義
   「Developerが24/7で roductionの運用にも責任を持つこと」
   ● tart pでは限られたエンジニアが開発してリリースまで行う
   ● Cloudや周辺ツールが充実してきたので、コードを書いた人がデプロ
   イして運用できる
   ● 自分のコードに問題があると、自分で気づいて自分で直すしかない。
   クオリティをかならず意識する世界
   10
   

   View Slide

7. Merpay SREの役割
   11
   

   View Slide

8. 組織とサービスの成長とDev ps
   サービスと組織が成長すると、
   - コミュニケーションと開発の効率を維持するのが困難になる
   - onolithから icroserviceのようなアーキテクチャへと移行する
   - icroservice化に伴い、システムの複雑度が上がる
   - トラフィック増加によるネットワークやDB等で課題が出てくる
   Developerだけでシステム全体の運用をやるのが困難になってくる
   12
   

   View Slide

9. erpayの Eチーム
   システム全体を横断的に見るチーム
   ● icroservicesの各チームがDev psを実現するための基盤づくり
   ● 各チームがDev psを行うためのサポート
   ● インフラ寄りの問題解決
   13
   

   View Slide

10. 「 E」ってなんだっけ
    このあとの北野さんの発表とかぶりそうなので省略
    参考資料
    ● E本: http://landing.google.com/sre/book.html
    ● Dev ps vs E (google cloudのblog記事)
    ○ https://cloudplatform.googleblog.com/2018/05/ E-vs-Dev ps-competing-standards-or-close-
    friends.html
    また、ここまでの話は以下の記事を参考にしています
    - he human scalability of “Dev ps” – att lein
    https://medium.com/@mattklein123/the-human-scalability-of-devops-e36c37d3db6a
    14
    

    View Slide

11. MerpayのMicroservices基盤
    15
    

    View Slide

12. erpayのアーキテクチャ概要
    Clients
    Merpay
    API
    Gateway
    API
    ServiceA
    ServiceA
    ServiceA
    API
    Google Kubernetes Engine
    16
    

    View Slide

13. Microservices
    ● caleする組織＆サービスに耐えられるアーキテクチャ
    ● 機能やデータをサービスごとに分離できる
    ○ コードが分かれている（当たり前）
    ○ チームが分かれている
    ○ データベースが分かれている
    ○ Kubernetesのnamespaceが分かれている
    ○ GCPのprojectが分かれている
    サービスの安定性・安全性を実現するために重要
    17
    

    View Slide

14. MerpayのMicroservices
    ● ほとんどはGoで書かれている
    ○ Go microservice templateのようなコードがある
    ● gRPCでやりとり
    ○ protoファイルで定義を決めて共有できる
    ○ 多言語対応が比較的カンタン
    ● A Iレイヤを分離することで、各サービスはサービスの機能に専念
    できる
    ○ クライアントを意識するのはA Iレイヤの仕事
    18
    

    View Slide

15. G E(Google ubernetes Engine)
    ● Microserviceのための機能
    ○ Namespace
    ○ Secret
    ○ RBAC
    ○ Managed Istio(まだ使ってない)
    ● 運用が楽になるための機能
    ○ Managed kubernetes
    ○ Update/Rollback
    ○ Load balance & Autoscale
    ○ Auto repair
    19
    

    View Slide

16. erpay A I Gateway
    Clients
    Merpay
    API
    Gateway
    API
    ServiceA
    ServiceA
    ServiceA
    API
    Google Kubernetes Engine
    20
    

    View Slide

17. erpay A I Gateway (+G B)
    ● equestの outing + rotocol transform
    ● 共通のEndpoint処理
    ○ DDo rotection(G B)
    ○ ermination(G B)
    ○ Authentication
    ○ Buffering
    ● bservability
    ○ ogging & racing
    参考: 「A I Gatewayによる icroservices化」 by deeeet
    21
    

    View Slide

18. icroservices latformの構築と運用
    22
    

    View Slide

19. icroservice latform eam @mercari
    ● icroservices latform = GC , G Eとその周りの仕組み
    ○ erpayのサービスは icroservices latform上に構築
    ● erpay Eは latform側の改善にも参加する
    23
    

    View Slide

20. icroservice latformが提供する機能
    ● icroservice tarter-kit
    ○ GC projectとk8s namespaceを自動作成
    ○ Datadogや agerdutyとも連携
    ○ terraformでInfraのコード管理
    ● CI/CD
    ○ CircleCI → Container egistry　→　 pinnaker で自動デプロイ
    ● ecurity
    ○ さまざまなレイヤでのセキュリティのための機能
    24
    

    View Slide

21. 運用体制イメージ
    サービスに関する問題
    ● Error
    ● atency
    ● DB
    ● 問い合わせ
    Service Alert
    latformやInfraの問題
    ● kubernetes
    ● Gateway
    ● GC まわり
    Platform Alert
    Service Team SRE
    25
    

    View Slide

22. 運用の仕組みの共通化
    ● icroserviceでは各サービスのチームが wnerとなって運用を進め
    ていく。技術選定も自由。
    ● とはいえ、 Eや他のチームのメンバーがサポートするためには共
    通化が必要
    ● ルールの共通化: ( ervice evel bjective)を決めよう
    ● ツールの共通化: tackDriver, Datadog, entry, agerduty
    26
    

    View Slide

23. 運用の仕組みの共通化
    ● : サービスが信頼できる状態かどうか判断するための指標
    ○ 例: Gatewayで測定して、あるA Iの equestの成功率が99.99%
    ○ 指標がないと、何を直すのか、いつ緊急対応するのかの判断ができない
    ● ツールの共通化
    ○ ログ: tackDriver & Big uery, メトリクス: Datadog, エラー通知: entry, 当番通
    知: agerduty
    ○ icroservice starter-kitで自動で各サービスの eamや rojectなどが生成され
    る
    27
    

    View Slide

24. まとめ
    28
    

    View Slide

25. まとめ
    erpayの Eは
    ● icroservice latformを使ったサービス運用を行うチームです
    ● icroservice latform自体の改善にも参加しています
    GC やりたい人、 ubernetesや icroserviceやりたい人、DB, etwork, ecurityなどが
    得意な人、ぜひ一緒にやりましょう！！
    merpay 採用ページの ite eliability までお願いします
    We are hiring!!!
    29
    

    View Slide