Chapter 1

[Enoch-Kim]

스터디 방식

1. 준비 안해올 시 벌칙 2만원
2. 각자 챕터 읽고 + 참고문헌 골라서 읽기 -> 단, 참고 문헌 5개 이하 시, 이전 참고문헌 발표
3. Git issue에 Comment 남겨서 발표 주제 선점 -> 추후 발표자료는 해당 Comment 수정하여 넣기

[Enoch-Kim]

What it takes to run Stack Overflow

https://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow/

필자는 스택오버플로는 효율적으로 운영하고 있지만 대규모 시스템은 아니라고 생각한다.

2013.11.12 날짜 기준 다음과 같은 network 요청이 있었다. (매우 옛날 글인 것 같음..)

• 148,084,883 HTTP requests to our load balancer
• 36,095,312 of those were page loads
• 833,992,982,627 bytes (776 GB) of HTTP traffic sent
• 286,574,644,032 bytes (267 GB) total received
• 1,125,992,557,312 bytes (1,048 GB) total sent
• 334,572,103 SQL Queries (from HTTP requests alone)
• 412,865,051 Redis hits
• 3,603,418 Tag Engine requests
• 558,224,585 ms (155 hours) spent running SQL queries
• 99,346,916 ms (27 hours) spent on redis hits
• 132,384,059 ms (36 hours) spent on Tag Engine requests
• 2,728,177,045 ms (757 hours) spent processing in ASP.Net

실제로 스택오버플로 회사에서 사용하고 있는 서버는 다음과 같습니다.

• 4 MS SQL Servers
• 11 IIS Web Servers
• 2 Redis Servers
• 3 Tag Engine servers (anything searching by tag hits this, e.g. /questions/tagged/c++)
• 3 elasticsearch servers
• 2 Load balancers (HAProxy)
• 2 Networks (each a Nexus 5596 + Fabric Extenders)
• 2 Cisco 5525-X ASAs (think Firewall)
• 2 Cisco 3945 Routers

이들 모두가 운영 서버로 사용되고 있는것이 아님..

필자가 주장하는 스택오버플로우를 사용하기 위한 최저 조건

• 2 SQL servers (SO is on one, everything else on another…they could run on a single machine still having headroom though)
• 2 Web Servers (maybe 3, but I have faith in just 2)
• 1 Redis Server
• 1 Tag Engine server
• 1 elasticsearch server
• 1 Load balancer
• 1 Network
• 1 ASA
• 1 Router

스토리지의 경우 2단계의 캐시를 잘 활용하기 때문에 실제 스토리지의 R/W 비율은 40:60임 -> 이를 위해 쓰기에 유리한 SSD 사용하여 스토리지 구성 그리고 고가용성 공유 스토리지를 사용하여 VM 서버를 지원함. 이때, 호스팅에 지원하지 않아 백그라운드 프로세서가 죽어도 실제 사이트에 직접 지장이 가진 않음

클라우드가 아닌 물리장비의 매우매우매우 큰 수직 스케일링만으로 스택오버플로우가 버틸 수 있음. 그런데 실제로 높은 스펙의 장비들의 사용률은 15% 정도밖에 안함. 이를 가능하게 한 것은 스택오버플로우 개발자들이 렌더링 최적화를 진짜 잘했기 때문. 실제 모니터링도 하고 비쥬얼라이징도 하여 속도를 개선해나감

-> 결국 자기네 자랑.. 그래서 어떻게 한건데.. -> 이거 보면 나올 것 같은데.. 나중에.. https://nickcraver.com/blog/2016/02/03/stack-overflow-a-technical-deconstruction/

[matteblack9]

Scaling Memcache at Facebook

페이스북과 같은 SNS 시스템은 다음과 같은 상황에 놓여져있다.

• 페이스북의 경우 SNS 특성상, 사용자는 자신이 '창작'하는 것에 비해, 훨씬 많은 콘첸츠를 '소비' 한다.
• 수 억명의 사용자가 동시 다발적으로 request를 한다.

