[데이터 중심 애플리케이션 설계] 1장 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션 - 확장성 (2)

확장성

- 부하 증가에 대처하는 시스템 능력을 설명하는 데 사용하는 용어

- 우리는 확장성에 대해 "시스템이 특정 방식으로 커지면 이에 대해 어떻게 대처할 것 인가? 와 "추가 부하를 다루기 위해 계산 자원을 어떻게 투입할까?" 질문을 던져야 한다. 

 

1. 부하 기술하기

- 부하 매개변수(load parameter) : 몇개의 숫자로 나타냄

- 부하 매개변수로 웹 서버의 초당 요청 수, 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자, 캐시 적중률 등 이 있음

 

▶ 트위터

- 트웟 작성 : 작성자는 팔로워에게  새로운 메시지를 게시할 수 있음

- 홈 타임라인 : 사용자는 팔로우한 사람이 작성한 트윗을 볼 수 있다. 

- 작동 방식 : 

1) 트윗 작성은 새로운 트윗을 트윗 전역 컬렉션에 삽입한다. 사용자가 자신의 홈 타임라인을 요청하면 팔로우하는 모든 사람을 찾고, 이 사람들의 모든 트윗을 찾아 시간순으로 정렬해서 합친다. 

SELECT tweets.*, user.* FROM tweets
	JOIN users ON tweets.sender_id = users.id
    JOIN users ON followee_id = users.id
    WHERE follows.follower_id = current_user

 

2) 각 수신 사용자 트윗 우편함처럼 개별 사용자의 홈 타임라인 캐시를 유지한다. 해당 사용자를 팔로우하는 사람을 모두 찾고 팔로워 각자의 홈 타임라인 캐시에 새로운 트윗을 삽입한다. 그러면 홈 타임라인의 읽기 요청은 요청 결과를 미리 계산했기 때문에 비용이 저렴함. 

 

=> 트위터는 1번 방식 -> 2번 방식 -> 1번 & 2번 방식

 

 

2. 성능 기술하기

- 하둡같은 일괄 처리시스템은 보통 처리량에 관심을, 온라인 시스템ㅇ

- 성능 수치들 

 1) 처리량 : 초당 처리할 수 있는 레코드 수나 일정 크기의 데이터 집합으로 작업을 수헹할 때 걸리는 전체 시간

 2) 응답 시간 : 클라이언트 관점에서 본 시간으로, 요청을 처리하는 실제 시간(서비스 시간) 외에도 네트워크 지연과 큐 지연도 포함함, 측정 가능한 값의 분포로 취급

 3) 특이 값 : Outlier

 4) 지연 시간 : 요청이 처리되길 기다리는 시간으로, 서비스를 기다리며 휴지 상태인 시간을 말한다. 

- 평균보다는 백분위를 사용하는 편이 좋다. 

- 특이 값이 얼마나 좋지 않은지 알아보려면 상위 밴분위를 살펴 보는 것이 좋다. 

- 꼬리 지연 시간으로 알려진 상위 백분위 응답 시간은 서비스의 사용자 경험에 영향을 주기 때문에 중요함

- 큐 대기 지연 (queueing delay)은 높은 백분위에서 응답 시간의 상당 부분을 차지한다. 

 

*꼬리 지연 증폭 : 작은 비율의 백엔드 호출만 느려도 최종 사용자 요청이 여러 번 백엔드를 호출하면 느린 호출이 발생할 가능성이 증가한다. 그래서 최종 사용자 요청 중 많은 비율의 응답 시간은 결과가 느려진다. 이 효과를 명칭한다. 

 

 

3. 부하 대응 접근 방식

- 부하 매개변수가 어느 정도 증가하더라도 좋은 성능을 유지하려면 어떻게 해야할까? : 아키텍처를 재검토 해봐라

- 아키텍처를 결정하는 요소 : 읽기의 양, 쓰기의 양, 저장할 데이터의 양, 데이터의 복잡도, 응답시간 요구사항, 접근 패턴 ..

 

 

 

*비공유 아키텍처 : 다수의 장비에 부하를 분산하는 아키텍처