Stack Overflow Architecture

원제 : Stack Overflow Architecture

번역 : Stack Overflow Architecture

Update: Startup – ASP.NET MVC, Cloud Scale & Deployment shows an interesting alternative approach for a Windows stack using ServerPath/GoGrid for a dedicated database machine, elastic VMs for the front end, and a free load balancer.

Stack Overflow는 무명의 두 사람이 만든 사랑하는 프로그래머들이 질문과 답을 하는 사이트입니다. 정확하지 않습니다. Stack Overflow는 최상의 프로그래머이자 블로그 스타인 Jeff  Atwood와 Joel Spolsky가 개발했습니다. 잠시 둘러봐도 Stack Overflow는 유명한 식당을 소유하는 것과 같습니다. 조엘은 세상의 1/3 이상의 프로그래머가 Stack Overflow를 이용하고 있다고 추산하는데, 무엇인가 좋은 것을 제공하기 때문입니다..

나는 순수한 이기적인 이유를 위해 Stack Overflow를 깊이 좋아했는데,  Stack Overflow는 내 눈을 찔러 고통을 주는 몇 가지 어려운 문제를 해결하는데 도움을 주었기 때문입니다. 또한 나는 인류학적으로 설계 철학에 바탕을 둔 사과없음에 감사합니다. 기술자에게 행동에서 설계를 사용하면 여러분이 좌절시키기 원하는 응답을 권장하거나 최소화하기를 원합니다. 이는 시너지 효과 같은 것을 생성하는 자의식적인 메커니즘입니다.

나에게 Stack Overflow 이야기에 대한 주요부분은 잠재적으로 큰 문제들을 위한 실행 가능한 솔루션으로 확장(scale up)을 한 강력한 사례입니다. 최근 관심은 NoSQL 데이터베이스를 이용하여 확장(scale out)하는 것입니다.

그러나 Stack Overflow는 Google 이 아니고 대부분의 사이트와도 다릅니다. 설계 옵션을 생각할 때 Stack overflow를 잊지마시길. 멀티코어, 큰 RAM 장치와 병렬 프로그래밍 기술의 장점이 있는 시대에서, 더 이상 차갑지 않기 때문에 확장(scale up)은 실행가능한 전략이며, 가장자리에 방치해서는 안됩니다. 언젠가 우리는 두 세계의 최고를 가지겠지만, 현재는 만들어야 하는 고통이 큰 선택이고 이 선택이 당신의 운명을 결정합니다.

조엘은 비슷한 크기의 사이트와 비교하여 유사한 성능을 내는데 1/10의 하드웨어를 사용한다는 것을 자랑합니다. 그는 다른 사이트에 좋은 프로그래머가 있는가 궁금해합니다. 그들이 어떻게 했는지 보고 여러분이 판단해보세요.

Site: http://stackoverflow.com

The Stats

월 천6백만 페이지 뷰16 million page views a month

월 3백만 고유 방문자 (Facebook은 월 7천7백만 고유 방문자에 도달)

월 6백만 방문자

86% 트래픽은 구글에서 옵니다

전세계에 9백만명의 프로그래머가 있고 이중 30%가 Stack  Overflow를 이용합니다

Microsoft's BizSpark  프로그램을 획득하여 저렴한 라이센싱. OS와 SQL 라이선스로 만천달러를 지불했다는 것에 감명받았습니다.

Monitization strategy: 야단스럽지 않게 취업 알선 광고, 개발자 컨펀러스 를 추가, 소프트웨어를 다른 관련된 틈새로 확장(Server Fault, Super User), white Label이며 Stack Overflow의 호스팅 버전인 StackExchange를 개발, 다른 종류의 프로그래머 순위 시스템을 개발

Platform

Microsoft ASP.NET MVC

SQL Server 2008

C#

Visual Studio 2008 Team Suite

JQuery

LINQ to SQL

Subversion

Beyond Compare 3

VisualSVN 1.5

Web Tier
- 2 x Lenovo ThinkServer RS110 1U
- 4 cores, 2.83 Ghz, 12 MB L2 cache
- 500 GB datacenter hard drives, mirrored
- 8 GB RAM
- 500 GB RAID 1 mirror array

Database Tier
- 1 x Lenovo ThinkServer RD120 2U
- 8 cores, 2.5 Ghz, 24 MB L2 cache
- 48 GB RAM

