💋 인트로
이번 포스팅에서는 몇백만 사용자를 지원하는 시스템에서 규모 확장성과 관련된 설계 문제들을 정리해볼 것이다.
해당 내용은 가상 면접 사례로 배우는 대규모 시스템 설계 기초를 읽고 정리한 내용이다.
단일 서버에서 모든 트래픽 처리와 데이터베이스를 겸용하는 설계에서 시작한다.
이후에 하나씩 인프라를 개선해나가는 절차를 보여줄 것이다.
💋 단일 서버일 때
- 사용자는 DNS 서버를 통해서 접속하고자 하는 도메인 이름을 IP 주소로 변환해 웹 서버의 주소를 알아낸다.
- 해당 IP 주소로 요청을 보내고 응답을 받음.
💋 데이터베이스 서버와 트래픽 처리 서버를 분리한다
- 웹/모바일 트래픽 처리 서버(웹 계층), 데이터베이스 서버(데이터 계층)를 분리한다.
- 각각 독립적으로 확장해나갈 수 있게 된다.
✔ 어떤 데이터베이스 서버를 사용할까?
- 관계형 데이터베이스
- 전통적인 데이터베이스
- 자료를 테이블, 열, 칼럼으로 표현
- 여러 테이블의 데이터를 관계에 따라서 join 할 수 있음.
- 명확하게 정의된 스키마로 데이터 무결성을 보장함.
- 덜 유연해서, 데이터 스키마를 사전에 계획해야 함.
- 대부분의 경우에 사용하게 될 것임.
- 예) MySQL, 오라클, PostgreSQL 등
- 비관계형 데이터베이스
- NoSQL이라고도 부름
- 일반적으로 join 연산을 지원하지 않음.
- key-value, graph, column, document store의 4가지 저장 방식으로 크게 분류할 수 있음.
- 예) CouchDB, Neo4j, Cassandr, MongoDB 등
- 자주 사용되지는 않지만, 아래와 같은 경우에 고려해볼 수 있음.
- 아주 낮은 응답 지연시간이 요구될 때
- 다루는 데이터가 비정형이라 관계형이 아닐 때
- 데이터를 직렬화하거나 역직렬화할 수 있기만 하면 될 때
- 아주 많은 데이터를 저장해야 할 때
- 정확한 데이터 구조를 알 수 없거나 변경/확장 될 수 있을 때
- 읽기를 자주 하지만, 데이터 변경은 자주 없을 때
- 데이터베이스를 수평으로 확장해야 할 때(막대한 양의 데이터를 다뤄야 하는 경우)
참고: https://gyoogle.dev/blog/computer-science/data-base/SQL%20&%20NOSQL.html
💋 수직적 규모 확장 VS 수평적 규모 확장
- 수직적 규모 확장
- scale up
- 프로세스 서버에 고사양 자원(CPU, RAM)을 추가해 성능 개선
- 한 대의 서버에 무제한으로 CPU, 메모리를 증설할 수 없어 한계가 존재함.
- 한 대의 서버에 장애가 발생하면 웹 사이트가 완전히 중단되어 장애에 대한 자동 복구, 다중화 불가
- 수평적 규모 확장
- scale out
- 더 많은 서버를 추가해 성능 개선
- 대규모 애플리케이션을 지원하는데 적합함.
우리는 위에서 학습한 수평적 규모 확장을 적용하기 위해 아래의 두 가지 방법을 도입할 것이다.
수평적 규모 확장의 궁극적인 목표는 장애 발생 시 다른 서버로 트래픽을 전송해 장애를 자동으로 복구해 사용자가 서버 장애를 경험하지 않도록 하는 것이다.
아래에서 설명할 로드 밸런서는 네트워크 트래픽을 분산시켜 서버의 성능을 향상시키고,
데이터베이스 다중화는 데이터베이스의 가용성과 내결함성을 강화하여 데이터의 안정성을 높이는 역할을 한다 .
✔ 로드 밸런서(Load Balancer)
웹 서버에 네트워크 트래픽을 고르게 분산시켜 서버의 성능을 향상
사용자를 실제 웹 서버의 IP 주소로 바로 연결하는 경우에, 아래와 같은 단점이 존재한다.
- 해당 IP의 웹 서버가 다운되면 사용자는 웹사이트에 접속할 수 없다.
- 너무 많은 사용자가 접속해 웹 서버가 한계에 도달하면 응답 속도가 느려지거나, 서버 접속이 불가능해질 수 있다.
위의 문제점을 해결하기 위해서 로드 밸런서를 도입할 수 있다.
로드 밸런서는 웹 서버들에게 트래픽 부하를 고르게 분산한다.
- 클라이언트는 로드 밸런서의 공개 IP 주소로 접속
- 웹서버가 클라이언트 접속을 직접 처리하지 않음.
- 서버 간 통신에는 사설 IP 주소를 이용해, 보안이 강화됨.
- 로드 밸런서에 연결된 서버의 개수를 늘리면, 장애 자동 복구 문제를 해결할 수 있고, 웹 계층의 가용성이 향상됨.
- 하나의 서버가 다운되면, 다른 서버로 트래픽을 전송함.
- 트래픽이 가파르게 증가하면, 서버를 더 추가하면 로드밸런서가 자동으로 트래픽을 분산함.
✔ 데이터베이스 다중화
데이터베이스의 가용성과 내결함성을 강화하여 데이터의 안정성 향상
- 많은 데이터베이스 관리 시스템에서 다중화를 지원함.
- 보통은 서버 사이에 master-slave 관계를 설정해서 데이터 원본은 master 서버(주 버서)에, 사본은 slave 서버(부 서버)에 저장하는 방식
- 쓰기 연산(INSERT, DELETE, UPDATE)은 master 서버에서만 지원하고, 그 사본을 slave 서버로 전송함
- slave 서버는 읽기 연산(SELECT)만을 지원
- 데이터 변경 연산은 주 서버로, 읽기 연산은 부 서버로 분산해 쿼리를 병렬로 처리할 수 있어 성능 향상
- 일부 데이터베이스 서버가 불타서 사라지더라도, 여러 지역에 데이터베이스를 떨어뜨려 다중화할 수 있어서 안정성 향상
- 데이터가 여러 지역에 복제되어 있어, 하나의 서버에 장애가 발생하면 다른 서버의 데이터를 가져와 서비스할 수 있어 가용성 향상
데이터베이스 서버 중 한 대가 다운된 경우에, 어떤 일이 벌어질까?
- 부 서버가 다운된 경우
- 부 서버가 1대인 경우
- 일시적으로 모든 읽기 연산을 주 서버가 담당
- 주 서버의 내용을 복사해 새로운 부 서버 생성
- 부 서버가 여러 대인 경우
- 읽기 연산은 나머지 부 서버로 분산
- 새로운 부 서버를 생성해 장애 서버 대체
- 부 서버가 1대인 경우
- 주 서버가 다운된 경우
- 부 서버가 1대인 경우
- 해당 부 서버가 새로운 주 서버가 되며, 일시적으로 모든 데이터베이스 연산 수행
- 새로운 부 서버 추가
- 가능한 문제 상황
- 부 서버에 보관된 데이터베이스가 최신이 아닐 수 있음.
- 복구 스크립트, 다중 마스터, 원형 다중화 (공부해볼 키워드)
- 부 서버에 보관된 데이터베이스가 최신이 아닐 수 있음.
- 부 서버가 1대인 경우
✔ 수평적 규모 확장 적용 후 인프라의 모습
- 사용자는 공개 IP 주소를 통해 로드 밸런서에 접속
- 로드 밸런서가 적절히 트래픽을 분산해 실제 웹 서버로 요청 전달
- 웹 서버는 데이터를 부 데이터베이스에서 읽고, 변경 연산은 주 데이터베이스로 전달
💋 참고자료
- 책) 가상면접 사례로 배우는 대규모 시스템 설계 기초
- https://velog.io/@haron/%EA%B0%80%EC%83%81-%EB%A9%B4%EC%A0%91-%EC%82%AC%EB%A1%80%EB%A1%9C-%EB%B0%B0%EC%9A%B0%EB%8A%94-%EB%8C%80%EA%B7%9C%EB%AA%A8-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EC%84%A4%EA%B3%84-%EA%B8%B0%EC%B4%88-1%EC%9E%A5-%EC%82%AC%EC%9A%A9%EC%9E%90-%EC%88%98%EC%97%90-%EB%94%B0%EB%A5%B8-%EA%B7%9C%EB%AA%A8-%ED%99%95%EC%9E%A5%EC%84%B1
- https://gyoogle.dev/blog/computer-science/data-base/SQL%20&%20NOSQL.html
- https://m.post.naver.com/viewer/postView.naver?volumeNo=27046347&memberNo=2521903
'DevOps > 대규모 시스템 설계' 카테고리의 다른 글
| [대규모 시스템 설계] 사용자 수에 따른 규모 확장성(2): 응답 시간 개선을 위한 캐시, 컨텐츠 전송 네트워크(CDN) 도입 (0) | 2023.08.25 |
|---|
