• Redisson

선택지

• 비관적 락
• 낙관적 락 | Redisson
• Pub/Sub 방식으로 락을 구현하고, 락 만료 설정, 락 획득 재시도 로직 등을 설정하여 락을 자동으로 해제시켜줄 수 있는 Redisson을 사용하기로 결정했습니다.

~~낙관적 락~~

• 9시마다 열리는 랜덤 세일 이벤트의 시나리오를 생각해본다면 트래픽이 몰려 락 획득을 위해 치열하게 싸울 것을 상상 할 수 있다. 이 경우 버전을 통해 재시도를 반복하며 db를 업데이트하는 낙관적락은 효율이 좋지 않을 것이라 판단해서 제외했습니다.

~~비관적 락~~

• 비관적락은 충돌이 많을 경우 롤백의 횟수를 줄일 수 있어 낙관적 락 보다는 성능이 좋지만, 트래픽이 몰리는 서비스의 특성상 Database 자체에 락을 걸게되면 성능이 떨어질 것을 염두하여 제외 하였습니다. | ‣ | | 성능 테스트 | 선택한 기술
• Apache Jmeter
• Prometheus
• Grafana

선택지

• PinPoint | Apache Jmeter Jmeter는 opensouce tool이기 때문에 사용함에 있어서 비용이 발생하지 않고, 사용하기 쉬운 GUI를 제공합니다. 또한 오래된 tool이기 때문에 저희가 참고할 수 있는 자료도 많고 결과도 직관적으로 볼 수 있어서 JMeter를 사용했습니다.

Prometheus Prometheus는 모니터링 하기 원하는 리소스로부터 metric을 수집하고 해당 metric을 이용해서 모니터링하는 기능을 제공합니다. 따라서 서버가 현재 사용하고 있는 리소스들을 직관적으로 볼 수 있기 때문에 부하를 줄 경우 서버에 어느 정도 부담이 가는지 확인하기 위해서 사용했습니다.

Grafana Grafana는 멀티플랫폼 오픈 소스 시각화 웹 애플리케이션입니다. Prometheus 자체만 사용할 때 데이터를 분석함에 있어서 직관적이지 못해서 어려움을 겪을 수 있기 때문에, Grafana를 활용해 해당 정보를 쉽게 시각화할 수 있는 Grafana를 Prometheus에 연동해서 사용했습니다.

PinPoint Pinpoint는 코드 수준의 정보를 추적하는데, 트래픽이 많으면 많을수록 데이터의 양이 폭발적으로 증가한다는 단점이 있습니다. 따라서 저희가 Jmeter를 활용해 부하를 줄 경우 많은 트래픽이 발생하는데 그러한 데이터를 처리하지 못할 것으로 판단해서 Pinpoint를 사용하지 않았습니다. |

‣ ‣ | | CI/CD | 선택한 기술

• Github Actions
• Docker
• CodeDeploy

선택지

• Jenkins | Github Actions CI/CD의 주 목적은 코드 변경이 자주 발생하는 개발 환경에서도 안정적인 자동 배포를 활성화하는 것입니다. 저희 프로젝트는 GitHub을 코드 저장소로 사용하고 있으며, 각 코드 변경마다 자동으로 테스트와 배포를 수행해야 했습니다. 이에 대한 비용 문제도 고려해야 했기 때문에 추가적인 지출은 최소화하고자 했습니다. GitHub Actions는 EC2와 편리하게 연동이 가능하며, 설정과 문제 해결에 도움이 되는 풍부한 레퍼런스와 문서가 있기 때문에 이를 선택했습니다.

Docker 애플리케이션 환경에 구애 받지 않고 실행하기 위해서입니다. 도커만 깔아둔 상태이고, 도커 이미지를 생성해 놓은 상태면 다른 설정 필요 없이 바로 서버를 돌릴 수 있기 때문에 CI/CD구축에 있어 매우 편리하게 사용할 수 있기에 사용했습니다.

CodeDeploy 기존 Github Actions 과 Docker 로만 배포 자동화를 구성하였고 Auto Scaling 이후 자동 생성되는 인스턴스에 자동화 배포를 위한 추가적인 작업이 필요하였고 CodeDeploy 가 연동과 설정이 상대적으로 복잡하지 않기에 선택하였습니다.

Jenkins Jenkins는 사용하려면 별도의 서버가 필요하고 이에 따른 비용이 발생하고, 처음 사용함에 있어서 설정하는 것이 상대적으로 어렵기 때문에 Github에서 제공하는 GitHubAction을 사용했습니다. | ‣ | | 검색 성능 개선 | 선택한 기술

