실사례로 본 DB on Kubernetes 효과
기업의 가장 중요한 자산은 Data이다. 그 Data를 보관하고 관리하는게 Database이다. 따라서 가장 중요한 시스템 중 하나가 Database이다. 가장 중요하다 보니 안정성이 가장 우선시 된다. 대다수 회사가 Oracle 버전 Update 작업은 가장 나중에 안정성이 검증된 버전만 올리곤 한다.
요즈음 Kubernetes를 많이 사용하고 있다. 신규로 개발되는 Application의 거의 모든 Project는 컨테이너, Kube 기반이라는 Survey도 있다. WEB/WAS 뿐만 아니라 Database 까지 사용하는 고객이 늘고 있다. SK는 이미 2018년부터 DBaaS를 Kube 기반으로 운영 중이라고 컨퍼런스에서 소개 하였다.
운영자 입장에서는 겨우 안정적으로 DB를 운영 중인데 굳이 kubernetes라는 아직 성숙하지 않은 것 같은(?) 솔루션을 도입할 필요가 있을까 라는 생각이 든다.
그럼, database를 kube 환경에서 운영 시 어떤 이점이 있을까? 모 ERP 회사 MariaDB Database를 VM에서 Kube 기반으로 이전한 경험이 있다. 해당 경험을 소개해 보겠다.
먼저, 안정성 측면이다. MySQL/MariaDB, PostgreSQL, Redis, Kafka 등 대부분의 Database 관련 제품이 3중화를 지원하고 있다. 오라클 RAC 이중화 보다 3중화 이므로 안정성이 뛰어나다. 최대 2개 인스턴스, 노드가 동시에 장애가 발생하여도 서비스에는 문제가 없다.
그리고 컨테이너 특성 상 Application 재 시작 시 소요 시간이 1분 내외로 빠르다. 또한 노드가 다운되어도 별다는 설정없이 다른 노드에서 실행되는 자동 스케쥴링이 잘된다. 내가 구축에 참여한 모 ERP 회사는 1년 넘게 안정적으로 MariaDB를 운영 중이다.
[spkr@erdia22 ~ (scluster:mariadb)]$ kgp
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
mariadb-erp-0 2/2 Running 0 8d 10.10.100.35 dia03 <none> <none>
mariadb-erp-1 2/2 Running 0 20d 10.10.100.24 dia02 <none> <none>
mariadb-erp-2 2/2 Running 0 20d 10.10.100.27 dia01 <none> <none>
mariadb-gw-0 2/2 Running 0 20d 10.10.100.26 dia01 <none> <none>
mariadb-gw-1 1/2 Running 0 8d 10.10.100.22 dia03 <none> <none>
mariadb-mail-0 2/2 Running 0 20d 10.10.100.33 dia02 <none> <none>
mariadb-mail-1 2/2 Running 0 20d 10.10.100.36 dia01 <none> <none>(거의 모든) Database가 3중화 지원한다.
Oracle이 License 정책이 어떻게 되는지 모르겠는데 (인터넷에서는 이미 오라클도 kube 기반으로 잘 운영 중이라고 하기는 하지만) 오라클도 최소 VM 만큼 안정적으로 운영 할 수 있을 것이다. 구축 후 다양한 가용성 테스트(노드 & POD 다운, Disk 이중화 테스트) 시나리오를 통하여 충분히 검증 가능하다.
성능 측면에서 실제 측정한 결과 기존 VM 기반 HCI 장비 보다 Latency 기준 20배 이상 빨라졌다. 기존 장비는 HDD/SSD 구조이고 분산 파일 시스템 기반이라 디스크 I/O 측면에서 성능 Loss가 많았다. 이에 반하여, Local NVMe Disk를 사용하면 비약적인 성능 향상이 가능하다. 빠른 I/O latency(sub ms) 및 IOPS (노드 당 백만 IOPS)로 I/O 관련 DB Timeout 에러도 사라졌다. 모 회사는 DB 성능 이슈가 주요한 Migration 이유 였는데 (Kube 솔루션 도입이 목적이 아니라) 만족할만한 성과를 거두고 있다.
Kubernetes는 Application을 YAML 파일이라는 소스 코드로 관리한다. VM 처럼 명령어 기반이 아니다. 따라서, 같은 소스를 사용하므로 항상 같은 결과가 보장된다. 구성이 달라지고 서버가 달라지고 사람이 달라져도 결과는 항상 동일하다.
처음 만들 때 YAML 파일만 잘 만들면 이 후 모든 작업 결과가 동일하다. 휴먼 에러가 발생하지 않아 작업 시간이 대폭 줄어든다. 신규 DB를 생성하고 버전 업그레이드 작업 등이 운영자 업무인데 이 부문이 빠르게 처리된다. 실례로 10개 MariaDB Galera Cluster(30개 DB Instance) Database를 VM 기반에서 컨테이너 기반으로 Migration 하는데 2시간 걸렸다. 스테이징 환경에서 충분히 사전 검증 작업을 하여 실제 작업 소요 시간을 대폭 줄일 수 있었다.
그리고 Kube는 Declarative 방식으로 항상 선언된 상태를 자동으로 유지한다. Database를 Master-Slave 3중화로 구성하면 그 상태가 항상 유지된다. 물리 서버가 죽고 DB Process가 죽어도 자동으로 프로세스를 재실행하여 항상 동일 상태를 유지한다. 당연히 운영 단계에서 운영자 업무가 줄어든다. (새벽에 전화 받을 일이 없다) Google 같은 곳에서 관리자 혼자서 몇 만대의 서버를 운영한다는 이야기는 이같은 자동화가 가능하기 때문이다.
다음으로 컨테이너는 자원 효율이 뛰어나다. VM은 실제 사용량과 상관 없이 Max 사용량 기준으로 자원을 할당한다. 초기 VM 실행 시 max 사용량 128G 메모리를 할당하면 실 사용과 관계 없이 항상 128G를 사용한다. 이에 반하여, 컨테이너는 실 사용하는 만큼만 자원을 할당한다. 실 사례로 기존 VM 환경에서 단일 물리 노드 당 3~4개 DB만 운영 가능 하였는데, 컨테이너로 변경 이 후 물리 노드 당 9~10개 까지 운영하고 있다.
마지막 고객 사례로 SK 에서 발표한 내용 같이 소개드린다.
SK(주) CNCG(2020년) 발표 내용
- 2018년 부터 Managed DB 서비스 제공 중
Diamanti & Managed Kubernetes Service 문의 : leejunghoon@spkr.co.kr
