미리보기

https://github.com/woowa-techcamp-2024/Team5-Guys

기술 스택: Spring Boot, JDBC, MySQL, Docker(docker-compose), AWS(EC2, RDS, VPC)

• 우아한 테크캠프 7기에 참여하여 만든 관리형 중앙 로그 수집 SaaS

• 부하 테스트를 통해 병목을 발견하고, 최적화를 지속적으로 진행하여 1시간 이상의 고부하 요청에도 초당 50,000개의 로그를 안정적으로 저장할 수 있도록 개선

• 로그를 전송할 수 있는 Client인 Java SDK (Logback Appender) 개발, JavaScript SDK 제공

• 데모데이 우아한형제들 구성원 투표 1위 달성, 우아한 기술 블로그 게시 : https://techblog.woowahan.com/19370/

로그 처리 서버 성능 점진적 개선

1. DB 커넥션의 효율성을 위해 서버 측 Bulk Insert 도입

로그 저장 요청이 증가하면 DB 커넥션이 부족해지는 현상 발생

• 서버 내 로그 큐를 두고 리더 스레드와 워커 스레드 풀을 이용하여 Bulk Insert 도입

• 리더 스레드는 로그 큐를 감시하여 로그를 모아서 워커 스레드로 넘겨주는 역할

• 워커 스레드는 Bulk Insert 수행

  • 로그 초당 500개 -> 초당 3,100개로 개선

2. 클라이언트 부하 감소를 위해 SDK 측 배치 전송 도입

클라이언트에 로그 발생량이 빈번해질 경우 클라이언트 애플리케이션 성능에 영향을 미침

• SDK에 버퍼를 추가하여 로그를 100개씩 ScheduledExecutorService로 배치 전송하도록 개선

  • 로그 초당 3,100개 -> 초당 15,000개로 개선

3. 로그 큐 삽입 시 Lock 경쟁 최적화

Tomcat 스레드에서 로그 큐에 Lock을 100회씩 요청하여 경쟁이 심화되어 응답 시간 저하

• 큐에 로그 추가를 전담하는 싱글 스레드를 도입하여 Lock 경쟁을 제거

• 전담 스레드에서 로그 큐에 List<Log> 를 addAll 하도록 변경

• 경쟁 상태가 제거되어 동기화되지 않은 큐로 변경

  • Lock 경쟁이 최대 1/100으로 감소

  • 로그 초당 15,000개 -> 초당 17,000개로 개선

  • 응답 시간: 평균 500ms -> 평균 200ms로 개선

4. 리더 스레드의 busy waiting 제거를 통한 CPU 사용량 최소화

로그 큐를 감시하는 리더 스레드가 busy waiting 하여 CPU 사용량이 과도하게 증가

• ReentrantLock과 Condition을 이용하여 Bulk Size 이하일 경우 소비자가 await, Bulk Size 이상일 경우 생산자가 signal 호출하도록 변경

  • busy waiting이 제거되어 로그 요청이 적은 상황에서 CPU 사용량 대폭 감소

5. 로그 큐 수평 확장으로 처리량 최적화

단일 로그 큐를 사용함에 따라 동시 처리량의 한계가 발생

• 기존 단일 [싱글 스레드 – 큐 – 싱글 스레드] 구조를 3개로 확장하여 로그 큐의 부하 분산

• AtomicLong을 사용한 round-robin 방식에서는 병목이 발생할 것으로 예상되어 ThreadLocalRandom을 통해 큐 선택 시의 경쟁 조건을 제거

  • 로그 초당 17,000개 -> 초당 50,000개로 개선

  • 응답 시간: 평균 200ms -> 평균 50ms 이하로 개선

디버깅을 위해 고부하 환경에서 성능 저하 없이 요청이 처리된 횟수를 카운팅하는 ThreadLocalLongAdder 개발

• 각 스레드 내에 처리 횟수를 기록하여 경쟁 상태가 발생하지 않는 고성능 카운터 개발

  • 스레드 1,000개, 스레드 별 10,000,000번 증가 연산을 하는 데 평균 10초 소요 (LongAdder의 경우 7분 소요)

https://morandi.co.kr/ (시즌 1)

https://github.com/SWM-Morandi/NewMorandi-Backend/tree/dev (시즌 2)

기술 스택: Spring Boot, JPA, MariaDB, Redis, Docker(docker-compose), AWS(EC2, ECR, S3, RDS, VPC)

• SW Maestro 14기에 참여하여 만든 코딩 테스트 실전 모의고사 플랫폼

• 모두의 랜덤 디펜스는 ‘백준’과 연동되는 코딩 테스트 실전 모의고사 플랫폼

• 누적 사용자 500명 이상을 달성, 1,000회 이상의 모의고사가 진행

제한 시간 후 시험을 종료하는 타이머 기능에서 스레드 부족 현상 발생

• ScheduledExecutorService를 이용하여 정해진 수의 스레드로 타이머 구현

• 트랜잭션의 롤백과 타이머가 동기화되지 않는 문제가 발생하여 TransactionalEventListener를 이용하여 커밋 이후에 타이머를 동작시키도록 구현

문제 메타 데이터 업데이트 시 외부 API 호출 수가 과도하게 증가

API 호출 수를 줄이기 위해 배치 처리 단위를 Item -> List<Item>으로 묶어서 처리할 수 있는 도메인 특화 Reader 개발

• 호출 수 30000번 -> 600번으로 감소

시험 요청 중복 도착으로 시험이 동시에 여러 번 실행되는 문제 발생

• Client에서 API 요청이 의도치 않게 여러 번 도착하는 것을 서버 단에서도 처리하기 위해 락 도입

  • 어노테이션 기반 AOP와, scale-out을 대비하여 Redis를 사용하여 동시성 제어

테스트 코드를 통해 휴먼 테스트로 오는 비효율성 개선

• 280개의 단위 / 통합 테스트를 작성.

백준의 공식 API 미제공으로 채점 시스템 연동 불가

• 백준의 채점 서비스를 통합할 수 있도록 채점 파이프라인 솔루션 설계 및 구현. [링크]

수동 배포 작업의 비효율 개선을 위해 배포 자동화

Java (OpenJDK)

OpenJDK 메일링 리스트에 LinkedBlockingQueue일반 모드와 ArrayBlockingQueue의 일반모드, 공정모드에서 AbstractQueuedSynchronizer와 Condition 대기 공간의 분리로 발생할 수 있는 스레드 starvation으로 FIFO 위반 가능성 제안 (2024.09.04 ~ )

• 최초 이슈 제기

• 문제 상세 설명

ArgoCD

ArgoCD hydrator 유닛 테스트 작성 (2024.08.11) [링크]