Netflix에서 마이크로서비스 도입: 건축 설계를 위한 교훈

최근 블로그 게시물에서는 애플리케이션이 마이크로서비스 세트로 개발되고 배포되는 4계층 애플리케이션 아키텍처를 채택하는 것이 중요하다고 생각하는 이유를 설명했습니다. 10년 전에도 잘 작동했던 개발 프로세스와 애플리케이션 아키텍처를 계속 사용한다면, 점점 더 많은 앱을 선택할 수 있는 모바일 사용자의 관심을 사로잡고 유지할 만큼 빠르게 움직일 수 없다는 것이 점점 더 분명해지고 있습니다.

마이크로서비스 아키텍처 로 전환하면 시장에서 기업에 흥미로운 기회가 창출됩니다. 시스템 설계자와 개발자에게는 고객에게 혁신적인 새로운 웹 경험을 제공하면서 전례 없는 수준의 제어와 속도를 약속합니다. 하지만 그렇게 숨가쁘게 진행되다 보니 실수할 여지가 별로 없다고 느껴질 수도 있습니다. 현실 세계에서는 앱 개발 및 배포 프로세스를 재정비하는 동안 앱 개발 및 배포를 멈출 수 없습니다. 미래의 성공이 마이크로서비스 아키텍처로의 전환에 달려 있다는 사실은 알고 계시지만, 실제로는 어떻게 전환할 수 있을까요?

다행히도 마이크로서비스 를 일찍 도입한 몇몇 기업이 오픈 소스 정신에 따라 전문 지식을 공유하고 있습니다. 이는 공개된 코드뿐만 아니라 컨퍼런스 프레젠테이션과 블로그 게시물을 통해서도 가능합니다. 넷플릭스 가 대표적인 예이다. 웹 엔지니어링 책임자이자 클라우드 아키텍트인 Adrian Cockcroft는 100명의 엔지니어가 모놀리식 DVD 대여 애플리케이션을 생산하는 기존 개발 모델에서 수백 개의 마이크로서비스를 종단 간 개발하는 여러 소규모 팀으로 구성된 마이크로서비스 아키텍처로의 회사 전환을 감독했습니다. 이 마이크로서비스는 매일 수백만 명의 Netflix 고객에게 디지털 엔터테인먼트를 스트리밍하기 위해 함께 작동합니다. 현재 Battery Ventures의 기술 펠로우인 Cockcroft는 마이크로서비스와 클라우드 네이티브 아키텍처의 유명한 전도사이며, NGINX 기술 자문 위원회에 참여하고 있습니다.

2부로 구성된 블로그 게시물 시리즈에서는 Cockcroft가 작년 10월에 열린 첫 번째 연례 NGINX 컨퍼런스와 그보다 몇 달 전에 열린 Silicon Valley Microservices Meetup에서 한 두 가지 강연의 주요 내용을 소개합니다. (전체 영상 도 꼭 시청해 보세요.)

• 이 게시물에서는 마이크로서비스 아키텍처를 정의하고 이를 설계하기 위한 몇 가지 모범 사례를 설명합니다.
• Netflix에서 마이크로서비스 도입: 팀 및 프로세스 설계 수업에서는 소프트웨어 개발을 위한 새로운 사고방식을 도입하고 이를 중심으로 팀을 재편하는 방법과 이유를 논의합니다.

마이크로서비스 아키텍처란 무엇인가?

Cockcroft는 마이크로서비스 아키텍처를 제한된 컨텍스트를 갖는 느슨하게 결합된 요소로 구성된 서비스 지향 아키텍처 로 정의합니다.

느슨하게 결합되었다는 것은 서비스를 독립적으로 업데이트할 수 있다는 것을 의미합니다. 즉, 한 서비스를 업데이트하기 위해 다른 서비스를 변경할 필요가 없습니다. 여러 개의 작고 특화된 서비스가 있지만 모두 함께 업데이트해야 하는 경우 느슨하게 결합되어 있지 않으므로 마이크로서비스가 아닙니다. 사람들이 마이크로서비스 아키텍처로 전환할 때 간과하기 쉬운 결합 유형 중 하나는 데이터베이스 결합입니다. 데이터베이스 결합은 모든 서비스가 동일한 데이터베이스와 통신하고 서비스를 업데이트하면 스키마가 변경되는 것을 의미합니다. 데이터베이스를 분할하고 비정규화해야 합니다.

