마이크로서비스 채택한 넷플릭스: 팀 및 프로세스 설계를 위한 교훈

이전 포스트에서는 넷플릭스 에서 웹 엔지니어링 디렉터와 클라우드 아키텍트로 근무한 경험을 바탕으로 nginx.conf 2014에서 발표한 Adrian Cockcroft의 발표를 바탕으로 마이크로서비스 아키텍처 설계를 위한 모범 사례를 공유했습니다. 이번 후속 포스팅에서는 마이크로서비스 의 원활한 전환을 위해 개발팀과 프로세스를 재구성하기 위한 그의 권장 사항을 검토해 보겠습니다.

목차

1. 효율이 아닌 속도를 위한 최적화
2. 가정이 여전히 옳은지 확인하기
3. 인프라를 클라우드에 배치
4. 적은 프로세스로 높은 자유와 높은 책임의 문화 만들기
5. 사일로를 마이크로서비스 팀으로 대체하기
6. OODA 루프의 안내에 따라 마이크로서비스에 지속적 배포를 도입하세요.
7. NGINX Plus가 마이크로서비스에 어떻게 도움을 주나요?

1. 효율이 아닌 속도를 위한 최적화

Cockcroft가 넷플릭스에서 얻은 가장 중요한 교훈은 속도가 시장에서 이긴다는 것입니다. 개발자에게 개발 프로세스가 느린 것이 더 좋은지 물어보면 아무도 그렇다고 대답하지 않습니다. 경영진이나 고객도 개발 주기가 너무 빠르다고 불평하지 않습니다. 속도에 대한 필요성은 기술 기업에만 적용되는 것이 아닙니다. 자동차, 가전제품, 센서, 모바일 기기 등 사물 인터넷에서 소프트웨어가 점점 더 보편화됨에 따라 소프트웨어 개발을 전혀 하지 않던 기업도 이제 소프트웨어 개발을 잘하는 것이 성공의 관건이라는 사실을 깨닫고 있습니다.

넷플릭스는 일찍이 속도 최적화를 결정했습니다. 이는 특히 고객이 원하는 것에 빠르게 대응하거나 더 나아가 고객을 끌어들이는 혁신적인 웹 경험을 만들 수 있도록 소프트웨어 개발 프로세스를 툴링하는 것을 의미합니다. 속도란 고객에 대해 학습하고 경쟁사보다 더 빠른 속도로 고객이 원하는 것을 제공하는 것을 의미합니다. 경쟁업체가 특정 방식으로 도전할 준비가 되었을 대쯤이면, 이미 다음 개선 사항으로 넘어간 후입니다.

이 점근 방식은 효율성을 위해 최적화하는 일반적인 패러다임을 뒤집습니다. 일반적으로 효율성이란 비용을 절감하기 위해 개발 프로세스의 전반적인 흐름을 제어하여 노력의 중복을 없애고 실수를 방지하는 것을 의미합니다. 일반적인 결과는 수익을 높일 수 있는 기회를 찾는 대신 비용 절감에 집중하게 되는 것입니다.

Cockcroft의 경험에 따르면, “더 효율적이기 때문에 이렇게 하는 거야”라고 말하면 의도치 않게 다른 사람의 속도를 늦추는 결과를 초래할 수 있습니다. 이는 낭비를 부추기는 것이 아니라 속도를 먼저 최적화해야 한다는 뜻입니다. 속도를 늦추지 않는다는 제약 조건을 충족하면 효율성은 부차적인 문제가 됩니다. 비즈니스를 더 효율적으로 성장시키는 방법은 더 빠르게 나아가는 것입니다.

2. 가정이 여전히 옳은지 확인하기

