배포의 경우 클라이언트는 vercel을 통해 배포하고, 백엔드 서버는 ECS + ECR로 진행되었다1차 문제: SameSite로그인 성공 시 액세스 토큰과 리프레시 토큰을 쿠키에 담아 클라이언트로 리다이렉트 하는 데, 배포 환경에서 쿠키가 저장되지 않는 문제가 있었다.. 알아보니, 쿠키의 경우 SameSite 속성을 명시하지 않으면 기본으로 Lax가 설정되어 다른 도메인끼리 쿠키 전달이 되지 않는 다는 것..=> SameSite 옵션을 None으로 설정해주자!2차 문제: SecureSameSite를 None으로 설정하려면 Secure 옵션은 true로 설정되어 있어야 한다..=> 결국 HTTPS 설정이 필수인 것 같다.. 이를 위해 귀찮지만 도메인 연결 및 SSL 인증서를 발급해주자도메인 발급 및 연결가..

이번 시간에는, 열심히 학습한 코드 리팩토링 기법들을 활용해서 내 프로젝트 코드를 개선했던 경험에 대해 포스팅해보도록 하겠다.Auth DomainAuthController@RestController@RequestMapping("/api/auth")@RequiredArgsConstructorpublic class AuthController { private final JwtService jwtService; private final MemberRepository memberRepository; @GetMapping public DataResponse getUserInfo( @AuthenticationPrincipal TodomonOAuth2User todomonOA..

결제 실패, 중단, 타임아웃 등의 이벤트 발생 시, 이를 로깅하고 알림을 통해 관리자 또는 사용자에게 문제를 전달해야 한다.로그 관리는 여러가지 방식으로 수행할 수 있으며, Logback 라이브러리에서는 다양한 Appender를 통해 이를 지원한다. 나는 그 중에서 ELK 스택을 통해 로그 관리를 수행하기로 했다. 그 이유는 다음과 같다. ElasticSearch는 분산형 아키텍처를 기반으로 설계되어 대규모 데이터도 빠르게 처리하고 확장 가능=> 이를 통해 대규모 시스템에서 발생하는 대량의 로그를 실시간으로 저장하고 검색 가능Elasticsearch는 역색인(inverted index)을 활용하여 로그 데이터를 실시간으로 검색하고 분석 가능Kibana를 통해 로그 데이터를 직관적으로 시각화 가능=> 대시..

OSIV 문제Filter 단에서 유저를 검증하기 위한 member 조회 쿼리 반드시 1번씩 발생authCheker를 통한 검증 로직을 분리했지만, 이 역시 Service 로직 접근 전에 실행되기에 OSIV false로 인해 영속성 컨텍스트의 관리를 받지 않음이로 인해 중복 쿼리가 2, 3개씩 발생..다음은 나의 펫에게 먹이를 주는 API에서 발생하는 쿼리들이다2024-09-13T15:01:39.371+09:00 DEBUG 10375 --- [nio-8080-exec-3] org.hibernate.SQL : select -- 1) m1_0.id, m1_0.created_at, m1_0.daily_achievement_cnt, m1_0.dilig..

OneToOne 양방향 관계 조회 시 문제Member와 TitleName, Member와 Diligence는 모두 OneToOne 양방향 관계로 구성이 되어 있으며,연관관계의 주인은 Member가 아닌 TitleName과 Diligence로 설정되어 있었다.이렇다보니 문제가 하나 발생했는데.. 연관관계의 주인이 아닌 Member를 조회할 때 Member 뿐만 아니라 TitleName과 Diligence까지 모두 조회되는 문제가 발생했다. 왜 이런 문제가 발생하는걸까? 지연 로딩 동작 매커니즘지연 로딩이 동작하는 매커니즘은 다음과 같다.지연 로딩은 로딩되는 시점에 Fetch 전략이 Lazy로 설정되어있는 엔티티를 프록시 객체로 가져온다.이후 실제로 객체를 사용하는 시점에 초기화되면서 쿼리가 실행된다.이렇게..

성능 테스트를 진행하다보니 여러 스레드의 동시 요청을 처음으로 경험할 수 있었다. 그리고 역시나 무수히 무수히 많은 문제가 발생했다... 이번 포스팅에서는 여러 로직에 대한 동시성 테스트를 진행해보면서 이를 해결하는 과정을 적어보려고 한다. 먼저 동시성 테스트에 사용되는 클래스 및 인터페이스에 대해 알아보자.멀티 스레드를 사용하는 비동기 테스트에 사용되는 클래스Executors: 스레드 풀을 손쉽게 생성해주는 팩토리 클래스스레드 풀 종류FixedThreadPool고정된 스레드 개수를 가지는 스레드 풀작업이 고정된 스레드 개수를 넘는다면 큐에서 대기CachedThredPool필요할 때 필요한 만큼의 스레드를 생성하는 스레드 풀이미 생성된 스레드가 있다면 이를 재활용하여 사용ScheculedThreadPoo..

이전 포스팅에 이어 이번에는 투두 조회 API의 성능을 개선해보자!개선 전 상황특별한 개선 없이도 1500만 개의 todo와 750만 개의 todo_instance가 있는 상황에서 일간 조회, 주간 조회, 월간 조회 API의 성능은 다음과 같이 준수하게 나왔다.평소 트래픽(Vusers: 29)TPS: 556.2MTT: 45.43ms최대 트래픽(Vusers: 86)TPS: 587.5MTT: 139.77msVuser가 증가함에도 불구하고 TPS는 늘지 않고 MTT만 증가한 것을 보니 리소스 한계로 인한 포화점(Saturation Point)을 넘었음을 확인할 수 있었다. 이미 목표로 하는 성능을 뽑아내고 있지만, 개인적인 욕심에 조금 더 최적화를 하고 싶었다! 포화점 문제를 해결하기 위해선 로드밸런싱이나 스..

이전 포스팅에서 확인했듯이 다음의 API에 대한 성능 개선이 필요해보였다.투두 조회 API전체 & 소셜 랭킹 조회 API투두 생성 API이번 포스팅에서는 전체 & 소셜 랭킹 조회 API에 캐싱을 적용하여 성능을 개선시킨 경험에 대해 포스팅하도록 하겠다!캐싱모든 유저가 동일한 데이터를 하루 혹은 일주일 동안 본다면 이는 캐싱을 적용하기 아주 좋은 지점이다!캐싱 전략 선택일반적으로 백엔드 개발 시 고려하게 되는 캐시는 다음 2가지이다.Local Cachce애플리케이션 내부에서만 유효하며, 동일한 애플리케이션 내의 여러 모듈이나 서비스 간에는 공유 X메모리 내에 데이터를 저장해서 읽기 및 쓰기 성능이 매우 빠름애플리케이션의 JVM 내부 또는 로컬 서버에 저장되며, 외부에서 접근 불가능Global Cache (..

이 부하테스트는 todo_instance를 제거하기 전에 진행한 것이기에 todo_instance에 대한 내용이 포함되어 있음테스트 개요테스트 범위 및 데이터 개수테스트 범위: WAS - DB까지데이터 개수member: 50만 개diligence: 50만 개(member 수와 동일)todo: (member 수) * (한명 당 30개(단일 25개 + 반복 5개)) = 1500만개single todo: 25 * member 수 = 1250만개repeat todo: 5 * member 수 = 250만개repeat_info: (member 수) * (member 당 반복 todo 수) = 50만 * 5 = 250만todo_instance: (member 수) * (member 당 반복 todo 수) * (인스턴..

nGrindernGrinder 설치nGrinder 깃허브 설치 링크: https://github.com/naver/ngrinder/releases위 링크 접속 후 원하는 버전의 nGrinder의 war 파일 설치설치된 war 파일이 있는 디렉토리로 가서 다음의 명령어를 통해 war 파일 실행 -> nGrinder-Controller 구동java -Djava.io.tmpdir=/Users/${username}/${생성할 파일명} -jar [파일명].war --port=${포트} // ex) java -Djava.io.tmpdir=lib -jar ngrinder-controller-3.5.9-p1.war --port=8300이후 localhost:${설정한포트}로 접속한 후, 아이디와 비밀번호 각각 admi..