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

1. 단일서버#

1.1. 단일서버란?#

• 웹, 앱, 데이터베이스, 캐시 등이 모두 한 대의 서버에서 실행되는 형태

1.2. 단일 서버의 사용자 요청 처리 흐름#

1. 사용자는 DNS를 통해서 웹사이트의 접속 정보를 받는다.
2. DNS 조회 결과로 IP주소가 반환된다.
3. 해당 IP 주소로 HTTP 요청이 전달된다.
4. 요청을 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답을 반환한다.

1.3. 요청 단말의 종류#

• 웹 어플리케이션

  • 비즈니스 로직, 데이터 저장 등을 처리하기 위한 서버 구현용 언어를 사용한다.
  • 프레젠테이션용으로는 클라이언트 구현용 언어를 사용한다.
• 모바일 앱

  • 모바일 앱과 웹 서버 간 통신을 하기 위해서는 HTTP 프로코톨을 이용한다.
  • HTTP 프로토콜을 통해 반환될 응답 데이터 포맷은 보통 JSON 포맷이 사용된다.

2. 데이터베이스#

2.1. 데이터 베이스의 분리#

• 웹/모바일 트래픽 처리 용도
• 데이터베이스 용도

2.2. 사용할 데이터베이스 선택#

2.2.1 관계형 데이터베이스#

• 관계형 데이터베이스는 관계형 데이터베이스 관리 시스템이라 부른다.

  • Relational Database Management System, RDBMS
• 가장 유명한 것으로는 MySQL, Oracle, PostgreSQL 등이 있다.
• 관계형 데이터베이스는 자료를 테이블과 열, 칼럼으로 표현하고, SQL을 사용해 여러 테이블에 있는 데이터를 관계에 따라 조인하여 합칠 수 있다.

2.2.2. 비-관계형 데이터베이스#

• 비 관계형 데이터베이스는 NoSQL이라고도 부른다.
• 대표적으로 CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB 등이 있다.
• 비 관계형 데이터베이스는 일반적으로 조인 연산은 지원하지 않는다.
• NoSQL은 다시 네 분류로 나눌 수 있다.

  • 키-값 저장소 (key-value store)
  • 그래프 저장소 (graph store)
  • 칼럼 저장소 (column store)
  • 문서 저장소 (document store)
• 비 관계형 데이터베이스가 바람직한 경우

  • 아주 낮은 응답시간(latency)이 요구되는 경우
  • 다른 데이터가 비정형(unstructured)이라 관계형 데이터가 아닌 경우
  • 데이터(JSON, YAML, XML 등)를 직렬화하거나 역직렬화 할 수 있기만 하면 되는 경우
  • 아주 많은 양의 데이터를 저장할 필요가 있는 경우

3. 수평적 규모 확장 vs 수직적 규모 확장#

3.1. 수평적 확장#

• 스케일 아웃(Scale out)이라고 불린다.
• 더 많은 서버를 추가해 성능을 개선하는 행위
• 수직적 확장의 단점 때문에 대규모 어플리케이션을 지원하는 데는 해당 방법이 적절하다.

3.2. 수직적 확장#

• 스케일 업(Scale up)이라고 불린다.
• 서버에 고사양 자원(추가적인 CPU, RAM 등)을 추가하는 행위
• 서버의 트래픽 양이 적을때는 수직적 확장이 좋은 선택이다.
• 해당 방법의 가장 큰 장점은 확장의 단순함에 있다.

3.2.1. 단점#

• 수직적 규모 확장에는 한계가 있다.

  • 서버 한 대에 무한대로 사양을 증설할 방법이 없다.
• 수직적 규모 확장법은 장애에 대한 자동복구(Failover) 방안이나 다중화 방안을 제시하지 않는다.

  • 장애가 발생하면 웹/앱 서비스가 모두 중단된다.

3.2. 로드밸런서#

• 서버가 한계 상황에 도달하게 되면 응답 속도가 느려지거나 접속이 불가능해질 수도 있다.
• 이런 문제를 해결하기 위한 방법으로 분산부하기인 로드밸런서를 도입하는것이 최선이다.
• 사용자는 로드밸런서로 접속하고 서버로 직접적으로 접속하지 않는다.

  • 더 나은 보안을 위해 서버 간 통신은 사설IP를 이용한다.
  • 서버1이 다운되면 모든 트래픽은 서버2로 전송된다.

    • 따라서 웹 사이트 전체가 다운되는 일이 방지된다.
    • 부하를 나누기 위해 새로운 서버를 추가할 수도 있다.

3.3. 데이터베이스 다중화#

