지난 두달간 HappyScrolls를 개발하고 1차 테스트 배포를 거치고 지금은 잠깐 휴식기이다.
프로젝트를 정리하고 한번 되돌아보고자 한다.
잘했다고 생각한 점과 아쉽고 보완해야 할 점에 대해 정리해보자.
아쉬운 점은 2차 스프린트 전에 보완하고 넘어가자!
🙂: 잘 한것 같은 점
🥲: 아쉬운 점
🙂 테스트 코드의 도입
이전 프로젝트와 가장 달랐던 점은 테스트 코드의 도입이다.
테스트 코드를 작성하면서 기존 코드의 문제점을 파악하는데에도 도움이 되었다. 또한 포스트맨을 활용할 때와는 다르게 실행 버튼 하나만으로 테스트가 가능해서 파악이 더 쉬웠다. 또한 jacoco를 통해 커버리지를 확인할 수 있는것도 도움이 많이 되었다.
🥲 테스트 코드의 어려움
반면에 좋은 테스트 코드를 짰는가? 에 대한 대답은 NO이다. 물론 이번에 처음 짜본 테스트코드라 좋은 테스트 코드를 짤 수는 없었다고 변명해본다.. 그렇지만 분명 아쉽긴 하다. 내 테스트 코드가 모든 상황을 검증해주는것 같진 않다. 또한 통합테스트를 아직 해보지 못한것 또한 2차 스프린트 전에 보완해야할 것이다.
테스트 코드의 도입
서비스 레이어 테스트 코드를 작성하면서 알게된 테스트 코드의 장점
🙂 댓글과 대댓글
성능을 생각해서 댓글과 대댓글을 한 테이블로 합쳐놓았다. 각각의 성격을 분석하고 역할을 고민해서 결정한 점은 분명 생각하고 설계한 것이니 발전한 점이라고 생각한다. 그러나...
댓글과 대댓글의 구현
🥲 댓글과 대댓글을 합치는게 최선이었을까..?
댓글과 대댓글을 합치는게 단기적인 솔루션이지 장기적으로 바라보았을 때는 좋지 않은 방법이라고 생각되었다. 프로젝트의 규모가 커지고 데이터가 많아질수록 조금씩 조회하고, 조건을 걸어서 조회해야한다고 생각하는데, 댓글과 대댓글의 경계가 그 조건을 만들어주지 않을까라는 생각을 하게 되었다. 그런 관점에서는 내가 선택한 방법은 약점이 될수도 있다. 인덱스를 걸고 조회해보면 좀 다를수도 있긴 할거 같다. 추후에 데이터를 쌓아보고 실험을 해보면 좋을것 같다.
🙂 쿼리의 개선
쿼리를 개선할 생각을 한번도 해본적이 없는데, 이번에 처음 해보았다. 한번도 대용량 데이터 처리에 대해 고민해보지 않다가, 이번에 프로시저로 더미데이터를 생성하고, 쿼리의 속도를 측정한 후 개선해보았다. MySQL의 아키텍처에 대해서도 공부해보고, 옵티마이저, 인덱스 등등 많은 개념을 더 깊이 공부하게 된 좋은 계기였다.
N+1 문제 해결기
성능 최적화
🥲 올바른 인덱스와 정규화의 필요성
쿼리 성능을 개선하면서 인덱스를 잘 잡아야겠다는 생각과, 테이블 설계가 더 좋았다면 어땠을까 하는 생각을 했다. db에 대해 더 공부해보고 좀 더 개선해볼 필요가 있다.
🙂🥲 연관관계 해소
네이티브 쿼리를 사용하기 위해 연관관계를 "잠시" 해소했던 적이 있다. Jpa ManyToOne같은 어노테이션을 쓰지 않고 외래키로만 조회했던 것인데, 결국엔 아직까지 Jpa가 주는 이점을 살리고자 되돌렸다. 후에 좀 더 공부해보고 Jpa를 쓸 수 없는 상황에서는 어떻게 해야할지 더 고민해봐야겠다.
연관관계 해소
🙂🙂🙂 의존성의 흐름 제어
기존의 코드는 한 서비스 레이어에서 여러 리포지토리를 의존한다던가, 아니면 한 컨트롤러에서 여러 서비스를 의존한다던지 의존성이 많이 꼬이고, 여기저기서 각각이 필요한 클래스를 맘대로 의존하고 있었다.
흐름을 제어하고자 각 컨트롤러는 자신과 동일한 도메인의 서비스만, 각 서비스는 자신과 동일한 도메인의 서비스만 의존토록 하고, 타 도메인의 기능이 필요할 땐, 서비스 레이어에서 다른 서비스 레이어를 의존토록 하였다.
이것이 가진 굉장한 장점이 있었는데, 기존에 타 도메인의 리포지토리를 의존할 때에 타 도메인과 관련된 예외처리도 그 도메인을 의존하는 쪽에서 처리해야 했다.
그런데 기존에 예외처리를 컨트롤러와 서비스 레이어 양쪽에서 하다가 서비스레이어로 통일했던 적이 있었고, 이와 시너지가 발생이 되었다.
타 도메인을 의존할 때에는 타 도메인 서비스 레이어를 의존하고, 그와 관련된 오류가 발생할 때에는 그 도메인 서비스 코드에 예외처리 코드가 있으니 타 도메인에 예외처리를 위임하게 된다.
따라서 각 도메인의 역할이 분명해지는것을 알 수 있었고, 의존성의 흐름이 굉장히 중요하다는 것을 깨달았다.
위 코드에서 cartService.carFind를 호출할 때에 기존에는 repository에서 find를 호출해서 오류를 직접 처리해야했다.
하지만 지금은 cartService에 그 예외처리를 위임하게 된다.
간단한 리팩토링
🙂 아키텍처에 대한 고민
아키텍처에 대한 제대로된 고민을 처음 해보았다.
과부하에 대한 해결을 해야한다는건 누구나 아는 사실이고 서버수를 늘리면 된다는것도 당연하긴 하다.
하지만 진짜 뿌듯한 점은 처음에 쿠버네티스로 적용해보려다 내 상황에 맞게 aws 오토스케일링과 elb로 대체하는것을 고민하고 도출해낸 것이다.
아키텍처에는 정답이 없고, 내 상황에 맞는 솔루션을 선택하는 능력을 더 길러야겠다는 생각을 했다.
또한 RDS에서 퍼블릭 엑세스가 불가능하게 설정한 점도 특별했다. 보안을 위해 ec2에서만 접근 가능하도록 변경하였다. 서브넷, vpc에 관한 개념을 더 공부할 수 있게된 계기였다.
🥲🥲 Jmeter를 통한 성능 테스트, 아키텍처 설계, 레디스를 통한 캐싱
Jmeter, 프로메테우스, 그라파나를 이용해 성능테스트를 진행하고 충격을 먹고 오토스케일링이 가능한 아키텍처로 배포했다.
하지만 각각의 성능 수치가 아직은 어떤 의미인지 더 공부해야하는 상황이고, 떄문에 내가 설계한 아키텍처가 프로젝트가 처한 문제점들을 해결해줄 수 있는건지 아직 알 수 없다.
후에 라즈베리파이 여러개로 실제 물리서버도 분리해보면서 성능을 체크해보고, 더 알맞은 아키텍처를 설계할 필요가 있다.
또한 레디스를 이용해서 캐싱을 일부분 적용했는데, 이부분도 아직 숙련도가 부족하기에 공부를 더 해야겠다는 생각을 했다.
또한 레디스 서버가 다운되면 어떡하지??라는 문제점을 아직 해결하지 못한 상태이다.
Jmeter를 통한 스트레스 테스트
아키텍처에 대한 고민
🙂🥲 event의 사용
이벤트를 사용하면서 의존성을 제거했었다. 의존성을 제거한 것은 굉장히 기뻤다.
다만 너무 남용하면 안될 것 같다는 생각이 크게 들었고, 특히나 관련된 코드를 쉽게 볼 수 없다는 단점이 생겨버린것 같다.
또한 이벤트를 사용하면서 기존의 코드들을 재사용하기 힘들어진 것 같다. 따라서 좀 더 공부해보고 신중히 사용해야할 것 같다.
event를 통한 의존성 제거
++ 쿠버네티스를 사용해보고 싶다.
++ 아키텍처의 변경이 필요한것 같다. 지금의 레이어드 아키텍처로는 조금 알아보기 힘들고, 어쩔 수 없이 의존성이 꼬이는 경우가 생기는 것 같다. 클린,헥사고날 아키텍처의 도입을 고민해봐야겠다.
