시스템 디자인 인터뷰를 진행하면서 준비가 필요한 항목에 대해서 좀 더 정리해보고자 한다.
대략적인 솔루션은 알고 있었겠지만, 상세한 설계에 대한 방법에 대한 준비와 정리가 필요하다.
- 요청 트래픽 제한되는 외부 서비스 연동 시스템 설계
- 분리된 다른 시스템 간 요청 거래 대사 시스템 설계
- 네트워크 구간 장애 대응 시스템 설계
- Event Driven Architecture 설계
1. 요청 트래픽 제한되는 외부 서비스 연동 시스템 설계
Requirments
결제 서비스 구현을 위해 내부 결제 시스템을 통해 외부 결제 서비스 연동이 필요한 상황이다.
외부 결제 서비스는 최대 TPS 500 트래픽만 허용한다는 제약 조건이 있을 떄,
폭발적인 트래픽 증가로 TPS 500 을 초과하더라도 외부 결제 시스템까지 정상 연동하여 동작할 수 있는 시스템을 설계해보는 것이 목표이다.
- 결제 서비스를 위해 내부 결제 시스템을 통해 외부 결제 서비스 연동 필요
- 외부 결제 서비스 최대
TPS 500트래픽 허용 TPS 500이상 초과 트래픽은 지연 처리
Solutions
Rate Limiting
Rate Limiter 처리율 제한기를 통한다면 지정한 트래픽만큼 처리하고, 그 이상의 트래픽을 거부할 수 있는 시스템 구축이 가능하다.
처리율 제한기 구현을 위해서는 Token Bucket 알고리즘, Leaky Bucket 알고리즘, Sliding Window 알고리즘 등 여러 알고리즘 적용하여 처리할 수 있다.
하지만, 처리율 제한기의 한계점은 초과 트래픽에 대한 지연 처리가 힘들다는 점이다.
초과 요청되는 트래픽을 429 Too Many Requests 상태 거부 응답 처리가 되기 때문이다.
Queueing
처리율 제한기의 한계점을 해결하기 위해서 비동기적으로 요청 트래픽을 제어할 수 있는 Queue 자료구조를 가진 시스템을 적용해보면 좋을 것 같다.
Queue 시스템을 도입한다면, 아래와 같은 다양한 장점을 가져올 수 있다.
- 비동기 처리
- 부하 분산 처리
FIFO처리- 확장성, 내구성 등
Queue 지원 Message Broker 종류는 다양하고, 대표적으로는 다음과 같다.
RabbitMQ- 다양한 메시징 프로토콜 지원
AMQP프로토콜 사용- 중소규모 처리 성능 적합
- 메모리 저장 방식으로 별도 메시지 보존 없이 소비 후 삭제
Queue단위 메시지 순서 보장- 까다로운 클러스터링 구성
Apacche Kafka- 대규모 데이터 스트림 실시간 분산 처리 지원
TCP기반 자체 프로토콜 사용- 높은 데이터 처리량 보장
- 디스크 로그 저장 방식으로 설정 기간 동안 메시지 저장 유지
- 파티션 단위 메시지 순서 보장
- 비교적 편리한 클러스터링 구성
Amazon SQS- 클라우드 완전 관리형 서비스
- 간단한 구현과 높은 가용성 보장
2. 분리된 다른 시스템 간 요청 거래 대사 시스템 설계
Requirments
결제 서비스를 통해 결제 완료된 거래에 대해서는 정산 처리가 필요하다. 결제 완료 거래에 대한 정산 처리를 위해 정산 서비스를 별도로 구현하였을 떄, 결제 서비스와 정산 서비스 간의 요청 거래 대사 시스템 설계해보는 것이 목표이다.
- 결제 완료 거래를 결제 서비스에서 정산 서비스로 요청 거래 대사 필요
3. 네트워크 구간 장애 대응 시스템 설계
서비스 네트워크 장애 대응
대부분 모든 서비스를 단일 애플리케이션에서 모든 기능을 구현/수행하지 않는다.
특히, MSA 구조의 서비스라면 도메인 별로 서비스가 분리되어 있고, 분리된 서비스 간 네트워크 통신은 복잡하고, 많아진다. 그리고, 외부 서비스 연동과 같은 대외계 네트워크 통신까지 필요로 할 수 있다.
네트워크 구간에 대한 시스템 장애에 대한 대응책을 정리해보고자 한다.
Circuit Breaker패턴 &Retry매커니즘 적용Message Broker활용한 비동기 네트워크 시스템 적용
Circuit Breaker 패턴 & Retry 매커니즘 적용
Circuit Breaker 패턴
Circuit Breaker는 MSA 구조의 대표적인 장애 대응 패턴 중 하나이다.Circuit Breaker의 주요 목적은 다음과 같다:- 장애 전파 방지 : 한 서비스의 장애가 전체 시스템으로 확산되는 것을 막는다.
- 빠른 실패 처리 : 장애 상황에서 빠르게 대체 응답을 제공하여 사용자 경험을 개선한다.
- 시스템 복구 지원 : 장애 서비스에 대한 요청을 일시적으로 차단하여 복구 시간을 확보한다.
- 시스템 안정성 향상 : 과부하 상황에서 시스템을 보호하고 전반적인 안정성을 높인다.
Circuit Breaker는 요청을 하는 클라이언트보다 요청을 받아 처리하는 서버 측에서 구현한다.
Retry 매커니즘
Retry매커니즘은 일시적인 네트워크 오류나 서비스 불안정으로 인한 실패를 극복하기 위한 전략이다.Retry매커니즘의 주요 특징은 다음과 같다:- 재시도 횟수 제한 : 무한 재시도를 방지하기 위해 최대 재시도 횟수를 설정한다.
- 지수 백오프 : 재시도 간격을 점진적으로 늘려 서버 부하를 줄인다.
- 재시도 조건 설정 : 특정 오류 코드나 예외에 대해서만 재시도를 수행한다.
- 타임아웃 설정 : 각 시도마다 적절한 타임아웃을 설정하여 응답 지연을 방지한다.
- 실패 로깅 : 재시도 실패 시 로그를 남겨 추후 분석에 활용한다.
Retry매커니즘은Circuit Breaker와 함께 사용하여 더 강력한 장애 대응 시스템을 구축할 수 있다.
Resilience4j
Resilience4j는Java애플리케이션을 위한 경량화된 장애 허용 라이브러리이다.- 이전에는
Netflix Hystrix를 주로 사용하였지만,Hystrix라이브러리가 적용하기에 무겁고,Maintenance단계로 더이상 신규/개선 개발되지 않는 문제로,Resilience4j로 대체되었다.
- 이전에는
Resilience4j의 주요 제공 기능은 다음과 같다:Circuit Breaker: 서비스 장애 시 빠른 실패 처리와 시스템 복구를 지원합니다.Retry: 일시적인 오류에 대해 자동으로 재시도를 수행합니다.Rate Limiter: 특정 시간 동안의 요청 수를 제한하여 시스템 과부하를 방지합니다.Bulkhead: 동시 실행 가능한 작업 수를 제한하여 리소스 고갈을 방지합니다.Time Limiter: 작업 실행 시간을 제한하여 장기 실행 작업으로 인한 문제를 방지합니다.Cache: 결과를 캐싱하여 반복적인 호출을 최적화합니다.
Spring.io에서 개발되는Spring Cloud Gateway프레임워크에서 제공되는Circuit Breaker기능 역시Resilience4j라이브러리를 활용하여
Message Broker 활용한 비동기 네트워크 시스템 적용
서비스 네트워크 장애를 방지하기 위해서는 서비스 간 느슨한 결합 구조도 설계의 중요한 부분이다.
Message Queue 또는 Message Broker 를 활용하여 서비스 간 비동기 메시지 전달하고,
이를 통해 전체 시스템의 서비스 결합도를 낮추고, 확장성과 안정성을 높일 수 있다.
Message Queue 메시지 큐는 Producer 생산자에 의해 발행된 메시지를 저장하였다가
Consumer 소비자가 순차적으로 수신하여 처리하는 FIFO 기반 비동기적인 서비스 흐름을 구현하도록 지원한다.
Message Broker 메시지 브로커는 메시지 큐와 같이 메시지를 저장하고 처리하는 방식이지만,
메시지 라우팅, Pub/Sub 메시징 패턴 외 Point-to-Point 메시징 패턴 지원, 트랜잭션 관리 등 보다 다양한 기능을 제공하고 있다.
Apache Kafka
- 분명 Kafka 가 더 대규모 분산 처리와 성능 측면 우월한 것은 알겠는데,
- 정확히 어떤 차이점을 가지고 있는지 알아야 할 필요가 있다!
- 그리고, 시스템 데이터 대사 프로세스에 대한 대응 방안 꼭 생각해보자!
DB 네트워크 장애 대응
서드-파티 서비스 네트워크 장애 대응
4. Event Driven Architecture 설계
- 애플리케이션 내부 Event 처리
- 애플리케이션 외부 Event 처리
