Jins' Dev Inside

MySQL 의 빈로그 혹은 바이너리 로그는 MySQL 서버 인스턴스의 데이터 변경사항들에 대한 정보를 포함하는 로그 파일의 세트이다.

여기에는 에러코드, 바이너리 로그 자체에 대한 메타데이터 등 다양한 데이터가 같이 포함되게 된다.

기본적으로 Transaction Commit 시에 기록되어지며, 데이터 변경 순서를 보장한다는 특징이 있다.

주로 복제(Replication) 및 복구(Recovery)를 목적으로 binary log 가 사용되어지며, 복제 시에는 Secondary Node 가 Primary Node 로부터 binlog 데이터를 전달받아서 로깅하게 된다. (그리고 전달받아 로깅하는 이 로그를 릴레이 로그 라고 한다)

MySQL 에서 제공하는 바이너리 로그에는 3가지 종류가 있다.

(1) Statement-based logging

Insert, Update, Delete 에 대한 SQL 문들이 포함된다. Statement base 로 복제를 수행 시 Statement-Based Replication (SBR) 이라고 한다.

이 방식에서는 로그 파일에 적은 데이터가 기록되며, 로그 파일에 필요한 저장 공간이 줄어드는 장점이 있다.

백업에 대한 복구는 Replay 처럼 수행되며 빠르게 복원이 수행될 수 있다.

다만 로그 기반으로 복원 시 제약이 조금 있는데, 예를들어 RAND(), LOAD_FILE, UUID() 등과 같이 Deterministic 하지 않은 동작에 대해서는 정확히 복제가 안된다고 보면 된다. (당연히 RAND() 를 복원해서 나온 두 번의 결과가 같을리는 만무하다!)

(2) Row-based logging

이 방식은 각 행에 대한 변화를 기록한다. Row-based logging 을 이용해서 Primary → Secondary 로 복제를 수행할 수 있고, 이를 Row-Based Replication(RBR)이라 한다

RBL 의 경우 각 행의 변경 사항을 이진 로그에 기록하므로 로그 파일의 크기가 매우 빠르게 증가할 수 있으며 지연이 발생할 수도 있다.

또한, 임시 테이블의 경우 RBL 기반으로 복제되지 않으므로 임시 테이블 관련 구문은 Statement base 로 기록되어야 한다.

(3) 혼합형

MySQL 5.1 이상부터 Row-based logging 과 함께 혼합형태가 지원되어진다. 기본적으로는 Statement based logging 을 사용하지만, 스토리지 엔진 및 특정 명령문에 따라 로그가 자동으로 Row based logging 으로 기록되어진다.

물론 사용하는 개발자 입장에서는 큰 차이가 느껴지지는 않는다.

mysqlbinlog 유틸리티를 사용하면 바이너리 로그에 대한 내용을 쉽게 조회해볼 수 있다.

또 한가지.. 바이너리 로그와 헷갈리는 개념이 MySQL 의 Transaction log (트랜잭션 로그) 라는 개념이다.

binlog 는 데이터베이스에 기록 및 업데이트한 이력(History)을 로깅하는 개념이고, 이를 기반으로 상태 복원에 대해 핵심적으로 사용될 수 있는 Incremental Backup 을 지원한다.

반면 transaction log(redo log) 는 트랜잭션에 대한 처리, 롤백, Crash Recovery, Point In Time Recovery 등을 위한 용도로 사용되어지게 된다. 

MySQL 에서 트랜잭션은 InnoDB 스토리지 엔진만 사용하므로, MyISAM과 같은 스토리지 엔진에서는 binlog 만 사용하게 된다.

Point In Time Recovery 가 트랜잭션 로그를 통해서 지원되므로, 어떤 데이터베이스 솔루션 등을 쓴다라고 할 때에는 Transaction Log 에 대한 지원을 살펴볼 필요가 있겠다.

컨테이너로 어플리케이션 워크로드를 운영하는 것은 일반 가상 환경에서 서버를 운영하는 것과 다르다.

특히 실제 서비스 운영 단계에 봉착하면 컨테이너 자체의 관리 뿐 아니라 Docker 설정 환경 상 이슈, 컨테이너 들 간에 Dependency 관리 및 스케일링과 같은 다양한 문제를 만나게 되며, 이러한 문제를 마주치면 컨테이너가 무조건 좋은 기술만은 아니라는 생각이 들게 된다.

