Overview

---

규모의 확장성과 관계된 설계 문제를 푸는데 유용한 지식들을 정리한다.
또한 "가상면접사례" 가 제목에 포함된 만큼, 기초적인 지식들을 함께 정리하는 것을 목표로 한다.

단일서버

• dns
  

(1) 브라우저가 설치된 컴퓨터는 opentutorials.org의 IP를 알아내기 위해서 가장 가까운 곳에 위치한 DNS에 opentutorials.org의 IP를 문의 한다.
(2)가장 가까운 DNS 서버가 IP를 알고 있다면 즉시 IP 주소를 알려준다. 하지만 IP 주소를 모르면 루트 도메인 네임서버에게 문의한다.
(3) 루트 네임서버는 도메인의 최상위 도메인이 .org인 것을 보고 .org가 등록된 네임서버의 IP를 전달한다. 이것은 이런 의미가 된다. "나는 IP 주소를 가지고 있지 않지만, .org 네임서버에게 물어보면 도와줄꺼야"
(4) 가장 가까운 DNS는 org 도메인을 관리하는 네임서버에게 문의한다.
(5) org 네임서버는 opentutorials의 네임서버 IP 주소를 알려준다.
(6) 가장 가까운 DNS 서버는 opentutorials의 네임서버에게 문의하고,
(7) www 의 네임서버를 알려준다.
(8) 최종적으로 www 네임서버에게 문의 후
(9) www.opentutorials.org의 IP 주소를 얻는다.
(10) 가장 가까운 DNS 서버는 이 IP 주소를 클라이언트에게 알려준다. 클라이언트 컴퓨터는 이 IP를 브라우저에게 알려주면 브라우저는 이 IP에 해당하는 컴퓨터에 접속 할 수 있게 된다.

• web service architecture
  

• 일반적인 사용자 요청 처리 흐름은 아래와 같음

(1) DNS에 도메인 이름을 IP 주소로 변환하는 과정 진행
(2) 변환된 IP 주소로 HTTP 요청을 전달
(3) 요청받은 웨 서버는 정적 컨텐츠 또는 JSON을 전달함

• 웹의 경우 WS, WAS 에서부터 원하는 정보를 얻어옴
• 모바일의 경우 HTTP 프로토콜을 이용해서 응답 데이터 포맷을 전달받음(JSON)

도메인 vs 호스트

• 호스트

웹사이트를 호스팅하는 제공업체가 호스팅됩니다. 이 사람들은 서버 공간을 임대하여 웹 사이트 또는 응용 프로그램을 호스팅하고 전 세계적으로 사용할 수 있도록 합니다. 웹 호스팅은 사람들이 웹 사이트, 웹 응용 프로그램, 백업 파일, 데이터베이스 등을 저장하는 장소입니다. 모든 물건을 보관하는 집이라고 생각하십시오. 웹 호스트에 컴퓨터 파일(HTML, 문서, 이미지, 비디오 등)을 저장합니다. 종종 "웹 호스팅"이라는 용어는 귀하의 웹사이트(따라서 호스트라는 단어)를 저장하기 위해 컴퓨터/서버를 임대하고 다른 컴퓨터가 귀하의 웹사이트에 있는 파일에 액세스할 수 있도록 인터넷 연결을 제공하는 회사를 의미합니다.

• 도메인

도메인 이름은 웹사이트 이름입니다. 도메인 이름은 인터넷 사용자가 웹사이트에 액세스할 수 있는 주소입니다. 도메인 이름은 인터넷에서 컴퓨터를 찾고 식별하는 데 사용됩니다. 컴퓨터는 일련의 숫자인 IP 주소를 사용합니다. 그러나 인간이 일련의 숫자를 기억하는 것은 어렵습니다. 이 때문에 IP 주소를 사용하는 대신 인터넷에서 개체를 식별하기 위해 도메인 이름이 개발되고 사용되었습니다.

데이터베이스

• 사용자가 늘어날 수록 인메모리 방식으로 데이터를 저장하는 것은 확장성이나 가용성 측면에서 쉽지 않음
• 따라서 웹/모바일 트래픽 처리 서버와 데이터베이스 서버를 분리하면, 각각을 독립적으로 확장할 수 있다는 장점이 있음

데이터베이스 선택하기

관계형 데이터베이스란? (RDBMS)

• MySQL , Oracle , MsSQL , PostgreSQL ...
• 자료를 테이블과 열, 칼럼으로 표현하고, 각 테이블간의 관계에 집중하여 스키마를 설계
• Join 을 통해서 각 테이블간의 정의된 관계를 활용하여 클라이언트에 정보를 제공할 수 있음
• ACID