그래서 페이스북과 같은 소셜 네트워크 인프라는 수억명의 사용자에 대응하기 위해 다음과 같은 4가지 기능을 제공할 필요가 있다.

• 리얼타임에 가까운 상호작용
• 여러개의 소스로 부터 즉시 관련 콘텐츠를 모으는 것
• 초마다 백만개 이상의 요청을 처리하기 위한 확장성
• 엄청나게 인기많은 하나의 콘텐츠에 대해 접근/수정이 용이해야 한다는 것

그러면 페이스북(현 메타)이 어떻게 시스템을 최적화 했는지 알아보자.

Caching을 위한 memcached 도입

가장 간단하게 페이스북은 여러개의 데이터 소스(HDFS, MySQL, backend Service....)로부터 데이터들을 read operation 시fetch 하는데, 여러개의 소스로부터 데이터 취합 + 빠른 응답을 위해 (webserver, database) 로 이루어진 시스템에서 (webserver, database, cache) 와 같이, 캐시 부분을 추가 했다.

그러나 memcached와 같은 캐시를 도입하여도 새로운 여러 문제가 발생한다.

Reducing Latency

caching을 위해 사용한 memcache의 지연성은 사용자의 request 시간을 잴 때 중요한 요소 중 하나이다. 페이스북에서 인기 있는 페이지 하나를 로딩할 때 평균적으로 521개의 value들을 memcached로 부터 각각 가져온다. 그래서 memcached 병목이 일어나면 사용자의 request가 느려질 수 밖에 없다.

Parallel requests and batching

각각의 value들을 memcached들로부터 가져오는 것이 아니라, 서로 의존성을 가지는 데이터들의 DAG를 구성하여, 한꺼번에 여러개의 데이터를 가져오도록 하였다. 평균적으로, 요청당 24개의 키를 쿼리하게 되었다.

Client-server Communication

Client는 UDP와 TCP를 memecached 서버들과 통신할 때 사용하는 데, get 요청을 latency와 오버헤드를 줄이기 위하여, UDP 방식으로 사용 하였다.

Client들은 UDP를 사용함으로써 나타나는 에러들을 단순히 cache miss로 처리할 것이기 때문에, 서비스에도 이상이 없다. 표에서 볼 수 있듯이, UDP는 20%의 요청에 대한 지연 감소 효과가 있었다.

get외의 요청들은 여전히 TCP를 사용하는데, get 외의 요청들은 get 보다 빈번하지 않기 때문에 상관없으나, 사용자가 많아지면 Incast Congestion이 발생할 수도 있다. 그래서 슬라이딩 윈도우 방식을 통해 적절한 윈도우의 크기를 찾아서 잘 해결했다.

Reducing Load

Lease

동시 쓰기 문제에서 발생하는 지연의경우 CPU 시스템이 사용하고 있는 방식인 Store Contional와 비슷 한 방식을 차용함으로써 해결했다. 하나의 요청이 토큰(세마포)을 얻으면 memcache에 수정 권한이 생기는 데, 이 때 다른 요청이 세마포를 얻고 같은 키에 접근하는 경우에 그냥 실패처리 시킨다. (페이스북 / 인스타 그램에서 에러 자주 뜨는 이유인가..)

memcache pools

memcached들을 서로 다른 성격들의 pool로 나누는 것이다(데이터 저장소가 Region/Group으로 나누는 것처럼) SNS 시스템은 이를 Daily / Weekly / Seconds처럼 시간 단위로 성격을 나누어서 pool을 형성한다고 한다.

스터디 시간이 길어질 것을 배려해 여기까지 정리한다 (뒤에 나오는 장애 복구는 chapter 1에 해당 안한다고 판단)

[hyeriful]

Caching Strategies and How to Choose the Right One

https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

상황에 맞게 올바른 캐싱 전략을 선택해야 한다. 상황 예시.

• is the system write heavy and reads less frequently? (e.g. time based logs)
• is data written once and read multiple times? (e.g. User Profile)
• is data returned always unique? (e.g. search queries)

