Medium - What, Why, When; Microservices
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 마이크로 서비스는 무엇이고 왜 해야하며 언제 해야하는가; 직관적인 가이드
One-Liner
마이크로 서비스는 원격으로 접근가능한 컴포넌트로 응용프로그램을 쪼개놓은 구조입니다. 마이크로 서비스는 그런 컴포넌트의 인스턴스를 가리키는 말이기도 합니다.
Simple Idea, Seems Complex
마이크로서비스의 개념은 실제적으로 매우 간단하지만 입을 열어서 설명할려고 하면 끊임없이 복잡해지는 개념입니다. 여기서는 최대한 잘 설명해 보겠습니다. 매우 직관적인 가이드로 정말 필요한 것들만 언급하겠습니다.
제가 만약에 마이크로서비스의 이름을 다시 붙일 수 있다면 저는 아마 원격적으로 분리된 응용프로그램 아키텍쳐라고 하겠습니다.
우리는 마이크로서비스가 무엇이며 왜, 그리고 언제 마이크로서비스를 사용해야 되는지 알아보겠습니다.
Services
먼저 혼동을 피하기 위해서 여러분은 서비스(혹은 웹서비스)가 무엇인지 정확하게 아셔야 합니다. 서비스란 요청에 의해 응답할 수 있는 원격적으로 사용가능한 자원입니다 모든 의도와 목적에서 이 말은 서비스가 동작하는 URL들을 제공해야 한다는 것입니다. 전체적인 웹(클라우드)은 서비스 제공자와 클라이언트 사이에 상호작용하는 URL의 집합처럼 보일 수 있습니다. 그렇기 때문에 우리는 서비스가 URL을 구동하는 인프라 라고 말할 수 있습니다.
API
특정 URL들은 흔히 엔드포인트라고 불리며 엔드포인트들의 집합은 API라고 합니다. 앱 아키텍쳐를 설명할 때 서비스는 주로 API나 앱의 프로그래밍 인터페이스를 말합니다. 이것은 소프트웨어 패키지 내에 있는 특정 목적을 위한 API들과 통신하기 위해서 있는 것으로 마치 소프트웨어 컴포넌트간 결합 부분의 인터페이스처럼 동작합니다.
우리는 거시적으로 API그룹을 컨수머와 인프라로 나눌 수 있습니다. 아직도 큰그림에서 ㅁ라하는 것이지만 컨수머 API는 클라이언트들이 그들의 목적을 충족시키기 위해 소비되는 것이며 내부에 존재하는 API들은 적절하게 동작하기 위해 필요한 인터렉션을 수행합니다. 이 내부에 API들을 인프라 API라고 부릅니다.
그러니까 API(다양하지만)는 결과이고 서비스들은 시작입니다. 서로 바뀌어서도 사용되지만 크게 상관은 없습니다. 그것들이 뭔지 확실히 알고 있으니까요.
Web Apps
웹 응용프로그램은 서비스를 제공하고 소비합니다. 마지막 날까지 그게 웹 앱이 존재하는 이유입니다. 여기서 질문은 웹 응용프로그램을 위한 최선의 디자인은 무엇이고 어떻게 견고하고 효율적으로 유지보수할 것인가 하는 것입니다. 이것은 꽤나 어려운 질문이 됩니다.
Internal Design and External Architecture
마이크로서비스 구조는(이전의 패러다임인 서비스 기반 구조,SOA) 웹 응용프로그램의 목적으로 사용됩니다. 서비스를 노출하고 해당 응용프로그램의 디자인으로 메카니즘을 변환하는 것입니다. 우리는 신중하게 왜 마이크로 서비스가 필요하며 언제 쓰는 것이 좋은지 살펴봐야 합니다. 왜냐면 결국에 여러분이나 저나 기술이 쿨하거나 트렌디하다고 쓰게 되니까요. 동시에 우리는 마이크로서비스가 무엇인지 파고들어가서 우리는 왜에 대한 탄탄한 기반을 가지게 될 것입니다.
마이크로 라는 것이 결코 서비스의 크기를 말하는 것이 아닙니다. 마이크로 서비스는 연관된 기능들을 담고있는 집합이라는 것이며 그들을 네트워크 리소스에 노출시키는 것입니다. 그러고 나면 네트워크 리소스에 있는 응용프로그램의 컬렉션들을 조합하는 것입니다. 서비스를 이용해서요 그렇게 하면서 내부 응용프로그램 디자인과 외부 응용프로그램 구조의 경계가 모호해집니다. 그래서 응용프로그램의 외부가 어디인지 정확하게 말하는 것이 어려우며 어떤 것이 응용프로그램의 요소이거나 노드인지 말하기 어려워집니다.
이런건 원격 데이터베이스나 외부 서비스, 브라우저 클라이언트가 응용프로그램의 요소로 있다면 항상 있어왔던 케이스 들입니다.
Remotely Decoupled Application Architecture
마음을 바꿔서 여기서는 한번 마이크로 서비스의 대체적인 이름을 고려해봅시다. 이 개념에 제가 이름을 붙인다면 원격으로 분리된 응용프로그램 아키텍처라고 할겁니다. 아니면 RDAA라거나, 마이크로서비스처럼 캐치한 것은 하니지만 집에 오는 길에 생각난겁니다.
Component
소프트웨어 디자인의 하단부는 여러분이 조각조각 나눠야 하고 연관된 조각을 모아서 작업이 수행될 수 있도록 해야 합니다. 이것은 함수부터 더욱 상위개념까지 모든 레벨의 소프트웨어에서 이뤄져야 합니다. 그래서 전체적인 응용프로그램의 구조로본다면 질문은 어떻게 쪼개야 가장 효과적인가 하는 것입니다.
Layered Architecture
오랫동안 웹앱에서 이 질문에 대한 대답은 레이어로 쪼개라 였습니다. 각 레이어로 구분하는 목적은 기술적인 목적으로 나누는 것입니다. 대개 데이버 접근, 비즈니스 로직, UI입니다. 이것은 꽤나 타당하고 효과적입니다. 그림 1을 보시죠.
Fig. 1: Basic Layer Design
이런 레이어들은 응용프로그램 노드로서 배포되는 유닛입니다. 이런 레이어들은 내부적인 패키지와 모듈, 그리고 앱 내부에 있는 준수해야할 API의 컨벤션들로 이뤄집니다. 이런 API들은 내부적으로 묘사될 수 있으며 혹은 로컬API라고 합니다. 로컬 API들은 모든 응용프로그램에서 상위레벨의 내부 구조를 담당합니다. 전통적인 앱들은 이런 로컬 API의 투명성과 조직에 의존합니다. 그러나 이것은 모노리틱 아키텍쳐가 되며 새로운 스타일인 마이크로서비스에 반하는 것입니다.
마이크로 서비스는 뿌리가 사용가능하 원격 API를 확장하여 배포하는 것이 쉽습니다. 원격 API의 다른 이름으로는 앞서 말씀드렸지만 서비스 입니다. 기술적인 역할에 따라 레이어를 구분하는 응용프로그램 디자인 대신에 마이크로 서비스는 응용프로그램의 부분을 노드로 그룹화 시키며 해당 그룹은 논리적으로 비즈니스와 연관된 요소들입니다. 그렇기 때문에 각 노드가 분산되어 배포될 수 있으며 네트워크에서 서로 통신을 하는 것입니다.
Evolving the Monolith
잠깐 멈춰서 꼭 필요한 질문을 생각해봅시다. 마이크로서비스도 그렇고 왜 우리가 소프트웨어를 조각조각 나눠야 할까요? 여기에는 여러가지 대답이 있을 수 있지만 대개 2가지로 귀결됩니다. 사람이 이용하는데 이해하기 쉽게 만드는 것이며 컴퓨터가 동작하기에 효율적이기 때문입니다. first camp에서는 여러분이 유지보수와 재사용성 같은 것들을 관리해야 합니다.
그래서 우리는 응용프로그램을 파트로 나누는 것이 사람이 관리하기 쉬우며 성능이 더 잘나오기 때문이라고 말할 수 있습니다. 이제 계속해서 왜 우리가 응용프로그램 구조를 고려해야 하는지 뒷주머니에서 알아봅시다.
Fig. 2: Basic Microservice
An Example App
더욱 실질적인 것을 만들어 보고 예제를 고려해봅시다. 우리가 웹메일 앱을 만든다고 칩시다. 모노리틱 디자인으로 레이어를 나눌 경우 이 앱은 어떻게 될까요? 레이어된 응용프로그램 디자인은 다음과 같을 것입니다.
Fig. 3: App Layers — Detail
그림3에서 추가된 사실은 영구적인 데이터와 앱의 UI요소가 정말로 코어 앱에서 분리되어 있다는 것이며 코어 앱은 이런 요소와 통신하는 레이어를 가지고 있고 비즈니스 로직을 담당하는 레이어와 함께 있다는 것입니다.
Business Logic Divisions
이제 한발 더 나가서 실제적인 비즈니스 프로세스를 추가해봅시다.
Fig. 4: App Layers With Business Areas
Business Logic Decoupling
비즈니스 영역은 간단하게 우리가 고려하는 다양한 영역입니다. 예를들어 이메일 웹 앱에서는 최소한 인증, 허가, 메일발송, 메일 수신, 메일 포워딩 등이 있을 것입니다.
Fig. 5: Webmail App Detail
이제 마이크로 서비스가 제시하는 것은 그림 6과 같습니다.
Fig. 6: Webmail Microservice Architecture
이것이 일반적으로 단순하다고 생각하시겠지만 여러분이 감을 잡으셨을거라 생각합니다. 각 비즈니스 목적의 영역이 하나의 응용프로그램 노드에 통합되는 것 대신에 독립적으로 배포될 수 있는 유닛으로 쪼개어지고 네트워크로 통신을 하게 됩니다. 여러분이 기억하셔야 할 점은 노드의 레이어드 디자인은 그대로 있다는 것입니다. 노드 자체가 관리할 수 있게되는 구성 원리를 위반하지 않은 것입니다.
The Layers are Still There
어떤 마이크로서비스는 동일한 레이어가 필요없을 수도 있습니다. 서비스가 UI를 필요로 하지 않는 API일 수도 있습니다. 우리는 서비스의 레어이를 3가지 목적으로 일반화 할 수 있습니다. API 제공, API 사용, 비즈니스 로직 입니다.
이런 레이어들은 모든 서비스에 있을 것이지만 다른 서비스들을 작업에 사용하지 않는 간단한 데드 엔드 서비스들은 없을 것입니다. 이제 마이크로서비스의 구조를 보는 것은 충분한 것 같고 다시 근본적인 질문으로 돌아가봅시다. 왜죠? 왜 마이크로 서비스를 써야하죠?
이 질문은 작업하기 좋은 가장 효과적인 원격 API의 경계가 어디인가? 가되어야 합니다.
Microservice Plusses and Minuses
확실하게 마이크로서비스는 번들 레이어 스타일 위에 추가적인 아키텍처를 나타냅니다. 최소한 서비스들은 그들사이에 네트워킹이 되어야 하고 각각 머신이 배치되어야 합니다. 장점은 각 서비스들이 독립적으로 유지보수되고 배포되고 결합도가 낮아진다는 것입니다. 우리의 머리에 떠오른 질문은 마이크로서비스를 써야할까요? 가 아니라 가장 작업하는데 효과적인 원격 API 바운더리가 어디인가 하는 것입니다.
두가지 목적을 기억하세요. 사람과 컴퓨터의 효율입니다. 우리는 마이크로 서비스가 두가지 장점을 제공한다고 말할 수 있습니다.
첫번째 경우 결합도가 낮은 컴포넌트들은 서비스들을 이해하기 쉽게 만들고 관리하기 쉽게 만듭니다. 서비스가 하는 일과 API 노출에만 신경쓸 수 있으며 다른 일들을 걱정하지 않아도 됩니다. 말할 필요도 없이 이것은 양날의 검으로 다양한 서비스와 연관된 기능을 추가하거나 공유 자원을 리팩토링 할 때는 공수가 많아집니다.
개념적으로 그리고 조직적으로 절차가 깔끔하다면 마이크로 서비스는 개발팀에 큰 이익이 될 것입니다. 그리고 성능또한 마찬가지 입니다. 더욱 작고 많이 포함된 서비스들은 더욱 최적으로 튜닝될 수 있습니다. 이말은 우리가 앱 요소 클러스터를 작게 만들면 앱 전체를 복사하는 것과는 달리 오직 작은 부분이 헤비로드가 된다는 것입니다.
성능과 효율성 또한 개선될 수 있는데 작은 서비스들은 서버리스 환경에서 동작할 수 있으며 실제적으로 사용량에 대해서만 비용을 지불하면 됩니다.
For Real: When Should We Use MicroServices?
먼저 마이크로 서비스는 이상적인 형태에서 정말 감탄할만한 개념이라는 것입니다. 마이크로 서비스는 SOA 개념을 잇는 것으로 핵심 원리는 응용프로그램의 함수를 독립시켜서 서로 네트워크 API 바운더리에서 통신하느 ㄴ것입니다. 마이크로서비스와 SOA들이 직면한 문제는 필드에서 현실들입니다. 서비스를 배포하고 관리하는 것은 복잡하고 오버헤드가 있죠.
이런 사실은 도커나 쿠버네티스와 같은 도구의 소개때문에 점점 나아지고 있는 상황입니다. 그러나 이런 추가적인 도구를 여러분에 팀에 알려줘야만 하죠. 제 주관적인 의견은 마이크로서비스는 성공적으로 사용되기 위해서는 큰 조직이 필요하고 또한 적절한 운영환경이 있어야 장점이 될 것입니다. 제말은 대부분의 응용프로그램들은 단일 배포 유닛으로도 잘 동작할 것이고 필요하다면 클러스터될 것입니다. 그것을 변경하려면 정말 납득할만한 성능 혹은 조직적 이유가 필요할 것입니다, 필연적으로 네트워크에 서비스를 독립시키는 작업 또한 누군가의 공수가 들어야 하고 이것또한 계산에 포함되어야 할 것입니다.
More Examples
거의 끝이났습니다. 웹 메일 예제를 더욱 고도화 시켜보겠습니다. 실제적이니 예제에서는 어떻게 동작하는지 보여드리겠습니다.
Service Exposures
그림 7에서 다이어그램은 더욱 현실적인 연결을 정의하고 있습니다. 사실 많은 서비스들은 UI와 마주치지 않습니다. 포워딩, 수신, 발신 메일 서비스는 화면 뒤에서 일어나며 인프라 API 처럼 동작합니다. 우리가 이것을 서비스의 노출 레벨이나 타입으로 생각해 볼 수 있습니다. 그렇다면 어떤 것이 서비스와 클라이언트에게 노출되어야 하는지 생각해봅시다.
Fig. 7 Webmail Microservices Refined: Exposure Levels
또한 각 서버들은 provide/consume이라는 라벨이 붙었습니다. 이게 더욱 정확합니다.
Adding a Service
이제 우리가 오고가는 메일에 악성 코드를 필터링 한다고 가정합시다. 해당 기능을 추가하기 위해 소프트웨어 패키지에 빌드하는 것이 아니라 송신, 수신 어플리케이션 노드에 추가할 것입니다. 우리는 새로운 서비스를 배포하고 메일 필터링 마이크로서비스에 연결할 수 있습니다.
Fig. 8 Adding a Sanitize Mail Service
물론 이것은 작업이 VM/서버리스 환경에서 이뤄졌고 연관된 서비스들이 dev/test/production 네트워크로 설정되어 있다는 것을 의미합니다.
Two Kinds of Service: Ours and Theirs
다른 유용한 서비스 타입의 구분은 누가 소유하고 있는지에 관한 것으로 우리가 소유하는지 아니면 제 3자가 소유하는지로 구분하는 것입니다. 우리는 인프라와 내부 서비스에 대한 책임을 지고 있고 우리가 공공 API나 과금 서비스와 같이 써드파티는 외부에 속한다고 볼 것입니다.
Fig. 9 Ours Services vs. Others’
마지막으로 우리가 소비하는 외부 서비스를 끝에 추가할 수 있습니다. 또한 그림 9와 그림 10모두 UI서비스가 UI 설정을 담당하고 있고 UI응용프로그램들은 에셋을 전달하여 처음에 UI 클라이언트가 설정하는 일을 담당합니다.
Summary
- 마이크로서비스의 정의
- 마이크로 서비스는 기본적으로 SOA를 잇는 것이다. 레이어로 나뉘던 기존의 방식에서 비즈니스 로직에 관련된 노드로 나누는 것이다.
- 해당 노드들은 서로 네트워크로 통신하며 개별적으로 배포될 수 있다.
- 이런 분리된 노드 관리를 도커나 쿠버티네스로 할 수 있게 되어 공수가 줄었다.
- 서버리스 환경에서는 관리 포인트가 더욱 줄어들 수 있다.
- 마이크로서비스 아키텍쳐는 올바르게 사용하는 곳에서 효율적이다. 만약 단일 배포 시스템으로 충분히 가능한 구조라면 그렇게 심플한 구조를 택하는 것이 더욱 좋을 것이다. 필요하다면 클러스터만 하면 된다.
