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

Y·2022년 11월 1일

가상 면접 사례로 배우는 대규모 시스템 설계 기초

목록 보기

1/9

*<가상 면접 사례로 배우는 대규모 시스템 설계 기초> 을 참고하여 작성한 게시물입니다.

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

1. 단일서버

가장 처음으로는 단일 서버를 사용한다. 사용자 단말은 도메인 이름을 이용하여 웹 사이트에 접속하며, 도메인 이름은 DNS를 통해 IP 주소로 변환된다. 그러면 해당 IP주소로 HTTP 요청이 전달되고, 요청을 받은 서버는 HTML 페이지/JSON 형태의 응답을 반환하게 된다.

2. 웹서버와 DB 서버의 분리

사용자 수가 늘면 단일 서버로는 충분치 않다. 그러면 웹/모바일 트래픽 처리 용도의 서버와, DB용 서버를 각각 따로 두게 된다. 이를 분리하면 각각 독립적으로 확장이 가능해진다.

서버에는 수직적 규모 확장, 수평적 규모 확장이 있는데 수직적 규모 확장(scale up)은 서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM)을 추가하는 행위이고, 수평적 규모 확장(scale out)은 더 많은 서버를 추가하여 성능을 개선하는 행위이다. 서버로 유입되는 트래픽 양이 적을 때는 수직적 확장이 좋은 선택이나, 이에는 한계가 있으며 장애에 대한 자동복구(failover) 방안이나 다중화(redundancy) 방안을 제시하지 않는다. 장애가 발생하면 엡/앱은 완전히 중단되는 것이다. 따라서 대규모 애플리케이션에는 수평적 규모 확장이 보다 적절하다.

3. 로드밸런서의 사용

웹 서버들에게 부하를 고르게 분산하기 위해서 로드밸런서를 사용할 수 있다. 사용자가 로드밸런서의 공개 IP 주소로 접속하면, 웹 서버는 클라이언트의 접속을 직접 처리하지 않고, 로드밸런서는 사설 IP 주소(같은 네트워크에 속한 서버 사이의 통신에만 쓰임. 인터넷을 통해 접속할 수 없음.)를 이용하여 웹 서버와 통신한다.

서버 1이 다운되면 모든 트래픽은 서버2로 전송된다. 웹사이트로 유입되는 트래픽양이 매우 많아지면 두 대의 서버로도 부족한데, 이때 로드밸런서가 있으므로 서버 추가가 매우 쉽다. 서버를 추가하기만 하면 로드밸런서가 자동으로 트래픽을 분산한다.

웹서버는 이와같이 다중화되고, 데이터베이스 서버의 경우 서버 사이에 주(master)-부(slave) 관계를 설정하여 데이터 원본은 주 서버, 사본은 부 서버에 저장하는 방식을 사용한다. 쓰기 연산은 주 서버에서만 지원하고, 부 서버는 주 서버로부터 그 사본을 전달받아, 읽기 연산을 지원한다. 이를 통해 더 나은 성능(대부분의 질의인 읽기 연산이 여러개의 부 서버를 통해 분산된다.), 안정성(DB 서버 가운데 일부가 파괴되어도 데이터가 보존된다.), 가용성(데이터를 여러 지역에 복제해둠으로써, 하나의 DB 서버에 장애가 발생해도 다른 서버에 있는 데이터를 가져와서 계속 서비스할 수 있게 된다.)이 보장된다.

만약 부 서버가 한 대뿐인데 다운되면, 읽기 연산은 한시적으로 모두 주 서버로 전달된다. 그리고 즉시 새로운 부 서버가 장애 서버를 대체한다. 부 서버가 여러대인 경우라면 읽기 연산은 나머지 부 서버로 전달도니다. 주 서버가 다운되면 한 대의 부 서버만 있는 경우 해당 부 서버가 새로운 주 서버가 되며, 모든 DB 연산은 일시적으로 새로운 주 서버에서 수행된다. 그리고 새로운 부 서버가 추가된다. 그러나 부 서버에 보관된 데이터가 최신 상태가 아닐 수 있으므로, 없는 데이터는 복구 스크립트를 돌려서 추가해야한다. 다중 마스터(multi-master), 원형 다중화(circular replication) 방식을 도입하면 이러한 상황에 대처하는데 도움이 될 수 있다.

