【マイクロサービス】設計（通信、APIゲートウェイ、テスト、リリース手法、正常性確認、可観測性）

設計：サービス間通信

マイクロサービスならサービス間の通信の手法を考える必要性が発生する。

数の分類

• 1:1
• 1:多

待ち受け方の分類

• 同期通信
• 非同期通信

マッピング表

	1:1	1:多
同期通信	REST、gRPC	なし
非同期通信	バッチ	メッセージブローカー、DB共有

REST

メリット

• どの言語でもサポートしている。
• ツールが多い。

デメリット

動詞の種類に限りがある。

1リクエストで複数リソース操作ができない。

あくまで1リソースに対して1URLになる。

バッファリングなしに直接操作するため可用性が下がる。

gRPC

メリット

• バイナリ+HTTP2で高速通信

デメリット

• 古い環境だと対応していない。
• 通信がバイナリなので監視が難しい。
• swiftなど対応してない言語がある。

バッチ

メリット

• 非同期にまとめて実行できる。

デメリット

• 頻度を上げるとサーバーサイドの負荷になるので実行は夜間など負荷が低い時に限られる。
• 反映まで時間がかかる。

メッセージブローカー

非同期にメッセージを交換する仕組み。専用ミドルウェアを使います。確実に後続サービスに通知を行ってくれます。

方式

キュー方式

貯めておく方式

Pub/Sub方式

パブリッシャーがプッシュする方式

メリット

• 疎結合になる。
• メッセージのバッファリングができる。

デメリット

• パフォーマンスがボトルネックになる危険性がある。
• 単一障害点になる可能性がある。
• 運用複雑度が上がる。

DB共有

基本的にはマイクロサービスではアンチパターンになります。なぜならマイクロサービスの考え方としてDBのデータを含めてサービスとして独立させるという考え方のためです。

メリット

• 大量データの移行が必要ない。
• データ変更が即時反映される。

デメリット

• データ変更に対する影響が広い。

外部公開

アプリ設計

データ整合性

セキュリティ

APIゲートウェイ

マイクロサービス化している課題の一つに複数サービスに分かれていると「あるサービスはアクセスさせて」、「あるサービスはアクセスさせない」など認証認可を一律で行いたいみたいな課題が出てきます。そこで登場するのが「APIゲートウェイ」です。サービスの入り口に関しては共通化してしまいましょうという考え方になります。

代表的なAPIゲートウェイ製品

Kong

一番有名な製品。OSS。Nginx上のLuaで動作。

Zuul(Netflix)

OSS。Javaで実装されている。

Tyk

たいくとよむ。OSS。Goで実装されている。軽量。高速。スケーラブル。

Apigee(Google Cloud)

クロスクラウドでAPI管理できる。

API Gateway(AWS)

フルマネージドサービス。認証認可などは別途LambdaやCognitoを使う。

用途

主に以下の用途で用いられます。

APIのエンドポイントの統一

認証認可

まずは、APIゲートウェイで認証を行い、マイクロサービスの各サービスで認可を行うようにする。という使い方をします。そうすることで統一的な認証認可の仕組みを導入することが可能になります。

認可を行いたい各サービスにOAuthサーバーを入れておき、APIゲートウェイをクライアントとしてアクセスしてもらいます。

設計：テスト

単体テスト

各サービス内のクラスのみで実施するテストです。（自動テスト）

課題

モックやスタブが大量に必要になってくる。

どうしても各サービスとの連携ができないのでモック化が増えます。基本的にはツールを利用して対応します。

• OpenAPI
• Mockito
• nock

テストデータの初期化が都度必要

コンテナを利用して対応します。テストを実行する都度コンテナを入れ替えることでテストデータを初期化してあげます。

• Docker
• cri-o
• OpenShift

結合テスト

依存関係のあるサービスのみを対象にテストします。

受け入れテスト

関連サービスを全て結合してテストします。よくあるウォーターフォールの発注側の会社内でのテストではなく、開発しているサービスが現状動作しているマイクロサービスのサービス群に受け入れられるかのテストになります。

E2Eテスト

全てのサービスを連携させてEnd To Endでテストします。ここがウォーターフォールで言うところの「受け入れテスト」に近いイメージになります。

結合テスト以降の課題

リリース物が増えるとどうしても手動ではやりきれなくなる。CI/CDを導入して自動デプロイ、自動リリースができるようにします。

• Jekins
• CircleCI

デプロイ/リリース