시장에서 성공을 거둔 많은 대기업(기존 기업이라고 부를 수 있음)은 소비자 행동의 변화에 훨씬 더 빠르게 반응하는 더 민첩하고 규모가 작은 조직(파괴적 혁신 기업)에 추월당하고 있습니다. 예를 들어 넷플릭스 는 더 이상 작은 회사가 아니기 때문에 규모가 크다고 해서 반드시 문제의 근원이 되는 것은 아닙니다. Cockcroft가 보기에 기존 업계가 어려움을 겪는 주된 원인은 더 이상 사실이 아닌 비즈니스 가정에 따라 운영되고 있기 때문입니다.

물론 비즈니스 모델을 수립할 때는 가정을 세워야 하며, 그 가정을 바탕으로 비즈니스 관행을 최적화하는 것이 합리적입니다. 위험은 더 이상 사실이 아닌 가정을 고수할 때 발생하는데, 이는 잘못된 것을 기준으로 최적화하고 있다는 것을 의미합니다. 바로 이때 현재 비즈니스 환경에 맞는 올바른 가정을 세우고 최적화하는 업계 파괴적 혁신가에게 취약해질 수 있습니다.

예를 들어, 많은 기존 기업에서 영향력을 행사하는 다음과 같은 가정을 생각해 보십시오. 표시된 섹션에서 이러한 가정에 대해 자세히 살펴보고 넷플릭스 가 채택한 접근 방식을 설명하겠습니다.

• 컴퓨팅 파워는 비용이 많이 듭니다. 컴퓨팅 용량을 늘리려면 컴퓨터 하드웨어에 자본 지출이 필요했습니다. 인프라를 클라우드에 배치하기를 참조하세요.
• 프로세스가 문제를 예방합니다. 많은 회사에서 문제가 발생했을 때 표준적인 대응은 관련 절차에 예방 단계를 추가하는 것입니다. 프로세스를 줄이면서 자유롭고 책임감 높은 문화 만들기를 참조하세요.

유효기간이 지난 가정을 붙잡아 두지 않는 몇 가지 방법은 다음과 같습니다:

• 당연해 보일 수 있지만, 가정을 명확히 하고 주기적으로 검토하여 여전히 유효한지 확인해야 합니다.
• 기술 동향을 파악하세요. 예를 들어, SSD(solid-state drive) 스토리지의 비용은 계속 낮아지고 있습니다. 여전히 일반 디스크보다 비싸지만, 비용 차이가 점점 작아지고 있어 많은 기업이 우수한 성능을 위해 조금 더 지불할 가치가 있다고 판단하고 있습니다.
  
  [편집자 – 이 재미있는 동영상에서 Fastly의 설립자이자 CEO인 Artur Bergman이 SSD가 항상 올바른 선택이라고 믿는 이유를 설명합니다.]
• 고객이 아닌 사람들과 대화하세요. 이는 잠재적인 신규 고객이 자사 제품에 관심을 갖고 있는지 확인해야 하는 기존 고객에게 특히 필요합니다. 그렇지 않으면 고객이 사용하지 않는다는 사실을 알 수 없기 때문입니다. 예를 들어, 점점 더 많은 기업이 데이터를 클라우드에 저장하고 오픈 소스 스토리지 관리 소프트웨어를 사용하고 있는 가운데 스토리지 분야의 일부 공급업체는 하이퍼 컨버지드 시스템을 구축하고 있습니다. 예를 들어, 넷플릭스(Netflix)는 SSD가 장착된 Amazon Web Services(AWS) 서버에 데이터를 저장하고 Apache Cassandra로 관리합니다. 상용 스토리지 도구나 스토리지, SAN, 백업 전문 엔지니어의 도움 없이 자바 분산 시스템 전문가 한 명이 전체 구성을 관리하고 있습니다.
• 미래 전략은 현재의 IT 지출이 아니라 개발자의 채택 수준에 따라 결정해야 합니다. 귀사가 독점 가상화 소프트웨어 시장에서 거의 모든 지출을 차지하고 있는데 경쟁업체가 귀사 비용의 1%에 불과한 오픈 소스 기반 제품을 제공하기 시작했다고 가정해 보겠습니다. 사람들이 귀사의 제품 대신 이 제품을 선택하기 시작하면 전체 지출에서 귀사의 점유율이 여전히 90%인 시점에서 시장 점유율은 10%로 감소하게 됩니다. 수익에만 신경을 쓰고 있다면 여전히 좋은 상태인 것처럼 보이지만 시장 점유율 10%는 정말 빠르게 무너질 수 있습니다.

