분류 전체보기

마이크로서비스 아키텍처에서 API Gateway는 클라이언트 요청을 적절한 서비스로 라우팅하는 중요한 역할을 합니다. 최근 Spring Cloud Gateway에서 X-Forwarded-Prefix 헤더가 요청 경로에 영향을 미치는 이슈를 발견했습니다. 이 글에서는 문제 상황부터 원인 분석, 해결 방법까지 상세히 공유하고자 합니다. 1. 문제 상황: 의도치 않은 경로 추가Spring Cloud Gateway를 기반으로 한 API Gateway를 개발 환경에서 테스트하던 중, 이상한 현상을 마주쳤습니다. X-Forwarded-Prefix 헤더가 포함된 요청을 보냈을 때, Gateway가 이 헤더 값을 경로 앞에 자동으로 붙여서 라우팅을 시도하는 일이었죠🤔 예를 들어, /test/** 경로에 대한 라우트가..

되돌아보는 2024년2024년을 돌아보며, 나의 한 해는 크게 4가지 주제로 정리할 수 있다.LIME 프로젝트취업 성공신입 개발자그리고 현재 LIME 프로젝트LIME 프로젝트는 나에게 많은 것을 남긴, 특별한 경험이었다. 이 프로젝트는 데브코드에서 진행했던 기존 프로젝트를 기반으로, 백엔드 팀원은 그대로 유지한 채 프론트엔드 팀원들과 디자이너를 새롭게 모집하여 리뉴얼한 프로젝트이었다. 처음부터 기획을 다시 구성하며, 디자이너와의 협업을 통해 퀄리티를 높이고 실사용자를 확보하는 것을 목표로 진행했다. 프로젝트는 1월에 시작해 2개월 안에 마무리하겠다는 계획으로 출발했지만, 예상과 달리 작업은 5월까지 이어졌다. 결국 절반 정도 완성한 상태에서 마무리하지 못했지만, 이 프로젝트는 단순한 결과 이상의 의미를 ..

안녕하세요. 지난 6월에 입사하여 이제 4개월 차가 된 신입 백엔드 개발자입니다. 오늘은 그동안의 경험들을 돌아보며, 더 나은 ’팀원‘ 또는 ’개발자‘가 되기 위해서는 어떻게 해야하는지 생각해보는 시간을 가지려 합니다. 새로운 시작입사 당시를 떠올려보면 설렘, 긴장, 걱정, 열정 등 다양한 감정이 교차했습니다. 첫 커리어를 시작하는 만큼 새로운 환경에 대한 기대감과 함께 ‘과연 내가 잘 해낼 수 있을까?’ 하는 걱정도 있었습니다. 회사의 문화는 어떨지, 팀원들은 어떤 분들일지 궁금하기도 했고, 새로운 도전에 대한 두려움도 있었습니다. 하지만 누구보다 열심히 하겠다는 열정으로 가득 차 있었기에, 스스로를 믿고 한 걸음 내딛었습니다. 4개월이 지난 지금, 회사 생활에 어느 정도 적응하면서 초기의 설렘은 조금..

저번 포스팅에서 해결한 데드락 문제에 이어서 이번에는 동시성 문제를 해결해보겠습니다.  1. 투표 참여 기능 설명투표는 최대 1000명까지의 참여 인원 수를 설정할 수 있으며, 설정된 참여 인원 수가 모두 차면 투표는 즉시 종료됩니다. 회원은 투표 아이템 중 하나를 선택하여 투표에 참여할 수 있습니다. 투표 도메인은 votes(투표) 테이블과 voters(투표자) 테이블이 있습니다. 2. 문제 상황투표 참여 기능의 성능 테스트 중 🚨 동시성 이슈가 발생했습니다. 테스트 조건대상 투표 ID: 1번설정된 제한 인원: 1000명동시 참여 사용자 수: 1010명 테스트 결과기대했던 1000명의 투표자 대신, 실제로는 1009명의 투표자가 등록되었습니다. 동시성 이슈가 발생한 것입니다. 😱 3. 동시성이 발생..

투표 참여 기능 설명투표는 최대 1000명까지의 참여 인원 수를 설정할 수 있으며, 설정된 참여 인원 수가 모두 차면 투표는 즉시 종료됩니다. 회원은 투표 아이템 중 하나를 선택하여 투표에 참여할 수 있습니다. 투표 도메인에는 votes(투표) 테이블과 voters(투표자) 테이블이 있으며, 이 두 테이블은 1:N 관계를 가집니다. voters(투표자) 테이블에서 votes(투표) 테이블의 기본키를 외래키로 사용합니다. 투표 참여 기능에 사용되는 코드는 아래와 같습니다. Vote 엔티티와 Voter 엔티티는 양방향 매핑을 통해 연결됩니다.VoteManager.participate()@Transactionalpublic void participate( final Vote vote, final Long me..

상황 LIME 서비스 개발 중에, 특정 상황에서 사용자에게 포인트를 지급하는 요구사항이 있었다. 포인트는 댓글 작성, 댓글 채택, 리뷰 작성 세 가지 상황에서 지급된다. 현재 LIME 서비스에서는 이 로직을 AOP로 구현하고 있다. AOP는 주로 비지니스 로직과 그 외 공통 로직을 분리하는 프로그래밍 방식으로 사용되는데, 포인트 지급이라는 비지니스 로직을 AOP로 처리하는 것이 다소 어색해 보였다. 따라서, 이 기능을 '직접 메소드 호출' 또는 '이벤트 처리' 중 어느 방식으로 변경할지 고민하게 되었다. 고려 사항 1. 관심사의 분리 포인트 지급이 비지니스 로직의 한 부분이라는 건 분명하다. 그렇다면 이 로직은 포인트 지급이 발생하는 로직(댓글 생성, 댓글 채택, 리뷰 생성)과 분리되어야 하는 관심사인가..

🌤️ 2023년 회고 2023년이 빠르게 지나가고 2024년이 왔다. 2023년은 나의 부족함을 느끼며, 그것을 채우기 위해 노력한 한 해였다. 2023년을 되돌아보면, 가장 먼저 떠오르는 것은 ✨취업 준비와 데브코스✨이다. 4학년 2학기를 마치고 취업 준비를 시작했다. 이때 가장 큰 실수는 취업 준비를 4학년이 끝나고서야 시작한 것이었다. 코딩테스트와 프로젝트 준비가 되어 있지 않았기 때문에, 취업 시장에 바로 뛰어들 수 없었다. 이를 극복하기 위해 그 당시에 내가 할 수 있던 최선은 알고리즘, 스프링, CS 스터디를 시작하고, 이전에 했던 프로젝트를 혼자 리팩토링하는 것이었다. 그러나 공부를 할수록 나의 부족함이 더욱 실감나고, 취업 가능성에 대한 두려움이 커졌다. 혼자서 공부하는 것으로는 원하는 곳..

🚨 에러가 발생한 상황 투표 취소 API를 테스트 하던 중에 아래에 적힌 에러가 발생했다. No EntityManager with actual transaction available for current thread - cannot reliably process 'remove' call 문제가 일어난 코드는 아래와 같다. public void cancel( final Long voteId, final Long memberId ) { final Vote vote = voteReader.read(voteId); if (voterRepository.existsByVoteAndMemberId(vote, memberId)) { voterRepository.deleteByVoteAndMemberId(vote, me..

Cascade의 사전적 정의는 "계단 폭포", "폭포처럼 흐르다." 계단식의 연쇄 반응을 말하기도 한다.JPA CascadeCascade는 엔티티 간의 연결을 통해 엔티티의 상태를 자동으로 전파하는 기능이다. 부모 엔티티가 변경되면 변경 내용이 자식 엔티티에도 적용된다. Cascade TypePERSISTCascadeTyep.PERSIST를 사용하면, persist 작업이 부모 엔티티에서 자식 엔티티로 전파된다. MERGEmerge 작업은 준영속 상태의 엔티티를 영속성 컨텍스트에 다시 병합하는 작업이다. 즉, 영속 상태로 변경하는 작업이다. CascadeTyep.MERGE를 사용하면, merge 작업이 부모 엔티티에서 자식 엔티티로 전파된다. REMOVECascadeTyep.REMOVE를 사용하면, re..

커버링 인덱스(covering index)쿼리에 필요한 모든 결과를 제공하는 인덱스를 커버링 인덱스라고 한다. 쿼리는 인덱스 테이블에서 값을 반환하므로 실제 레코드를 읽어올 필요가 없다. 따라서 디스크 I/O가 절약된다. 예를 들어, 주문 테이블에 shop_id 인덱스가 있다고 해보자. 이때 아래의 쿼리를 실행하면 커버링 인덱스가 사용된다.SELECT shop_id FROM orders WHERE shop_id = 6; 참고로 커버링 인덱스가 적용된 경우, 실행 계획의 Extra 필드에 Using index 라고 나온다. + Real MySQL 책 읽으면서 헷갈렸던 부분 🧐Real MySQL 책에서 클러스터링 인덱스의 장점으로 아래와 같은 내용이 나온다.테이블의 모든 세컨더리 인덱스가 프라이머리 키를 가..