장쫄깃 기술블로그

들어가며 지난 게시글에서 @ControllerAdvice, @RestControllerAdvice에 대해 알아보았다. 이번 게시글에서는 해당 어노테이션을 사용하여 예외 처리하는 방법에 대해서 알아보려고 한다. Rest API 구현 중 오류 메시지는 개발자가 의도한 오류(Custom Exception)와 예상치 못한 오류(System Exception)로 구분된다. 이번 게시글에선 이러한 예외 상황에 대한 공통 예외 처리(Exception Handler)를 적용하는 방법에 대해 알아보겠다. 네이버 오픈 API 오류 메시지 형식 가이드처럼 API 오류 메시지에 대해 일관된 형식으로 응답하도록 설계해야 한다. 신규 API를 구현할 때마다 작성하도록 설계하는 것은 작업자마다 일관된 응답 구조를 보장하기 어렵기 ..

들어가며 자사 서드파티 API를 개발하는 업무를 담당했을 때, 처음에는 모든 예외처리를 try-catch로 처리하였다. 그렇다 보니 불필요한 중복 코드들이 많아지고 가독성도 떨어졌다. 또, 코드가 점점 복잡해져 생산성도 떨어졌다. 확실한 건 중복되는 코드들이 너무 많았다. 이러한 문제를 해결하기 위해 고민하고 찾아본 결과 @ControllerAdvice, @RestControllerAdvice를 발견했다. @ControllerAdvice 란 /** * Specialization of {@link Component @Component} for classes that declare * {@link ExceptionHandler @ExceptionHandler}, {@link InitBinder @InitBi..

git-flow란 git-flow는 git이 새롭게 활성화되기 시작하는 10년전 쯤에 Vincent Drissen이 제안한 효율적인 git 브랜치 전략이다. 현재는 git으로 개발할 때 거의 표준과 같이 사용되는 방법론이다. 말하자면, git-flow는 기능이 아니라 하나의 방법론이라는 점이다. Vincent Drissen도 언급했듯이 git-flow가 완벽한 방법론은 아니고 각자 개발 환경에 따라 수정하고 변형해서 사용하라고 언급한다. git-flow 5가지 브랜치 모델 Vincent Drissen의 브랜칭 모델에는 5개의 브랜치가 사용된다. master develop feature release hotfix master 정식 배포되는 안정적인 버전의 소스코드가 관리되는 브랜치로, master 브랜치의..

Merge 일반적으로 많이 사용되는 병합으로, 커밋 이력을 모두 남길 때 사용한다. git checkout jangjjolkit git merge my-branch 이 방식은 다시 Fast-Forward 방식과 Recursive 방식으로 나뉜다. Fast-Forward 새로운 브랜치 my-branch가 jangjjolkit 브랜치로부터 분기된 이후 jangjjolkit 브랜치에 새로운 커밋이 올라오지 않았다면, my-branch 브랜치가 jangjjolkit 브랜치와 비교하여 최신의 브랜치라고 할 수 있다. 이런 경우 my-branch의 변경 이력을 그대로 jangjjolkit으로 가져올 수 있는데, 이를 Fast-Forward Merge라고 한다. Recursive my-branch가 jangjjolk..

캐시(Cache) 란? 컴퓨터 공학 전반에서 이야기되는 캐시는 자주 사용되는 데이터를 임시로 복사해두는 임의의 장소를 의미한다. 그리고 데이터를 캐시에 저장하는 행위를 캐싱이라고 한다. 일반적으로 캐싱은 캐시에 저장된 데이터에 접근하는 시간에 비해 원본 데이터에 접근하는 시간이 오래 걸리는 경우 사용한다. HTTP 캐시 앞서 설명했듯이 캐시는 자주 사용하는 데이터에 더 빠르게 접근하기 위해 사용한다. 데이터 접근을 위해 네트워크를 사용해야 하는 웹 환경에서도 캐시는 유용하게 사용된다. HTTP 캐싱을 활용하면 웹 사이트의 로딩 시간을 개선할 수 있다. 특히 자주 변하지 않는 정적 파일(js, css, 이미지 등)들을 캐시를 사용하지 않으면, 요청마다 새롭게 다운로드 해야 한다. 이는 불필요한 네트워크 비..

프록시(Proxy) 란? 프록시는 클라이언트와 서버 사이에 위치한 중계 서버로, 통신을 대신 수행하는 대리자 역할을 한다. 프록시가 없다면 클라이언트는 서버와 직접 통신한다. 반면, 클라이언트와 서버 사이에 프록시 서버가 있다면, 클라이언트와 서버는 프록시를 한번 거쳐 통신하게 된다. 왜 프록시를 사용할까? 프록시를 사용하면 보안을 강화할 수 있고, 통신 성능을 높여주며, 통신 비용을 절약할 수 있다. 프록시는 프록시 서버의 위치에 따라 유형이 나뉜다. 유형에 따라 각각의 용도도 조금씩 다른데, 이 글에서는 프록시의 유형을 크게 포워드 프록시(Forward Proxy)와 리버스 프록시(Reverse Proxy) 2가지로 나누어 설명하려고 한다. 포워드 프록시 (Forward Proxy) 포워드 프록시는 ..

중단 배포 방식과 다운타임 서버 한대로 서비스를 운영한다면, 서버 배포 시 어떻게 될까. 현재 서버에서 V1 버전이 실행되고 있는 상황이다. 그리고 우리는 여러 기능이 추가된 V2 버전을 새로 개발했다. 이제 사용자들이 V2 버전을 사용할 수 있도록 배포해야 한다. 배포를 하려면 우선 기존에 V1 버전이 실행되고 있는 서버를 중지시켜야 한다. V1 버전과 V2 버전은 서로 같은 포트를 사용하므로, V2 버전을 실행하기 전에 먼저 V1 버전의 프로세스를 중단해야 한다. 이 시점부터 사용자들은 서비스를 사용할 수 없게 된다. 사용자가 V2 버전을 사용할 수 있도록 바로 V2 버전을 빌드 후 실행해야 한다. 빌드, 로딩과정을 거치고 V2 버전이 정상적으로 실행되면 사용자들은 서비스를 이용할 수 있게 된다. 이..

STRAIGHT_JOIN MySQL에는 STRAIGHT_JOIN 이라고 하는 JOIN이 있다. STRAIGHT_JOIN is similar to JOIN, except that the left table is always read before the right table. This can be used for those (few) cases for which the join optimizer processes the tables in a suboptimal order. 왼쪽 테이블을 강제로 먼저 읽는 JOIN이라고 보면 될 것 같다. 간혹 explain을 이용하여 쿼리 실행계획을 보면 index가 적용되지 않고 쿼리 타입이 ALL로 실행되는 경우가 있다. 이는 MySQL의 옵티마이저(optimizer)가..

INSERT IGNORE 중복키 제약조건에 위배되면 INSERT를 무시한다. 기본적으로 PRIMARY KEY를 기준으로 한다. INSERT IGNORE INTO USER (id, name, salary) VALUES ("user", "장쫄깃", 20000) REPLACE INTO 중복키 제약조건에 위배되면 해당 레코드를 삭제하고 다시 삽입한다. 기본적으로 PRIMARY KEY를 기준으로 한다. REPLACE INTO USER (id, name, salary) VALUES ("user", "장쫄깃", 20000)

DUPLICATE ON KEY UPDATE 데이터 삽입 시, PRIMARY KEY나 UNIQUE KEY가 중복되었을 경우 UPDATE, 중복이 아닌 경우 INSERT를 수행하는 구문이다. INSERT INTO [TABLE] (COLUMN1, COLUMN2, ...) VALUES (VALUE1, VALUE2, ...) ON DUPLICATE KEY UPDATE (COLUMN1 = VALUE1, COLUMN2 = VALUE2, ...) 기존 INSERT INTO 구문 뒤에 추가해서 사용하면 된다. 성능면에서도 괜찮은 구문이라는 말이 많다. 예) PK = id INSERT INTO USER (id, name, salary) VALUES("user", "장쫄깃", 20000) ON DUPLICATE KEY UP..