3. 인프라를 클라우드에 배치

과거에는 컴퓨팅 용량을 늘리는 유일한 방법은 컴퓨터 하드웨어를 구입하는 것이었기 때문에 컴퓨팅 성능이 비싸다는 가정하에 비즈니스 계획을 세우는 것이 유효했다고 앞서 언급했습니다. 그런 다음 이 값비싼 리소스를 고객 문제를 해결하는 데 올바른 방식으로 사용하여 수익을 창출할 수 있었습니다.

클라우드 컴퓨팅의 등장으로 이러한 가정은 거의 완전히 무효화되었습니다. 이제 필요할 때 필요한 만큼의 용량을 구매하고 실제로 사용한 시간만큼만 비용을 지불하는 것이 가능해졌습니다. 새롭게 가정해야 할 것은 (가상) 머신은 임시적이라는 것입니다. 회사 내 다른 부서와 협상할 필요 없이 버튼 하나만 누르거나 API를 호출하여 가상 머신을 생성하고 소멸할 수 있습니다.

이러한 변화를 한 가지 방법으로 설명하자면, 셀프 서비스 클라우드는 이전에는 불가능했던 일을 즉각적으로 가능하게 해준다는 것입니다. Netflix의 모든 엔지니어는 캘리포니아에 있지만 전 세계 인프라를 관리합니다. 클라우드를 통해 특정 위치에 서버를 추가하면 성능이 향상되는지 여부를 실험하고 결정할 수 있습니다. 브라질에서 비디오 전송 문제를 발견했다고 가정해 보겠습니다. 상파울루에 클라우드 서버 인스턴스 100개를 몇 시간 내에 쉽게 설치할 수 있습니다. 일주일 후 전송 속도와 안정성의 차이가 추가 서버 인스턴스의 비용을 정당화할 만큼 크지 않다고 판단되면 서버 인스턴스를 생성할 때와 마찬가지로 빠르고 쉽게 종료할 수 있습니다.

이런 종류의 실험은 기존 인프라로는 비용이 너무 많이 들기 때문에 시도조차 할 수 없습니다. 상파울루에 에이전트를 고용하여 프로젝트를 조율하고, 데이터 센터를 찾고, 브라질 정부 규정을 충족하고, 브라질로 기계를 배송하는 등의 작업을 수행해야 합니다. 테스트를 실행하고 현지 용량을 늘려도 배송 속도가 개선되지 않는다는 사실을 알아내기까지 6개월이 걸립니다.

4. 적은 프로세스로 높은 자유와 높은 책임의 문화 만들기

앞서 많은 기업이 문제를 예방하기 위해 규칙과 프로세스를 만드는 것을 관찰했습니다. 누군가 실수를 하면 인사 매뉴얼에 “다시는 그런 실수를 하지 마라”라는 규칙을 추가합니다. 이러한 관점에서 인사 매뉴얼을 읽으면 회사에서 잘못한 모든 일의 과거 기록을 추출할 수 있습니다. 개발 프로세스에서 문제가 발생하면 그에 상응하는 반응은 절차에 새로운 단계를 추가하는 것입니다. 문제를 예방하기 위해 프로세스를 만들 때 가장 큰 문제는 시간이 지남에 따라 복잡한 ‘흉터 조직’이 쌓여 속도가 느려진다는 것입니다.

