회고장

👣 개요 오늘은 주특기 3주차 과정을 마무리 짓는 시험을 치뤘다. 사실 구현 자체는 그다지 어렵지 않았지만 배포를 하는 것이 문제였다. 강의에서 지시한 배포 과정은 MySQL을 AWS RDS로 렌트하고 EC2 서버에 내가 구현한 API 서버를 배포해서 연계하는 방식을 사용하고 있었다. 하지만 RDS로 MySQL을 연결하는 과정 중에 문제가 크게 발생했고 이 때문에 시험이 끝나기 15분 전까지도 배포가 되지 않았다. 결국 그냥 EC2 서버에 직접 MySQL을 구성하고 알맞게 환경을 구성해서 문제를 해결했다. EC2가 저장을 위한 공간은 아니었기에 다소 찝찝한 감이 없지 않아 있었지만 결국 시험 요구 조건은 만족했기에 그 상태로 제출했다. 그 이후 내일 협업 프로젝트에 대비해서 협업 관련 Tool들을 찾아보..

👣 개요 오늘은 "Real MySQL 8.0"라는 책의 '옵티마이저와 힌트' 챕터를 읽고 게시글을 작성했다. 옵티마이저는 MySQL로 요청이 들어온 SQL을 어떤 방식으로 실행해서 결과를 계산할지에 대한 계획하는 실행 계획을 짜는 주체다. 옵티마이저의 성능에 따라 연산 속도가 결정되기 때문에 함부로 옵티마이저의 설정을 건드리지면 안된다. 하지만 경우에 따라 직접 만든 웹 App에 적합하지 않은 방식으로 연산을 수행하는 경우도 있기에 이것을 막기 위한 방법으로 '힌트'라는 것을 제공하고 있다. 힌트라는 것은 개발자가 직접 MySQL의 옵티마이저에게 특정 방식에 대해 가산점을 더 줘서 개발자가 판단하기에 더 효율적인 방법으로 SQL을 처리하도록 유도하는 방법이다. 이미 많은 경험을 통해 튜닝된 옵티마이저의 ..

👣 개요 특정 쿼리를 실행하는 방법은 매우 다양한 방법이 있을 수 있다. 테이블 자체를 풀 스캔 하던지 인덱스를 이용해서 검색하던지 등등의 방법이 많다. 하지만 최적의 방법은 존재하기 때문에 해당 방법을 찾는 장치가 필요하다. 그러한 역할을 옵티마이저가 담당한다. 👣 용어 정리 실행 계획 쿼리를 이용해서 데이터를 어찌 가져올까에 대한 계획. 옵티마이저 실행 계획 중 가장 최적화된 것을 찾는 주체. 👣 쿼리 실행 절차 쿼리가 실행되는 절차는 3 단계로 나뉜다. 1. SQL 문장을 잘게 쪼게서 서버가 이해할 수 있는 수준으로 분리(Parse Tree)한다. 2. Parse Tree를 확인하면서 어떤 테이블부터 읽고 어떤 인덱스를 이용할지를 선택한다. 3. 결정된 읽기 순서를 이용해서 스토리지 엔진으로부터 데..

👣 개요 오늘은 Lv 5 관련 과제를 끝마치고 문서화 진행해서 제출을 했다. 그리고 그 이후에 페어 팀과 같이 리뷰를 해 드디어 주특기 숙련주차의 모든 과제를 마치게 되었다. 해당 일들이 끝나고 '자바 ORM 표준 JPA 프로그래밍'의 마지막 장인 16장을 모두 읽고 게시글을 작성했다. 해당 책을 2주 이상이나 붙잡고 있었어서 한편으로는 너무 지루하다는 생각도 들었지만 결국 JPA에 대한 깊을 이해를 할 수 있어서 정말 좋았다. 이번 Lv 5 과제도 위 책을 읽고 깨달은 Listener를 이용한 좋아요 갯수 계산을 구현했었다. 원래 나의 방식대로 라면 JPQL의 groupby를 이용해서 좋아요 갯수를 계산하겠지만 이미 작성된 코드들이 있었고 해당 코드들을 모조리 살펴서 리펙토링하는 것이 큰 부담이었다. ..

👣 개요 해당 게시글은 JPA에서의 '트랜잭션과 락'과 '2차 캐시'에 대해 서술할 계획이다. JPA는 대부분의 DB는 READ COMMITTED 수준의 격리 수준을 요구한다. 이것은 성능 상 큰 이점을 줄 수 있어도 정확도 면에서는 손해를 볼 수 있다. JPA는 부분적으로 해당 격리 수준 이상의 격리 수준을 제공할 수 있다. Lock이 그 역할을 수행하고 이것을 심도있게 살펴본다. JPA는 영속성 컨텍스트를 이용해 요청 범위 내에서 같은 엔티티를 DB 2번 이상 호출하지 않도록 1차 캐시를 제공한다. 해당 캐시 덕분에 성능이 크게 늘어났지만 안타깝게도 '요청과 응답 사이'의 캐시를 도와주는 것이지 'Web App 차원'에서의 캐시를 제공하는 것은 아니기에 이전 요청을 위해 DB에서 조회했던 엔티티를 이..

