항공권 예매 서비스 - 내부 최적화로 중규모 트래픽 처리하기

들어가며클라우드 서비스 회사와 ORM 도구들은 우리가 지불해야 될 비용에 대해서 걱정해주지 않는다.출처: Real MySQL 1권 p.10이 테스트는 외부 자원 활용보다는 내부 개선에 집중합니다.무분별한 캐싱이 불필요한 인프라 비용을 증가시킬 수 있고, 극단적으로 오버 엔지니어링으로 캐싱 인프라를 제외시킬 경우 트래픽을 어떻게 얼마나 대응할 수 있는지 알 수 없습니다.꼭 필요한 부분만 캐싱을 도입하자는 마인드로 캐싱이 없는 상태에서 소프트웨어 최적화로 얼마나 개선할 수 있는지 확인하고, 한계 지점을 파악해 정확한 시점에 필요한 만큼만 인프라 확장을 하기 위한 테스트를 진행했습니다.목표: VUser 500 동시 처리, 99% 응답 1초 이내, 에러율 0%Setting테스트 환경로컬 환경프로세서: Intel..

• format_list_bulleted Dev
• · 2025. 3. 12.

week 10 팀 프로젝트 - 검색 쿼리 인덱스 최적화

1. 선택도에 따른 단일 칼럼 인덱스 최적화1.1 선택도가 높은 컬럼(domain)인덱스의 성능에 칼럼의 선택도가 중요하게 작용한다. 선택도는 데이터의 "고유성"을 의미하는데 domain 컬럼의 selectivity_percentage를 보면 100이다. 이 말은 43,420개의 rows 중 데이터 중복이 없다는 뜻이다. 인덱스를 걸어보면 아래와 같은 성능 차이를 확인할 수 있다. 1.2 선택도가 낮은 칼럼(businessStatus)이제 반대로 선택도가 낮은 칼럼에 인덱스를 걸어보자. businessStatus 칼럼은 domain에 비해 선택도가 0.01152로 굉장히 낮은 편이다.실험을 통해 선택도가 낮은 컬럼은 단일 인덱스로 적합하지 않다는 걸 확인하였다.2. 복합 인덱스 쿼리 최적화그렇다면 선택도..

• format_list_bulleted Dev
• · 2025. 2. 6.

시스템 설계의 변화와 불변: 병목 관리의 진화

1. 들어가며　개발에 입문한지 4개월 차, 선배 개발자로부터 "가상 면접 사례로 배우는 대규모 시스템 설계" 책을 추천받았다. 과연 이해할 수 있을까 하는 기대 반 걱정 반의 마음으로 도서관을 찾았고, 다행히 1장은 생각보다 어렵지 않았다. 이틀 간 고군분투하며 AWS를 학습한 경험이 도움이 되었다.1장을 읽으며 가장 흥미로웠던 점은 서비스의 성장에 따라 단순한 아키텍처가 복잡한 구조로 발전하는 과정에서 발견된 '변하지 않는 중심'이었다.유연한 병목 핸들링비용 최소화데이터의 영구보존사용자 경험과거 생산관리로 일하던 시절 거대한 생산 흐름속에서 움직이는 병목을 잡아내고 생산 최적화를 이루고 싶은 열망이 가득한 시절이 있었다. 실시간 생산현황을 신호등으로 볼 수 있게 해주는 모니터링 도구를 만든다면 될 것만..

• format_list_bulleted Dev
• · 2025. 2. 1.

Spring MVC의 요청 처리 과정 이해하기 (초기화 시점, 클라이언트 요청 시점)

1. 들어가며　자동차 내부 동작 원리를 모르더라도 자동차를 타고 다닐 수 있습니다. 하지만 비용과 시간을 아끼기 위해서는 반드시 내부 동작 원리를 알아야만 합니다. Spring 프레임워크를 통해 클라이언트의 요청(HTTP 스펙)이 Java 객체로 자동 변환되는 혜택을 누리고 있지만, 내부에서 어떻게 이 과정이 수행되는지를 모른다면 성능 문제나 예외 상황 발생 시 원인을 파악하고 해결하기가 어려워집니다.이번 포스트에서는 초기화 시점과, 클라이언트의 요청 시점을 구분하여 Spring의 내부가 어떻게 동작하는지를 자세히 다뤄보고자 합니다.2. 초기화 시점실제 HTTP 요청을 수신하기 위해서는 Spring 내부에서 받을 준비가 되어 있어야 합니다. 이 준비는 컴파일 시점이 아닌 애플리케이션 실행 시점에 발생합니..

• format_list_bulleted Dev
• · 2025. 1. 30.

Spring Security에서 필터 체인과 @PreAuthorize의 접근 권한 처리 사례

1. 배경　이번 팀 프로젝트에서 상기 논리 구조를 가지고 Spring Security를 사용하게 되었습니다. 처음 목표는 권한 검증이 필터 체인에서 처리되도록 하는 것이였지만, Security Config의 가독성있게 관리하자는 2차 목표로 발전하게 되었습니다.2. 발단: 권한 검증이 글로벌 예외처리 핸들러에서 처리되다.Security Config에서 경로에 따른 권한 규칙을 설정했고, 검증 실패 시 처리해 줄 JwtAccessDeniedHandler를 만들어 뒀기에 CUSTOMER 권한을 가진 유저가 OWNER 권한 API 접근 시 검증 실패에 대한 예외를 JwtAccessDeniedHandler가 잡아 줄 것으로 기대했습니다.하지만 예외가 글로벌  예외처리 핸들러로 전달되면서 500 ERROR가 발생..

• format_list_bulleted Dev
• · 2025. 1. 14.

Spring Security의 권한 처리 방식 비교 분석

1. 들어가며　간단한 아웃소싱 팀 프로젝트를 진행하며 처음으로 인증/인가 역할을 맡게 되었습니다. 7일이라는 짧은 프로젝트였기에 굳이 Spring Security를 사용해야 하는가? 에 대한 고민이 있었습니다.그럼에도 불구하고 Spring Security를 택하게 된 이유는  Security의 권한 처리 방식이 JWT만 사용한 방식과 어떤 부분이 다른지 알고 싶은 호기심과 근본적인 처리 과정을 이해하고 싶은 마음에서 출발하게 되었습니다.이번 포스트에서 비 Spring Security 방식에서 Spring Security를 도입 후 코드 변화를 통해 권한 처리 방식의 차이점을 이해하는 것입니다.2. 핵심 객체의 변화2.1 기존 : Request 객체 활용@Overrideprotected void doFil..

• format_list_bulleted Dev
• · 2025. 1. 10.