1.1 분산 컴퓨팅의 8가지 오류#

1990년대에 L. Peter Deutsch와 Sun Microsystems의 다른 사람들은 오류 목록을 작성했습니다. 분산 애플리케이션을 처음 접하는 프로그래머가 항상 위험에 빠지게 만드는 가정입니다.

CAUTION

{title=“Eight Fallacies of Distributed Computing”}

1. 네트워크는 안정적입니다. (그렇지 않습니다.)
2. 지연 시간은 0입니다. (그렇지 않습니다.)
3. 대역폭은 무한합니다. (그렇지 않습니다.)
4. 네트워크는 안전합니다. (그렇지 않습니다.)
5. 토폴로지는 변경되지 않습니다. (그렇습니다.)
6. 관리자는 1명입니다. (여러개가 있습니다.)
7. 운송비가 0입니다. (그렇지 않습니다.)
8. 네트워크는 동질적입니다. (그렇지 않습니다.) :::이 책에서 논의되는 모든 패턴, 프로토콜 및 아키텍처는 어떤 면에서 이러한 오류의 결과를 완화하기 위한 전략입니다.

1.2 고급 백엔드 엔지니어링을 위한 로드맵#

우리는 기초를 바탕으로 최신 시스템 아키텍처를 정의하는 고급 주제를 탐구합니다.

• 섹션 2: 고급 데이터 관리 및 일관성
• 섹션 3: 탄력적인 시스템 설계 패턴
• 섹션 4: 고급 비동기 통신
• 섹션 5: 대규모 성능 엔지니어링
• 섹션 6: 고급 API 및 보안 아키텍처

2.0 고급 데이터 관리 및 일관성#

하나의 데이터베이스가 있는 단일 서버 애플리케이션에서 데이터 일관성은 주로 ACID 트랜잭션을 통해 해결됩니다. 분산 시스템에서 일관성은 가장 어려운 과제 중 하나가 됩니다.

2.1 일관성 스펙트럼과 PACELC 정리#

CAP 정리는 네트워크 분할 중 동작을 설명하지만 PACELC 정리는 보다 완전한 그림을 제공합니다.

NOTE

{title=“PACELC Theorem”} “파티션(P)이 있는 경우 분산 시스템은 가용성(A)과 일관성(C) 중 하나를 선택해야 합니다. 그렇지 않으면(E) 시스템이 정상적으로 실행될 때 지연 시간(L)과 일관성(C) 중 하나를 선택해야 합니다.” :::이로 인해 미묘한 아키텍처 논의가 이루어집니다. 시스템은 장애 발생 시 가용성을 위해 일관성을 희생할 수 있지만 정상 작동 중에는 대기 시간보다 일관성을 우선시합니다.

2.2 분산 트랜잭션: 사가 패턴#

2단계 커밋은 동기식이며 마이크로서비스에 적합하지 않습니다. 사가 패턴은 로컬 트랜잭션 및 보상 작업을 통해 서비스 전반의 데이터 일관성을 관리합니다.

TIP

{title=“Saga Pattern Example: E-commerce Order”}

1. 주문 서비스: PENDING 상태의 주문을 생성하고 ORDER_CREATED 이벤트를 게시합니다.
2. Payment Service: 결제를 처리하고 성공 시 PAYMENT_PROCESSED를 게시합니다.
3. Inventory Service: 재고를 업데이트하고 성공 시 INVENTORY_UPDATED를 게시합니다.
4. 주문 서비스: 주문을 CONFIRMED로 업데이트합니다.

실패 처리: 재고가 실패한 경우 결제 서비스는 환불로 보상하고 주문 서비스는 취소합니다. :::구현 스타일:

NOTE

{title=“Saga Implementation Approaches”}

• 안무: 중앙 코디네이터 없이 이벤트 게시/구독 서비스
• 오케스트레이션: 중앙 오케스트레이터는 사가 상태 및 보상 트랜잭션을 관리합니다.

2.3 이벤트 소싱 및 CQRS#

이러한 패턴은 확장성이 뛰어나고 감사 가능한 시스템을 구축합니다.

• 이벤트 소싱: 현재 상태 대신 변경할 수 없는 이벤트를 저장합니다. 현재 상태는 이벤트 재생을 통해 파생됩니다.

NOTE

{title=“Event Sourcing Example”} “json // 잔액을 저장하는 대신: 80 // 이벤트 시퀀스 저장: [ {“유형”: “AccountCreated”, “initialBalance”: 0}, {“유형”: “DepositMade”, “금액”: 100}, {“type”: “WithdrawalMade”, “amount”: 20} ] // 현재 잔액 = 재생 이벤트 `