대표적으로 사용되는 것: Memcached, Redis

• 장점
  • work best for read-heavy workloads
  • are resilient to cache failures. If the cache cluster goes down, the system can still operate by going directly to the database
  • 캐시와 DB의 데이터모델이 다를 수 있다. 예) 다수의 쿼리 결과로부터 생성된 응답이 어떤request id에 대응되어 저장될 수 있다.
• 단점
  • 데이터를 쓸 때는 DB에 직접 쓰기때문에, 캐시와 db가 불일치하는 문제가 발생할 수 있다. 하지만 이 문제를 다루기 위해 TTL사용 or 적절한 쓰기 전략 선택

• cache-aside와 read-through 는 매우 비슷. 하지만 두가지 차이점 존재

  1. In cache-aside, the application is responsible for fetching data from the database and populating the cache. In read-through, this logic is usually supported by the library or stand-alone cache provider.
  2. Unlike cache-aside, the data model in read-through cache cannot be different than that of the database.

• 장점

  • work best for read-heavy workloads when the same data is requested many times. 예) 뉴스

• 단점

  • 데이터 처음 요청시 항상 cache miss 발생한다. (warming or pre-heating the cache 함으로써...)
  • 캐시와 db가 불일치하는 문제가 발생할 수 있다.

이거 자체는 별로인데, read-through cache랑 같이 사용하면, read-through 에 있었던 데이터 불일치 문제 해결 가능(DB에 대한 모든 쓰기가 캐시를 통과한다고 가정했을 때)

DynamoDB Accelerator (DAX) is a good example of read-through / write-through cache.

Write-Around

DB에 데이터를 직접 쓰고, 읽은 데이터만 캐시에 쓰는 방식.

Write-Around + Read-Through : 데이터를 한번 쓰고, 가끔 읽거나 읽지 않을 때 good performance. 예) real-time logs or chatroom messages

캐시에 기록을 해뒀다가 나중에 캐시가 DB에 데이터를 쓰는 방식

• Write-Through 와 Write-Back의 차이점
  • Write-Through는 캐시에 쓰인 데이터가 DB에 synchronously 업데이트 되고, Write-Back은 asynchronously 업데이트 된다.

대부분의 RDB storage engines (i.e. InnoDB)은 write-back cache를 디폴트로 한다. query를 메모리에 쓰고 이후 디스크에 flush 하는 식으로.

[jiyoungjha]

NDB Cluster Replication: Bidirectional and Circular Replication

https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-replication-multi-source.html

Circular replication example

NDB 클러스터를 활용한 MySQL에서의 circular replication 예제를 소개

아래의 조건을 충족할 때

• 모든 source와 replica의 SQL 노드는 같음
• 모든 source와 replica를 사용하는 SQL 노드가 -log-slave-updates 를 활성화하여 시작

-log-slave-updates 옵션에 대해

예를 들어 아래와 같이 chain replication server를 운용하고 싶을 때 사용할 수 있음

A -> B -> C

A가 replica B의 source이고, B가 replica C의 source인 경우 → B는 source 이면서 동시에 replica가 됨

• A와 B를 --log-bin을 사용해서 binary logging이 가능하게 시작해야 함
• B를 log_slave_updates 를 통해 A에서 받은 업데이트가 binary log에 로깅되도록 해야 함

시나리오 1. NDB Cluster Circular Replication with All Sources As Replicas

클러스터 1의 노드 A가 클러스터 2의 노드 D에 복제, 노드 D는 클러스터 3의 노드 E에 복제, 노드 E는 다시 노드 A에 복제하는 시나리오. 즉, 복제 라인이 직접 모든 replication source와 replica들을 연결

시나리오 2. NDB Cluster Circular Replication Where Not All Sources Are Replicas

앞서 시나리오 1과는 다르게 모든 source SQL 노드가 replica가 아닌 방식으로 circular replication을 짤 수도 있음 이 경우에는 클러스터의 서로 다른 노드가 replication source 및 replica로 사용됨 (복제라인이 불연속적이고, 완전히 테스트되지 않아 실험적.. 이라고 함)