• Full-Text Index
• Elastic Search
• Logstash

선택지

• QueryDSL | Full-Text index 상품 카테고리에 대한 Keyword 검색을 하려면 LIKE ‘%[입력단어]% 로 검색을 해야 하는데 INDEX의 특성 %단어후방 탐색에 대한 인덱스 생성이 불가 하기에 전문 검색에 특화된 Full Text Index를 적용 했습니다.

Elasticsearch Elasticsearch는 분산형 Restful 검색 및 분석 엔진입니다. RDBMS에서 %LIKE%쿼리를 날릴 경우 효율이 매우 떨어져 대량의 데이터에 접근할 경우 속도가 많이 떨어지고 리소스도 많이 차지해 이를 해결하기 위해서 사용했습니다.

Logstash Logstash는 RDBMS에 저장되어 있는 데이터를 Elastic Search에서 사용할 수 있는 데이터로 가공해서 Elastic Search에 전송해 RDBMS와 Elastic Search간의 데이터 정합성을 맞추는 데 활용했습니다.

QueryDSL | ‣ ‣ | | 상품 조회 성능 개선 | 선택한 기술

• Redis | Redis 상품 조회는 프로젝트의 핵심 기능 중 하나로, 주문 프로세스에 필수적인 과정입니다. 이 과정에서 자주 변경되지 않는 상품 정보를 캐시에 저장하여 데이터베이스에 직접적인 부하를 줄이고, 동시에 사용자에게 빠른 응답 시간을 제공하고자 합니다. 이를 위해 우리는 Redis를 도입하여 효율적인 캐싱 전략을 채택했습니다. Redis를 사용함으로써 안정적이고 확장 가능한 캐시 메커니즘을 확보하며, 사용자 경험을 향상시키는 데 기여할 것으로 기대합니다.

Look Aside Cache 저희가 현재 수집한 제품 정보는 샘플로서 안정적으로 변화하지 않을 것으로 예상됩니다. 이에 따라 프로젝트에서는 Look Aside Cache를 적용하여 제품 정보에 대한 요청에 대한 응답 속도를 향상시키고, 불필요한 데이터베이스 조회를 최소화하고자 합니다. Look Aside Cache는 데이터의 변경이 적고 읽기 중심인 경우에 효과적으로 사용될 수 있는 캐싱 전략 중 하나이기 때문에 해당 전략을 선택했습니다.

~~Read Through~~ 데이터가 캐시에 없을 경우 먼저 데이터 소스에서 조회한 후 캐시에 저장합니다. 하지만 해당 프로젝트에서는 자주 변경되지 않는 상품 정보를 대상으로 하고 있으며, 두 번의 조회를 피하기 위해 바로 캐시에서 데이터를 반환하는 방식을 택했습니다. 또한 Read Through 방식은 데이터 조회를 전적으로 캐시에만 의지하므로, 캐시 서버에 문제가 발생할 경우 본 서버에도 영향을 미칠 수 있습니다. 이러한 의존성을 줄이고 서버의 신뢰성을 강화하기 위해 데이터 소스에서 직접 조회하는 방식을 택했습니다. | ‣ ‣ | | 주문 성능 개선 | 선택한 기술

• Apache Kafka 선택지
• rabbitMQ | Kafka 트랜잭션을 줄이고 비동기적으로 데이터베이스에 저장할 수 있고 이벤트 재처리가 가능 하기 때문에 RabbitMQ 보다 정합성을 보장할 수 있고 다양한 기능들을 설정 하지 않아도 RabbitMQ보다 처리량이 높고, 수평 확장이 쉽다는 장점을 가지고 있어 kafka를 사용 했습니다.

RabbitMQ 메시지 전달 성공 이후 문제 발생시 재처리가 힘들고 성능 최적화를 위해 복잡한 설정이 필요해 RabbitMQ를 사용하지 않았습니다. | ‣ | | 대용량 트래픽 분산 처리 | 선택한 기술 Auto Scaling Load Balancing | Auto Scaling 수직 확장(Scale-up)으로만 성능의 한계가 존재하며 성능을 높이기 위해 비싼 하드웨어로 업그레이드해도 가격 대비 성능 향상이 제한적입니다. 따라서 Scale-out을 통해 확장하고, 부하에 따라 서버를 Scale-in하여 서버 비용을 더 유연하게 조절할 수 있습니다.

