🏛️

대규모 데이터를 처리하기 위한 시스템을 설계할 때에 고려해야할 사항들이 존재한다. 효율적이고 경제적인 시스템을 구축하기 위해서 이러한 개념을 잘 알고 있어야 한다. 이러한 핵심 구성 요소는 아래와 같다

• CAP Theorem

• PACELC Theorem

• SQL vs NoSQL

• Load Balancing

• Caching

• Data Partitioning

• Redundancy & Replication

• Indexing

• Proxies

• Long Polling vs WebSocket vs Server-Sent Event

• Leader & Follower

• Quorum

• Heartbeat

• Bloom Filter

• Checksum

• Consistent Hashing

---

1. 분산 시스템의 필수 고려사항

분산 시스템의 필수 고려사항은 다음과 같다

• 확장성 Scalability

  • 증가하는 작업량을 지원하기 위해 지속적으로 확장 가능한 구조를 가져야 한다.
  • Storage, Computing, Network 리소스 등에 대해서 확장이 가능해야 한다.
  • 일반적으로 시스템의 성능은 확장함에 따라 증가하지만 관리/환경적인 비용으로 성능이 감소할 수 있다.(locality 감소, N/W 망 분리에 따른 성능 저하 등)
  • 확장 가능한 아키텍쳐는 각 작업들을 atomic 하게 나눌 수 있어야 하고, 모든 노드의 로드를 균등하게 조정해야 한다.
  • 일반적으로 분산 시스템의 확장성은 scale-up이 아닌 scale-out을 의미한다. (scale-up은 downtime을 보통 유발한다.)

• 신뢰성 Reliability

  • HW나 SW가 고장나는 빈도나 고장나는 기간을 나타내는 개념. 서비스가 올바른 결과를 제공할 수 있는 능력
  • 일부 작업이 실패하더라도 해당 작업은 결국 정상적으로 처리가 완료되어야 한다.
  • 예를들어 사용자가 장바구니에 항목을 추가한 경우 시스템은 해당 데이터가 영구적으로 저장될 것으로 생각한다. 이는 데이터 중복을 통해 달성할 수 있으며, 장바구니 정보를 가진 서버에 오류가 발생하면 복제본을 통해 이를 처리해야 한다.
  • 신뢰할 수 있는 시스템은 모든 SPoF를 제거하고 서비스에 대한 복원력resilience를 제공하기 위한 비용이 발생한다.

• 가용성 Availability

  • 사용자 입장에서 시스템을 어느정도 이용할 수 있을 지 나타내는 개념. 서비스를 제공할 수 있는 능력.
  • 신뢰성은 가용성보다 더 높은 범위로 모든 조건에서 정상적으로 처리될 수 있는 시간을 의미한다.
  • 시스템이 신뢰성이 있으면 가용하나, 가용성이 있다고 해서 신뢰성이 있는 것은 아니다. 신뢰성이 낮은 시스템이라고 하더라도 서비스 복구 시간을 최소화하고 대체 서비스를 제공함으로써 고가용성High Availability 를 보장할 수 있다.
  • 예를 들어 반대로, 출시 후 2년동안 가용성이 99.99% 인 온라인 마켓이 별도의 보안 테스트 없이 서비스 되고 있는 경우 이때 신뢰할 수 없지만 가용성은 높은 상태가 된다. 만약 3년차에 보안 사고가 발생하고 나면 이때는 가용성과 신뢰성 모두 떨어지게 된다.

• 효율성 Efficiency

  • 분산 시스템에서의 효율성 지표는 두 가지로 나타낼 수 있다.
    1. 응답시간response time (latency) - 결과를 얻기 위해 지연되는 시간
    2. 처리량throughput(bandwidth) - 단위 시간 당 처리할 수 있는 데이터 량
  • 두 측정 값은 다음의 단위비용에 상응된다.
    1. 전송되는 메세지 수 (메세지 크기와 무관)
    2. 전송된 메세지 크기 (메세지 수와 무관)
  • 일반적으로 메세지 수를 기준으로 분산 시스템을 분석하는 것은 지나치게 단순하여 많은 특성들을 놓치게 된다. (?)
  • 분산 시스템에서의 성능에 대한 예측은 매우 어렵지만 성능 기준이 되는 추정치는 정의할 수 있어야 한다.

