1장 사용자수에 따른 규모 확장성

 

DNS(도메인, 서드파티)를 통해서 도메인으로 로그인하면 DNS 연결된 IP를 반환해준다. 

웹서버에 IP를 보내면, 웹서버는 해당하는 HTML 페이지나, JSON 형식 파일을 반환한다. 

 

 

데이터 베이스

 

사용자가 늘면, 서버 하나로는 충분하지 않아서 여러 서버를 둔다.

하나는 웹/모바일 '트래픽 처리' 용도, 다른 하나는 '데이터 베이스' 용도이다. 

웹계층과 데이터 계층을 분리하면, 그 두개의 가지를 각각 마다 확장해 나갈 수 있다. 

 

RDBMS(Relaitonal Data Base Management System), 관계형 데이터 베이스

오라클, MySQL, PostgreSQL

 

NoSQL, 비 관계형 데이터베이스

Cassandra, HBase, Amazon DynamoDB, CouchDB, Neo4j

 

 

 

 

사설 IP는 인터넷을 통해서는 접속이 안된다. 

웹사이트로 유입되는 트래픽이 가파르게 증가하면, 로드밸런스로 우아하게 대처가능하다. 웹서버 계층에 더 많은 서버를 추가 하기만 하면되고, 로드 밸런스가 자동적으로, 트래픽을 분산한다. 

 

 

데이터베이스의 다중화

많은 데이터 베이스 관리 시스템이 다중화를 지원한다. 보통 서버 사이에 주(master)-부(slave)를 설정하고, 원본은 주에, 사본은 부에 저장하는 방식이다. 

쓰는 방식은 마스터만 지원한다. 부는, 읽기만 지원한다. INSERT, DELETE, UPDATE 등은 주 데이터 베이스로만 전달돼야 한다. 

데이터 베이스를 다중화 하면 여러 이점이 있다.

보통 쓰기 연산보다, 읽기 연산이 훨씬 많기 때문에 연산이 병렬로 분산 처리되며 성능이좋아진다. 

안정성이 증가한다. 서버가 일부 파괴되어도, 데이터가 보존된다. 

가용성(availability) : 여러개를 복제해두었음으로, 일부에서 장애가 발생해도 다른 곳에서 가져와서 계속 이용가능하다. 

 

 

 

캐시 

캐시는 자주 참조 되거나 값비싼 연산 결과 데이터를 메모리 안에 두고, 뒤 요청이 더 빨리 처리될 수 있게 하는 저장이다. 

app의 성능은 db를 얼마나 자주 호출하느냐에 크게 좌우되기 때문에, 캐시는 그런문제를 완화한다. 

 

캐시 계층

캐시 계층(cashe tier)는 잠시 보관하는 장소로 db보다 훨씬<<< 빠르다. 

별도 캐시 계층을 두면서, db 부하를 줄이고, 캐시계층의 규모를 독립적으로 확장하는 것도 가능하다. 

 

읽기 주도형 캐시 전략(read-through caching strategy) 

웹서버는 요청을 받으면, 캐시에 있으면 해당db를 반환한다. 

캐시에 없으면 db질의를 통해서 데이터를 찾아서, 캐시에 저장해놓고, 클라이언트에 반환한다. 

캐시 서버들은 일반적인 프로그래밍 언어로 api를 제공하기 때문에 이용은 간단하다. (ex. memcached API) 

코드 줄별 쉬운 설명

• SECONDS = 1 시간을 계산하기 편하도록 1초(Second)를 의미하는 변수를 만들어 둔 것입니다.
• cache.set('myKey', 'hi there', 3600 * SECONDS) 데이터를 임시 보관함(캐시)에 저장(set)하는 명령어입니다.
  • 'myKey': 데이터를 찾을 때 쓸 이름표(Key)입니다.
  • 'hi there': 실제로 보관할 내용(데이터)입니다.
  • 3600 * SECONDS: 이 데이터를 보관할 시간입니다. 3,600초, 즉 1시간 동안만 보관하고 그 이후에는 자동으로 삭제해 달라는 뜻입니다.
