Update 4:Joe Stump가 작성한 Introducing Digg’s IDDB Infrastructure. IDDB 는 인덱스(e.g. integer sequences and unique character indexes) 와 실제 테이블을 다중 저장 서버(MySQL and MemcacheDB are currently supported with more to follow)로 분할하는 방법입니다.
Update 3:: Scaling Digg and Other Web Applications.
Update 2:: How Digg Works and How Digg Really Works (wear ear plugs). Digg의 블로그에서 곧바로 여러분을 일깨워줍니다.시스템의 요청을 추적하면서 Digg의 아키텍처의 주요 요소에 대한 매우 간결한 설명. 새로운 정보에 이 프로파일을 갱신했습니다.
Update: Digg now receives 230 million plus page views per month and 26 million unique visitors - traffic that necessitated major internal upgrades.
Digg의 2200만 이상의 인기있는 정보를 찾는 사용자와 2억 3천만 페이지뷰가 만드는 트래픽은 예상하지 못한 웹사이트를 CPU, 메모리, 대역폭의 제한으로 갑자기 멈추게 할 수 있습니다. Digg는 월 수억개의 요청을 어떻게 처리할까요?
Site: http://digg.com
Information Sources
How Digg Works by Digg
How Digg.com uses the LAMP stack to scale upward
Digg PHP's Scalability and Performance
Platform
MySQL
Linux
PHP
Lucene
Python
APC PHP Accelerator
MCache
Gearman - job scheduling system
MogileFS - open source distributed filesystem
Apache
Memcached
The Stats
Apache 1.3, PHP4, 기본 MyISAM 저장 엔진을 사용하는 MySQL 4 를 운영하는 단일 리눅스 서버로 2004년 늦게 시작
2200만 이상 사용자.
월 2억 3천만 이상의 페이지뷰
월 26백만 유니크 방문자
월 수억 페이지뷰
어떤 확장도 PHP로 다 가능했음. 가장 큰 이슈는 데이터베이스와 관련됨.
열 두개의 웹 서버.
열 두대의 DB 서버.
추천 엔진을 운영하는 여섯 대의 특성화된 그래프 데이터베이스 서버
MogileFS로부터 파일을 서비스하는 여섯에서 열대의 장비.
What's Inside
전문 로드 밸런스 장비는 응용프로그램 서버를 감시하고, 장애를 처리하고, 현재 상태에 따라 클러스터를 조정하고, 들어오는 요청과 JavaScript, CSS, 이미지 캐싱을 조정합니다. 고가의 로드 밸런서를 가지지 않고 있다면 대체품으로 Linux Virtual Server와 Squid를 검토해보세요.
요청은 응용프로그램 서버 클러스터로 전달됩니다. 응용프로그램 서버 구성: Apache+PHP, Memcached, Gearman , 다른 데몬들. 이들은 다른 서비스로(DB, MogileFS, etc)의 접근을 조정하는 임무가 있고 브라우저로 보내는 응답을 만듭니다..
MySQL master-slave을 사용.
- 4대의 마스터 데이터베이스는 기능으로 분할됩니다: 홍보, 프로파일, 댓글, 메인. 많은 슬래이브 데이터베이스가 각 마스터에 걸려있습니다.
- 쓰기는 마스터로, 읽기는 슬래이브로 갑니다.
- 무거운 트랜잭션 서버는 InnoDB 저장 엔진을 사용합니다.
- OLAP 전용 서버는 MyISAM 저장 엔진을 사용합니다.
- Digg는 MySQL 4.1에서 5 버전으로 성능 감소를 알리지 않았습니다.
- 스키마는 보통 데이터베이스 디자인 보다는 반정규화되었습니다.
- 조각화는 데이터베이스를 여러개의 작은 것으로 쪼개는 데 사용됩니다.
Digg의 사용패턴은 확장하기 더 쉽게 만들었습니다. 대부분 사람들은 프론트 페이지를 단지 보고 떠납니다. Digg의 데이터베이스 접근의 98%는 읽기입니다. 동작의 균형을 통해 Digg는 쓰기를 위한 복잡한 아키텍팅 작업을 걱정하지 않았는데, Digg가 확장을 매우 편하게 해줬습니다.
Digg는 그들이 실제로 원하지 않을 때 디스크에 저장하는 것을 알려주어야 하는 저장 시스템에 문제들을 가지고 있었습니다. 컨트롤러는 성능의 외향을 향상시켰습니다. 그러나 컨트롤러의 동작은 장애 시나리오에서 거대한 데이터 일치성을 남겨두었습니다. 이것은 정말로 꽤 일반적인 문제이고 하드웨어 설정에 의존하는, 고치기 어려운 것이었습니다.
데이터베이스 부하를 낮추기 위해 Digg는 APC PHP accelerator MCache를 사용했습니다.
Memcached 는 캐싱을 위해 사용되고 memcached servers 는 데이터베이스와 응용프로그램 서버들에 넓게 분포되어 있습니다. 전문화된 데몬은 연결을 감시하고 너무 오래 열린 연결을 죽입니다.
여러분은 Apache2 의 worker threads, FastCGI, PHP accelerator의 조합으로 매번 로딩할 때 PHP가 분석과 컴파일을 하지 않도록 구성할 수 있습니다. 페이지의 첫번째 로드에서 PHP 코드는 컴파일되고 연이은 페9이지로드는 매우 빠릅니다.
분산 파일시스템인 MogileFS은 스토리 아이콘, 사용자 아이콘을 서비스하고, 각 스토리 원본의 스토리 복제를 저장합니다. 분산 파일 시스템은 빠르고 확장가능한 파일 접근을 지원하는 많은 디스크들에 파일을 퍼뜨리고 복사합니다.
전문화된 추천 엔진 서비스는 분산 그래프 데이터베이스로 동작하도록 구축되었습니다. 관계형 데이터베이스는 추천 생성을 위한 구조에 적합하지 않았고 따라서 분리된 서비스가 생성되었습니다. LinkedIn 은 Digg의 그래프를 위해 비슷한 일을 합니다.
배운 교훈
장비의 숫자는 중요하지 않고 어떻게 구성하고 잘 어울리게 할 것일지가 중요합니다.
큰망치로 데이터베이스를 다루지 마세요. 추천은 관계형 모델로 적합하지 않아 전문화된 서비스를 만들었습니다.
데이터베이스 엔진 선택을 통해 MySQL를 조절하세요. 트랜잭션이 필요하면 InnoDB를, 필요없으면 MyISAM을 사용하세요. 예로, 마스터의 트랜잭션 테이블은 읽기전용 슬래이브를 위해 MyISAM을 사용하세요.
Digg의 성장 곡선의 어떤 지점에서 그들은 RAM을 추가하여 성장하는 것이 불가능해져서 아키텍처를 통해 성장해야 했습니다.
사람들은 자주 Digg가 느리다고 불평했습니다. 아마도 백엔드 아키텍처가 아니라 큰 자바스크립트 라이브러리 때문이었습니다.
확장하는 한 가지 방법은 시스템에 배치하는 응용프로그램에 주의하는 것이었습니다. 너무 많은 CPU를 사용하는 응용프로그램을 출시하지 않도록 주의했습니다. 분명히 Digg는 꽤 표준적인 LAMP 아키텍처를 사용하지만, 나는 이것이 흥미로운 지점이라고 생각했습니다. 기술자는 자주 그들이 출시하고 싶은 멋진 기능들을 가지고 있지만, 인프라가 기능들과 함께 커지지 않으면 그러한 기능들은 인프라를 망가뜨립니다. 시스템이 새로운 기능을 처리할 때까지 참으세요. 이것은 용량 계획으로 이어지는데, Flickr가 그들의 확장 과정에서 강조한 것입니다.
Digg의 인프라에 맞춰 새로운 기능을 제한하는 것이 Digg가 빠르게 소셜 북마킨 서비스로 움직이는 배경을 잃어버리는 것이 아닌가 궁금할 것입니다. 아마도 인프라가 쉽게 확장된다면 Digg는 더 나은 경쟁을 도와주는 기능들을 더 빠르게 추가했을 것입니다. 반대로, 많은 이해가 없기 때문에 단지 기능만 추가했을 것입니다.
데이터 레이어는 대부분 확장과 성능 문제가 발견되는 곳이고 이들은 언어에 종속적입니다. Java, PHP, Ruby를 적용할 수 있고, 또는 좋아하는 개발언어를 넣을 수 있습니다.
관련 기사
