Google이 구축한 대규모 시스템 –
디자인 패턴
최흥배
• 인프라에 대한 필요 기능에 대해 물어보면 많은 요청이 있다
- 요구 중 6개를 만족시킬 수는 있다
- 7번째를 만족시키는 것은 어렵다
- 8번째까지 만족시키면 반대로 나빠진다
- 그러므로 모든 요구를 만족할 필요는 ...
대규모 분산 처리 디자인 패턴 – Single Master, 1000s of Workers
• D중심적인 마스터를 가지고 있다.
• GFS 마스터나 BigTable, MapReduce 등에서 사용하고 있다.
• 마스터에...
대규모 분산 처리 디자인 패턴 – Canary Request
• 이상한 요청에 의해서 크래쉬가 발생할 가능성이 있을 때, 그리고 이것을
막아낼 수 없을 때 이 패턴을 사용한다.
• 이 경우 같은 이상한 요청이 수 천의 ...
대규모 분산 처리 디자인 패턴 – Tree Distribution of Request
• 수 천대의 머신에 요청을 보낼 때 송신별 NIC랑 CPU가 병목이 된다. 이 때 이
패턴을 사용한다.
대규모 분산 처리 디자인 패턴 – Multiple Smaller Units per Machine
• 크래쉬 되었을 때 복구 시간을 최소화 하고 싶을 때 적절한 단위로 로드
밸런스 하고 싶을 때 사용한다.
• 큰 처리 덩...
대규모 분산 처리 디자인 패턴 – Multiple Smaller Units per Machine
대규모 분산 처리 디자인 패턴 – Range Distribution of Data, not Hash
• Key-Value 형 데이터 스토어 등을 복수의 머신에서 분산 처리하고 있을 때,
여기에다 머신을 추가하는 경우. ...
대규모 분산 처리 디자인 패턴 – Elastic Systems
• 부하에 대해서 유연한 시스템을 만들고 싶을 때 사용하는 패턴
• 부하에 대해서 큰 시스템을 만들면 리소스를 낭비하고. 부하를 작게 예상하면
멜-다운 해버...
대규모 분산 처리 디자인 패턴 – One Interface, Multiple Implementation
• 구글의 검색 서비스에서는 동시에 달성하는 것이 거의 불가능할 정도의 많은
서로 다른 속성을 동시에 달성하고 있다...
대규모 분산 처리 디자인 패턴 – One Interface, Multiple Implementation
Evolution and Future Directions of Large-Scale Storage and Computation Systems
at Google」(Google에 있어서 대규모 저장소와 계산의 진화와 장래의...
Upcoming SlideShare
Loading in …5
×

Google이 구축한 대규모 시스템–디자인 패턴

1,009
-1

Published on

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,009
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Google이 구축한 대규모 시스템–디자인 패턴

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

×