MySQL을 운영할 때 DC1, DC2 작업을 하는 과정이 갑자기 궁금해져서 진화과정을 공부해보고 정리한다.
MySQL 한 대에 앱이 붙어서 read/write를 다 받는 가장 단순한 구조이다. → 단순한건 운영이 쉽다라는 뜻이고 이건 사실 엄청난 이점이다. 하지만.. 잘 돌때는 아무 문제가 없지만 문제는 잘 안돌때와 커질 때 드러난다.
이 서버가 죽으면 서비스가 전면 중단된다. 디스크 고장, 커널 패틱, OOM 등 다양한 요소로 MySQL은 죽을 수 있다. 복구는 다시 이 프로세스를 살리는 건데, 그 사이 서비스는 전면 장애를 맞을 수 밖에 없다. → 이중화의 동기
트래픽이 늘면 read든 write든 한대가 감당하기 힘들 수 있다. CPU / IO / Memory 등이 한계에 닿으면 스케일업을 해야하고, 이것도 천장이 있다. read는 대부분 다른데서 받아도 되지 않나? 가 다음 2장 내용의 시작점이다.
일관성 있는 백업을 뜨려면 부하가 걸리거나 락이 잡힌다. 운영 트래픽을 받는 장비에서 이걸 하면 서비스가 느려진다. “백업 전용으로 데이터 사본이 하나 더 있으면?”도 다음 2장 내용인 복제로 이어진다.
장비가 아니라 랙, 전원, DC가 통째로 날아가는 상황엔 백업도 사라질 수 있다. 물리적으로 떨어진 곳에 사본이 있어야 살아남을 수 있는데 이게 뒤에 나오는 멀티 DC까지 고려하는 이유이다.
핵심 아이디어는 다음과 같다.