Slide 1

Slide 1 text

#merpay_techtalk エンジニアリングを支援するための様々なかたち 2022/05/25 @goccy

Slide 2

Slide 2 text

goccy ( ごっしー )
 merpay Architect
 
 @goccy54
 
 goccy 
 Total 3.7k +


Slide 3

Slide 3 text

Engineering Productivity Teamで
 開発・運用している主なもの
 ● 社内の開発者向けのサービス・ライブラリ・ツールを開発
 ● 旧Architectチームの時代からの成果物の例
 ○ QA環境の複製とリクエスト経路の動的切り替え
 ○ マイクロサービス間の結合テスト支援
 ○ マイクロサービスのダッシュボード
 ○ Cloud Spanner や gRPC を扱うための便利なライブラリやツール
 ● 上記の成果物の具体的な内容と開発のモチベーションについて紹介


Slide 4

Slide 4 text

QA環境の複製とリクエスト経路の動的切り替え 4

Slide 5

Slide 5 text

QA環境の複製とリクエスト経路の動的切り替え
 ● QAや開発を効率よく進めるために、検証したい単位ごとに環境を用意して同時並 行で進められると嬉しい
 ○ これができないと、決められた環境を順番待ちで利用することになってスケー ルしない
 
 ● メルペイでは以下の技術を利用しながら実現
 ○ Pull Request Replication Controller
 ○ Dynamic Service Routing
 ○ 110y/bootes


Slide 6

Slide 6 text

Pull Request Replication Controller ( PRRC )
 ● Pull Request ( PR ) を作ると、差分を反映した状態のサービスを立ち上げてくれる Kubernetes Operator 
 ○ PR毎に別のサービスが立ち上がり、個別に検証することができる
 ○ Merpay Tech Fest 2021_The World Is at Your Pull Request How to Make a Dynamic QA Environment on Kubernetes and Istio
 Motivation
 ● マージ前の PR のコードで動くサービスでテストしたい
 ● QAしたい環境をPRの単位で表現したい
 ○ 環境Aでは feature-xyz branch からできた PR の差分をもとに
 作ったサービスが立ち上がる

Slide 7

Slide 7 text

Dynamic Service Routing ( DSR )
 ● 切り替えたい経路の情報をヘッダに付与してリクエストすることで、
 任意の環境にリクエストを届ける仕組み
 ○ Merpay Tech Fest 2021_The World Is at Your Pull Request How to Make a Dynamic QA Environment on Kubernetes and Istio
 Motivation
 ● PRRC で立ち上がった複数の環境を切り替えるための統一的な仕組みが欲し い
 ● クラスタの外からのリクエストは基本的にGatewayを通るため、PRRCで立ち上 がった特定の環境に直接リクエストを送るようなことはできない

Slide 8

Slide 8 text

110y/bootes
 ● Kubernetes Operator として動作する xDS API 準拠の Control Plane github 
 ○ Envoy の各種設定 ( Cluster や Listener など ) を k8s の CRD として提供
 ○ k8s のリソースとしてクラスタに反映された Envoy の設定を xDS API 経由で各 Envoy に配布
 
 
 Motivation
 ● 複数用意した Gateway を切り替えるために前段に配置した DSR 用の Envoy に対 して、再デプロイすることなく設定を配布したい public


Slide 9

Slide 9 text

マイクロサービス間の結合テスト支援 9

Slide 10

Slide 10 text

マイクロサービス間の結合テスト支援
 ● Scenario Test Platform
 ○ 複数のマイクロサービスへのリクエストをシナリオとして YAML で
 記述し、レスポンスを検証する
 ○ シナリオをリポジトリに含めて簡単な設定ファイルを書くと、
 CIでそのシナリオを実行してくれるようになる
 ○ Scenario-Based Integration Testing Platform for Microservices 
 
 ● モックではなく実サービスを使ったテストをCIで検証したい
 ● Postman を使った既存の QA プロセスを改善したい
 Motivation


