マイクロサービスアーキテクチャ——分割の利点とその代償

読了時間: 約9分｜ 文字数: 約3,200字

Netflix が 2009年にモノリスからマイクロサービスへ移行した事例は、業界に大きな影響を与えた。しかし、Netflix がマイクロサービスを必要としたのは、数億人のユーザーに99.99%の可用性を提供するためだ。あなたのプロジェクトが同じ状況にあるとは限らない。

モノリスとマイクロサービス

すべての機能が1つのプロセスとして動作する。デバッグが容易、トランザクション管理がシンプル、テストが書きやすい。

ビジネスドメインに沿って分割された小さなサービスの集合。各サービスは独立してデプロイ可能で、独自のデータストアを持つ。

各サービスは1つのビジネス機能を担当する。「このサービスが何をするか」を1文で説明できないなら、分割が不適切だ。

DDD の概念。各サービスは自身のドメインモデルを持ち、外部とは API で通信する。

各サービスは自身のデータベースを所有する。他のサービスの DB に直接アクセスすることは禁止。

シンプルだが、呼び出し先がダウンすると呼び出し元もブロックされる。サーキットブレーカーの実装が必要。

サービス間の結合度が低い。Kafka や RabbitMQ を介してメッセージをやり取りする。

サービスがイベントを発行し、興味のあるサービスが購読する。新しいサービスの追加が、既存サービスの変更なしにできる。

複数サービスにまたがる ACID 保証は事実上不可能。Saga パターンで補償トランザクションを使う。

Consul や Kubernetes の DNS でサービスを動的に発見する。

分散トレーシング、集約ログ、メトリクスの3本柱が必要。

分割してよい兆候: チーム間の調整コストがデプロイを遅延させている、特定の機能だけスケールしたい。

分割すべきでない兆候: チームが10人以下、ドメインの境界がまだ見えていない、運用基盤が未整備。

マイクロサービスは技術的な問題ではなく組織的な問題を解決するアーキテクチャだ。その代償を払う理由があるかどうかが、導入判断の本質だ。

免責事項 — 掲載情報は執筆時点のものです。料金・機能は変更される場合があります。最新情報は各公式サイトをご確認ください。