概要
分割に意味がある場合にのみモノリスを分けます。多くはチーム同士が互いをブロックしている場合か、スケール特性が大きく異なる構成要素がある場合です。意味がないときはそう申し上げます。マイクロサービスは複雑さを移動させるだけで、消しはしません。
主なメリット
実際の境界で分ける
サービスは組織図ではなく業務ドメインに従います。そうでなければ分散モノリス、両方の悪いところ取りになります。
初日から可観測性を確保
分散トレーシング、相関の取れたログ、サービス単位のメトリクスを、本番リリース前に用意します。
必要な部分だけスケールさせる
決済とレポートはそれぞれ独立にリソースを得ます。まとめて増やす必要はありません。
進め方
- 01
現状把握
提案の前に、既存システムと制約、そして事業目標を整理します。
- 02
アーキテクチャ設計
構成・データモデル・連携点を設計します。決定は文書化し、場当たりにしません。
- 03
実装
短いイテレーションで納品。コードレビュー済みで、ステージング環境はいつでも確認できます。
- 04
テスト・QA
リリースごとに自動テストと性能・セキュリティ検証を実施します。
- 05
公開と運用
ロールバック計画とともに公開し、その後も監視と改善を継続します。
技術スタック
DockerKubernetesRabbitMQgRPCKafkaTraefikOpenTelemetry
ユースケース
リリースのたびに詰まるチーム
複数チームが単一のデプロイパイプラインを共有し、順番待ちになっている状態。
特定機能だけのトラフィック集中
画像処理やレポート生成がアプリ全体のリソースを奪ってしまう。
買収後のシステム統合
コードを完全に統合せずに、二つの製品を一つとして振る舞わせる。