카테고리 없음

대용량 트래픽 설계 김순철 튜터님

sooyeoneo 2024. 12. 24. 23:11

인류 역사상 가장 신뢰도가 높은 시스템 DataBase

2020년 알리의 10억건 이상의 결제

피크 기준 초당 175000건 이상 주문이 이루어짐.

3000건만 넘어도 대용량 트래픽으로 모니터링…

 

데이터 그래프 실시간 갱신 - 주식, 코인 차트

 

옛날에는 페이지가 브라우저에 로딩되면 HTML 코드가 변경되지 않는데 요새는 실시간 변함 ㅋㅋ

DBMS 가장 핵심 목적은 데이터 손실 없이 잘 저장하는 것.
신뢰도 높게 잘 저장하는것이 목적
캐싱, 인덱스 등등의 방법을 제공하지만 다른 방법이 필요하다

 

그래서 대용량 트래픽 설계를 해야한다.

DB의 용량을 덜어주는 방법으로

단일 서버 아키텍쳐 

 

 

 

대부분의 서비스를 이렇게 시작함.

Server에 CPU 용량 증가 이런식으로 하다보면 한계가 옴.

 

대표적인 4가지 방법

 

  1. 로드 밸런싱 : 1대 이상의 서버를 띄우고 요청을 분산 처리
  2. 캐싱 : 자주 요청되는 내용을 캐싱 또는 캐싱 서버를 이용하여 처리
  3. DB의 읽기/쓰기
  4. CDN 적용 : 외부의 캐싱 서버 / 대표적 역할로 페이지 레벨의 캐싱 또는 JS나 CSS 같은 리소스 레벨의 캐싱 - 클라우드플레어(사람인지 아닌지.. 체크하는)

 

 

로드 밸런싱 - 데이터 게이트

 

 

  1. 라운드 로빈 : 요청을 순서대로 분배 - 많이 들어오고 요청이 동일하면 이 방법이 좋음
  2. 가중치 라운드 로빈 : 더 좋은 서버가 가중치가 높고, 가중치가 높은 서버에 더 많은 요청을 보냄 - 어떤 작업은 큰작업 어떤 작업은 작으면 고려?
  3. 최소 연결 : 현재 연결된 요청이 가장 적은 서버에 새 요청을 보냄 - 로드밸런서가 각 서버가 요청을 얼마나 들고있는지 계속 모니터링해야함… 단점 / 일을 제일 안하는 IDLE인 상태에게 보내면서 성능이 높아짐.. 장점

 

이 분야는 서버 인프락쳐의 영역이라 우리가 다루는 일이 별로 없음

 

MSA 를 다루는 대용량 트래픽은 담당팀이 따로 있어서 

개념만 알아두자

 

환율은 분산캐시로 DB요청을 대신 처리하여 DB로 몰리는 트래픽을 처리… DATABASE로 바로 안가고 Redis로 바로바로 함…

주로 읽기 트래픽 분산, 임시 데이터 저장, 세션 관리, API 응답 캐싱(영화 정보같은) 등의 용도로 사용 Redis가 메모리 기반이라 DB보다 빠름

 

 

로컬 캐시는 애플리케이션 레벨(스프링 부트)에서 계산된 결과를 캐싱하여 성능 최적화

 

헤이즐 캐싱

m캐싱?

 

환율은 하루 한 번만 업데이트 되는 값이라 매번 외부에서 불러올 필요 없다

로컬 캐시에 저장해두고 빠르게 불러와 사용

 

데이터베이스 캐시는 DBMS 자체가 가지고 있는 캐시

데이터 페이스 캐시, 인덱스가 있음.. (쿼리 캐시 없어졌다…)

 

데이터 페이지 캐시는 자주 사용되는 데이터는 디스크I/O 최소화를 위해 데이터 페이지와 인덱스를 메모리에 캐싱하는 것.

 

쿼리 캐시 삭제

 

MySQL 8.0 에 쿼리캐시가 삭제되었음

쿼리 캐시는 동일한 쿼리 인입되면 캐싱해두었던 결과를 바로 응답하는 것을 말한다.

 

데이터가 변경되면 저장된 캐시에서 변경된 테이블과 관련된 것들을 모두 삭제하고 이 부분은 엄청난 성능 저하를 유발…

 

돌려봤더니 성능이 생각보다…

캐싱을 쓰는건 있는 거 그냥 가져다 쓰려고 있는건데

