MSA
01
마이크로서비스 아키텍쳐 구조
마이크로 서비스 아키텍처에서는 각 컴포넌트를 서비스라는 개념으로 정의합니다. 서비스는 데이터에서부터 비즈니스 로직까지 독립적으로 상호간의 의존성이 없이 개발된 컴포넌트입니다. 각 서비스는 REST API와 같은 표준 인터페이스로 그 기능을 외부로 제공합니다.
서비스경계는 도메인(업무)의 경계를 따릅니다. 예를들어 사용자관리, 상품관리, 주문관리와 같은 각 업무별로 서비스를 나눠서 정의합니다. 사용자/상품관리 처럼 여러 개의 업무를 동시에 하나의 서비스로 섞어서 정의하지 않습니다. REST API에서 /users, /products와 같이 주요 URI도 하나의 서비스 정의의 범위로 좋은 예가 됩니다.
배포 구조관점에서도 각 서비스는 독립된 서버로 타 컴포넌트와의 의존성없이 독립적으로 배포됩니다. 예를 들어 사용자 관리 서비스는 독립적인 war파일로 개발되어, 독립된 톰캣 인스턴스에 배치됩니다. 확장을 위해서 서비스가 배치된 톰캣 인스턴스는 횡적으로 스케일 (인스턴스 수를 더함으로써)이 가능하고, 앞단에 로드 밸런서를 배치하여 서비스간의 로드를 분산 시킵니다.
가장 큰 특징이, 애플리케이션 로직을 분리해서 여러개의 애플리케이션으로 나눠서 서비스화하고, 각 서비스별로 톰캣을 분산 배치한 것이 핵심입니다.
02
마이크로서비스와 API Management
위에서 언급되었던 바와 같이 마이크로서비스의 각 모듈은 API 를 통해 서로 통신을 합니다. 여기서 API의 정의를 살펴보면, API 란 하나의 어플리케이션이 다른 어플리케이션과 통신할 수 있도록 만들어주는 어플리케이션 프로그래밍 인터페이스 (Application Programming Interface) 입니다.
지난 수십년 동안 API는 발전해왔다
-
1960-1980
Basic interoperability enables the first programmatic exchanges of information. Simple interconnect between network protocols. Sessions established to exchange information.
Techniques : ARPANET, ATTP and TCP sessions.
-
1980-1990
Creation of interfaces with function and logic. Information is shared in meaningful ways. Object brokers, procedure calls, adprogram calls allow remote interaction across a network.
Techniques : Point-to-point interfaces, screen scraping, RFCs and EDI.
-
1990-2000
New platforms enhance exchanges through middleware, interfaces begin to be defined as services. Tools manage the sophistication and reliability of messaging.
Techniques : Message-oriented middle ware, enterprise service bus, and service oriented architecture.
-
2000-Today
Businesses build APIs to enable and accelerate new service development and offerings. API layers manage the OSS / BSS of integration.
Techniques : Integration as a service, RESTful services, API management and cloud orchestration.
역사적으로 볼때 1960년에서 1980년대까지는 시스템간의 운영을 가능하게하는 아주 기초적인 Programmatic Information Exchange 에 불과 하였고, 프로토콜 역시 ARPANET, ATTP & TCP 같은 네트워크 기반의 세션 기반 프로토콜이었습니다. 1980년에서 1990년사이의 Information exchange는 Point-to-Point Interfaces, Screen scraping, RFCs & EDI 같은 기능과 로직을 가지고 다이나믹한 방법으로 이루어졌습니다. 이기간에 정보는 네트워크간 교류를 가능하게 하는 Object Brockers, Procedure Calls & Remote Program calls을 통하여 공유되었습니다.
1990년에서 2000년사이의 Information Exchange는 서비스로 정의되는 미들웨어와 인터페이스를 통하여 향상되었습니다. 이 시기에는 미들웨어의 등장과 함께 ESB (Enterprise Service Bus)데크놀로지를 사용하기 시작했고, 이후 서비스의 확장과 더불어 엔터프라이즈 아키텍쳐는 점점 SOA (Service Oriented Architecture)로 옮겨지게 되었습니다. 2000년 이후부터 오늘날까지 APIs는 Rest Protocol을 지원하는 다음 단계로 진화하게 되었고 API management systems 과 cloud API management 제품들이 인기를 끌기 시작하였습니다. 그 이후로 점점 마이크로서비스가 점점 주목을 받기에 이르렀고 차세대 Information Exchange를 위한 커다란 변화가 일기 시작했습니다.
아래의 그래프에서 확인할 수 있듯이 APIs는 2005 이후로 계속 증가하기 시작하였고 REST APIs 가 가장 인기있는 Architectural Style 이고, 여기서 한가지 주목할 부분은2014년도에 Web APIs 가 엄청나게 증가한 부분을 확인할 수 있는데 이는 Docker 가 시작된 시점이라 할 수 있습니다.
03
마이크로서비스와 도입 시 고려사항
앞서간단히 설명한바와 같이 마이크로서비스로 전환하는 이유는 모노리틱이 효율성이 크게 떨어지며 기업이 기민하게 사업을 하기어렵게 만들기 때문입니다. 앞서 설명한바와 같이 모니리틱 아키텍쳐는 민첩성(Agility)과 유연성(Flexibility), 재활용성 (Reusability)이 현저히 떨어짐을 의미합니다.
그렇다고 마이크로서비스로 전환하는 일이 쉬운 일이라는 뜻이 아닙니다. 전환을 시작하기전에 모노리틱의 문제점과 한계를 확인하고 그것들을 독립된 여러개의 서비스로 나누어볼때, 각 서비스의 "적정규모"에 너무 에너지를 소모하지 말아야 합니다. 서비스크기에 따라 코드의 양이 달라집니다. 더 중요한 것은 각 서비스들이 맡은 역할의 범위 안에서 목적하는 업무 로직을 처리할 수 있도록 하는 것입니다. 마이크로서비스 개발자와 설계자는 모노리틱 소스코드에서 분리된 서비스블록 코드의 사이즈에 과도하게 신경을 쓰는 것이 보통입니다. 그러나 각 서비스들이 담당 업무 로직을 처리하는데 적정한 크기라면 충분합니다. 모노리틱을 과도하게 배척하면 마이크로서비스들이 너무 많아지게 됩니다. 새 아키텍쳐 역시 구축하고 운영하는 과정에서 문제점이 발생하면 서비스들을 더욱 세분해야 할 때가 반드시 있게 됩니다. 또 한가지 유념할 중요한 문제가 전환을 시작한 뒤에도 모노리틱 방식으로 사업을 운영하고 확대할 수 있어야 한다는 점입니다.
이를 위해 개발 시기에 팀을 두개의 작은 팀으로 나누어 "책임을 분산" 하는 것이 좋은 방법입니다. 기존모노리틱을 유지하는 팀과 새로운 소스코드로 작업하는 팀. 이렇게 하려면 인력 배치에 더욱 신경을 써야 합니다. 팀을 나누는데 따른 부작용으로 두 팀 사이에 알력이 생길 수 있기 때문입니다. 대규모 모노리틱 어플리케이션을 유지하는 일은 새로운 기술로 작업하는 것만큼 재미있는 일이 아닙니다. 이 문제는 팀의 규모가 클수록 해결하기 쉽습니다. 팀 구성원들을 두가지 작업에 교대 배치할 수 있기 때문입니다. 이렇게 하면 모든 팀 구성원들이 새로운 개발 업무를 함으로써 프로그래머들이 선호하는 새로운 기술을 습득할 수 있으며 모노리틱도 새로운 시각으로 접근할 수 있게 됩니다. 다음 고려해야할 사항이 시간입니다.
마이크로서비스로의 전환은 하룻밤 새 할 수 있는 것이 아닙니다. 아무리 고민하고 계획을 많이 세워도 재빨리 해치울 수는 없습니다. 마이크로서비스로 전환하는 것은 상당한 엔지니어링 투자입니다. 그러나 일정 규모 이상의 어플리케이션이라면 투자한 만큼 혜택이 있습니다. 대부분의 기업들이 마이크로서비스 아키텍쳐를 고려하거나 설치하는 이유는 모노리틱이 갈수록 커지고 팀 규모도 따라서 커지는 문제를 해결하기 위한 것입니다. 마이크로서비스로 전환하기 위해선 단순히 프로그램을 분리하는 것을 넘어 개발 팀도 새로 구축해야 한다는 점에서 기술적 변화와 함께 조직적 변화도 뒤따르게 됩니다.
이처럼 근본적인 변화를 하기 위해서는 장기적 계획이 반드시 필요하며, 준비 작업과 검증작업이 있어야만 성공적으로 전환할 수 있습니다. 이는 하룻밤 새에 이룰 수 있는 작업이 아닙니다. 또 이행 만을 위한 절차와 프로그램을 만들고 사용한 뒤 나중에 제거해야 하는 경우도 있습니다. 예컨대 이행과정에서 기존 데이터베이스를 활용하기 위한 별도의 아키텍쳐, 인증과 허가 기능과 같은 것들을 처리하기 위한 별도의 아키텍쳐가 필요한 것입니다. 이 모든 어려움을 극복하고 전환에 성공하면 마이크로서비스 아키텍쳐 덕분에 기업들은 보다 민첩 해질 수 있으며 어플리케이션 개발 속도도 크게 빨라질 수 있습니다.
