Redis Cluster에 이어 이번엔 Kafka Cluster를 구축해보도록 하자 1. Kafka ClusterKafka Cluster는 여러 개의 브로커로 구성되며 다음의 장점을 가지고 있다. 높은 확장성수평 확장을 지원하여, 필요에 따라 브로커를 추가함으로써 처리 용량을 쉽게 늘릴 수 있다.내결함성각 토픽의 데이터를 여러 브로커에 복제함으로써, 브로커가 실패하더라도 다른 브로커에서 데이터를 유지할 수 있어 시스템의 가용성을 높인다. 2. ReplicationReplication은 각 Topic의 Partition을 Kafka Cluster 내의 다른 Broker들로 복제하는 과정을 말한다. 생성된 Replication은 Leader와 Follower로 나뉘며, 이들은 ISR(In Sync Rep..

이어서 Kafka에서 메시지를 받아 소비하는 Consumer 설정을 해보도록 하자. 1. 처리량 설정Consumer의 처리량과 관련된 주요 옵션은 다음과 같다.fetch.min.bytes: 한 번에 가져올 최소 데이터 크기. 값이 커지면 처리량이 증가하지만 대기시간이 늘어난다.fetch.max.wait.ms: 데이터가 최소 크기(fetch.min.bytes)가 될 때까지 기다려야 되는 시간. 마찬가지로 값이 커지면 처리량이 증가하지만 대기시간이 늘어난다.max.poll.records: 단일 poll() 호출당 최대 레코드 수. 값이 클수록 높은 처리량을 가지지만 메모리 사용량이 증가한다.fetch.max.bytes: 한 번에 가져올 수 있는 최대 데이터 크기. 값이 커..

어플리케이션에서 Kafka로 메시지를 발행하는 Producer 설정을 해보도록 하자. 1. 처리량 설정Kafka의 Producer는 다음과 같이 Serializer를 사용해서 레코드를 byte 배열로 변환한 후 배치로 버퍼에 저장한다. 이후 Sender는 별도의 쓰레드를 통해 배치가 꽉 차거나 일정 시간이 지나면 브로커로 버퍼를 전달한다. 이때 다음의 설정들이 처리량에 영향을 준다.batch.size: 배치의 크기. 다 차게 되면 전송한다.linger.ms: 전송 대기 시간. 설정한 시간만큼 배치가 차기를 기다렸다 전송한다. 2. ACK 설정 ACK(Acknowledgment)는 메시지 전송 후 브로커로부터 받는 성공 응답을 의미한다. 설정을 통해 어떤 방식으로 응답을 받을지 정할 수 있다. 2.1...

현재 티켓핑은 대기열 관리를 비롯해 좌석 선점, 인증 정보 등 많은 서비스에서 Redis를 사용하고 있는 만큼 의존성이 크다. 그 말은 즉, Redis 서버에 이상이 생겼을 때 서비스 전체에 문제가 생긴다는 것을 뜻하는데.. 1. High Availability와 Failover고가용성(HA)은 시스템에서 최소한의 다운타임으로 지속적으로 운영될 수 있는 능력을 의미한다. 일반적으로 서버와 데이터베이스를 여러 대 운용하여 단일 실패 지점을 없애서, 한 서버에 장애가 발생하더라도 서비스가 중단되지 않도록 설계해야 한다. Failover는 시스템이나 구성 요소가 실패했을 때 자동으로 대체 시스템이나 구성 요소로 전환하는 과정을 말한다. 즉, Failover는 고가용성을 구현하는 방법 중 하나로 다음의 방식이 ..

어플리케이션의 성능을 높이기 위해 기존에 MVC를 사용하던 대기열 서비스를 WebFlux로 전환하게 되었다. 먼저 WebFlux는 MVC와 어떤 차이가 있는지 알아보자.1. MVC VS WebFlux1.1. Spring MVCMVC는 기본적으로 Thread Per Request 방식으로 동작하며 Servlet Container에서 요청을 Thread에 할당하여 Blocking 방식으로 호출하게 된다. 만약 MVC로 구성된 서버에 동시에 많은 요청이 들어오게 된다면 사용 가능한 Thread 수만큼 요청이 처리되며 Blocking IO 작업을 할 때 해당 Thread는 아무것도 하지 않고 대기하게 되어 병목 현상이 발생할 수 있다. 스레드 풀의 크기를 늘려 사용할 수 있는 스레드 수를 증가시킬 수 있지만,..

1. 동시성 문제 발견대기열 진입 API의 부하 테스트 진행 도중에 한가지 이상한 점을 발견하였다.작업열 인원 제한을 100으로 지정했음에도 불구하고 동시 테스트 시에는 다음과 같이 결과 값이 100이 넘는 것을 확인할 수 있었는데.. 동시에 많은 요청을 받게 되었을 때 발생하는 동시성 문제라는 것을 파악할 수 있었다. 문제의 원인은 코드에서 바로 찾을 수 있었는데, 현재 Redis에 저장된 작업열 인원수 Counter 조회를 통해 작업열 인원 여유를 확인하고 그에 따라 사용자를 대기열 혹은 작업열로 진입시키고 있다. 이때 여러 스레드가 동시에 작업열 인원 가능 여부를 확인하는 분기문을 통과함에 따라, 결과적으로 제한 개수 이상의 작업열 토큰이 저장되는 것이었다. @Override public Gen..

1. 스케줄러의 문제점스케줄링은 간편하게 토큰의 만료 상태를 확인할 수 있는 좋은 방법이지만, 대기열이 존재하지 않을 때에도 동작하는 만큼 비효율적인 부분이 존재한다. 이에 기존의 스케줄러를 사용하지 않고, 하나의 작업열 토큰이 만료될 때에만 토큰을 즉시 이동시킬 방법이 필요했다. 2. Redis Keyspace NotificationsRedis의 Keyspace Notifications를 사용하면 Redis에서 발생하는 이벤트를 클라이언트에게 알릴 수 있다. 다양한 이벤트 유형을 지원하며 나의 경우 작업열 토큰의 만료 이벤트를 구독할 것이다. 먼저 redis-cli에 해당 설정을 입력하자. CONFIG SET notify-keyspace-events Ex RedisConfig만료 이벤트 발생 시에 메시..

1. 작업열 토큰 TTL 도입현재의 대기열 시스템은 은행 창구 방식에서 모티브를 얻어 사용자가 예매를 완료할 때마다 대기열에서 작업열로 한 명씩 이동하고 있다. 단 이러한 방식은 작업열에서 사용자가 예매를 하지 않으면 순환이 이루어지지 않는다는 문제점이 있다. 따라서 사용자가 작업열로 이동 시에는 Redis에 TTL과 함께 토큰을 저장해 일정 시간 이후 작업열에서 토큰이 삭제되어 대기열의 순회가 이루어지도록 설계해보기로 한다. 2. 작업열 이동 스케줄러이에 토큰의 만료 상태를 어플리케이션이 알 수 있는 방법들에 대해 고민해보았는데, 첫 번째로 주기적으로 현재 작업열에 저장된 토큰 수를 세고 여유가 있는 만큼 대기열에서 작업열로 이동시키는 Job 스케줄러를 사용하는 것이었다. TokenTransferSch..