10 17 Reading_Assignment_3(20094068 3학년 이준서) - JunSeoLee/project_team_5 GitHub Wiki

###Facebook 공개 엔지니어링 은밀히 들여다보기(취재하다)

Facebook은 캘리포니아 Menlo Park 안에 옛날 Sun Microsystems가 썼던 곳을 본사로 사용하고 있다. 영화 "The Social Network" 덕분에, Facebook이 기숙사 방 프로젝트에서 세계에서 두 번째로 큰 웹사이트로 성공하기까지의 놀라운 이야기를 다들 알게 되었지만, 동시에 매일 수 억명의 사용자들에게 상호작용하는 웹 경험을 전달하는 매우 복잡한 기술 인프라 인, Facebook의 덮개 밑에 돌아가는 엔진에 대한 아주 흥미로운 이야기는 오직 소수의 사람들만이 알고 있다. 그런데 Facebook은 나에게 독점적으로 새로운 기능들을 배포하는 과정을 은밀히 들여다 볼 수 있는 기회를 주었다. 나는 브랜드 페이지들을 위한 새로운 "timeline" 기능이 출시되는 것을 Facebook 릴리즈 엔지니어들과 같이 직접 지켜보기로 하였다. 가는 길에 눈에 뛰는 것들이 많았다. 워크스테이션들이 공유된 책상에 나란히 올려져 있고 개개인 사이에는 벽(파티션)이 없었다. 그리고 각 건물마다 미팅 룸들이 재미있게 이름이 붙여지고 있었다. 릴리즈 엔지니어링 팀의 본부가 있는 곳에 도착했다. 다른 개발자들과 마찬가지로 릴리즈 엔지니어링 팀도 오픈 워크스테이션을 이용하고 있었다. 하지만 그들의 공간은 특별한 것을 가지고 있었는데 바로 잘 갖춰진 "hotfix"라는 바(bar)이다 바로 그 곳에서 릴리즈 엔지니어링 리더인 Chuck Rossi를 만났다.

Facebook의 BitTorrent 배포 시스템

Facebook의 소스 코드는 주로 PHP라는 프로그램 언어로 짜졌는데 PHP는 빨리 개발하기에는 좋지만 저수준 언어의 성능과 몇몇 최신 대안들에 대해서는 부족하다. 그리하여 Facebook은 PHP 기반의 인프라스트럭쳐의 확장성을 향상시키기 위해, Facebook은 HipHop이라고 부르는 PHP를 엄청나게 최적화 된 C++ 코드로 변환시키는 특별한 코드 변환기를 개발했는데 이는 효과적인 네이티브 바이너리로 컴파일 할 수 있도록 만들어준다. 페이스북이 2010년에 HipHop을 공개하고 오픈소스 라이센스로 배포하기 시작하면서, 회사의 엔지니어들은 Facebook의 CPU 소모량을 50%정도 줄였다고 했다.

Facebook의 전체 code base는 하나의 실행가능한 바이너리로 컴파일 되기 때문에, 일반적인 PHP 환경에서의 포로세스와는 다르다. Rossi는 Facebook은 애플리케이션 전부를 나타내는 그 바이너리는 대략 1.5 GB라고 밝혔다. 즉 업데이트를 하면 빌드 할 때 마다 모든 서버에 push되어야 한다. 1.5 GB의 바이너리를 셀 수 없이 많은 서버로 옮기는 것은 기술적으로 중대한 도전이다. 몇몇 솔루션들을 탐색하면서 Facebook은 유명한 P2P 파일 공유 프로토콜인 BitTorrent를 사용하는 아이디어를 도출해냈다. Rossi는 Facebook이 자신들만의 BitTorrent tracker를 만들었으며, 이는 Facebook의 인프라스트럭처가 전체(네트워크) 대기시간을 감소시키기 위해 같은 노드(node)나 랙(rack) 상에 있는 다른 서버들로부터 바이너리 조각들을 얻도록 시도하게끔 디자인 되었다. Facebook update가 배포 되는데는 평균 30분이 소요되는데, 15분은 실행가능한 바이너리를 생성하는데 소요되며, 나머지 15분은 바이너리를 BitTorrent를 통해 Facebook 서버들에 push되는데 소요된다. 물론 실행 가능한 바이너리는 페이스북 애플리케이션 스택에 있어 한 부분에 불과하다. Facebook 페이지에서 JavaScript, CSS, 그래픽 자원 등 많은 외부 리소스들이 참조되고 있다. 그러한 파일들은 지역적으로 분산된 CDNs(Content Delivery Networks)을 통해 제공된다. Facebook은 매일 마이너 업데이트를 진행하는데 메이저 업데이트는 일주일에 한번 진행된다. 잦은 업데이트는 Facebook 개발 철학에 있어 중요한 부분이다. Facebook은 초기에 개발자들은 웹사이트를 계속적으로 개선시키기 위해 빠른 iteration과 점진적인 engineering을 사용해왔다. Rossi는 높은 품질과 탄탄함에 대한 높은 수준의 기준을 세웠지만, 솔루션을 찾기 위해서는 기대하지 않는 방식을 수용할 만큼 충분히 유연했다.

