20180920 DevOps on Merpay Microservices

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

Transcript

1. JDDStudy #3 Merpay SRE @tjun DevOps on Merpay Microservices
2. 2 自己紹介 Copyright © Merpay, Inc. All Rights Reserved. @tjun SRE Team at Merpay
3. DevOpsを振り返る 7
4. Dev psってなんだっけ Dev psとは（自分の3年前くらいの理解） • 開発と運用が協力する • 運用にもソフトウェア開発のノウハウを用いて、デプロイの自動化や インフラのコード化を行う • それによって、開発とリリースを効率よく回す Dev ps以前: 運用担当がサーバにsshして必要パッケージを install/update、コードをscpして実行 Dev ps以後: chefやansibleなどを使ってInfraを管理、自動化 8
5. Dev psの変化 3年前に比べると - Cloud化 - コンテナ化、サーバレス化 - Dev psを実現するツールが増えた 単純なインフラ運用作業(toil)が減ってきた。 Developerがある程度 psもできる時代に 9
6. 今のDev psとは yftの att(Envoyの作者の人)の定義 「Developerが24/7で roductionの運用にも責任を持つこと」 • tart pでは限られたエンジニアが開発してリリースまで行う • Cloudや周辺ツールが充実してきたので、コードを書いた人がデプロ イして運用できる • 自分のコードに問題があると、自分で気づいて自分で直すしかない。 クオリティをかならず意識する世界 10
7. Merpay SREの役割 11
8. 組織とサービスの成長とDev ps サービスと組織が成長すると、 - コミュニケーションと開発の効率を維持するのが困難になる - onolithから icroserviceのようなアーキテクチャへと移行する - icroservice化に伴い、システムの複雑度が上がる - トラフィック増加によるネットワークやDB等で課題が出てくる Developerだけでシステム全体の運用をやるのが困難になってくる 12
9. erpayの Eチーム システム全体を横断的に見るチーム • icroservicesの各チームがDev psを実現するための基盤づくり • 各チームがDev psを行うためのサポート • インフラ寄りの問題解決 13
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
11. MerpayのMicroservices基盤 15
12. erpayのアーキテクチャ概要 Clients Merpay API Gateway API ServiceA ServiceA ServiceA API Google Kubernetes Engine 16
13. Microservices • caleする組織＆サービスに耐えられるアーキテクチャ • 機能やデータをサービスごとに分離できる ◦ コードが分かれている（当たり前） ◦ チームが分かれている ◦ データベースが分かれている ◦ Kubernetesのnamespaceが分かれている ◦ GCPのprojectが分かれている サービスの安定性・安全性を実現するために重要 17
14. MerpayのMicroservices • ほとんどはGoで書かれている ◦ Go microservice templateのようなコードがある • gRPCでやりとり ◦ protoファイルで定義を決めて共有できる ◦ 多言語対応が比較的カンタン • A Iレイヤを分離することで、各サービスはサービスの機能に専念 できる ◦ クライアントを意識するのはA Iレイヤの仕事 18
15. G E(Google ubernetes Engine) • Microserviceのための機能 ◦ Namespace ◦ Secret ◦ RBAC ◦ Managed Istio(まだ使ってない) • 運用が楽になるための機能 ◦ Managed kubernetes ◦ Update/Rollback ◦ Load balance & Autoscale ◦ Auto repair 19
16. erpay A I Gateway Clients Merpay API Gateway API ServiceA ServiceA ServiceA API Google Kubernetes Engine 20
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
18. icroservices latformの構築と運用 22
19. icroservice latform eam @mercari • icroservices latform = GC , G Eとその周りの仕組み ◦ erpayのサービスは icroservices latform上に構築 • erpay Eは latform側の改善にも参加する 23
20. icroservice latformが提供する機能 • icroservice tarter-kit ◦ GC projectとk8s namespaceを自動作成 ◦ Datadogや agerdutyとも連携 ◦ terraformでInfraのコード管理 • CI/CD ◦ CircleCI → Container egistry　→　 pinnaker で自動デプロイ • ecurity ◦ さまざまなレイヤでのセキュリティのための機能 24
21. 運用体制イメージ サービスに関する問題 • Error • atency • DB • 問い合わせ Service Alert latformやInfraの問題 • kubernetes • Gateway • GC まわり Platform Alert Service Team SRE 25
22. 運用の仕組みの共通化 • icroserviceでは各サービスのチームが wnerとなって運用を進め ていく。技術選定も自由。 • とはいえ、 Eや他のチームのメンバーがサポートするためには共 通化が必要 • ルールの共通化: ( ervice evel bjective)を決めよう • ツールの共通化: tackDriver, Datadog, entry, agerduty 26
23. 運用の仕組みの共通化 • : サービスが信頼できる状態かどうか判断するための指標 ◦ 例: Gatewayで測定して、あるA Iの equestの成功率が99.99% ◦ 指標がないと、何を直すのか、いつ緊急対応するのかの判断ができない • ツールの共通化 ◦ ログ: tackDriver & Big uery, メトリクス: Datadog, エラー通知: entry, 当番通 知: agerduty ◦ icroservice starter-kitで自動で各サービスの eamや rojectなどが生成され る 27
24. まとめ 28
25. まとめ erpayの Eは • icroservice latformを使ったサービス運用を行うチームです • icroservice latform自体の改善にも参加しています GC やりたい人、 ubernetesや icroserviceやりたい人、DB, etwork, ecurityなどが 得意な人、ぜひ一緒にやりましょう！！ merpay 採用ページの ite eliability までお願いします We are hiring!!! 29