リリース手法の種類

リリース方法	切り替え台数	ダウンタイム
一括リリース	全台	(デプロイ方法次第）
カナリアリリース	一部	ほぼゼロ

一括リリース

ユーザー全員にいきなり公開するために使われる手法です。

カナリアリリース

いきなりユーザー全員に公開するのではなく限られた人にだけリリースしてフィードバックを受けるために使用します。

ユースケース

現状と大きく異なるようなUI/UXの効果を試したい場合など

CI/CDパイプライン

サービス正常性確認

正常性確認用のAPIを作成する。

エンドポイントのURLは「/health」、「/hc」などにしておけば良いでしょう。

正常であればレスポンスに200を返し、異常であれば500を返すようにします。（リクエストボディの中には正常性情報を埋め込まずあくまでステータスコードで確認できるようにするのが一般的です。）

チェック内容

アプリ自体が200を返すか。

DBにアクセスできるか。

以下のようなSQLを実行すれば良いでしょう。

可観測性

マイクロサービスではたくさんサービスがあるのでどのサービスが問題になっているのかの障害発生箇所などが特定しずらいです。

複雑なシステムを横断的に監視できるようにするために三つのポイントがあります。

項目	説明
ログ収集	各サービスで発生するイベントの記録。モノリシックなシステムでもよく出てくる概念です。
メトリクス	各サービスの定量数値情報の記録。長期的な経過から問題になりそうか判断する。モノリシックなシステムでもよく出てくる概念です。
トレーシング	リクエストに対する各サービス処理を記述

ログ収集

コンテナ化するとコンテナの破棄と生成を繰り返すのでログが消える可能性がある。なので、ログを一箇所に集約、永続化させることになります。

ログ送信エージェント

通信できないとロストするサービスが多い場合はログのバッファリングも検討します。

ログ収集

ビジュアライズ

ログ収集によく使われるツール

S3

アカツキではアクセスログ収集に使っている。

ElasticSearch Kibana

ログ収集、ビジュアライズができる。オンプレミスから使われるツール。ElasticSearchで完結できる構成。

Fluentd

ログ送信ができる。CNCF、ログ回収、フィルター、送信など各処理をプラグイン実行でき、送信時のバッファリング機能などを持っていたりして柔軟性が高いツール。

Prometheus Grafana

ログ送信、収集、ビジュアライズができる。Kubenetesとの統合がしやすい。製品自体の管理ができる。

Datadog

ログ送信、収集、ビジュアライズができる。SaaS。ログ収集、分析ができる。アカツキではミドルウェアのエラーログだけフィルタして溜めている。

CloudWatch Logs(AWS)

アカツキではアプリケーションのエラーログだけフィルタして溜めている。

Log Monitor(Azure)

Cloud Logging(GCP)

メトリクス収集

CPU使用率、メモリ使用率などです。ログ収集と同じく一箇所に収集していきます。よく使われるツールはログ収集のツールとほぼ同じです。

分散トレーシング

マイクロサービスでユーザーがどの経路を通ったか追跡したい場合があります。

ユーザーがどの経路をたどりどこで止まったのかを把握できて障害対応に活用することが可能です。

Trace

リクエスト全体。TraceIDによって特定します。

Span

各サービスの処理時間。必ずTraceの中にSpanは複数存在する関係性になります。SpanIDによって特定します。また、呼び出し元はParent SpanIDによって特定します。

OpenTelemetry

TraceやSpanなどを定義しておく情報。OpenTracingや、OpenCensusが元となった仕様。

代表的な分散トレーシングのツール

Zipkin

一番有名。Java実装。GoogleのZipperを参考にしてTwitterが作ったOSS。各言語の計測ライブラリがある。

Jaeger

Go言語実装。OpenTracing互換。各言語の計測ライブラリがある。

X-Ray

AWS純正の分散トレーシング。

サービスメッシュとは？

サービスとは別に外付けとして実装します。なので言語や環境には依存しないです。

外付け機能の例

kubenetesにおける「サイドカー」などがあります。

代表的なサービスメッシュ

lstio(Google、IBM、Lyft)

一番有名。高機能、YAML管理、Kubenetesのサイドカーとして自動導入できる。（というか、Kubenetes専用みたいな感じ）

Linkerd

利用実績が多い。(Expedia、Cisco webex、Walmartなど）

Conduit

Linkerd2.0へ吸収

Consul

エージェントを使ってサービス監視を行える。