계속 지우고 다시 만들고 하는 과정이 생각보다 많아서 성능 떨어짐 캐싱 쓰는 이유가…;;;

 

 

DB 읽기/쓰기 분리

 

DB에서 대부분은 쓰기보다 읽기 작업이 많다

두 작업을 서로 다른 DB나 DB인스턴스로 분리하여 최적화하는 것

쓰기는 마스터 읽기는 슬레이브로 분리 처리

 

 

 

 

캐시를 적용할 때 쓰기가 잦은 데이터는 캐싱 불가

읽기/쓰기 분리하면 읽기에 캐실르 적용하기 쉬워서 이 방식은 대용량 트래픽 대응시 거의 필수 적용

 

CDN

 

15:30~15:45 유실 ㅠㅠ

 

아래 부분 부터 다시 필기… 읽기와 쓰기를 기준으로 분리

 

 

UPDATE, DELETE 할때가 문제다.. 

쓰기

 

ADMIN인 친구를 다 일반 USER로 강등시켜!

주 데이터베이스 서버에 UPDATE setUser().Type 어쩌구

 

넷플릭스 예시

마스터에 슬레이브 ???

………??????

 

 샤딩

데이터 특정 기분에 따라 분할하여 여러 DB에 분산 저장하는 것

 

 

 

 

 

나눠놓는 것끼리 비슷비슷… 

회원 정보 저장시 10대 / 20대 / 30대 분산 저장

 

전체 데이터의 분포도가 일정한 경우에 고려할 방법

 

이론상으로는 존재하지만 실제로 쓸 일이 없음…

이쁘게 나뉘는 데이터가 있으려나 어쩌구.. 

 

 

DB 다중화의 문제

  1. 복제 지연 - 토스에 10만원 입금했는데 10만원이 안보여?? 읽기가 늦어지고 있음 …
    DB 다중화는 DB가 여러개 존재하고 서로 하나와 같이 움직여야한다. Master가 변경되면 나머지 Slave들이 Master의 변경사항을 자신에게 적용… 복제(Replication)이라고 함 복제는 어떤 방식이라도 지연이 발생.. 지연 때문에 특정 노드가 최신 데이터를 갖지못함
  2. 동기화 성능 저하 (동기화 성능 늦어지면 복제지연 당연히 생김)
    Master 변경된 데이터를 Slave로 복제하는 것은 자원 소비하는 일임. Master에서 Slave로 복제할 때도 각 서버의 리소스를 사용. 이 때문에 Master의 쓰기 작업 성능이 저하됨
    EX) 상품의 재고가 1개 남았는데.. 복제 지연 나서 0개인데.. 업데이트가 안되서 주문 계속 진입… 난리난리 빨리 내놔…
  3. 데이터 불일치
    Master - Slave 간 복제가 완료되기 전에 장애가 발생하는 경우 데이터 불일치가 발생… 데이터를 신뢰할 수 없는 상황
  4. 비용 증가
    여러 대의 DB를 운영해야해서 비용 증가

 

기타

메시징 서비스 부분 다시 듣기

 

  • 메시징 서비스 : Kafka 카프카, RabbitMq 래빗엠큐, Redis Pub/Sub 레디스 펍/섭
    카프카 많이 쓰지만 무조건 답은 아니다.

 

  • MSA 도입

 

  • 오토 스케일링 : 설정한 수치를 넘어서면 자동으로 서버를 추가(스케일 아웃)

 

50이 들어오고 있었는데, 500이 들어가면?

 

CPU 사용량이 60%올라간다 - 서버를 하나 추가해라 - 오토스케일링

 

70% 넘어가면 자동으로 스프링 애플리케이션이 또 뜸… 스케일 아웃

 

 

 

 

 

 

 

Scale UP : GB 용량이 증가하면서 스팩이 높아짐…

반대는 Scale DOWN 해서 스팩을 줄임

정리…

로드 밸런싱, 캐싱, DB 다중화, 샤딩, CDN, MSA, 메시징 서비스

 

 

카프카 이전의 링크드인.. 아키텍쳐 

코드로 파악하기가 매우매우 어려움….ㅠㅠ

 

 

답변 다시 듣기…

 

Q. 분리된 DB 환경에서 만약 기존 쓰기 DB인 master DB에서 오류가 발생되서 DB가 정상 동작되지 않으면 어떻게 처리하나요?

 

A. master가 죽는 경우 slave 중 하나를 master로 승격 시켜 대응하도록 구성할 수  있습니다.

 

 

 

 

 

 

 

 

ＴＩＬ 12월 24일