CSE 452: Google의 분산 시스템 설계 입문

AI 요약

이 글은 Steve Yegge가 2011년 Google 내부에 올리려다 공개된 글입니다. Amazon과 Google을 비교하는 거친 도입부 뒤에서, 대규모 조직이 서비스 지향 아키텍처(Service-Oriented Architecture, SOA)와 플랫폼을 어떻게 설계해야 하는지 설명합니다. 당시 글의 문제의식은 오늘날의 API, 서비스 디스커버리, 운영 자동화, 서드파티 생태계 설계와 직접 이어집니다.

Amazon의 강제적인 서비스 전환

Jeff Bezos는 2000년대 초 모든 팀이 데이터와 기능을 서비스 인터페이스로 노출하라고 지시했습니다. 팀 사이의 통신은 네트워크를 거치는 서비스 호출만 허용했습니다. 직접 링크, 다른 팀 데이터베이스 직접 조회, 공유 메모리, 비공식 백도어는 금지했습니다. HTTP, CORBA, PubSub, 자체 프로토콜처럼 어떤 기술을 쓰는지는 중요하지 않았습니다.

특히 모든 서비스 인터페이스를 처음부터 외부 개발자에게 공개할 수 있는 형태로 설계하라고 요구했습니다. 내부 전용 API를 만들고 나중에 외부 공개용으로 고치는 방식이 아니라, 처음부터 외부화 가능성을 설계 조건에 넣으라는 뜻입니다. Yegge는 이 정책이 Amazon 전체를 몇 년에 걸쳐 서비스 중심 조직으로 바꿨다고 설명합니다.

SOA가 드러낸 운영 문제

Amazon은 서비스 전환 과정에서 기존 SOA 문서만으로는 해결되지 않는 문제를 대규모로 발견했습니다.

• 장애 티켓이 여러 서비스를 거치면서 실제 담당 팀을 찾기 어려워집니다. 호출 경로가 20개 서비스로 이어지고 각 팀의 응답 시간이 15분이라면, 적절한 담당자를 찾는 데 몇 시간이 걸릴 수 있습니다. 호출 경로, 에스컬레이션, 지표, 리포팅을 위한 별도 기반 시설이 필요합니다.
• 모든 동료 팀이 잠재적인 서비스 거부 공격자처럼 바뀝니다. 악의가 없어도 한 팀의 과도한 호출이 다른 팀의 처리 용량을 소진할 수 있습니다. 따라서 모든 서비스에 쿼터와 스로틀링을 마련해야 합니다.
• 모니터링과 품질 검증의 경계가 흐려집니다. 서비스가 정상이라고 응답하는 작은 구성 요소만 살아 있고 실제 기능은 망가진 상황이 생길 수 있습니다. 서비스가 실제로 동작하는지 확인하려면 개별 API를 호출하고 결과의 의미까지 검사해야 합니다. 전체 서비스와 데이터에 대한 의미 검사가 늘어나면 모니터링은 자동화된 QA와 구분하기 어려워집니다.
• 서비스가 수백 개로 늘면 서비스 디스커버리가 필수가 됩니다. 디스커버리를 사용하려면 서비스 등록이 필요하고, 등록 시스템 자체도 하나의 서비스가 됩니다. Amazon은 각 서비스의 API, 실행 상태, 위치를 프로그램으로 조회하는 범용 서비스 레지스트리를 구축했습니다.
• 다른 팀의 코드에서 발생한 문제를 디버깅하기가 훨씬 어려워집니다. 모든 서비스를 디버깅 가능한 샌드박스에서 실행하는 보편적인 표준이 없으면, 서비스 경계를 넘은 장애를 재현하기 어렵습니다.

Yegge는 이런 문제를 단순한 부작용으로 보지 않습니다. 서비스가 외부 개발자에게 공개된다고 가정하면 팀은 다른 팀을 내부 사용자라고 믿기보다, 외부 사용자를 대하듯 명확한 계약과 제한을 마련하게 됩니다. Amazon은 해고가 두려워서 시작한 정책을 시간이 지나며 설계의 기본 원칙으로 받아들였다고 설명합니다.

서비스에서 플랫폼으로

Yegge가 말하는 플랫폼은 내부 시스템을 서비스로 쪼개는 데서 끝나지 않습니다. 서비스 인터페이스를 외부 개발자가 조합하고 새로운 제품을 만들 수 있는 기반으로 공개해야 합니다. Amazon이 서점 운영에 쓰던 인프라를 Amazon Elastic Compute Cloud(Amazon EC2), Amazon Elastic MapReduce, Amazon Relational Database Service(Amazon RDS) 같은 서비스로 확장한 사례가 대표적입니다.

그는 Amazon이 모든 사용자를 만족시키는 하나의 제품을 직접 만들 수 없다는 사실도 이해했다고 봅니다. 다양한 사용자의 요구를 회사가 전부 예측하는 대신, 인터페이스와 워크플로를 외부 개발자에게 제공하면 각자가 서로 다른 제품을 만들 수 있습니다. Yegge는 이 성질을 Accessibility라고 부릅니다. 여기서 접근성은 장애인 지원만 뜻하지 않습니다. 하나의 제품 설계가 모든 사람에게 맞을 수 없으므로, 플랫폼이 다른 팀과 개발자에게 선택권을 제공해야 한다는 주장입니다. 글에서는 Accessibility와 Security를 대비하며 이 주장을 과장된 비유로 밀어붙이기도 합니다.

Google의 제품 중심 문화 비판

