2주차 - 오퍼레이터 & MySQL 오퍼레이터

1. 쿠버네티스 오퍼레이터

  - 오퍼레이터는 쿠버네티스 추상화를 통해 관리 대상 소프트웨어의 전체 라이프사이클을 자동화, 애플리케이션을 패키징-배포-관리하는 툴입니다. (공식문서)

 

  - CRD(Custom REsource Definition) : 오퍼레이터로 사용할 상태 관리용 객체 Spec 정의

  - CR(Custom Resource) : CRD의 spec을 지키는 객체들의 실제 상태 데이터 조합

  - CC(Custom Controller) : CR에 규정된 상태를 유지하기 위한 컨트롤 루프

 

 

2. DB 기본지식

2.1. DB에서의 Transaction이란?

  - (일반적 정의) 쪼갤 수 없는 업무 처리의 최소 단위
  - (DB적 정의) 데이터베이스의 상태를 변화시키기 해서 수행하는 작업의 단위 
  - (또 다른 정의) 절대로 깨져서는 안되는 하나의 작업

  그 업무 환경에 따라 의미는 다르겠지만, 위 3가지의 뜻을 모두 합친 뜻이라고 볼 수 있다. 즉 우리는 DB에서의 Transaction을 묻고 있으므로, DB 상태 변화를 시키는 최소 수행 작업 단위이며, 절대 깨지면 안되는 작업으로 볼 수 있다.

이 말은 무슨말인가? 우리는 DB에 중요한 자료들을 주로 담는다. 여러분이 송금을 했는데 송금작업이 안되거나 실패한다면? 쇼핑몰에서 옷을 주문했는데 주문이 잘못되었다면 과연 좋겠는가?

 

2.2 복제가 깨진다는 것의 의미는?

  DB는 중요한 자료를 담고 있기 때문에 기본적으로 Main 서버(프라이머리)와 복제본(세컨더리)로 이중화 이상의 구성을 갖추고 있다. 하지만 이 모두가 1개의 DB처럼 작동해야하므로 세컨더리에 지속적인 동기화를 진행하는 형식을 취한다. 문제는 트랜젝션을 주고 받는 Main 서버가 죽으면 자료가 동기화 되기도 전에 날라가 버릴 수도 있다. 이런식으로 모든 자료가 단 1개도 빠지지 않고 복제되어야 하는데, 복제되기도 전에 DB가 죽어버리는 상황을 말한다.

 

2.3 복제 시 동기화 방식은 무엇인가요?

비동기 복제

  - 소스 서버가 레플리카 서버의 변경 이벤트에 대해 신경쓰지 않는다. (마치 UDP 같은)

  - 소스 서버에서 발생한 트랜젝션이 레플리카 서버에 도달하지 않은 상태로 장애 발생시, 자료가 날라갈 수 있음.

 

반동기 복제

  - 소스 서버가 레플리카 서버의 변경 이벤트가 정상 완료되었는지 확인하고 커밋을 하고, 클라이언트에게 전달된다. 

  - 적어도 하나 이상의 레플리카에 안정성을 보장한다.

  - 트랜잭션 전송이 보장된 것이지, 데이터의 실제 적용이 보장된 것은 아님.

  - 서버응답을 기다리므로, 비동기 방식보다 트랜잭션 처리가 느릴 수 있음 (타임아웃시 비동기로 전환됨)

 

3. MySQL 소개

  MySQL은 가장 널리 활용되는 RDBMS 오픈소스이다. 다양한 운영체제에서 사용 가능하고, 다양한 프로그래밍 언어와 연동될 수 있다. 

 

3.1 MySQL 복제 전략

싱글 레플리카 복제  : 1개 Source, 1개 Replica

  - Source 서버의 예비 및 데이터 백업용으로 Replica를 사용

 

멀티 레플리카 복제 : 1개 Source, 2개 이상 Replica

  - Replica1개는 예비 및 데이터 백업으로 사용하고, 나머지 1개는 읽기 요청 분산 등으로 활용

 

체인 복제  :  1:M:M의 구조

  - Source 서버의 바이너리 배포 역할이 Replica가 많아지면서, 일부 Replica 서버가 바이너리 배포를 담당하기 위해 또 다른 Replica를 갖추게 활용

 

듀얼 소스 복제  :  2개가 각각 Source + Replica를 담당

  - 두 서버 모두 쓰기가 가능하며, 서로 복제를 하므로 동일한 자료를 유지

  - 목적에 따라 Active-Active / Active-Passive 형태가 가능

  - 1개의 서버가 죽어도 다른 서버가 그대로 Source 서버 역할이 가능

 

멀티 소스 복제  :  2개 이상의 Source, 1개 Replica

  - 여러 서버에 존재하는 다른 데이터를 하나의 Replica 서버로 통합함

  - 샤딩된 테이블 데이터를 하나의 테이블로 병합할 수 있음

 

4. InnoDB 클러스터

  - MySQL이 자체적으로 Failover를 처리하지 못해, 장애 발생시 레플리카 서버가 새로운 소스 서버가 되도록 작업을 수행하는 InnoDB 클러스터를 사용한다. (MySQL의 HA클러스터 라고 볼 수 있다)

https://dev.mysql.com/doc/mysql-shell/8.0/en/mysql-innodb-cluster.html

  - MySQL Router : Client가 MySQL과 소통하기 위한 Gateway 및 route 용도로 사용됩니다.

  - Cluster Admin은 MySQL Shell을 통해서도 Primary에 명령을 내릴 수 있습니다.

 

 

가볍게 오퍼레이터 개념 및 DB에 대한 지식을 배웠고 본격적으로 다음 포스팅에 MySQL 오퍼레이터를 사용해 보겠습니다.