Multi-source failover example

서버 ID가 1,2,3 인 3개의 클러스터를 사용하는 경우, multi-source failure 예시 클러스터 1이 클러스터 2와 3에 복제되고, 클러스터 2가 클러스터 3에 복제된다고 했을 때

즉, (1) 데이터가 클러스터 1에서 클러스터 3으로 직접 복제 되거나, (2) 클러스터 2를 통해 복제 되는 두 경로가 존재

아래와 같이 모든 SQL 서버가 source 및 replica 역할을 하지 않고 서로 다른 복제 채널에 서로 다른 SQL 노드를 사용할 수 있음 마찬가지로, replica 역할을 하는 서버는 -log-slave-updates 을 활성화한 상태로 실행해야 함

복제 클러스터 중 하나가 중단되면 → failover가 발생 해당 예시에서는 클러스터 1이 서비스에서 손실되어 → 클러스터 3이 클러스터 1의 업데이트 소스를 손실하는 시나리오

이 경우, 클러스터 3이 클러스터 1의 업데이트와 관련해서 클러스터 2를 따라잡도록 하여 문제를 해결할 수 있음 (SQL 서버 C에서 서버 F로 업데이트를 복제해야 함)

[gimmizz]

Multi-master replication

https://en.wikipedia.org/wiki/Multi-master_replication

• Replication Types
  • Single Master Replication
  • 데이터에 대한 변경은 오직 한 노드 (=master) 에서만 가능
  • 이러한 변경은 다른 노드들에 복제된다.
  • conflict 발생 가능성이 없고, 구성 및 관리가 덜 복잡함
  • master-replica replication 이라고 불리기도 하는듯?
  • Multi-Master Replication
  • 말그대로 master node 가 여러대!
  • 데이터에 대한 변경도 여러대에서 가능하다
  • 시스템 단에서 동시 변경 간에 발생하는 충돌들을 해결해야만 한다.
• How to replication
  • Synchronous replication
  • : data is written to master and slave simultaneously
  • overhead 가 존재
  • Asynchronous replication
  • : data is written to the master first and later replicated to the slave.
  • master 에 write 완료된 이후에 다른 노드들로 복제되기 때문에, 시간차가 존재
  • 

Multi-Master Replication

• 장점? 왜 사용할까?

  • Sharing Load : handle more write traffic than a single node
  • Maintaining a second copy
  • No SPoF Master
  • Lower latencies across geographies
    • client 는 여러개 master node 중 하나를 pick 하게될텐데, 지리적으로 가장 가까운 master 에요청하게 되면 latency 를 줄일 수 있다.
    • typically depends on the client to pick a Master node, or an abstracted proxy may choose one
  • Upgrading the database to a newer version

• 단점은 없을까? 주의해야할 부분은?

  • Eventual Consistency : master 간의 복제가 Asynchronous 라면 복제에 시간이 걸릴 것!
  • ACID 보장을 잃음
  • Sluggish Performance : 데이터 복제 시..
  • Conflict Resolution
  • 해결하는 방법은 굉장히 다양함. application 에 따라 다른 방법을 채택
    • discarding the entire sequence of writes
    • the last write wins

• multi-master replication 의 예제: Galera Cluster

  • Galera Cluster is a synchronous cluster of databases with several master nodes based on synchronous replication.
  • MariaDB의 공식적인 클러스터
  • 특징
  • Multi Master: 모든 노드에서 읽기 쓰기가 가능합니다.
  • 동기적 복제: 슬레이브 지연이 없고 노드 충돌 시에 데이터 손실이 없습니다.
  • 일관적인 데이터: 모든 노드는 같은 상태를 유지합니다.

cf) MSR (Multi Source Replication) : 여러개의 마스터 서버 발생하는 데이터를 하나의 슬레이브 서버에서 받아내는 방식

참고: https://arpitbhayani.me/blogs/multi-master-replication/