Node에서 마이크로서비스를 구축할 때 무엇을 고려해야 하나요?

Question

Accepted Answer

**마이크로서비스**는 애플리케이션을 작고 독립적으로 배포 가능한 서비스들로 분할하며, 각각 특정 도메인을 소유하고 네트워크를 통해 통신합니다. Node의 경량적이고 빠른 시작 특성이 잘 맞지만, 이 아키텍처는 계획해야 할 분산 시스템 복잡성을 도입합니다.

## 모놀리스 vs 마이크로서비스

```text
Monolith:      one codebase/deployment — simple to build, harder to scale teams
Microservices: many small services — independent deploy/scale, but distributed complexity
```

마이크로서비스는 프로세스 내 단순성을 운영 유연성과 맞바꿉니다. 독립적인 확장/배포가 진정으로 필요하거나 여러 팀이 있을 때만 가치가 있습니다.

## 서비스 간 통신

```text
Synchronous:  REST / gRPC — direct request/response (simple, but tight coupling + cascading failures)
Asynchronous: message queues (RabbitMQ, Kafka) — events, decoupled, resilient
```

```js
// async/event-driven decouples services — a service publishes an event;
// others react without the publisher knowing/waiting for them
await queue.publish("order.created", { orderId: 123 });
// the email service, inventory service, etc. each consume it independently
```

가능한 한 분리와 복원력을 위해 **비동기 메시징**을 선호하세요. 동기 호출은 더 간단하지만 강한 결합과 실패 연쇄(cascade)를 만듭니다.

## 반드시 다뤄야 할 핵심 고려사항

```text
✓ Service discovery / API gateway — how services find each other & route external traffic
✓ Data ownership — each service owns its OWN database (no shared DB) → loose coupling
✓ Resilience — timeouts, retries, circuit breakers (a down service shouldn't cascade)
✓ Distributed tracing & centralized logging — debug a request across many services
✓ Eventual consistency — no cross-service transactions; use sagas / events
✓ Authentication — propagate identity (JWT) across service calls
✓ Idempotency — retried messages shouldn't double-process
```

## 복원력 예: circuit breaker

```js
// stop hammering a failing dependency; fail fast and recover gracefully
const breaker = new CircuitBreaker(callPaymentService, { timeout: 3000, errorThreshold: 50 });
breaker.fallback(() => ({ status: "queued" })); // degrade gracefully when it's down
```

## 트레이드오프에 대한 솔직함

```text
Microservices add real complexity: network failures, distributed debugging, data
consistency, deployment orchestration, more infrastructure. Many apps are better
as a well-structured monolith. Adopt microservices for specific needs, not by default.
```

## 왜 중요한가

마이크로서비스는 상당한 트레이드오프를 동반하는 주요 아키텍처 선택입니다.

Node가 잘 맞지만(경량, 빠른 시작), 어려운 부분은 코드가 아니라 **분산 시스템 고려사항**입니다. 서비스 간 통신(분리를 위한 비동기 메시징 선호), 독립적인 데이터 소유, 복원력(연쇄 실패 방지를 위한 타임아웃/재시도/circuit breaker), 관측 가능성(서비스 간 추적/로깅), 최종 일관성(eventual consistency)입니다.

이들을 이해하는 것 — 그리고 마이크로서비스가 많은 애플리케이션에 필요 없는 복잡성을 더한다는(좋은 모놀리스가 종종 더 낫다는) 솔직한 현실 — 이 건전한 아키텍처 결정과 유행하는 패턴을 맹목적으로 따르는 것을 구분합니다.