• 관리성 Manageability

  • 시스템을 수리하거나 유지보수 할 수 있는 단순성과 속도를 의미
  • 모니터링을 통해 결함을 조기에 발견하거나, 자동화된 조치로 시스템 다운 타임을 줄이는 등의 능력을 말함.

---

2. CAP 이론

분산 시스템에서는 다양한 유형의 오류가 발생할 수 있다. 예를 들어 서버가 영구적으로 충돌하거나 오류가 발생하거나 디스크가 손상되어 데이터가 손실되거나 네트워크 연결이 끊어져 시스템 일부에 액세스 할 수 없게 될 수 있다. 다양한 리소스를 활용해서 최대한의 이점을 얻기 위해 어떻게 시스템을 디자인 해야 하는지 알아보자

CAP이론에서는 분산 시스템이 다음 세 가지 바람직한 속성을 모두 동시에 제공하는것은 불가능 한다고 한다. 모든 분산 시스템은 세가지 속성 중 두가지를 선택해야 한다.

• 일관성Consistency
  • 모든 노드가 동시에 동일한 데이터를 조회. 이는 데이터 사본을 가지는 것과 동일
• 가용성Availability
  • 시스템의 실패하지 않은 노드가 받은 요청은 응답을 받아야 한다. 심각한 장애가 발생하더라도 모든 요청은 정상적으로 종료되어야 한다.
• 파티션 허용Partition tolerance
  • 시스템의 부분적인 오류나 임의의 메세지 손실에도 정상적으로 동작해야 한다. 시스템 전체 네트워크 장애가 아닌 한, 모든 네트워크 장애를 견디고 데이터는 충분히 복제되어 시스템을 유지되어야 한다.

파티션 허용가 없는 경우 네트워크 장애에 대해서 일관성/가용성을 포기해야 하기 때문에 CA는 일관된 옵션이 될 수 없다. 따라서 실제 분산시스템에서는 CP 또는 AP를 선택해야 한다.

---

3.PACELC 이론

분산시스템은 partitioning을 피할 수 없음으로 CAP에 따라 일관성 또는 가용성을 선택해야 한다. ACID(Atomicity, Consistency, Isolation, Durability) 데이터베이스는 일관성을 선택한 반면 BASE (Basically Available, Soft-state, Eventually consistency) 데이터베이스는 가용성을 선택했다. BASE는 최신 데이터를 확인하지 않고 로컬 데이터로 응답을 제공한다. PACELC 이론은 파티셔닝을 하지 않았을 때의 선택 방법을 추가로 제시한다.

• P가 있는 분산 시스템은 A와 C간 균형을 맞출 수 있다.
• 그렇지 않으면(Else - E) 파티션이 없는 상태에서 시스템이 정상적으로 실행될 때 시스템은 대기시간(L)과 일관성(C)에 균형을 맞출 수 있다.
• 결국 PAC는 CAP와 동일하고 ELC는 P가 없는 경우에 대한 확장이된다.
• PACELC의 전체 논문에서는 복제를 통한 고가용성을 유지하게 된다. 따라서 실패가 발생하는 경우 발생하면 CAP정리가 우선되고, 실패가 없는 경우에는 일관성과 대기시간 간 tradeoff를 고려해야 한다.

이에 대한 예시는 아래와 같다

• Dynamo와 Cassandra는 PA / EL 시스템입니다. 파티션이 발생할 때 일관성보다 가용성을 선택합니다. 그렇지 않으면 낮은 지연 시간을 선택합니다.
• BigTable 및 HBase는 PC / EC 시스템입니다. 항상 일관성을 선택하여 가용성을 포기하고 지연 시간을 줄입니다.
• MongoDB는 PA / EC입니다. 네트워크 파티션의 경우 가용성을 선택하지만 그렇지 않으면 일관성을 보장합니다.

---

4. SQL vs NoSQL

