분류 전체보기

1. InnoDB 버퍼 풀 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간이다. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다. 일반적인 애플리케이션에서는 INSERT, UPDATE, DELETE 처럼 데이터를 변경하는 쿼리는 데이터 파일의 이곳저곳에 위치한 레코드를 변경하기 때문에 랜덤한 디스크 작업을 발생시킨다. 하지만, 버퍼 풀이 이러한 변경된 데이터를 모아서 처리하면 랜덤한 디스크 작업의 횟수를 줄일 수 있다. 버퍼 풀의 크기 설정 운영체제와 각 클라이언트 스레드가 사용할 메모리를 고려하여 설정해야 한다. MySQL 5.7 버전부터는 InnoDB 버퍼 풀의 크기를 동적으로 조절할 수 있게 개선되었다. 따라서 상황을 조금씩 보면서 증가시키는게 최..

MySQL 5.5 버전 이후 부터는 기본 스토리지 엔진이 InnoDB 스토리지 엔진으로 변경되었다. 1. InnoDB 스토리지 엔진 InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공하며, 그 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다. 1-1. PK에 의한 클러스터링 InnoDB의 모든 테이블은 기본적으로 PK를 기준으로 순서대로 클러스터링되어 디스크에 저장되며, 모든 세컨더리 인덱스는 레코드의 주소 대신 PK의 값을 논리적인 주소로 사용한다. PK가 클러스터링 인덱스이기 때문에 PK를 이용한 레인지 스캔은 상당히 빨리 처리될 수 있다. 결과적으로 쿼리의 실행 계획에서 다른 보조 인덱스보다 PK가 선택될 확률이 높다. MyISAM ..

MySQL 서버는 크게 머리 역할을 하는 MYSQL 엔진과 손발 역할을 담당하는 스토리지 엔진으로 구성된다. 기본으로 제공되는 스토리지 엔진으로는 InnoDB과 MyISAM 등이 있고, 핸들러 API를 만족하면 누구든지 스토리지 엔진을 추가하여 MYSQL 서버에 추가할 수 있다. 1. MYSQL 전체 구조 MySQL 고유의 C API부터 JDBC나 ODBC, 그리고 .NET의 표준 드라이버를 제공하며, 이러한 드라이버를 이용하여 C/C++, PHP, 자바, 펄, 파이썬, 루비, .NET 등 모든 언어로 MYSQL 서버에서 쿼리를 사용할 수 있게 지원한다. MySQL 엔진 Client로부터의 접속 및 쿼리 요청을 처리하는 커넥션 핸들러 SQL 파서 및 전처리기 쿼리의 최적화된 실행을 위한 옵티마이저 위 구..

1. 배포 자동화를 구축하게 된 계기 현재 교내 서버실에 운영서버가 구축되어 있고, 교내망 정책에 따라 외부 액세스 포트는 80, 443 2개만 사용할 수 있었다. 이미 80, 443은 애플리케이션 배포를 위해 사용하고 있다. 따라서 교내망에 접속해 있을 때만 22번 포트로 ssh 접속을 통해 변경사항을 운영서버에 배포할 수 있었다. 이렇듯 교내망에 접속해야만 한다는 문제도 있었지만, 결국에는 수동으로 배포하다 보니 명령어를 잘못 입력하는 경우도 있었고 배포할 때마다 반복되는 작업을 진행하다 보니 배포 자동화가 정말 절실했다. 2. 배포 자동화 플로우 우선 Jenkins를 이용하여 배포 자동화를 구축하고자 한다. PR이 Master 브랜치로 Merge되면 Github WebHook이 Trigger 된다...

1. 클라우드 서비스로 이전하게 된 계기 현재 교내 서버실에 KIOSEK 서비스가 On-Premise 환경으로 배포되었있고, 이전에는 프론트 개발자와의 지속적인 협업을 위한 개발 서버는 필요할 때마다 내 노트북에서 틀어서 포트포워딩 해주는 방식으로 하였다. 해당 방식은 너무나도 비효율적이었지만, 가용할 물리 서버가 없었고 사실 환경을 하나 더 구축한다는게 귀찮은 점도 있었다. 하지만 한계를 느꼈고, 이번 기회에 개발 서버를 AWS 클라우드 환경에 구축해서 프론트엔드 개발자에게 IAM 계정을 할당하고 필요할 때마다 서버를 껐다 켤 수 있게 할 생각으로 구축하게 되었다. 2. 사용할 AWS 자원 정하기 1. 키오스크 백엔드 어플리케이션과 NGINX 웹서버를 운영 할 EC2 인스턴스가 먼저 필요했다. 해당 시..

1. 문제상황 Repository단에서 Command와 Query를 분리하여 책임을 분리함으로써 코드 응집도와 유지보수성을 높이고자 하였다. 이에 처음 시도했던 방법은 아래와 같다. Create, Update, Delete를 담당할 CommandableRepo Interface와 Read를 담당할 QueryableRepo Interface로 나누었다. 구현체는 CommandRepo, QueryRepo로 구현한다. 하지만, 문제가 생겼다. 어떠한 엔티티를 save해야 하는 상황을 가정할 때, 중복조회나 다른 조회 메서드를 이용해야 하는 상황이 주로 발생했다. 이럴때, Repository를 사용해야 하는 Service 계층에서 의존성이 너무나 많아지는 문제가 발생했다. 2. 문제해결 과정 1 - interf..