다음 글은 Real MySQL 스터디를 진행하면서 정리한 4.1장 내용입니다. 🙌 💡 Intro 프로젝트를 진행해보니 서비스의 대부분의 병목은 데이터베이스에서 발생한다는 것을 알 수 있었다. DBA가 아니더라도 기본적으로 파생된 쿼리가 어느 과정을 거쳐서 처리되는지, 성능을 좌우하는 시스템 변수들은 어떠한 것들이 있는지 아는 것이 매우 중요하다고 생각한다. MySQL 엔진은 데이터베이스의 뇌의 역할을 한다. 기본적은 서버 구조와 MySQL 엔진과 스토리지 엔진의 차이점 및 담당 부분을 이해해보자. 🌩 MySQL 서버의 구조 머리 역할을 하는 MySQL 엔진과 손발 역할을 하는 스토리지 엔진(InnoDB, MyISAM)이 있다. 스토리지 엔진은 핸들러 API를 만족하면 직접 구현하여 추가해서 사용할 수 있다. 🌩 MySQL 엔진 아키텍쳐 MySQL 전체구조 MySQL 엔진 먼저 MySQL 서버는 대부분의 상용 언어에서 지원할 수 있으며 MySQL 서버의 커넥션 핸들러에서 커넥션을 관…

💡 Intro 진행 중인 프로젝트에서 구현한 웹 어플리케이션이 어느 정도의 부하를 견딜 수 있는지에 대한 성능테스트를 진행했다. 프로젝트는 개발자를 타켓으로 한 깃헙 레포지토리를 연동한 게시물을 업로드하여 개발자들이 자신의 작업을 공유하고 다른 이들의 프로젝트를 캐줄얼하게 엿볼 수 있는 SNS형 웹 어플리케이션이다. 웹 어플리케이션에 들어가자마자 최신순으로 정렬된 게시물 피드를 볼 수 있다. (비로그인/로그인 모두 가능) 홈피드 게시물 조회 성능테스트를 진행, 병목 지점을 분석하고 개선하는 과정을 따라가보자. 🌩 사전 작업 테스트 더미 데이터 입력 테스트를 진행하기 위해서는 실제 운영환경과 최대한 유사한 환경에서 테스트하는 것이 중요하다. 운영환경과 유사한 환경이라고 하면 크게 1) 인프라 구조 2) 데이터 두 가지가 있다. 먼저 대량의 더미 데이터를 입력하도록 한다. (팀원 케빈이 수고해주었다 !! 👍) MariaDB 쿼리 캐시 끄기 왜 쿼리 캐시를 껐을까? 실제 어플리케이션에서…

💡 Intro 이전 포스트에서 진행한 프로젝트에서 홈피드 게시물 조회 성능 테스트에 대한 결과를 보고 개선대상을 파악하고 개선한다. 개선 후 테스트를 재진행하여 결과를 비교한다. 🌩 쿼리 진단 이전 포스트에서 진행한 성능 테스트를 통해 DB 쿼리 쪽 병목이 있다는 것을 알아냈다. 구체적으로 쿼리를 자세히 살펴보면서 어떤 문제가 있는지 확인해보자. 홈피드 게시물을 반환할 때 발생하는 slow query 현재는 포스트 조회하는 쿼리가 최대값으로는 3.62 초가 소요된다. 쿼리의 실행계획을 확인해서 문제점을 파악해보니 100만건의 데이터를 거의 다 훑으면서 filesort를 하고 있었다. 게시물을 최신순으로 정렬하여 상위 10개를 가지고 오는 Pagination을 적용하고 있기 때문이다. 🌩 개선하기 createt_At 칼럼에 인덱스를 추가하여 데이터가 정렬되도록 한다. 인덱스를 건 후 실행계획을 확인해보니 filesort가 제거되었고 훑는 row 수가 대폭 줄어들었다. 🌩 개선 후 성…

INTRO 현재 진행중인 프로젝트에서 DB Replication을 적용했었다. Replication 알아보기 DB replication 적용 이후 Master DB를 업그레이드 해야하는 상황에서 replicas와의 연동에 문제가 생긴적이 있었다. 이때 Master와 replicas 간의 데이터 연동 방법을 이해하고 해결한 (매우 간단한) 방법을 기록한다. Master DB와 replicas 동기화 Master DB에 데이터를 쓰기 위해서는 replicas에서 master db 의 데이터와 연결되어 있어야 한다. 그러기 위해서 replication을 설정할 때 라는 명령어를 통해서 나온 값과 값을 replica db 설정시 적용해 주었다. 여기서 File은 master db의 binary 로그 파일이고 Position 값은 해당 파일의 현재 위치이다. 위 log 파일에는 어떤 내용이 담겨 있을까? The MariaDB binary log is a series of files th…