넷플릭스 에는 HR 매뉴얼이 없습니다. 단 하나의 지침이 있을 뿐입니다: “넷플릭스 의 최선의 이익을 위해 행동하라”. 직원이 주어진 상황에서 이 지침을 어떻게 해석해야 할지 모른다면 그 직원은 판단력이 부족하다는 뜻입니다. 팀원들의 판단력을 신뢰하지 못한다면 왜 그들을 고용하고 있는지 자문해 보아야 합니다. 가이드라인을 위반한 직원을 해고해야 하는 경우가 종종 있는 것은 사실입니다. 전반적으로 팀원 간, 그리고 회사 전체에 걸쳐 높은 수준의 상호 신뢰는 강력한 구속력이 됩니다.

다음 책은 조직을 혁신하고자 하는 분들을 위해 프로세스에 대한 새로운 사고 방식을 설명합니다:

• 목표: 지속적인 개선의 과정 엘리야후 골드라트(Eliyahu M. Goldratt)와 제프 콕스(Jeff Cox)가 쓴 책입니다. 이 책은 1984년 처음 출간된 이래 비즈니스 스쿨의 표준 경영 교재로 자리 잡았습니다. 90일 안에 공장의 성과를 개선하지 않으면 공장을 폐쇄해야 하는 한 관리자의 이야기를 다룬 소설로, 골드라트의 제약 이론을 프로세스 제어 및 자동화의 맥락에서 구현한 책입니다.
• 피닉스 프로젝트: IT, 데브옵스, 비즈니스 성공에 관한 소설 Gene Kim과 Kevin Behr의 저서입니다. 제목에서 알 수 있듯이 이 소설은 90일 안에 늦어지고 예산이 초과된 프로젝트를 구하지 않으면 부서 전체가 아웃소싱될 위기에 처한 IT 관리자의 이야기를 다루고 있습니다. 그는 문제의 해결책으로 데브옵스를 발견합니다.

5. 사일로를 마이크로서비스 팀으로 대체하기

대부분의 소프트웨어 개발 그룹은 사일로로 분리되어 있으며, 그룹 간에 인력이 겹치지 않습니다. 소프트웨어 개발 프로젝트의 표준 프로세스는 제품 관리자가 사용자 경험 및 개발 그룹과 회의를 통해 새로운 기능에 대한 아이디어를 논의하는 것으로 시작됩니다. 아이디어가 코드로 구현된 후에는 품질 보증(QA) 및 데이터베이스 관리 팀에 코드를 전달하고 더 많은 회의에서 논의합니다. 시스템, 네트워크 및 SAN 관리자와의 커뮤니케이션은 주로 티켓을 통해 이루어집니다. 전체 프로세스는 느리고 오버헤드가 많은 경향이 있습니다.

일부 회사는 개발 프로세스를 처음부터 끝까지 처리하는 소규모 “스타트업” 스타일의 팀을 만들어 속도를 높이려고 하거나, 인수한 회사가 별도의 부서로 독립적으로 운영되는 인수합병의 결과로 이러한 팀이 만들어지기도 합니다. 그러나 소규모 팀이 여전히 모놀리식 배포를 수행하는 경우, 일반적으로 다른 기능을 담당하는 개인 또는 그룹 간에 핸드오프가 이루어집니다. 이러한 프로세스는 대기업의 모놀리식 딜리버리와 동일한 문제를 겪게 되는데, 그다지 효율적이거나 민첩하지 못하다는 점입니다.