Testing

최근 빠르게 릴리즈하려고 하는 흐름에 대한 도전과 보상에 대해 썼었다. 이런 속도로 운영할 때 중요한 하나는 높은 품질을 유지하는 것이다. 즉, 베타 테스팅을 위한 시간이 줄어든다는 문제를 야기한다.

매일 새로운 변화를 반영해야 하는 Facebook에겐 품질 테스팅은 하나의 도전이다. 직원들에게 테스트 사이트를 기본 페이지로 만드는 것은 곧 출시된 기능들을 릴리즈되기 전에 더 많이 노출되도록 한다. 테스트 사이트는 몇몇 버그 리포팅 툴들이 있는데, 이는 직원들이 테스트하면서 이슈들을 발견했을 때 쉽게 피드백을 줄 수 있게 해준다. Facebook은 자동화된 테스트들을 사용하고 있다. 이들 테스트들은 두개의 세트를 갖고 있는데, 그 중에 하나는 맨 정신으로 checking하는 것이고 다른 하나는 웹사이트에서 사용자 인터페이스가 사용자의 상호 작용을 시뮬레이션 하는 것이다. 모든 업데이트를 출시하기 전에, 먼저 새로운 코드는 "a2"라고 불리는 얼마 안 되는 Facebook의 프로덕션 서버에 적용된다. 이 단계에서 많은 Facebook의 랜덤 사용자들에게 그 업데이트를 노출시켜주지만, 여전히 사이트 전체 사용자 중에선 극히 일부이다. 그리고 이 단계는 Facebook 엔지니어들은 프로덕션 환경에서 업데이트가 어떻게 작동하는지 지켜본다.

배포하기 전 상황

Facebook은 내부 협업을 위해서 자체 IRC 서버를 관리하고 있다. Facebook의 툴 개발자들은 IRC를 Facebook의 개발과 deployment workflow에 통합하기 위해 다양한 종류의 기능을 제공하는 IRC 로봇들을 만들었다. Rossi가 업데이트를 반영하려고 할 때, 그는 IRC에서 체크인 프로시저를 시작했다. Facebook의 개발 문화에서 중요한 점은 프로덕션 환경에서 개발자들이 그들의 소스 코드가 어떻게 동작하는 지에 대한 모든 책임을 진다는 것이다. 이런 철학은 소프트웨어 개발과 운영 사이의 벽을 낮추는 것을 장려하는 "DevOps"라는 움직임을 반영한 것이다.

Deployment

Rossi는 소스 코드를 배포하는 동안 소수의 시스템들이 업데이트를 실패하는 것은 흔히 본다고 말했다. 그것은 보통 하드웨어 문제 때문에 발생된다고 했다 예를 들면, 서버의 저장 공간 용량이 낮거나 파일을 토렌토를 통해 다운받는 동안 네트워크 이슈가 발생해서 서버가 업데이트를 실패할 수 있다. 소프트웨어가 서버에 배포되는 동안, Rossi는 Facebook의 아키텍쳐의 몇몇 특징들이 어떻게 업데이트 과정동안 영향을 주는 지 설명해주었다. Facebook은 사용자의 세션이 특정 서버에 묶이지 않는다는 의미에서 무상태(stateless)와 분산 처리 되도록 디자인되어졌다. 어떤 페이지가 요청되어 지면 Facebook의 인프라스트럭쳐 안에서 어떤 서버든 처리할 수 있다. 이런 처리 방법은 많은 복원력을 준다.
Facebook이 업데이트를 수행할 때 사용자 세션들의 상태를 이전하거나 직렬화 하는 것에 대해 걱정하지 않아도 된다. 배포 시스템은 서버들이 업데이트를 받자마자 연달아 실행가능한 Facebook 프로세스들을 다시 시작한다. 회사의 인프라스트럭쳐를 통해서 업데이트가 출시되고 있는 동안에도 이전 버젼을 여전히 돌리고 있거나 아니면 벌써 끝낸 서버들은 계속해서 다음 페이지 요청들을 처리할 수 있다. Facebook은 업데이트하는 동안에도 서비스를 완전 가동한다.

업데이트 후 점검

