[번역] 어떻게 마이크로 서비스가 인터넷을 구했을까?

도입

오늘날 분산 시스템이 얼마나 영향력 있는지, 적어도 대학 수준에서는 가장 간과되는 주제 중 하나로 남아있습니다. 컨테이너화(containerization)와 폴트 톨러런스(falut tolerance)와 같은 개념을 이해하는 학생들은 많지 않고 시스템 프로젝트가 해커톤에서 이기는 것을 볼 수 없을 겁니다. 그럼에도 불구하고, 저는 적어도 오늘날의 대규모 시스테이 어떻게 작동하는지 간단하게 이해하는 것이 매우 중요하다고 생각합니다.

이 이야기는 1~2년 동안 일반적인 컴퓨터 과학 교육을 받은 사람이나 웹 개발을 넓게 독학한 사람과 같이 초보자를 대상으로 하는 시리즈 중 첫번째 글입니다. 처음 몇 개의 글은 주요 개념에 대한 높은 수준의 소개와 기술적 세부 사항에 대한 몇 가지 심층적인 설명을 할 것입니다. 나중에 네트워킹, 쿠버네티스나 쿨한 것들에 관한 주제를 탐험해보고 싶습니다. 이번 첫번째 글은 매우 간단하고 마이크로 서비스 이면의 기본 개념과 동기부여를 설명하는 것을 목표로 합니다.

분산 시스템이 인터넷을 돌아가게 한다.

옛날 옛적에, 애플리케이션은 모놀리식하게 만들어졌습니다. 애플리케이션은 웹 서버 자체와 어떤 종류의 데이터 스토리지 시스템으로 구성되었을 가능성이 높고, 하나 또는 두 개의 바이너리에 구축되어 패키지되었습니다. 이 바이너리는 서버 랙에 업로드 되어 기계 위에서 직접 실행되었습니다. 이것이 80년대와 90년대 인터넷에는 괜찮았지만 오늘날 구글은 35억 개의 검색 쿼리를 매일 받고 있고, 아무리 큰 서버라할지라도 그것을 다 처리하기는 어렵습니다.

예전에는 엔지니어가 더 나은 서버, 더 나은 케이블 등을 구입함으로써 수직적으로 확장했습니다. 인터넷의 성장과 무어의 법칙의 종식과 함께, 기존 확장 방식이 빠르게 지속할 수 없게 되었고 수평적 확장의 필요성은 고통스러울 정도로 분명했습니다. 더 좋고, 더 비싼 하드웨어를 사는 대신에, 단순히 싼 서버를 아주 많이 구입하고 모든 서버에 부하를 분산시키는 것입니다.

최초의 수평적 확장은 웹 서버를 중복 실행하는 것이었습니다. 그러나 최근 클라우드 발전과 함께 마이크로 서비스 아키텍처가 빠르게 도입되기 시작했습니다. 이 아이디어는 거대한 애플리케이션을 서비스라고 불리는 개별 컴포넌트로 나누어 각자 전문화된 작업을 수행하는 것입니다. 그러므로 개발자들은 처음부터 끝까지 요청을 처리하는 대신에, 사용자 인증기, 페이지 서버, api 서버, 데이터베이스 모델 서비스 같은 서비스들로 애플리케이션을 분리합니다.

모놀리식 애플리케이션 쪼개기 (출처)

각 마이크로 서비스는 하나 이상의 레플리카로 구성됩니다. Django에서 실행되는 백엔드를 가진 웹사이트의 경우, Django 서버의 복사본 수를 늘리으로써 수평적으로 확장할 수 있습니다. 이 복사본들이 레플리카입니다. 데이터베이스를 사용하는 경우, 데이터베이스의 복사본인 샤드(shard)라는 레플리카의 수를 늘리는 것으로 확장할 수 있습니다. 샤드를 개별로 실행하고 전체 데이터의 일부를 저장할 수 있는 전체 데이터 베이스를 생각해보시기 바랍니다. 샤드의 수를 늘림으로써 데이터베이스를 수평으로 확장할 수 있습니다. 이 복제품들은 다른 기계에서 실행 될 수 있습니다. 그래서 만약 100대의 컴퓨터에서 거대한 웹 서버를 실행하길 원한다면, 100개의 레플리카를 만들어 각각의 컴퓨터에서 실행할 수 있습니다.