Slide 11

Slide 11 text

Scenario Test Platform を支える OSS
 ● Scenario Test Platform を支えるチームメンバーのOSS
 ○ zoncoen/scenarigo
 ○ goccy/go-yaml
 ○ goccy/kubetest
 
 ● その他のOSS
 ○ Prow : Contributionもしている 


Slide 12

Slide 12 text

zoncoen/scenarigo 
 ● YAML でテストシナリオを書いて、APIのシナリオテストができる github 
 Motivation
 ● それまでQAで使われていたPostmanの代わりに利用する目的で開発
 ● より社内の開発フローや技術スタックにあうツールを使いたい
 ○ Go でプラグインが開発できる: 認証認可などの社内共通ライブラリが再利 用できる
 ● Postman はテストケースをエクスポートすると複雑なJSONになり、
 コード管理と相性が悪い: 差分が確認しづらい
 public


Slide 13

Slide 13 text

goccy/go-yaml
 ● Goから使えるYAMLライブラリ github
 ○ zoncoen/scenarigo の内部や社内ツールのいろいろなところで使われている
 
 Motivation
 ● https://github.com/go-yaml/yaml を使っていて不満点が多くあったので自分で作っ た
 ● Article: GoでYAMLを扱うすべての人を幸せにするべく、ライブラリをスクラッチから 書いた話 public


Slide 14

Slide 14 text

goccy/kubetest
 ● 重いタスクをk8sクラスタ上で分散実行するための仕組み github
 ○ タスク数に応じて k8s Job を起動して Pod を複数起動して処理する
 ○ k8s Job をいい感じに操作するライブラリは goccy/kubejob として公開
 ○ Blog: テスト時間を短くするための分散テスト実行
 Motivation
 ● 大量のシナリオテストを実行すると時間がかかる
 ● k8sクラスタのリソースを効率的に使って分散テストすることで、
 シナリオテストの量に依存せずにテストしたい
 public


Slide 15

Slide 15 text

マイクロサービスのダッシュボード 15

Slide 16

Slide 16 text

マイクロサービスのダッシュボード
 ● 各マイクロサービスの色々な情報を収集して表示するサービス
 ○ 表示に利用しているAPIは、ブラウザだけでなく Go など他の
 クライアントからも2次利用できるように作られている
 ○ マイクロサービスダッシュボードの紹介 
 
 
 
 Motivation
 ● マイクロサービスの数が増えるにつれ、管理しているチームや問い合わせ先を把握 することなどが難しくなった
 ● 各マイクロサービスの様々な情報を統一的なインターフェースで参照したい

Slide 17

Slide 17 text

Spanner や gRPC を扱うための 便利なライブラリやツール 17

Slide 18

Slide 18 text

handy-spanner
 ● Storage engine に SQLite3 を用いた、インプロセスで使える 
 Spanner Emulator github 
 ○ handy-spanner GCPUG 
 ○ Cloud Spanner emulator with go-sqlite3 
 Motivation
 ● SpannerがbetaからGAになったあたりで社内で一斉に使い始めたが、
 当時はエミュレータがなかった
 ● インターンの方が Spannerの SQL Parser として memefish を作っていることを知り、こ れを使ったらエミュレータが作れると思って作った public


Slide 19

Slide 19 text

spool
 ● テスト用途の Spanner データベースを効率的に使うためのツール github 
 Motivation
 ● 開発当時(2018年7月頃)Spanner にはエミュレータがなかった
 ● テスト時に毎回データベースを作成するのは時間がかかる
 ○ 同時利用やスキーマ変更のことも考えながら適当に使いまわしたい
 ● 不要になったものは適宜消しておきたい
 ○ リソースの無駄
 ○ 1つのインスタンスに100個までしかデータベースをつくれない public


Slide 20

Slide 20 text

wrench
 ● Spanner 用データベーススキーママイグレーションツール github 
 
 Motivation
 ● Spanner はスキーマの仕様に既存のクラシカルな RDB と互換性がなく、
 専用のツールが必要だった
 public


