반응형
반응형
왜 저장 순서와 다르게 조회가 되지..? (MySQL 시간 타입의 정밀도)현재 진행하고 있는 프로젝트에서 저장된 순서데로 조회가 되길 기대했던 기능이 있었다.저장된 순서는 아래의 createdAt 필드를 사용해 오름차순으로 구분했다.알림 1을 저장하고, 알림 2를 저장하면 createdAt 기준으로 조회시 [알림1, 알림2] 순서로 조회가 되야 하는데의도와 다르게 [알림2, 알림1]이 조회되고 있었다.뭐가 문제였을까 ? 기본적으로 나노초가 포함되어 시간이 저장될 것을 기대했지만 초까지만 저장되고 있었고저장된 순서는 나노초 단위로는 구분이 되더라도 초는 같아서 의도와 다르게 조회되고 있었던 것이다. 저장 순서데로 조회가 가능하도록 해보자MySQL의 공식문서를 살펴본 결과 시간 타입에 (fsp) 정밀도를 ..
현재 진행하고 있는 "오디"프로젝트는 다음과 같이 3가지 환경으로 구성되어 있다.각 환경에 대해 간단히 설명하자면Local 환경은 각자 기능을 개발 해 PR을 보내는 용도.Dev 환경은 EC2로 애플리케이션이 실행되고 있어 Local 환경에서 개발된 PR을 Merge하면 Dev 서버로 배포하여 클라이언트와 서버가 기능 동작을 테스트하는 용도.Prod 환경도 EC2로 애플리케이션이 실행되어 있고 실제 운영을 위한 아키텍처로 구성이 되어 있으며Dev에서 테스트한 기능들이 문제가 없을 때 배포하여 실제 서비스를 하는 용도로 사용하고 있다. 문제 상황그리고 각 환경들은 다음과 같이 각자 다른 DB를 사용하고 있다.현재 필자의 프로젝트는 배포 전 로컬에서도 스키마에 대한 에러를 빠르게 캐치하고자 ddl-auto를..
현재 오디 프로젝트는 다음과 같이클라이언트가 요청을 보내면 BationEc2를 거쳐 Application이 실행되는 Ody EC2로 연결돼 작업을 처리하고,DB 접근이 필요할 때 쓰기 작업, 읽기 작업을 구분해 적절한 DB에 요청을 보내고 응답을 받는 구조로 되어 있다.그렇다면 애플리케이션에서 어떻게 쓰기 작업, 읽기 작업을 구분해 적절한 DB에 요청을 보내고 응답을 받을 수 있을까 ?@Transactional 어노테이션으로 write, read DB를 구분해 연결하기@Transactional 어노테이션의 readOnly 옵션으로 쓰기, 읽기 작업을 구분해 적절한 DB에 요청을 보내는 방법을 알아보자.application.yml에 WRITE / READ DB 주소 설정우선 다음과 같이 datasource..
Bastion Host란, 외부에서 내부 네트워크로 들어가는 유일한 입구 역할을 한다.모든 외부 접속은 이 베스천 호스트를 통해서만 이루어진다. 현재 상황지금진행 중인 프로젝트는 Public Subnet에 있는 Bastion EC2를 거쳐서 Private Subnet에 있는 Ody EC2에 접근할 수 있다.우리 서버는 Ody EC2에서 실행되고 있으므로 해당 EC2로의 접근이 필요했고이 Bastion EC2는 모든 프로젝트 팀이 접근가능한 EC2다.원래라면 Public Subnet에 EC2에 Private Subnet EC2의 Pem키를 scp로 전송해 해당 Pem키로 private Subnet EC2로 접근했겠지만Bastion EC2에 우리 프로젝트 서버의 Pem 키를 넣으면 모든 프로젝트 팀이 이를 ..
ArgumentCaptor란?ArgumentCaptor는 Mockito 프레임워크에서 클래스로, Mock 객체의 메소드가 호출될 때 전달되는 인자를 이름 그대로 "캡처"하고 검증하는 데 사용된다.ArgumentCaptor는 복잡한 객체나 람다 함수와 같은 인자를 검증할 때 매우 유용하게 사용할 수 있다. ArgumentCaptor Mokito 공식 문서https://site.mockito.org/javadoc/current/org/mockito/ArgumentCaptor.html ArgumentCaptor (Mockito 2.2.7 API)Use it to capture argument values for further assertions. Mockito verifies argument values i..
이번 프로젝트에서 민감한 설정(DB 계정, 비밀번호 등)을 private 레포지토리에 저장하고 이 레포지토리를 서브모듈로 사용해 관리하고 있었다.하지만 서브모듈을 사용하는데에 다음과 같은 많은 번거로움이 있었다.서브모듈을 포함하고 있는 부모 레포지토리는 서브모듈로 적용한 레포지토리의 커밋 내역을 참조하고 있기 때문에 서브모듈에 수정사항이 생겼다면 꼭 서브모듈 먼저 push 후 메인 프로젝트를 push 하여야 한다.서브모듈로 적용한 레포지토리에 변경사항이 부모 레포지토리에 바로 반영되지 않으므로 서브모듈을 사용하는 프로젝트를 관리할 때 서브모듈의 상태를 항상 확인하고 변경사항이 있다면 update 해주어야만 반영된다.이러한 주의점들을 지켜주지 않으면 프로젝트를 진행하면서 서브모듈의 이전 커밋 내역을 들고와..