• cache.get('myKey') 보관함에서 데이터를 다시 꺼내오는(get) 명령어입니다. 'myKey'라는 이름표가 붙은 데이터를 찾아달라고 요청하는 것이며, 만약 1시간이 지나지 않았다면 처음에 넣었던 'hi there'라는 문구를 결과로 돌려받게 됩니다

 

 

캐시 사용의 유의 점 

1. 데이터 갱신은 별로 없는데 참조는 자주하는 데이터를 캐시에 넣으면 유용하다. 

2. 영속성 데이터를 두는건 바람직 하지 않다. 캐시 서버는 재시작 되면 모든 데이터가 사라진다. 

3. 언제 만료(Expire)하는가? 정책을 마련하는건 좋다. 없으면, 계속해서 캐시에 남기 때문이다. 

4. 일관성(Consistency)는 어떻게 유지하는가? db원본과 캐시내 사본이 같은지이다. 

- 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지 않으면, 일관성은 깨질 수 있다. 

여러 지역에 시스템을 확장해나가면, 캐시~저장소사이 일관성 유지는 어려운 문제가 될수 있다. 

페북논문 <Scaling Memcahe at Facebook> 참조 

5. 장애 처리 : 캐시 서버가 한 대만 있으면 단일 장애 지점(Single Point of Failure, SPOF)가 될 수 있다. 

단일 장애 지점(SPOF)의 정의는 다음과 같다. 특정 지점에서의 장애가 전체 시스템 동작을 중단 시켜버릴 수 있으면, 그 지점을 단일 장애 지점이라고 부른다. 

SPOF를 피하려면, 여러 지역에 걸쳐 캐시 서버를 분산 시켜야 한다. 

6. 캐시 메모리의 용량 크기 : 너무 작으면, 너무 밀려나버리면서 성능이 떨어진다. 캐시 메모리를 과할당(Overprovision)하면, 보관될 데이터가 갑자기 늘어날때 생기는 문제도 방지할 수 있다. 

7. 데이터 방출(Eviction) 캐시가 꽉 차버리면, 추가 넣어야할때 기존 데이터를 내보내야한다. 이게 방출 정책이다

마지막으로 사용지점이 가장 오래된 데이터를 보내는정책 LRU(Least Recently Used) 를 내보내는것. 

FIFO(First In First Out) 경우에 맞게 적용을 한다. 

 

콘텐츠 전송 네트워크(CDN)

CDN은 정적 콘텐츠를 전송할 때 쓰는, 지리적으로 분산된 서버의 네트워크다. 이미지, 비디오, CSS, JS 파일 등을 캐시할 수 있다. 

동적 콘텐츠 캐싱은 새로운 개념으로,  요청 경로(Request path), 질의 문자열(Query String), 쿠키(Cookie) 요청 헤더(Request header) 등의 정보 기반으로 HTML 페이지를 캐시하는 것이다. [9]

 

CDN을 사용해서 정적 콘텐츠를 캐시하는 방법만 일단 집중해서 이해를 진행한다. 

사용자가 웹사이트를 방문하면, 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달한다. CDN서버가 사용자로부터 멀수록 웹사이트는 천천히 로드되기 때문이다. CDN 서버가 SF에 있으면, LA 사용자는 유럽 사용자보다 빠른 웹사이트를 본다. 

1-9는 어떻게 CDN 이 사이트 로딩 시간을 줄였는지 보여준다. 

 

 

 

1. 사용자 a가 이미지 URL로 image.png에 접근한다. url은 CDN사업자가 제공한 것이다. 

ex) cloudfront, akamai CDN 의 URL 예제 

- https://mysite.cloudfront.net/logo.jpg 

 

2. CDN 서버 캐시에 그 이미지가 없으면 원본 서버 요청해서 가져온다.

원본 서버는 웹 서버일 수도 있고 AWS같은 S3 온라인 저장소 일 수 있다. 