INTRO DB Replication을 MySQL 공식 홈페이지에서 찾아보면 다음과 같이 말한다. Replication enables data from one MySQL databse server (known as a source) to be copied to one or more MySQL database servers (know as replicas) 출처 : 링크 즉, 하나의 데이터베이스(master/source)에서 다른 하나 또는 그 이상의 데이터베이스(slaves/replicas)로 데이터를 복제하여 저장하는 것이다. Replication은 비동기로 동작한다. 따라서 replicas가 master에 지속적으로 연결되어는 동기식으로 동작하지 않는다. 설정에 따라서 여러 데이터베이스, 선택된 데이터베이스, 선택된 테이블에만 replication을 적용할 수도 있다. MySQL replication 장점 공식 홈페이지에 나와있는 장점 4가지는 다음과 같다. Scale-out …

동시성 문제 발생 가능 상황 두개의 트랜잭션이 모두 읽는 연산을 하는 경우 문제가 되지 않는다. 하나의 트랜잭션은 read, 하나는 write인 경우 (Isolation으로 해결) Dirty Read 상황: 트랜잭션1이 write 할 때 트랜잭션2가 update된 데이터를 읽었지만 트랜잭션1이 rollback 되었을 때 발생 문제: 트랜잭션2가 무효된 데이터를 읽었음 Non-repeatable Read 상황: 트랜잭션1이 데이터를 read하고, 트랜잭션2가 데이터를 write 한 후, 트랜잭션1이 다시 동일한 데이터를 read 할 경우에 발생 문제: 트랜잭션이 1이 동일한 read를 했음에도 불구하고 바뀐 데이터를 읽음 Phantom Read 상황: 트랜잭션1이 데이터(범위)를 read하고, 트랜잭션 2가 데이터를 추가(insert) 했는데, 트랜잭션1이 다시 데이터를 read한 경우 문제: 동일한 read를 실행하였는데, 이전에 없었던 값이 추가됨 두개의 트랜잭션이 모…

트랜잭션을 사용하는 이유 트랜잭션을 사용하면 각각의 단위로 나누어져있는 작업의 단위를 하나로 합칠 수 있다. 즉, 일련의 연산들을 하나의 독립된 작업 단위로 보고 하나로 취급하기 위해서 사용하는 것이다. 언제 일련의 연산들을 하나로 봐야 할 때가 생길까? 예를 들어서 돈을 송금하는 시스템이 있다고 가정해보자. 계좌A에서 계좌B로 돈을 송금해야 할 때, 계좌A에 충분한 잔액이 있는 것을 확인하고 돈을 송금하기 위해서 돈을 차감했다. 그리고 계좌B에 입금을 하려고 하는 순간 예외가 발생하면서 입금을 하지 못했다. 그런데 계좌A에서는 여전히 돈이 차감된 상태이다. 중간에 송금하려고 했던 돈이 사라지게 된 것이다. 이때, 위의 과정을 로 관리를 하게 된다면 위의 여러 작업들을 하나의 단위로 보고 중간에 예외가 발생한다면 위에서 실행중이던 작업을 한꺼번에 롤백해준다. 트랜잭션 기본 방법 2개 이상의 쿼리를 하나의 커넥션으로 묶어 DB에 전송하고, 에러가 발생할 경우 자동으로 모든 과정…

Transaction 이란? 개인이 설정할 수 있는 작업의 최소 단위이다. Transaction을 기준으로 을 할 수도, 을 할 수도 있다. Transaction을 사용할 때 DBMS에서 ACID를 제공받을 수 있다. Atomic(원자성) : 한꺼번에 모두 처리가 되거나, 한꺼번에 모두 처리가 되지 않도록 원자성을 부여한다. 데이터 관련 일부만 처리되었을 때 생길 복잡한 상황과 부작용을 막을 수 있다. Consistency(일치성) : 하나의 데이터가 처리되었을 때 관련된 다른 테이블 혹은 상황에서 일관된 논리가 수행 되도록 하는 것을 보장한다 (ex. A 에서 1000원이 차감되면 B에서 1000원이 증감되어야 하는 상황 등등.) Isolation(독립성) : 데이터가 처리되는 도중 다른 일이 중간에 일어나지 않도록 해당 데이터를 보호하도록 보장. 중간에 다른 일이 끼어들어 부작용이 생기는 것을 방지한다. Durability(영구보존성) : 데이터를 DB에 저장하여 보존하도록 한…