현 시점에서 일반적으로 SQL이라고 이야기하는 데이터베이스는 관계형 데이터베이스 (RDB)를 의미하는 것이며, NoSQL은 이를 제외한 모든 데이터 베이스를 의미한다고 봐도 과언이 아니다. 위의 CAP에서 RDB에 해당 하는 것은 CA이며, NoSQL은 CP, AP를 의미한다.

4.1 SQL

• 관계형 데이터베이스는 행과 열에 데이터를 저장
• 각 행에는 하나의 항목에 대한 모든 정보가 포함되고 각 열에는 모든 개별 데이터 요소가 포함.
• ex) MySQL, Oracle, MS SQL Server, SQLite, Postgres, MariaDB

4.2 NoSQL

• NoSQL은 형태에 따라 일반적으로 아래와 같이 구분함.
  1. Key-Value : 데이터는 key-value 형태로 저장 (Redis, Voldemort, DynamoDB 등)
  2. Document : 데이터는 문서 형태로 저장되며, 문서는 collection 형태로 그룹화 된다. 각 문서는 정해진 구조가 없으며 서로 다른 구조를 가질 수 있다. (CouchDB, MongoDB 등)
  3. Wide-Column : 테이블 대신 column family를 가지고 행에 대한 정보를 저장한다. 모든 column을 미리 알 필요가 없으며 각 행에 동일한 수의 column이 있을 필요가 없다. (Cassandra, HBase 등)
  4. Graph : 데이터는 노드(entity), 속성(properties) 및 선(line)으로 구성되어 관계를 나타낸다. (Neo4J, InfiniteGraph 등)

4.3 SQL과 NoSQL의 차이점

1) 스키마

• SQL : 각 레코드는 고정 스키마를 따름. row 마다 고정된 column 값을 가져야함
• NoSQL : 스키마가 동적이며 쉽게 column 을 추가할 수 있음. row 마다 서로 다른 column을 가질 수 있음.

2) 쿼리

• SQL : 데이터를 정의하고 조작하는데 강력한 SQL을 사용
• NoSQL : 종류에 따라 제공하고 있는 기능이 전부 다름

3. 확장성

• SQL : 일반적으로 scale-up을 통해서 확장 가능. partitioning을 통해서 확장 가능
• NoSQL : scale-out이 가능함으로 서버를 추가해서 쉽게 부하분산을 할 수 있음

4. 신뢰성 / ACID

• SQL : 일반적으로 RDBMS 는 ACID를 보장함. 안정성과 트랜잭션 처리는 더 좋음
• NoSQL : 성능과 확장성을 위해서 ACID를 부분적으로 희생한다.

4.4 적절한 DBMS의 선택

세상에 모든 것을 고치는 만병통치약이 아직 개발되지 않았듯, 데이터를 저장하기 위한 기술도 모든 것을 만족시킬 수는 없다. 따라서 시스템의 요구사항을 확인하고 올바른 기술을 선택해야 한다.

관계형 데이터베이스를 선택해야 하는 경우

• ACID가 보장되어야 하는 경우.
• 데이터 구조가 한번 정의되면 변경되지 않은 경우.
• 대규모 데이터가 적재되지 않으며 일관된 데이터 량으로 작업되어야 하는 경우

NoSQL을 사용해야 하는 경우

• 빅데이터를 처리해야 하는 경우. 여기서의 빅데이터는 대용량의 데이터를 의미할 수도 매우 빠르게 들어오는 트랜잭션이 될 수도 있다.
• 매우 빠른 트랜잭션을 처리해야 하는 경우(MongoDB, CouchDB, Cassandra, HBase 등)
• 스키마가 없는 데이터를 대량으로 저장하는 경우.
• 클라우드 스토리지 및 컴퓨팅 리소스를 사용하여 데이터를 저장하는 경우. scale-out을 통해 확장할 수 있기 때문에 NoSQL을 사용.
• 빠르게 개발을 해야하는 경우

---

5. Load Balancing

로드 밸런서 (LB)는 서버 및 DB에 대한 응답성과 가용성을 향상시키기 위해 사용됨. 다양한 알고리즘을 사용하여 밸런싱 대상에게 효율적으로 트래픽을 분산해주며, 일반적으로 client와 server 사이에 놓여서 처리가 됨.