Conway’s의 법칙에 따르면 소프트웨어 시스템의 인터페이스 구조는 그 시스템을 만든 조직의 사회 구조를 반영합니다. 따라서 마이크로서비스 아키텍처(MSA)로 전환하려면 직원을 제품팀으로 구성하고 DevOps 방법론을 사용해야 합니다. 더 이상 제품 관리자, UX 관리자, 개발 관리자 등으로 구분되어 사일로에서 하향식으로 관리할 필요가 없습니다. 각 제품 기능(마이크로서비스 로 구현됨)에 대한 관리자가 있으며, 이 관리자는 개념부터 배포까지 마이크로서비스 에 대한 소프트웨어 개발의 모든 측면을 처리하는 팀을 감독합니다. 플랫폼팀은 제품팀이 API를 통해 액세스할 수 있는 인프라 지원을 제공합니다. 넷플릭스 의 플랫폼 팀은 대부분 시애틀에 있는 AWS를 사용하며, 그 위에 넷플릭스 가 관리하는 인프라 계층을 일부 구축했습니다. 하지만 클라우드 플랫폼이 사내에서 사용하든 퍼블릭에서 사용하든 상관없으며, 중요한 것은 API 기반, 셀프 서비스, 자동화가 가능하다는 점입니다.

6. OODA 루프의 안내에 따라 마이크로서비스 에 지속적 배포를 도입하세요.

사일로화된 팀 조직은 일반적으로 통합된 다기능 애플리케이션이 정기적인 일정에 따라 하나의 단위로 릴리스되는 모놀리식 배포 모델과 짝을 이룹니다(종종 버전 번호가 지정됨). 이 모델은 비교적 간단하고 적은 수의 개발자(예: 50명 이하)로도 충분히 잘 작동하기 때문에 대부분의 소프트웨어 개발 팀이 초기에 이 모델을 사용합니다. 그러나 팀이 성장함에 따라 QA 또는 프로덕션 테스트 중에 한 개발자의 코드에서 버그를 발견하고 버그가 수정될 때까지 99명의 다른 개발자의 작업이 릴리스되지 않는 경우 실제 문제가 될 수 있습니다.

2009년에 Netflix는 마이크로서비스 아키텍처(MSA)와 완벽하게 맞물리는 지속적 배포 모델을 채택했습니다. 각 마이크로서비스 는 다른 마이크로서비스 와 독립적으로 자체 일정에 따라 업데이트할 수 있는 단일 제품 기능을 나타냅니다. 마이크로서비스 에서 버그를 발견해도 다른 마이크로서비스 의 릴리스 일정에는 영향을 미치지 않습니다. 지속적인 제공은 마이크로서비스 를 표준 컨테이너에 패키징하는 데 의존합니다. Netflix는 처음에 Amazon 머신 이미지(AMI)를 사용했으며, 약 10분 만에 업데이트를 테스트 또는 프로덕션 환경에 배포할 수 있었습니다. Docker를 사용하면 그 시간이 훨씬 더 단축되어 경우에 따라 단 몇 초로 단축됩니다.

넷플릭스 에서 지속적인 개발과 배포를 위한 개념적 프레임워크는 Observe-Orient-Decide-Act (OODA) loop입니다.

Observe는 현재 상태를 조사하여 혁신할 수 있는 부분을 찾는 것을 의미합니다. 프로젝트를 시작할 기회를 발견한 사람은 누구나 이를 활용할 수 있도록 암묵적으로 권한을 부여하는 것이 회사 문화입니다. 예를 들어, 다이어그램에서 ‘고객 불만 사항’이라고 부르는 것, 즉 많은 사람들이 웹사이트의 특정 단계에 도달하면 등록 절차를 포기하는 것을 발견할 수 있습니다. 그 이유를 조사하고 문제를 해결하기 위한 프로젝트를 진행할 수 있습니다.

Orient는 관찰 지점에서 관찰한 현상의 원인을 이해하기 위해 메트릭을 분석하는 것을 말합니다. 여기에는 종종 로그 파일과 같은 대량의 비정형 데이터를 분석하는 것이 포함되며, 이를 빅데이터 분석이라고도 합니다. 찾고자 하는 답이 비즈니스 인텔리전스 데이터베이스에 이미 존재하지 않는 경우가 있습니다. 이전에 아무도 살펴본 적이 없는 데이터를 검토하고 이전에 질문하지 않았던 질문을 던지고 있는 것입니다.

