Jins' Dev Inside

분산 환경의 처리는 일반적인 환경의 구성과 많이 다르며 분산시스템의 특이성에 대한 개념들이 있다.

특히나 자주 듣게 되는 단어 중 하나는 결과적 일관성(Eventual Consistency) 라는 개념으로, 분산 시스템(Distributed System) 을 운영하게 되면 흔치않게 접하게 된다.

이는 개념과 관련된 이론이 그만큼 중요한 내용임을 반증한다.

먼저 예로 들은 Eventual Consistency 에 대해 설명하자면 이는 분산 컴퓨팅(Distributed Computing) 에서 고가용성(High Availability)을 보장하기 위한 방법의 하나로

"주어진 데이터에 대한 변경이 없다면 해당 Element 에 대한 모든 Access 는 가장 최근에 변경된 내용을 가리킨다" 는 정의를 말한다.

분산 시스템에서 데이터를 조회할 때 모든 시스템이 동일한 데이터를 가질 수 있다고 보장할 수는 없으며 결과적 일관성은 어느 시점에는 데이터가 다를 수 있지만, 결국에는 모든 시스템이 최신의 데이터를 가질 수 있도록 보장된다는 내용이다.

이는 BASE 원칙의 일종으로 분류되기도 한다. BASE 원칙이란 다음의 원칙들이 포함된다.

- Basically Available : 일반적인 Read / Write 에 대한 동작이 "가능한만큼" 지원된다.

(여기서 가능한만큼 이라 함은, 동작이 가능하나 Consistency 에 대한 보장이 되지않는다는 점이다.)

- Soft state : Consistency 가 보장되지 않기 때문에 상태(State) 에 대해 Solid 하게 정의하지 못하다.

- Eventually consistent : 위에 언급된 Eventual Consistency 개념에 따라 충분한 시간이 흐르면 모든 시스템 환경 내에서 데이터는 최신의 데이터가 보장된다.

BASE 원칙은 전통의 트랜잭션 시스템을 위한 ACID 원칙에 반대된다. 이는 분산 환경에서 나타나는 특징이기 때문이다.

이러한 특징에 대해 CAP Theorem 은 다음 3가지 조건을 모두 만족하는 분산 시스템을 만드는 것이 불가능함을 정의한다.

- 일관성(Consistency) : 모든 시스템의 데이터는 어떤 순간에 항상 같은 데이터를 갖는다.

- 가용성(Availability) : 분산 시스템에 대한 모든 요청은 내용 혹은 성공/실패에 상관없이 응답을 반환할 수 있다.

- 내구성(Partition Tolerance) : 네트워크 장애 등 여러 상황에서도 시스템은 동작할 수 있다.

분산환경 특징 상 3가지 성질을 모두 만족할 수는 없고, 일반적으로 다음과 같이 선택된다.

- CP (Consistency & Partition Tolerance) : 어떤 상황에서도 안정적으로 시스템은 운영되지만 Consistency 가 보장되지 않는다면 Error 를 반환한다. (어떤 경우에도 데이터가 달라져서는 안된다.)

이는 매 순간 Read / Write 에 따른 정합성이 일치할 필요가 있는 경우 적합한 형태이다.

- AP (Availability & Partition Tolerance) : 어떤 상황에서도 안정적으로 시스템은 운영된다. 또한 데이터와 상관없이 안정적인 응답을 받을 수 있다. 다만 데이터의 정합성에 대한 보장은 불가능하다. (특정 시점에 Write 동기화 여부에 따라 데이터가 달라질 수 있다.)

이는 결과적으로는 일관성이 보장된다는 Eventual Consistency 를 보장할 수 있는 시스템에 알맞는 형태이다.

서버시스템 및 분산시스템에 있어서 핵심적인 개념이므로 잘 정리해두고 아키텍처를 고려할 때 항상 생각해두자

Data Replication은 데이터를 물리적으로 다른 서버 공간에 복제하는 일이다. 

이를 잘 이용하면 부하 분산 및 고가용성, 버전 테스트 등 멋지게 사용할 수 있는 방안이 많아진다. 

일반적으로 하나의 Master와 여러 개의 Slave로 이루어진 구조에서 Read Only인 Slave 노드들에 Write 가능한 Master의 데이터가 업데이트되면 동기화시키는 방향으로 복제가 이루어진다.

Database Replication 은 기본적으로 비동기(Asynchronous)로 이루어진다.