업데이트를 완료한 후에, Rossi는 새로 반영된 것들이 어떤 걸 깨뜨리지 않았는지 확인하기 위해 시스템의 다양한 면들을 살펴본다. 이들 바이탈 사인의 변동을 지켜보는 것은 시스템 안에서 Facebook이 문제들을 찾는 데 도움이 된다. 지난 데이터와 비교하는 것은 문제가 발생할 때 어디서 그랬는지 정확하게 집어내는 걸 도와준다. 만약 어떤 문제가 발견되면, 시스템의 일부에서 예기치 않은 높은 에러 비율 같은, 회사의 엔지니어들은 정확히 어떤 일이 벌어지고 있는지 보기 위해서 에러 로그들을 파헤친다. 에러 로그들을 보여주고 분석하는 Facebook의 내부 툴들은 사용자가 특정 에러 메시지와 관련된 코드의 변화들을 쉽게 볼 수 있게 해준다. 많은 데이터 소스들은 Facebook의 내부 모니터링 툴에 의해서 Facebook에 대한 트윗들까지 추적된다. 이 정보들은 Facebook에 대해 긍정적인 발언과 부정적인 발언의 양의 변화를 각각 다른 추세선(trend line)으로 보여준다. 이것은 유용하다. 왜냐면, 사람들이 소셜네트워크 사이트에서 기술적인 문제에 부딪힐 때 하는 것 중에 하나가 다른 소셜네트워크에서 그것에 대해 컴플레인하는 것이기 때문이다.

패배자들이나 되돌린다.

Rossi는 "Reverting은 루저들이나 하는거죠" 라고 말했다. 그는 이전 버전으로 되돌리기 위한 장치에 대해 설명에 들어갔다. 그러나 이건 마지막 수단의 조치로 쓰여 진다. 서버들은 이전 버전의
Facebook 바이너리 코드를 가지고 있고 만약 이것이 절대적으로 필요하다면 그들로 다시 되돌릴 수 있다고 했다. 그는 Facebook에서 이전 버전으로 돌리는 일은 기차의 비상정지 손잡이를 당기는 것과 약간 비슷하다고 말했다. 바람직하지 않고, 거의 일어나지 않는. 그가 Facebook에 있는 동안 몇 번 없었다고 한다. Facebook의 테스트 습관과 개발자 책임 문화는 심각한 버그가 프로덕션 코드에 반영되는 것을 막는데 도움이 된다. 회사의 사내 툴에는 Rossi가 (인사) 점수 관리를 위해 Facebook과 비슷하게 만든 장치가 있다. Facebook의 모든 개발자들은 코드 리뷰 시스템에 의해 추적되는 "카르마" 순위를 가지고 있다. Rossi의 툴에 '위' 아이콘은 Facebook의 '좋아요' 기능과 같은 것이다. '아래' 버튼은 같은 아이콘을 뒤집어 놓았다. 이 카르마 점수는 회사가 실적이 좋지 않은 직원을 찾아내는데 도움이 되지만, 또한 코드 리뷰 과정에도 도움이 된다. 만약 카르마 점수가 낮은 엔지니어가 코드 머지(merge)를 제안하면 Rossi는 만약 그 코드를 받아들일 경우 잠재적으로 높은 위험이 있을 수 있다는 것을 한눈에 알 수 있게 된다. 낮은 카르마를 갖은 직원들은 실적을 올려 포인트를 다시 얻을 수 있다.

미래

Rossi의 비전에 대해서 이야기했다. Rossi는 미래 개발들은 그의 팀이 극적으로 출시 프로시저를 가속화시켜서 전체 빌드를 하고 배포하는 시간을 현재의 30분보다 훨씬 더 단축 시길 수 있을 거라고 말했다. HipHop transpiler를 대체하는 프로젝트는 Facebook에서 공들여 개발을 진행하고 있는 것 중의 하나이다. Facebook 개발자들은 더 강화된 플랫폼의 다음 세대를 만들기 위해 그들의 자체 바이트코드 포맷과 HipHop 가상머신이라고 불리는 커스텀 run-time 환경을 만들고 있다. 이 프로젝트가 끝나면 Facebook은 PHP 소스코드를 가상머신 상에서 실행될 수 있는 바이트코드로 컴파일 할 수 있게 된다.

오랜 배포 과정이 필요 없이 몇 분 안에 업데이트를 배포하는 것이 가능할 때, Facebook은 그동안 해왔던 업데이트 일정을 버리고 변경된 것들이 개발 되자마자 바로 출시되는 모델로 이동이 가능할 것이다.
Facebook은 사용자에게 경험을 나누고 그들의 개인적인 이야기들을 적는 플랫폼을 제공하는 것에 더욱 더 중점을 두게 만들 것이다. 이런 능력을 발휘할 수 있게 해주는 기술적인 인프라스트럭쳐는 그것만의 이야기를 가지고 있다. 정체성은 Facebook만의 개발자 문화에 달려있다.

나의 생각 내 집 같은 직장, 색다른 시도, 자신들 만의 기술연구, 지속적인 업데이트가 있기에 페이스 북이 이렇게 성장하지 않았나 싶다.