단일서버
: 모든 컴포넌트가 단 한 대의 서버에서 실행되는 간단한 시스템
•
이런 느낌?
: 이때 하나의 웹 서버가 모든 클라이언트의 요청을 담당하게 됨, 이때 사용자의 요청 처리 흐름은 어떻게 될까?
1.
클라이언트는 DNS에 도메인 네임으로 IP를 질의
2.
클라이언트는 DNS 조회 결과로 IP를 받아 해당 주소로 프로토콜을 사용해 요청을 보냄
3.
웹 서버는 클라이언트에게 HTML 웹 페이지를 전달
데이터베이스
: 사용자가 늘면 단일 서버로는 자원이 부족해지므로 서버와 데이터베이스를 분리
: 분리하였으므로 각각의 요소들은 영향을 받지 않고 확장이 가능해짐
•
이런 느낌?
어떤 데이터베이스를 사용할 것인가
•
관계형 vs 비관계형
◦
관계형
: 관계형 데이터베이스는 MySQL, Oracle, PostgreSQL 등, 데이터를 테이블, 열, 컬럼으로 표현, SQL을 이용해 테이블의 관계에 따라 데이터를 조인할 수 있음
◦
비관계형
: 비관계형 데이터베이스는 흔히 NoSQL로 불리며 MongoDB, Amazon DynamoDB 등, NoSQL은 키-값 저장소, 그래프 저장소, 칼럼, 문서 저장소 등으로 분류됨
•
Redis와 ElasticSearch를 사용해봤으니 키-값 저장소와 문서 저장소를 사용해봄!
: 일반적으로 관계형 데이터베이스를 사용하는 것이 최선, 그렇다면 어느 경우에 비관계형 데이터베이스를 사용해야할까?
◦
아주 낮은 응답 지연시간이 요구될 때 → 캐싱..?
◦
다루는 데이터가 비정형이라서 관계형 데이터가 아닐 때 → 스키마리스?
◦
데이터를 직렬화하거나 역직렬화만 하면 될 때 → ElasticSearch?
◦
아주 많은 양의 데이터를 저장할 필요가 있을 때 → 텍스트..
수직적 규모 확장 vs 수평적 규모 확장
: 일반적으로 수직적 규모 확장은 서버의 스펙을 향상시키는 것, 수평적 규모 확장은 더 많은 서버를 추가하여 성능을 개선하는 행위, 확장의 방향이 다르다. 위로 가느냐 퍼져 나가느냐
•
수직적 규모 확장
: 일반적으로 트래픽이 적을 경우, 좋은 선택, 다만 이론적으로 처리할 수 있는 트래픽에 한계가 있고 자동복구나 다중화 방안이 제시되지 않음
•
수평적 규모 확장
: 장애에 대한 자동복구나 다중화 방안을 제시, 대규모 애플리케이션에서 더 적절한 확장법
: 단일서버의 경우, 통상적으로 클라이언트가 직접 서버에 질의를 날림 → 트래픽이 많아질 경우 응답속도 지연, 접속 불가 등의 현상이 발생 → 로드 밸런서를 사용!
로드밸런서
: 로드밸런서는 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산해주는 요소, 사용자는 웹서버 대신 로드밸런서의 공개 IP 주소로 접속
: 이렇게 부하 분산 집합에 웹 서버를 하나 더 추가하게 되면 자동 복구하지 못하는 문제가 해소되고, 웹 계층의 가용성은 향상, 하나의 서버가 죽어도 다른 서버가 그 역할을 대신
: 이로써 웹 계층은 어느정도 개선됐는데, 데이터베이스 서버는 아직 하나이다. 자동 복구나 다중화를 지원하지 않는다. 데이터베이스 다중화는 이런 문제를 해결한다.
데이터베이스 다중화
: 단일 데이터베이스는 자동 복구나 다중화를 지원하지 않음, 다중 데이터베이스는 이를 해결하기에 적절한 방법
: Master - Slave 관계를 설정하고 데이터의 원본은 Master에 사본은 Slave에 저장, 쓰기 연산은 Master 서버에서만 일어나고 Slave 서버는 Master 서버로부터 사본을 전달받아 읽기 연산만을 담당
: 통상적으로 CUD의 연산보다 R의 연산이 더 빈번하므로 Master보다 Slave의 수가 더 많음
⇒ 간단하게 생각하면 데이터 동기화 문제가 발생할 것 같은데 어떡하지?
⇒ ElasticSearch에선 Replica로 데이터 안정성을 보장했던 것 같은데..
•
데이터베이스 다중화로 얻는 이점
1.
더 나은 성능
: 모든 쓰기 연산은 Master가 읽기 연산은 다수의 Slave가 담당하므로 단순하게 생각해서 트래픽이 나눠진다..! 그러므로 성능이 향상!
2.
안정성
: 자연 재해등으로 서버의 일부가 파괴되어도 데이터가 보존됨, 지리적으로 떨어져 있는 곳으로 서버를 다중화시킬 수 있기 때문
3.
가용성
: 데이터를 여러 지역에 복제하여 저장하므로 하나의 데이터베이스 서버가 뻗어도 다른 데이터베이스 서버가 그 역할을 대신
•
데이터베이스 다중화는 다음과 같은 상황에 대처가 가능
◦
하나뿐인 Slave 서버가 다운 → Master 서버가 일시적으로 읽기 연산까지 담당
◦
두 개 이상의 Slave 서버 중 하나의 서버가 다운 → 다른 Slave 서버가 담당
◦
Master 서버가 다운 → Slave 서버가 단일이든 다중이든 한 대의 Slave 서버가 Master 서버가 되어 쓰기 연산을 담당
•
더 생각해볼 부분
◦
어? 이거 완전 CQRS 패턴?
캐시
•
캐시 계층
◦
캐시 계층을 두어 빠른 반환
◦
read-through caching strategy
•
캐시 사용 시 유의할 점
◦
캐시메모리 사이징
◦
단일서버일 경우 단일 장애 지점이 될 확률
•
콘텐츠 전송 네트워크
◦
CDN 사용 시 고려해야 할 사항
▪
캐시의 일종으로 인식해도 될듯함
•
무상태 웹 계층
◦
상태 정보 의존적인 아키텍처
◦
무상태 아키텍처
•
데이터 센터
•
메시지 큐
•
로그, 메트릭 그리고 자동화
◦
메시지 큐, 로그, 메트릭, 자동화 등을 반영하여 수정한 설계안
▪
메시지 큐는 느슨한 결합을 지원
•
데이터베이스의 규모 확장
◦
수직적 확장
◦
수평적 확장
•
백만 사용자, 그리고 그 이상
