Side

들어가며모두의 회식 백엔드에는 운영을 대비해서 무중단 배포를 적용했었다. 즉, 새로운 버전의 코드가 배포되더라도 사용자 입장에서는 마치 끊김 없이 서비스가 지속되는 것처럼 보이기 위한 것이다.여러 전략 중 Blue/Green 배포 전략을 선택했는데, 백엔드에선 하나의 인스턴스를 사용하고 있으며 인스턴스를 추가하지 않고도 Nginx가 가리키는 컨테이너만 변경하는 간단한 방식이 적합하다고 생각했기 때문이다. 무중단 배포에 대한 조사를 하면서 고민이 필요한 부분이 있었는데 아래에서 이어가도록 하겠다. Graceful Shutdown배포가 이루어질 때 구버전의 서버에서 요청을 처리하다가 응답이 완료되지 않은 시점에 구버전으로 향하는 포트가 끊기고 신버전의 서버가 실행된다고 가정하자.이때 처리가 끝나지 않은 요청..

들어가며현재 프로젝트에는 음식점 데이터가 존재하고 이를 각각 제공하는 메뉴에 따라 특정 카테고리로 분류하는 작업이 필요하다. 예를 들면 다음과 같은 방식이다.각 카테고리가 계층적인 구조를 가질 필요가 있다. 고민한 방법들1. 테이블 구조 변경처음으로 고려한 방법이다.Enum은 건드리지 않으면서 음식점 카테고리 엔티티에 부모 엔티티를 나타내는 하나의 외래키 필드만 추가하면 되었기 때문에 해당 방법을 사용했었다.위와 같이 빨간색으로 표시된 하나의 필드만 추가하면 되었기 때문에 변경할 부분이 많지 않았고, 아직 운영 DB에 보존해야 할 데이터가 없기 때문에 구조를 바꾸는 것 또한 간단했다. 사실 이 방법을 사용했을 때의 문제는 카테고리의 depth가 깊어질수록 쿼리가 계속해서 추가적으로 실행되어야 한다는 점이..

배경Java 8에서 등장한 Stream을 사용하면서 다음과 같은 장점들을 체감하게 되었다. 1. 불변성, 즉 스트림을 통해 연산하는 동안 참조하는 변수의 값을 변경하지 않는다.2. 메서드 체이닝을 이용해 연산을 편리하게 조합할 수 있다.3. 익숙해지면 스트림을 사용하지 않을 때보다 가독성이 향상된다. DB에서 조회한 결과 리스트들의 중복을 스트림을 이용해 제거하는 중 겪은 문제 상황을 정리해 보았다. 문제 발생distinct()만 사용한 경우// 중복 제거 후 검색 정책에 따라 정렬List sortedPlaces = Stream.concat( firstPlaces.stream(), secondPlaces.stream()) .distinct() .(중략) .toList();단순히 이 코드만 작성했..

적용하게 된 배경 기존에 AWS CloudWatch를 통해 EC2, RDS, Application의 몇 가지 메트릭을 보여주는 대시보드를 구성했다. 다만 간혹 EC2 인스턴스가 알 수 없는 이유로 먹통이 되는 현상이 발견되었고, SSH 툴을 이용해 터미널 접속을 시도하기 전까지 이를 인지하지 못하는 일이 있었다. 따라서 특정 조건 만족 시 Slack 채널에서 알림을 받을 수 있도록 설정하고자 했다. 이번에 적용한 알림은 두 가지이다. 1. EC2 인스턴스의 CPU 사용률이 5분 이상 70%를 초과하는 경우 2. EC2 인스턴스의 상태 검사(시스템, 인스턴스)가 둘 중 하나라도 실패하는 경우 CPU 사용률의 경보 기준은 다음 레퍼런스를 참조하여 설정했다. AWS 경보 흐름 이해하기 경보 흐름은 위와 같다...

도입 배경 서비스 운영 시에 갑자기 API 서버에서 500번대에 해당하는 응답이나 Error 레벨의 로그가 발생했다고 가정해 보았다. 아무런 대비가 되어있지 않다면 개발자는 에러가 발생한 줄도 모르고 있을 가능성이 높다. 이 사실을 알게 되었다 하더라도 에러와 관련된 로그를 찾기 위해 로그 파일을 일일이 열어서 찾아야 한다면 참 막막할 것 같다. 따라서 개발자가 에러 발생 시 적절히 대처할 수 있도록 Error 레벨의 로그가 기록되면 곧바로 설정한 Slack 채널로 관련 로그가 송신되도록 적용했고, 해당 과정을 소개하겠다. 과정 조사 결과 Slack에서 제공하는 API를 호출하는 방법과 maricn이라는 깃헙 유저가 개발한 SlackAppender를 사용하는 방법이 있었다. 사용법은 둘 다 어렵지 않으나..

배경 최근 김영한님 강의에서 필터에 관한 내용을 보게 되었다. 강의에서는 UUID를 통해서 필터를 통과하는 요청에 대한 로그를 구분하고 있었는데, 이 방법은 같은 요청이더라도 필터를 통과하고 난 이후부터 응답하기 이전까지의 로그에 대해서는 같은 UUID를 로그로 남겨줄 수 없어 실제 서비스에서는 활용하기 힘들어 보였다. 그래서 여러 요청에 대한 로그가 무작위로 뒤섞이는 어지러운 상황에서도 특정 요청에 대한 로그를 구분할 수 있도록 도와주는 MDC라는 도구를 프로젝트에 사용했고, 이를 정리하고자 한다. MDC란? MDC(Maped Diagnostic Context)는 ThreadLocal을 통해 구현된 일종의 저장 공간을 제공하는 클래스로서, Map 구조의 객체를 지니고 있어 (Key, Value) 형태로..

들어가며 기존 프로젝트에 작성한 테스트를 한꺼번에 실행시켰더니 위 사진처럼 내장 톰캣 서버가 8번이나 실행되고 있었다. @DisplayName("PlaceService 통합테스트") @Sql("classpath:db/teardown.sql") @ActiveProfiles("test") @SpringBootTest class PlaceServiceTest { // 생략 } @DisplayName("ReviewService 통합테스트") @Sql("classpath:db/teardown.sql") @SpringBootTest class ReviewServiceTest { // 생략 } 이런 식으로 각 테스트 클래스마다 @SpringBootTest 어노테이션이 달려있을 때 특정 테스트는 test 프로파일이 아..

들어가며 최근 프로젝트를 개발하면서 API를 구현한 뒤 기능을 검증하기 위해 열심히 테스트를 작성하고 있다. 약간 기계적으로 작성하고 있었다는 생각도 들어서, 코드 커버리지에 대한 이야기를 하기 전에 테스트를 작성하는 이유부터 짚고 넘어가고자 한다. 테스트를 작성하는 이유 먼저 전통적으로 Postman 등을 이용해 직접 API를 호출하고 요청을 일일이 만들어가면서 테스트한다고 가정해보자. 제품, 그러니까 프로젝트의 규모가 작을 때는 사람이 직접 값을 집어넣어 가면서 테스트를 진행해도 크게 문제가 없을 것이다. 하지만 사용자가 많아지고 프로젝트의 규모가 거대해진다면...? 테스트가 필요한 케이스 또한 굉장히 많아질 것이고, 일일이 요청을 날리는데 필요한 시간과 노력도 결코 무시할 수 없다. 그 말은 즉슨 ..