[대규모 시스템 설계 기초] 1장

[대규모 시스템 설계 기초] 1장 : 사용자 수에 따른 규모 확장성

---

1. 일반적인 서비스 구성

- 일반적인 Application은 아래와 같이 구성된다. 보통 규모의 서비스는 직접 Server를 구매하여 구성하기도 한다. 하지만 대규모 서비스에서는 Application Load Balance, Auto Scaling, Security 등 다양한 기능과, 유연성 때문에 AWS같은 클라우드 사용하여 서비스를 구성하는것이 좋다.

---

2. 서비스 구조
- 사용자에게 빠르고 안정적인 서비스를 하기위해서 Server, CDN 등은 대륙, 국가, 도시에 존재한다. AWS를 예로들면 아래와 같다. 또한 H/A (high availability) 구성을 위해 여러 지역에 동일한 Application이 배포된다. 때문에 천재지변이나 예기치 못한 사고가 발생해도 서비스가 아주 빠르게 복구될 수 있다.

---

3. Elastic Servcie

- 대규모 트래픽, 데이터를 처리하기 위해서는 탄력적인 서비스가 필요하다. 탄력적인 서비스를 위해서는 Application이 처리할 수 있는 만큼만 Request나 Event를 받아야 한다. 아래와 같은 기능들이 이를 지원한다.

• Auto Scaling: Request나 CPU 사용량 등 특정기준에 따라 Server를 증가/감소 시킨다.
• Api Gateway Throttle: 지정한 Reuest가 넘어가면 Server로의 Request를 차단한다.
• Stream Backpressure: 처리할 자원이 없는 경우 새로운 Event를 요청하지 않는다.

---

4. DB

- 보통 크기의 데이터의 처리하는 서비스는 RDS를 많이 사용한다. 하지만 RDS는 저장하는 있는 데이터가 많을 경우 인덱스나 컬럼의 추가/변경이 힘들다. 또한 대용량 데이터를 처리하기 위해서 샤딩을 사용하지만 한번 설정된 샤딩을 다시 변경하기 매우 힘들기 때문에 대규모 트래픽을 처리하는 서비스에는 적합하지 않다. 때문에 Gossip protocol을 사용하는 Cassandra나 Elastic Search 등 서비스 특징에 맞는 NoSql DB를 사용한다. 대용량 데이터를 처리하는 경우 가용성(Availability) 과 정확성 (Consistency) 중 하나를 선택해야 한다. 2가지를 모두 충족하는 DB는 없다.

---

5. Cache

- 대규모 트래픽을 처리하는 서비스에서 DB는 매우 비싼 자원이다. 때문에 DB의 접근을 줄이기 위해서 Cache를 사용한다. Cache는 꼭 최신데이터가 필요하지 않거나, 자주 변경되지 않는 데이터에 적합하다. Cache의 종류로는 크게 Guava같은 Local Cache, Redis같은 Grobal Cache 등이 있다.

---

6. Monitoring

- 대규모 트래픽을 처리하는 서비스는 잠시만 정지하더라도 많은 데이터가 날아간다. 때문에 빠르게 Application의 상태를 캐치하여 장애를 처리해야 한다. 모니터링 툴은 보통 JMX, Exporter, Grafana, Graphite, Promethues 등이 많이 사용되고, Alarm은 Email, Slack, Vitor Ops 등이 많이 사용된다.

---

8. Performance Test
- 대규모 트래픽을 처리하는 서비스는 당연한 애기지만 많은 자원을 사용하고 비용도 많이 들어간다. 때문에 현재 Application 사양에서 최대 성능을 뽑아내야 한다.