【マイクロサービス】「メッセージブローカー」(AWSメッセージングサービス比較など）

メリット

例えば、稼働率99%のものを直列に3つ同期的に繋げたとしたら稼働率は97%に下がってしまいます。

必要のないものはできるだけ非同期処理に置き換えるようにした方が稼働率は向上します。その際に使用するのがメッセージブローカーになります。

方式

キュー方式（pull方式）

メリット

処理量が多くても対応できる。（バッチ処理に対応できる。）

デメリット

コンシューマー側主導であり、取りに来られたタイミングが適切でなければラグ（待ち時間）が多少発生する。

Pub/Sub方式（Push方式）

メリット

常にコンシューマ側へプッシュするので通信がリアルタイムに近づけられる。

デメリット

コンシューマー側の許容できるリソース量を加味しないといけないので重い処理には向かない。

代表的なメッセージブローカー（インストールするもの）

Apache Kafka

高スループット。キュー方式のメッセージング。一番有名。

Apache ActiveMQ

Pub/Sub方式のメッセージング

RabbitMQ

AMQPに対応している。メッセージ、キュー、ルーティングに対応。

Redis

KVSの一種としてメッセージキューを提供している。（他と違いジャンルはメッセージというよりは、データベースではあるが。）

代表的なメッセージブローカー（マネージドサービス）

Queue Storage(Azure)

ストレージを使ったメッセージサービス

Service Bus(Azure)

Queue Storageより多機能

Pub/Sub(GCP)

Pub/Sub呼び出し。

Tasks(GCP)

相手を指定する呼び出し

AWSのメッセージングサービスの比較

SQS

Queueサービス、アプリケーションを統合するのに向いたサービス、KVS

Amazon MQ

Apache MQからの移行向け、ActiveMQ、RabbitMQのマネージドサービス

SNS(Pub/Sub)

Messagingサービス、アプリケーションを統合するのに向いたサービス

SNS(Mobile push)

Pinpointセグメントプッシュに置き換えも検討可能なのでSNSのPub/Sub機能に比べてあまり使われません。

SES

eメールに特化

Pinpoint

キャンペーン、効果測定、顧客利用状況把握、分析基盤として利用することが可能

MSK(AWS)

Kafkaのマネージドサービス

ElasticCache(AWS)

Redisのマネージドサービス

サーキットブレーカー

何度かエラーになっているサービスは即時エラーを返してくれるような仕組みです。なので、ユーザーはエラーだった場合はいろんなサービスを経由することなく即時応答結果を得ることができます。

有名なサーキットブレーカー

Istio

サービスメッシュ。Kubenetesの拡張。サーキットブレーカーにも多数の機能があります。

Hystrix

現在はメンテナンスされていないです。

resilience4j

Hystrixの後継サービスで、Javaで実装されているOSSです。

App Mesh(AWS)

サーキットブレーカー以外にカナリアデプロイにも対応しています。マネージドサービスなのでできるだけ使った方が良いでしょう。

サービスディスカバリ

マイクロサービスはサービスが動的に生成破棄されるのでアクセス先のIP、ポート番号がわからない現象が起きます。

サービスレジストリ

クライアントとサービス間に配置しておき、サービスとIPアドレスのマッピング表を保持させます。やっていることはDNSに似ています。

有名なサービスレポジトリ

Zookeper(Apach)

Hadoopで利用されている。CLIを実行する実装が必要になります。公式ライブラリはJavaとCに対応。

Consul(Hashi Corp)

エージェントを使ってサービスを監視する。Hashi Corpはteraformを作っている会社。

Eureka(Netflix)

ロードバランスとフェイルオーバー。AWS向け。

etcd

エトセディーと読む。Kubenetesで利用されている。Kubenetesはetcdを使ってアクセス先のポートを見つけることに成功しています。