A fourth server was added to run superuser.com. All together the servers also run Stack Overflow, Server Fault, and Super User.

QNAP TS-409U NAS for backups. Decided not to use a cloud solution because the bandwidth costs of transferring 5 GB of data per day becomes prohibitive.

Hosting at http://www.peakinternet.com/. Impressed with their detailed technical responses and reasonable hosting rates.

SQL Server's full text search is used extensively for the site search and detecting if a question has already been asked. Lucene.net is considered an attractive alternative.

배울 교훈

Jeff와 Joel가 그들로 받은 코멘트로부터 받은 혼합한 교훈입니다.

서버 관리가 편하면 구매하세요. 서버를 빌리는데 2가지 큰 문제가 있습니다 : 1) 메모리와 디스크 업그레이 비용이 비정상적입니다 2) [호스팅을 제공하는] 그들이 어떤 것도 관리하지 않는다는 사실.

장기적인 관점에 비용이 더 많이 드는 매월 되풀이 되는 비용을 피하기 위해 초기 투자를 한번 크게 하라.

모든 네트워크 드라이버를 업데이트 하세요. 성능이 2배 느린 상태에서 2배 더 빨라집니다.

MS Enterprise edition  업그레이드를 위해 램을 48GB 로 업그레이드.

메모리는 매우 저렴합니다. 자유로운 성능을 위해 메모리를 최대화하세요. 예로 델에서 메모리 4G를 128G로 업그레이드하는데 4378달러입니다.

Stack Overflow 는 Wikipedia 데이터베이스 설계를 부분적으로 복사했습니다.  수리를 위해 거대하고 고통스러운 리팩토링이 필요하다는 실수로 밝혀졌습니다. 리팩토링은 많은 주요한 쿼리에서 과도한 조인을 피하기 위한 것이었습니다. 완전히 (Google의 BigTable 처럼 )join-free 해야하는 거대한 TB급 테이블 스키마로부터 핵심 교훈입니다. Stack Overflow의 데이터베이스가 거의 모두 RAM에 있고 조인은 여전히 비용면에서 너무 높아 정확해야 하기 때문에 중요합니다.

데이터베이스 서버에서 CPU 속도는 놀랄 정도로 중요합니다. 1.86 GHz에서 2.5 GHz,  3.5 GHz CPU는 전형적인 질의에서 거의 선형적으로 동작합니다. 예외는 메모리에 맞지 않는 질의를 할 때 입니다.

여러분이 매달 문의하지 않는다면 하드웨어를 빌릴 때 아무도 RAM 업그레이드의 판매가를 모릅니다.

병목은 데이터베이스가 90%입니다.

적은 서버를 사용하면,  핵심 비용은 랙공간, 전원, 대역폭, 서버, 소프트웨어에서 발생하지 않습니다; 비용은 네트워킹 장비에서 발생합니다. 여러분은 DB와 웹 티어간에 기가비트 네트워크를 필요로 합니다. Cloud(사용자망)과 웹서버간에, 여러분은 방화벽,라우팅, VPN 장비가 필요합니다. 두번째 웹 서브를 추가하는 순간에, 여러분은 또한 로드밸런서 장비가 필요합니다. 이런 장비들의 추가 비용은 간단히 몇 안되는 서버 비용의 두배가 됩니다.

EC2 는 수평적으로 확장하는데, 여러분이 많은 장비로 여러분의 작업을 나누어야 합니다(여러분이 확장할 수 있다면 좋은 생각입니다). 필요할 때마다 확장해야 한다면, (부하 증가/감소할 때 장비를 추가/제거해야 하는) 더 많은 신경을 쓰게 만듭니다.

오픈소스 소프트웨어를 이용할 때 확장(scale out)은 유일한 마찰입니다. 달리 확장(scale up)은 더 적은 라이선스 비용 더 많은 하드웨어 비용을 지불하는 것을 의미합니다. 확장(scale out)이 하드웨어에 적게 지불한다는 의미는, 라이선스에 더 많이 지불한다는 뜻입니다.

RAID-10은 과도한 읽기/쓰기가 발생하는 데이터베이스 작업량에서 기막히게 좋은 것입니다.

용프로그램과 데이터베이스를 분리는 의무인데, 각기 다른 부분과 독립적으로 확장할 수 있기 때문입니다.  데이터베이스는 scale up 확장하고 응용프로그램은 scale out 확장합니다.

응용프로그램은 데이터베이스에 상태를 저장해야 서버를 추가하여 수평으로 확장할 수 있습니다.