Slide 21

Slide 21 text

yo
 ● xo の Spanner 対応版 github 
 
 Motivation
 ● 既にMySQLでxoを使っており、Spanner に移行する際に同じ機能性の
 ものがほしかった
 ● xoは当時 Spanner に対応していなかったので、forkして作った public


Slide 22

Slide 22 text

spanner-autoscaler
 ● SpannerのNodeを負荷に応じて自動的に増減するための Kubernetes Operator github 
 
 
 Motivation
 ● 日中と深夜など時間帯毎にトラフィック量が異なるので、SpannerのNode数を時 間帯や負荷に応じて変更したいという要望が多くあった
 ● 今までは手動でNode数を調整していたが、最適化したかった
 ● 似たものが ecosystem版 であるが、 少し思想が違った
 ● KubernetesベースのCloud Spanner Autoscaler public


Slide 23

Slide 23 text

kazegusuri/grpcurl
 ● curl ライクに gRPC endpoint をたたけるCLI github
 ○ 当時 fullstorydev/grpcurl はまだ存在していなかったはずで、あとから気づい たら同じ名前で作られていた
 ○ 今は fullstorydev 版を推奨している
 Motivation
 ● gRPCのサービスをデプロイしたときに、疎通確認のため毎回Goで簡易の
 プログラムを書いていたがさすがに面倒だった
 ● 当時は公式のgrpc_cliもprotoを手元に用意しなければならず、もっと簡単にできな いか調べたところ gRPC Server Reflection を知り、これを使って proto なしで gRPC call ができるツールを作りたかった
 ● その後 protoreflect の改善が進んで reflection から proto を構築できる
 ようになったので作った public


Slide 24

Slide 24 text

kazegusuri/channelzcli
 ● gRPC channelz の情報を表示するCLIツール github
 Motivation
 ● gRPC channelz という仕組みが導入されて、デバッグにかなり便利そうだったので 作った
 ● channelz 自体にも コントリビューションした 
 ● channelz について public


Slide 25

Slide 25 text

grpc-http-proxy
 ● HTTP のリクエストを gRPC に変換するための proxy server
 Motivation
 ● OSS版の grpc-http-proxy のメンテナンスが滞っていて修正されていないバグが あった
 ● kubernetes-sigs/controller-runtime をベースに社内向けに作り直した
 ● 後々OSS版を新しいものに置き換える予定

Slide 26

Slide 26 text

おまけ: go-microservices-kit 
 ● Goでマイクロサービスを構築するのに使える便利なライブラリ集
 ○ HTTP Middleware, gRPC Interceptor, Logging/Monitoring/Instrumentation など に対する便利な API を提供
 ○ panic recoveryやloggingなどチーム間共通の課題を解決する API
 ○ Datadogのメトリクスやトレースを取るmiddlewareも提供し、メルペイではそれを SLIとして利用している


Slide 27

Slide 27 text

OSSとの関わり方
 ● チームメンバーが開発・管理しているOSSだけでもたくさんある
 ○ もちろん、今回紹介していないものもたくさんある
 ● 新規で作るだけでなく、利用している様々なOSSに貢献もしている
 ● OSSを使うだけではなく、貢献し、生み出すことを当たり前のように
 行う文化で開発している
 ● 会社としても、OSSへの貢献を後押ししてくれる 風土がある 
 ○ 体外的にも発信できるような形で調整してくれている

Slide 28

Slide 28 text

まとめ
 ● Engineering Productivity Team では社内の開発者向けに様々な
 サービス・ライブラリ・ツールを開発し、運用している
 ○ 開発して、使ってもらって、改善するところまでがセット
 
 
 ● 今日紹介した成果物を作ってきたメンバーと一緒に、開発体験を
 より良くするものを作りませんか?
 We’re Hiring !!


Slide 29

Slide 29 text

No content