Save My Code

규모 증대와 시스템 확장「대규모 서비스를 지탱하는 기술」 Chapter 12계층별 확장성AP 서버비교적 간단하게 확장 가능구성이 동일하고 상태를 갖고 있지 않으므로 요청별로 다른 AP 서버로 날려보내도 처리상 문제가 발생하지 않고, 로드밸런서에 새로운 서버를 추가해가면 점점 확장 가능DB나 파일 서버분산, 확장성 확보 매우 어려움데이터 소스로의 요청은 read와 write로 나뉨read의 분산 → 비교적 용이write의 분산 → 매우 어려움 튜닝서버관리툴로 부하 파악 & 상태 감시 → 부하를 가시화해서 병목이나 이상현상을 파악할 수 있도록 함부하 측정 항목: Load Average, 사용자 공간이 소비되고 있는 메모리, 공유되고 있는 메모리, 커널이 사용하고 있는 버퍼의 메모리 등 확장성 확보로드밸랜서 ..

웹 서비스의 백엔드「대규모 서비스를 지탱하는 기술」 Chapter 11웹 서비스의 인프라에서 중요시되는 것 세 가지저비용 고효율→ 100%의 신뢰성은 목표로 하지 않음확작성이나 응답성에 대한 설계 중요→ 기술적으로 중점을 둔 설계서비스 사양 변화에 유연하게 대응할 수 있는 인프라여야 함→ 개발속도 중시, 배포 간편, 필요한 서버 즉시 추가, 문제 발견 시 곧바로 이전 상태로 클라우드 컴퓨팅장점: 확장의 유연성단점: 각각의 클라우드 서비스마다 독자적인 사양에 대응할 필요 있음 자체구축 인프라의 장점유연한 서버 구성서비스로부터의 요청에 대한 유연한 대응병목현상 제어 자체구축 인프라와 수직통합 모델수직통합 모델: 물리적 계층부터 서비스 설계까지 모든 것을 한 회사에서 구축하는 모델 (e.g. Google, A..

대규모 데이터 처리의 노하우「대규모 서비스를 지탱하는 기술」 Chapter 09검색 시스템의 여섯 단계크롤링: 검색할 대상 문서 가져오기저장인덱싱검색스코어링: 검색 결과를 어떤 순서로 표시해줄 것인가 (aka 랭킹)결과 표시 전문 검색의 종류grep형검색 대상 문서를 처음부터 전부 읽어가는, 가장 단순한 아키텍처검색 대상인 텍스트의 길이를 m, 검색하려는 검색어의 길이를 n이라고 했을 때 O(mn)만큼 걸림 → 상당한 시간즉시성이 좋음 → 문서가 갱신되더라도 바로 검색 가능검색 누락 없음 → 전부 읽어가므로병렬화 간단 → 대규모 환경에 무리Suffix형검색 대상 전문을 검색 가능한 형태로 가지고 있음 → 빠르게 검색 가능이론적으로는 가능하나 정보량이 크고 구현이 어려움역 인덱스형역 인덱스: 단어(term..

가까운 예로 보는 이론 · 연구의 실전 투입「대규모 서비스를 지탱하는 기술」 Chapter 07데이터 구조배열, 트리구조, 힙 등알고리즘에서 자주 사용하는 조작에 맞춰 선택 알고리즘 Order 표기의 상수항해당 알고리즘을 구현하는 중 입력 크기에는 의존하지 않지만 실행하지 않으면 안 되는 처리의 일종e.g. 함수호출이나 함수로부터 값을 반환하기 위한 처리, 일차변수 확보, if문 분기 Order 표기 유의점계산량 O(n^2)인 알고리즘을 나름대로 노력해서 상수항을 줄이는 연구를 하더라도 이를 대체해서 O(n log n)인 알고리즘이 있다면 후자를 사용하는 편이 개선효과가 더 클 것→ ‘측정이 중요’하다는 얘기로, 지금 대상으로 하는 프로그램에 무엇이 문제인가를 정확하게 아는 것이 중요알고리즘을 교체해서 ..

애플리케이션 개발의 급소「대규모 서비스를 지탱하는 기술」 Chapter 05RDBMS에 한계가 있을 시DB에서 정기적으로 데이터를 추출하여 별도의 인덱스 서버로 넘겨줌인덱스 서버가 웹 API 등으로 처리 용도특화형 인덱싱데이터를 정기적으로 뽑아내고 이 데이터에서 데이터 구조를 구축검색용 역 인덱스키워드 링크용 Trie 등 RDBMS 대신 전문 검색엔진을 직접 구현RDB의 데이터를 배치로 얻기역 인덱스를 만들어 검색 알고리즘을 사용

「대규모 서비스를 지탱하는 기술」 Chapter 04분산을 고려한 MySQL 운용의 포인트OS 캐시 활용인덱스를 적절하게 설정하기확장을 전제로 한 설계 OS 캐시 활용전체 데이터 크기에 주의데이터량 를 유지메모리가 부족할 경우에는 증설스키마 설계가 데이터 크기에 미치는 영향 고려 인덱스(=색인)의 중요성MySQL의 인덱스는 기본적으로 B+트리라는 데이터 구조B+트리DB에 데이터를 저장하는 데 최적화된 데이터 구조 → Seek 횟수 최소화하는 트리 구조색인 계산량: O(log n) MySQL의 레플리케이션 기능레플리케이션: 마스터를 정하고 마스터를 뒤따르는 서버를 정해두면 마스터에 쓴 내용을 슬레이브가 폴링해서 동일한 내용으로 자신을 갱신하는 기능 → 동일한 내용의 서버를 여러 대 마련 가능참조 쿼리는 슬..

대규모 데이터를 효율적으로 처리하는 원리「대규모 서비스를 지탱하는 기술」 Chapter 03메모리, 디스크, OS 캐시 구조디스크와 메모리 간 속도차는 10^5~10^6배 이상메모리를 이용해서 디스크 액세스를 줄이고자 함 → OS는 캐시 구조를 갖추고 있음 OS의 가상 메모리 구조논리적인 선형 어드레스를 물리적인 물리 어드레스로 변환하는 것페이지OS가 물리 메모리를 확보/관리하는 단위가상 메모리의 최소단위 Linux의 페이지 캐시디스크의 내용을 일단 메모리에 읽어들임 → 페이지가 작성됨작성된 페이지는 파기되지 않고 남음 → 페이지 캐시예외의 경우를 제외하고 모든 I/O에 투과적으로 작용 → VFS(Virtual File System)가 담당 캐싱 방법: Linux의 파일 식별i노트 번호 → “어떤 파일의..

메모리와 디스크, 웹 애플리케이션과 부하「대규모 서비스를 지탱하는 기술」 Chapter 02대규모 데이터의 어려움 → 메모리 내에서 계산할 수 없음 → 디스크에 있는 데이터를 검색해야함 → 디스크는 느리므로 I/O 시간이 걸림 → 어떻게 대처할 것인가?DB 확장성 확보의 어려움 (웹 애플리케이션 3단 구조 프록시 ↔ AP서버 ↔ DB 에서)AP 서버는 CPU 부하만 걸리므로 분산이 간단함 → 데이터를 분산해서 갖고 있는 것이 아니므로 새로운 서버를 추가하고자 한다면 원래 있던 서버와 완전히 동일한 구성(복사본)을 갖는 서버의 대수를 늘리기만 하면 간단히 확장 가능 → 요청을 균등하게 분산하는 것은 로드밸런서가 해줌I/O의 부하에는 문제가 있음 → DB와 DB’(복사본)의 데이터 동기화 문제AP 서버는 디..

전체 그림 파악하기「대규모 서비스를 지탱하는 기술」 Chapter 01대규모 서비스에 있는 문제점 → 서버 1대로는 처리할 수 없는 부하를 어떻게 처리할 것인가?스케일아웃: 서버의 역할을 분담하거나 대수를 늘림으로써 시스템의 전체적인 처리능력을 높여서 부하를 분산하는 방법스케일업: 하드웨어의 성능을 높여 처리능력을 끌어올리는 방법스케일아웃 전략을 채용한 경우 비용이 절감되는 반면 다양한 문제가 발생함사용자로부터의 요청을 어떻게 분배할 것인가? → 로드밸런서 사용데이터 동기화는 어떻게 할 것인가?네트워크 통신의 지연시간은? (e.g. 이더넷을 경유해서 통신한 경우)스케일아웃을 할수록 서버 대수가 늘어나고 서버의 고장률도 필연적으로 올라감 → 서버의 다중성 확보 중요시스템은 다중성을 지닌 구성, 즉 특정 서..