실전 프로젝트가 거의 마무리 되고 문서화 단계에 돌입해서 그 동안 했던 것들은 되돌아 보고자 한다. 나는 프로젝트에서 데이터 수집/생성/관리, 동시성 문제 해결, 코드 리팩토링, 테스트 코드 작성 등의 작업을 맡아서 했다. 프로젝트를 하면서 가장 어려웠던 것은 의사결정이었다. 하나의 문제를 해결하는 데에도 여러가지 방법이 존재했고 다양한 방법 중 어떤 방법을 선택할 것인가를 결정해야 했는데 이론적인 내용으로 알고 있던 것과 실제로 테스트 했을 때의 결과가 다를 때 어떤 기준을 따라야 할 지 결정이 어려웠다. 특히 동시성 문제를 해결하는 파트에서 이론적으로 학습했을 때는 분산 환경에서 Redis를 이용한 방식이 성능이 뛰어나다고 알고 있었는데 실제로 테스트를 했을 때는 락의 범위가 상대적으로 좁은 비관적 ..

이번 주는 동시성 문제를 해결하기 위해 사용할 수 있는 다양한 방법들에 대해 알아보고 적용하는 시간을 가졌다. 어떤 방법을 선택할 것인가에 대해서 성능 테스트(기준 : TPS) 를 통해서 결정하고자 했으나 결과가 조금 이상했다. 예상하기로는 각각의 방법들의 성능 차이가 거의 없거나 혹은 Redis 를 이용한 방법이 좀 더 성능이 우수할 것이라고 생각했는데 비관적 락을 사용한 방법이 가장 성능이 우수했다. 강의를 듣고 질문을 한 결과 요청 수(스레드 수)가 너무 적으면 그런 결과가 나올 수도 있으며 실제로 분산 서버가 필요할 만큼의 많은 트래픽이 발생하는 경우에는 Redis를 사용하는 방법이 확실히 성능 면에서 우수하다는 답변을 들을 수 있었다. 그래서 성능 테스트 시 동시에 발생하는 스레드의 수를 더 늘..

드디어 실전 프로젝트에 돌입했다. 도전하기로 한 주제들에 대해 팀원 모두 지식이 없다보니 우선 공부를 한 후에 코딩을 하자고 했었는데 서로 학습 진도가 달라 어려움이 있었다. 결국 관심 있는 주제를 선택해 A-Z까지 해당 인원이 맡아서 진행하는 방식으로 변경했다. 그렇게 한 주를 보냈는데 개인적으로는 스스로를 질책하고 싶고, 질책해야만 하는 한 주였던 것 같다. 아무래도 이전에 했던 미니프로젝트나 클론코딩 프로젝트에 비해서 시간적으로 여유가 있다보니 더 깊게 학습하고 더 고민하는 과정이 수반되어야 하는데 나는 여전히 구현에만 급급한 상태였다. 실제로 피드백을 들을 때도 너무 한 번에 정답으로 가려고 하는 것 같다는 얘기도 들었다. 앞으로는 내가 어떤 것을 적용하면 이걸 왜? 어떤 의사결정 과정에 기반해서..

지난 클론코딩 프로젝트에서 예약하기 기능을 구현하고 동시성 문제를 해결하기 위해 몇 가지 방법을 적용한 결과 중 이해가 안 가는 부분이 있었는데 오늘 추가로 학습을 진행하면서 이해하게 된 부분을 정리하고자 한다. 예약하기 메서드를 synchronized 메서드로 만들었을 때 왜 2명 동시 예약이 됐을까?? 이 부분에 대해 이해를 하지 못 했었는데 스레드가 임계영역을 탈출하면서 Lock을 반납하고 트랜잭션의 커밋이 이루어지는 사이에, 그 사이에 다른 스레드가 임계영역에 진입해 데이터 조회를 하게 되면 이전 스레드에 의해서 발생한 쿼리문들의 결과가 데이터베이스에 반영이 되지 않은 상황이므로 동일하게 예약이 가능하다고 나오게 되는 것이었다. 나는 트랜잭션의 커밋이 되고 난 후에 메서드가 종료된다고 착각하고 있..