이는 다음과 같이 동작하는데, 사용자가 DNS로 부터 로드 밸런서의 공개 IP 주소룰 바드면 사용자는 해당 IP 주소를 이용해 로드밸런서에 접속하고, HTTP 요청은 서버1 또는 서버2로 전달된다. 웹 서버는 사용자의 데이터를 부 DB서버에서 읽고, 데이터 변경 연산(추가, 삭제, 갱신)은 주 DB서버로 전달한다.

4. 캐시와 CDN의 사용

응답시간(latency)를 개선하기 위하여 캐시를 붙이고, 정적 콘텐츠를 CDN으로 옮길 수 있다. 캐시는 값비싼 연산 결과, 혹은 자주 참조되는 데이터를 메모리 안에 두고 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다. 앱의 성능은 DB를 얼마나 자주 호출하느냐에 크게 좌우되는데, 웹 페이지를 새로 고침할때마다 표시할 데이터를 가져오기 위해 한 번 이상의 DB 호출이 발생한다. 캐시는 이런 문제를 완화할 수 있다.

캐시는 데이터가 잠시 보관되는 곳으로, DB보다 훨씬 빠르다. 별도의 캐시 게층을 두면 성능이 개선될 뿐만 아니라 DB의 부하를 줄일 수 있고, 캐시 계층 규모를 독립적으로 확장시키는 것도 가능하다. 웹 서버는 캐시에 응답이 저장되어있는지 확인하고 저장되어있으면 이를 클라이언트에 반환, 저장되어있지 않으면 DB를 통해 데이터를 찾아 캐시에 저장한 뒤 클라이언트에 반환한다. (이는 컴퓨터 내부에서 사용하는 방식과 동일한 것 같다.)

캐시의 경우 데이터 갱신이 잦지 않고, 참조가 잦은 데이터에 고려할 수 잇다. 휘발성 메모리이므로 영속적으로 보관할 메모리는 캐시에 두지 않고, 만료에 대한 정책을 마련해야한다. 일관성에 대해서도 고민해야한다. (저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션이 아니라면 일관성이 꺠질 수 있다.) 또한 캐시 서버를 하나만 두면 단일 장애 지점(SPOF, 어떤 특정 지점에서의 장애가 전체 시스템의 동작을 중단시켜버릴 수 있는 경우)가 될 수 있으므로, 이를 피하려면 여러 지역에 걸쳐 캐시 서버를 분산해야한다. 메모리가 너무 작으면 데이터가 너무 자주 캐시에서 밀려나버려서 캐시의 성능이 떨어지므로 메모리에 대해서도 고민해야하는데, 캐시메모리를 과할당하는 방법이 있다. 캐시가 꽉 차면 추가 캐시에 데이터를 넣기위해 기존 데이터를 내보내야하는데, 이에 대한 데이터 방출 정책도 고민해야한다.

CDN은 정적 콘텐츠를 전송하는데 쓰이는 지리적으로 분산된 서버의 네트워크다. 이미지, 비디오, CSS, JS 파일등을 캐시할 수 있다. (동적 콘텐츠 캐싱도 있다. request path, query string, cookie, request header 등의 정보에 기반해 HTML 페이지를 캐시하는 것이다.) CDN은, 어떤 사용자가 웹사이트에 방문하면 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하는 방식이다. (사용자와 서버의 거리가 멀수록 로딩시간은 길기 떄문이다.) 사용자가 이미지 URL을 통해 사진에 접근할때, CDN 서버의 캐시에 해당 이미지가 없으면 원본 서버(S3나 웹 서버 등일 수 있을 것이다.)에 요청하여 파일을 가져오고, 원본 서버가 파일을 CDN 서버에 반환한다. 응답 HTTP 헤더에는 해당 파일의 TTL 값이 설정되어 있다. CDN 서버는 파일을 캐시하고 사용자 A에게 반환, 이미지는 TTL에 명시된 시간이 끝날때까지 캐시된다. 사용자 B가 같은 이미지에 대한 요청을 CDN 서버에 전송하면, 만료되지 않은 경우 캐시를 통해 요청이 처리된다.