3. 원본 서버가 CDN에 반환한다. 응답의 HTTP헤더에는 해당 파일이 얼마나 오래 캐시될 수 있는지 TTL(Time-To-Live)값이 있다.

4. CDN 서버는 파일을 캐시하고 사용자 A에게 반환한다. 이미지는 TTL 명시된 시간이 끝날때까지 캐시된다.

5. 사용자B도 같은 이미지 요청을 CDN에 전송한다.

6. 만료되지 않은 이미지 요청은 캐시를 통해 처리된다. 

 

 

1. 정적 콘텐츠(JS, CSS, 이미지 등) 는 더 이상 웹 서버를 통해 서비스하지 않으며, CDN을 통해 더 나은 성능을 보장한다. 

2. 캐시가 데이터베이스 부하를 줄여준다. 

 

무상태(Stateless) 웹 계층

웹 계층을 수평적으로 확장하는 방법이다. 상태 정보(사용자 세션 데이터와 동일)를 웹 계층에서 제거해야 한다. 바람직한 전략은 상태정보를 관계형 데이터 베이스나 NoSQL같은 지속성 저장소에 보관하고, 필요할 때 가져오는 것이다. 

이렇게 구성된 웹 계층이 무상태 웹 계층이다.

 

상태 정보 의존적인 아키텍처

상태 정보를 보관하는 서버는, 클라이언트의 상태를 유지해서 요청들 사이에 공유되게 한다. 무상태 서버에는 이런 장치가 없다. 

 

같은 클라이언트의 요청은 항상 같은 서버로 전송 되어야 한다는게, 상태 정보를 보관하는 서버이다. 

로드밸런서가 이를 위해서, 고정 세션(Sticky sesion) 기능을 제공하는데[10], 이는 로드밸런서에 부하가 가해진다. 

또한, 로드밸러넛 뒷단에 서버를 추가하거나, 제거하기도 어려워진다. 

 

무상태 아키텍처

이 구조에서 사용자의 HTTP요청은 어떤 웹서버로도 전달이 가능하다. 웹 서버는 상태 정보가 필요하면, 공유 저장소(Shared storage)로 부터 db를 가져온다. 

이 구조는, 단순하고 안정적이고, 규모 확장이 쉽다. 

 

 

세션 데이터를 웹 계층에서 분리하고 지속성 데이터 보관소에저장하도록 만든다. 

공유 저장소는 RDBMS일수도, Memcahed/Redis 캐시 시스템 일수도, NoSQL일 수도 있다. 

여기선 NoSQL인데, 규모 확장이 간편해서다. 1의 규모 확장(Autoscaling)은 트래픽 양에 따라서 웹 서버를 자동 추가하거나 삭제하는 기능이다. 상태 정보가 웹 서버로부터 제거되면, 트래픽 양에 따라 웹서버를 넣거나 빼기만하면 자동 규모 확장이 된다. 

 

웹사이트가 매우 빨리 성장해서 전세계 사용자가 쓰면 가용성을 높이고, 전세계 어디서든  쾌적하도록 여러 데이터 센터를 지원하는게 필수적이다. 

 

데이터 센터

두 개의 데이터 센터를 이용하는 사례다. 장애가 없으면, 가까운 데이터 센터로 사용자는 안내된다(geo-routing). 

geoDNS는 사용자 x% 는 US, (100-x)%는 US-West 센터로 안내된다고 가정한다. 

 

다중 데이터 센터 아키텍처

센터중 하나가 심각한 장애가 발생되면 모든 트래픽은 장애가 없는 데이터 센터로 전송된다. 

 

1. 트래픽 우회 : 올바른 센터로 트래픽을 보내는 효과적인 전략을 찾는다. GeoDNS는 User에 가장 가까운 센터로 트래픽을 보낼 수 있게 한다. 

2. 데이터 동기화 : 센터마다 별도 db를 사용 중이면, 장애가 복구되어 트래픽이 없을때 다른 db로 우회 한다 해도, 해당 센터에 필요한 db가 없을 수 있다. 이를 해결하는 전략이, 여러 센터에 걸쳐 다중화 하는 것이다. 넷플릭스[11]