완전한 확장성과 중복성을 활용하기 위해 시스템의 각 계층에 LB를 둘 수 있음

• 사용자와 web-server 사이
• web-server와 application 서버 또는 cache 서버와 같은 내부 플랫폼 계층 사이
• 내부 플랫폼 계층과 DB 사이

LB를 사용하게 되면 가용성(일부가 장애가 발생하더라도 사용 가능한 서버로 연결), 응답성(여러 서버가 나눠서 요청을 받음), 처리량 증가(여러 서버의 컴퓨팅 리소스를 사용)하는 장점이 있음.

LB에서 제공되는 알고리즘

• Health check - LB는 각 서버의 상태를 확인하여 정상으로 수행되는 백엔드 서버로 트래픽을 전달함. 백엔드 서버의 상태를 모니터링 하기 위해 주기적으로 연결을 시도함. 상태 확인에 실패하면 서비스 대상에서 제거하고 상태 확인에 다시 응답 하기 전까지 트래픽이 전달되지 않음

• 최소연결법 Least Connection - 활성 연결이 가장 적은 서버로 트래픽을 전달. 이 방식은 서버간 고르지 않게 분산된 영구적인persistent client 연결이 많은 경우 유용함.

• 최소응답시간법 Least Response Time - 활성연결이 가장 적고 평균 응답이 가장 낮은 서버로 트래픽을 보냄

• 최소 대역폭 Least Bandwith - 초당 메가 비트로 측정된 최소 트래픽 양을 제공하는 서버를 선택

• 라운드 로빈 Round Robin - 서버 목록을 순환하고 각각의 새 요청을 다음 서버로 보냄. 목록 끝에 도달하면 처음부터 다시 시작.

• 가중 라운드 로빈 Weighted Round Robin - 각 서버의 사양이 다를 때 해당 사양에 맞춰 요청을 보내기 위해서 고안됨.

• IP hash - 클라이언트 IP주소의 해시 값을 구해 해시 테이블에 상응하는 서버로 연결해 줌.

LB 자체가 SPoF가 될 수 있음. 그렇기 때문에 LB를 클러스터로 구성할 수 있음. LB는 다른 LB의 상태를 모니터링하고 두 LB 모두 트래픽 및 장애 감지를 동등하게 제공해줄 수 있음으로 primary LB가 실패하면 secondary LB가 동작하게 됨

---

6. Caching

LB는 scale-out을 통한 확장에서 사용되면서 성능 개선에 도움을 주지만, 캐싱caching을 사용하면 이미 보유한 리소스를 훨씬 더 효율적으로 사용할 수 있으며 LB를 통해 제공될 수 없는 수준의 성능향상을 제공해 줄 수 있다.

캐시는 참조 원칙의 지역성을 활용하는데 최근 요청 된 데이터는 다시 요청 될 가능성은 특성을 이용하는 것이다. 일반적으로 파레토 법칙을 따라 약 20%의 데이터를 캐시함으로서 전체 80%의 트래픽에서 캐시 데이터를 활용할 수 있다. 캐시는 모든 컴퓨팅 계층에서 사용된다. (HW, 운영 체제, 웹 브라우저, 웹 애플리케이션 등)

캐시는 아키텍처의 모든 수준에 존재할 수 있지만 종종 프런트 엔드에 가장 가까운 수준에서 발견되며 다운 스트림 수준에 부담을주지 않고 데이터를 빠르게 반환하도록 구현된다.

App 서버 캐시

요청 계층 노드에 직접 캐시를 배치하면 요청 데이터에 대한 응답이 로컬 저장소를 참조하여 처리된다. 요청 계층 노드의 캐시는 메모리 (매우 빠름)와 노드의 로컬 디스크 (네트워크 스토리지로 이동하는 것보다 빠름) 모두에 위치할 수 있다.

• cache-hit : 서비스가 요청될 때마다 캐시를 확인하여 요청한 데이터가 캐시에 있는 경우 캐시의 데이터를 바로 반환
• cache-miss : 요청한 데이터가 캐시에 없으면 요청 노드가 디스크/외부 서비스에서 데이터를 가져옴