예약하기 서비스 동시성 문제 해결하기 하나의 숙소에 겹치는 기간으로 2명이 동시에 예약을 시도할 경우 -> 처음에 만든 로직으로는 2명 다 예약이 성공함 시도1. synchronized 를 통해 어플리케이션 단에서 제어하기 -> 스프링 프레임워크에서 IOC 컨테이너에 빈 객체를 만들고 주입하는 방식이기에 모든 요청에서 동일한 서비스 객체를 사용하므로 인스턴스 메서드에 synchronized 해줘도 해결이 될 거라고 생각 -> 그런데 그대로 2명이 다 예약됌 시도2. 비관적 락을 통해 DB 단에서 제어하기 -> 비관적 락을 걸면 하나의 트랜잭션이 커밋을 하기 전까지 다른 트랜잭션이 데이터에 접근하지 못 하므로 해결될 것으로 예상 -> 하나의 트랜잭션에 의해서 DB에 데이터가 저장이 됐음에도 마치 커밋이 안..

에어비앤비 클론코딩 프로젝트를 하면서 사용자가 설정한 checkIn, checkOut 기간에 예약이 없는 숙소들만 필터링해서 보여줘야 할 일이 있었다. 내가 선택한 방법은 checkIn, checkOut 기간에 예약이 있는 방번호를 구하고 이 번호에 해당하지 않는 숙소들만 보여주는 방법이었다. 그렇게 하기 위해서는 Reservation 테이블에서 'checkIn, checkOut 기간에 예약이 있는 방 번호'를 서브쿼리를 통해 구하고 메인 쿼리의 where 절에 조건으로 사용해야 했다. SQL문으로 서브 쿼리는 몇 번 써봤지만 querydsl로는 써 본 적이 없어 이런 저런 시도 끝에 내가 원하는 쿼리문을 만들 수 있었다.

스프링부트로 만든 어플리케이션에서 AWS 리소스를 사용하기 위해서 아래와 같은 라이브러리를 추가했다. 그랬더니 이런 에러가 발생했다. 어플리케이션 실행은 문제 없이 되긴했지만 도대체 무슨 에러인가 찾아보니 로컬 환경은 EC2가 아니라서 발생하는 에러라고 했다. 그래서 이를 해결하고자 어플리케이션 실행 시 일부 파일들은 실행하지 않는 방식을 사용했다. 이렇게 해서 EC2 관련 에러는 사라졌지만 S3에 이미지 파일이 저장되지 않는 문제가 발생했다. 에러 메시지를 보니 S3Client의 region과 실제 이미지 업로드를 하려 하는 버킷의 region이 일치하지 않아 발생하는 문제였다. 그래서 직접 출력해서 확인해보니 분명 S3Client를 만들 때 'ap-northeast-2'로 region을 설정하고 있음..

"아쉽지만 좋았다" 이번 주는 프론트엔드 분들과의 첫 협업으로 미니프로젝트를 진행했다. 개인적으로는 미니프로젝트 주차에 채팅 기능을 구현해보고 싶었는데 주제 선정에서 다른 분의 의견이 더 많은 투표를 받아 이미지 업로드가 가능한 페이지를 구현하는 것으로 방향이 잡혔다. 이미지 업로드 역시 한 번도 구현해본적 없는 기능이기에 좋긴했지만 채팅 기능을 구현해보지 못 한 것이 조금은 아쉬웠다. 그래도 프론트엔드 분들과 첫 협업을 하면서 눈에 보이는 성과물을 만들어 내는 것이 재밌었고 완성된 결과물을 봤을 때는 괜시리 뿌듯한 마음도 들었다. 나는 이번 프로젝트에서 파일 업로드를 포함한 게시글 작성 구현을 주로 담당했다. 기능을 구현하면서 겪었던 문제 및 회고 발표 때 들었던 피드백에 대해서 정리하고자 한다. 1...