• 일반적으로 나눠진 데이터베이스 다중화의 형태

  • 주(master)-부(slave) 관계를 설정해 원본은 주 서버, 사본은 부 서버에 저장한다.
  • 쓰기연산과 읽기연산의 부하 분산이라 말할 수 있다.
• DB 다중화를 하면 얻게되는 이점

  • 더 나은 성능 - 병렬 처리되는 읽기 연산이 늘어나 성능이 좋아진다.
  • 안정성 - 데이터를 여러 지역에 다중화 해놓으면 재해를 당해도 데이터를 보존할 수 있다.
  • 가용성 - 데이터를 여러 지역에 복제해두어 하나의 DB에서 장애가 발생해도 다른지역에서 가져올 수 있다.
• 주 서버가 죽으면?

  • 하나의 부 서버가 주 서버로 승급하여 쓰기 연산을 받기 시작한다.

3.4. 요약#

• 트래픽이 증가해서 더 많은 트래픽 처리를 위해 행할 수 있는 방식은 크게 수평적 확장과 수직적 확장이 존재한다.
• 일반적으로 애플리케이션 가용성을 위해서 수평적 확장을 더 선호한다.

  • 이는 웹서버뿐 아니라 데이터베이스 또한 동일하게 적용된다.
• 웹서버는 로드밸러스를 통해, 데이터베이스는 주-부 서버를 통해서 수평적 확장된다.

4. 캐시#

• 캐시는 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤 이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다.

4.1. 캐시 계층#

• 일반적으로 데이터베이스보다 비싸지만 훨씬 빠르다.
• 위 그림과 같이 캐시 히트된다면 캐시에서 없다면 데이터베이스에서 읽은 후 적제하는 방식을 읽기 주도형 캐시 전략이라 한다.

  • 이 외 캐시할 데이터 종류, 크기, 액세스 패턴에 맞게 다른 전략을 사용할 수 있다.

4.1.1. 캐시 사용시 유의점#

• 중요한 데이터는 영속성 저장소에 저장하도록 하자
• 데이터 갱신이 빈번하지 않다면 캐시를 고려할만 하다.
• 캐시 만료 정책을 잘 마련해두어야 한다.
• 원본과의 일괄성 유지 방법에 대해서 고민해보아야 한다.
• 캐시가 단일 장애 지점이 되어버릴 가능성이 있기 때문에 이에 대한 대책을 세워야 한다.
• 캐시가 꽉차면 어떤 데이터를 방출할 것인가?

5. 콘텐츠 전송 네트워크 (CDN)#

• CDN은 정적 콘텐츠를 전송하는 데 쓰이는 지리적으로 분산된 서버의 네트워크다.
• 이미지, CSS, JS, 비디오 등을 캐시할 수 있다.

• 위 그림처럼 CDN을 통해서 대용량 이미지나 비디오 HTML 등을 보다 빠르게 로딩할 수 있다.

  • 원본서버가 해저케이블을 통해서 나가야하는 위치에 있다면 상당히 오래 걸리고, 중간에 데이터가 유실될 가능성이 높다.
  • 이때 CDN을 사용하면 해당 지역에 가까운 CDN을 통하기 때문에 빠르고 안정성 높게 이용할 수 있다.

5.1. 이용시 주의사항#

• 비용 - 보통 서드파티 업체가 제공하기 때문에 전송량에 따라 가격이 책정되며 도입의 이점이 크지 않다면 빼도록 하자
• 적절한 만료 시한 설정 - CDN도 캐시기 때문에 원본과 괴리가 생길 수 있어 적절한 만료 시점이 필요하다.
• CDN 장애에 대한 Failover - CDN이 죽었을 경우 어떻게 응용 프로그램이 동작할지 고려해야한다.

6. 무상태(stateless) 웹 계층#

• 상태 정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관 후, 필요할 때 가져오도록 하는 구성을 무상태 웹 계층이라 부른다.

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

• 위 그림처럼 서버 간 상태정보가 공유되지 않고 독립적으로 가진 아키텍처가 상태정보 의존적인 아키텍처다.
• 이 경우 로드밸런서에서 Stiky Session 과 같은 기술로 특정 사용자가 마지막으로 접속한 서버에 지속적으로 연결 시켜줘야지 상태 정보를 잃어버리지 않는다.

  • 그런데 이러면 로드밸런서의 이점을 잃어버리게 된다.

6.2. 무상태 아키텍처#

• 해당 구조로 변경된다면 고정 세션이 될 필요없이 어떤 서버에서도 동일한 상태 정보에 접근할 수 있다.
• 해당 공유 저장소는 Redis와 같은 캐시일 수도 있고, NoSQL일 수도 있다.

  • NoSQL이 확장성이 좋아서 주로 쓰이는 편이다.

7. 데이터 센터#