scale up 확장 전략의 문제는 중복의 부족입니다. 클러스터 광고가 더 신뢰가 가지만, 개별 장비들이 비싸기 때문에 매우 비쌉니다.

소수의 응용프로그램은 프로세스 개수에 따라 선형적으로 확장할 수 있습니다. 락(Lock)은 프로세싱을 직렬화하면서 발생할 수 있으며 결국 Big Iron(프로세스)의 유효성을 감소시킬 수 있습니다.

7U 전력과 냉각기 같은 커다란 부품은 심각한 이슈입니다. 1U와 7U 사이의 뭔가를 사용하면 데이터센터에서 일하기가 수월해집니다.

더 많은 데이터베이스 서버를 추가할 수도록 SQL 서버 라이선스 비용은 너무 충격적일 수 있습니다. Scale up으로 시작하고 점차 오픈소스가 아닌 소프트웨어로 scale out을 하면 재정적으로 상처를 받을 수 있습니다.

Stack Overflow에 대한 내용이 많이 없는 것이 사실입니다. 우리는 그들의 장비, 도구 사슬과, 그들이 웹서버 코드에서 직접 데이터베이스에 접근하는 2-tier 아키텍처를 사용한다는 것을 압니다. 우리는 태그와 같은 것을 구현한 방법을 모릅니다. 관심이 있다면 explanation of their schema로부터 정보를 얻을 수 있습니다. 둘다 논란이 많고 흥미로운 토론의 주제입니다.

토론

아키텍처 프로파일 후보에 따르면 Stack Overflow는 2개의 중요한 HighScalability 배지를 받았습니다.: Microsoft Stack 배지와 Scale Up 배지.

Microsoft Stack Badge

Stack Overflow 가 전반적으로 Microsoft Stack 을 사용하기 때문에 Microsoft Stack 배지를 받았습니다: OS, database, C#, Visual Studio, ASP .NET.  사람들은 LAMP와 어떻게 비교되는가에 항상 관심을 가지지만,  저는 이 비교를 보여줄 사례 연구가 많이 없습니다..

Plenty of Fish의 Markus Frind는 가끔 Microsoft stack을 전형적으로(poster child)로 사용하기로 유명하지만, 분명히 가능한 조금만 stack을 사용하기 때문에 좋은 예는 아닙니다. 반대로 Stack Overflow는 때때로 퇴짜를 맞을지라도 MS에 대한 사랑을 보여주는데 자신만만합니다.

라이선스로 인해 함께하는 경향이 있기 때문에 Microsoft stack과 scale up 접근법을 분리하기 어렵습니다. 수십개의 코어를 추가하여 Scale up에서 scale out으로 전환하는 위치에 있다면, MS 라이선스가 여러분을 꽉 물어뜯을 것입니다.

라이센싱을 제쳐두고 C#, Visual Studio, .Net이 매우 생산적인 환경임을 발견했습니다. . C#/.Net은 Java/JVM. ASP .NET이 항상 나를 항상 엉망으로 혼란시켜 온 것만큼 좋습니다. SQL Server에 대한 두드림은 비용을 지불할 수 있는가이며 만약 여러분을 괴롭히지 않는다면 탄탄한 선택입니다. Windows 운영체계는 다른 대체 운영체계처럼 믿음직스럽지 않지만 잘 동작합니다.

특별히 여러분이 Windows 중심으로 일하고 있다면, 여기까지가 Microsoft  stack으로 작업하는 scale up 솔루션입니다.

Scale Up Badge

scale out 대 scale up, 임대 대 구매 전쟁을 재현하고 싶지 않습니다. 이런 이슈의 철저한 토론은 Scaling Up vs. Scaling Out 와 Server Hosting — Rent vs. Buy? 을 보도록 하세요. 여러분이 혼란스럽지 않고 다 읽은 후에도 상처받지 않는다면 아마도 자료들을 이해하지 못한 것입니다

Stack Overflow은 그들의 확장 요구사항을 접하기 위한 scale up 전략을 사용했기 때문에 Scale Up 배지를 수여했습니다. Stack Overflow가 제한에 도달했을 때, 더 큰 장비와 더 많은 돈을 추가하여 수직으로 확장하였습니다.

