2PC

이벤트 소싱

이벤트 소싱은 데이터 상태 변화를 이벤트로 기록하고, 해당 이벤트들을 순차적으로 재생하여 현재 상태를 파악하는 방법

• 전통적인 데이터 저장 방식과 달리, 이벤트 소싱에서는 데이터 변경 자체가 아닌 변경 이벤트를 저장
• 복잡한 비즈니스 로직을 다루는 시스템에서 데이터 일관성과 추적 가능성을 높이는 데 유용
• 복잡성이 증가할 수 있으므로, 시스템의 요구사항에 따라 신중하게 적용

주요개념

• 이벤트(Event):
  • 데이터의 상태 변화를 나타내는 기록
  • 예를 들어, "주문 생성", "결제 완료", "주문 취소" 등이 이벤트
• 이벤트 스토어(Event Store):
  • 이벤트를 저장하는 저장소
  • 전통적인 데이터베이스 대신 이벤트를 순서대로 저장하는 스토리지. 이는 이벤트의 불변성과 순차성을 보장
• 애그리게이트(Aggregate):
  • 관련된 이벤트를 모아 현재 상태를 재현할 수 있는 엔터티
  • 애그리게이트는 도메인 모델의 일부분으로, 이벤트를 적용하여 상태를 변화
• 커맨드(Command):
  • 애그리게이트에 특정 동작을 지시하는 명령입니다. 커맨드는 이벤트를 생성하는 트리거 역할
• 프로젝션(Projection):
  • 이벤트를 읽기 모델로 변환하여 조회 성능을 최적화하는 방식
  • 이벤트를 기반으로 읽기 전용 데이터베이스를 업데이트

이벤트 소싱의 장점

• 데이터 변경 이력 추적:
  • 모든 상태 변화를 이벤트로 기록하므로, 데이터 변경 이력을 완벽하게 추적
  • 이는 감사와 디버깅에 유용
• 복구 및 재생:
  • 이벤트를 재생하여 시스템의 현재 상태를 복구
  • 이는 데이터 손실이나 시스템 장애 시 유용
• CQRS와의 자연스러운 통합:
  • 이벤트 소싱은 CQRS(Command Query Responsibility Segregation)와 잘 어울린다.
  • 명령과 조회를 분리하여 성능과 확장성을 최적화

이벤트 소싱의 단점

• 복잡성 증가:
  • 시스템 설계와 구현의 복잡성이 증가
  • 이벤트 모델링과 이벤트 스토어 관리가 필요합니다.
• 읽기 성능:
  • 이벤트를 재생하여 현재 상태를 계산해야 하므로, 읽기 성능이 저하
  • 이를 해결하기 위해 프로젝션과 CQRS를 활용할 수 있습니다.

CQRS

• CQRS는 명령(Query)과 조회(Query)의 책임을 분리하는 소프트웨어 디자인 패턴
• 이 패턴은 읽기 작업과 쓰기 작업을 서로 다른 모델로 분리하여, 각 작업에 최적화된 구조를 사용
• CQRS는 시스템의 성능, 확장성, 유지보수성을 향상시키는 데 도움이 됩니다.

주요 개념

• 명령(Command):
  • 데이터를 변경하는 작업
  • 예를 들어, 주문 생성, 결제 처리, 계정 업데이트 등이 명령에 해당.
  • 명령은 데이터베이스에 대한 쓰기 작업을 수행
  • 명령 모델은 데이터의 상태 변경을 담당
  • 이는 복잡한 비즈니스 로직을 포함할 수 있으며, 데이터 무결성을 보장하기 위해 트랜잭션을 사용
• 조회(Query):
  • 데이터를 조회하는 작업
  • 예를 들어, 주문 내역 조회, 계정 정보 조회 등이 조회에 해당
  • 조회는 데이터베이스에 대한 읽기 작업을 수행
  • 조회 모델은 읽기 전용 데이터베이스 또는 캐시를 사용하여 빠른 응답을 제공
  • 이는 단순한 데이터 조회를 위한 최적화된 구조를 가질 수 있습니다.

CQRS의 장점

• 성능 향상:
  • 읽기와 쓰기를 분리하여 각 작업에 최적화된 데이터 저장소와 인프라를 사용
  • 예를 들어, 조회 성능을 높이기 위해 읽기 전용 데이터베이스를 사용하거나, 캐시를 활용
• 확장성:
  • 읽기와 쓰기를 독립적으로 확장
  • 예를 들어, 읽기 요청이 많은 경우 조회 모델을 수평으로 확장하여 부하를 분산
• 유지보수성:
  • 비즈니스 로직이 명령 모델에 집중되므로, 복잡한 상태 변경 로직을 관리하기 쉽다. 또한, 읽기 모델은 단순화되어 유지보수하기 용이
• 데이터 일관성:
  • CQRS는 이벤트 소싱과 잘 어울린다. 이벤트 소싱을 통해 데이터 상태 변경을 이벤트로 기록하고, 이벤트를 재생하여 현재 상태를 유지할 수 있다. 이를 통해 데이터 일관성을 보장할 수 있습니다.

CQRS의 단점

• 복잡성 증가:
  • 시스템 설계와 구현의 복잡성이 증가합니다. 명령 모델과 조회 모델을 각각 설계하고 관리해야 합니다.
• 데이터 동기화:
  • 명령 모델과 조회 모델 간의 데이터 동기화가 필요. 이는 추가적인 구현과 관리가 필요.

모니터링과 로깅

• 대규모 시스템에서 모니터링과 로깅은 시스템의 안정성과 성능을 유지하는 데 필수적인 역할
• 이를 통해 시스템의 상태를 실시간으로 파악하고, 문제 발생 시 신속하게 대응
• 모니터링과 로깅 모두 다음의 항목을 주요 사항으로 봄.
  • 시스템 안정성 유지
  • 성능 최적화
  • 문제 예방 및 대응

