한빛출판네트워크

1.2 주요 혜택

마이크로서비스가 제공하는 혜택은 많으면서도 다양하다. 이러한 혜택 대부분은 다른 분산 시스템도 제공하지만, 마이크로서비스의 경우 분산 시스템과 서비스 지향 아키텍처service-oriented architecture의 개념을 더 깊이 내포하는 만큼 훨씬 더 많은 혜택을 누릴 수 있다.

1.2.1 기술 이기종성

다수의 협업 서비스로 구성된 시스템에서는 각 서비스가 다른 기술을 사용하도록 결정할 수 있다. 이는 결국 최소한의 공통점만을 지닌 표준화된, 만능의 접근 방식을 선택하기보다 각 작업에 적합한 도구를 선택하게 해준다.

시스템 특정 부분의 성능을 높이려 할 때, 요구되는 성능 수준을 만족하는 데 유리한 다른 기술 스택을 고려해야 할 수도 있고 변환할 데이터를 어떻게 저장할지 결정해야 할 수도 있다. 예를 들어 소셜 네트워크의 경우에는 소셜 그래프의 높은 상호 연결성을 반영하기 위해 사용자 상호 작용은 그래프 지향 데이터베이스graph-oriented database에, 사용자 게시물은 문서 지향 데이터 저장소documented-oriented data storage에 저장할 수 있다. 즉, [그림 1-1]과 같은 이기종 아키텍처가 생겨난다.

• [그림 1-1] 14 옮긴이 주: 그래프 DB는 노드, 에지, 프로퍼티에 대한 시맨틱 검색을 위해 그래프 구조를 사용하는 데이터베이스 시스템으로 Neo4j, Titan, OrientDB 등이 있다.
• [그림 1-1] 15 옮긴이 주: Blob(Binary Large Object) 저장소는 이미지, 오디오, 멀티미디어 및 파일을 저장하는 데 사용하는 저장 시스템이다. AWS S3 또는 Azure Blob 스토리지 등이 있다. 

마이크로서비스를 통해 기술을 더 신속히 적용할 수 있고, 개선된 새로운 기능들이 어떻게 도움이 될지 살펴볼 수 있다. 새로운 기술을 시험하고 적용하는 과정에서 최대 걸림돌은 새로운 기술을 도입했을 때 결국에는 잘 맞지 않을 수 있다는 위험이다. 모놀리식 애플리케이션에서 새로운 프로그래밍 언어, 데이터베이스 또는 프레임워크를 시도하면 그 변경은 시스템에 큰 영향을 미칠 것이다. 하지만 다양한 독립 서비스로 구성된 시스템에는 새로운 기술 분야를 시험해볼 만한 곳이 많다. 혹시 잘못될 때 제한할 수 있는 방법이 있다면 리스크가 가장 낮은 서비스를 선택해서 그곳에 새로운 기술을 사용해볼 수 있다.

물론 여러 기술을 함께 사용하면 문제가 전혀 없을 수는 없다. 몇몇 기업은 프로그래밍 언어 선택에 일부 제한을 걸어둔다. 예를 들어 넷플릭스와 트위터는 대부분 자바 가상 머신Java Virtual Machine(JVM)을 플랫폼으로 사용하는데, 이는 JVM의 신뢰성과 성능을 매우 잘 이해하고 있기 때문이다. 또한 그들은 대규모 시스템의 운영을 더 쉽게 만드는 JVM용 라이브러리와 도구를 개발하고 있지만 자바 기반이 아닌 서비스와 클라이언트로는 어려움이 더 많다. 그렇다고 해서 트위터나 넷플릭스가 한 가지 기술 스택을 모든 작업에 사용하는 것은 아니다. 다른 기술들의 병행 사용에 우려되는 또 다른 요소는 (서비스의) 크기다. 만약 실제로 2주 안에 마이크로서비스를 재작성할 수 있다면 새로운 기술을 적용하는 데 따른 리스크를 완화할 수 있을 것이다.

이 책을 통해 알게 되겠지만 마이크로서비스와 관련된 다른 많은 사항과 마찬가지로 올바른 균형을 찾는 것이 최선이다. 진화적 아키텍처를 주로 다루는 2장에서는 기술을 선택하는 방법을 논의하고, 시스템 통합을 다루는 4장에서는 서비스 간의 지나친 결합 없이 독립적으로 기술을 진화시키는 방법을 배울 것이다.

1.2.2 회복성