비-관계형 데이터베이스란? (NOSQL)

• Mongo DB, CouchDB, Neo4j, Cassandra , HBase , Amazon DynamoDB ...
• 키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소 등으로 나눠 질 수 있음
• 관계형데이터베이스가 아닌 Remainder라고 생각하면 됨
• BASE

NOSQL이 바람직한 경우

• 아주 낮은 응답 지연시간(latency)이 요구되는 경우
• 다루는 데이터가 비정형이라 관계형 데이터가 아닌 경우
• 데이터(JSON, YAML, XML..) 을 직렬화(serialize) 역직렬화(deserialize) 하는 경우
• 대용량의 데이터가 저장할 필요가 있는 경우

수직 vs 수평 규모의 확장

수직

• scale up 이라고도 함
• 서버를 더 좋은 사양으로 바꾸는 것(CPU, RAM, Memory..)

수평

• scale out 이라고도 함
• 서버의 개수를 늘리는 것

• 서버로 유입되는 트래픽의 양이 높지 않을 때는 scale up 을 고려하는 것이 좋고, 반대의 경우에는 scale out 을 고려해본다
• 수직적 규모 확장에는 한계가 존재한다
• 수직적 규모 확장법은 장애에 대한 자동복구(failover) 방안이나 다중화(redundancy) 방안의 제시가 불가능함
• 사용자가 많아지는 경우 로드밸런서를 도입하고, scale out 하는 것이 현실적인 방법

로드밸런서

• 부하분산집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할
• DNS를 이용해서 공개 IP 주소로 접속시에 웹 서버가 직접 처리하기보다는 로드밸런서로 접속
• 로드밸런서는, 보안을 위해 사설 IP 주소가 할당된 서버들에 대신 접속하여 응답
• 사설 IP가 할당 된 2개의 서버가 존재한다고 가정한다면, 서버 1이 다운되면 서버 2로 전환함
• 즉, 가용성을 높이는 역할을 함
• 트래픽이 증가하면 웹 서버 계층에 더 많은 서버를 추가하기만 하면 됨

데이터 베이스의 자동화

• 위 로드밸런서의 경우 웹서버의 가용성을 높이는 방식이었다면, 데이터베이스의 경우는 데이터베이스 관리 시스템의 다중화를 이용
• master - slave 데이터베이스를 구축해서 원본은 master, 사본은 slave 에 저장함
• write 연산은 master 데이터베이스 서버를 이용하고, slave 에서는 읽기 연산만을 진행
• 대부분의 서비스는 읽기 연산이 대부분인 만큼, slave 데이터베이스의 수가 더 많음
• 읽기와 쓰기(삭제, 업데이트) 를 분리함으로써 병렬로 처리될 수 있는 query의 수가 증가하는 장점이 있음
• 재해의 경우에 데이터베이스 서버가 사용 불가능 해져도, 데이터는 보존할 수 있는 장점이 있음
• 데이터를 여러지역에 분산처리함으로써, 하나의 데이터베이스에 서버장애가 발생해도 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있음

Q : 데이터베이스 서버 한개가 다운 되면 어떻게 될까?
A1 : 부 서버가 다운된다면, 읽기연산은 한시적으로 모두 주 데이터베이스로 전달되고 즉시 새로운 부 데이터베이스 서버가 생성될 것 + 부 서버가 여러대인 경우 곧바로 새로 생성될 것이라 문제가 없을것으로 보임
A2 : 주 데이터베이스 서버가 다운되는 경우에 한 개의 부 데이터 서버가 있다면, 역할을 주 데이터베이스로 변경할 것이고 새로운 부 데이터베이스 서버가 수행될 것임
A3 : 프로덕션 환경에서는 부 서버에 보관된 데이터베이스가 최신이 아닐경우 문제가 생길 수 있음, 이 경우에는 recovery script를 추가해야함. 다중 마스터나 원형 다중화 방식을 도입하면 될 수 있음

리플리케이션

• 리플리케이션이란 여러 개의 DB를 권한에 따라 수직적인 구조(Master-Slave)로 구축하는 방식
• 리플리케이션에서 Master Node는 쓰기 작업 만을 처리하며 Slave Node는 읽기 작업 만을 처리
• 리플리케이션은 비동기 방식으로 노드들 간의 데이터를 동기화하는데, 자세한 처리 방법은 아래와 같다.

