[DOIK2] 스터디: Operator 를 사용하는 이유, InnoDB 주요 Component

 

주의사항

이 글은 DIOK2 스터디에서 진행한 내용을 바탕으로 작성한 내용입니다. 공부중인 내용이기때문에, 틀린 부분이 있을수 있습니다.

 

 

기본 용어 정리

Kubernetes: 선언적 상태관리 시스템

Operator: K8s 애플리케이션을 패키징, 배포, 관리하는 방법론

Operator Pattern: K8s에서 Operator 방법론을 사용해서 확장하는 패턴

Operator Framework: K8s에서 Operator를 실제 구현하고 관리하는 프레임워크

CRD: Operator를 사용할 상태관리용 오브젝트들의 Spec을 정의

CR: CRD의 Spec을 따르는 오브젝트들의 실제 데이터 상태

CC(Custom Controller): CR의 상태를 기준으로, CR을 desire stated로 바꾸기위해서 처리하는 컨트롤루프. Control Plane에 존재한다.

 

 

Operator를 사용하는 이유

‘운영자’관점에서 보았을때, 주로 하는 작업들을 묶어서 자동화하거나 관리 편의성을 생각해서 사용하는것이 주된 목적. 이를 위해서는 아래의 내용이 진행되어야함.

1. 관리해야할 Object의 Spec을 CRD에 정의(CPU, RAM, Docker image…)
2. Object가 유지해야할 상태정보를 CR객체로 생성, 상태데이터는 Etcd에 저장
3. 상태유지를 위한 CC를 구성해서 ControlPlane에 등록 (CC는 실제상태 정보를 갖고있는 CR을 모니터링)

 

일반 K8s Object를 관리할때 동작흐름

• 이미 잘 정의된 Object들은 Controller에서 관리할수 있다

 

 

CR,CRD를 사용해서 K8s Object를 관리할때 동작흐름

• 새로운 Object의 형태 를 CRD로 정의하고
• 기존 Object가 아닌 새로운 Spec을 가지는 Obect를 다루기 위한 CC(Custom Controller)가 필요하며
• 정의된 CRD를 베이스로 만들어지는 CR을 관리하기위해서 CC가 kube-apiserver에 연결되서 관리한다

 

 

 

Operator vs Helm

‘Operator와 Helm을 비교하자면 어떤게 더 포괄적인 기능일까?’ 라는 질문의 답엔 Operator이라고 말을 할수 있다. Opeartor는 Helm기능을 포함하고있기 때문이다.

 

간단히 비교하면 다음과같다.

• Helm: Application 의 배포 및 업그레이드를 다룬다.
• Operator: 자체를 Helm Chart로 만들수도 있고, Operator 내부에서 애플리케이션 배포를 Helm을 통해서 할수 있다.

 

MySQL → InnoDB Cluster

기존 MySQL 의 단점

 MySQL 서버는 자체적으로 Failover 기능을 처리할 수 없습니다. 따라서, Source 서버에 장애가 발생한다면 Replica 서버가 새로운 Source 서버 역할을 할 수 있게 해주어야합니다.

 이때 필요한 것은 Replica 서버에 설정된 읽기모드 해제, Split-brain 방지, 서버 설정 변경, 커넥션 설정 등등 다양한 작업이 필요하며, 이 모든 과정은 수동으로 진행됩니다.

 

이런 다양한 단점들 때문에 MySQL서버 내부적으로 HA솔루션인 InnoDB클러스터를 도입하였습니다.

 

 

InnoDB Cluster Architecture

 

 

주요 컴포넌트

• Group Replication
• Primary Instance 로 들어오는 Data를 Secondary로 동기화 하는 작업을 진행합니다.
• 살아있는 MySQL 서버들에 대한 멤버쉽 관리(Group 내부의 멤버의 추가 및 제거 등)을 진행합니다.
• Primary Instance 는 Read/Write 기능을 가진 Source 서버입니다. 최소 1대 이상을 사용해야합니다.
• Secondary Instance는 Read only 기능인 Replica 서버입니다. 최소2대 이상을 사용해야합니다.
• MySQL Router

• Client Application서버와 MySQL서버 사이에서 동작하는 미들웨어 프로그램입니다.
• Client Application은 MySQL Router에 연결해서 쿼리를 작성하고, Router는 실행한 쿼리를 적절한 MySQL서버로 전달하는 Proxy역할 입니다.
• Client Application은 InnoDB클러스터가 어떻게 구성되어있는지 알 필요가없고, MySQL Router 정보만 알고 있으면 됩니다.
• MySQL Shell

• MySQL 클라이언트 프로그램입니다.
• 기본적인 SQL문 실행을 합니다.
• Cluster 구성 등의 어드민 작업을 하게해주는 Admin API를 제공합니다.

 

InnoDB 클러스터 장애대응순서

상황: MySQL 서버(여기서는 Primary, Secondary 서버들로 구성되어있는 클러스터를 지칭함) 에서 특정 서버에 장애발생하여 사용하지 못하는 경우

 

장애대응순서

1. Group Replication: 장애가 발생한 서버를 감지하고, 해당 서버를 Group Replication되는 서버에서 제외시킴
2. MySQL Router: Group Replication 서버의 변경을 감지하고(복제 토폴로지 변경), Client Application으로부터 실행된 쿼리가 정상작동하는 서버로만 제공될수 있게 메타데이터를 갱신한다.