Stack Overflow는 scale up을 위한 달콤한 곳입니다. 너무 크지도 않고, Alexa 순위 1666 등이고 월 16백만 페이지뷰를 가지고 있는 상당히 큰 사이트입니다. Google 규모는 아니지만, 아마도 그럴 필요도 없지만, 많은 사이트들이 가지고 싶어 열광할 것입니다. 게다가 그들은 많은 미디어도 올리지 않았습니다. 그들은 수백만의 사용자와 함께 하는 복잡한 소셜 네트워크를 이용한 수십억의 트윗도 하지 않았습니다. 그들의 사용자 수는 자기 제한입니다. 그리고 그들이 확장하고자 할 때 취할 수 있는 방향들이 여전히 있습니다.(caching, 더 많은 웹 서버, 빠른 디스크, 더 많은 반정규화, 더 많은 메모리, 약간의 파티셔닝 등). 모든 것에서 잘 만들었고 2-tier CRUD 응용프로그램으로 매우 쓸만합니다.

NoSQL is Hard

이 경우에 Stack Overflow 가 scale up 대신에 scale out을 했다면 어떻게 되었을까요?

드러나지 않은 것이 NoSQL이 어렵다는 것입니다. 관계형 데이터베이스는 많은 단점이 있지만, 비용과 복잡성을 감춰주면서 일반적인 많은 작업을 간단하게 만들어줍니다. 공장에 얼마나 많은 검정 Prius가 있는지 알아내는 것은 매우 쉬운 작업입니.

대부분의 NoSQL 데이터베이스에 대한 것이 아닙니다(여기서 일반적으로 말하자면, 몇몇 NoSQL 데이터베이스 다른 것에 비해 더 많은 기능을 가지고 있습니다). 여러분이 앞에서 예를 든 검은 Prius 차의 대수를 파악하는 프로그램 코드를 가지고 있을 수 있습니다. 어떤 합계(aggregate) 연산자도 없습니다. 여러분은 2차 인덱스를 관리해야 합니다. 검색도 없습니다. 파티션을 넘어스는 분산 질의도 없습니다. Group By 또는 Order By도 없습니다. 결과 집합을 쉽게 페이징하는 커서도 없습니다. 100개의 큰 레코드를 한번에 리턴하면 시간초과가 될 것입니다. 작업을 위한 IO 양의 제한 때문에  매우 한정적인 할당이 있을 것입니다. 질의 언어는 표현력이 부족합니.

이 모든 것의 가장 큰 문제는 트랜잭션이 임의의 경계를 넘을 수 없다는 것입니다. 단일 레코드나 작은 entity group 을 넘어서는 ACID 보장도 없습니다. 여러분이 머리를 한번만 굴려봐도 프로그래머에게 결코 즐거운 전망을 주지 않는 것을 알 수 있습니다. 참조는 수동으로 관리되어야 합니다. 관계도 수동으로 관리되어야 합니다. 실패가 발생할 때 정확하게 동작하는 cascading 삭제도 없습니다. 반정규화된 모든 복제는 수동으로 추적해야 하고 부분적인 실패의 가능성과 외부적인 뚜렷한 일치하지 않는 계정을 감안하기 위해 업데이트 되어야 합니다.

이런 모든 기능은 여러분이 직접 작성해야 합니다. 유연성 때문에 코드 작성은 OLAP/map-reduce 상황처럼 커지거나, 서술적인 접근법은 여전히 매우 커지거나 잘 깨지지 않는 코드로 만들어야 합니다.

여러분이 얻는 것은 대용량의 데이터를 쓰는 능력입니다. 잃는 것은 만족입니다. 프로그래머는 분산 동작에는 비용이 들고 장애가 언제든지 일어나는 시스템을 다루고 있다는 것을 항상 잘 알고 있어야 합니다.

이 모든 것이 진정한 확장과 분산 시스템 구축의 가격이지만, 정말로 여러분이 지불하고 싶은 가격입니까?