(1) Master 노드에 쓰기 트랜잭션이 수행된다.
(2) Master 노드는 데이터를 저장하고 트랜잭션에 대한 로그를 파일에 기록한다.(BIN LOG)
(3) Slave 노드의 IO Thread는 Master 노드의 로그 파일(BIN LOG)를 파일(Replay Log)에 복사한다.
(4) Slave 노드의 SQL Thread는 파일(Replay Log)를 한 줄씩 읽으며 데이터를 저장한다.
(5) 리플리케이션은 Master와 Slave간의 데이터 무결성 검사(데이터가 일치하는지)를 하지 않는 비동기방식으로 데이터를 동기화한다.

• 장점

DB 요청의 60~80% 정도가 읽기 작업이기 때문에 Replication만으로도 충분히 성능을 높일 수 있다.
비동기 방식으로 운영되어 지연 시간이 거의 없다.

• 단점

노드들 간의 데이터 동기화가 보장되지 않아 일관성있는 데이터를 얻지 못할 수 있다.
Master 노드가 다운되면 복구 및 대처가 까다롭다.

클러스터링

• 클러스터링이란 여러 개의 DB를 수평적인 구조로 구축하는 방식
• 클러스터링은 분산 환경을 구성하여 Single point of failure와 같은 문제를 해결할 수 있는 Fail Over 시스템을 구축하기 위해서 사용
• 클러스터링은 동기 방식으로 노드들 간의 데이터를 동기화하는데, 자세한 처리 방법은 아래와 같음

(1) 1개의 노드에 쓰기 트랜잭션이 수행되고, COMMIT을 실행한다.
(2) 실제 디스크에 내용을 쓰기 전에 다른 노드로 데이터의 복제를 요청한다.
(3) 다른 노드에서 복제 요청을 수락했다는 신호(OK)를 보내고, 디스크에 쓰기를 시작한다.
(4) 다른 노드로부터 신호(OK)를 받으면 실제 디스크에 데이터를 저장한다.

• 장점

노드들 간의 데이터를 동기화하여 항상 일관성있는 데이터를 얻을 수 있다.
1개의 노드가 죽어도 다른 노드가 살아 있어 시스템을 계속 장애없이 운영할 수 있다.

• 단점

여러 노드들 간의 데이터를 동기화하는 시간이 필요하므로 Replication에 비해 쓰기 성능이 떨어진다.
장애가 전파된 경우 처리가 까다로우며, 데이터 동기화에 의해 스케일링에 한계가 있다.

캐시

• 연산결과나 자주 참조되는 데이터를 인메모리형태로 가지고, 뒤이은 동일한 요청에 대해 빠르게 처리할 수 있도록 하는 저장소

캐시 계층

• 아래와 같은 방식을 read-through caching strategy 라고 함

(1) 데이터가 캐시에 있으면 캐시에서 데이터를 리턴
(2) 데이터가 캐시에 없으면 DB에 요청
(3) (1) 또는 (2) 의 결과를 클라이언트에 전달

캐시계층 사용시 유의할 점

• select가 빈번하게 사용되는 경우에 활용할 것
• 영속적인 데이터 저장이 빈번하게 필요한 경우에는 사용하지 않는 것이 좋음
• CRUD 과정에서 영속데이터 저장시 캐시계층에도 함께 수정해야함(트랜잭션)
• SPOF 를 일으킬 수 있기 때문에 단일화 캐시 서버를 두는 것은 위험
• eviction을 고려해서 캐시메모리의 크기를 결정해야함
• eviction의 종류로는 LRU + LFU + FIFO.. 등이 존재

프로그래머스 문제

CDN

• 정적 컨텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버의 네트워크
• 정적컨텐츠는 js, css, html, jpg 등..
• 동적컨텐츠 전송이란?
• 순서는 아래와 같음

(1) URL을 통해서 컨텐츠 접근을 수행, CDN 서비스 사업자가 도메인을 제공
(2) 서버에 캐시된 이미지가 없는 경우, 원본 서버에 요청하여 파일을 가져와서 전달 및 캐싱
(3) 응답의 HTTP 헤더에는 해당 파일이 얼마나 캐시 될 수 있는지 Time To Live 를 설정(원본서버에서 캐시서버에게 컨텐츠를 넘겨줄때)

CDN 사용시 고려해야할 점

• 비용
• TTL
• CDN 장애에 대한 대안을 고려해야함
• Object Versioning 을 통한 컨텐츠 버전 분리

무상태 웹 계층

• WS(WAS) 와 DB Server를 분리한다면 웹 서버는 상태를 가지고 있지 않고 이것을 무상태(stateless) 라고 부름

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

