Antigravity Agent
63 lines
5.7 KiB
Markdown
63 lines
5.7 KiB
Markdown
---
|
|
category: Unified
|
|
tags: [auto-consolidated, technical-documentation]
|
|
title: [[Distributed-Systems|Distributed-Systems]]
|
|
last_updated: 2026-05-02
|
|
---
|
|
|
|
# [[Distributed-Systems|Distributed-Systems]]
|
|
|
|
## 📌 Brief Summary
|
|
> "하나처럼 움직이는 여럿: 여러 대의 컴퓨터가 네트워크로 연결되어 사용자에게는 하나의 시스템처럼 보이지만, 실제로는 작업을 나누어 처리하고 일부가 고장 나도 멈추지 않는 현대 인터넷 제국의 엔진이자 뼈대."
|
|
|
|
## 📖 Core Content
|
|
분산 시스템(Distributed-Systems)은 독립된 다수의 컴퓨터(노드)가 서로 협력하여 하나의 공동 목표를 수행하는 하드웨어/소프트웨어 아키텍처입니다.
|
|
|
|
1. **3대 핵심 난제 (CAP Theorem)**:
|
|
* **Consistency (일관성)**: 모든 노드가 항상 같은 데이터를 보여줘야 함.
|
|
* **Availability (가용성)**: 일부 노드 장애 시에도 서비스는 계속 되어야 함.
|
|
* **Partition Tolerance (분할 내성)**: 노드 간 네트워크 통신이 끊겨도 작동해야 함. (셋 중 둘만 완벽히 가질 수 있다는 이론)
|
|
2. **왜 중요한가?**:
|
|
* 단일 서버로는 감당할 수 없는 빅데이터와 폭발적 트래픽을 감당하는 유일한 방법임. (Scalability의 근간)
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
- **과거 데이터와의 충돌**: 과거에는 관리의 편의를 위해 '거대 단일 서버 정책(Monolithic)'을 선호했으나, 현대 정책은 유연성과 생존력을 위해 작게 쪼개어 분산하는 '클라우드 네이티브 정책(Microservices)'으로 전환됨(RL Update).
|
|
- **정책 변화(RL Update)**: AI 학습 정책에서, 수만 개의 GPU가 하나로 묶여 거대 모델을 학습하는 '분산 훈련 정책'이 국가적 경쟁력의 지표가 되고 있음.
|
|
|
|
## 🔗 Knowledge Connections
|
|
- [[Scalability|Scalability]], [[Blockchain|Blockchain]], Load Balancing, [[Technical-Architecture|Technical-Architecture]], [[Internet of Things (IoT)|Internet of Things (IoT)]]
|
|
- **Modern Tech/Tools**: Redis, Kafka, Cassandra, Kubernetes, gRPC.
|
|
---
|
|
|
|
---
|
|
|
|
- [[Microservices_Architecture]]: 분산 시스템 사상을 현대적으로 구현한 대표적 아키텍처 스타일.
|
|
- [[Event_Driven_Architecture]]: 분산 노드 간의 느슨한 결합을 구현하는 비동기 통신 방식.
|
|
- [[Cloud_Native_Patterns]]: 분산 시스템을 효율적으로 관리하기 위한 플랫폼 기술 및 패턴.
|
|
|
|
|
|
## 1. 개요
|
|
분산 시스템 아키텍처는 애플리케이션의 기능을 단일 프로세스가 아닌, 네트워크를 통해 상호작용하는 자율적인 여러 노드(서비스)로 분산하여 구성하는 방식이다. 이는 시스템의 무한한 확장성과 고가용성을 제공하지만, 네트워크 지연, 부분적 장애, 데이터 일관성 유지 등 단일 노드 환경에서는 존재하지 않던 고도의 기술적 복잡성을 수반한다.
|
|
|
|
## 2. 분산 환경의 핵심 과제와 해결 패턴
|
|
- **장애 대응 및 복원력 (Resilience)**: 네트워크 장애나 특정 노드의 다운은 '발생할 수 있는 일'이 아니라 '반드시 발생하는 일'로 간주한다.
|
|
- **회로 차단기 (Circuit Breaker)**: 장애가 발생한 서비스로의 요청을 일시적으로 차단하여 연쇄 장애 전파 방지.
|
|
- **재시도 및 타임아웃 (Retries & Timeouts)**: 일시적 네트워크 오류에 대응하고, 무한 대기로 인한 자원 고갈 방지.
|
|
- **벌크헤드 (Bulkhead)**: 서비스 내부 자원(스레드 풀 등)을 격리하여 특정 기능의 부하가 전체 서비스에 영향을 주지 않도록 차단.
|
|
- **데이터 일관성 (Consistency)**: 분산된 데이터베이스 간의 물리적 정합성을 실시간으로 유지하기 어려우므로, 결과적 일관성(Eventual Consistency)과 사가(Saga) 패턴 등을 활용한 보상 트랜잭션 설계 적용.
|
|
- **분산 트레이싱 (Distributed Tracing)**: 여러 서비스를 관통하는 하나의 요청 흐름을 추적하기 위해 상관관계 ID(Correlation ID)를 활용한 전 구간 가시성 확보.
|
|
|
|
## 3. 엔지니어링 가치
|
|
- **수평적 확장성 (Scalability)**: 트래픽 증가 시 특정 노드를 추가하는 것만으로 시스템 전체의 처리 성능을 선형적으로 증대 가능.
|
|
- **지리적 가용성**: 서버를 여러 지역(Region)에 분산 배치하여 사용자에게 낮은 지연 시간을 제공하고 지역적 재난 상황에서도 서비스 유지.
|
|
- **기술적 유연성**: 각 노드별로 비즈니스 요구사항에 최적화된 프로그래밍 언어, 프레임워크, 데이터베이스 스토리지 선택 가능.
|
|
|
|
## 4. 트레이드오프 및 주의사항
|
|
- **관측의 어려움**: 시스템의 논리가 여러 저장소와 프로세스에 파편화되어 있어, 전체적인 실행 흐름을 파악하기 위한 인지적 부하와 모니터링 인프라 구축 비용이 매우 높음.
|
|
- **테스팅 복잡도**: 단일 노드에서의 단위 테스트만으로는 부족하며, 서비스 간의 상호작용과 네트워크 실패 시나리오를 포함한 정교한 통합 테스트 및 카오스 엔지니어링(Chaos Engineering) 요구됨.
|
|
- **네트워크 오버헤드**: 내부 함수 호출에 비해 네트워크를 통한 통신은 수백~수천 배의 지연 시간을 발생시키므로, 빈번한 통신을 최소화하는 조립성(Cohesion) 있는 경계 설계 필수.
|
|
|
|
## 🧪 검증 상태 (Validation)
|
|
- **정보 상태**: 검증 완료 (Verified)
|
|
- **출처 신뢰도**: A
|
|
- **검토 이유**: 대규모 트래픽과 가용성 요구사항을 충족하기 위한 분산 컴퓨팅의 원리를 이해하고, 네트워크 불확실성에 대응하는 견고한 시스템 설계 표준 정립. |