Node で microservices を構築する際に何を考慮すべきですか？

Question

Accepted Answer

**microservices**（マイクロサービス）は、アプリケーションを独立してデプロイ可能な小さなサービスに分割し、それぞれが特定のドメインを所有してネットワーク越しに通信するアーキテクチャです。Node の軽量で起動が速い特性はこれによく適していますが、このアーキテクチャは計画して対処すべき分散システムの複雑さをもたらします。

## モノリス vs microservices

```text
モノリス:      単一のコードベース/デプロイ — 構築は単純だが、チームのスケールは難しい
microservices: 多数の小さなサービス — 独立したデプロイ/スケールが可能だが、分散の複雑さがある
```

microservices はプロセス内の単純さを運用上の柔軟性と引き換えにします。本当に独立したスケーリング/デプロイが必要な場合や、複数のチームがいる場合にのみ価値があります。

## サービス間の通信

```text
同期:    REST / gRPC — 直接のリクエスト/レスポンス（単純だが密結合 + 連鎖的な障害）
非同期:  メッセージキュー（RabbitMQ, Kafka）— イベント、疎結合、回復力がある
```

```js
// 非同期/イベント駆動はサービスを疎結合にする — サービスがイベントを発行し、
// 他のサービスは発行側が知ったり待ったりすることなく反応する
await queue.publish("order.created", { orderId: 123 });
// email service、inventory service などがそれぞれ独立して消費する
```

可能な限り、疎結合と回復力のために**非同期メッセージング**を優先しましょう。同期呼び出しは単純ですが、密結合と障害の連鎖を生みます。

## 対処すべき主要な関心事

```text
✓ サービスディスカバリ / API gateway — サービスが互いを見つける方法 & 外部トラフィックのルーティング
✓ データの所有権 — 各サービスは自身のデータベースを所有する（共有 DB なし）→ 疎結合
✓ 回復力 — timeout、retry、circuit breaker（停止したサービスが連鎖させない）
✓ 分散トレーシング & 集中ログ — 多数のサービスをまたぐリクエストをデバッグする
✓ 結果整合性 — サービスをまたぐトランザクションは不可；saga / イベントを使う
✓ 認証 — サービス呼び出し間で ID（JWT）を伝播する
✓ 冪等性 — リトライされたメッセージが二重処理されないようにする
```

## 回復力の例：circuit breaker

```js
// 失敗している依存先を叩き続けるのをやめる；fail fast し、グレースフルに回復する
const breaker = new CircuitBreaker(callPaymentService, { timeout: 3000, errorThreshold: 50 });
breaker.fallback(() => ({ status: "queued" })); // 停止時はグレースフルに機能を縮退させる
```

## トレードオフの正直な評価

```text
microservices は実際の複雑さを増します：ネットワーク障害、分散デバッグ、データの
一貫性、デプロイのオーケストレーション、より多くのインフラ。多くのアプリは、よく構造化された
モノリスのほうが優れています。デフォルトではなく、特定のニーズのために microservices を採用しましょう。
```

## なぜ重要なのか

microservices は重大なトレードオフを伴う大きなアーキテクチャ上の選択です。

Node はこれに適しています（軽量、起動が速い）が、難しい部分はコードではなく、**分散システムの関心事**です。サービス間通信（疎結合のため非同期メッセージングを優先）、独立したデータの所有権、回復力（連鎖的な障害を防ぐ timeout/retry/circuit breaker）、可観測性（サービスをまたぐトレーシング/ログ）、結果整合性などです。

これらを理解すること — そして microservices が多くのアプリには不要な複雑さを増すという正直な現実（良いモノリスのほうがしばしば優れている）を理解すること — が、健全なアーキテクチャ上の判断を、流行りのパターンの猿真似と分けるのです。