1
:::* **CQRS(Command Query Responsibility Segregation):** 쓰기 모델을 읽기 모델에서 분리합니다.
2

3
:::tip
4
{title="CQRS Benefits"}
5
* 쓰기와 읽기에 최적화된 다양한 모델
6
* 명령 및 쿼리 측면의 독립적인 크기 조정
7
* 별도의 컨텍스트를 사용한 더 나은 도메인 모델링

2.4 백엔드 엔지니어를 위한 데이터베이스 내부#

성능과 안정성을 위해서는 스토리지 엔진과 복제 전략을 이해하는 것이 중요합니다.

NOTE

{title=“MySQL Storage Engines”}

• InnoDB: OLTP 워크로드를 위한 트랜잭션, ACID 호환, 행 수준 잠금
• MyISAM: 빠른 읽기, 테이블 수준 잠금, 트랜잭션 없음(새로운 앱에서는 더 이상 사용되지 않음) :::복제 전략:

TIP

{title=“Replication Models”}

• 리더-팔로워: 리더에 대한 모든 쓰기, 복제본에서 읽기(가장 일반적)
• 다중 리더: 여러 노드가 쓰기를 허용하고 복제 충돌을 해결해야 합니다.
• 리더리스(Cassandra 스타일): 여러 노드에 동시에 쓰기, 쿼럼 읽기 :::트랜잭션 격리 수준(SQL):

NOTE

{title=“SQL Isolation Levels”}

1. 커밋되지 않은 읽기: 커밋되지 않은 변경 사항(더티 읽기)을 읽을 수 있습니다.
2. 커밋된 읽기: 커밋된 변경 사항만 읽습니다(반복 불가능한 읽기 가능).
3. 반복 읽기: 트랜잭션 내에서 일관된 행 값(팬텀 읽기 가능)
4. 직렬화 가능: 전체 직렬 실행(최고의 일관성, 최저 성능)

3.1 회로 차단기 패턴(심층)#

회로 차단기는 오류를 모니터링하고 분산 시스템의 계단식 오류를 방지합니다.

NOTE

{title=“Circuit Breaker States”}

• 닫힘: 정상 작동, 요청 흐름, 오류 모니터링
• 열림: 다운스트림 문제로 인해 빠르게 실패하고 재시도 전 시간 초과됨
• 반 개방: 단일 프로브 요청으로 다운스트림 복구 테스트

3.2 벌크헤드 패턴#

단일 오류가 전체 시스템에 영향을 미치지 않도록 애플리케이션 구성 요소를 풀로 격리합니다.

TIP

{title=“Bulkhead Implementation”} 각 다운스트림 서비스에 대해 별도의 스레드/연결 풀을 사용하십시오. 느린 서비스 A는 서비스 B의 풀에 영향을 주지 않아 전체 시스템 오류를 방지합니다.

3.3 재시도 및 시간 초과 패턴#

분산 시스템의 일시적인 오류를 처리하는 데 필수적입니다.

CAUTION

{title=“Retry Best Practices”}

• 시간 초과: 공격적인 시간 초과로 리소스 고갈을 방지합니다.
• 지수 백오프: 재시도 간격 증가(1초, 2초, 4초, 8초)
• 지터: 천둥소리 무리 문제를 방지하기 위해 무작위성을 추가합니다.

3.4 속도 제한 및 부하 차단#

과부하로부터 서비스를 보호하고 점진적인 성능 저하를 구현합니다.

NOTE

{title=“Rate Limiting Strategies”}

• 토큰 버킷: 요청 시 토큰이 누적되고 사용 시 제거됩니다.
• 누수 버킷: 고정 속도로 처리된 요청, 초과분은 폐기됨
• 로드 차단: 극심한 로드 상황에서 우선순위가 낮은 요청을 거부합니다.

4.1 메시지 브로커와 이벤트 로그#

뚜렷한 장단점이 있는 메시징에 대한 다양한 접근 방식입니다.

TIP

{title=“Message Broker Characteristics”}

• RabbitMQ: 스마트 라우팅, 작업 대기열, 메시지 브로커 모델
• Apache Kafka: 이벤트 스트리밍, 영구 로그, 다중 소비자

4.2 멱등성 소비자#

메시징 시스템에서 “최소 한 번” 전달을 처리하는 데 중요합니다.

NOTE

