Files
2nd/10_Wiki/Topics/Architecture/마이크로서비스 아키텍처의 의존성 관리.md
T
2026-05-10 22:08:15 +09:00

5.5 KiB

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score verification_status tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0508-마이크로서비스-아키텍처의-의존성-관리 마이크로서비스 아키텍처의 의존성 관리 10_Wiki/Topics verified self
Microservice Dependency Management
Service Dependencies
MSA 의존성
none A 0.9 applied
microservices
architecture
dependency-management
distributed-systems
2026-05-10 pending
language framework
Go gRPC/Kubernetes

마이크로서비스 아키텍처의 의존성 관리

매 한 줄

"매 service 간 coupling 의 minimize, 매 explicit contract 의 enforce.". 매 monolith 의 internal call 의 network call 의 transform 의 후, 매 transitive dependency · version skew · cascading failure 의 새로운 challenge 의 emerge. 2026 modern stack 은 매 OpenAPI/Protobuf contract + service mesh (Istio/Linkerd) + 매 SBOM-driven dependency tracking 의 combine.

매 핵심

매 dependency 의 종류

  • Build-time: 매 shared library 의 dependency (avoid — leads to coordinated deploys).
  • Runtime sync: 매 HTTP/gRPC call 의 직접 의존 (latency · failure propagation).
  • Runtime async: 매 event/queue 의 통한 loose coupling (Kafka, NATS).
  • Data: 매 shared DB schema 의 의존 (anti-pattern — own your data).

매 핵심 원칙

  • Bounded context: 매 서비스 의 own 의 data + 매 logic 의 own.
  • Explicit contract: 매 OpenAPI/gRPC schema 의 source-of-truth.
  • Backward compatibility: 매 N-2 version 의 support.
  • Failure isolation: 매 circuit breaker · timeout · bulkhead.

매 응용

  1. 매 dependency graph 의 visualize (Backstage, Grafana service map).
  2. 매 contract testing 의 CI integration (Pact, Schemathesis).
  3. 매 chaos engineering 의 통한 cascading failure 의 test.

💻 패턴

Circuit Breaker (Go, gobreaker)

import "github.com/sony/gobreaker"

cb := gobreaker.NewCircuitBreaker(gobreaker.Settings{
    Name:        "payment-service",
    MaxRequests: 3,
    Interval:    60 * time.Second,
    Timeout:     30 * time.Second,
    ReadyToTrip: func(c gobreaker.Counts) bool {
        return c.ConsecutiveFailures > 5
    },
})

result, err := cb.Execute(func() (interface{}, error) {
    return paymentClient.Charge(ctx, req)
})

gRPC contract via Protobuf

syntax = "proto3";
package payment.v1;

service PaymentService {
  rpc Charge(ChargeRequest) returns (ChargeResponse);
}

message ChargeRequest {
  string order_id = 1;
  int64 amount_cents = 2;
  string currency = 3;
}

Pact consumer-driven contract test

import { PactV3 } from "@pact-foundation/pact";

const provider = new PactV3({ consumer: "checkout", provider: "payment" });

provider
  .uponReceiving("a charge request")
  .withRequest({ method: "POST", path: "/v1/charge", body: { amount: 1000 } })
  .willRespondWith({ status: 200, body: { id: "ch_123", status: "ok" } });

Async event via Kafka (decouple)

producer.Send(&kafka.Message{
    Topic: "order.placed.v1",
    Value: marshal(OrderPlaced{ID: orderID, Items: items}),
})
// payment, inventory, notification 의 own pace 의 consume.

Service mesh policy (Istio)

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  hosts: [payment]
  http:
  - timeout: 2s
    retries:
      attempts: 3
      perTryTimeout: 500ms
      retryOn: 5xx,reset,connect-failure

Dependency graph extraction

# Backstage catalog scan + 매 OpenTelemetry trace 의 통한 actual call graph
otel-cli export --format=json | jq '.spans[] | {service, downstream}'

SBOM for transitive deps

syft packages dir:. -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high

매 결정 기준

상황 Approach
Strong consistency 의 required Sync gRPC + saga compensation
매 latency-sensitive read Sync + cache (Redis)
매 cross-service workflow Async event + saga orchestrator (Temporal)
Shared reference data Read replica or 매 cached projection
Tight build coupling Refactor — extract 매 shared concept 의 own service

기본값: 매 async event-driven + 매 contract testing + 매 service mesh resilience.

🔗 Graph

🤖 LLM 활용

언제: 매 service decomposition 의 design, 매 dependency graph 의 review, 매 contract evolution 의 plan. 언제 X: 매 small monolith — 매 premature decomposition 의 cost > benefit.

안티패턴

  • Distributed monolith: 매 service 의 split 의 했지만 매 deploy 의 still coordinated.
  • Shared DB: 매 두 service 가 same table 의 write — coupling worst case.
  • Chatty API: 매 single user action 의 N개 service call 의 fan-out.
  • No timeout: 매 default infinite timeout — cascading hang.
  • Synchronous chain: A → B → C → D 매 single failure 의 entire chain 의 break.

🧪 검증 / 중복

  • Verified (Sam Newman Building Microservices 2nd ed, CNCF service mesh landscape 2026).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — dependency types, contract testing, mesh resilience patterns