Decide는 프로젝트 계획을 개발하고 실행하는 것을 의미합니다. 이 시점에서 회사 문화는 큰 요소입니다. 앞서 설명한 바와 같이, 자유도가 높고 책임감이 높은 문화에서는 변경을 시작하기 전에 경영진의 승인을 받을 필요가 없습니다. 계획을 공유하되 허가를 요청할 필요는 없습니다.

Act는 솔루션을 테스트하고 프로덕션에 적용하는 것을 의미합니다. 점진적 기능이 포함된 마이크로서비스 를 클라우드 환경에 배포하면 이전 솔루션과 나란히 비교하는 A/B 테스트가 자동으로 진행되어 새로운 접근 방식이 더 나은지 여부를 보여주는 데이터를 수집하는 데 걸리는 시간 동안 나란히 비교됩니다. 협력하는 마이크로서비스 는 중단되지 않으며, 고객은 테스트에 선택되지 않는 한 변경 사항을 볼 수 없습니다. 솔루션이 더 나은 경우 프로덕션에 배포하면 됩니다. 크게 개선될 필요는 없습니다. 마이크로서비스 의 클라이언트 수가 충분히 많다면 응답 시간에서 몇 퍼센트만 개선되어도 통계적으로 유효한 것으로 나타날 수 있으며, 여러 작은 변경 사항의 시간 경과에 따른 누적 효과도 상당할 수 있습니다.

이제 관찰 지점으로 돌아왔습니다. 항상 모든 단계를 수행하거나 엄격한 순서로 수행할 필요는 없습니다. 이 프로세스의 중요한 특징은 고객이 원하는 것이 무엇인지 빠르게 파악하고 이를 만들어낼 수 있다는 것입니다. 콕크로프트는 충분한 데이터 포인트를 기반으로 움직이고 있는데 경쟁업체가 입증하거나 반증하는 데 몇 달이 걸리는 추측을 하고 있다면 “이기기 힘들다”고 말합니다.

최신 기술은 1~2주마다 루프를 순환하는 것이지만, 모든 마이크로서비스 팀은 독립적으로 이 작업을 수행할 수 있습니다. 마이크로서비스 를 사용하면 회사 전체가 일사불란하게 루프를 돌지 않아도 되므로 훨씬 더 빠르게 진행할 수 있습니다.

7. NGINX Plus가 마이크로서비스 에 어떻게 도움을 주나요?

NGINX 는 애플리케이션을 마이크로서비스 집합으로 개발 및 배포하는 4계층 애플리케이션 아키텍처를 채택하는 것이 향후 성공에 매우 중요하다고 생각합니다. 이 포스팅과 NGINX STORE의 업로드된 ‘넷플릭스 에서 마이크로서비스 도입하기‘에서 공유한 정보가 도움이 되길 바랍니다: 아키텍처 설계를 위한 교훈’에서 공유한 정보가 애플리케이션 개발을 위한 최신 아키텍처로의 전환을 계획하는 데 도움이 되기를 바랍니다.

앱을 전송할 때가 되면 NGINX Plus는 사용자가 기대하는 우수한 성능, 안정성, 확장성을 제공하는 애플리케이션 전송 플랫폼을 제공합니다. 웹 서비스, 로드 밸런싱, 콘텐츠 캐싱을 위한 단일 소프트웨어 툴로 전환하면 마이크로서비스 기반 아키텍처를 완전히 도입하는 것이 더 쉽고 성공 가능성이 높아집니다. NGINX Plus는 이러한 기능과 그 이상을 배포 및 관리하기 쉬운 하나의 패키지에 결합합니다. 이러한 접근 방식을 통해 개발자는 플랫폼 팀이 마련한 표준과 모범 사례를 준수하면서 마이크로서비스 의 완벽한 전송을 정의하고 제어할 수 있습니다. 여기를 클릭하여 NGINX Plus가 애플리케이션의 성공을 지원하는 방법에 대해 자세히 알아보세요.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX 에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.