분산 시스템 (Distributed System)
분산 시스템은 현대 IT 인프라의 근간을 이루는 핵심 기술로, 여러 노드가 협력하여 확장 가능하고 안정적인 서비스를 제공한다. CAP 정리, 합의 알고리즘, 복제 전략 등의 이론적 기반과 마이크로서비스, 컨테이너 오케스트레이션 등의 실무적 구현이 결합되어 있다. 일관성, 가용성, 분할 허용성 간의 트레이드오프를 관리하며 실무에서는 Netflix, Google 등의 대규모 시스템에서 활용된다.
배경
단일 시스템 구조의 한계
- 확장성 부족: 사용자 수, 데이터 양 증가에 따라 단일 서버의 처리 능력에 한계 발생.
- 단일 장애점 (SPOF): 하나의 장애가 전체 시스템 중단으로 이어짐.
- 장애 복구 지연: 장애 발생 시 전체 서비스 복구에 시간이 오래 걸림.
네트워크 기술의 발전
- 1960–70 년대: ARPANET, Ethernet, Email 등 네트워크 기술 발전으로 컴퓨터 간 통신 가능해짐.
- 분산 운영체제 연구: 1980–90 년대에 노드 간 자원 공유와 협업 개념이 본격적으로 연구됨.
애플리케이션 복잡도 및 규모 증가
- 클라우드 컴퓨팅 도입: 유연한 자원 확장과 온디맨드 처리 수요 증가.
- 글로벌 서비스 확산: 지리적으로 분산된 사용자에게 빠른 응답을 제공하기 위한 구조 필요.
- 빅데이터 등장: 단일 시스템으로는 감당할 수 없는 대규모 데이터 처리 필요.
비용 효율성 및 내결함성 요구
- 비용 절감: 고가의 고성능 서버 대신 저가의 범용 서버 다수 활용 가능.
- 내결함성 강화: 일부 노드 장애에도 시스템 전체가 지속적으로 동작 가능하도록 설계 필요.
목적 및 필요성
목적 (Goal) | 필요성 (Why it’s Needed) |
---|---|
** 확장성 (Scalability)** | 단일 서버는 트래픽, 데이터, 사용자 수 증가에 따른 수직 확장에 한계가 있음 → 수평 확장이 가능한 구조 필요 |
고가용성 (High Availability) | 서비스가 일부 컴포넌트 실패에도 중단되지 않고 지속되도록 하려면 단일 장애점을 제거하고 노드 이중화가 필요 |
내결함성 (Fault Tolerance) | 하드웨어나 소프트웨어 오류 발생 시 전체 시스템에 영향이 확산되지 않도록 장애 격리 및 자동 복구 메커니즘 필요 |
성능 향상 (Performance) | 병렬 처리를 통해 다수 요청을 동시에 빠르게 처리하고 응답 시간을 줄이기 위해 → 처리량 (throughput) 과 응답 속도 향상 필요 |
지리적 분산 (Geo Distribution) | 전 세계 사용자에게 빠른 서비스를 제공하기 위해 사용자와 가까운 지역에 노드를 분산 배치해야 함 |
** 비용 효율화 (Cost Efficiency)** | 고성능 단일 서버 대신 저비용 범용 서버 + 클라우드 자원을 활용하여 인프라 투자 및 운영비용을 절감할 수 있어야 함 |
유지보수 유연성 (Maintainability) | 일부 노드만 업데이트하거나 재배포할 수 있어야 전체 시스템 무중단 운영이 가능 → 민첩한 운영 및 빠른 롤아웃 필요 |
자원 공유 (Resource Pooling) | 컴퓨팅 자원, 저장소, 네트워크 등을 노드 간에 효율적으로 공유함으로써 인프라 활용률을 극대화하고 중복 투자를 방지해야 함 |
핵심 개념
개념 구분 | 개념명 | 설명 |
---|---|---|
1. 정의 | 분산 시스템 (Distributed System) | 네트워크로 연결된 여러 독립적인 노드들이 메시지를 주고받으며 하나의 시스템처럼 동작하는 구조. |
2. 구성 요소 | 노드 (Node) | 독립적인 실행 단위. 물리적 서버, VM, 컨테이너 등 포함. |
네트워크 통신 (Network Communication) | 노드 간 메시지 전달: RPC, REST, 메시지 큐, gRPC 등 활용. | |
미들웨어 (Middleware) | 이기종 시스템 간 통신을 추상화하여 상호운용성 제공. | |
3. 기본 특성 | 확장성 (Scalability) | 수평적/수직적 확장을 통해 시스템 용량 유연 조정 가능. |
가용성 (Availability) | 일부 노드 장애에도 서비스 지속 가능. | |
장애 허용성 (Fault Tolerance) | 실패 감지, 복제, 페일오버로 시스템 지속성 확보. | |
일관성 (Consistency) | 여러 노드에 저장된 데이터의 정합성 보장. | |
투명성 (Transparency) | 분산 구조를 사용자에게 숨기고 단일 시스템처럼 보이도록 설계. | |
4. 핵심 이론 | CAP 정리 (CAP Theorem) | 일관성 (Consistency), 가용성 (Availability), 분할 허용성 (Partition Tolerance) 중 2 개만 동시 보장 가능. |
일관성 모델 (Consistency Model) | 강한/최종/인과 일관성 등 다양한 정합성 보장 수준 존재. | |
합의 알고리즘 (Consensus Algorithm) | Paxos, Raft, PBFT 등 다수 노드 간 일관된 상태 유지 기법. | |
5. 데이터 처리 기법 | 복제 (Replication) | 동일 데이터를 다수 노드에 복사하여 가용성 및 성능 향상. |
샤딩 (Sharding) | 데이터 또는 작업을 노드 간에 분산 저장·처리. | |
6. 처리 특성 | 병렬성 & 동시성 (Parallelism & Concurrency) | 여러 작업을 동시에 병렬 처리함으로써 처리량 증가. |
7. 아키텍처 스타일 | 클라이언트 - 서버, P2P, 마이크로서비스 등 | 분산 시스템 설계 방식에 따른 다양한 아키텍처 존재. |
실무 연관성
도메인 | 관련 요소/기술 | 설명 |
---|---|---|
클라우드 인프라 | AWS, GCP, Azure | 대부분의 클라우드 플랫폼은 분산 시스템 위에 구축되어 있음. |
데이터베이스 | Cassandra, MongoDB, Google Spanner | 분산 저장, 샤딩, 복제를 통한 고가용성과 확장성 제공. |
메시징 시스템 | Kafka, RabbitMQ, NATS | 노드 간 비동기 통신 및 이벤트 전달을 위한 핵심 구성 요소. |
서비스 구조 | 마이크로서비스, SOA, API Gateway | 기능 분리를 통한 독립 배포 및 확장. |
오케스트레이션 | Docker, Kubernetes | 컨테이너 기반의 분산 애플리케이션 배포 및 스케줄링. |
장애 대응 | 로드밸런서, 페일오버, 헬스체크, 리더 선출 | 장애 허용성과 고가용성을 실현하기 위한 메커니즘. |
모니터링/로깅 | Prometheus, Grafana, ELK Stack | 분산 시스템 상태 및 이벤트의 가시화와 추적. |
서비스 디스커버리 | Consul, Eureka, etcd | 동적으로 위치 변경이 가능한 노드의 탐색 기능. |
분산 알고리즘 | Raft, Paxos, Gossip Protocol | 상태 동기화 및 장애 감지 등 분산 환경의 필수 알고리즘. |
주요 기능 및 역할
기능 영역 (Function Area) | 구체 기능 (Function / Mechanism) | 수행 역할 (Role / Objective) |
---|---|---|
1. 데이터 관리 | 데이터 샤딩 (Sharding) | 데이터 저장 분산 → 확장성 확보 (Scalability) |
데이터 복제 (Replication) | 다중 노드에 데이터 복사 → 고가용성 (High Availability) | |
일관성 모델 적용 (e.g., Strong, Eventual) | 데이터 정합성 유지 → 신뢰성 있는 읽기/쓰기 제공 | |
분산 트랜잭션 처리 (2PC, Paxos, Raft) | 다중 노드 간 정합성 보장 → 데이터 무결성 확보 | |
2. 통신 및 협업 | 메시지 전달 (Message Passing, RPC, gRPC) | 노드 간 작업 요청 및 협력 수행 → 시스템 구성 요소 통합 |
서비스 발견 (Service Discovery) | 동적 위치 탐색 → 시스템 동적 확장 및 장애 대응 | |
리더 선출 (Leader Election) | 조율 및 결정권 통합 → 일관된 시스템 운영 | |
3. 장애 감지 및 복구 | 하트비트 감시 (Heartbeat) | 노드 장애 실시간 감지 → 신속한 장애 인식 |
자동 페일오버 (Failover) | 장애 발생 시 백업 노드 전환 → 서비스 중단 최소화 | |
복제 로그 리플레이 (Log Replay) | 상태 복원 → 장애 전 상태로 롤백 가능 | |
4. 자원 관리 및 최적화 | 로드 밸런싱 (Load Balancing) | 요청 균등 분산 → 자원 활용 최적화 및 응답 지연 최소화 |
스케줄링 및 자원 할당 (Scheduling) | 클러스터 자원 효율 사용 → 고성능 유지 | |
5. 확장성 및 투명성 | 수평 확장 (Horizontal Scaling) | 노드 추가로 처리량 증가 → 탄력적 시스템 대응 |
위치/접근/장애 투명성 제공 | 사용자에게 단일 시스템처럼 보이도록 추상화 → UX 향상 | |
6. 미들웨어 통합 | 메시지 브로커 사용 (Kafka, RabbitMQ 등) | 느슨한 결합, 비동기 처리 → 시스템 유연성 및 모듈화 |
RPC 프레임워크 활용 (gRPC 등) | 인터페이스 간 통신 통합 → 상호운용성 확보 | |
7. 시스템 관측성 (Observability) | 분산 트레이싱 (OpenTelemetry, Jaeger) | 요청 흐름 추적 → 성능 병목 진단 |
메트릭 수집 (Prometheus, Grafana) | 시스템 상태 모니터링 → 자가 치유, 자동 확장 기반 | |
로깅 및 이벤트 수집 | 장애 분석 및 감사 → 안정성 향상 | |
8. 보안 및 접근 제어 | 인증/인가 (OAuth2, mTLS) | 권한 기반 접근 통제 → 무단 접근 방지 |
데이터 암호화 (TLS, 데이터 암호화 저장) | 데이터 보안 및 무결성 확보 → 규제 준수 및 안전성 보장 |
특징
자율성 (Autonomy)
- 각 노드는 독립적으로 실행되고, 자체적으로 운영/관리 가능
- 시스템 운영은 중앙 제어 없이 분산된 방식으로 이루어짐
- → 예시: 마이크로서비스 기반 시스템, P2P 네트워크
이질성 (Heterogeneity)
- 서로 다른 하드웨어, 운영체제, 프로그래밍 언어, 네트워크 프로토콜 등이 공존 가능
- 미들웨어나 API 게이트웨이 등을 통해 이질적인 구성 요소 간 상호 운용성 확보
- → 예시: Python 으로 구성된 서비스가 Node.js 서비스와 통신
확장성 & 탄력성 (Scalability & Elasticity)
- 수평 확장: 노드를 추가하여 처리 성능 향상
- 탄력성: 수요 변화에 따라 자원을 자동으로 증감 (Auto-scaling)
- → 예시: Kubernetes HPA, AWS Auto Scaling Group
투명성 (Transparency)
- 사용자는 분산 구조를 인지하지 못하고 단일 시스템처럼 인식
- 위치 투명성 (Location Transparency)
- 사용자는 리소스가 물리적으로 어디에 존재하는지 알 필요가 없다. 리소스의 위치에 상관없이 동일한 방식으로 접근할 수 있어야 한다.
- → 예:
http://service.local/data
가 실제로 어느 서버에 있는지 몰라도 사용 가능
- 장애 투명성 (Failure Transparency)
- 시스템에서 일부 노드나 서비스에 장애가 발생해도, 사용자는 이를 인식하지 못한다. 자동 복구나 리다이렉션을 통해 서비스는 지속적으로 제공된다.
- → 예: 한 노드 다운 시 다른 노드가 자동으로 요청을 처리
- 접근/접속 투명성 (Access Transparency)
- 서로 다른 접근 방식 (RPC, REST, 로컬 호출 등) 을 내부적으로 사용하더라도, 클라이언트는 동일한 방식으로 리소스에 접근할 수 있다.
- → 예: 로컬 파일이든 네트워크 파일이든 동일한 API 로 접근
- 복제 투명성 (Replication Transparency)
- 시스템 내에서 리소스가 여러 복제본으로 존재하더라도, 사용자 입장에서는 단일 자원처럼 보인다. 어떤 복제본이 사용되었는지는 사용자에게 보이지 않는다.
- → 예: 여러 DB 복제본 중 하나에서 읽더라도 사용자에겐 차이 없음
- 동시성 투명성 (Concurrency Transparency)
- 여러 사용자가 동시에 동일한 리소스에 접근해도, 시스템은 이를 적절히 조율하여 일관된 결과를 보장한다.
- → 예: 두 사용자가 같은 데이터를 수정해도 충돌 없이 처리됨
- 이주/이동 투명성 (Migration Transparency)
- 실행 중인 프로세스나 자원이 다른 위치로 이동하더라도, 사용자는 이를 전혀 인지할 수 없다.
- → 예: 가상 머신이나 컨테이너가 다른 서버로 이동해도 연결 유지
내결함성 (Fault Tolerance)
- 일부 노드나 네트워크 장애가 발생해도 시스템 전체가 동작
- 장애 감지, 리더 재선출, 복제, 페일오버 등 전략 활용
- → 예시: Raft 기반 리더 재선출, Cassandra 의 복제본 읽기
병렬성 & 동시성 (Parallelism & Concurrency)
- 다수의 노드가 동시에 작업을 수행하여 전체 처리량 (throughput) 을 높임
- 다중 사용자 요청을 동시에 처리하면서도 일관성 유지 필요
- → 적용 기술: 비동기 메시징, 멀티스레딩, 이벤트 루프, actor model 등
비결정성 (Nondeterminism)
- 네트워크 지연, 패킷 손실, 메시지 순서 변경, 장애 등으로 인해 예측 불가능한 상황이 발생 가능
- 프로그래머는 일관성/장애 허용 설계 고려 필요
- → 대응 전략: 재시도, 타임아웃, 순서 보장 메커니즘, 지연 허용 일관성 모델 등
부분 장애 (Partial Failure)
- 단일 장애가 아닌, 시스템 일부 컴포넌트만 실패하는 비완전 실패 모델
- → 전체 시스템 복구가 아니라 부분 복구 및 격리 전략 필요
- → 예시: Circuit Breaker, Bulkhead 패턴
모듈성 (Modularity)
- 각 구성 요소 (서비스, 노드, DB 등) 는 독립적으로 배포, 관리, 확장 가능
- → 시스템 유연성 및 테스트 용이성 향상
개방성 (Openness)
- 분산 시스템은 다양한 외부 시스템/서비스와 인터페이스를 통해 연동 가능
- 오픈 프로토콜 기반 설계 (REST, gRPC 등) 를 통해 확장 가능
핵심 원칙
투명성 원칙 (Transparency)
분산 시스템은 사용자에게 단일한 시스템처럼 보이도록 다양한 투명성을 제공해야 한다.
종류 | 설명 |
---|---|
접근 투명성 | 원격 자원을 로컬 자원처럼 동일한 방식으로 접근 가능해야 함 |
위치 투명성 | 자원이 물리적으로 어디에 존재하는지 숨김 |
복제 투명성 | 데이터가 복제되어 있더라도 단일 자원처럼 보이도록 보장 |
장애 투명성 | 일부 구성 요소의 실패가 사용자에게 감지되지 않음 |
확장 투명성 | 시스템 확장 시 사용자나 애플리케이션의 변경 없이 동작 지속 |
목적: 사용자 경험 향상, 시스템 복잡성 은닉, 인터페이스 일관성 유지
개방성 원칙 (Openness)
분산 시스템은 다양한 환경과 시스템이 상호작용 가능해야 하므로 개방적 구조를 가져야 함.
- 표준화된 인터페이스: REST, gRPC, GraphQL, OpenAPI 등
- 이식성 (Portability): 다양한 플랫폼 간의 실행 가능성 확보
- 상호 운용성 (Interoperability): 서로 다른 언어나 시스템 간의 원활한 통신
목적: 이기종 시스템 간 통합, 확장성 확보, 커뮤니티/생태계 연계
확장성 원칙 (Scalability)
분산 시스템은 성능 저하 없이 수평적 확장 (Horizontal Scaling) 을 지원해야 한다.
- 수평 확장 (Horizontal Scaling): 노드를 추가하여 시스템 용량 증가
- 성능 병목 최소화: 공유 자원 제거, 분산 처리 구조 설계
- 자원 관리 최적화: 오토스케일링, 캐시 전략, 로드 밸런싱 적용
목적: 대규모 트래픽 및 데이터 증가에 유연하게 대응
일관성 및 가용성 원칙 (Consistency & Availability)
CAP 정리 (CAP Theorem)
- Consistency (일관성): 모든 노드가 동일한 데이터를 반환해야 함
- Availability (가용성): 모든 요청에 응답이 있어야 함
- Partition Tolerance (분할 허용성): 네트워크 분할이 발생해도 시스템은 계속 동작해야 함
네트워크 분할 상황에서는 C 또는 A 중 하나는 희생해야 한다.
BASE 원칙 (Eventually Consistent Systems)
- Basically Available: 시스템은 항상 사용 가능
- Soft State: 상태는 시간이 지나면서 변경 가능
- Eventually Consistent: 일정 시간이 지나면 모든 복제본이 일관된 상태로 수렴
목적: 일관성과 가용성의 트레이드오프 관리 및 설계 의사결정 명확화
장애 허용 설계 원칙 (Fault-Tolerant Design)
- 실패를 전제로 한 설계: 장애가 발생할 수 있음을 전제로 시스템 구성
- 복제 (Replication): 데이터 및 서비스 중복 배치
- 리트라이/백오프: 실패 시 재시도 로직 및 대기 전략
- 리더 선출 (Leader Election): 합의 알고리즘 기반 장애 복구
- Circuit Breaker & Bulkhead: 장애 전파 방지 및 격리
목적: 시스템의 안정성과 연속성 확보
주요 원리
CAP 이론 (CAP Theorem)
분산 시스템에서 네트워크 분할 (Partition) 이 발생하는 경우, 세 가지 속성 중 두 가지만 동시에 보장할 수 있다는 이론:
- Consistency (일관성): 모든 노드가 동일한 데이터를 동시에 보여줌
- Availability (가용성): 모든 요청에 대해 항상 응답을 보장
- Partition Tolerance (분할 허용성): 네트워크 분할 상황에서도 시스템이 동작함
네트워크 분할 (P) 이 발생했을 때, 시스템은 Consistency와 Availability 중 하나를 포기해야 함.
실무 적용 예:
시스템 유형 | 보장 조합 | 예시 |
---|---|---|
CA 시스템 | 일관성 + 가용성 (분할 없음 가정) | RDBMS (단일 노드) |
CP 시스템 | 일관성 + 분할 허용성 | HDFS, Zookeeper, Spanner |
AP 시스템 | 가용성 + 분할 허용성 | Cassandra, DynamoDB, CouchDB |
PACELC 이론 (확장 이론)
CAP 이론의 확장으로, 분할이 발생하지 않을 때도 시스템은 지연 시간 (Latency) 과 일관성 (Consistency) 사이에서 트레이드오프를 겪는다는 것을 설명함.
적용 사례:
시스템 | PACELC 성향 | 설명 |
---|---|---|
Cassandra | PA/EL | 분할 발생 시 가용성 우선, 평상시 지연 우선 (튜너블 일관성) |
Google Spanner | PC/EC | 분할 발생 시 일관성 우선, 평상시에도 일관성 우선 |
DynamoDB | PA/EL | 상황에 따라 읽기/쓰기 일관성 선택 가능 |
일관성 모델 (Consistency Models)
주요 일관성 수준:
모델 | 정의 | 사용 예시 |
---|---|---|
Strong Consistency | 모든 읽기가 항상 최신 쓰기 이후의 값을 반환 | Spanner, etcd |
Linearizability | 강일관성 + 전체 시스템에서 단일 타임라인처럼 작동 | Zookeeper, Raft 기반 시스템 |
Sequential Consistency | 연산 순서는 유지되나 실제 시간과는 무관 | 일부 메모리 모델, Java memory model |
Eventual Consistency | 시간이 지나면 데이터가 일관된 상태로 수렴 | Cassandra, DynamoDB, S3 |
Causal Consistency | 인과 관계가 있는 연산 순서는 유지 | COPS, Orchestrated CRDTs |
- 실무에서는 Eventual 을 기반으로 " 요구 시 일관성 강화 (Tunable Consistency)" 전략이 자주 사용된다.
합의 알고리즘 (Consensus Algorithms)
목적:
- 여러 노드 간 상태 동기화 및 리더 선출을 통해 정합성과 안정성을 확보하는 데 사용됨.
알고리즘 | 특징 및 구조 | 사용처 |
---|---|---|
Paxos | 이론적으로 강력하지만 구현 복잡 (기본/멀티/패스트 변형 있음) | Chubby, Microsoft Azure Fabric 등 |
Raft | 리더 선출, 로그 복제, 안전성 구조화 → 구현 단순 | etcd, Consul, NATS, CockroachDB |
PBFT | 비잔틴 오류 (비정상 노드) 도 허용, n ≥ 3f+1 필요 | Hyperledger Fabric 등 |
ZAB | Zookeeper 에서 사용되는 Paxos 기반 알고리즘 | Apache Zookeeper |
CRDTs | 수학적 구조를 활용해 충돌 없이 병합 가능한 데이터 구조 | Edge 기반 저장소, Collaborative Editing |
Vector Clocks | 인과성 추적용 타임스탬프 모델 | Dynamo, Riak, Git |
핵심 시스템 원리
원리 | 설명 | 예시 또는 기술 |
---|---|---|
분산 처리 | 작업을 여러 노드에 나누어 병렬/비동기 처리 | Spark, Flink, Airflow DAG |
데이터 복제 | 데이터 가용성과 내결함성을 위해 여러 노드에 복제 저장 | Cassandra, Redis Sentinel |
메시징 기반 통신 | 노드 간 데이터 전달은 비동기 메시징 기반 구조 채택 | Kafka, RabbitMQ, gRPC |
장애 감지 및 복구 | 헬스체크, 리더 재선출, 로그 복원, 리트라이 등으로 복구 | K8s Probes, Raft, Circuit Breaker |
정합성 보장 구조 | 데이터 일관성 유지를 위한 모델 및 알고리즘 적용 | CRDT, Raft, 2PC |
작동 원리 및 방식
분산 시스템은 각 노드가 독립적으로 동작하면서, 네트워크를 통해 메시지를 주고받아 전체 시스템의 일관성과 가용성을 유지한다. 장애 발생 시 일부 노드가 복구 또는 대체되어 서비스가 지속된다.
graph TB A[클라이언트 요청] --> B[로드 밸런서] B --> C[서버 1] B --> D[서버 2] B --> E[서버 N] C --> F[데이터베이스 클러스터] D --> F E --> F F --> G[마스터 DB] F --> H[슬레이브 DB 1] F --> I[슬레이브 DB 2] J[분산 캐시] --> C J --> D J --> E
작동 원리:
- 요청 분산: 로드 밸런서가 클라이언트 요청을 여러 서버에 분산
- 데이터 접근: 각 서버가 분산된 데이터베이스에 접근
- 캐시 활용: 분산 캐시를 통해 성능 최적화
- 장애 처리: 장애 발생 시 자동 페일오버 수행
메시지 흐름과 합의 과정
sequenceDiagram participant Client participant Leader participant Follower1 participant Follower2 Client->>Leader: Write Request(value) Leader->>Follower1: AppendLog(value) Leader->>Follower2: AppendLog(value) Follower1-->>Leader: Ack Follower2-->>Leader: Ack Leader-->>Client: Commit Confirmation
- 클라이언트가 리더에게 쓰기 요청을 전달
- 리더가 팔로워 노드에 로그 저장을 요청
- 팔로워가 ACK 응답
- 과반 이상 응답 시 커밋 처리 후 클라이언트 응답
이 흐름은 Raft 또는 Paxos 의 핵심 섹션 (log replication, leader election, safety guarantee) 을 시각화함.
구조 및 아키텍처
graph TB subgraph "클라이언트 계층" WEB[웹 브라우저] MOBILE[모바일 앱] API_CLIENT[API 클라이언트] end subgraph "게이트웨이 계층" LB[로드 밸런서] API_GW[API 게이트웨이] end subgraph "서비스 계층" USER_SVC[사용자 서비스] ORDER_SVC[주문 서비스] PAYMENT_SVC[결제 서비스] INVENTORY_SVC[재고 서비스] end subgraph "데이터 계층" USER_DB[(사용자 DB)] ORDER_DB[(주문 DB)] PAYMENT_DB[(결제 DB)] INVENTORY_DB[(재고 DB)] end subgraph "인프라 계층" CACHE[캐시 클러스터] MESSAGE_Q[메시지 큐] MONITOR[모니터링] end WEB --> LB MOBILE --> LB API_CLIENT --> API_GW LB --> API_GW API_GW --> USER_SVC API_GW --> ORDER_SVC API_GW --> PAYMENT_SVC API_GW --> INVENTORY_SVC USER_SVC --> USER_DB ORDER_SVC --> ORDER_DB PAYMENT_SVC --> PAYMENT_DB INVENTORY_SVC --> INVENTORY_DB USER_SVC --> CACHE ORDER_SVC --> MESSAGE_Q PAYMENT_SVC --> MESSAGE_Q MONITOR --> USER_SVC MONITOR --> ORDER_SVC MONITOR --> PAYMENT_SVC MONITOR --> INVENTORY_SVC
구성요소
계층 | 구성 요소 | 역할/기능 | 대표 기술 예시 | 특징 |
---|---|---|---|---|
클라이언트 계층 | 웹/모바일/API 클라이언트 | 사용자 요청 생성 및 UI/UX 제공 | React, Flutter, Postman, Swagger UI | 요청 발신자, 다양한 플랫폼 지원 |
게이트웨이 계층 | 로드 밸런서 | 트래픽 분산, 서비스 헬스체크, 장애 발생 시 리다이렉션 | NGINX, HAProxy, AWS ELB | 고가용성 확보, 가중치 기반 분산 |
API 게이트웨이 | 인증, 라우팅, 요청/응답 변환, 로깅, 속도 제한 | Kong, Apigee, Istio Gateway | 경계 계층, API 관리 중심 역할 | |
서비스 계층 | 마이크로서비스 | 핵심 비즈니스 로직 수행, 각 기능을 모듈화하여 독립 운영 | FastAPI, Spring Boot, Node.js | 독립 배포, 확장성 우수 |
데이터 계층 | 분산 데이터베이스 | 영속성 있는 데이터 저장, 읽기/쓰기 처리, 일관성/복제/샤딩 | PostgreSQL, Cassandra, MongoDB | CAP 모델 기반, 구조적/비구조적 지원 |
키 - 값 캐시 | 자주 조회되는 데이터 캐싱, 응답 지연 최소화 | Redis, Memcached | 메모리 기반, TTL, 성능 최적화 | |
인프라 계층 | 메시지 브로커 | 서비스 간 비동기 메시지 전달, 큐잉 처리 | Kafka, RabbitMQ, NATS | 느슨한 결합, 이벤트 기반 아키텍처 지원 |
모니터링/로깅 | 서비스 상태 수집, 경고, 메트릭/로그 분석 | Prometheus, Grafana, ELK, OpenTelemetry | 실시간 추적, 장애 대응 가능 | |
설정 관리 / 보안 게이트웨이 | 서비스 설정값 분리 관리, 인증·인가 처리 | Consul, Vault, SPIFFE, OPA | 보안 중심 제어, 정책 기반 관리 |
구현 기법
카테고리 | 구현 기법 | 정의/구성 | 주요 목적 및 특징 | 실무 예시 |
---|---|---|---|---|
1. 데이터 분산 처리 | 샤딩 (Sharding) | 데이터를 여러 노드에 분할 저장 (Key-range, Hash 등) | 수평 확장, 부하 분산, 데이터 분리 | MongoDB, Cassandra, Elasticsearch |
데이터 복제 (Replication) | 데이터를 다수 노드에 복사 저장 (동기/비동기) | 고가용성, 장애 복원력, 읽기 확장성 | Cassandra, DynamoDB, MongoDB | |
CQRS + Event Sourcing | 읽기/쓰기 모델 분리 + 변경을 이벤트로 저장 | 성능 분리, 확장성, 감사 및 복구 가능 | 전자상거래 주문 시스템, Axon, Microsoft Azure | |
2. 통신 및 메시징 | 메시지 큐 & Pub/Sub | Kafka, RabbitMQ, SQS 등 | 비동기 처리, 느슨한 결합, 확장성 | Kafka 기반 이벤트 처리, 주문 → 재고 전달 |
Service Mesh & Sidecar | 사이드카 프록시 + 트래픽 정책 (Istio, Linkerd 등) | 보안, 트래픽 관리, 관찰성 향상 | Istio + Envoy in GKE, K8s 기반 서비스 간 통신 | |
RPC / gRPC / REST | 원격 호출 기반 통신 구조 | 동기 처리, 서비스 직접 연결 | gRPC 기반 마이크로서비스 통신 | |
3. 트랜잭션 및 일관성 처리 | 합의 알고리즘 (Consensus) | Raft, Paxos, ZAB 등 | 리더 선출, 일관성 유지 | Zookeeper, etcd, Consul |
Saga Pattern | 보상 트랜잭션 기반 분산 트랜잭션 | 데이터 정합성, ACID 대체 | 주문 → 결제 → 재고 → 취소 플로우 | |
4. 신뢰성/복원력 | Circuit Breaker / Retry / Timeout | 네트워크 실패/지연 대응 패턴 | 장애 격리, 사용자 경험 보호 | Netflix Hystrix, Spring Cloud Resilience4J |
장애 감지 및 복구 (Failover) | Heartbeat, Timeout, Leader Election | 내결함성, 장애 자동 복구 | Kubernetes, Consul, Zookeeper | |
5. 인프라 관리 및 오케스트레이션 | 컨테이너화 & 오케스트레이션 | Docker + Kubernetes / Mesos / Nomad | 일관된 배포 환경, 오토스케일링, 자원 격리 | Kubernetes ReplicaSet, HPA, GKE |
오토스케일링 & 로드 밸런싱 | 요청 기반 자동 확장 및 분산 | 성능 최적화, 트래픽 대응 | AWS ALB + K8s HPA, Nginx, Envoy | |
6. 이벤트 기반 설계 | Event-Driven Architecture (EDA) | 이벤트 생산자/브로커/소비자 구조 | 실시간 반응, 느슨한 결합, 확장성 | Kafka 기반 실시간 로그 처리, LinkedIn |
Domain/Integration Event 구분 | 내부 도메인 이벤트 vs 외부 통합 이벤트 | 책임 분리, 확장성 강화 | DDD 기반 MSA 이벤트 설계 | |
7. 통합 및 상호운용성 | ESB (Enterprise Service Bus) | 메시지 변환, 라우팅, QoS 제어 | 이기종 시스템 통합, 프로토콜 브리지 | Apache Camel, Mule ESB |
8. 시스템 아키텍처 패턴 | Microservices Architecture | 독립적인 소형 서비스 조합 | 독립 배포, 팀 분리, 빠른 개발 | Netflix, Amazon, Uber |
Monolith to Microservices 전환 | 도메인 기반 분리 및 마이그레이션 | 점진적 전환, 리스크 완화 | Spring Boot → Spring Cloud 전환 사례 |
장점
카테고리 | 항목 | 설명 | 기여 요소 및 배경 기술 |
---|---|---|---|
확장성 | 수평 확장 (Horizontal Scalability) | 노드 추가만으로 시스템 성능과 처리량을 선형적으로 증가시킬 수 있음 | Stateless 설계, Partitioning, Auto-scaling |
탄력성 (Elasticity) | 트래픽 변동에 따라 자원을 동적으로 조절할 수 있어 유연하게 대응 가능 | 클라우드 오토스케일링, KEDA, HPA | |
가용성/내결함성 | 고가용성 (High Availability) | 하나의 노드에 장애가 발생해도 다른 노드가 이를 대체하여 시스템 연속성 보장 | 이중화 구성, Failover, Leader Election |
장애 허용성 (Fault Tolerance) | 일부 노드에 장애가 발생하더라도 전체 시스템이 정상 동작하도록 설계됨 | 복제, 분산 합의 알고리즘 (Raft, Paxos), Retry/Backoff | |
지속 가능성 (Resilience) | 시스템이 장애 또는 부하 변화에도 스스로 복원하거나 안정성을 유지할 수 있음 | Self-healing, Circuit Breaker, Bulkhead 패턴 등 | |
성능 | 병렬 처리 (Parallelism) | 작업을 여러 노드에 분산시켜 동시에 처리함으로써 처리 속도를 극대화할 수 있음 | Task 분산, Worker Pool, MapReduce 구조 |
낮은 지연 시간 (Low Latency) | 사용자 가까운 노드에서 요청 처리하여 전송 지연을 줄일 수 있음 | Geo-distribution, Edge Computing | |
부하 분산 (Load Balancing) | 요청을 여러 노드에 고르게 분산하여 과부하를 방지하고 처리 성능을 유지함 | Reverse Proxy, Load Balancer, Consistent Hashing | |
유연성/운영 효율 | 기술 유연성 (Heterogeneity) | 다양한 운영체제, 프로그래밍 언어, 하드웨어 환경 간의 통합이 가능함 | Polyglot Architecture, API Gateway |
점진적 확장 및 변경 (Incremental Scalability) | 일부 컴포넌트만 변경하거나 업그레이드 가능함 | 마이크로서비스, Canary/Blue-Green 배포 | |
독립 배포 및 업그레이드 | 각 노드를 개별적으로 배포·운영 가능하므로 유지보수 효율 향상 | Containerization, Kubernetes | |
비용 효율성 | 범용 하드웨어 활용 | 고성능 전용 장비 대신 저렴한 범용 서버로 고성능 시스템을 구성 가능 | Commodity Hardware 기반 시스템 |
자원 활용 최적화 | 사용하지 않는 자원을 공유하거나 활용하여 비용을 절감함 | Virtualization, Resource Pooling | |
클라우드 비용 절감 | 클라우드 기반 자원 사용 시 필요한 만큼만 쓰고 비용을 절감할 수 있음 | Pay-as-you-go, Spot 인스턴스 활용 | |
지리적 분산 | 글로벌 사용자 지원 | 전 세계 여러 지역에 노드를 배치하여 사용자에게 빠른 응답을 제공함 | CDN, Multi-region 서비스 |
로컬 장애 대응 | 특정 지역의 장애가 다른 지역 서비스에 영향을 주지 않도록 설계 가능 | Region Isolation, 지연 기반 라우팅 | |
투명성 | 위치/접근/장애 투명성 | 사용자에게는 분산 시스템이 단일 시스템처럼 보이며, 복잡한 내부 구조는 감춰짐 | Location Transparency, Unified Endpoint, Consistency Protocol |
단점과 문제점 그리고 해결방안
단점
항목 | 설명 | 해결 전략 및 대응 기법 |
---|---|---|
설계 및 운영 복잡성 | 마이크로서비스 수 증가, 상태 분산 등으로 아키텍처 및 운영 부담 증가 | IaC 기반 자동화, 도메인 단위 분할, 서비스 메시, DevOps 문화 정착 |
네트워크 의존성 | 노드 간 통신 필수 → 지연, 패킷 손실, 장애 전파 등의 위험 존재 | 리던던시 구성, Circuit Breaker, QoS 기반 네트워크 설계 |
데이터 일관성 유지 어려움 | CAP 원칙에 따라 강한 일관성 - 가용성 - 분할 허용성 동시 보장이 불가능 | Event Sourcing, CRDT, Saga 패턴, Tunable Consistency 활용 |
보안 공격 표면 증가 | 노드·서비스 수 증가에 따라 공격 경로 다변화 | 제로 트러스트, mTLS, 방화벽, 서비스 메시 기반 인증 및 암호화 적용 |
디버깅 및 관찰성 부족 | 로그 및 상태가 분산되어 있어 문제 파악이 어려움 | 분산 트레이싱 (Jaeger, Zipkin), 중앙 로깅 (ELK, Loki) |
운영 비용 증가 | 복잡도 증대로 인프라/인력 비용 동반 증가 | 오토스케일링, 서버리스 도입, 비용 기반 리소스 할당, Cloud 비용 최적화 도구 |
문제점
항목 | 원인 | 영향 | 탐지 및 진단 | 예방 방법 | 해결 전략 및 기법 |
---|---|---|---|---|---|
네트워크 분할 | 스위치 장애, 라우팅 이슈, 패킷 손실 | 쿼럼 실패, 데이터 불일치, 시스템 중단 | 헬스 체크, RTT 분석, 패킷 드롭률 모니터링 | 이중화된 네트워크 경로 구성, 지연 감시 | Quorum 알고리즘, 리더 재선출, Retry with Timeout |
데이터 불일치 | 비동기 복제, Conflict, 시간차 발생 | stale 데이터, 정합성 오류 | 버전 충돌 모니터링, Data Drift 알림 | 강한 일관성 설정, Conflict-free 구조 설계 | Read Repair, CRDT, Anti-Entropy Sync |
스플릿 브레인 발생 | 네트워크 단절로 인한 다중 노드 리더 상태 | 두 개 이상의 리더로 인한 충돌 | 쿼럼 로깅, 리더 선출 로그 추적 | 홀수 노드 수 유지, Quorum 기반 합의 로직 | Paxos/Raft 기반 리더 선출 알고리즘 적용 |
캐스케이딩 실패 | 하나의 장애가 인접 서비스에 전파 | 전체 시스템 마비 | 트레이싱 및 호출 체인 분석 | 서킷 브레이커, 벌크헤드 패턴 적용 | 서비스 격리, 점진적 복구, Backpressure |
데이터 레이스 / 동시성 충돌 | 다중 노드 동시 쓰기, 락 경합 | 트랜잭션 실패, 데이터 손상 | Deadlock 카운터, 트랜잭션 충돌 로그 추적 | 락 분할, 버전 관리, 트랜잭션 격리 수준 설정 | Optimistic Concurrency Control, Pessimistic Locking |
지속적인 리소스 낭비 | 자동화 미흡, 유휴 리소스 방치 | 비용 급증, 자원 낭비 | Cloud Cost Alerts, 리소스 사용률 모니터링 | 오토스케일링, 서버리스, Spot 인스턴스 | VPA/HPA 적용, 멀티 테넌시 설계, 비용 기반 스케일링 |
보안 취약점 | 통신 암호화 미흡, 인증/인가 누락 | 데이터 유출, 무단 접근 | IDS/IPS, 인증 실패 로그 분석 | TLS, 최소 권한 원칙 (RBAC), 서비스 계정 분리 | 인증서 회전, Zero Trust, 정책 기반 접근 제어 |
동기화 지연 | 글로벌 노드 간 클럭 차이, 네트워크 지연 | 순서 불일치, 타임스탬프 충돌 | Clock Drift 로그, 타임스탬프 기반 정렬 오류 | 논리 시계 (Lamport, Vector Clock) 도입 | 동기화 주기 조정, Conflict 해결 알고리즘 적용 |
메모리 누수 및 GC 문제 | 장기 실행 서비스, 객체 해제 실패 | 성능 저하, OutOfMemory | APM, 힙/스택 사용량 추적 | 주기적 재시작, 메모리 한도 설정 | GC 튜닝, 경량 런타임 도입, 컨테이너 기반 스케줄링 적용 |
도전 과제
카테고리 | 도전 과제 | 주요 원인 | 영향 | 탐지 및 진단 | 예방 전략 | 해결 전략 및 기술 |
---|---|---|---|---|---|---|
1. 네트워크/통신 | 네트워크 지연 및 불안정성 | 지역 간 거리, 혼잡, 라우팅 오류, 패킷 손실 | 서비스 응답 지연, 타임아웃 발생 | RTT, TCP 재전송률, 트레이스 분석 | CDN, 엣지 컴퓨팅, QoS 기반 경로 구성 | 백오프 전략, 타임아웃 조정, 지역 분산 배포 |
합의 지연 및 리더 장애 | 노드 장애, 네트워크 분할, leader 교체 지연 | 쓰기 지연, 일관성 저하 | 리더 전환 로그, 지연율, Quorum 실패 추적 | Heartbeat 튜닝, 리더 사전 선출 기준 강화 | Fast quorum, 리더 안정화 로직 | |
2. 데이터/일관성 | 상태 불일치 (State Drift) | 비동기 복제, 네트워크 장애, 버전 충돌 | 데이터 불일치, 트랜잭션 실패 | 벡터 클록, 버전 해시 비교, read-verification | CRDT, Vector Clock, Quorum Read 설정 | Anti-Entropy, Read Repair, 교정 작업 |
데이터 샤딩 핫스팟 | 특정 키/파티션 집중 트래픽 | 노드 과부하, 응답 지연 | 파티션별 요청/응답 로그 분석 | Consistent Hashing, 키 분산, 고정 슬롯 | 리파티셔닝, 샤드 재분배, Dynamic Partitioning | |
3. 성능/자원 최적화 | 스케일링 오류 및 자원 낭비 | 수동 확장, 스팟 인스턴스 미활용, 예측 실패 | 과소/과대 할당, 비용 낭비 | 리소스 사용량, AutoScaler 로그, 비용 경고 | 오토스케일링 (HPA/VPA), 예약 인스턴스, 서버리스 | KEDA, Spot/FaaS 기반 아키텍처 전환 |
메모리/GC 이슈 | 비효율적인 객체 관리, GC Pause | 지연 증가, 성능 저하 | GC 로그, Heap/Alloc 프로파일링 | JVM/Go 튜닝, 경량 런타임 적용 | GC 알고리즘 변경 (G1, ZGC), 메모리 프로파일링 | |
네트워크 I/O 최적화 | 과도한 메시지량, 직렬화 비용 | 전송 지연, 처리량 감소 | 메시지 사이즈, 직렬화 속도 측정 | Snappy/LZ4 압축, Avro/Protobuf | Batch 전송, 직렬화 포맷 최적화 | |
4. 보안/프라이버시 | 인증/암호화 취약점 | 미암호화 통신, 인증 생략, RBAC 미비 | 데이터 유출, 권한 오용 | 보안 로그, 침입 탐지 (IDS), 권한 오디팅 | mTLS, 최소 권한 원칙, 서비스 계정 분리 | Zero Trust, IAM 정책, 인증서 자동 순환 |
데이터 프라이버시 | 사용자 민감 데이터 분산 저장 | 법적 규제 위반, 신뢰도 하락 | 민감 필드 추적, 감사 로그 | PII 마스킹, 암호화 저장, 접근 로깅 | 동형 암호화, Tokenization, 연합 학습 | |
5. 운영 복잡성 | 마이크로서비스 복잡성 증가 | 서비스 수 증가, 의존성 과잉 | 배포 난이도 상승, 장애 추적 어려움 | 트레이싱, API 의존성 시각화 | 서비스 메시, API 게이트웨이, Domain 분리 | 관찰성 강화 (Tracing, Logging), 정책 기반 배포 |
자동화 부족 | 수작업 운영, 배포 일관성 부족 | 운영 비용 증가, 인적 오류 | CI/CD 파이프라인, IaC 적용 | GitOps, ArgoCD, Terraform | ||
장애 대응 지연 | 분산 로그, 모니터링 미비 | MTTR 증가, SLA 불이행 | 모니터링 + 알림 설정, 분산 추적 도입 | Chaos Engineering, Self-healing 구성 | ||
6. 데이터 거버넌스 | 소유권 분산 및 정책 불일치 | 각 팀/서비스별로 책임 범위 불명확 | 품질 저하, 감사 실패 | 데이터 라벨링, 거버넌스 상태 대시보드 | 데이터 메시 아키텍처, 카탈로그화 | 연합 거버넌스, 중앙 정책 + 팀 자율 조합 모델 |
요약
핵심 영역 | 주요 과제 | 핵심 대응 전략 요약 |
---|---|---|
통신/지연 | 네트워크 불안정, 리더 전환 지연 | 백오프 + 리트라이, Fast Quorum, 에지 분산 배포 |
데이터 일관성 | 비동기 복제, 핫스팟, 충돌 | CRDT, Vector Clock, 샤딩 최적화, 리파티셔닝 |
리소스 최적화 | 자동화 부족, 스케일링 오류, 자원 낭비 | 오토스케일링, 서버리스, FaaS, IaC, 비용 기반 리소스 관리 |
보안/규제 | 인증 취약, 민감 데이터 유출 | Zero Trust, mTLS, 동형 암호화, IAM |
운영 복잡성 | 장애 복원력, 서비스 증가, 추적 어려움 | Observability 강화 + Chaos Engineering + API 게이트웨이 |
거버넌스 | 소유권 불명확, 정책 충돌 | 데이터 메시, 중앙 거버넌스 + 자율 분산 모델 |
분류 기준에 따른 종류 및 유형
분류 기준 | 주요 유형 | 설명 및 특징 | 대표 예시 |
---|---|---|---|
1. 아키텍처 구조 | Client–Server | 중앙 서버가 요청 처리, 클라이언트는 요청 송신 | 전통적 웹 애플리케이션, RESTful API 서버 |
Peer-to-Peer (P2P) | 모든 노드가 동등한 역할 수행, 자율 분산 구조 | BitTorrent, 블록체인 | |
Microservices | 기능별로 서비스 분리, 독립 배포 가능, 느슨한 결합 | Netflix, Amazon | |
N-Tier (3-Tier 포함) | 프레젠테이션, 애플리케이션, 데이터 계층 분리 | 엔터프라이즈 시스템 아키텍처 | |
2. 통신 방식 | Synchronous (RPC, REST) | 실시간 요청 - 응답 구조, 응답 지연에 민감 | gRPC, REST API |
Asynchronous (Messaging, Event Queue) | 메시지 큐 기반, 비동기 이벤트 전달 구조 | Kafka, RabbitMQ | |
3. 데이터 처리 구조 | Replication (복제) | 동일 데이터를 여러 노드에 복사하여 고가용성 확보 | MongoDB, Cassandra |
Partitioning (샤딩) | 데이터를 키 기반으로 나누어 여러 노드에 저장 | Cassandra, HDFS | |
Shared-Memory / Shared-Disk / Nothing | 자원 공유 수준에 따라 구분: 공유 메모리/디스크/완전 독립형 구조 | Shared-Disk (Oracle RAC), Shared-Nothing (Cassandra) | |
4. 데이터 일관성 모델 | Strong Consistency | 모든 노드에 대해 즉시 일관된 데이터 보장 | RDBMS Cluster, Raft |
Eventual Consistency | 시간이 지나면 데이터가 수렴하며 일관성 확보 (AP 계열 시스템) | DynamoDB, Cassandra | |
Causal / Session Consistency | 순서 기반 일관성, 사용자 요청 흐름 내에서는 정합성 보장 | AWS S3 (Causal), Redis (Session) | |
5. 확장성 및 장애 모델 | Horizontal Scaling (수평 확장) | 노드를 추가해 시스템 확장, 고가용성 확보 가능 | Kubernetes 기반 서비스, Kafka Cluster |
Vertical Scaling (수직 확장) | 단일 노드 리소스를 증가시켜 확장 | 단일 서버 기반 DB 확장 | |
Crash Fault Tolerant (CFT) | 노드 장애를 감지하고 정상 노드로 failover 가능 | Raft, Zookeeper | |
Byzantine Fault Tolerant (BFT) | 악의적인 노드도 감내할 수 있는 구조 (트러스트 없는 환경) | PBFT, Tendermint, 블록체인 네트워크 | |
6. 제어 구조 | Centralized | 중앙 노드/관리자에 의해 전체 제어됨 | Master-Slave 구조 (HDFS NameNode 등) |
Decentralized | 각 노드가 독립적으로 작동하며 상호 협력 | P2P 시스템, 블록체인 | |
7. 컴퓨팅 목적 | Cluster Computing | 동일 작업을 고성능 환경에서 병렬로 처리 | Spark, Kubernetes Job |
Grid Computing | 다양한 위치의 자원을 묶어 이기종 작업을 병렬로 수행 | BOINC, Globus Toolkit | |
Cloud Computing | 자원 가상화 + 온디맨드 프로비저닝 + 종량제 모델 | AWS, Azure, GCP | |
8. 지리적 분포 | LAN 기반 분산 | 근거리 네트워크에서 구성된 클러스터 구조 | 기업 내부 전산망, 데이터센터 클러스터 |
WAN 기반 분산 | 전 지구적 분산 환경으로, 고지연 네트워크 기반 설계 | 글로벌 CDN, Multi-region 서비스 |
실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점
영역 | 고려사항/주제 | 설명 | 권장 방안 |
---|---|---|---|
설계 | 도메인 경계 정의 (DDD) | 서비스 분할 기준이 명확하지 않으면 결합도 증가, 장애 전파 위험 | 바운디드 컨텍스트 기반 도메인 모델링, DDD 적용 |
데이터 일관성 모델 선택 | 모든 상황에서 강한 일관성은 성능과 가용성을 희생함 | 비즈니스 목적에 따른 강일관성/최종일관성 선택, BASE 원칙 활용 | |
장애 격리 설계 (Blast Radius 축소) | 단일 장애가 전체 시스템에 전파될 수 있음 | 서비스 독립 배포, Bulkhead, Circuit Breaker 패턴 적용 | |
동적 구성/서비스 디스커버리 | 노드 추가/삭제 시 수동 대응은 확장성과 관리 효율 저하 | Consul, Eureka, Spring Cloud Config 등 서비스 탐색 및 구성 자동화 도구 사용 | |
개발 | API 버저닝 및 변경 관리 | 하위 호환성 없는 API 변경은 시스템 장애를 유발할 수 있음 | 시맨틱 버저닝, API Gateway 통한 점진적 전환, deprecated 단계 운영 |
메시지 직렬화 포맷 | JSON 은 가독성은 좋지만 성능 저하 원인이 될 수 있음 | Protobuf, Avro 사용하여 스키마 강제 및 효율적 직렬화 구현 | |
통신 방식 선택 (RPC vs 메시징) | 실시간 응답 필요/비동기 처리 필요 여부에 따라 선택 | gRPC (실시간 RPC), Kafka/RabbitMQ (비동기 이벤트 기반 통신) | |
장애 대응 패턴 | 실패 전파 및 연쇄 장애 발생 가능성 존재 | Retry, Backoff, Timeout, Circuit Breaker, Bulkhead 패턴 적용 | |
운영 | 오토스케일링 정책 | 고정 리소스는 피크 트래픽 대응 어려움 | HPA(VPA), Kubernetes, KEDA, 리소스 기반 Autoscaling 정책 적용 |
테스트 및 배포 자동화 | 분산 환경에서 수동 배포는 위험도와 반복 비용 증가 | CI/CD 구축, Canary, Blue/Green 배포 전략, 테스트 자동화 프레임워크 도입 | |
장애 감지 및 복구 | 장애 지연 감지 시 SLA 위반/서비스 중단 우려 | 이중화 구성, Health Check + Auto Healing, Self-Healing Controller 도입 | |
관측성 | 분산 트레이싱 구현 | 마이크로서비스 흐름 파악 어려움 | Trace ID 기반 전파, Jaeger, OpenTelemetry, Zipkin 등 도입 |
로깅/메트릭 수집 | 분산 구조에서는 로그의 상관 관계 확인이 어려움 | 구조화 로그 + Correlation ID, ELK, Loki, Prometheus, Grafana | |
장애 원인 분석 및 Alerting | 수많은 구성요소 중 어디서 장애가 발생했는지 파악이 어려움 | SLA 기반 알림 시스템 구성, AlertManager, AIOps 적용 | |
보안 | 인증/인가 체계 구축 | 분산 서비스 간 권한 관리 누락 시 공격 표면 확대 | OAuth2.0, JWT, RBAC, API Gateway 기반 보안 정책 적용 |
통신 암호화 | 노드 간 트래픽 노출로 인한 보안 위협 존재 | TLS, mTLS, Zero Trust Architecture, 서비스 간 Mutual TLS 적용 | |
규정 준수 및 감사 로깅 | 금융/의료 등 규제 산업에선 민감 정보 보호가 필수 | 감사 로그 수집, PII 필드 마스킹, 접근 감사/추적 기능 도입 | |
확장성/신뢰성 | 수평 확장 설계 | 단일 인스턴스 확장 한계 → 수평 확장 구조 필요 | 컨테이너화 (K8s), Stateless 구조, Kafka 파티셔닝 및 서비스 복제 적용 |
데이터 파티셔닝 전략 | 불균형한 샤드 키는 Hot Partition 유발 | 해시 기반 샤딩, 범위 기반 파티셔닝, 동적 재파티셔닝 설계 | |
합의/리더 선출 알고리즘 | 리더 장애 시 전체 시스템 정지 위험 존재 | Raft, Paxos, ZAB 등 합의 알고리즘 사용, 타임아웃/하트비트 튜닝 최적화 | |
일관성 vs 가용성 (CAP/PACELC 고려) | 시스템 전체 특성에 맞는 트레이드오프 필요 | 일관성 중심 (CA), 가용성 중심 (AP), 지연 고려 (PACELC) 에 따라 설계 선택 | |
데이터 처리 | 캐시 계층 도입 | 읽기 부하 집중 시 DB 병목 가능 | Redis, Memcached, CDN 활용, TTL 기반 강/약 캐시 계층 분리 설계 |
실시간 데이터 스트림 처리 | 배치 처리로는 지연이 과도한 시나리오 존재 | Kafka + Flink/Spark Streaming, Event Sourcing 기반 비동기 파이프라인 구성 |
최적화하기 위한 고려사항 및 주의할 점
카테고리 | 고려 항목 | 주요 고려사항 및 주의점 | 권장 전략 및 적용 방안 |
---|---|---|---|
성능 최적화 | 네트워크 튜닝 | RTT, 대역폭 병목, 연결 비용, 리전 간 통신 지연 | gRPC/HTTP2, CDN/에지 배포, Keep-alive 연결 풀링, 배치 전송 |
캐싱 전략 | 캐시 무효화 복잡성, TTL 관리 문제 | 다층 캐싱 (Redis + CDN), TTL 정책 설계, 응답 기반 캐시 유효성 판단 | |
로컬화 및 인접성 최적화 | 요청 → 응답 거리를 줄이기 위한 물리적/논리적 구조 설계 | 리전 분산 배포, 클라이언트 근처의 Microservice 구성 | |
메시지 커밋 정책 | 동기 vs 비동기 ack 선택, 중복 수신, 성능 저하 가능성 | Async Commit + 멱등성 적용, 배치 Ack, Timeout 조정 | |
확장성/탄력성 | 오토스케일링 | 부하 예측 실패, 스케일 업/다운 시점 오차 | HPA/VPA, KEDA 기반 이벤트 스케일링, Queue 길이 기반 확장 트리거 |
데이터 파티셔닝 | Hot-spot, 불균형 파티션 이슈 | Consistent Hashing, Dynamic Sharding, 읽기 전용 Replication | |
부하 분산 (Load Balancing) | 트래픽 집중 지점, Failover 미비 | L7/L4 로드밸런서, Zone-Aware Routing, Weighted Round-Robin | |
데이터 최적화 | 샤딩/복제 전략 | 샤드 키 설계 오류 시 불균형 발생, 리더 - 팔로워 지연 | 샤딩 기준 분석 기반 설계, 핫키 분산, 읽기 전용 복제본 구성 |
배치 vs 스트림 처리 | 실시간 요구와의 충돌 가능성 | Kafka/Flink 기반 스트림, 필요 시 마이크로배치 (Bulk API + Window Trigger) 적용 | |
일관성/지속성 | 일관성 vs 성능 트레이드오프 | 높은 일관성은 성능 저하를 동반함 | Tunable Consistency, Read Replica 활용 |
데이터 보존 및 TTL 정책 | 저장소 누적 → 비용 증가, GC 부담 가능성 | Kafka Log Retention 설정, S3 로 이동, TTL 관리 체계화 | |
비용 최적화 | 자원 활용 최적화 | 유휴 인스턴스, 과잉 리소스 소비 | 스팟 인스턴스, 서버리스 FaaS, 리소스 기반 과금 구조 설계 |
로깅/모니터링 과다 | 지나친 로깅으로 I/O 병목, 비용 증가 | 샘플링 로깅 (1~5%), Elasticsearch Pipeline 필터, 인프라 수준 로깅 분리 | |
운영 효율화 | 운영 자동화 (Infra as Code) | 반복 작업 수작업 시 실수 증가, 배포 오차 발생 | Terraform, Helm, ArgoCD, GitOps 기반 선언형 자동화 |
CI/CD 및 테스트 자동화 | 수동 배포로 인한 서비스 중단 위험 | Blue-Green, Canary, Progressive Delivery | |
모니터링/관찰성 강화 | 병목 탐지 어려움, Alert Noise | 분산 트레이싱 + APM, SLA 기반 알림 조건 설정, 메트릭 기반 Scaling Trigger | |
메모리/처리 최적화 | GC/메모리 누수 대응 | JVM/Go 환경에 따라 GC Pause 로 인한 성능 저하 | JVM GC 튜닝 (G1/Parallel), Go GC 설정, 메모리 프로파일링 도구 적용 |
압축 및 직렬화 포맷 | 과도한 압축은 CPU 사용 증가 | LZ4, Snappy + Avro/Protobuf 조합 사용 |
요약
주제 | 전략적 선택 기준 | 권장 조합 기술 예시 |
---|---|---|
성능 ↔ 일관성 | 성능 우선 → Eventually / 일관성 우선 → Linearizable | Cassandra, DynamoDB, Spanner |
확장성 | 비동기, 메시지 기반, Stateless 우선 설계 | Kafka + Stateless Worker + Consumer Scaling |
운영 자동화 | 선언형 IaC + 모니터링 기반 스케일링 | Terraform + Prometheus + HPA |
비용 효율 | 서버리스 + 에지 최적화 + 로그 샘플링 | Lambda/FaaS + CloudFront + OpenTelemetry Sampling |
관찰성과 복원력 | 분산 추적 + Chaos Testing 도입 | Jaeger + Gremlin, Chaos Monkey |
실무 사용 예시
도메인/산업 분야 | 주요 목적 | 기술 스택/구성 요소 | 기대 효과 및 운영 이점 |
---|---|---|---|
전자상거래 | 대규모 주문 처리, 고가용성, 확장성 확보 | Kafka, Redis, Elasticsearch, Microservices, Load Balancer, Kubernetes | 트래픽 급증 대응, 실시간 이벤트 흐름 처리, 장애 격리, 24/7 운영 |
금융/결제 서비스 | 실시간 트랜잭션, 규정 준수, 일관성 보장 | RabbitMQ, Kafka, Oracle RAC, PostgreSQL Cluster, Saga Pattern | 초당 수십만 트랜잭션 처리, 데이터 정합성 보장, 트랜잭션 감사 및 보상 처리 시스템 구현 |
미디어/스트리밍 | 전 세계 콘텐츠 전송 최적화, 추천 시스템 처리 | CDN, Redis Streams, Kafka, ML Pipeline, Distributed Cache, Edge Node | 낮은 지연, 대역폭 절약, 사용자 맞춤형 콘텐츠 제공, 글로벌 동시 접속 대응 |
소셜 미디어 플랫폼 | 사용자 활동 수집 및 알림, 실시간 피드 구성 | Kafka, Redis Pub/Sub, Graph DB, WebSocket, Elasticsearch | 수십억 이벤트 전송, 피드 동기화, 멀티 채널 알림 동시 처리 |
IoT/스마트 플랫폼 | 대규모 센서 데이터 수집, 엣지/실시간 처리 | MQTT, Apache Storm, Kafka, Azure IoT Hub, Time Series DB (InfluxDB, Prometheus) | 수백만 장치 동시 연결, 저지연 데이터 수집, Edge→Cloud 데이터 파이프라인 최적화 |
모바일/게임 서버 | 글로벌 유저 처리, 실시간 이벤트 동기화 | Akka Cluster, Redis, gRPC, Geo Load Balancing, Kubernetes | 전 세계 사용자 분산 처리, 지역 장애 복구, 빠른 반응속도 제공 |
데이터 분석/AI | 실시간 데이터 스트리밍, ML 추론 자동화 | Kafka, Apache Flink, Spark, Hadoop, TensorFlow Serving, Airflow | 대용량 실시간 분석, 추론 트리거 자동화, ETL 병렬 처리 |
백오피스/배치 시스템 | 비동기 예약 작업, 대용량 백그라운드 처리 | SQS, Celery, RabbitMQ, Cron, Apache Airflow | 리소스 분산, 병렬 처리, 예약 태스크 자동화 |
글로벌 서비스 인프라 | 다중 리전 운영, 고가용성, 지연 최소화 | Cassandra, DynamoDB, Kubernetes, Istio, Consul, Nginx + CDN | 지역 장애 격리, 분산 데이터 일관성 확보, 다중 리전 라우팅 및 페일오버 구현 |
분산 파일 시스템 | 대용량 파일 저장, 복제, 장애 복원 | HDFS, Ceph, MinIO, GlusterFS | 데이터 내구성 보장, 복제 기반 장애 복구, 대규모 데이터 분산 저장 구조 |
활용 사례
사례 1: Netflix 마이크로서비스 아키텍처
시스템 구성:
Netflix 는 700 개 이상의 마이크로서비스로 구성된 분산 시스템을 운영합니다.
graph TB A[사용자] --> B[Edge Service] B --> C[API Gateway] C --> D[User Service] C --> E[Recommendation Service] C --> F[Content Service] C --> G[Billing Service] D --> H[User Database] E --> I[ML Models] F --> J[Content Database] G --> K[Payment Database] L[Eureka Service Discovery] --> D L --> E L --> F L --> G M[Hystrix Circuit Breaker] --> D M --> E M --> F M --> G
Workflow:
- 사용자 요청이 Edge Service 를 통해 진입
- API Gateway 에서 요청 라우팅 및 인증
- 각 마이크로서비스가 독립적으로 처리
- Eureka 를 통한 서비스 발견
- Hystrix 를 통한 장애 격리
분산 시스템의 역할:
- 확장성: 개별 서비스 독립적 확장
- 내결함성: 한 서비스 장애가 전체에 영향 없음
- 개발 속도: 팀별 독립적 개발 및 배포
분산 시스템 유무에 따른 차이점:
- 적용 전: 모놀리식 구조로 배포 시간 길고 확장 어려움
- 적용 후: 빠른 배포, 선택적 확장, 장애 격리 가능
구현 예시:
|
|
사례 2: E-Commerce 주문 처리 플랫폼
시스템 구성:
flowchart LR Client[유저 앱] Client --> API["API 서버 (K8s)"] API --> Kafka[Kafka Broker] Kafka --> OrderSvc[주문 서비스] Kafka --> InventorySvc[재고 서비스] Kafka --> PaymentSvc[결제 서비스] OrderSvc --> DB1[MySQL 샤드 A] InventorySvc --> DB2[MySQL 샤드 B] PaymentSvc --> DB3[MySQL 샤드 C] Compensation[보상 서비스] InventorySvc --> Compensation PaymentSvc --> Compensation
Workflow:
- 주문 요청: 클라이언트 → API 서버
- 이벤트 발행: API 서버 → Kafka 토픽:
OrderCreated
- 각 서비스 처리:
- Stock 확인 → Kafka
StockChecked
- 결제 진행 → Kafka
PaymentProcessed
- 주문 완료 → Kafka
OrderCompleted
- Stock 확인 → Kafka
- 실패 처리: Stock 또는 Payment 실패 시 Saga 보상 →
OrderCancelled
,StockReverted
등 이벤트 발행 - DB 업데이트: 각 샤드에 최종 상태 저장
시스템 효과:
- 확장성: Kafka 파티션, 샤드별 서비스 병렬 처리
- 장애 내성: 각 서비스 독립, 실패 시 보상 로직
- 이벤트 기반: 비동기 커플링으로 유연한 확장 가능성
구현 예시:
|
|
|
|
이 코드 예시는 FastAPI 기반 Order Service
에서 주문 생성 이벤트를 Kafka 에 발행하고, Inventory Service
가 이를 컨슈밍하여 재고 확인 후 이벤트를 재발행하는 EDA 기반 분산 시스템의 단순 구현.
사례 3: Netflix 스트리밍 플랫폼
시스템 구성:
Netflix 는 2008 년 데이터베이스 장애를 계기로 모놀리식 아키텍처에서 마이크로서비스로 전환했다. 현재 700 개 이상의 마이크로서비스가 AWS 클라우드에서 운영되고 있다.
graph TB subgraph "클라이언트" CLIENT[스마트TV/모바일/웹] end subgraph "AWS 클라우드" subgraph "API 게이트웨이" ZUUL[Zuul Gateway] end subgraph "마이크로서비스" USER[User Service] RECOM[Recommendation Service] VIEW[Viewing Service] BILLING[Billing Service] end subgraph "데이터 저장" CASSANDRA[(Cassandra)] MYSQL[(MySQL)] ELASTIC[(Elasticsearch)] end subgraph "메시징" KAFKA[Apache Kafka] end subgraph "캐싱" EVcache[EVCache] end subgraph "CDN" OPENCONNECT[Open Connect CDN] end end CLIENT --> ZUUL ZUUL --> USER ZUUL --> RECOM ZUUL --> VIEW ZUUL --> BILLING USER --> MYSQL RECOM --> CASSANDRA VIEW --> CASSANDRA BILLING --> MYSQL USER --> EVcache RECOM --> EVcache VIEW --> KAFKA RECOM --> KAFKA RECOM --> ELASTIC CLIENT --> OPENCONNECT
Workflow:
- 사용자가 Netflix 앱을 통해 접속
- Zuul API Gateway 가 요청을 적절한 마이크로서비스로 라우팅
- User Service 가 인증 및 사용자 프로필 처리
- Recommendation Service 가 개인화된 콘텐츠 추천 생성
- Viewing Service 가 시청 기록 및 재생 위치 관리
- Open Connect CDN 이 비디오 콘텐츠를 사용자에게 직접 전송
역할 및 특징:
- 확장성: 개별 서비스의 독립적 스케일링으로 트래픽 급증 대응
- 가용성: 서킷 브레이커 패턴으로 장애 전파 방지
- 성능: 전 세계 CDN 과 캐싱을 통한 빠른 콘텐츠 전송
- 혁신: A/B 테스트를 통한 지속적 기능 개선
구현 예시:
|
|
주목할 내용
카테고리 | 핵심 주제 | 핵심 항목 | 설명 |
---|---|---|---|
아키텍처 원칙 | CAP 정리 | 일관성, 가용성, 분할 허용성 | 3 요소 중 2 가지만 보장 가능한 분산 시스템 기본 원칙. 설계 트레이드오프의 핵심. |
BASE 원칙 | Eventually Consistency | 일관성 대신 가용성과 유연성을 추구하는 NoSQL 기반 분산 시스템 원칙. | |
Fallacies | 네트워크 가정의 오류 | 분산 환경에서 흔히 간과되는 네트워크 지연, 신뢰성 등에 대한 잘못된 가정 목록. | |
데이터 처리 전략 | 데이터 분산 저장 | 샤딩 / 복제 | 수평 확장성과 내결함성 확보를 위한 핵심 기법. 성능 최적화와 가용성 향상에 기여. |
이벤트 소싱 | 상태 변화 기록 | 모든 상태 변화를 이벤트로 저장하여 추적 가능. Event-Driven 시스템과 결합 효과적. | |
CQRS | 명령/조회 분리 | 읽기와 쓰기 모델 분리를 통한 확장성과 최적화. 이벤트 소싱과 함께 자주 사용됨. | |
Saga 패턴 | 분산 트랜잭션 처리 | 보상 트랜잭션을 통해 트랜잭션 일관성을 유지. 데이터베이스 일관성이 어려운 상황에서 유용. | |
합의 및 일관성 | 합의 알고리즘 | Raft / Paxos / PBFT | 리더 선출, 로그 복제, 장애 복원 등 클러스터 내 일관성 보장 메커니즘. PBFT 는 비잔틴 장애까지 허용. |
쿼럼 (Quorum) | 의사결정 기준 노드 수 | 합의를 위한 최소한의 동의 노드 수. 일관성/가용성 비율에 영향을 줌. | |
통신 및 메시징 | 비동기 통신 | 메시지 큐 / 이벤트 스트리밍 | 마이크로서비스 간 decoupling 을 위한 핵심. Kafka, RabbitMQ 등으로 구현. |
Service Mesh | 서비스 간 통신 추상화 | 통신 제어, 인증, 로깅, 라우팅을 추상화하여 일관된 인프라 계층 제공. | |
gRPC | 고성능 RPC 통신 | HTTP/2 기반 이진 RPC 로 마이크로서비스 내부 통신에 최적화. | |
운영 및 오케스트레이션 | 컨테이너 관리 | Kubernetes / 오케스트레이션 | 분산된 워크로드 자동 배포, 복구, 확장. MSA 운영의 핵심 플랫폼. |
오토스케일링 | HPA / Auto Scaling | 부하 기반으로 자원 자동 확장. KEDA, AWS Auto Scaling 과 연동 가능. | |
관찰성 | 모니터링 / 분산 추적 | 메트릭, 로그, 트레이싱 기반으로 실시간 시스템 상태 확인 및 병목 탐지. | |
카오스 엔지니어링 | 장애 시뮬레이션 | Netflix Chaos Monkey 등의 도구로 복원력 및 장애 대응능력 점검. | |
배포 전략 | 배포 패턴 | Canary / Blue-Green | 점진적 또는 무중단 배포를 통해 안정성과 속도를 모두 확보하는 전략. |
보안 모델 | 제로 트러스트 | 지속적 인증 검증 | 네트워크 내부도 신뢰하지 않음. 사용자·디바이스별 세밀한 접근 통제 필요. |
Mutual TLS | 상호 인증 암호화 통신 | 클라이언트와 서버가 모두 인증을 수행하여 신뢰 기반 통신 구현. | |
동형 암호화 | 암호 상태 연산 | 암호화된 상태에서 연산 가능. 개인정보 보호를 위한 최신 기술. | |
신기술 트렌드 | 에지 컴퓨팅 | 5G 통합 | 지연 최소화와 실시간 반응성을 위한 컴퓨팅 자원의 지역 분산화. |
서버리스 | FaaS (Function as a Service) | 인프라 운영 제거, 비용 최적화. 이벤트 기반 비동기 처리에 적합. | |
웹어셈블리 (WASM) | 고성능 경량 실행 | 브라우저 외부 또는 클라우드 엣지에서도 안전한 고성능 코드 실행 가능. | |
AI/ML 인프라 | MLOps | 모델 배포 자동화 | 머신러닝 모델의 학습 → 배포 → 운영 과정을 자동화하여 일관성 확보. |
연합 학습 (Federated Learning) | 데이터 분산 학습 | 중앙 서버 없이 각 장치에서 학습. 개인정보 보호에 유리함. |
반드시 학습해야 할 내용
카테고리 | 주제 | 항목/개념 | 설명 및 실무 적용 포인트 |
---|---|---|---|
이론 | 분산 시스템 원칙 | CAP 이론 / BASE 원칙 | 일관성, 가용성, 분할 허용성의 트레이드오프 (CAP) / 최종 일관성과 가용성을 강조하는 BASE 모델 이해 |
데이터 일관성 모델 | Strong, Eventual, Causal | 다양한 일관성 수준을 선택하여 서비스의 특성에 맞게 적용 (e.g., SNS 는 Eventual, 은행은 Strong) | |
알고리즘 | 합의 알고리즘 | Paxos, Raft | 리더 선출, 로그 복제, 장애 복구에 핵심. Raft 는 Paxos 보다 구현이 단순해 실무에서 더 선호됨 |
시계 동기화/순서 보장 | Vector Clock, Lamport Timestamp | 이벤트 간 인과관계 추적 및 순서 보장을 위해 필수. 특히 분산 로그 처리 및 트레이싱에 활용 | |
패턴/아키텍처 | 장애 격리 패턴 | Circuit Breaker, Bulkhead | 장애 전파 방지, 복원력 확보. 마이크로서비스에서 외부 의존성 실패 시 격리 역할 수행 |
아키텍처 스타일 | Microservices, Event-Driven | 서비스 단위 분리와 확장성 확보. EDA 는 Kafka, NATS 등과 결합하여 느슨한 결합 구조 설계 가능 | |
메시징 패턴 | Pub/Sub, Event Sourcing, CQRS | 비동기 메시징, 상태 저장 분리, 이벤트 로그 기반의 복원력 있는 시스템 설계 가능 | |
운영/인프라 | 오케스트레이션 | Kubernetes, KEDA | 컨테이너 기반 자동 배포, 장애 복구, 스케일링. KEDA 는 이벤트 기반 오토스케일링에 최적화 |
서비스 메시 | Istio, Linkerd | 서비스 간 트래픽 제어, TLS 적용, 인증/인가, A/B 테스트 구성 등 서비스 통신 제어 기술 | |
장애 복구 | Self-Healing, Health Check, Leader Election | 장애 탐지 및 자동 복구 메커니즘 구현. Kubernetes 의 Liveness Probe, Kafka 의 컨트롤러 선출 등 예시 | |
모니터링/관찰성 | 시스템 모니터링 | Prometheus, Grafana | 실시간 메트릭 수집 및 시각화. AlertManager 연동으로 SLA 위반 감지 가능 |
분산 추적 | Jaeger, Zipkin, OpenTelemetry | 요청 흐름 추적, 성능 병목 식별, SLA 분석. TraceID 기반으로 메시지 경로 추적에 필수 | |
보안 | 인증 및 암호화 | TLS, mTLS, OAuth2, RBAC | 데이터 전송 암호화, 서비스 간 인증. Istio 를 통한 정책 기반 인증/인가 구성 가능 |
분산 보안 정책 | IAM, Network Policy, Zero Trust | 멀티 테넌시, 경계 없는 네트워크 환경에서 최소 권한 접근 제어 및 흐름 제어 정책 설정 필요 | |
데이터 | 데이터 복제/샤딩 | Master-Slave, Multi-Master, Sharding | 고가용성, 장애 내성 및 수평 확장성 확보. NoSQL 계열 (예: Cassandra, MongoDB, CockroachDB) 에서 핵심 |
분산 데이터베이스 | Cassandra, CockroachDB, TiDB 등 | 지리적으로 분산된 데이터 저장/읽기. Eventual Consistency 와 데이터 파티셔닝 전략 필수 이해 |
용어 정리
카테고리 | 용어 | 설명 | 관련 기술 / 개념 |
---|---|---|---|
이론 및 원칙 | CAP 이론 | 일관성 (C), 가용성 (A), 분할 허용성 (P) 중 2 가지만 동시에 만족 가능 | CA, CP, AP 모델 구분 기준 |
BASE 원칙 | Basically Available, Soft State, Eventually Consistent | NoSQL, Eventually Consistency | |
Fallacies of Distributed Computing | 분산 시스템 설계 시 흔한 오해들 (예: 네트워크는 항상 안정적이다 등) | 네트워크/지연/시계 차이 기반 설계 주의점 | |
일관성 모델 | Strong Consistency | 모든 노드에서 항상 최신 데이터를 읽음 (Linearizability 포함) | HBase, Spanner, Raft |
Eventual Consistency | 시간이 지나면 모든 노드가 일관된 상태에 수렴 | DynamoDB, Cassandra | |
Quorum | 합의나 동기화를 위해 필요한 최소 노드 수 | Paxos, Raft, Cassandra | |
합의 알고리즘 | Paxos | 고장 허용 분산 환경에서 일관성을 보장하는 복잡한 합의 알고리즘 | Chubby, etcd 내부 구성 |
Raft | 리더 선출, 로그 복제 등 구현이 쉬운 합의 알고리즘 | etcd, Consul, CockroachDB | |
데이터 설계 및 처리 | 샤딩 (Sharding) | 데이터를 여러 노드에 분산 저장하여 처리량 향상 | MongoDB, Elasticsearch |
복제 (Replication) | 동일 데이터를 다중 노드에 저장하여 내결함성과 가용성 확보 | Kafka, MySQL, Cassandra | |
Event Sourcing | 상태를 이벤트 시퀀스로 저장하며 변경 이력을 관리 | Kafka + CQRS, Axon Framework | |
CQRS | Command 와 Query 를 분리하여 확장성과 유연성 확보 | CommandBus, ReadModel | |
Saga Pattern | 분산 트랜잭션을 보상 작업으로 나누어 처리하는 트랜잭션 패턴 | Kafka Saga Orchestrator, BPMN | |
통신/미들웨어 | gRPC | 고성능 RPC 프로토콜, HTTP/2 기반 이진 통신 지원 | Istio, Envoy, microservices RPC |
메시지 큐 (Message Queue) | 비동기 메시지 전송을 위한 큐 기반 통신 구조 | RabbitMQ, SQS, Celery | |
Service Mesh | 마이크로서비스 간 통신을 추상화하여 관측, 보안, 라우팅 등을 자동화 | Istio, Linkerd, Consul Connect | |
아키텍처 패턴 | 마이크로서비스 (MSA) | 서비스 기능을 독립적으로 분리하여 유연한 배포 및 확장 가능 | Spring Boot, Kubernetes |
Sidecar Pattern | 보조 기능 (모니터링, 보안 등) 을 메인 서비스와 함께 배포 | Istio Proxy, Dapr Sidecar | |
Bulkhead Pattern | 장애 격리를 위한 리소스 분리 설계 | Thread Pool 분리, 컨테이너 단위 서비스 격리 | |
Circuit Breaker | 실패한 서비스 호출을 차단하여 장애 확산 방지 | Netflix Hystrix, Resilience4j | |
운영 및 배포 | Service Discovery | 동적 서비스 위치 탐지, 부하 분산 및 확장 지원 | Consul, Eureka, Kubernetes DNS |
Auto Scaling | 트래픽 또는 부하에 따라 자원을 자동 확장/축소 | Kubernetes HPA, AWS ASG | |
Orchestration | 컨테이너 배포·운영·확장 등을 자동화 | Kubernetes, Nomad | |
Canary Deployment | 점진적 배포 전략으로 리스크 최소화 | Argo Rollouts, Flagger | |
Blue-Green Deployment | 무중단 배포 전략. 기존과 새 환경을 번갈아 사용 | Spinnaker, Jenkins Pipeline | |
Distributed Tracing | 요청이 여러 서비스에 걸쳐 흐르는 과정을 추적 | Jaeger, Zipkin, OpenTelemetry | |
보안 및 네트워크 | Mutual TLS (mTLS) | 클라이언트와 서버가 서로 인증하는 TLS 기반 통신 | Istio 인증 정책, SPIFFE |
RBAC / ACL | 역할 기반 접근 제어 및 구체적 권한 설정 | Kubernetes RoleBinding, Kafka ACL | |
지표/운영 메트릭 | SLA (Service Level Agreement) | 서비스 성능/가용성 등에 대한 공급자와 소비자 간 합의 | MTTR, Uptime %, Availability % |
Backpressure | 소비자가 처리 불가능할 때 전송 속도를 제한 | Reactive Streams, Kafka Fetch |
참고 및 출처
- 분산 시스템 아키텍처 패턴 – DEV Community
- Google Cloud 분산 아키텍처 패턴
- Martin Fowler의 분산 시스템 패턴 카탈로그
- CAP 이론 상세 설명 – IBM
- Raft 합의 알고리즘 공식 사이트
- Netflix 마이크로서비스 아키텍처 – GeeksforGeeks
- Apache Kafka 공식 문서
- Raft 합의 알고리즘 논문
- CAP 정리 원문 – Eric Brewer (InfoQ)
- 마이크로서비스 패턴 – Chris Richardson
- 분산 시스템 보안 – Palo Alto Networks
- IBM 분산 시스템 개요
- Microsoft Azure 분산 시스템 설계 가이드 (ko)
- AWS “CAP 이론과 BASE 원칙” 블로그
- Google Cloud “분산 시스템 설계 및 운영” 문서
- InfoQ “분산 시스템의 장애 허용성” 기사
- Kubernetes와 분산 시스템 오케스트레이션
- 중앙 집중형 분산 시스템 관찰성 – Honeycomb 블로그