skarltjr
commented
2 years ago 챕터 1. 서비스 규모 확장
수직적 규모확장 vs 수평적 규모 확장
수직적 규모 확장 / scale up
- 말 그대로 서버의 성능을 증가시키는 것
- 트래픽의 양이 적을 때 좋으며 특히 단순함이 가장 큰 장점
- ★그러나 수직전 확장에는 한계가 존재
- 성능 증가는 한계가 존재하며 서버에 장애가 발생하면 서비스가 완전히 중단된다.
수평적 규모 확장
- 대규모 서비스는 위와같은 이유로 수평적 규모확장이 효율적로드밸런서
- 수평적 규모 확장을 어떻게 이뤄내는지 확인해보자
로드밸런서는 트래픽을 여러 서버에 분산시킨다. 만약 하나의 서버가 다운돼도 다른 서버로 트래픽을 전달하고 그 동안 고장난 서버를 복구시킬 수 있다.
데이터베이스 다중화
- 서버로 전달되는 트래픽은 로드밸런서를 통해 분산
- 그러나 각 서버와 연결된 데이터베이스는 하나라면?
- 데이터베이스에서 병목이 발생할것
대부분의 서비스에서 읽기가 많이 발생할까? 아니면 쓰기가 많이 발생할까? 거의 모든 서비스에서 읽기가 더 많이 발생할것이고 이것이 핵심이다 주 데이터베이스와 / 여러개의 부 데이터베이스를 활용한다
쓰기 -> 주 데이터베이스 -> N개의 부 데이터베이스 <- 읽기 <- 유저
쓰기(write update delete )는 주 데이터베이스에서만 가능하도록하여 수행하고 원본은 이곳에 저장 읽기는 부 데이터베이스에서 수행하며 주 데이터베이스에 쓰여진 원본의. 사본을 전달받아 저장 후 읽기 시 이를 전달
장점 :
- 성능 : 읽기를 여러 데이터베이스에 분산시키고 이를 통해 병렬로 처리할 수 있는 쿼리의 개수가 증가
- 안정성 : 부 데이터베이스 중 하나가 고장나도 읽을 수 있다.
캐시
- 캐시는 자주 참조되거나 값비싼 연산의 결과를 미리 갖고 있음으로써 보다 빠른 요청처리를 가능하게한다.
- 데이터베이스 다중화를 통해 병목현상을 해결할 수 있지만 어쩌면 매 번 데이터베이스까지 다녀와야한다는게 문제가 될 수 있다.
- 이 때 캐시를 통해 성능을 개선할 수 있다.
찾고자하는 데이터가 캐시에 저장되어 있다면 바로 반환해준다. 만약 없다면 데이터베이스에서 찾아와 이를 캐시에 저장한 후 반환한다. 캐시는 데이터베이스보다 훨씬 빠르게 동작한다.
그러나! 캐시를 사용하기전 고려사항이 있다.
- 데이터 업데이트보다 데이터 참조가 빈번한 경우 사용을 고려해볼만한다.
- 캐시는 휘발성. 중요데이터를 저장할목적으로 사용할 순 없다.
- 캐시에 저장된 데이터를 어떻게 만료시킬것인가?
- 너무 오래 저장되면 원본과 달라질 수 있으며
- 그렇다고 너무 짧으면 데이터베이스에 자주 접근한다
- ★어떻게 일관성을 유지할것인가?
- 데이터베이스에 존재하는 원본과 캐시 내 사본이 동일하다는걸 어떻게 보장하는가?
- 저장소의 원본 갱신 연산과 캐시 갱신 연산이 단일 트랜잭션으로 처리된다면 괜찮지만
- 만약 이것이 불가능한. 여러 지역에 걸쳐 시스템이 확장된 경우는 어떻게 해야할까
캐시 일관성 보장
- https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf
- http://muratbuffalo.blogspot.com/2016/03/paper-summary-measuring-and.html
- 읽기는 유저 -> local region caches / miss -> root caches / miss -> databases
- 쓰기는 유저 -> database -> root caches -> leaf caches(local caches)
- ★
does not go for the update, but goes for the lazy strategy- 데이터베이스가 변경되면 변경사항을 하위 캐쉬들에게 update시키는것이 아닌 캐시들에 있는 해당 데이터를 무효화시킨다
- lazy strategy -> 그러면 다시 요청이 들어오면 그 때 miss를 일으키고 이때 db에서 가져온다
- 즉 데이터베이스가 업데이트되면 캐쉬들을 업데이트하는것이 아닌 데이터를 삭제
- This lazy strategy also has the advantage of being simple and avoiding inadvertantly messing things (such as ordering of writes
- 개인적으로 고민해봤을 때 이 방법은
내가 데이터를 요청한 순간 이전 마지막으로 업데이트된 데이터를 가져오는걸 보장해줄 수 있다고 생각한다 - 만약 위 방법이 아닌 데이터베이스가 업데이트되면 캐쉬들도 바로 업데이트한다라고 했을 때 a에 대한 수정( 1,2,3,4 ...)이 거의 동시에 매우 많이 이뤄졌을 때 1보다 아주 조금 더 나중에 수행된 100이 먼저 처리되면 결국 나는
이전데이터를 받는것이라고 생각
stateless
- 웹 계층의 수평적 확장
-
앞서 트래픽을 여러 서버로 분산시키위해 앞단에 로드밸런서를 위치시킨다고했다. 여기서 만약 ★모든 서버가 데이터를 저장하는 stateful상태라면? a 클라이언트에 대한 요청은 반드시 해당 클라이언트 정보를 갖고있는 A서버가 일대일 처리를해야한다 B서버는 a 클라이언트의 정보를 모르니 처리해줄 수 없다. 즉 확장의 한계를 가져다준다. 여기서 만약 모든 서버가 stateless고 중요데이터는 그 뒷단에 db에 저장한다면 어떠한 클라이언트가 요청을해도 모든 서버가 이를 처리해줄 수 있다.
메세지 큐
- 메세지 큐는 일단 보관된 메세지는 consumer가 꺼내기전까지 안전하게 보장
- 비동기 통신에 유용
producer라는 입력 생산 서비스가 메세지를 만들고 이를 큐에 발행 큐와 연결된 consumer 서비스가 큐에서 메세지를 꺼내 이를 처리
큐와 연결된 여러 consumer를 통해 하나의 consumer가 죽더라도 다른 consumer가 이를 처리해줄 수 있다. 또한 consumer가 죽더라도 입력 서비스는 살아있고 메세지를 생산하여 큐에 저장해놓을 수 있다. 이 경우 consumer가 살아나면 이를 처리해줄 수 있다.
추가로 시간이 오래 걸리는 처리과정은 이러한 메세지큐를 통해 비동기로 효과적으로 처리할 수 있다. 물론 큐가 커지면 이를 빠르게 처리하기위해선 더 많은 consumer가 필요하다
### 로그 & 매트릭
- 로그 : 에러 로그를 모니터링하는것은 중요하다. 시스템의 오류와 문제를 보다 쉽게 찾아낼 수 있다.
- 매트릭 : cpu 메모리 등의 정보로 시스템의 현재 상태를 파악하기 좋다.
- 앞에서 확장에 대해 얘기하며 항상 한 말은 서버가 죽어도 다른 서버가 처리할 수 있다는 말이었다.
- 개인적인 생각으로 이 서버가 죽었다는 말은 곧 서버가 왜 죽었는지를 파악하고 다시 살려야한다는 말이라고 생각
- 이를 위해 로그나 매트릭 정보가 필요하며 이 정보들을 저장할 필요가 있다고 생각
- ★ 쿠버네티스를 학습하며 이러한 경험을 해본적이 있다.
- 간단하게 filebeat 컨테이너를 활용하여 /var/log/nginx/error.log에 저장되는 nginx 에러로그를 수집
- 이를 엘라스틱서치에 저장한 후 키바나를 통해 시각화
- 이를 통해 어느 시점에 에러가 발생하며, 그 기록이 무엇인지를 파악할 수 있었다.
- https://github.com/skarltjr/Kubernetes-with-Docker/tree/main/쿠버네티스_dev(4)
- https://github.com/skarltjr/Kubernetes-with-Docker/tree/main/쿠버네티스_dev(5)
### 데이터베이스의 규모 확장
- 데이터베이스 또한 수직적 vs 수평적으로 확장할 수 있는데데이터베이스의 수직적 확장 수직적 확장 방법에는 심각한 약점이 존재.
- 사용자가 늘어나면 한 대의 서버로는 감당하기가 어렵다.
- single point of failure : 한 대의 고성능 데이터베이스가 망가지면 전체 서비스가 붕괴될 수 있다.
수평적 확장
수평적 확장은 샤딩이라고도 부르는데 대규모 데이터베이스를 샤드(shard)라는 작은 단위로 분할하여 저장
모든 샤드는 같은 스키마를 사용하지만 각 샤드에 보관되는 데이터는 중복 x
ex) 아래처럼 number가 2보다 작은건 a 데이터베이스 / 2보다 큰것들은 b데이터베이스에 보관
- 여기서 샤딩 키(sharding key)는 user_number
- 추가적으로 이 경우 sharding key를 인덱스로 하여 특정 데이터를 검색할 때 더 빠른 속도로 가능
- 만약 user_number가 1인애를 찾겠다고하면 2보다 작으니 바로 a데이터베이스로 접근하여 탐색
샤딩에서도 고려해야할 문제점은 존재한다.
데이터의 재 샤딩 (re-sharding) :
- 만약 데이터가 너무많아서 이들을 구분하기 위한 추가적인 샤드 키를 추가하여 더 쪼거나
- 특정 샤드에만 데이터가 집중되면 샤드 키를 계산하는 함수를 변경하여 데이터를 재배치한다.
hotspot key :
- 특정 샤드에 쿼리가 집중되는 경우도 존재할 수 있다.
- 예를들어 나이가 샤딩키인 경우 특히 20세 이상에 대해 쿼리가 너무많은 경우 더 잘게 쪼개야 할 수도 있다.
조인과 비정규화 :
- 하나의 데이터베이스를 여러 샤드로 쪼갰다.
- 그럼 당연하게도 여러 샤드에 걸친 데이터를 조인하기가 힘든데
- 이를 해결하는 방법 중 하나는 데이터베이스의 비정규화★1 챕터 정리
1. 웹 계층은 stateless하게
2. 모든 계층은 다중화를 통해 안정성 확보
3. db접근을 줄이기위한 캐싱 고려
4. 시스템을 지속적으로 모니터링
https://book.naver.com/bookdb/book_detail.nhn?bid=20756755 도서를 읽고 정리한 이슈