「ArmeriaとCentral Dogmaから学ぶ、マイクロサービスに必要な機能」というタイトルで発表してきた #edayfuk
ちょっと前になりますが、FUKUOKA Engineers Day 2019 ~Summer~というイベントで、
「ArmeriaとCentral Dogmaから学ぶ、マイクロサービスに必要な機能」というタイトルで発表してきました。
- イベントページ:
FUKUOKA Engineers Day 2019 ~Summer~ - クラスメソッド株式会社さんによるまとめ:
[全レポートまとめ] 福岡のエンジニアの大文化祭 FUKUOKA Engineers Day 2019 ~Summer~ を開催しました #edayfuk
福岡には沢山のコミュニティが存在していて、コミュニティ間のコミュニケーションも活発で非常に盛り上がっています。
今回のイベントは全部のコミュニティが参加されてないですが(枠に入りきれないくらい沢山のコミュニティがあります)、まとめ記事を読んでもらうと盛り上がりを感じてもらえると思います。
主催者の皆さん、ありがとうございました!
イベントとても楽しかったです。
僕の発表資料はこちらです。
マイクロサービスの話題や事例をよく聞くようになって久しいですが、今回はSREコミュニティ枠での登壇という事で、
「サービスReliabilityの視点からマイクロサービスに必要な機能を考えてみる」というテーマで発表しました。
参考資料
まず、以下の3つを参考にして、キーワードをいくつかピックアップしてみました。
- 実践マイクロサービス ─ コンポーネント分割やトラブル回避の考え方をLINEの導入事例に学ぶ
- RxJava 2とArmeriaでマイクロサービスを非同期化してみた
- Envoy Proxy - Learn Envoy
最初の2つの記事では、
- なぜLINEでマイクロサービスが導入されたのか
- 分割の粒度をどう決めていくか?
- マイクロサービスアーキテクチャ運用の注意点
- なぜ非同期APIでマイクロサービスを構築するのか?
といった内容がまとめられています。
とても良い記事ですのでマイクロサービスに興味があればぜひ読んでみてください。
そして3つ目のページは、Service meshのEnvoyの公式サイトです。
Envoyのページからがピックアップしたキーワードは以下です。
- Service Discovery
- マイクロサービスに限った話ではありませんが、サービスのスケールアウトなどでリクエスト先が動的に変わるため、それを解決する必要がある
- Circuit Breaker
- 一部のマイクロサービスで障害が発生した時に、ドミノ倒し的に広範囲のサービス障害に発展する事を防ぎ、サービスのGraceful Degradationを可能にする
- Distributed tracing
- マイクロサービスでは複数のサービスが繋がるので、どこでどのくらいの時間が掛かっているか確認するための分散トレーシング。※New RelicなどのAPMではなくAPI単位
- Metrics
- メトリクスは説明不要だと思います。メトリクスの重要性はマイクロサービスに限った話ではありませんね
Distributed tracingやMetricsはライブラリを導入すれば実現できますが、Circuit BreakerはEnvoy/IstioなどのService meshやCircuit Breaker機能を持っているフレームワーク(後述するArmeriaは持っています)を導入する必要があるので、“マイクロサービスでサービスを構築しているけどCircuit Breakerは無い"というサービスは結構あるのではないでしょうか?
マイクロサービスではCircuit Breaker重要な概念の1つです。
Armeria入門
ArmeriaはLINE社がOSSとして開発しているJavaのRPCフレームワークで、LINEのサービスで実際に使われています。
公式サイト: https://line.github.io/armeria/
主な特徴は以下になります。
- RPC(gRPC, Thrift)やREST APIを実装する事が出来る
- 非同期
- Reactive Streams (RxJava2, Project Reactor)サポート
- Event Loopを使ったNon blocking I/Oで処理するので、必要なサーバリソースを抑える事が出来る
- ThriftとREST APIでもHTTP/2で通信が出来る
- マイクロサービスで必要となる機能を持っている
- この記事の上の方でEnvoyのページからピックアップした機能(Service Discovery, Circuit Breaker, Distributed tracing, Metrics)は持っています
- Spring Bootインテグレーション
- etc
Central Dogma入門
Central DogmaはLINE社がOSSとして開発している設定管理リポジトリツールで、LINEのサービスで実際に使われています。
Spring Cloud Configみたいなものだと思ってもらって良いと思います。(僕はSpring Cloud Configは使った事ないので細かい事はわかってないですが)
公式サイト: https://line.github.io/centraldogma/
主な特徴は以下になります。
- バックエンドにGitを採用
- ZooKeeperによるHA構成が可能
- 外部のGitリポジトリ(GitHubなど)とのミラーリングが可能
- アプリケーションやコンテナイメージの再ビルドやデプロイ無しで設定の動的変更ができる
- アプリケーションからCentral Dogmaをwatchすると、Central Dogmaで管理されている設定が変更されたら通知を受け取る事が可能
- JavaとGolangのクライアントライブラリがある
例えば、以下のユースケースが考えられます。
- APIサーバリスト (Service Discovery)
- Rate limit設定
- ブラックリスト
- A/Bテスト
- etc
サンプルアプリケーション
発表の最後に、サンプルアプリケーションを使ってCircuit Breakerのデモを行いました。
ソース: https://github.com/matsumana/armeria-sandbox
k8sにデプロイ出来るようにしてあります。
いくつかのアプリケーションとCentral Dogma、Zipkin、Prometheusがデプロイされます。
サンプルとして以下が実装してあります。実際に動くArmeriaやCentral Dogmaのサンプルとしても参考になると思います。
- DocService (Armeriaが持っているSwaggerみたいな機能です)
- gRPC, Thrift, REST API
- Retrofit integration
- RxJava 2
- Spring Boot integration
- Zipkin integration
- Throttling (Rate limit)
- Automatic retry
- Circuit Breaker
- Client-side load balancing
- Central Dogma integration
概要図:
まとめ
サービスReliabilityの視点からマイクロサービスに必要な機能を考えてみました。
色々と考慮するべき点は多いと思います。
あと、ArmeriaとCentral Dogmaぜひ試してみてください〜