이 문제를 해결하기 위해 실제 프로덕션 환경에서는 Container 들 간에 논리적인 Orchestration 을 수행하게 된다. 이를 통해 컨테이너를 적절히 배치하고 스케줄링하며 죽은 컨테이너를 재구성해준다.

이를 통해 실제로 컨테이너 기반의 서비스를 한다는 것은 기존 전통적인 방식대로 몇개 컨테이너 위에서 서비스를 구동하고 직접 유지보수하는 것이 아니라 수많은 컨테이너를 띄워놓고 Container Orchestration Tool 을 통해 수많은 컨테이너의 관리 및 제어를 하는 것을 의미하게 된다.

이를 통해 각종 리소스의 관리, 컨테이너 라이프사이클 관리 및 서비스 관리 전반을 포괄하는 Container Orchestrator 에 대해서는 반드시 알아야하는 필수 지식이 되게 된다. 컨테이너 오케스트레이터는 YAML, JSON 과 같은 설정 파일을 기반으로 컨테이너 클러스터를 서술하며 이를 통해 어플리케이션 환경, 네트워크 구성 방법, 로그 저장 방식 등 어플리케이션 전체 환경을 포괄하는 코드 파이프라인을 구성한다.

가장 유명한 서비스는 역시 구글의 Kubernetes(k8s) 이다. 사실상 컨테이너 오케스트레이션 툴의 스탠다드가 되어가고 있으며, 이를 클라우드 위에서 활용한다면 아마존의 EKS(Elastic Kubernetes Service) 등 위에서 매니지드 인프라를 통해 제공받게 된다.

쿠버네티스는 구글에서 시작되어 CNCF 재단에서 기증받아 운영되는 오픈소스 프로젝트로, 운영 환경의 기본 사상 자체가 모든 클러스터 환경의 관리를 kubectl 과 같은 CLI 를 통해 YAML 파일 형태로 관리하는 것을 추구한다. (실제로 수많은 컨테이너를 중앙 관리하려면 코드 없이 관리가 사실 상 불가능하다..)

쿠버네티스에서 컨테이너들은 일종의 클러스터(Cluster)를 구성하며 이는 노드들의 집합으로 이해하면 된다.

쿠버네티스는 위와 같이 제어부(Control Plane)와 데이터부(Data Plane)을 갖고 있으며, Control Plane 에서는 Worker Node 들과 Cluster 내의 Pod 들을 관리하고 제어하는 역할을 수행하고, 사용자가 제어할 수 있는 인터페이스를 API 서버 형태로 제공한다.

Data Plane 은 워커 노드(Worker Node)들로 구성되어 있으며 컨테이너화된 어플리케이션의 구성 요소인 파드(Pod)를 호스팅하게 된다.

데이터 플레인에는 Kube-proxy 라는 일종의 프록시 서버가 존재하는데, Data Plane 내에서 네트워크의 조작을 담당하며, 특히 각 Pod 가 Failover 될 수 있기 때문에 해당 부분에 대한 제어 등 Access 를 위한 엔드포인트로써 사용되어진다.

Data Plane 의 kubelet 은 컨테이너 제어를 위한 런타임 인터페이스로 초창기에는 Docker 에 종속적인 내부 모듈이었지만, 이제는 표준화된 런타임인 Container Runtime Interface(CRI) 를 기반으로 구성되어 컨테이너 관리를 위한 추상화된 계층 형태를 제공한다.

개발자 및 관리자는 Kubectl 이라는 쿠버네티스 API 명령어를 인터페이스로 k8s 클러스터의 컨트롤 플레인과 통신하며, 내부를 CLI 로 제어한다. 

기초적인 개념에 대한 1차 정리는 여기까지 마치고, 내부 구성 요소들에 대한 개념은 다음 포스팅에 정리합니다. :) 

빅데이터 기반 분석은 많은 엔터프라이즈에서 기본적으로 고려하는 부분이 되었으며, 이에 대해 기본적으로 이해하는데 도움이 되는 몇가지 기본 지식들을 정리해보았다.

최근의 데이터 분석의 추세는 Data Gravity 라는 용어로 시작할 수 있을 것 같다. 기술적인 용어라기 보다는 추세를 비유하는 용어에 가까운데, 이 개념은 다음과 같다

• 개념 : 데이터 규모가 커지고 무거워질 수록 비즈니스를 끌어당기는 중력(Gravity) 이 강해지는 현상을 나타내는 개념
• 성질 : 데이터를 저장할 스토리지, 데이터를 운용 및 관리할 인력, 데이터 활용을 위한 어플리케이션 등 비즈니스는 데이터에 기반해서 함께 이동한다