Yegge는 Google이 플랫폼을 이해하지 못한다고 주장합니다. Google은 검색처럼 넓은 사용자를 확보한 제품을 직접 만들고 성공시킨 경험이 강해, 제품을 먼저 만든 뒤 나중에 API를 붙이려는 경향을 보인다는 설명입니다. 하지만 플랫폼은 나중에 덧붙이기 어렵고, 처음부터 플랫폼으로 설계해야 한다고 강조합니다.

Google+를 대표 사례로 듭니다. 글이 쓰인 당시 Google+는 출시 시점에 API가 없었고, 나중에 공개된 API도 사실상 한 가지 호출에 그쳤다고 비판합니다. 반면 Facebook은 기본 소셜 서비스 자체를 다른 개발자가 활용하도록 만들었고, Mafia Wars와 FarmVille 같은 다양한 애플리케이션이 플랫폼 위에서 생태계를 구성했다고 설명합니다. Facebook이 모든 사용자의 취향을 직접 예측한 것이 아니라, 외부 개발자가 각기 다른 수요를 채우게 했다는 분석입니다.

이를 플랫폼의 황금률인 Eat Your Own Dogfood로 정리합니다. 내부 팀이 공개 플랫폼을 직접 사용해야 API가 실제 요구를 충족하고, 조직이 플랫폼의 문제를 먼저 경험합니다. 내부 제품에만 통하는 비공개 경로를 남겨두면 외부 개발자가 겪는 제약을 조직이 알기 어렵습니다. Microsoft는 오랜 기간 개발 플랫폼을 운영하면서 이 문화를 익혔고, Amazon은 AWS를 통해 뒤늦게 전환했습니다. Apple은 폐쇄적인 선택을 하면서도 서드파티 개발과 API 품질을 이해하고, 자사 플랫폼을 직접 사용한다고 평가합니다.

늦게 붙이는 API의 비용

Yegge는 Google이 팀 단위로 조금씩 서비스 API를 제공하는 방식만으로는 부족하다고 말합니다. Stubby 같은 내부 RPC 도구가 있어도 서비스 디스커버리, 호출 제한, 모니터링, QA, 디버깅 샌드박스 같은 운영 문제를 자동으로 해결하지는 않습니다. 플랫폼을 만들려면 이런 기반 기능과 외부 공개 정책을 조직 전체가 함께 설계해야 합니다.

Google Maps, Docs, Gmail처럼 플랫폼 가능성을 가진 제품을 언급하면서도, Google의 개발자 포털과 API가 Microsoft나 Amazon에 비해 빈약하다고 지적합니다. Google+의 실패도 특정 팀 한 곳의 문제라기보다, 제품을 먼저 만들고 확장성을 나중에 고민하는 회사 문화의 결과로 봅니다. 플랫폼화가 늦어질수록 처음부터 설계했을 때보다 훨씬 많은 작업이 필요하며, 내부용 백도어를 유지한 채 외부 API만 덧붙이는 방식으로는 문제를 해결하기 어렵다고 주장합니다.

글의 주장은 특정 회사의 2011년 상황에 대한 강한 의견이지만, 서비스 경계가 호출 체인, 장애 전파, 레이트 리밋, 디스커버리, 관측성, 디버깅 환경을 함께 요구한다는 설명은 분산 시스템 설계의 실제 비용을 구체적으로 보여줍니다. 동시에 API를 공개하는 일과 플랫폼을 만드는 일을 구분합니다. 플랫폼은 서비스 목록을 내놓는 데서 끝나지 않고, 다른 개발자가 회사가 예상하지 못한 제품을 만들도록 내부 시스템과 외부 인터페이스를 같은 기준으로 설계하는 작업입니다.

Reddit 반응

• @u/boboman911 — 링크에는 15년 전 Google이 PaaS 회사가 되지 못한 일을 다룬 흥미로운 글이 나옵니다.
  • @u/fagnerbrack — 혼란을 드려 죄송합니다. 예전에 맥락 없이 강의나 논문을 올렸다가 지적을 받은 적이 있습니다. 제목이 좋지 않았을 수도 있지만, 이 글을 읽기 전까지 존재하는지도 몰랐던 강의에 대한 지식과 누군가의 의견을 함께 공유하고 싶었습니다.
• @u/FlatProtrusion — 비난조 글이 아닌 원래 강의 링크입니다: https://courses.cs.washington.edu/courses/cse452/22wi/ 그리고 게시자가 다시 강의 링크로 바꿀 경우를 대비한 글 링크입니다: https://courses.cs.washington.edu/courses/cse452/23wi/papers/yegge-platform-rant.html
  • @u/st4rdr0id — 강의 내용은 조금 오래되어 보입니다. RPC와 전이 시스템을 다룬 뒤 BigTable 같은 여러 선행 시스템을 소개합니다.
• @u/D3PyroGS — 2011년에 읽어도 재미있는 글이었고, 15년이 지난 지금 읽어도 똑같이 재미있습니다.
  • @u/st4rdr0id — 언급된 회사들의 업무 문화가 지금도 여전히 같은지 궁금합니다.
  • @u/qckpckt — 그렇지 않습니다. 훨씬 더 나빠졌기 때문입니다.
  • @u/boboman911 — Google은 Amazon처럼 변하고 있습니다. 복지는 나빠졌고, 조직은 이제 완전히 하향식이며, 서비스 전체를 API로 공개하지도 않습니다. 예전보다 나아지기는 했지만 말입니다. 동료 보너스는 인플레이션을 반영하지 않아 우스운 수준이고, 여전히 새로운 것을 만들기보다 반응적으로 제품을 만듭니다. 게다가 모두가 해고를 두려워합니다.
  • @u/Wonnk13 — 저는 2020년에 퇴사했고, 당시에도 그렇게 느꼈습니다. 지금은 어떤지 상상하기 어렵습니다.

원문: Reddit / 번역·요약: Trawling