모니터링

• 애플리케이션, DB, 캐시 등 각 컴포넌트의 성능을 모니터링
• 이를 위해 Prometheus, Grafana 같은 도구를 사용.
• 시스템의 주요 지표(TPS, 응답 시간, 에러율 등)를 모니터링하고, 이상 징후를 감지하면 알림
• 모니터링을 통해 시스템의 상태를 실시간으로 파악하고, 문제 발생 시 빠르게 대응. 또한, 모니터링 데이터를 기반으로 시스템의 성능을 분석하고, 최적화

주요사항

• 실시간 상태 파악
• 자동 알림
• 성능 분석
• 병목 지점 파
• 사전 예방
• 신속한 대응

로깅

• 애플리케이션의 주요 이벤트를 로깅하여 문제 발생 시 원인을 추적
• 로그는 Elasticsearch, Logstash, Kibana(ELK 스택) 등을 사용하여 수집, 저장, 분석
• 이를 통해 시스템의 상태를 파악하고, 문제를 해결
• 로깅은 시스템의 모든 중요한 이벤트를 기록, 문제 발생 시 정확한 원인을 파악

주요사항

• 이벤트 추적
• 디버깅 및 오류 해결:
• 패턴 분석
• 장기적 최적화
• 원인 분석
• 법적 및 규제 요구 사항 준수

테스트와 배포

• 대규모 시스템에서는 테스트와 배포도 중요한 요소
• 시스템이 정상적으로 동작하는지 확인하고, 문제 발생 시 빠르게 대응

테스트

단위 테스트(Unit Test):

• 시스템의 개별 구성 요소를 테스트하여 각 부분이 예상대로 동작하는지 확인
• JUnit, TestNG와 같은 도구를 사용하여 자동화된 단위 테스트를 작성하고 실행
• 단위 테스트는 개발 초기 단계에서 발생할 수 있는 결함을 조기에 발견하고 수정하는 데 유용

통합 테스트(Integration Test)

• 여러 구성 요소가 함께 동작하는지를 테스트. 이는 개별 구성 요소들이 올바르게 상호작용하는지를 검증
• Spring Boot에서는 @SpringBootTest 어노테이션을 사용하여 통합 테스트를 작성
• 통합 테스트는 시스템의 다양한 부분들이 함께 올바르게 동작하는지를 확인하여, 인터페이스 간의 문제를 발견하는 데 유용

부하 테스트(Load Test):

• 시스템이 높은 트래픽 상황에서도 안정적으로 동작하는지를 테스트
• Apache JMeter와 같은 도구를 사용하여 다양한 부하 시나리오를 설정하고 테스트를 수행
• 부하 테스트를 통해 시스템의 성능 한계를 파악하고, 병목 지점을 찾아 최적화

회귀 테스트(Regression Test):

• 새로운 코드 변경이 기존 기능에 영향을 미치지 않는지 확인
• 기존 테스트 케이스를 자동화하여 주기적으로 실행함으로써, 코드 변경으로 인한 결함을 방지
• 회귀 테스트는 지속적인 코드 변경에도 시스템의 안정성을 유지하는 데 중요

사용자 수용 테스트(UAT, User Acceptance Test):

• 실제 사용자 환경에서 시스템을 테스트하여, 사용자가 요구하는 기능이 모두 제대로 동작하는지 확인
• 사용자 피드백을 반영하여 시스템을 최종 조정하고, 배포 준비를 완료
• 사용자 수용 테스트는 시스템이 실제 운영 환경에서 기대대로 동작하는지 확인하는 중요한 단계

배포

지속적인 통합(CI, Continuous Integration):

• 개발자가 변경한 코드를 자주, 자동으로 빌드하고 테스트하여, 코드 변경 시점에서 발생할 수 있는 문제를 조기에 발견하고 해결
• Jenkins, GitLab CI, Travis CI와 같은 도구를 사용하여 CI 파이프라인을 설정
• CI는 코드 통합을 빠르고 효율적으로 수행하여 개발 주기를 단축시키고, 코드 품질을 높인다.

지속적인 배포(CD, Continuous Deployment):

• CI 파이프라인을 통해 검증된 코드를 자동으로 프로덕션 환경에 배포
• Argo CD와 같은 도구를 사용하여 CD 파이프라인을 설정
• CD는 코드 변경 사항을 빠르고 안전하게 프로덕션 환경에 적용하여, 새로운 기능을 신속하게 제공

Canary 배포:

• 새로운 버전을 전체 시스템에 배포하기 전에, 일부 사용자에게만 배포하여 문제가 없는지 확인
• 문제가 발생할 경우 빠르게 이전 버전으로 롤백.
• Canary 배포는 리스크를 최소화하면서 새로운 기능을 단계적으로 도입할 수 있는 방법

블루-그린 배포(Blue-Green Deployment):

• 두 개의 환경(블루와 그린)을 사용하여 하나는 현재 운영 중인 환경이고, 다른 하나는 새로운 버전을 배포하는 환경으로 사용
• 새로운 버전을 그린 환경에 배포한 후, 모든 트래픽을 그린 환경으로 전환합니다. 문제가 발생하면 블루 환경으로 빠르게 롤백
• 블루-그린 배포는 무중단 배포를 가능하게 하며, 배포 실패 시 신속한 복구를 제공.

롤링 배포(Rolling Deployment):

• 새로운 버전을 점진적으로 배포하여, 각 서버를 순차적으로 업데이트.
• 시스템 가동 시간을 유지하면서 점진적으로 새로운 버전을 도입
• 롤링 배포는 대규모 시스템에서 무중단 배포를 구현하는 데 유용