집단 스타일 마이크로 서비스 아키텍쳐 (출처)

마이크로 서비스 아키텍쳐 패턴에 대한 더 많은 정보를 원한다면 Arun Gupta 블로그를 방문해보세요. 그는 AWS의 주요 기술자입니다.

장점

아래 항목들은 마이크로 서비스를 사용하는 가장 큰 장점을 나열한 것 입니다. 더 많은 장점이 있지만 이 4가지가 가장 중요합니다.

• 마이크로 서비스 프레임워크의 가장 크고 부인할 수 없는 장점은 어떤 컴포넌트라도 수평으로 확장할 수 있다는 것입니다. 하나의 서비스(예:신경망)가 과부하 상태라면, 간단하게 특정 서비스의 더 많은 레플리카를 실행하면 됩니다.
• 서비스들이 독립적입니다. 각 컴포넌트는 별도의 저장소로 저장할 수 있고 전담 엔지니어 팀에 의해 관리됩니다. 컴포넌트는 용도에 가장 적합한 언어로 작성되므로 데티어베이스 서비스는 C로 작성되고 웹 서버는 Python으로 작성될 수 있습니다. 이러한 서비스는 업데이트될 수 있고 파이프라인의 나머지 부분에 영향을 미치지 않고 새로운 컴포넌트가 만들어질 수 있습니다.
• 이 아키텍처는 플러거블합니다. 서비스의 독립성을 기반으로 하지만 완전히 새로한 단계로 나아갑니다. 회사는 모든 서비스를 쓸 필요도 없습니다. MySQL, Elasticsearch, Redis와 같은 타사 애플리케이션은 모두 시스템에 쉽게 통합될 수 있는 마이크로서비스입니다.
• 폴트 톨러런스. 이 장점은 시스템이 제대로 설계되지 않은 경우에만 존재합니다. 하나의 서비스 레플리카가 실패해도 전체 파이프라인 또는 해당 서비스에 오류가 발생해서는 안 됩니다. 마찬가지로 특정 서비스의 버그는 다른 비 관련 서비스의 가동 시간에 영향을 미치지 않습니다. 이것이 항상 쉬운 것은 아니며, 폴트 톨러런스는 산업과 연구 모두에서, 특히 분산 데이터베이스나 네트워크와 같은 주제에 대해 야기되는 문제입니다.

그리고 물론 모든 것과 마찬가지로 약간의 단점도 있습니다. 한 서비스에서 다른 서비스로 요청을 보내는 것이 오버헤드가 있고 복잡합니다. 분산 시스템은 종종 의존성, 레플리케이션, 공유 운명 문제를 가질 수 있습니다. 구축과 디버깅의 어려움은 마이크로 서비스의 수와 복잡성에 따라 기하급수적으로 증가합니다.

좋은 소식은 수많은 연구원, 기업, 그리고 스타트업이 이 문제의 모든 측면을 연구합니다. Jenkins, Spinnaker, Jegertraacing과 같은 프로젝트는 산업과 학계에서 매일 새로운 혁신이 이루어지고 있는 오늘날 가장 인기 있는 오픈 소스 솔루션 중 하나입니다.

그래서 분산 시스템은 여전히 상대적으로 새로운 반면 그 영향은 매일 지속적으로 느껴질 수 있습니다. 제 말은, 이 글을 당신이 어떻게 읽고 있는지 생각해보시기 바랍니다.

이 글은 How Microservices Saved the Internet을 파파고의 도움을 얻어 번역한 글입니다.