CDN 사용시에는 비용, 만료 시한 설정(너무 길지도 짧지도 않아야함.), CDN 장애에 대한 대처방안(CDN 자체가 죽었을 경우 어떻게 동작해야할지. 해당 문제를 감지하여 원본 서버로부터 가져오도록 한다든지...), 콘텐츠 무효화 방법(아직 만료되지 않아도 CDN에서 제거. CDN 서비스 사업자가 제공하는 API를 사용하거나, 다른 버전을 사용하도록 오브젝터 버저닝 ex.URL 마지막에 버전 번호를 인자로 줌)을 고민해아한다.

이를 통해 정적 콘텐츠(JS, CSS, 이미지 등)은 더 이상 웹 서버를 통해 서비스하지 않으며, CDN을 통해 제공하여 더 나은 성능을 보장한다. 그리고 캐시가 DB 부하를 줄여준다.

5. 무상태 웹 계층

웹 계층을 수평적으로 확장하는 방법이다. 이를 위해서는 상태 정보(세션 데이터 등)은 웹 계층에서 제거해야한다. 이를 위해서 바람직한 전략은 상태 정보를 RDB, NoSQL등의 지속성 저장소에 보관하고 필요할때 가져오도록 하는 것으로, 이렇게 구성된 웹계층을 무상태 웹계층이라한다. 웹서버가 상태를 가지게되면, 같은 클라이언트의 요청이 항상 같은 서버로 고정되어야하는데 이를 위해 고정 세션이라는 기능을 제공하고는 있으나 이는 로드밸런서에 부담을 준다. 따라서 무상태 아키텍처를 사용하면, HTTP 요청은 어떤 서버로도 전달될 수 있으나, 상태 정보가 필요할 경우 공유 저장소로부터 데이터를 가져온다. 따라서 상태정보는 웹 서버로부터 물리적으로 분리된다. 이 공유저장소는 RDB, 캐시시스템, NoSQL, 뭐든지 가능하다.

6. 데이터 센터

사용자가 매우 많아지면 가용성을 높이고 전 세계 어디서든 쾌적하게 사용할 수 있도록 여러 데이터센터를 지원하는 것이 필수적이다. 장애가 없는 경우 사용자는 지리적으로 가까운 데이터 센터로 안내되어, 이를 통상적으로 지리적 라우팅(geoDNS-routing 또는 geo-routing)이라고 부른다. 데이터 센터 중 한군데가 장애가 발생하면 모든 트래픽은 장애가 없는 데이터 센터로 전송된다. 이를 위해서는 1)트래픽 우회(지리적으로 가까운 데이터센터가 아니라, 올바른 데이터센터로 트래픽을 보내는 효과적인 방법을 찾아낸다.) 2)데이터 동기화(데이터 센터마다 별도의 DB를 사용하고 있으면, 장애가 자도으로 복구되어(failover) 트래픽이 다른 DB로 우회된다 해도, 해당 데이터센터에는 찾는 데이터가 없을 수 있으므로, 이를 위해 데이터를 여러 데이터센터에 걸쳐 다중화하도록 해야한다.), 3)테스트와 배포(여러 데이터센터를 사용하게 된다면 여러 위치에서 테스트해보는 것이 중요하다. 또한 자동화된 배포도구는 모든 데이터 센터에서 동일한 서비스가 설치되도록 하는데 중요한 역할을 한다.)

7. 메시지 큐