• 두 개의 데이터 센터를 로드밸런서를 통해서 묶는 방식이다.
• 일반적으로는 가까운 데이터 센터로 안내하는 지리적 라우팅 방식을 사용한다.

  • 지리적 라우팅에서의 geoDNS는 사용자의 위치에 따라 도메인 이름을 어떤 IP주소로 변환할 지 결정할 수 있게 해주는 DNS서비스다.
• 만약 두 데이터 센터 중 하나가 재해나 장애가 발생할 경우 다른 쪽 데이터 센터가 모든 트래픽을 받도록 한다.

7.1. 해당 아키텍처의 기술적 난제#

• 데이터 동기화 문제

  • 데이터 센터마다 독립적인 데이터베이스를 사용하고 있다면, 장애가 해소되어도 다른 센터 내 데이터베이스와 괴리가 발생할 수 있다.
• 테스트와 배포

  • 어플리케이션을 다양한 위치에서 테스트 해보고 배포 도구를 통해서 일괄성있는 배포가 이뤄질 수 있도록 해야한다.

8. 메시지 큐#

• 메시지 큐는 무손실을 보정하는 비동기 통신을 지원하는 컴포넌트다.

  • 버퍼 역할을 하며 비동기 적으로 전송한다.

• 기본적 아키텍쳐는 간단한데 생산자가 메시지를 발행 소비자가 메시지를 구독 하는 방식으로 서비스가 느슨하게 연결되어 있다.

  • 생산자는 소비자의 상태와 무관하게 메시지를 발행할 수 있고, 소비자는 언제든지 메시지를 구독/해지 할 수 있다.

9. 로그, 메트릭 그리고 자동화#

• 소규모 웹 사이트를 만들 때는 로그나 메트릭, 자동화 같은 것을 하면 좋지만 꼭 할 필요는 업었다.
• 하지만 사업 규모가 커지고 나면, 그런 도구에 필수적으로 투자해야 한다.
• 로그 - 로그를 수집해 웹 사이트에서 발생하는 오류를 모니터링 해야한다.
• 메트릭 - 트래픽, 서버의 하드웨어적 상태, 가상 프로세서의 상태 등을 수집할 수 있으며 수집된 데이터는 유용하게 사용할 수 있다.
• 자동화 - 시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 활용해야 한다.

  • 코드 검증 절차의 자동화
  • 빌드, 테스트, 배포 등의 자동화

10. 데이터베이스의 규모 확장#

• 저장할 데이터가 많아지면 데이터베이스에 대한 부하도 증가한다.
• 이때 데이터베이스의 증설 방법을 찾아봐야한다.

10.1. 수직적 확장#

• 스케일 업이라고도 부르는 수직적 규모 확장법은 기존 서버에 더 많은, 또는 고성능의 자원을 증설하는 방법
• 증설에는 한계가 있으므로 CPU, RAM 등을 무한으로 증설할 수는 없다.
• SPOF로 인한 위험성이 크다.
• 비용이 많이 든다. 고성능 서버로 갈수록 가격이 올라가게 마련이다.

10.2. 수평적 확장#

• 데이터베이스의 수평적 확장은 샤딩이라고도 부르는데, 더 많은 서버를 추가함으로써 성능을 향상시킬 수 있도록 한다.
• 샤딩은 샤드라고 부르는 작은 단위로 분할하는 기술을 일컫는데, 모든 샤드는 같은 스키마를 쓰지만 샤드에 보관되는 데이터 사이에는 중복이 없다.

• 가장 단순하게 샤딩하는 방법으로써 해당 그림처럼 진행할 수 있다.
• 하나의 샤드는 각각 하드웨어적으로 독립되어 있어서 보다 빠르게 CURD를 할 수 있다.

10.2.1. 샤딩을 도입하면 풀어야할 문제#

• 데이터의 재 샤딩

  • 재 샤딩은 다음 경우에 필요하다.

    • 데이터가 너무 많아져서 하나의 샤드로는 더 이상 감당하기 어려울 때
    • 샤드 간 데이터 분포가 균등하지 못하여 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빨리 진행될 때
  • 샤드 소진이라고도 부르는 이런 현상이 발생하면 샤드 키 계산 함수를 변경하고 데이터를 재배치 하여야 한다.
• 유명인사(celebrity) 문제

  • 핫스팟 키 문제라고도 하는데, 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제다.
  • 이 문제를 풀려면 유명인사 각각에 샤드 하나씩을 할당해야 할 수도 있고, 심지어 더 잘게 쪼개야할 수 있다.
• 조인과 비 정규화

  • 일단 하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기 힘들어진다.
  • 데이터베이스를 비정규화 하여 하나의 테이블에서 질의가 수행되도록 한다.