1장은 CDN 까지의 개념을 집중적으로 살펴봤다.
사용자 수에 따른 규모 확장성
사용자 수에 따른 프로그램을 설계해야한다는 내용이다.
단일서버
모든 컴포넌트가 단 한대의 서버에서 실행되는 간단한 시스템.
웹, 앱, 데이터베이스, 캐시 등이 전부 서버 한대에서 실행된다.
즉, 사용자가 도메인 이름으로 접속하면 자동으로 DNS 조회를 통해 서버의 IP 주소를 받아오고, 해당 주소로 HTTP 요청이 전달된다. 이후 웹 서버가 HTML 페이지나 JSON 형태의 응답을 생성하여 반환하기까지의 모든 과정이 하나의 서버에서 실행되는 것이다.
데이터베이스
여러 사람이 동시에 공유하여 사용할 목적으로 통합 관리되는 데이터의 집합.
이를 관리하는데, 여러 서버를 둘 수 도 있다.
EX) 웹/모바일 트래픽 처리 용도와 데이터베이스 서버를 따로두는 경우 : 독립적으로 확장 가능.
데이터베이스의 종류
데이터베이스는 크게 관계형과 비관계형으로 나뉜다.
| 구분 | 관계형 데이터베이스(RDBMS) | 비관계형 데이터베이스(NoSQL) |
|---|---|---|
| 대표 제품 | MySQL, Oracle Database, PostgreSQL | CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB |
| 데이터 저장 방식 | 테이블(Table), 행(Row), 열(Column) | 키-값 저장소(Key-Value Store), 그래프 저장소(Graph Store), 칼럼 저장소(Column Store), 문서 저장소(Document Store) |
| 데이터 조회 | SQL을 사용하여 여러 테이블을 JOIN 가능 | 일반적으로 JOIN 연산 미지원 |
관계형 데이터는 아래와 같은 상황에서 쓰기 좋다.
1) 엄격한 데이터 일관성과 트랜잭션 보장이 필요할 때 (ACID)
2) 데이터 간의 관계가 복잡하고 구조가 명확할 때 (Schema)
3) 다양하고 복잡한 조건의 데이터 조회가 필요할 때 (JOIN)
4) 비즈니스 규칙이 자주 바뀌거나 데이터가 계속 변할 때
이런 이유로 대부분의 프로그램에서 관계형을 채택 하지만 아래와 같은 경우에는 비관계형을 사용하는것이 좋다.
1) 아주 낮은 응답 지연시간 요구
2) 다루는 데이터가 관계형 데이터가 아님 (= 비정형)
3) 데이터 직렬화 혹은 역직렬화만이 필요
4) 분산 저장 및 수평 확장이 필요한 대용량 데이터를 다룰 때
데이터가 대용량이고 빠르게 쌓이는 비정형 데이터라면 NoSQL, 데이터의 정확성과 신뢰성, 복잡한 관계가 중요하다면 RDBMS를 쓰는 것이 좋다.
수직적 규모 확장(스케일업) vs 수평적 규모확장(스케일아웃)
사용자가 증가하면 서버 확장이 필요하다.
서버 확장은 수직적 규모확장과 수평적 규모확장으로 가능하다.
스케일업 : CPU, RAM, SSD 등 증설해 기존 서버의 성능을 높이는 방식
- 스케일업시 장애에 대한 자동복구나 다중화 방안 제시되지 않아 장애발생시 프로그램 중단된다는 단점이 있음.
스케일아웃 : 동일한 역할을 하는 서버를 여러 대 추가하여 처리량을 늘리는 방식
- 스케일업의 단점으로 인해, 대규모 어플리케이션에서는 스케일 아웃 사용이 적절함.
정리하자면,
스케일업이 유리 : 서버로 유입되는 트레픽 양이 적을 때
스케일아웃이 유리 : 서버로 유입되는 트레픽 양이 많을 때
트래픽 부하 분산 방법
스케일업과 스케일아웃은 서버의 성능과 처리량을 향상시키지만, 대규모 서비스에서는 이것만으로 충분하지 않다.
증가한 트래픽을 여러 웹 서버에 분산하고, 정적 콘텐츠를 효율적으로 제공하기 위한 추가적인 아키텍처 가 필요하다.
이유: 서버가 여러대일때, 쓰이지 않는 서버가 있으면 비효율.
서버 성능이 좋더라도, 하나에서 처리하는 것보다 여러대에서 처리하는 것이 효율.
로드밸런서
부하분산집합(load balancing set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산.
사용자는 DNS주소를 통해 도메인에 접속함으로, 주소를 다르게 입력하지 않아도 괜찮다.
데이터베이스 다중화
데이터 원본은 주 서버(Master)에, 사본은 부 서버(Slave)에 저장하는 방식
- 쓰기 연산(Write): 마스터(Master) 서버에서만 처리 (insert, delete, update 등)
- 읽기 연산(Read): 슬레이브(Slave) 서버들로 분산하여 처리. 통상 어플리케이션은 읽기 비중이 훨씬 높기 때문에 슬레이브 서버의 수가 더 많음.
⚠️ 서버가 다운되면 어떻게 대응하는가?
- 부(Slave) 서버가 다운된 경우: 읽기 연산은 한시적으로 모두 주 서버로 전달되며, 나머지 부 서버들이 부하를 분산함. 그동안 새로운 부 서버가 장애 서버를 대체함.
- 주(Master) 서버가 다운된 경우: 한 대의 부 서버가 새로운 주 서버로 승격(Failover)되어 일시적으로 모든 연산을 수행함.
- 실무 고려사항: 부 서버의 데이터가 최신 상태가 아닐 수 있으므로(복제 지연), 누락된 데이터는 복구 스크립트를 돌려 채워넣어야 함.
캐시
불러오는 비용이 크거나 자주 불러와야 하는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소.
캐시 계층
"느리고 무거운 원본 저장소(DB/디스크)에 접근하는 횟수를 줄이기 위해, 빠르고 가벼운 임시 저장소(메모리/RAM)에 데이터를 미리 올려두는 아키텍처 설계 기법"
컴퓨터 엔지니어링의 대원칙인 "자주 쓰는 데이터는 더 가깝고 빠른 곳에 둔다"를 웹 서버와 데이터베이스 레이어에 적용했다.
사용시 유의할점
캐시는 어떤 상황에 바람직한가
어떤 데이터를 캐시에 두어야 하는가
캐시에 보관된 데이터는 어떻게 만료(expire)되는가?
일관성은어떻게 유지되는가?
단일 장애 지점에 어떻게 대처할 것인가?
캐시 메모리는 얼마나 크게 잡을 것인가?
데이터 방출(eviction) 정책은 무엇인가?
콘텐츠 전송 네트워크 (CDN)
전 세계에 분산된 서버를 통해 웹 콘텐츠를 사용자와 가까운 위치에서 빠르게 전달하는 기술
ex)
react 라이브러리를 사용해 새로운 서비스를 개발한 민성.
MZ한 에셋을 사용해 로드오브레전드를 개발한 김낍삽.
생각한 점
트래픽이 적을 때 자원이 낭비되는 오버 엔지니어링을 경계하고, 트래픽이 많을 때는 병목 없이 유연하게 확장되는 비용 효율적인 아키텍처를 고민해야겠습니다.