3. 테스트와 배포 : 웹/app 을  여러 위치에서 테스트 해보는 것도 중요하다. 자동화된 배포 도구는모든 데이터 센터에 동일한 서비스가 설치되도록 하는데 중요한 역할을 한다. 

 

시스템이 더 큰 규모로 확장되려면, 컴포넌트를 분리해서, 독립적 확장이 가능한 상태로 만드는 것이다. 

메시지 큐(message queue)는 실제 많은 분산 시스템이 이 문제를 해결하기 위해서, 채용하는 핵심 전략 중 하나다. 

 

메세지 큐

메세지 큐(무손실, durability)를 보장한다. 비동기 통신을 지원하는 구성이다. 아키텍처는 간단하다.

생산자/발행자(pd/publisher) 입력서비스가 메세지를 만들어서 큐에 발행한다. 큐에는 보통 구독/소비자(consumer/subscriber)라 불리는 서버가 연결되면서, 메세지를 받아서 그에 맞는 동작을 수행한다. 

이는 규모 확장성이 보장되어야하고, 안정적인 app을 구성하기에 좋다. 

생산자는 소비자 프로세스가 다운되어도 메세지를 발행 할 수있고, 소비자는 생산자가 가용상태가 아니여도 메세지를 수신할 수 있다. 이미지의 크로핑, 샤프닝, 블러링 등을 지원하는 사진 보정 app을 만든다고 예를 들자. 

보정은 오래 걸릴 수 있는 프로세스이므로, 비동기적을 처리하면 편하다. 

 

사진 보정 작업(job)을 메세지 큐에 넣는다. 작업프로세스들(worker)은 이 작업을 메세지 큐에서 꺼내서 비동기적으로 완료한다. 

생산자, 소비자 서비스의 규모는 각기 독립적으로 확장 될 수 있다. 

큐의 크기가 더 커지면 더 많은 작업 프로세스를 추가해야 처리 시간을 줄일 수 있다. 하지만 큐가 거의 항상 비어있는 상태라면 ,작업 프로세스 수는 줄일 수 있을 것이다. 

 

로그, 메트릭 그리고 자동화

 

사업규모가 커지고나면, 필수적으로 로그(log), 메트릭(metric), 자동화(automation) 같은걸 필수적 으로 투자해야한다.

1. 로그 : 에러 로그를 모니터링 한다. 시스템 오류와 문제를 쉽게 찾아내게 하기 때문이다. 서버 단위로 모니터링 할 수도 있지만, 로그를 단일 서비스로 모아주는 도구를 활용하면 더 편리하게 검색하고 조회할 수 있다.

2. 메트릭 : 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수 있고, 시스템의 현재 상태를 쉽게 파악할 수도 있다. 

- 호스트 단위 메트릭 : CPU, 메모리, 디스크 I/O 메트릭 여기 해당

- 종합(Aggregated) 메트릭 : db 계층의 성능, 캐시 계층의 성능

-  핵심 비즈니스 메트릭 : 일별 능동 사용자(daily active user), 수익(revenue), 재방문(retention) 

3. 자동화: 시스템 복잡성이 올라가면 생산성을 높이기 위해서 자동화 도구를 활용해야한다. 지속적 통합 도구를 활용하면, 개발자가 만드는 코드가 검증 절차를 자동으로 거치도록 할 수 있어서, 문제를 쉽게 감지할 수 있다.

빌드, 테스트, 배포 등의 절차를 자동화하면 개발 생산성을 크게 향상시킨다. 

 

메세지 큐, 로그, 메트릭, 자동화 등을 반영하여 수정한 설계안

1. 메세지 큐는 각 컴포넌트가 더 느슨히 결합 될 수 있게하며, 결함에 대한 내성을 높인다 

2. 로그, 모니터링, 메트릭, 자동화 등 지원장치를 추가

 

 