즉, 데이터 기반의 의사 결정을 통해 서비스의 방향이 결정되고 향후 비즈니스 가치를 판단하는 기준이 바뀔 수 있다는 측면이다.

이러한 데이터 기반의 의사 결정을 위해 데이터를 다루는 큰 두가지 틀이 있을 수 있다.

(1) Data Warehouse (데이터 웨어하우스)

• 데이터를 저장해두는 창고. 데이터 분석이 필요할 때 창고의 데이터를 가져다 이용하자는 개념
• 분석을 위해 OLAP 툴 또는 SQL 을 이용하여 최종 정보 이용자들이 활용한다
• 데이터들에 대해 정형화된 형식으로 통합해 단일 형식으로 구성
• 복잡한 데이터 모델에 대해 갖고 있는 데이터 모델에 제약을 맞춰야하는 이유 등으로 인해 데이터 모델 통합이 어렵고, 인프라 증설에 따른 운영 비용이 많이 발생

데이터 웨어하우스는 잘 구성된 데이터를 규격화된 데이터베이스에 적재해놓고 쿼리를 조합해서 필요한 정보를 얻어내는 방식이다.

가장 친숙하게는 관계형 데이터베이스(RDB) 에서 쿼리를 통해 데이터를 조회하는 것도 웨어하우싱 방식의 접근 방식이라 할 수 있겠다.

장점으로는 적재(Storing)된 데이터를 정해진 Case 에 대해서는 다루기가 아주 쉽다. 정형화된 형식이기 때문에 마케팅, 사업 등 엔지니어가 아니라도 쉽게 조회 및 집계 등이 가능하다.

단점으로는 데이터를 잘 구성해서 적재해주는 측면이 중요하다. 특히 최근에 생성되는 비정형 데이터를 사용할 수 있는 형태의 정형 데이터로 바꿔줘야 한다. 또한 데이터가 적재되는 방식은 데이터가 사용되는 방식과 다른 경우가 많아 확장성을 갖추기가 쉽지 않다.

(2) Data Lake (데이터 레이크)

• 정형 데이터로 구성된 전통적 소스 외에도 수많은 비정형 데이터들을 실시간으로 수집, 정제, 통합하여 활용하기 위해 확장된 개념
• Raw 데이터 형식으로 저장했다가 나중에 쉽게 분석할 수 있도록 구성
  • 이를 위해 분산 시스템 환경에서 데이터를 독립적으로 쪼개고 다시 취합하는 기법을 사용
  • 하둡과 같은 맵리듀스 방식이 대표적
• 데이터를 구축하고 활용하는 기술이 어려워서 습득과 활용이 쉽지 않다

데이터 레이크는 데이터 웨어하우스에서 접근 방식을 바꾼 방법이다. 비정형 데이터를 정형화시키지 않고 Raw 데이터 형태로 적재하고, 사용할 때 필요에 맞게끔 구성하는 방법이다.

장점으로는 데이터의 수집(Ingestion) 및 적재(Storing) 에 있어서 부담을 덜 수 있다. 데이터의 정형화에 대한 부담이 적기 때문에 새로이 비즈니스 확장이나 새로운 데이터가 들어오더라도 비정형으로 그냥 적재하면 된다. 따라서 데이터의 수집 자체가 더 용이하다.

단점으로는 결국 데이터는 사용 시에 Use Case 에 맞게 형변환되어야 한다. 따라서 적재된 데이터의 사용을 위해 별도의 인프라 및 시스템이 필요한 경우가 많다. 이런 측면으로 인해 비개발자가 다루기가 쉽지 않다.

최근의 추세는 Data Lake 형태로 온갖 데이터를 몰아넣고, 이를 적절한 사례에 맞게 가져가 쓰는 것으로 보인다.

비즈니스 확장성이 중요해진 추세다보니, 언제 어떤 데이터가 어떻게 쓰일지 모르고, 따라서 일단 적재해놓고 적합한 사용 사례에 맞게 데이터 분석 시스템을 모두 갖춰놓고, 이용하는 방식으로 많이 사용되어지는 것 같다.

이제 빅데이터도 어느새 알아야하는 기본 지식이 되어가기 때문에, 기반 지식들을 알아두면 많이 도움이 될 것으로 보인다.