회복 공학resilience engineering의 핵심 개념은 ‘격벽bulkhead’(옮긴이 주: 선박의 방을 막는 칸막이벽으로, 장애의 전파를 막는 용도로 사용된다.)이다. 즉, 한 시스템의 컴포넌트에 장애가 발생하더라도 그 장애가 전파되지 않는다면 해당 문제를 격리하고 나머지 시스템을 계속 작동시킬 수 있다. 서비스의 경계야말로 명확한 격벽인 셈이다. 모놀리식 서비스에서는 한 서비스가 고장나면 모든 것이 작동을 멈춘다. 모놀리식 시스템은 장애 가능성을 낮추기 위해 수많은 머신 상에서 실행되어야 하지만, 마이크로서비스에서는 서비스의 전체 장애를 차단하고 기능을 적절히 저하degrade시키는 시스템을 구축할 수 있다.(옮긴이 주: 결함 감내 시스템(장애 허용 시스템, fault tolerant system)은 일부 장치나 서브시스템에 고장이나 오작동이 나타나면 시스템의 성능과 기능을 축소 구성하여 정지하지 않고도 동작을 유지하는 방식을 사용하고 있는데, 이 방식을 단계별 성능 저하(graceful degradation)라고 한다.)

하지만 주의해야 할 점도 있다. 마이크로서비스 시스템이 향상된 회복력을 적절히 수용할 수 있도록 분산 시스템이 마주한 새로운 장애 요인들을 이해해야 한다. 네트워크도 머신처럼 장애가 발생할 수 있는 만큼 이것을 다루는 방법을 이해해야 하며, 소프트웨어의 최종 사용자에게 어떤 영향을 미치는지도 알아야 한다.

회복력과 장애 형태를 더 잘 처리하는 방법에 대해서는 11장에서 자세히 이야기하겠다.

1.2.3 확장성

하나의 큰 모놀리식 서비스에서는 항상 모든 것을 함께 확장해야 한다. 만약 전체 시스템에서 작은 한 부분만 성능이 떨어지는데, 해당 동작이 거대한 모놀리식 애플리케이션에 묶여 있다면 전체를 한 덩어리처럼 확장해야 한다. 그러나 만약 작은 서비스들로 구성되어 있다면 필요한 서비스만 확장할 수 있다. 또한 다음 [그림 1-2]처럼 나머지 서비스를 더 작고 낮은 사양의 하드웨어에서 실행할 수 있다.

온라인 패션몰인 길트Gilt는 정확히 이런 이유로 마이크로서비스를 도입했다. 2007년부터 2009년까지 모놀리식 레일즈 애플리케이션(옮긴이 주: 길트는 2007년 Ruby on Rails로 작성한 모놀리식 애플리케이션을 2009년 자바로 작성된 10개의 마이크로서비스로 변환했고, 2011년에 스칼라를 적용했다. 2014년 Node.js를 도입하여 수백 개 이상의 마이크로서비스를 운영하고 있다.)으로 작성된 길트 시스템은 유입되는 부하를 충분히 처리할 수 없었다. 하지만 시스템의 코어 부분을 분리하면서부터는 급등하는 트래픽을 더 잘 처리 할 수 있게 되었다. 현재 450개 이상의 마이크로서비스가 분리된 많은 머신에서 동작 중이다.

아마존 웹 서비스Amazon Web Service (AWS)에서 제공하는 것과 같은 주문형 프로비저닝 시스템on-demand provisioning system을 도입하면 필요한 곳에 이 주문형 확장 기술을 적용할 수 있다. 이렇게 필요에 따라 확장하는 것이 비용을 더욱 효과적으로 쓸 수 있게 해주지만 미리 모든 걸 다 예상해서 아키텍처로만 해결하려 할 때 바로 비용절감으로 이어지는 경우는 드물다.

1.2.4 배포 용이성

무려 백만 줄에 달하는 모놀리식 애플리케이션에서는 한 줄만 수정하더라도 해당 변경을 릴리스하기 위해 전체 애플리케이션을 배포해야 한다. 이는 막대한 영향을 끼치는 아주 위험한 배포가 될 수 있다. 실제로는 이러한 걱정으로 위험도가 높은 배포는 잘 안 하게 된다. 그렇기 때문에 불행하게도 많은 경우에 수차례의 릴리스에 걸친 수많은 변경 사항이 한꺼번에 반영된 버전의 애플리케이션이 운영 환경에 배포되게 된다. 그리고 릴리스 간의 차이가 클수록 무언가 잘못될 위험성도 같이 높아진다!

마이크로서비스를 이용하면 하나의 서비스만 변경할 수 있고, 나머지 시스템과 독립적으로 배포할 수 있다. 코드를 더 신속히 배포할 수 있고, 문제가 발생하더라도 손쉽게 개별 서비스만 롤백rollback함으로써 해당 문제를 격리할 수 있다. 이는 새로운 기능을 고객에게 더 신속히 전할 수 있다는 것을 의미한다. 이는 아마존이나 넷플릭스 같은 회사가 소프트웨어를 배포할 때 여러 잠재 문제를 예방하는 수단으로 이 아키텍처를 채택하는 주요 이유이기도 하다.

