JDDStudy #3 Merpay SRE @tjun DevOps on Merpay Microservices

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

DevOpsを振り返る 7

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

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

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

Merpay SREの役割 11

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

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

「 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

MerpayのMicroservices基盤 15

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

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

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

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

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

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

icroservices latformの構築と運用 22

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

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

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

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

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

まとめ 28

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