Comparison between Golang microservices frameworks

Slide 1

Slide 1 text

GoのマイクロサービスFWについて tracerの観点から⽐比較する Gunosy Inc. 2016.03 @y_̲matsuwitter

Slide 2

Slide 2 text

2 ©Gunosy Inc. ⾃自⼰己紹介 n Gunosy Inc. – 開発本部執⾏行行役員 n 業務 – 開発全般のマネジメント – Go⾔言語布教係 – パフォーマンスチューニング – ISUCONとか好きです n 担当 – 右⼿手でiOS、左⼿手でAndroid – Web – Infrastructure(AWSのみ) n 最近の興味 – HTC Viveに感動した松本勇気 @y_̲matsuwitter

Slide 3

Slide 3 text

3 ©Gunosy Inc.

Slide 4

Slide 4 text

4 ©Gunosy Inc. 今⽇日の話 n マイクロサービスフレームワークを知る n kit, gizmo, micro n Tracerの観点から n 最後に Go⾔言語のマイクロサービスフレームワークの紹介

Slide 5

Slide 5 text

5 ©Gunosy Inc. マイクロサービスフレームワークを知る Microservices FWに触れることで必須な要素を知ることができる n 運⽤用にはモノリシックと⽐比べてより複雑な考え⽅方が必要 – ログ収集 – サービスディスカバリ – ロード・バランシング – プロトコル – メトリクス管理理 – APIクライアント提供 – …etc n 現状のチームではAWSに頼りつつ、こうした機能をまかなっている状況単にRPCでつなぐだけがマイクロサービスではない。 API Gateway Auth Content Log

Slide 6

Slide 6 text

6 ©Gunosy Inc. GoでのMicroserviceフレームワーク go-‐‑‒kit/kit gizmo micro n 3854star n 他⾔言語との協調も睨みつつ、⼤大規模な micorserviceの運⽤用をサポート n Pluggableで多くのプロトコルをサポート n Pub/subなどはサポートしていない n 1345star n NYタイムズが開発元 n Config, service, pubsubの3つを提供 n 軽量量、基本的な機能以外はミドルウェアを通じて実装する n 多数のrepoに分割 n microservicesに必要な多くの機能をmicro ⾃自⾝身で開発している n 最もfullstackなFW n Go以外の⾔言語との協調 n Dockerによる動作環境なども提供している Go⾔言語でのmicroservicesフレームワークはその他にもKiteなど登場 go-‐‑‒kit, gizmo, microの3つを⾒見見てみた

Slide 7

Slide 7 text

7 ©Gunosy Inc. Tracerに⾒見見る各フレームワークの考え⽅方 n Tracing packageにて提供 n 基本機能はZipkinへの tracingパラメタ送信 n ⾃自⾝身で定義したService を、zipkin packageに annotation付けてもらう形式 kit n Tracer機能は持たない n Readmeによれば、 middlewareとして⾃自⾝身で作成・追加するとのこと n 軽量量なライブラリであることがわかる gizmo n Micro⾃自⾝身がtrace-‐‑‒srv を持ち各サービスから投げる n 各サービスはgo-‐‑‒ platform/traceという⼦子パッケージを利利⽤用 n KafkaなどのBrokerを間で利利⽤用する n “Full-‐‑‒stack!!!” micro フレームワークごとに⽤用意しているレイヤーが異異なっている Tracer = 障害発⽣生時にどういった経路路のアクセスがあったか追跡するもの

Slide 8

Slide 8 text

8 ©Gunosy Inc. 最後に GoのMicroservicesフレームワークからエッセンスを汲み取ろう Microservicesは銀の弾丸ではない、モノリシックとの間で悩もう Microservicesにおいて考えることグノシーでのmicroservicesの現状 n 複雑なサービス依存を管理理する⽅方法 – 多くのGo製フレームワークから学ぶことができる n 本当にサービスを分割するべきか – 登場するドメインが少ないシステムでモノリシックから移⾏行行する必要はない n 多数のシステムから単⼀一のデータを触る際の拘束具としてのサービス分割 n Opsworksの運⽤用が確⽴立立しているゆえの⼤大量量のサービス管理理 n より適切切な解を模索索している