지난 몇 해 동안 배포 기술이 엄청나게 변화했다. 마이크로서비스 세상에서의 배포에 관해서는 6장에서 더 심도 있게 논의할 것이다.

1.2.5 조직 부합성

대부분의 독자는 대규모 팀과 코드베이스 때문에 생긴 문제를 경험한 바 있을 것이다. 이러한 문제는 팀이 분산되어 있으면 더 심해진다. 더 작은 팀이 더 작은 코드베이스로 일할 때 더 생산적임을 우리는 알고 있다.

마이크로서비스를 이용하면 아키텍처를 조직 구조에 맞게 더 적절히 정렬할 수 있고, 최적의 팀 크기와 생산성을 위해 하나의 코드베이스에서 일하는 인원을 최소화할 수 있다. 그리고 같은 곳에 있는 서비스 소유권을 팀 간에 이전할 수도 있다. 10장에서 콘웨이의 법칙을 논의하면서 이 주제에 대해 좀 더 심도 있게 살펴볼 것이다.

1.2.6 조합성

(옮긴이 주: 조합성(composability)은 컴포넌트 간의 상호연관성을 다루는 시스템 설계 원칙이다. 조합성이 높은 시스템은 고객의 요구사항에 맞춰 다양한 방식으로 선택하고 조립하여 조합할 수 있는 구성 요소를 제공한다.)

분산 시스템과 서비스 지향 아키텍처의 주요 장점 중 하나는 기능을 재사용할 기회가 많다는 것 이다. 마이크로서비스를 통해 다양한 방법과 목적으로 우리가 제공하는 기능이 소비되도록 할 수 있다. 고객들이 어떻게 소프트웨어를 사용하는지 생각해보면 이는 매우 중요하다. 데스크톱 웹사이트나 모바일 애플리케이션에 국한해서 생각하는 시대는 지났다. 이제 우리는 웹, 네이티브 앱, 모바일 웹, 태블릿 앱이나 웨어러블 장치를 위한 기능들을 함께 엮을 무궁무진한 방법을 고민해야 한다. 조직이 고객과의 좁은 채널에서 벗어나 고객이 직접 참여하는 더 포괄적인 개념을 고려하게 된 만큼 이를 지원할 수 있는 아키텍처가 필요하다.

외부에서 직접 접근할 수 있는 시스템의 접합부seam를 마이크로서비스로 개방한다고 생각해보자. 환경이 바뀌면 다른 방식으로 구축할 수 있다. 모놀리식 애플리케이션은 외부에서 사용할 수 있는 하나의 큰 접합부를 가지고 있다. 그 하나의 접합부를 끊어내 외부에서 접근하기 더 유용한 것을 만들려면 아마도 우리는 전체 시스템을 다 때려 부숴야 할 것이다! 5장에서는 기존 모놀리식 시스템을 분리하는 방법과, 더 나아가 재사용 및 재구성을 할 수 있는 마이크로서비스로 변경하는 방법에 대해 논의한다.

1.2.7 대체 가능성을 위한 최적화

만약 어느 정도 규모가 되거나 그보다 큰 조직에서 일하고 있다면, 그 누구도 손대기 싫어하는, 한 귀퉁이에 자리하고 있는 크고 지저분한 레거시 시스템legacy system을 발견할 수 있을 것이다. 이 시스템이 포트란 변종 언어로 작성되었고, 25년 전에 판매가 중단된 하드웨어에서만 동작 한다고 가정하자. 그런데도 교체되지 않는 이유는 교체 작업이 방대하고 수행하기도 어렵기 때문이다.

각 서비스가 작은 크기로 이루어져 있다면 더 나은 구현으로 교체하는 비용을 줄일 수 있으며, 심지어 삭제도 쉽게 할 수 있다. 하루에 100줄 이상을 삭제하고도 크게 염려하지 않았던 때가 과연 얼마나 될까? 마이크로서비스는 대개 비슷한 크기로 이루어지므로 서비스를 재작성하거나 삭제하기 매우 쉽다.

마이크로서비스 방식을 사용하는 팀은 필요할 경우 서비스를 완전히 재작성하는 것을 편하게 생각하며, 서비스가 더 이상 필요치 않으면 쉽게 제거할 수 있다. 코드베이스가 단지 몇 백 줄 규모일 때 개발자들은 자기가 쓴 코드이더라도 집착하지 않으며 교체 비용 또한 매우 적다.