개발하는 기계공학도

요약 : 여러 객체를 사슬처럼 연쇄적으로 묶고, 객체 사슬을 차례대로 돌면서 원하는 객체를 결정하는 방법 요청이 들어오고 요청을 처리할 수 있으면 처리하고 없으면 다음 사람에게 떠넘긴다. 클래스 목록 Trouble 트러블 클래스, 특정 번호(Number)를 갖는다. Support 트러블을 해결하는 추상 클래스 NoSupport 트러블을 해결하는 구상 클래스(항상 No!) LimitSupport 트러블을 해결하는 구상 클래스(지정한 번호 미만의 트러블만 Yes) OddSupport 트러블을 해결하는 구상 클래스(홀수 번호만 Yes) SpecialSupport 트러블을 해결하는 구상 클래스(특정 번호만 Yes) Main 동작 테스트용 클래스 예제 프로그램의 클래스 다이어그램 Chain of Responsib..

1단계 문제 이해 및 설계 범위 확정 기본적인 기능 URL 단축: 주어진 긴 URL을 훨씬 짧게 줄인다. URL 리디렉션: 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내 높은 가용성과 규모 확장성, 그리고 장애 감내가 요구됨 개략적 추정 쓰기 연산: 매일 1억 개의 단축 URL 생성 초당 쓰기 연산: 1억/24/3600 = 1160 읽기 연산: 읽기 연산과 쓰기 연산 비율은 10:1이라고 하자. 초당 읽기 연산은 초다아 11,600회 발생한다. URL 단축 서비스를 10년간 운영한다고 가정하면 1억 * 365 * 10 = 3650억개의 레코드를 보관해야 한다. 축약 전 URL의 평균 길이는 100이라고 하자. 따라서 10년 동안 필요한 저장 용량은 3650억 * 100바이트 = 36.5TB이다..

auto_increment 속성? → No! 분산 환경에서 이 접근법은 통하지 않는다. 여러 데이터베이스 서버를 쓰는 경우에는 delay를 낮추기 어렵다. 1단계. 문제 이해 및 설계 범위 확정 ID는 유일해야 한다. ID는 숫자로만 구성되어야 한다. ID는 64비트로 표현될 수 있는 값이어야 한다. ID는 발급 날짜에 따라 정렬 가능해야 한다. 초당 10,000개의 ID를 만들 수 있어야 한다. 2단계. 개략적 설계안 제시 및 동의 구하기 선택지 4개 multi-master replication UUID(Universally Unique Identifier) ticket server twitter snowflake 접근법 다중 마스터 복제 데이터베이스의 auto_increment 기능을 활용한다. 다만..

키-값 쌍에서의 키는 유일해야 하며 해당 키에 매달린 값은 키를 통해서만 접근할 수 있다. put(key, value) get(key) 문제 이해 및 설계 범위 확정 완벽한 설계란 없다. 읽기, 쓰기 그리고 메모리 사용량 사이에 어떤 균형ㅇㄹ 찾고, 데이터의 일광성과 가용성 사이에서 타협적 결정을 내린 설계를 만들어야 한다. 단일 서버 키-값 저장소 한대는 쉽다. 가장 직관적인 방법은 키-값 쌍 전부를 메모리에 해시 테이블로 저장하는 것이다. → 빠른 속도를 보장하긴 하지만 모든 데이터를 메모리 안에 두는 것이 불가능할 수도 있다는 약점이 있음 개선책 2가지 데이터 압축 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장 그래도 부족한 때가 곧 찾아온다. 분산 키-값 저장소 분산 키-값 저장소는 ..