다중임대 문제(The Multitenancy Problem, HTTP://EN.WIKIPEDIA.ORG/WIKI/MULTITENANCY)

StackExchange를 통해 Stack Overflow는 자임대 사업을 하고 있습니다. Stack Overflow는 직접 호스팅이나 white label application 호스팅으로 StackExchange를 제공합니다.(http://en.wikipedia.org/wiki/White-label_product)

그들의 아키텍처가 매우 많은 사이트를 처리하기 확장되는지 보는 것은 매우 재미있습니다. Salesorce 는 다중임대의 제왕이고 오라클을 데이터베이스로 사용한다고 해도, 기본적으로 오라클을 매우 적게 사용하며 오라클 위에 자신의 테이블 구조와 색인과 질의 처리기를 작성했습니다. 이 모든 것이 다중임대를 지원하기 위한 것입니다.

많은 다른 사용자를 지원하는 일은 특별히 커스터마이징을 허용하고 버전컨트롤을 지원하는 일이 보여지는 것과는 다르게 어렵기 때문에 Salesforce는 극단적입니다.

분명하게 모든 사용자들이 보안, 커스터마이징, 확장 이유 때문에 하나의 서버에서 동작하지 않습니다.

사용자를 위해 데이터베이스를 생성하고, 특정 사용 단위로 서버를 공유하고, 필요한만큼 서버를 추가하면 될 거라 생각할 수 있습니다. 사용자들이 하나의 서버만 필요하다면 여러분은 대박입니다.

이런 일은 실제로 잘 일어나지 않는 것 같습니다. 이상하게도 데이터베이스 관리자는 데이터베이스를 추가하거나 업데이트를 위해 최적화하지 않습니다. 데이터베이스 생성은 매우 무거운 동작이고 현재 고객들에게 시스템에 락킹이 발생한 것 처럼 성능을 저하시킵니다. 업그레이드 이슈 또한 문제가 있습니다. 컬럼을 추가하는 것은 높은 트래픽 상황에서 문제인 테이블 락을 발생시킵니다. 새로운 인덱스 추가도 또한 매우 긴 시간이 걸리며 성능을 저하시킵니다. 사용자들은 업그레이드를 더욱 복잡하게 만드는 전문성(specializations)을 가지고 있습니다.

이런 문제를 처리하기 위해 Salesforce의 아키텍트 수석인 Craig Weissman은, 테이블이 고객별로 생성되지 않는 혁신적인 접근법을 고안했습니다. 모든 고객들로의 모든 데이터는 인덱스를 포함하여 같은 데이터 테이블로 맵핑됩니다. 이런 테이블의 스키마는 orgid, oid, value0, value1, value 500과  유사합니다. “orgid”는 조직 ID이고 데이터가 결코 섞이지 않는 방법입니다. 매우 광범위하고 드문 테이블인데, 오라클이 매우 잘 처리합니다. 수만개의 테이블과 고객 필드는 데이터 테이블로 맵핑됩니다.

이런 접근방법으로 Salesforce는 어떤 별도의 옵션을 가지지 않고 테이블에 어떤 것이 있는지 해석하는 인프라를 구축했습니다. 오라클은 트랜잭션, 일치, 데드락 발견을 처리하기 위해 사용됩니다. 장점은 버전관리를 처리하는 인터프리트 레이어가 있기 때문이며, 처리 로직을 만들었기 때문에 상대적으로 간결한 것입니다. 낯설지만 사실입니다.

읽을 거리

이 목록은 Jeff 가 Stack Overflow에 연대기로 기록한 몇 가지 게시물입니다. Jeff 는 무엇을 왜 했는지에 대해 공개하는데 놀라울 정도입니다. 댓글은 종종 엄청납니다. 배울 게 많이 있습니다.

Learning from StackOverflow.com by Joel Spolsky

Scaling Up vs. Scaling Out: Hidden Costs by Jeff Atwood

What Was Stack Overflow Built With?

New Stack Overflow Server Glamour Shots

New Stack Overflow Servers Ready

Server Hosting — Rent vs. Buy? - 임대와 구매간의 찬반논쟁의 유익한 토론입니다.

Rent vs. Buy (or EC2 vs. building your own iron) by Michael Friis

Oh, You Wanted "Awesome" Edition - -최근에 데이터베이스 서버의 램을 48GB로 업그레이드 하였습니다. – 하드웨는 저렴하고, 프로그래머는 비싸기 때문입니다.

Our Backup Strategy - Inexpensive NAS

The Economics of Bandwidth

Understanding the StackOverflow Database Schema by Brent Ozar

Server Speed Tests - new hardware 2x slower - it was the network.

ASP.NET MVC: A New Framework for Building Web Applications

Three key things to know about moving MySQL into the cloud by morgan

NoSQL Conference

Decline of the Enterprise Data Warehouse by Bradford Stephens

Webinar: Multitenant Magic - Under the Covers of the Force.com Data Architecture by Craig Weissman, Chief Architect, salesforce.com.