【閲覧注意】マイクロサービスが「デス・スター」化した件をMermaidで完全再現してみた

「マイクロサービスにすれば、開発速度が上がる」

そう信じていた時期が、私たちにもありました。

しかし、現実は甘くありません。サービスが増えるにつれ、依存関係は複雑化し、いつしか巨大な宇宙要塞**「デス・スター」**が誕生します。

[!WARNING] Death Star Architecture (死の星アーキテクチャ) 各サービスが密結合し、循環参照し、どこか一つが落ちれば全滅する状態。 誰も全体像を把握できないため、リファクタリングも不可能になる。

この記事では、そんな悪夢のようなアーキテクチャをMermaid.jsで再現し、なぜこうなってしまうのか、どうすれば防げるのかを解説します。

再現：これが「マイクロサービス・デス・スター」だ

百聞は一見にしかず。ある架空のEコマースシステムの末路をご覧ください。 （※心臓の弱い方はブラウザバックを推奨します）

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffcccc',
    'primaryTextColor': '#333',
    'primaryBorderColor': '#ff0000',
    'lineColor': '#ff0000',
    'secondaryColor': '#eee',
    'tertiaryColor': '#fff'
  }
}}%%
graph TD
    user((User)) --> CDN{CDN}
    CDN --> LB[Load Balancer]

    subgraph Frontend["Frontend Layer"]
        LB --> WebApp[Web App]
        LB --> MobileAPI[Mobile API]
        WebApp --> Auth[Auth Service]
        MobileAPI --> Auth
    end

    subgraph "Core Services"
        Auth --> UserDB[(User DB)]
        WebApp --> Catalogue[Catalogue]
        MobileAPI --> Catalogue
        Catalogue --> Inv[Inventory]
        Catalogue --> Recom[Recommendation]
        Recom --> BigData[Big Data Cluster]
    end

    subgraph "Order Processing (Chaos Zone)"
        WebApp --> Orchestrator[Order Orch]
        Orchestrator --> Pay[Payment]
        Pay --> Fraud[Fraud Check]
        Fraud --> Blacklist[(Blacklist)]

        Pay -- "OK" --> Ledger[Ledger]

        Orchestrator --> Logistics[Logistics]
        Logistics --> Warehouse[Warehouse]

        %% The Cycle of Death
        Warehouse --> Inv
        Inv -.-> Orchestrator
    end

    subgraph "Monitoring"
        LogAgent[Logging Agent] --> Datadog[Monitoring]
        Datadog --> PagerDuty[Alerting]
        PagerDuty -- "Wake up!" --> DevTeam((Dev Team))
    end

    %% Semantic Chaos Connections (Reduced)
    Recom -.-> Catalogue
    Fraud -.-> UserDB
    DevTeam -.-> WebApp

    style User fill:#fff,stroke:#333
    style DevTeam fill:#f00,stroke:#fff,color:#fff

    classDef chaos fill:#ffcccc,stroke:#d00,stroke-width:2px;
    class Orchestrator,Logistics,Inv,Warehouse chaos

…いかがでしょうか。 Catalogue から Inventory への依存、Orchestrator から Logistics への依存、そして Logistics からまた Inventory へ戻る依存。

これはまさに、「スパゲッティ・コード」の分散システム版です。

なぜこうなってしまうのか？

原因はシンプル。「境界線」が曖昧だからです。

モノリス（一枚岩）の時代は、関数呼び出し一つで済んでいた処理が、マイクロサービスではHTTP通信になります。そして、「とりあえずAPI叩けばいいや」という軽い気持ちで依存関係を増やしていくと、あっという間に蜘蛛の巣が出来上がります。

モノリス vs デス・スター

項目	🗿 モノリス (Monolith)	☠️ デス・スター (Death Star)
依存関係	コード内部（コンパイル時に検知可能）	ネットワーク越し（実行時まで不明）
障害の影響	プロセスごと落ちる	1つの遅延が全体に波及する（カスケード障害）
デバッグ	ブレークポイントで止めるだけ	分散トレーシングでログを追う地獄
デプロイ	遅いが安全	早いが、何が壊れるか分からない

[!TIP] アナロジーで言えば、モノリスは「大勢で一つの大部屋にいる会議」、マイクロサービスは「社員全員がリモートワークでSlackだけで会話している状態」です。 誰と誰が話しているか管理しないと、情報は錯綜し、誰も全体の意思決定ができなくなります。

解決策：可視化とオーナーシップ

このカオスを飼いならす唯一の方法は、**「地図」**を持つことです。

AmazonやNetflixのような成功企業は、この複雑なグラフをツールでリアルタイムに可視化し、**「このサービスは誰が責任を持つのか（オーナーシップ）」**を明確にしています。

1. 可視化する: Mermaid.jsのようなツール（または自動生成ツール）で、常に最新の依存関係を描画する。
2. 依存の方向を整理する: 循環参照（A→B→A）は絶対悪として排除する。
3. ドメインを分ける: お互いに干渉しない「境界づけられたコンテキスト (Bounded Context)」を作る。

結論：地図なき旅に出るな

Mermaid.jsを使えば、上記で示したような複雑な図も、テキストエディタだけで管理できます。

もしあなたのチームがマイクロサービスへの移行を検討しているなら、まずは**「将来のアーキテクチャ図」をMermaidで書いてみてください。 その線が少しでも絡まり合っているなら、それはデス・スターの設計図**かもしれません。

“Structure eats Strategy for breakfast.” （構造は戦略を朝食に平らげる）

参照・出典

• Amazon Prime Video’s move from Microservices to Monolith
• Microservices Death Star (Twitter/X)