수평적 규모 확장성을 달성하기 위해 요청을 서버에 균등하게 나누는 것이 중요한데 안정 해시는 보편적으로 사용하는 기술이다. 해시 키 재배치(rehash) 문제 안정 해시 해시 테이블 크기가 조정될 때 평균적으로 오직 k/n개의 키만 재배치하는 해시 기술이다. k : 키의 개수, n : 슬롯의 개수 해시 공간과 해시 링 해시 서버 해시 키 서버 조회 서버 추가 서버 제거 기본 구현법의 두 가지 문제 기본 절차는 다음과 같다. 서버와 키를 균등 분포 해시 함수를 사용해 해시 링에 배치한다. 키의 위치에서 링을 시계 방향으로 탐색하다 만나는 최초의 서버가 키가 저장될 서버다. 2가지 문제 서버가 추가되거나 삭제되는 상황을 감안하면 파티션의 크기를 균등하게 유지하는 것이 불가능 (파티션 : 인접한 서버 사이의 ..

처리율 제한 장치 : 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치 사례 사용자는 초당 2회 이상 새 글을 올릴 수 없다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없다. 같은 디바이스로는 주당 5회 이상 리워드를 요청할 수 없다. 장점 Dos(Denial of Service) 공격에 의한 자원 고갈 방지 요청에 대한 비용 절감 서버 과부화 방지 1단계. 문제 이해 및 설계 범위 확정 2단계. 개략적 설계안 제시 및 동의 구하기 처리율 제한 알고리즘 토큰 버킷 (버킷 크기, 토큰 공급률) 장점 구현이 쉽다. 메모리 사용 측면에서 효율적이다. 짧은 시간에 집중되는 트래픽도 처리 가능 단점 버킷 크기와 토큰 공급률이라는 두 개 인자를 갖고 있는데 적절하게 ..

개략적 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 한다. 특히 2의 제곱수나 응답지연 값, 그리고 가용성에 관계된 수치들을 기본적으로 잘 이해하고 있어야 한다. 2의 제곱수 2의 x제곱 근사치 축약형 10 1천 1KB 20 1백만 1MB 30 10억 1GB 40 1조 1TB 50 1000조 1PB 모든 프로그래머가 알아야 하는 응답지연 값 메모리는 빠르지만 디스크는 아직도 느리다. 디스크 탐색은 가능한 한 피하라. 단순한 압축 알고리즘은 빠르다. 데이터를 인터넷으로 전송하기 전에 가능하면 압축하라. 데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는 데는 시간이 걸린다. 가용성에 관계된 수치들 계산 팁 근사치를 활용하라 가정들은 적어 ..

단일 서버 웹 앱, DB, 캐시 등이 모두 서버 한 대에서 실행되는 구조 데이터베이스 사용자가 늘면 서버 하나로는 충분하지 않아서 여러 서버를 두어야 한다. 웹/모바일 트래픽 처리 용도(웹 계층) 데이터베이스 서버(데이터 계층) DB 선택 기준 대부분은 관계형 데이터베이스가 최선이지만 특정한 경우에는 비-관계형 데이터베이스를 사용한다. 아주 낮은 응답 지연시간(latency)이 요구될 때 다루는 데이터가 비정형이라 관계형 데이터가 아닐 때 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 될 때 아주 많은 양의 데이터를 저장할 필요가 있을 때 수직적 규모 확장 vs 수평적 규모 확장 스케일 업 : 고사양 자원을 추가하는 행위(수직적 규모 확장) 스케일 아웃 : 더 많은 서버를 추가해 성능을 개선하는 행위..

프로세스들의 Swap이 활발해지면서(Page Fault 자주 일어남) CPU 사용률이 하락하게 되고, CPU가 놀고있는 것을 발견한 운영체제는 프로세스를 추가하게 되는 쓰레싱 현상이 발생한다. 쓰레싱이 해소되지 않을 경우, Out of Memory 상태로 판단되어 중요도가 낮은 프로세스를 찾아 강제로 종료하게 된다. 쓰래싱 해결 방법 Page Fault Frequency 알고리즘은 Page Fault 퍼센트의 상한과 하한을 두고 너무 자주 일어나면 메모리를 더 주고, 너무 덜 일어나면 메모리르 뻇는다.

Dispatch (ready -> running) 여러 프로세스들 중 한 프로세스를 선정하여 CPU에 할당하는 과정입니다. Interrupt (running -> ready) 할당된 CPU 시간이 지나면 Timeout Interrupt 가 발생하여 CPU를 다른 프로세스에게 양도하고 자신은 ready 상태로 전이되는 과정입니다. Block (running -> waiting) I/O 등의 자원 요청 후 즉시 할당받을 수 없어, 할당받을 때까지 기다리기 위해 running에서 waiting 상태로 전이되는 과정입니다. I/O 처리는 CPU가 아닌 I/O 프로세스가 담당하기 때문에 block이 발생합니다. Wakeup (waiting -> ready) 필요한 자원이 할당되면 프로세스는 waiting에서 re..