• 상태 정보를 보관하는 것과 하지 않는 것의 차이는 동일한 정보를 보여주는 것의 유무임
• 만일 WAS 와 DB 서버가 각기 다르게 매칭되어 있다면 로드 밸런서는 sticky session 기능을 통해서 클라이언트별 요청 서버 분리를 해야함
• 차라리 DB 서버를 단일로 두거나 서로 업데이트시 공유하는 것이 나을 수도 있음

무상태 아키텍처

• 서버는 클라이언트가 요청한 정보에 응답하기 위해서 DB Server 로 부터 데이터를 가져옴

• 일반적인 웹 서버 계층

• 로드밸런서를 추가

• sticky session 활용

• session을 하나로 사용하는 방식

데이터센터

• 여러개의 데이터 센터를 이용하는 경우, 장애가 없는 서버가 위치한 지역에서 가장 가까운 데이터 센터를 활용
• 속도개선에 영향을 끼칠 수 있음
• 이 절차를 지리적 라우팅(geoDNS-routing || geo-routing)
• 데이터 다중 아키텍처를 만들려면 기술적인 고려가 필요

(1) 트래픽 우회 : 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법
(2) 데이터 동기화
(3) 테스트와 배포를 통한 데이터 정합성 검증

메시지 큐

• 시스템 규모를 확장하면서 여러 컴포넌트들로 분리하게되고, 이 때 메시지 큐는 분산 시스템을 효과적으로 활용하기 위한 핵심적인 전략기술 중 하나
• 정보나 요청의 무손실을 보장하는 비동기 컴포넌트
• 메시지 버퍼 역할을 비동기적으로 전송
• 메시지 큐를 이용하면 서비스 또는 서버 간 결함이 느슨해져서, 규모 확장성이 보장 되어야 하는 안정적인 애플리케이션을 구성할 수 있음
• producer + consumer 프로세스가 각자 다르게 구성되어있는 것이 특징

로그, 메트릭, 자동화

• 서비스의 규모가 커지면 로그, 메트릭 자동화 서비스는 필수적일 수 있음
• 로그 : 에러 로그 모니터링에 활용할 수 있음, 서버 단위로 모니터링 할 수도 있지만 로그 자체를 단일 서비스로 구성하여 한 곳에 모아주는 도구를 활용하는 방식으로 구성할 수 있음
• 메트릭 : 시스템 현재 상태를 손쉽게 확인하는 도구

(1) 호스트 단위 메트릭 : 시스템 자원을 관리
(2) 종합 메트릭 : 데이터 베이스 계층의 성능이나 캐시 계층의 성능을 관리
(3) 비즈니스 메트릭 : 일별 사용자나 방문자, 재방문 정도를 확인할 수 있음

• 자동화 : 시스템이 크고 복잡해지면 개발이나 배포 등 생산성을 높이기 위한 도구를 활용하면 편리함 (git + jenkins..등)

데이터베이스의 규모확장

• 데이터베이스 규모가 확장되면 부하도 그에 따라 증가하게 되고, 이를 해결하기 위한 증설방안을 고려해 봐야함

수직적 확장

• 더 좋은 컴퓨터 사양으로 교체함
• SPOF 를 고려해야함
• 바운더리가 존재(HW성장의 한계)
• 비용적인 문제 고려

수평적 확장

• 샤딩 이라고 부름
• 더 많은 DB 서버를 여러개 구성해서 함께 사용함으로써 트래픽 분산
• 샤드 라고 부르는 작은 단위로 분할하는 기술을 말함
• 클라이언트에 따라 접근하는 DB 를 지정하는 여러가지 샤딩키를 설정
• 아래와 같은 상황도 고려해야 할 수 있음

• Resharding : 데이터베이스가 많아지거나, 공간 소모가 빨라지는 경우 해싱 기법을 통해서 다시 샤딩하는 것
• celebrity 문제
• 조인과 비정규화 : 샤드가 너무 많아질 경우 조인하기 힘들어질 수 있음

마무리

• 웹 계층은 무상태 계층으로 두는 것이 좋음
• 모든 계층에 다중화를 도입해서 유연하게 대응하자
• 가능한 많은 데이터를 개싱하는 것이 좋을 때가 많음
• 데이터 센터를 확보하자?
• 정적 콘텐츠는 CDN을 고려해보자
• 데이터 계층은 수직, 수평적으로 확장이 가능하고 수평확장의 경우 핵심은 샤드키 설정
• 각 계층은 독립적 서비스를 활용하고 메시지 큐를 활용하면 컴포넌트 별 느슨한 결합이 가능해짐
• 자동화, 로그, 매트릭 등을 적극적으로 활용해서 유연한 설계를 하자
• Latency Numbers Every Programmer Should Know