👣 개요 오늘은 10시 부터 Lv 5 과제를 진행했다. 내가 맡은 부분은 좋아요 기능과 예외 처리, 회원 탈퇴 기능이었다. 예외 처리는 단순히 ControllerAdvice를 사용하면 됬고 회원 탈퇴는 단순한 CRUD 중 하나였어서 크게 어렵지는 않았다. 하지만 좋아요 기능은 생각보다 복잡했다. 우선 좋아요를 눌렀던 게시물에 다시 좋아요 API를 호출하면 좋아요 기록이 사라지는 토글 방식이어야 했고 게시글을 조회할 때, 좋아요 총합을 가져와야 했다. 위와 같은 이유로 좋아요 갯수 칼럼을 만드는 것이 아니라 따로 좋아요 테이블을 새로 만들고 좋아요 갯수는 해당 게시글에 해당하는 좋아요들의 갯수를 계산했다. 문제는 해당 좋아요 갯수를 계산하고 어떤 방식으로 조달받을지에 관한 것이었다. 예를 들어, 기존 게시..

👣 개요 이번 주는 주특기 2주차로서 JPA에 대한 심화 공부를 하는 한 주였다. 나의 경우, '자바 ORM 표준 JPA 프로그래밍'을 읽으며 더 깊은 JPA에 대한 이해를 하고자 했다. 결국, 해당 책을 모두 읽고 블로그에 정리했다. 이번 책은 단순히 읽기에서 그치지 않고 직접 코드로 구현해보려는 노력을 했다는 점에서 다른 책들과는 다른 전략으로 접근했다. 확실히 직접 코드로 구현하며 공부를 하니 기억에 더 남을 수 있었고 구버전의 JPA에 대한 책 내용을 바로 잡으며 공부할 수 있었다. 앞으로 특정 기술에 대한 공부를 할 때는 버전이 달라 잘못된 지식을 얻을 수 있으니 '자바 ORM 표준 JPA 프로그래밍' 책을 읽을 때와 같이 직접 코드로 구현하면서 잘못된 점이 있는지 확인하면서 공부해야 겠다고 결..

👣 개요 오늘은 '자바 ORM 표준 JPA 프로그래밍' 15장을 읽고 그에 대한 게시물을 작성했다. 15장 고급 주제와 성능 최적화 👣 개요 해당 게시글은 JPA에서의 예외 처리, 엔티티 비교 시 주의사항, 성능 최적화에 대한 주제로 작성되었다. 👣 예외 처리 순수 JPA 단계에서의 예외 1. 트랜잭션 롤백을 발생시키는 예외 해 ikadnorth.tistory.com 그 다음 Lv 5 과제를 위해 항해 99의 Spring 심화 주차의 강의를 들었다. 강의 내용은 대략 다음과 같았다. OAuth2를 이용한 소셜 로그인 JUnit5, Mockito Spring AOP 예외 처리 모두 대략적으로 알고 있던 내용이지만 특히나 예외 처리 부분의 MessageSource를 이용한 에러 메시지 분리는 처음 접해보는 ..

👣 개요 해당 게시글은 JPA에서의 예외 처리, 엔티티 비교 시 주의사항, 성능 최적화에 대한 주제로 작성되었다. 👣 예외 처리 순수 JPA 단계에서의 예외 1. 트랜잭션 롤백을 발생시키는 예외 해당 예외는 심각한 예외이므로 강제 롤백된다. 2. 트랜잭션 롤백을 발생시키지 않는 예외 그다지 심각하지 않는 예외이므로 개발자 선택에 의해 커밋하던지 롤백한다. 예를 들어, 단일 조회를 했는데 조회된 내용이 하나도 없으면 발생하는 예외 같은 것을 의미한다. Spring Framework에서의 JPA 예외 변환 아래 Effective Java의 내용에 따르면 저수준의 라이브러리[Hibernate]에서 발생한 예외를 고수준의 라이브러리[Spring Data JPA]에서 그대로 노출되면 오류의 원인을 파악하기 어려워..

👣 개요 오늘은 '자바 ORM 표준 JPA 프로그래밍' 책의 14장과 15장을 공부했다. 오늘 공부는 상당히 유의미 했던 것이 그동안 JPQL로만 연관 관계의 쿼리를 fetch join을 하기만 했지 JPA로만 연관 관계의 fetch join을 한 적은 없었다. 하지만 14장의 엔티티 그래프를 읽고 해당 기술을 이용하면 재활용성 높게 연관된 엔티티를 fetch join할 수 있음을 깨달았다. 추가로 리스너에 대해서도 깨달은 바가 컸는데 그동안 JpaAuditing을 사용할 줄만 알았지 어찌 작동하는 지는 모르고 살았는데 리스너를 사용하는 방법을 알아낸 뒤 AuditingEntityListener 코드를 읽고 해석하는 능력을 갖추게 되어 매우 인상적이었다. 현 시점에서는 15장을 공부만 하고 게시글을 작성..