사용자 수에 따른 규모 확장성
데이터베이스
•
•
NoSQL : RDBMS가 아닌 데이터베이스. Key-value, graph, column, document로 나눈다.
Scale up & scale out
•
Scale up : 성능을 좋게. 다만 성능 향상에는 한계가 있고, SPOF가 된다.
•
Scale out : 쪽수를 많게. 다만 트래픽을 여러 서버에 분산해줘야 한다.
로드밸런서(LB)
•
Load Balancing : 트래픽을 서버로 적절히 분산한다.
•
Forward proxy : 서버의 IP를 숨기고 LB의 IP만 노출한다. 반대 개념은 reversed porxy
데이터베이스 다중화
•
성능(performance) : 읽기 연산을 분산해서 처리하기 때문에 성능 증가
•
가용성(availability) : 장애가 생겨도 다른 DB로 대체 가능
•
안정성(reliability) : DB 하나가 훼손되어도 원본 유지 가능
캐시
서버가 DB에서 같은 값을 두 번 읽으면 낭비기 때문에 중간에 캐시를 둬서 DB 질의의 결과를 임시 저장한다. 서버는 질의할 때 캐시를 먼저 살피고 값이 없으면(miss) DB에서 가져온다. 이 캐시 전략을 읽기 주도형 캐시라고 부른다.
•
쓰기보다 읽기 연산이 많을 때 유리하다.
•
오래 저장되지 않을 자료에 유리하다.
•
적절한 시간이 지나면 값을 지워야 한다. 성능 문제(↓) vs 일관성 문제(↑)
•
캐시와 DB의 값이 동일하다는 것을 보장해야 한다. 일관성 문제
•
캐시를 한 대만 두면 SPOF가 되기 때문에 다중화해야 한다.
•
캐시 크기를 정해야 한다. 너무 작으면 값이 자주 방출돼서 성능이 떨어진다.
•
콘텐츠 전송 네트워크(CDN)
정적 콘텐츠를 지리적으로 분산된 서버에 저장해놓고 가장 가까운 서버에서 값을 가져오는 방식이다. 탱커랄까
•
돈 걱정 : 트래픽에 따라 돈을 내기 때문에 꼭 필요한 것만
•
장애 대처 : CDN이 죽으면…?
•
만료 시한 설정 : 캐시랑 똑같이 적절할 때 갱신해야 한다.
•
무효화 : 아직 만료 안되었는데 강제로 만료시키기
◦
CDN 서비스 사업자가 제공하는 API
◦
같은 콘텐츠라도 버전을 바꾼다.
무상태 웹 계층
로드밸런싱이 만든 작은 문제, 서버는 A,B가 있다.
1.
A 서버에서 장바구니에 물건을 하나 담았다.
2.
그런 다음 B 서버에서 다른 상품도 담았는데
3.
A 서버에서 담은 물건이 장바구니에 없다…!
4.
왜냐하면 A 서버와 B 서버는 서로 소통을 안하기 때문
이에 대한 해결책은 크게 두 가지가 있다.
•
Sticky session : A, B 서버 왔다갔다 하지 말고 유저 한 명은 한 서버가 전담하도록 한다. LB에 무리간다.
•
공유 저장소 : A, B 서버가 모두 참조할 수 있는 아주 가벼운 데이터베이스를 둔다. 여기다가 장바구니 물건을 담아둔다.
공유 저장소는 빨라야 하기 때문에 NoSQL로 주로 만든다.
데이터 센터
내 서버가 있는 서울에 지진이 나면?? 서비스가 안된다. 이 문제를 해결하기 위해서 도쿄에도 같은 서비스를 운영한다. 그러면 한 쪽이 멈춰도(failover) 다른 한 군데에서 서비스를 하면 되기 때문에 안전하다.
•
트래픽 우회 : 적절하게 트래픽을 보내야 한다. (GeoDNS)
•
데이터 동기화 : 서울에 있는 DB가 멈추면 데이터 복구가 안된다.
•
배포 : 배포를 할 때 서울과 도쿄가 동일한 어플리케이션을 설치하도록 해야 한다.
메시지 큐
메시지 큐는 메시지의 무손실을 보장하는 비동기 통신 컴포넌트이다. 생산자와 소비자를 분리해서 확장하기도 좋고 안정적이게 된다.
로그, 메트릭 그리고 자동화
•
로그 : 여러 서버의 에러 로그를 한군데 모으면 검색, 조회가 좋다.
•
메트릭 : 사업에 대한 인사이트를 얻고, 시스템의 현재 상태를 파악한다.
◦
호스트 단위 메트릭 : CPU, 메모리, 디스크 I/O
◦
종합 메트릭 : DB 계층의 성능, 캐시 계층의 성능
◦
핵심 비즈니스 메트릭 : 일일 능동 사용자(DAU), 수익, 재방문
•
자동화 : 빌드, 테스트 배포 등의 절차를 자동화한다. CI/CD
데이터베이스의 규모 확장
수직적 확장
서버 성능을 키운다. 서버 하드웨어에는 한계가 있고 SPOF의 위험이 있다. 또 비싸다.
수평적 확장
서버를 늘린다. 대규모 데이터베이스를 샤드(shard)로 나누고 데이터를 여러 대의 서버에 분산해서 저장한다. 어느 서버에 넣을지는 각 데이터의 샤딩 키(혹은 파티션 키)를 통해 결정한다.
•
재샤딩 : 한 샤드가 다른 샤드들에 비해 빨리 소진되면서 감당하기 어려울 때, 샤딩 키를 다시 분배해서 저장해야 하는 문제가 발생한다.
•
셀럽 문제 : 특정 샤드에 질의가 집중돼서 과부화가 걸리는 문제
•
조인과 비정규화 : 조인이 힘들기 때문에 비정규화를 수행할 수 밖에 없다.