반응형
레디스를 캐시로 잘 활용하기 위해서는 어떤 캐싱 전략을 적절히 도입하느냐에 따라 다르다.이 적절히라는 말은 캐싱 전략을 데이터의 특성과 엑세스 패턴을 잘 고려해 적용하냐는 것이다.어떤 캐싱 전략들이 있는지 한 번 알아보고 자신의 목적에 맞는 캐싱 전략을 선택할 수 있도록 하자. Redis에 대해 알아보고 싶다면 아래 포스팅을 참고하자.2023.09.11 - [◼ CS 기초 지식/[데이터베이스]] - [Redis] 레디스란? 특징, 활용예시, 비교 정리읽기 전략 Look Aside 전략1. cache에서 원하는 cache 데이터가 있는지 조회 (Cache Hit)2. 없다면 DB에서 조회 (Cache Miss)3. DB에서 조회한 데이터를 cache에 업데이트 데이터를 반복적으로 읽는 작업이 많을 때 사용..
DB Replication(레플리케이션)이란?Replication이란 번역하면 ‘복제’라는 뜻으로 DB를 복제한다는 뜻이다.기준이 되는 서버를 Source(원본) 서버라 하고, Source 서버와 동일한 내용을 갖는 또 다른 서버를 Replica(복제본)라 한다.즉, DB를 복제해서 여러 대의 DB 서버에 저장하는 방식이다.위는 Replication 기본 형태로 Source는 쓰기 작업만, Replica는 읽기 작업만 수행하도록 구성한다.(이외에도 다양한 Replication 방식이 있는데 ‘MySQL Replication 구성 형태’ 목차에서 설명한다.) - 참고로 기존에는 Master/Slave라는 용어를 사용해왔지만 위키백과에서 다음과 같은 문제로 Source/Replica와 같은 용어가 채택되고 ..
왜 저장 순서와 다르게 조회가 되지..? (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 키를 넣으면 모든 프로젝트 팀이 이를 ..