경계가 있는 컨텍스트 의 개념은 에릭 에반스의 저서 인 도메인 주도 설계 에서 유래되었습니다. 올바르게 경계가 지정된 컨텍스트를 갖춘 마이크로서비스는 소프트웨어 개발 목적에 맞게 독립적으로 실행됩니다. 마이크로서비스와 피어는 API를 통해서만 엄격하게 상호 작용하고 따라서 데이터 구조, 데이터베이스 스키마 또는 기타 객체의 내부 표현을 공유하지 않으므로 피어의 내부에 대해 아무것도 알지 못해도 마이크로서비스의 코드를 이해하고 업데이트할 수 있습니다.

인터넷용 애플리케이션을 개발한 적이 있다면 이름은 아니더라도 실제로는 이러한 개념에 이미 익숙할 것입니다. 대부분의 모바일 앱은 꽤 많은 백엔드 서비스와 통신하여 사용자가 Facebook에서 공유하고, Google Maps에서 길을 찾고, Foursquare에서 레스토랑을 찾는 등의 작업을 앱의 컨텍스트 내에서 수행할 수 있도록 합니다. 모바일 앱이 해당 서비스와 긴밀하게 결합된 경우 업데이트를 출시하기 전에 모든 개발 팀과 통신하여 변경 사항이 아무것도 손상시키지 않는지 확인해야 합니다.

마이크로서비스 아키텍처로 작업할 때, 다른 내부 개발팀을 인터넷 백엔드와 같은 것으로 생각합니다. 즉, 마이크로서비스가 API를 통해 상호 작용하는 외부 서비스로 생각합니다. 마이크로서비스 간의 일반적으로 이해되는 "계약"은 API가 안정적이고 향후 호환 가능하다는 것입니다. Google Maps API가 경고 없이 변경되어 사용자에게 피해를 주는 방식으로 변경되는 것이 용납될 수 없는 것처럼, 귀하의 API도 발전할 수 있지만 이전 버전과 호환되어야 합니다.

마이크로서비스 아키텍처 설계를 위한 모범 사례

콕크로프트는 넷플릭스의 클라우드 아키텍트로서의 자신의 역할을 아키텍처를 제어하는 것이 아니라, 넷플릭스 엔지니어들이 구축하면서 나타난 아키텍처를 발견하고 공식화하는 것으로 설명합니다. Netflix 개발팀은 마이크로서비스 아키텍처를 설계하고 구현하기 위한 몇 가지 모범 사례를 수립했습니다.

각 마이크로서비스에 대해 별도의 데이터 저장소 생성

여러 마이크로서비스에서 동일한 백엔드 데이터 저장소를 사용하지 마세요. 각 마이크로서비스의 팀이 해당 서비스에 가장 적합한 데이터베이스를 선택하기를 원합니다. 게다가 단일 데이터 저장소를 사용하면 여러 팀이 작성한 마이크로서비스가 데이터베이스 구조를 공유하는 것이 너무 쉽습니다. 아마도 작업 중복을 줄인다는 명분으로 그럴 수도 있습니다. 한 팀이 데이터베이스 구조를 업데이트하면 해당 구조를 사용하는 다른 서비스도 변경해야 하는 상황이 발생합니다.

데이터를 분리하면 데이터 관리가 더 복잡해질 수 있는데, 별도의 저장 시스템이 쉽게 동기화되지 않거나 일관성이 없어질 수 있고, 외래 키가 예기치 않게 변경될 수 있기 때문입니다. 불일치 사항을 찾아 수정하기 위해 백그라운드에서 작동하여 마스터 데이터 관리 (MDM)를 수행하는 도구를 추가해야 합니다. 예를 들어, 구독자 ID를 저장하는 모든 데이터베이스를 조사하여 모든 데이터베이스에 동일한 ID가 있는지 확인할 수 있습니다(어느 한 데이터베이스에도 누락되거나 추가 ID가 없는지). 도구를 직접 만들 수도 있고, 구매할 수도 있습니다. 많은 상업용 관계형 데이터베이스 관리 시스템(RDBMS)이 이런 종류의 검사를 수행하지만, 일반적으로 결합에 대한 요구 사항이 너무 많아서 확장성이 없습니다.

코드를 비슷한 수준의 성숙도로 유지

마이크로서비스의 모든 코드를 유사한 수준의 성숙도와 안정성으로 유지하세요. 다시 말해, 잘 작동하는 배포된 마이크로서비스에서 일부 코드를 추가하거나 다시 작성해야 하는 경우, 가장 좋은 방법은 일반적으로 새 코드나 변경된 코드에 대한 새 마이크로서비스를 만들고 기존 마이크로서비스를 그대로 두는 것입니다. [편집자 - 이를 불변 인프라 원칙이라고도 합니다.] 이런 식으로 버그가 없고 최대한 효율적일 때까지 새 코드를 반복적으로 배포하고 테스트할 수 있으며, 기존 마이크로서비스에서 실패나 성능 저하의 위험은 없습니다. 새로운 마이크로서비스가 원본만큼 안정되면 실제로 함께 단일 기능을 수행하거나 이를 결합하는 것이 다른 효율성이 있는 경우 이를 다시 병합할 수 있습니다. 그러나 Cockcroft의 경험에 따르면 마이크로서비스가 너무 커져서 분할해야 한다는 것을 깨닫는 경우가 훨씬 더 흔합니다.

