[Cloud Native] 분산 시스템의 기초 개념들

 

비둘기 책을 읽고 정리한 글입니다

---

분산 시스템이란?

분산 시스템은 개별 컴퓨터들이 네트워크로 연결되어서 하나의 컴퓨터로 보이는 시스템이다.

---

분산 시스템의 8가지 일반화 오류

네트워크는 안정적이다

네트워크는 언제든지 불안정해질 수 있다.

서비스들은 서로 다른 장비에 존재하기 때문에 잠재적인 네트워크 장애에 대응할 수 있도록 어플리케이션을 설계해야 한다.

 

네트워크 지연이 없다

넓은 의미의 네트워크 지연은 데이터를 받을 때까지 걸리는 시간을 의미한다.

서로 다른 장비에 있는 서비스들 간의 통신은 네트워크 지연이 반드시 존재한다.

• 네트워크 호출, 네트워크 통신 횟수를 줄여야 한다.
• 클라이언트와 가까운곳에 데이터를 두도록 한다.
  이를 위해 캐싱, CDN, 멀티리전 배포 등을 활용할 수 있다.
• Pub/Sub 방법을 이용한다.

 

대역폭은 무한대다

대역폭은 주어진 시간 동안 얼마나 많은 데이터를 전송할 수 있는지를 의미한다.

도메인 주도 설계(Domain-Driven-Design, DDD)와

명령 쿼리 책임 분리(Command-Query-Responsibility-Segregation, CQRS)

같은 데이터 패턴은 대역폭이 커야 하는 환경에서 매우 유용하다.

 

네트워크는 안전하다

네트워크가 안전하다는 가정은 치명적이다.

개발자나 아키텍트 엔지니어는 애플리케이션을 설계할 때 보안에 항상 높은 우선순위를 둬야 한다.

심층 방어(defense-in-depth) 같은 방법을 고려할 수 있다.

 

 

토폴로지는 변하지 않는다

토폴로지는 컴퓨팅 장비(노드)들의 연결 정보를 의미한다.

클라우드 환경은 탄력적으로 설계해야 한다.

따라서 노드들은 리소스 소모량과 초당 요청 횟수 같은 기준에 따라 Scale-Out 하거나 Scale-In 할 수 있다.

토폴로지는 언제든 변할 수 있고, 이를 고려해야 한다.

 

관리자는 한 명이다

최신 클라우드 네이티브 애플리케이션은 여러 팀이 나눠서 개발한 많은 서비스로 구성되어 있다. (MSA)

따라서 한 명이 문제를 해결할 수 없을 뿐만 아니라 전체 애플리케이션을 이해하는 것도 현실적으로 불가능해졌다.

따라서 배포 관리, 디커플링, 로깅, 모니터링과 같은 개념을 잘 알아야 한다.

디커플링이란?
특정 서비스의 변화에 상관없이 다른 서비스를 수정할 수 있다.
서비스간의 의존도, 결합도를 낮추는 것을 의미한다.

 

전송 비용이 없다

전송은 네트워크 상에서 발생하고 대부분의 클라우드 제공 업체에서 네트워크 비용은 무료가 아니다.

페이로드를 오브젝트로 변환하는 비용은 무료가 아니다.

즉, 직렬화 역직렬화 과정은 상당히 비싼 연산으로 취급한다.

 

 

네트워크는 동등하다

네트워크들은 서로 다를 수 있다.

서로 다른 프로토콜을 사용할 수 있고 이를 고려해야 한다.

---

CAP 이론

아래 3가지 중 2가지만 만족한다는 이론이다.

 

C(Consistency) 일관성

모든 데이터를 요청할 때 응답으로 가장 최신의 변경된 데이터를 리턴 또는 실패를 리턴한다는 것이다.
즉, 모든 읽기에 대해서 DB노드가 항상 동일한 데이터를 가지고 있어야 한다는 의미이다.

RDBMS는 기본적으로 가지고 있는 기능이지만 NoSQL에서는 다음과 같은 2가지 방법을 사용해서 일관성을 보장한다.