데이터베이스의 규모 확장

 

수직적 데이터베이스 규모 확장

스케일 업으로 부르기도 하는 수직적 규모확장은, 기존 서버에 더 많은, 고성능 자원(cpu, ram, disc 등)을 지원하는 것이다. 

AWS 는 RDS(Relational Database Service)는 24TB RAM 서버도 제공한다. 이정도 고성능 DB서버는 엄청난 양의 데이터를 보관하고 처리가 가능하다. Stackoverflow.com은 13년 동안 천만명 사용자를 전부 한대의 마스터 db베이스로 처리했다. 

 

수직적 db 의 심각한 약점 1. 서버 하드웨어의 한계. cpu, ram 등을 무한 증설은 안된다. 

2. SPOF(Single Point of Failure) 의 위험성 3. 비용이 많이든다. 고성능 서버는 당연 비싸다.

 

수평적 데이터베이스 규모 확장

db 수평 확장은 샤딩(sharding)으로 부른다. 더 많은 서버를 추가해서 성능을 향상 시킨다.

샤딩은 대규모 db를 샤드(shard)라 부르는 작은 단위들로 분할하는 기술이다. 

모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복이 없다. 

예시로 user_id %4 를 해시 함수로, 데이터가 보관되는 샤드를 정한다. 결과0이면 0번 샤드에, 1이면 1번 샤드에보관 하는 것이다.

user_id 같은걸  샤딩 키(sharding key)라고 한다. 샤딩 키는 partition key라고도 부른다. 데이터가 어떻게 분산될지 정하는 하나이상의 칼럼으로 구성한다.  

샤딩을 적용한 아키텍처. 

db 부하를 줄이기 위해서, 굳이 RDBMS 가 필요없는 기능은 모두 NoSQL로 이전한다. [14]

 

시스템 규모의 확장은 지속과 반복이다. 이번 장에서 다룬 내용을 계속 반복하면, 원하는 규모의 시스템을 달성하게된다. 

이번 장에서 맺으며, 시스템 규모 확장을 위해 살펴본 기법은 다음과 같다. 

1) 웹 계층은 무상태 계층으로

2) 모든 계층에 다중화 도입

3) 가능한 많은 데이터를 적절하게 캐시할 것

4) 여러 데이터 센터를 지원할 것

5) 정적 콘텐츠는 CDN을 통해 서비스 할것

6) 데이터 계층은 샤딩으로 규모를 수평 확장할 것

7) 각 계층은 독립적 서비스로 분할할 것

8) 지속 모니터링, 로그, 자동화, 메트릭 을 활용할 것 

 

참고문헌

[1] Hypertext Transfer Protocol: https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

[2] Should you go Beyond Relational Databases?: https://blog.teamtreehouse.com/should-you-go-beyond-relational-databases

[3] Replication: https://en.wikipedia.org/wiki/Replication_(computing)

[4] Multi-master replication: https://en.wikipedia.org/wiki/Multi-master_replication

[5] NDB Cluster Replication: Multi-Master and Circular Replication: https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-replication-multi-master.html

[6] Caching Strategies and How to Choose the Right One: https://codeahoy.com/2017/08/11/caching-strategies-and-how-to-choose-the-right-one/

[7] R. Nishtala, “Facebook, Scaling Memcache at,” 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI ’13).

[8] Single point of failure: https://en.wikipedia.org/wiki/Single_point_of_failure

[9] Amazon CloudFront Dynamic Content Delivery: https://aws.amazon.com/cloudfront/dynamic-content/

[10] Configure Sticky Sessions for Your Classic Load Balancer: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

[11] Active-Active for Multi-Regional Resiliency: https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b

[12] Amazon EC2 High Memory Instances: https://aws.amazon.com/ec2/instance-types/high-memory/

[13] What it takes to run Stack Overflow: http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-stack-overflow

[14] What The Heck Are You Actually Using NoSQL For: http://highscalability.com/blog/2010/12/6/what-the-heck-are-you-actually-using-nosql-for.html