Load Balancing 로드 밸런서는 서버로부터의 요청(트래픽)을 균등하게 분산하는 기술로, 부하 관리를 용이하게 해주며, 장애 시 복구와 확장성을 지원합니다. 이러한 특성은 Auto Scaling과 함께 사용하여 FlashFrenzy 프로젝트에 효과적으로 적용할 수 있습니다. | ‣ | | Scheduler 의 데이터 처리 작업 개선 | 선택한 기술

• Lambda

선택지

• Spring Batch | Lambda 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스, Serverless 한 특징을 가지고 있는 AWS 람다를 사용 하였습니다. Auto Scaling을 통해 Scale-Out 하는 과정에서 불필요한 서버의 리소스가 낭비되는 Flash Frenzy 프로젝트에서 적합하다고 판단하였습니다.

~~Spring Batch~~ Spring Batch의 경우 작동될 때 대량의 데이터에 접근시에 많은 메모리를 사용하는데, 현재 대량의 데이터를 다루는 것을 목표로 1000만 데이터를 DB에 저장시켜 놓고 사용하고 또 스케쥴러에서 해당 DB에 접근하기 때문에 저희 프로젝트와는 적합하지 않다고 생각하여 채택하지 않았습니다. | ‣ |

Redisson 을 선택한 이유

• Redisson 이외의 선택지

  • 비관적 락, 낙관적 락

  • 9시마다 열리는 랜덤 세일 이벤트의 시나리오를 생각해본다면 트래픽이 몰려 락 획득을 위해 치열하게 싸울 것을 상상 할 수 있다. 이 경우 버전을 통해 재시도를 반복하며 db를 업데이트하는 낙관적락은 효율이 좋지 않을 것이라 판단해서 제외했고,

  • 비관적락은 충돌이 많을 경우 롤백의 횟수를 줄일 수 있어 낙관적 락 보다는 성능이 좋지만, deadlock이 발생할 수 있어 제외 하였습니다.

  • Pub/Sub 방식으로 락을 구현하고, 락 만료 설정, 락 획득 재시도 로직 등을 설정하여 락을 자동으로 해제시켜줄 수 있는 Redisson을 사용하기로 결정했습니다.

Jmeter , nGrinder, K6

• Jmeter는 Apache에서 만든 오픈소스 소프트웨어이고, 1990년대에 나온만큼 안정화되고 문서도 많은 오픈소스입니다.

• 장점

  • 자주 버전을 릴리즈 하며, 버그 및 성능 개선이 그만큼 자주 일어나는 소프트웨어입니다.
  • 다양한 플러그인 제공합니다.

• 단점:

  • 오래된 만큼 안정적이긴 하지만, 가독성이 좋지 않은 문서들이 많습니다.
  • GUI 모드에서 많은 메모리 사용 - 성능테스트를 할 때 GUI를 사용하는 것은 권장하지 않습니다.

• K6는 Grafana Labs에서 만든 소프트웨어, 자바스크립트로 이루어져 있습니다.

  • 장점
    • 깔끔한 공식 문서가 제공됩니다..
    • 메모리 사용이 적습니다.
    • 다양한 GUI를 제공합니다.
  • 단점
    • 기본적으로 부하 분산 테스트를 제공하지 않음 - 부하 분산, 대용량 트래픽을 테스트하기 위해서 k6 operator, 쿠버네티스 같은 툴들을 같이 사용해야 할 수 있습니다.

• Ngrinder - 네이버에서 만든 오픈소스입니다.

  • 장점
    • 자바 스크립트와 비슷한 스크립트 언어를 지원합니다.
    • 한국어 지원합니다.
    • 완성도 높은 뼈대코드를 지원합니다.
    • 가독성 좋은 GUI가 존재합니다.
  • 단점
    • 분리된 프로세스
    • 테스트 스크립트 IDE 지원하지 않습니다.

Log4j2, Logback

• Lofg4j2가 약간 성능상으로 우수하다고는 하지만, 새로 의존성을 추가해줘야 한다는 것과,

데이터 파이프라인 Kafka vs RabbitMQ

Kafka 기술 선택 : 트랜잭션을 줄이고 비동기적으로 데이터베이스에 저장할 수 있고 이벤트 재처리가 가능 하기 때문에 RabbitMQ 보다 정합성을 보장할 수 있고 다양한 기능들을 설정 하지 않아도 RabbitMQ보다 처리량이 높고, 수평 확장이 쉽다는 장점을 가지고 있어 kafka를 선택하였다.