Create: [2주차] 2&3장 junstory

chap02/[chap02]이준호.md

@@ -0,0 +1,77 @@
+# #2 개략적인 규모 추정
+
+보편적으로 통용되는 성능 수치상에서 사고 실험을 통해 어떤 설계가 요구사항에 부합하는지 보는 것.
+
+## 2의 제곱수
+
+데이터 볼륨 단위를 2의 제곱수로 나타내자.
+최소 단위: 1바이트(8비트로 구성) //아스키 문자 하나는 1바이트
+
+| 2의 x제곱 | 축약형 |
+| --------- | ------ |
+| 10        | 1KB    |
+| 20        | 1MB    |
+| 30        | 1GB    |
+| 40        | 1TB    |
+| 50        | 1PB    |
+
+## 모든 프로그래머가 알아야 하는 응답 지연 값
+
+컴퓨터에서 구현된 연산들의 응답지연 값.
+처리 속도가 어느 정도인지 짐작할 수 있도록 해줌.
+
+2020년 기준으로 시각화한 값을 보면 다음의 결론을 내릴 수 있음.
+![image](https://velog.velcdn.com/images/dev_dc_hyeon/post/a7c2fc0c-f6e0-454f-9722-14dd69eb8d55/image.png)
+
+- 메모리는 빠르지만 디스크는 느림.
+- 디스크 탐색은 피하기
+- 단순 압축 알고리즘은 빠름.
+- 데이터를 인터넷에 보내기 전에 압축하기
+- 데이터 센터는 여러 지역에 있고 센터간 데이터를 주고받는 데 시간이 걸림.
+
+## 가용성에 관계된 수치
+
+고가용성: 오랜 시간 동안 지속적으로 중단 없이 운영될 수 있는 능력. %로 표현.
+SLA(Service Level Agreement): 서비스 사업자와 고객 사이에 맺어진 합의. 가용시간이 기술되어 있다.
+
+가용성은 보통 99%~100%사이의 값을 갖으며 소수점까지 9가 많을수록 높은 가용성.
+99%는 하루당 장애시간이 14.40분. 99.9999%는 86.40밀리초로 확연한 차이를 보임.
+
+## 트위터 QPS와 저장소 요구량 추정
+
+> 가정
+
+- 월간 능동 사용자(monthly active user)는 3억 명
+- 50%의 사용자가 트위터를 매일 사용
+- 평균적으로 각 사용자는 매일 2건의 트윗을 올림
+- 미디어를 포함하는 트윗은 약 10%
+- 데이터는 5년간 보관
+
+> 추정
+
+QPS(Query Per Second) 추정치
+
+- 일간 능동 사용자(Daily Active User, DAU) = 3억 X 50% = 1.5억
+- QPS = 1.5억 X 2트윗/24시간/3600초 = 약 3500
+- 최대 QPS(Peek QPS) = 2 X QPS = 약 7000 \*일반적으로 2배로 잡음. 시스템 기록을 통해 기간내 최고치로 잡을수도 있음.
+
+QPS: 초당 서버가 응답할 수 있는 쿼리의 수
+TPS: 초당 처리할 수 있는 트랜잭션의 수 (클라이언트 요청 → 서버 내부 처리 → 응답 // 1 TPS) \*페이지 방문시 1TPS but,, QPS는 1이상(실제 동작으로 게시글 조회, 댓글 조회 등등)
+
+> 미디어 저장을 위한 저장소 요구량
+
+- 평균 트윗 크기
+  - tweet_id에 64바이트
+  - 텍스트에 140바이트
+  - 미디어에 1MB
+- 미디어 저장소 요구량: 1.5억 X 2 X 10% X 1MB = 30TB/일
+- 5년간 미디어를 보관하기 위한 저장소 요구량: 30TB X 365 X 5 = 약 55PB
+
+> 팁
+
+결과를 내는 것보다 '**올바른 절차를 밟았는지**' 가 중요
+
+- 근사치를 활용한 계산 : 9888/9.234은 10000/10으로 보자
+- 가정들은 나중에 볼 수 있게 적어두자
+- 데이터 단위를 붙이자. 5를 보고 5KB, 5MB인지 알 수 없다
+- 많이 출제되는 건 미리 계산해보자.

chap03/[chap03]이준호.md

@@ -0,0 +1,61 @@
+# #3 시스템 설계 면접 공략법
+
+실세계의 수 천 명의 엔지니어가 만들어낸 그런 복잡한 시스템을 설계하라는 면접은 없다
+
+그럼 왜 시스템 설계 면접이 있을까?
+
+- 문제를 풀기 위해 협락하여 그 해결책을 찾아내는 과정을 시뮬레이션하기 위함.
+- 설계 과정에서 내린 결정에 대한 방어 능력, 피드백을 건설적으로 처리할 수 있음을 보인다.
+- 면접자는 지원자가 협력에 적합한지, 압박이 심해도 잘 헤쳐 나갈 수 있는지, over-engineering을 하지는 않는지 확인한다.
+
+## 효과적 면접을 위한 4단계 접근법
+
+> 1단계 문제 이해 및 설계 범위 확정
+
+- 깊이 생각하고 요구사항과 가정을 분명히 하자.
+- 중요한건 올바른 질문하기, 적절한 가정하기, 시스템 구축에 필요한 정보 수집
+  - 구체적으로 어떤 기능을 만들까?
+  - 사용자 수는 얼마나 될까?
+  - 회사의 규모는 얼마나 빨리 커질까? (n달 뒤)미래의 규모는?
+  - 회사의 주 기술 스택은?
+
+> 2단계 개략적인 설계안 제시 및 동의 구하기
+
+면접관을 팀원인 것 처럼 대하자.
+
+- 설계안에 대한 청사진을 제시하고 의견을 구한다.
+- 핵심 컴포넌트를 포함하는 다이어그램을 그린다.
+- 해당 설계가 시스템 규모와 관련된 제약사항들을 만족하는지 소리를 내어 확인해본다.
+- 여유가 된다면 구체적인 사용 사례도 생각해본다.
+
+> 3단계 상세 설계
+
+- 전체 설계 청사진 준비
+- 컴포넌트 사이의 우선순위 정하기
+
+> 4단계 마무리
+
+해야할 것
+
+- 질문을 통해 확인
+- 문제 요구사항 이해 // 정답이나 최선의 답은 없으니 요구사항을 정확하게 이해했는지 확인
+- 여러 해법 제시
+- 중요한 컴포넌트 부터 세부사항 설명
+- 면접관의 아이디어 이끌어내기
+- 포기하지 않기
+
+하지 말아야 할 것
+
+- 전형적인 면접 문제들에 대비하지 않고서 면접장에 가지 말기
+- 요구사항, 가정이 분명하지도 않은데 설계 제시하지 않기
+- 처음부터 컴포넌트에 대해 너무 깊이 설명X
+- 막히는 부분에서 힌트요청을 주저하지 않기
+- 소통 주저하지 않기. 침묵X
+- 의견을 일찍, 자주 구하기
+
+## 시간배분(일반적으로,,)
+
+1단계 - 문제 이해 및 설계 범위 확정 3~10분
+2단계 - 개략적인 설계안 제시 및 동의 구하기 10~15분
+3단계 - 상세설계 10~25분
+4단계 - 마무리 3~5분