Replication 은 대게 Writable 한 Master Node 에서 Readonly인 Slave로 이루어진다.

Replication 으로 인한 이점들에는 다음과 같은 것들이 있다.

- Scale out solution : Replication 을 통해 Read 요청에 대한 분산을 여러 Slave 로 나눔으로써 병목현상을 해결할 수 있다. 

- Data security : 데이터가 Slave로 복제됨에 따라서 마스터 서비스에 대한 영향 없이 데이터에 대한 백업이 가능하다.

- Analytics : 서비스에 영향을 미치지 않고 데이터 분석이 용이하다.

- Long-distance data distribution : Data를 여러 지리적 Location 혹은 Local에 Copy 를 만들 수 있다. 이는 자연적 재해나 지리적 장애에 대한 대응책이 될 수 있다.

MySQL 의 Replication은 로그 기반으로 비동기적으로 데이터를 복제한다. 

마스터에서는 데이터가 변경되면 Binary Log라는 곳에 이력을 기록하는데, 실행된 SQL을 그대로 기록하거나(Statement-Based), 변경된 행을 Base64로 인코딩하여 기록하거나(Row-Based), 적절히 혼합한형태(Mixed Type)로 동기화를 수행한다. 

(1) Master에서 데이터 변경이 일어나면 자신의 데이터베이스에 반영한다.

(2) Master에서 변경된 이력을 Binary Log에 기록한 뒤 관련 이벤트를 날린다.

(3) Slave IO_THREAD에서 Master 이벤트를 감지하고 Master Binary Log의 Relay Log에 기록한다.

(4) Slave SQL_THREAD는 Relay Log를 읽고 자신의 DB에 기록한다.

마스터에서는 여러 세션에서 데이터 변경처리가 가능하지만 Slave에서는 오직 SQL Thread에서만 데이터 변경처리가 이루어질 수 있기 때문에 Master의 데이터 변경 트래픽이 과도할 경우 동기화 시간 차이가 크게 날 수도 있다.

동일한 Database 소스를 여러 군데에 분산시키는 점은 개발자가 API 를 구현할 때에도 신경써주어야 하는 부분이다.

WAS 레벨에서 어떤 DB를 바라볼지에 대한 문제는 보통 Web Framework 레벨에서 지원해주는 경우가 많다. 가장 간단한 방법으로는 서로 다른 커넥션 풀을 만들어 쿼리를 날릴때마다 직접 분기해주는 방법이지만 이는 비효율적이며 비생산적이다.

먼저 Spring을 사용하면 @Transactional(readOnly=true) 라는 어노테이션에서 readOnly 옵션을 이용해서 트랜잭션 설정 하나로 서로 다른 데이터 소스로 연결시킬 수 있다. 

또한 Spring의 AbstractRoutingDataSource 클래스는 여러 개의 DataSource를 하나로 묶고 자동으로 분기처리해주는 Spring 기본클래스이다. 이를 이용해서 @Transactional 과 잘 연계하면 쉽게 분기처리가 가능하다.

참고로 Spring의 @Transactional 처리는 TransactionManager 선별 -> DataSource에서 Connection 획득 -> Transaction 동기화 순으로 일어나기 때문에 커넥션을 동기화 이후에 얻는 Lazy 한 방식을 사용해야 함을 명심한다.

본 포스팅에서 언급한 내용은 Master-Slave Replication 이지만, 경우에 따라 Master-Master Replication 을 구조로 구성하기도 한다.

Master-Master replication 구조를 고려할 때에는 Master 간 Conflict 및 데이터베이스에서의 ACID 성질의 유지가 힘들기 때문에 신경쓸 부분이 조금 더 많다. 

그렇기 때문에 Master-Master Replication 의 경우 Active Directory / LDAP 과 같은 Directory Service Server 나 Data 의 Conflict 우려가 적고 Accessibility 가 중요한 서비스의 경우 고려된다.

(참조 : https://stackoverflow.com/questions/3736969/master-master-vs-master-slave-database-architecture)

클라우드 환경이 도입되면서 Multi A-Z 에서의 Replication 전략도 눈여겨 봐야하는데, 보통 하나의 Master 를 한 Availability Zone 에 두고 Read-only Slave 들을 같은 Zone 및 다른 AZ 에 배치시켜두는 형태를 취한다. AWS 에서는 이를 Read-Replica 라는 서비스로 제공한다.