1. 클라이언트에 응답하기 전에 모든 노드에 데이터를 저장하는 동기식 방법
   • 느리지만 강한 데이터의 정합성을 가짐
2. 먼저 클라이언트에게 응답한 다음 노드로 데이터를 동기화하는 비동기식 방법
   • 빠른 응답이 가능하지만 쓰기 노드에 장애 발생 시 데이터 손실이 생길 수 있다.

 

추가 예시
DB가 2개의 Instance를 유지하고 있다면 A에 요청하든 B에 요청하든 동일한 값이 반환됨을 의미한다.
풀어서 설명하자면, A를 update 하고 B에 동기화 되기전에 누군가 READ를 한다면 동기화 되지 않은 B 데이터를 반환하는 것이 아니라 동기화 이후에 READ하고 데이터를 반환해야 한다.

A(Availability) 고가용성

모든 요청에 대해서 정상적인 응답을 리턴할 수 있어야 한다. (고장나지 않는다)

가용성을 가질 경우 클러스터 내에서 몇 개의 노드가 망가지더라도 정상적인 서비스가 가능하다.

 

가용성을 위한 데이터 중복 저장 방법

1. 동일한 데이터를 가진 저장소를 하나 더 생성하는 마스터-슬레이브 복제 방법
2. 데이터 단위로 중복 저장하는 피어-투-피어 복제 방법

 

P(Partition Tolerance) 분할 내구성

DB 노드들은 서로 완전히 분할되어 있어서 노드간의 통신 장애가 발생하더라도 사용자의 요청에 응답하는데 지장이 없어야 한다.

 

CAP 이론 그래프

 

CAP 이론은 약간의 문제가 있어보인다.

얼핏 보기에 DB는 CA, AP, CP 중 하나만 선택가능한 것으로 보이기 때문이다.

하지만 좀 더 유연하게 생각해야 한다.

우선 CAP 이론은 분산 데이터 저장소에 적용할 수 있으며 주로 네트워크 파티션(P)이 발생할 때 적용된다. 

네트워크 파티션(P)이 발생하면 분산 데이터 저장소는 일관성(C) 또는 가용성(A) 중에서 선택해야 한다.

즉, P가 발생하면 AP또는 CP가 되는 것이다.

 

RDBMS

기본적으로 RDBMS는 CA에 속한다.

MySQL은 Master 노드가 존재하고 이를 복제하여 사용하는 Slave를 구성하는 패러다임을 가지기 때문이다.

이 경우에 Master 노드에 장애가 발생하면 P를 보장할 수 없기 때문이다.

그리고 SQL 기반 시스템은 ACID 원리를 지키기 위해 일관성을 최적화하게 된다.

MySQL은 cluster 설정이 따로 존재하고 cluster로 설정하면 CP또는 AP로 구성될 수 있다.

 

Redis

위 표를 보면 Redis가 CP에 속한다고 되어있다.

하지만 Redis 클러스터를 구성하는 방법에 따라서 AP를 보장하게 할 수 있다.

 

보통의 Redis는 여러 노드에 Master-Slave Replication을 구성해서 사용한다.

이때 Master 노드가 고장나면 클라이언트는 Slave 노드와 연결되어 READ만 가능하고 WRITE가 불가능해지는 상황이 된다.

 

.. 그럼 고가용성을 해결하기 위해서?

Master 노드를 되살리거나, Slave노드를 Master 노드로 승격시킨다면 고가용성을 보장할 수 있다.

 

그런데 장애가 날 때마다 개발자들이 수동으로 이런 작업을 한다면 매우 힘들고 비효율적일 것이다.

 

실제로 Redis는 AP로 활용하기 위해 Slave 노드를 Master 노드로 승격시키는 방법을 사용하는데,

이 작업의 자동화를 위해 Redis Sentinel 이라는 기능을 사용할 수 있다.

 

Redis Sentinel 사용방법

Redis 고가용성으로 사용하기 with Sentinel

---