백엔드 개발자 블로그

테크 블로그에서 사용하는 대용량 트래픽 처리 전략을 정리해보았습니다. 하나씩 기존 프로젝트에 적용해보면서 성능 개선해볼 예정입니다. 1. CDN 2. Load Balancer + Scale Out 3. Scale Up 4. 비동기, 논블로킹Spring WebfluxMessage Queue5. DB 처리 속도 높이기캐싱인덱싱역정규화샤딩낙관적 락CQRS실행 계획 분석Stored Procedure 6. MSA 7. 장애로 인한 자원 점유 시간 줄이기서킷 브레이커time out 설정 8. gRPCMSA로 인해 서버가 많은 경우 적용 9. DB ReplicaMaster : 쓰기 + 동기화Slave x n : 읽기

요즘 신입 채용공고를 보면 대용량 트래픽 처리 역량을 요구하는 곳이 점점 많아지고 있습니다. 우아한테크에서는 대용량 트래픽을 어떻게 처리하고 있는지 정리해보면서 이해도를 키우기 위한 글입니다.https://www.youtube.com/watch?v=704qQs6KoUk 상황일평균 300만 건 이상의 트래픽이 발생 + 12:00, 18:30에 트래픽이 몰림문제 상황1. 단일 장애 포인트중앙집중 저장소에 모든 시스템이 의존하고 있음 하나의 시스템 에러 > 중앙집중 저장소에 부하 발생 > 다른 시스템에도 에러 발생 해결책MSA + MQ각 시스템으로 나누고, 통신은 Message Queue기반으로 통신시스템에 에러가 발생해도 이벤트를 재발행하면 끝이라서 장애가 전파가 안됨 2. 대용량 데이터조회시 JOIN 연산..

OOM 발생컨텍트 렌즈 온라인 플랫폼 관리자 앱에서, 송장 정보 일괄 입력을 위해 CSV 파일 처리 기능을 구현했습니다. 초기 테스트에서는 10MB 미만 파일만 다뤘지만, 운영 환경과 유사하게 200MB 파일을 업로드하자 백엔드 서비스의 메모리 사용량이 점차 증가하다가 서버 실행 후 몇 시간 뒤 OOM(Out Of Memory) 에러와 함께 다운되는 현상이 발생했습니다. 스파이크성 트래픽이 아니라 지속적으로 메모리가 상승하는 패턴이어서 원인 파악에 어려움이 있었습니다.원인 파악메모리 누수 파악 먼저, 서버의 힙 메모리와 GC를 확인했습니다.노란색이 Old Gen, 파란색과 녹색이 각각 Minor GC, Major GC입니다.GC 동작 이후에도 Old Gen의 최저 수위가 점점 높아지는 것을 볼 수 있습니..

파일업로드 속도 문제현재 'FE -> BE -> S3' 으로 사진을 업로드하고 있는데, 큰 패킷 전달이 두번이다 보니 업로드 속도가 너무 느리다. S3 업로드가 아니라 애초에 사이즈가 큰 요청이 오가는 시간 자체가 느린 것을 부하 테스트로 확인했다. 1MB 파일, 100명의 동시 요청 테스트에서 단순히 서버에서 MultipartFile 로 첨부 파일을 응답 받는 것만으로 응답 평균 시간은 200ms 가 걸렸다. 클라이언트에서 직접 S3 업로드파일 전달에 필요한 비용을 낮추고 서버의 요청 처리 속도를 개선하기 위해 클라이언트에서 직접 S3에 사진을 업로드한다. 프론트엔드에서 백엔드 서버로 이미지 파일이 전송되는 비용을 아낄 수 있다. 허용된 path에, 허용된 용량만큼만 업로드 할 수 있도록 S3 Pre..