각 마이크로서비스에 대해 별도의 빌드를 수행합니다.

각 마이크로서비스에 대해 별도로 빌드를 수행하여 해당 마이크로서비스에 적합한 개정 수준에서 저장소에서 구성 요소 파일을 가져올 수 있습니다. 이로 인해 다양한 마이크로서비스가 서로 다른 개정 수준에서 유사한 파일 세트를 가져오는 상황이 발생하는 경우가 있습니다. 이전 파일 버전을 폐기하여 코드베이스를 정리하는 것이 더 어려울 수 있습니다(개정판이 더 이상 사용되지 않는지 보다 신중하게 확인해야 하기 때문). 하지만 이는 새로운 마이크로서비스를 빌드할 때 새 파일을 추가하는 것이 얼마나 쉬운지에 대한 허용 가능한 균형입니다. 이러한 비대칭성은 의도적인 것입니다. 새로운 마이크로서비스, 파일 또는 기능을 도입하는 것이 위험하지 않고 쉽기를 바라는 것입니다.

컨테이너에 배포

컨테이너에 마이크로서비스를 배포하는 것이 중요한 이유는 모든 것을 배포하는 데 단 하나의 도구만 필요하기 때문입니다. 마이크로서비스가 컨테이너에 있는 한, 해당 도구는 이를 배포하는 방법을 알고 있습니다. 용기가 무엇인지는 중요하지 않습니다. 그럼에도 불구하고 Docker는 매우 빠르게 컨테이너의 사실상 표준이 된 것 같습니다.

서버를 무상태로 처리

특히 고객 대상 코드를 실행하는 서버를 그룹의 상호 교환 가능한 구성원으로 취급합니다. 그들은 모두 동일한 기능을 수행하므로 개별적으로 걱정할 필요가 없습니다. 여러분이 유일하게 신경 써야 할 점은 필요한 작업량을 생산할 만큼 충분한 수가 있는지이고, 자동 크기 조정을 사용해서 숫자를 늘리거나 줄일 수 있다는 것입니다. 하나가 작동을 멈추면 자동으로 다른 것으로 대체됩니다. 특수 기능을 수행하기 위해 개별 서버에 의존하는 "스노플레이크" 시스템은 피하십시오.

콕크로프트의 비유는 서버를 애완동물이 아닌 가축에 비유해야 한다는 것입니다. 생산 중에 특수 기능을 수행하는 기계가 있다면, 그 기계의 이름을 알고 있고, 그 기계가 고장나면 모두가 슬퍼한다면, 그것은 애완동물입니다. 그 대신에 당신은 당신의 서버를 소떼에 비유해야 합니다. 당신이 신경쓰는 것은 얼마나 많은 우유를 얻을 것인가입니다. 어느 날 평소보다 우유가 적게 나온다는 것을 알게 되면 어떤 소가 잘 생산하지 못하는지 알아내어 다른 소로 바꿔주세요.

Netflix 전송 아키텍처는 NGINX 기반으로 구축됨

넷플릭스는 오랫동안 NGINX 오픈 소스를 사용해 왔으며, 2011년 NGINX, Inc.가 법인으로 설립된 이후 첫 번째 고객이 되었습니다. 실제로 Netflix는 세계 최대 규모의 콘텐츠 전송 네트워크(CDN) 중 하나인 Open Connect를 자사의 전송 인프라의 핵심으로 선택했습니다. 초당 수천 개, 때로는 수백만 개의 요청을 처리할 수 있는 기능을 갖춘 NGINX와 NGINX Plus는 고성능 HTTP 전송을 위한 최적의 솔루션이며, Netflix와 같은 회사가 매일 수백만 명의 고객에게 고품질 디지털 경험을 제공할 수 있도록 합니다.

비디오 녹화

빠른 배송
nginx.conf 2014, 2014년 10월

마이크로서비스로의 마이그레이션, 1부
실리콘 밸리 마이크로서비스 미팅, 2014년 8월

마이크로서비스로의 마이그레이션, 2부
실리콘 밸리 마이크로서비스 미팅, 2014년 8월