{title=“Idempotency Strategy”} “텍스트 함수 processMessage(메시지) { if (processedMessages.contains(message.id)) { 반환; // 중복 건너뛰기 }

// 메시지 처리 processBusinessLogic(메시지);

// 처리된 것으로 추적(비즈니스 로직이 포함된 원자성) 처리된Messages.add(message.id); } `

4.3 트랜잭션 아웃박스 패턴#

이벤트 중심 시스템에서 원자 데이터베이스 업데이트 및 이벤트 게시를 해결합니다.

TIP

{title=“Transactional Outbox Flow”}

1. 단일 로컬 거래에서 비즈니스 엔터티를 업데이트하고 보낼 편지함에 이벤트를 삽입합니다.
2. 메시지 릴레이는 이벤트를 비동기적으로 게시하고 전송된 것으로 표시합니다.
3. 분산 트랜잭션 없이 원자성을 보장합니다.
4. “최소 한 번” 전달 의미 체계 제공

5.1 캐싱 패턴(심층)#

기본 캐시 배제를 뛰어넘는 고급 캐싱 전략.

NOTE

{title=“Caching Pattern Comparison”}

• 캐시 제외: 앱 코드가 캐시, 지연 로딩을 관리합니다.
• Read-Through: 캐시가 DB에서 데이터 로딩을 처리합니다.
• Write-Through: 캐시 업데이트가 동기적으로 DB를 업데이트합니다.
• Write-Back: 캐시 업데이트가 비동기식으로 DB에 플러시됩니다. :::천둥 떼 완화:

CAUTION

{title=“Thundering Herd Problem”} 캐시된 항목이 만료되면 수천 건의 요청이 동시에 캐시를 놓치고 DB를 압도합니다. 솔루션: 다른 요청이 기다리는 동안 첫 번째 요청만 데이터를 로드하는 잠금 기반 다시 가져오기.

5.2 동시성 대 병렬성#

성능 최적화를 위한 기본 개념.

TIP

{title=“Workload Matching”}

• I/O 바인딩된 워크로드: 비동기 모델(Node.js, asyncio)은 많은 동시 요청을 처리합니다.
• CPU 바인딩된 워크로드: 병렬 처리(Go, Java)는 여러 코어를 활용합니다.

5.3 프로파일링 및 성능 조정#

측정할 수 없는 것은 최적화할 수 없습니다.

NOTE

{title=“Performance Profiling”} 프로파일러를 사용하여 다음을 식별하는 Flame 그래프를 생성하세요.

• 코드 실행 경로의 CPU 핫스팟
• 메모리 할당 패턴 및 누수
• I/O 병목 현상 및 대기 시간

6.1 API 게이트웨이 패턴#

클라이언트와 서비스 간의 통신을 관리하는 단일 진입점입니다.

TIP

{title=“API Gateway Responsibilities”}

• 라우팅: 적절한 마이크로서비스로 요청 직접 전달
• 인증/권한 부여: 엣지에서 자격 증명 확인
• 속도 제한: 사용 정책 및 제한 시행
• 요청 변환: 다운스트림 서비스에 대한 요청 조정
• 관찰 가능성: 중앙 집중식 로깅 및 모니터링

6.2 서비스 메시#

안전하고 빠르며 안정적인 서비스 간 통신을 위한 인프라 계층입니다.

NOTE

{title=“Service Mesh Components”}

• 사이드카 프록시: (Envoy)는 서비스당 모든 인바운드/아웃바운드 트래픽을 처리합니다.
• 컨트롤 플레인: (Istio, Linkerd)는 모든 사이드카 프록시를 구성합니다.
• 기능: mTLS, 트래픽 관리, 분산 추적, 관찰 가능성

6.3 제로 트러스트 보안#

분산 시스템에 대한 “신뢰하지 말고 항상 확인하십시오” 보안 모델.

CAUTION

{title=“Zero Trust Principles”}

• 신원 기반 인증: 출처에 관계없이 모든 요청을 확인합니다.
• 최소 권한 액세스: 필요한 최소한의 권한을 부여합니다.
• 위반 가정: 내부 손상을 예상하는 설계

6.4 JWT(심층): 위험 및 완화#

JWT 취약성 및 보안 구현 이해

CAUTION

{title=“JWT Security Issues”}

• 알고리즘 혼란 공격: 약한 알고리즘으로 서버를 속입니다.
• 완화: 강력한 알고리즘(RS256)만 허용하도록 라이브러리 구성
• 토큰 취소: 상태 비저장 토큰은 무효화될 수 없습니다.
• 완화: 빠른 캐시에서 해지 거부 목록을 유지합니다.