2. • 인프라에 대한 필요 기능에 대해 물어보면 많은 요청이 있다
- 요구 중 6개를 만족시킬 수는 있다
- 7번째를 만족시키는 것은 어렵다
- 8번째까지 만족시키면 반대로 나빠진다
- 그러므로 모든 요구를 만족할 필요는 없다. 가장 일반적인 과제를 정하고
그것을 만족시켜야 한다.
• 시스템을 개발할 때 가장 중요한 것은 확장성이다.
그러나 무한대로 확장 할 필요는 없다.
• 스케일이 2항(자리 수. 9->10) 바뀔 때는 처음 디자인을 다시 생각하는 것이
좋다
• 무한 확장성을 처음부터 고민할 필요는 없다
3. 대규모 분산 처리 디자인 패턴 – Single Master, 1000s of Workers
• D중심적인 마스터를 가지고 있다.
• GFS 마스터나 BigTable, MapReduce 등에서 사용하고 있다.
• 마스터에 대해 자주 핫-스탠바이가 사용 되고 있다.
• 대량의 데이터가 클라이언트에서 워커 사이에 전송되고 있다
4. 대규모 분산 처리 디자인 패턴 – Canary Request
• 이상한 요청에 의해서 크래쉬가 발생할 가능성이 있을 때, 그리고 이것을
막아낼 수 없을 때 이 패턴을 사용한다.
• 이 경우 같은 이상한 요청이 수 천의 서버에 보내지면 모든 서버가 크래쉬
된다.
• 처음에 Canary Request를 보내고 그것이 성공한다면 통신을 계속한다.
5. 대규모 분산 처리 디자인 패턴 – Tree Distribution of Request
• 수 천대의 머신에 요청을 보낼 때 송신별 NIC랑 CPU가 병목이 된다. 이 때 이
패턴을 사용한다.
6. 대규모 분산 처리 디자인 패턴 – Multiple Smaller Units per Machine
• 크래쉬 되었을 때 복구 시간을 최소화 하고 싶을 때 적절한 단위로 로드
밸런스 하고 싶을 때 사용한다.
• 큰 처리 덩어리가 아닌, 복수의 작은 처리 유닛를 관리하는 방법
• 각각의 머신을 1 유닛으로 해서 관리하면 복구할 때를 위해 머신마다 새로운
복제를 만드는 것은 큰일. 이것을 로드 밸러스 하는 것은 더 어렵다
그래서 머신 마다의 처리를 작은 유닛으로 나눈다.
• 유닛 수의 조정으로 로드 밸런스가 하기 쉬워지고, 만약 머신이 실패하더라도
각각의 유닛을 N개의 머신이 분담해서 복구할 수 있으므로 빠르게 복구할 수
있다.
7. 대규모 분산 처리 디자인 패턴 – Multiple Smaller Units per Machine
8. 대규모 분산 처리 디자인 패턴 – Range Distribution of Data, not Hash
• Key-Value 형 데이터 스토어 등을 복수의 머신에서 분산 처리하고 있을 때,
여기에다 머신을 추가하는 경우. 이 머신에 어떻게 데이터를 할당할지가 고민.
• Consistent hashing에서는 머신 간에 평등하게 데이터를 분산할 수 있다.
그러나 어느 머신에 어떤 데이터를 분산하는지를 유저가 알기 어렵다.
• 이 패턴에서는 Key의 범위를 복수의 연속된 범위로 분할 하여 새로운 머신에
할당하고 있다. BigTable의 Tablet 등이 이 방법을 채용하고 있다.
• 이 방법은 Consistent hashing에 비해 구현이 어렵지만 어느 범위의 Key의
데이터를 같은 Tablet에 넣는 것을 컨트롤 할 수 있어서 데이터를 빼 낼 때
소수의 머신에 접근하는 것으로 끝 낼 수 있다.
9. 대규모 분산 처리 디자인 패턴 – Elastic Systems
• 부하에 대해서 유연한 시스템을 만들고 싶을 때 사용하는 패턴
• 부하에 대해서 큰 시스템을 만들면 리소스를 낭비하고. 부하를 작게 예상하면
멜-다운 해버린다.
가능하면 부하가 작을 때는 자동적으로 공유하여 리소스를 절약하고, Peek
때에는 자동적으로 확장하기를 바란다.
• 구글에서는 부하에 대해서 최대 2배 정도의 Capacity를 계호기하고 있다.
10. 대규모 분산 처리 디자인 패턴 – One Interface, Multiple Implementation
• 구글의 검색 서비스에서는 동시에 달성하는 것이 거의 불가능할 정도의 많은
서로 다른 속성을 동시에 달성하고 있다.
최신의 인덱스
대용량
고품질 취득
대규모
• 하나의 구현만으로 이것들을 해결하는 것은 아주 어렵다.
그래서 과제를 분할하여 각각을 해결하는 구현을 목표로 한다.
11. 대규모 분산 처리 디자인 패턴 – One Interface, Multiple Implementation
12. Evolution and Future Directions of Large-Scale Storage and Computation Systems
at Google」（Google에 있어서 대규모 저장소와 계산의 진화와 장래의 방향성）
http://research.microsoft.com/en-us/um/redmond/events/socc2010/index.htm
(일본어 번역) http://www.publickey1.jp/blog/10/4.html
참고
