단일 서버
- 사용자는 도메인 이름(api.mysite.com)을 이용해 웹사이트에 접속한다.
웹사이트에 접속하기 위해 도메인 이름을 DNS에 질의하여 IP 주소로 변환한다. - DNS 조회 결과로 IP 주소를 반환한다.
- IP 주소로 HTTP 요청이 전달된다.
- 요청을 받은 웹 서버는 HTML이나 JSON을 응답한다.
데이터베이스
웹/모바일 트래픽 처리 서버(웹 계층)와 데이터베이스 서버(데이터 계층) 분리를 하여 독립적으로 확장 가능
관계형 데이터베이스(RDBMS)
- MySQL, Oracle, PostgreSQL
- 자료를 테이블, 열, 칼럼으로 표현
- 여러 테이블에 있는 데이터를 조인(join)할 수 있음
비관계형 데이터베이스(NoSQL)
- CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB
- 키-값 저장소(key-value store), 그래프 저장소(graph store), 칼럼 저장소(column store), 문서 저장소(document store)
- 조인 연산 지원하지 않음
- 다음과 같은 경우에 사용하는 것이 좋음
- 아주 낮은 응답 지연시간(latency) 요구하는 경우- 다루는 데이터가 비정형 데이터인 경우
- 데이터(JSON, YAML, XML 등)를 직렬화 혹은 역직렬화 할 수 있기만 하면 되는 경우
- 아주 많은 양의 데이터를 저장할 필요가 있는 경우
수직적 규모 확장 vs 수평적 규모 확장
수직적 규모 확장(Scale Up)
- 고사양 자원(더 좋은 CPU, 더 많은 RAM 등)을 추가하는 행위
- 서버로 유입되는 트래픽 양이 적을 때 좋은 선택
- 하드웨어의 한계가 있음
- 자동복구(failover) 방안이나 다중화(redundancy) 방안을 제시하지 못해 서버에 장애가 발생하면 웹사이트/앱이 완전히 중단됨
수평적 규모 확장(Scale Out)
- 더 많은 서버를 추가하여 성능을 개선하는 행위
- 대규모 애플리케이션 지원하는데 유리
로드밸런서
로드밸런서는 부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽을 고르게 분산하는 역할을 한다.
사용자는 로드밸런서의 공개 IP 주소로 접속하고, 로드밸런서와 웹서버 간의 통신에는 사설 IP 주소가 이용된다.
사설 IP 주소는 같은 네트워크에 속한 서버 사이의 통신에만 쓰일 수 있는 IP 주소로, 인터넷을 통해서는 접속할 수 없다.
부하 분산 집합에 웹 서버를 추가하면 장애 자동복구(failover) 문제가 해소되고, 웹 계층의 가용성(availability)은 향상된다.
데이터베이스 다중화
주(master) - 부(slave) 관계를 설정하고, 데이터의 원본은 master에, 사본은 slave에 저장한다.
쓰기 연산은 master에서만 지원한다. slave는 master로 부터 사본을 전달 받으며, 읽기 연산만 지원한다.
대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산의 비중보다 높기 때문에 통상적으로 slave의 수가 master의 수보다 많다.
데이터베이스 다중화의 장점
- 더 나은 성능: 쓰기 연산은 master, 읽기 연산은 slave로 전달되기 때문에 병렬로 처리될 수 있는 query의 수가 늘어나 성능이 향상된다.
- 안정성(reliability): 데이터를 지역적으로 떨어진 여러 장소에 다중화시켜 놓으면 자연 재해등의 이유로 데이터베이스 서버의 일부가 파괴되어도 데이터가 보존된다.
- 가용성(availability): 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생해도 다른 서버에서 데이터를 가져와 계속 서비스할 수 있다.
캐시
캐시 계층
데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다.
별도의 캐시 계층을 둠으로써 성능이 개선되고, 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능하다.
캐시할 데이터의 종류, 크기, 액세스 패턴에 맞는 캐시 전략을 선택할 수 있다.
캐시 사용 시 유의할 점
- 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우 캐시 사용에 유리
- 캐시는 데이터를 휘발성 메모리에 두므로 영속적으로 보관할 데이터를 캐시에 두는 것은 바람직하지 않음
- 적절한 만료(expire) 정책을 설정하는 것이 좋음
- 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부인 일관성(consistency) 고려 필요
- 캐시 서버를 한 대만 두는 경우 단일 장애 지점(Single Point of Failure, SPOF)이 되어버릴 가능성이 있기 떄문에 여러 지역에 걸쳐 캐시 서버 분산시키는 것이 좋음
- 캐시 메머리 과할당(overprovision)을 통해 캐시 메모리가 부족해지는 문제 해결
- 적절한 캐시 데이터 방출(eviction) 정책 필요
콘텐츠 전송 네트워크(CDN)
CDN은 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크이다.
이미지, 비디오, CSS, JavaScript 파일 등을 캐시할 수 있다.
- 사용자 A가 CDN 서비스 사업자가 제공한 이미지 URL을 통해 이미지에 접근한다.
- CDN 서버의 캐시에 해당 이미지가 없는 경우, 서버는 원본 서버에 파일을 요청하여 가져온다.
- 원본 서버가 파일을 CDN 서비스에 반환한다. 이때 응답 헤더에는 캐시될 수 있는 기간인 TTL이 들어있다.
- CDN 서버는 파일을 캐시하고 사용자 A에게 반환한다. 이미지는 TTL이 끝날 때까지 캐시된다.
- 사용자 B가 같은 이미지에 대한 액세스 요청을 CDN 서버에 전송한다.
- 만료되지 않은 이미지에 대한 요청은 캐시를 통해 처리된다.
CDN 사용 시 고려해야 할 사항
- 비용: CDN으로 들어가고 나가는 데이터 전송 양에 따라 요금을 내게 되므로, 자주 사용되지 않는 콘텐츠를 캐싱하는 것은 이득이 크지 않음
- 적절한 만료 시한 설정: 너무 길지도, 짧지도 않은 TTL 설정 필요
- CDN 장애에 대한 대처 방안: CDN 자체가 죽었을 경우, 해당 문제를 감지하여 원본 서버로부터 직접 콘텐츠를 가져오도록 클라이언트 구성 필요
- 콘텐츠 무효화 방법
- CDN 서비스 사업자가 제공하는 API 이용- 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝 이용
무상태(stateless) 웹 계층
상태 정보에 의존적인 아키텍처는 서버에 사용자의 상태 정보가 보관되어 있기 때문에 같은 클라이언트로부터의 요청을 항상 같은 서버로 전송해야 하는 문제점이 발생한다.
대부분의 로드밸런서가 이를 지원하기 위해 고정 세션(sticky session) 기능을 제공하고 있지만, 이는 로드밸런서에 부담을 준다.
무상태 아키텍처는 상태 정보를 공유 저장소에 저장하여 필요한 경우 가져와서 사용한다.
상태 정보는 웹 서버로부터 물리적으로 분리되어 있어 안정적이며, 규모 확장이 쉽다.
상태 정보가 저장되는 공유 저장소르 관계형 데이터베이스일 수도 있고, Memcached/Redis 같은 캐시 시스템일 수도 있고, NoSQL일 수도 있다.
데이터 센터
지리적 라우팅(geoDNS-routing, geo-routing): 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내됨
geoDNS: 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해주는 DNS 서비스
DC1(US-East), DC2(US-West)로 트래픽이 나뉘어 전달된다고 할 때,
DC2(US-West)에서 장애가 발생하면 모든 트래픽이 DC1(US-East)로 전송된다.
다중 데이터센터 아키텍처를 만들기 위한 기술적 난제
- 트래픽 우회: 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야 함. GeoDNS는 사용자에게서 가장 가까운 데이터 센터로 트래픽을 보냄
- 데이터 동기화(synchronization): 데이터를 여러 데이터 센처에 걸쳐 다중화하는 것 필요
- 테스트와 배포(deployment):자동화된 배포 도구는 모든 데이터 센터에 동일한 서비스가 설치되도록 하는데 중요한 역할
메시지 큐
메시지 큐: 메시지의 무손실(durability, 메시지 큐에 보관된 메시지는 소비자가 꺼낼 때까지 안전하게 보관됨)을 보장하는, 비동기 통신(asynchronous communication)을 지원하는 컴포넌트
메시지 큐를 이용하면 서버 간 느슨한 결합(loosely coupled)이 되어 규모 확장성이 보장되어야 하는 안정적 애플리케이션 구성에 유리하다.
또한 생산자와 소비자는 각기 독립적으로 확장 가능하다.
로그, 메트릭 그리고 자동화
- 로그: 로그를 단일 서비스로 모아주는 도구를 활용해 편리하게 에러 로그 모니터링
- 메트릭: 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악 가능.
- 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O에 관한 메트릭
- 종합(aggregated) 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능
- 핵심 비즈니스 메트릭: 일별 능동 사용자(DAU), 수익(revenue), 재방문(retention)
- 자동화: 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구 이용. 지속적 통합(Continuous Integration) 도구를 통해 빌드, 테스트, 배포 등의 절차 자동화 가능
데이터베이스의 규모 확장
수직적 확장(Scale Up)
- 기존 서버에 더 많은, 고성능의 자원(CPU, RAM, 디스크 등)을 증설하는 방법
- 수직적 확장의 단점
- 데이터베이스 서버 하드웨어에는 한계가 있으므로 무한대로 자원을 증설할 수 없다.
- SPOF로 인한 위험성이 크다.
- 고성능 서버로 갈 수록 비용이 많이 든다.
수평적 확장(Scale Out)
- 샤딩(sharding)이라고도 부름
- 더 많은 서버를 추가함으로써 성능 향상
- 샤딩: 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술
- 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복 없음
- 데이터를 고르게 분할할 수 있는 적절한 샤딩 키(sharding key)를 정해 데이터 조회나 변경 처리의 효율을 높임
- 샤딩 도입시 풀어야할 문제
- 데이터의 재 샤딩(resharding): 데이터가 너무 많아져서 하나의 샤드로 감당하기 어렵거나, 샤드 소진 현상이 발생하면 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치 해야함
- 유명인사(celebrity) 문제: 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
- 조인과 비정규화: 하나의 데이터베이스를 여러 샤드로 쪼개면, 여러 샤드에 걸친 데이터를 조인하기 힘들어짐. 데이터베이스 비정규ㄹ화를 통해 하나의 테이블에서 질의가 수행될 수 있도록 하여 해결