시스템을 더 크게 확장하기 위해서는, 시스템 컴포넌트를 분리하여 각기 독립적으로 확잩할 수 있게 한다. 이를 위해 메시지 큐를 사용한다. 이는 메시지 무손실(durability, 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼때까지 안전히 보관된다는 특성)을 보장하는 비동기 통신을 지원하는 컴포넌트다. 메시지의 버퍼 역할을 하여 비동기적으로 전송하는데, 생산자/발행자(입력서비스)가 메시지를 만들어 메시지 큐에 발행하면, 소비자/구독자(서비스/서버)가 메시지를 받아 그에 맞는 동작을 수행하도록 하는 것이다. 이를 이용하면 서비스/서버간 결합이 느슨해져서 규모 확장성이 보장되어야하는 안정적 애플리케이션 구성에 좋다. 생산자는 소비자 프로세스가 다운되어 있어도 메시지를 발행할 수 있고, 소비자는 생성자 서비스가 가용한 상태가 아니어도 메시지를 수신할 수 있게 되는 것이다. (ex. 이미지의 크로핑, 샤프닝, 블러링 등 지원하는 사진 보정 애플리케이션은 시간이 오래 걸릴 수 있는 프로세스이므로 비동기 처리가 편리하다. 웹 서버가 사진 보정 작업을 메시지 큐에 넣으면, 사진 보정 작업 프로세스들은 이 작업을 메시지 큐에서 보내서 비동기적으로 완료한다. 이러면 생산자, 소비자 서비스 규모는 각기 독립적으로 확장될 수 있다. 큐의 크기가 커지면 더 많은 처리기 프로세스를 추가해야 처리시간을 줄일 수 있으나. 큐가 거의 항상 비어있다면 처리기 프로세스의 수는 줄일 수 있다.)

8. 로그, 메트릭, 자동화

로그는 에러 로그를 모니터링하는 것이다. 서버 단위로 모니터링 할 수도 있으나, 단일 서비스로 모아주는 도구를 활용하면 더 편리하다. 메트릭은 사업 현황에 관한 유용한 정보를 얻고, 시스템의 현재 상태를 파악한다. 호스트 단위 메트릭은 CPU, 디스크 I/O. 종합 메트릭은 DB 계층 성능, 캐시 계층 성능. 핵심 비즈니스 메트릭은 일별 능동 사용나, 수익, 재방문 등이다. 자동화는 CI, CD 등을 말한다.

9. DB 규모 확장

저장할 데이터가 많아지면 DB 부하도 증가하여, DB 증설 방안을 찾아야된다. 먼저 수직적 확장은 기존 서버에 더 많은, 또는 고성능의 자원을 증설하는 것이나, DB 서버 하드웨어에는 한계가 있으므로 무한 증설할 수 없고, SPOF로 인한 위험성, 그리고 비용 문제가 발생한다.

수평적 확장은 샤딩(sharding)이라고도 부르는데, 더 많은 서버를 추가하여 성능을 향상시킬 수 있도록 한다. 이는 대규모 DB를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술으로, 모든 샤드는 같은 스키마를 쓰나 샤드에 보관되는 데이터 사이에는 중복이 없다. 샤딩 시 가장 중요한 것은 샤딩 키(파티션 키라고도 부른다.)를 정하는 것인데, 데이터가 어떻게 분산될지 정하는 하나 이상의 컬럼으로, 샤딩 키를 통해 올바른 DB에 질의를 보내 데이터 조회/변경을 처리하므로 데이터를 고르게 분할할 수 있도록 하는게 중요하다.

샤딩에서 풀어야할 문제들은 다음과 같다. 1)데이터의 재샤딩:데이터가 너무 많아져서 하나의 샤드로는 더 이상 감당하기 어렵거나, 샤드간 데이터 배포가 균등하지 못하여 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빨리 진행될때(샤드 소진이라고도 부름. 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치해야한다. 2)유명인사 문제:핫스팟 키(hotspot key)라고도 불리는 유명인사 문제(한 샤드에 유명인사가 집중되어 read 연산때문에 과부하 발생)가 발생시, 유명인사 각각에 샤드 하나씩을 할당하거나, 더 잘게 쪼개야할 수도 있다. 3)조인과 비정규화:하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면 여러 샤드에 걸친 데이터를 조인하기가 힘들어지므로, 이를위해 DB를 비정규화하여 하나의 테이블에서 질의가 수행될 수 있도록 한다.