요청 레이어가 여러 노드로 확장 된 경우에도 각 노드가 자체 캐시를 가질 수 있다. 그러나 LB에 의해 요청이 무작위로 분산되면 동일한 요청이 다른 노드로 이동함으로 로컬 캐시의 효력이 약해진다 따라서 이를 위해서 아래와 같은 방법으로 처리한다.

• 전역 캐시global cache
• 분산 캐시distributed cache

CDN (Content Delivery Network)

CDN은 많은 양의 정적 미디어(image, videos, file 등) 를 제공하는 서비스에서 사용하는 캐시로, 일반적인 CDN 설정에서 요청은 먼저 CDN에 정적 미디어를 요청한다.

• cache-hit : CDN은 해당 콘텐츠를 로컬에서 사용할 수있는 경우 제공
• cache-miss : 사용할 수없는 경우 CDN은 백엔드 서버에 파일을 쿼리하고 로컬에 캐시 한 다음 요청하는 사용자에게 제공.

시스템이 자체 CDN을 가질만큼 충분히 크지 않은 경우 Nginx와 같은 경량 HTTP 서버를 사용하여 별도의 하위 도메인 (예 : static.yourservice.com)에서 정적 미디어를 제공하여 향후 CDN으로 쉽게 전환할 수 있따.

캐시 무효화 Cache Invalidation

캐싱을 성능을 향상시켜주지만 원본 데이터 (ex. DB에 저장되어 있는 데이터)와 일관성있게 유지하기 위해 유지관리가 필요하다. 데이터가 데이터베이스에서 수정되면 데이터 일관성이 깨져 App이 오작동할 수 있다. 이러한 문제를 해결하는 것을 캐시 무효화라고 한다.

주로 사용되는 세 가지 주요 체계가 있다.

• Write-through 캐시 : 데이터가 캐시와 와 DB(원본 데이터)간 에 동시에 기록됨. 완전한 데이터 일관성을 갖게되나 모든 쓰기작업을 캐시와 DB 두번 수행해야 함으로 write 작업에 대한 성능이 저하된다.
• Write-around 캐시 : write-through 캐시와 유사하지만 데이터는 캐시에 쓰이지 않고 DB(원본 데이터)에 직접 기록하고, 나중에 읽기 요청이 들어왔을 때 데이터가 캐시에 없다면 DB에서 데이터를 가져와 캐시에 기록하게 된다. 이는 최근에 쓴 데이터에 대한 읽기 요청이 “cache-miss"를 생성하고 read 작업에서 더 높은 지연이 발생하게 된다.
• Write-back 캐시 :데이터가 캐시에만 기록되고 클라이언트에 즉시 완료가 확인된다. DB(원본 데이터)에 대한 쓰기는 지정된 간격 후에 또는 특정 조건에서 수행된다. write-heavy인 서비스에서 짧은 지연 시간과 높은 처리량이 제공됩니다. 그러나 기록 된 데이터의 유일한 복사본이 캐시에 있기 때문에 충돌 또는 데이터 손실 위험이 있다.

캐시 제거 정책 Cache eviction policies

다음은 가장 일반적인 캐시 제거 정책이다.

• FIFO (First In First Out) : 캐시는 이전에 액세스 한 빈도 또는 횟수에 관계없이 먼저 액세스 한 첫 번째 블록을 제거
• LIFO (Last In First Out) : 캐시는 이전에 액세스 한 빈도 또는 횟수에 관계없이 가장 최근에 액세스 한 블록을 먼저 제거
• LRU(Least Recentlry Used) : 가장 적게 사용된 항목을 먼저 제거
• MRU(Most Recently Used) : LRU와 달리 가장 최근에 많이 사용한 항목을 먼저 제거
• LFU (Least Frequently Used) : 항목이 필요한 빈도를 계산합니다. 자주 사용되지 않는 항목이 먼저 제거
• RR(Random Replacement) : 후보 항목을 무작위로 선택하고 필요할 때 공간을 확보하기 위해 제거