읽을때 마다 새로운 지식을 알게되는 책이지만, 다음 챕터로 넘어 갈수록 너무 어려워져 손이가지 않는 책이다.
하지만 좋은 내용이 많아서 최대한 많이 이해하고 싶어서, 완독을 목표로 글을 작성하게 되었다.
잘근잘근 씹어먹듯, 많은 지식을 남길 수 있도록 열심히 정리해보려 한다.
책구매 링크!
가상 면접 사례로 배우는 대규모 시스템 설계 기초 - 예스24
사용자 수에 따른 규모 확장성
단일서버
→ 모든 컴포넌트가 단 한대의 서버에서 실행되는 간단한 시스템
가장 기초적인 구조이다. 사용자 단말로부터 도메인을 DNS 로 변환된 IP로 웹서버에 연결되어 해당 웹서버에서 제공해주고 있는 페이지를 호출한다.
데이터 베이스
→ 사용자가 늘면 여러서버로 분리해 안정성을 늘린다.
하나는 웹/모바일 트래픽 처리 용도고, 하나는 데이터베이스 용이다.
어떤 데이터 베이스를 사용할것인가도 중요한데 선택지에 따라서 잘 구별해서 사용할수 있어야한다.
40년 이상 잘 살아남은 RDBMS - 관계형 데이터 베이스 관리시스템
Oracle, Mysql, postgreSql 등
신흥 강자인 NoSQL - 비 관계형 데이터 베이스
mongoDB, Cassandra, CouchDB, Amazon DynamoDB 등
대부분은 관계형 DB 가 적합하나, 특정 케이스에서는 비-관계형 데이터 베이스가 적합한경우도 있다.
비-관계형과 관련된 자세한건 나중에 추가 설명하기로 하고, 우선 관련링크로 정리한다.
https://aws.amazon.com/ko/nosql/
수직적 규모확장 vs 수평적 규모확장
이제 DB를 추가하여 조금 살만해졌더니, 사용자가 늘어나 응답속도가 느려지거나 서버에 접속이 불가능하게 되어버렸다면 어떤방법으로 해당 이슈를 해결해아할까?
수직적 규모 확장 (Scale Up)
해당 프로세스는 서버에 고사양 자원을 (CPU, RAM 등) 추가하는 방식으로 적용된다.
수평적 규모 확장 (Scale Out)
해당 프로세스는 더 많은 서버를 추가하여 성능을 개선하는 방식으로 적용된다.
수직적 규모확장은 장애 대한 자동복구 방안이나 다중화 방안을 제시하지 않는다. 그럼 수평적 규모확장을 하기위해 웹서버와 사용자 사이에서 부하를 분산해주는 로드 밸런스를 도입하여 적용할 수 있다.
로드 밸런서 도입하기
→ 로드 밸런서는 웹서버에게 부하가 고르게 전달될 수 있도록 작동한다.
외부 공개 IP 로 로드 밸런스로 접근하고, 웹서버는 바로 접근되지 않고 사설 IP 주소로 로드 밸런서와 연결된다. 서버간 통신에서는 사설 IP 주소를 이용한다.
해당하는 방식으로 웹사이트에 유입되는 트래픽이 증가하면 웹서버를 증가시키고 로드 밸런스에 연결하면 자동적으로 트래픽을 분산하기 시작할것이다.
데이터베이스 다중화
보통은 서버 사이에 주-부 관계를 설정하고 데이터 원본은 주서버에, 사본은 부 서버에 저장하는 방식이다.
주 DB 에서만 쓰기연산을 지원하고, 부 DB 는 사본을 주 DB 에서 전달받으며 캐시
각각 주, 부 DB 가 죽었을때 각각의 서비스가 역할을 대체하는 방식으로 데이터를 처리하게 된다.
웹계층과 데이터 계층과 관련되어 충분하게 이해하게 되었으니 응답시간을 개선해보자. 캐시를 붙히고 정적 콘텐츠를 콘텐츠 전송 네트워크 (CDN) 으로 옮기면 개선할수 있다.
캐시 추가
→ 연산 결과나, 자주 참조되는 데이터를 메모리 안에 두고 빠르게 처리될 수 있도록 하는 저장소다.
캐시 계층
- 데이터가 잠시 보관되는곳으로 빠르다.
- DB 부하를 줄일 수 있고, 계층 규모를 독립적으로 확장도 가능하다.
관련하여 캐시를 설정할수 있는 정책 정보가 있는데, 해당부분은 추후 정리하도록 하겠다.
캐시 사용시 유의점
- 휘발성 메모리이므로, 데이터가 영속성이 없다.
- 데이터가 만료되는 정책을 잘 설정해야한다.
- 여러 저장소에 저장될때, 일관성은 어떻게 유지 되어야할지 등 세부 항목을 잘 설정해서 사용해야한다.
이어지는 확장과 관련된 나머지 부분도 있는데, 너무 길어져 다음 글로 이어서 정리할게요!
