마이크로서비스로의 점진적 전환 시 고려사항

개요

마이크로서비스 아키텍처는 고객의 경험을 높이고 서비스의 민첩성, 성능, 안정성 등을 향상시키는 개방형 아키텍처이다. 마이크로서비스로의 전환은 분산 서비스 환경에서 발생 가능한 트랜잭션에 따른 영향도, 분산 DB 구축에 따른 데이터 처리 또는 더 세분화 하여 서비스 간 동기/비동기 식별부터 DevSecOps 체계를 위한 조직, 문화, 기술의 변화까지 당면 과제들을 맞닥뜨리며 해결과정을 아키텍처에 반영하여, 프로젝트에 적합한 설계 방향을 잡아간다.

여러 당면 과제들이 생겨 나겠지만 프로젝트에서는 오픈 방식에 대해서도 심도있게 고려해야 한다. 전통적인 SI 프로젝트 특성상 빅뱅 방식을 선호하여, 점진적 이행을 추구하는 MSA와 다르게 진행되는 경우가 많다. SI를 통해 프로젝트가 진행되는 경우 대부분 지속적으로 MSA를 유지보수해 나갈 인력의 부족으로 인해 빅뱅 방식으로 오픈하고, 이후 모놀리스 개발 방식으로 회귀되는 경우가 많다.

이와 같은 일이 반복되지 않도록 전환 방식에 따른 영역별 대응 방안을 수립하고, 점진적 이행에 대응할 수 있도록 기술력을 내재화해 나가는 것이 무엇보다 중요할 것이다.

점진적 이행은 마이크로서비스를 한 번에 하나씩 분리하면서 오히려 더 빠르게 대규모 배포를 기다릴 필요 없이 마이크로서비스가 제공하는 가치를 점진적으로 얻을 수 있다. 지금부터는 점진적 확대 방식으로 마이크로서비스를 설계하고 개발할 때 고려해야 할 문제점들에 대해 살펴보고 현재 우리 회사의 도달 수준과 대처방안에 대해 알아보도록 하자.

---

권한 관리

마이크로서비스로 모놀리스 어플리케이션이 세분화되면서, 관리해야 할 대상이 증가하고 있다. 특히, 관리 대상 간의 자원 소유권을 정의하는 것은 역할의 구분이라는 측면에서 민감하고, 중요하다. 분산DB 분리에 따른 데이터 소유자, 소스코드 관리자, 공통 모듈 개발자, API Composition 대상 서비스 등 상호간 중복되는 영역에 대해 역할을 사전에 정의한 후 프로젝트를 진행할 필요가 있다.

---

1) 데이터 소유자

마이크로서비스 별 데이터의 소유 즉 테이블의 owner를 결정하는 것은 마이크로서비스의 성공 여부를 결정할 정도로 중요하다. 데이터의 소유자가 잘못 결정되어 불필요한 데이터 호출이 발생할 경우 서비스의 성능은 물론 정합성에 문제를 발생 시킬 수 있다. 따라서 서비스간 공유해야 할 데이터에 대한 소유자 관리는 데이터모델링을 통해 영향도를 파악하여 결정하는 것이 바람직하다.
CUD를 발생시키는 주체와 그 데이터를 사용하는 주체간에서 데이터 효율성을 재고해야하며, 대체로 공유서비스를 호출하는 빈도와 주고받아야 하는 데이터량을 기준으로 데이터 소유자를 결정하게 된다. 데이터의 소유자는 결국 데이터베이스의 테이블 소유자이며, 이를 기준으로 데이터베이스 분리를 진행한다. 또한, Join 테이블에 따라 결합도를 분석하고, 상호간 복제 또는 CQRS와 같은 ReadOnly DB를 활용하는 방법도 고려해 볼 수 있다.

2) 공통 모듈 개발자

공통 모듈의 경우 마이크로서비스의 규모와 비즈니스에 따라 공통 서비스를 개발하는 별도의 팀을 구성하는 경우와 모든 팀이 개별로 개발하여 배포하는 경우를 예로 들 수 있다. 공통 서비스도 하나의 서비스로 구분하여 단일 팀이 개발하는 경우에는 타 팀의 개발이 시작되기 전 선행적으로 먼저 개발하는 것이 추후 리웍을 줄이는 방안이며, 모든 서비스 간 테스트 방안을 수립해 두는 것이 중요하다. 또한, 각 팀에서 개발한 소스 코드를 머지하기 위한 정책과 배포 시 포함시키는 방안 그리고 무엇보다 개발한 공통 모듈에 대한 검증을 수행하는 단계에 대해 고려되어야 한다.

3) API Composition

데이터에 직접 접근하지 못하는 경우 데이터를 조회하기 위한 API를 개발해야 한다. 이로 인해 팀단위 프로젝트의 경우 상호간 협업이 증가하게 된다.

API Composition의 경우 Client/Server/3rd Party 솔루션/DB 등 다양한 위치에서 API를 조회하고 조합할 수 있다. Client Side도 msa 형태로 개발이 진행된다면, 가능한 Client Side에서 조합하되, 데이터의 양에 따라 CQRS 또는 데이터 복제를 통해 Join을 허용하는 것이 효과적일 수 있다. 물론 Server Side에서도 Composition을 처리할 수 있지만, Client의 결합도를 높일 수 있어 완전한 MSA 환경으로 데이터를 조회하기 위해서는 서버 사이드 Composition은 지양하는 것이 바람직하다.

4) 소스코드 관리

소스코드 관리의 경우 owner, maintainer, developer 등으로 구분하는 역할 기반 롤 배정 방식과 Commit, Merge, Branch 정책 등을 세분화하여 설계하는 정책 기반 롤 배정 방식이 있다.
역할기반 롤 배정 방식은 각 역할 별 특정 권한을 부여하는 방식이다. 예를 들어 maintainer까지 모든 프로젝트에 대한 merge 승인권한을 부여하거나, developer까지 feature branch push 권한을 부여하는 것과 같은 역할을 기준으로 소스코드에 대한 권한을 분리하여 관리할 수 있다.
정책기반 롤 배정 방식은 프로세스를 기준으로 수립한다. developer는 MR을 요청하고, maintainer 1명 이상 코드리뷰를 거쳐 머지 승인을 처리하는 프로세스, feature branch는 developer 이상 dev/stg/prd branch 등 main branch는 maintainer 이상의 승인이 있을 경우 merge한다는 프로세스 등을 프로젝트 내에 정의할 수 있다. 이와 같은 정책 기준으로 각 담당자에게 권한을 배정할 수 있다.
추가로 고려되어야 할 부분은 마이크로서비스로와 관리 조직 규모에 따른 권한 부여이다. 몇개의 팀 내에서 수개의 마이크로서비스를 운영하는 경우에는 각 마이크로서비스를 개발하는 DevOpS 조직 내에서 모두 동일한 권한을 갖고, 타 DevOpS 조직에서 관리하는 마이크로서비스에 접근하고자 할 경우 권한을 제어하여 관리할 수 있다. 또는 내가 속한 DevOps 조직에서도 역할을 세분화하여 이슈과 MR을 통해 권한을 분리하여 관리할 수 있다.

---

대체로 마이크로서비스가 증가함에 따라 개발팀이 세분화되고, 개발자가 늘어나면서 점점 공유되는 리소스에 대한 소유권 문제가 증가하게 된다. 소유권은 굉장히 민감한 문제로 발생시점에 해소하지 않을 경우 문제는 점점 더 심화될 가능성이 높다. 또한, 분리에 대한 해소 없이 데이터나 리소스에 대한 접근 권한을 여러 팀이나 여러 개발자에게 중복적으로 제공할 경우 모놀리스 어플리케이션화 된 마이크로서비스 형태가 될 수 있으며, 이는 마이크로서비스의 장점도 감소시킬 뿐더러 협업 체계를 악화 시키는 결과를 초래할 것이다.
무엇보다 데이터의 소유권이 명확하지 않을 경우 마이크로서비스를 개발하는 팀 간에 마찰이 빈번하게 발생할 소지가 있다. 이를 해소하기 위해 개발자 수가 증가하거나 개발 팀 단위의 역할이 분산될수록 인터페이스에 대한 체계를 만들고, 서비스 공통 데이터에 대한 처리 프로세스를 수립하여 이를 명확히 따르는 협업체계를 구축할 필요가 있다.

---

서비스간 Contract 관리

마이크로서비스는 전체 시스템의 일부로써 동작하며, 개별 서비스로의 역할과 함께 타 서비스와의 인터페이스로 서비스간 통신한다. 서비스는 그 자체의 서비스를 수행하거나, 타 서비스를 호출하거나 반대로 타 서비스로부터의 요청을 처리하는 역할을 담당한다. 이때 서비스간 인터페이스를 정의하는 Contract 관리는 무엇보다 중요하다. 특히 대규모 시스템을 개편/구축하는 프로젝트에서 Contact를 정의하고, 개발하는 것은 테스트 시간의 단축과 운영 장애 발생을 감소시키는 중요한 포인트이다. Contract를 관리해 주는 다양한 도구들이 존재하지만, 이번 포스팅에서는 도구 보다는 이론적인 내용에 맞게 접근해 보도록 하자.
서비스가 증가하고, 서비스간 호출이 복잡해짐에따라, 모든 서비스를 개발하는 담당 파트와 협업하는 것은 때로 시간적인 문제와 효율성 측면에서 고려되어야 한다. 예를 들어 판매 데이터를 조회하기 위해 판매 서비스를 제공하는 팀의 리더와 미팅을 잡고, 조회 시 필요한 데이터를 협의하고, 이를 통해 조회 결과를 테스트하고, 결과에 따라 이 과정을 반복하는 경우 개발 생산성을 저해할 수 있다. 물론 복잡한 비즈니스를 처리하는 경우 반드시 대면 협의가 필요할 수도 있지만, 신속한 서비스 출시라는 측면에서 가능한 간소화 할 필요성이 있다.

---

1) 개발자 포털 활용

마이크로서비스를 개발하는 프로젝트에서는 서비스간 인터페이스를 정의하는 Swagger와 같은 개발자포털을 커스터마이징하여 개발해야 한다. 개발자포털은 개발자간 API를 처리하기 위한 기본 Contract를 정의하여, 협의전 원하는 데이터를 조회하고 얻어 올 수 있는지 테스트해 볼 수 있는 포털이다. 개발자 포털을 통해 mock을 생성하고, Contract Test 전 api 규격을 확인하여 사전 테스트를 수행하여 원하는 데이터를 가져올 경우 반복적인 협의를 줄일 수 있을 것이다. 이를 위해 개발자 포털은 api 규격, api 테스트는 물론 상호간 협의할 수 있는 게시판, 알림 기능 등을 함께 포함하여 구현하는 것이 바람직하다.

2) 현행 API 유지 전략

신규 서비스가 출시되면, 신규 API가 개발되고, 이전 API를 호출하는 Client와 Contract를 통해 이전 API 운영방식을 공유하는 서비스 규칙을 제공해야 한다. 그렇지 않으면 현행 API를 운영하는 타 서비스에 영향을 끼치게 된다.
이와 같은 문제를 해소하는 방법은 두가지로 생각해 볼 수 있다. 먼저 1) 신규 API가 생성될 경우 이전 API를 호환할 수 있는 API를 생성하는 방법이다. 이는 AS-IS, TO-BE 모두 하나의 API로 커버할 수 있다는 장점이 있지만, 불필요한 데이터를 주고 받아야 할 수도 있다. 두번째로 2) 이전 API를 유지하고, 신규 URI를 통해 API를 배포하는 방식이다. 물론 이때 이전 API를 무한정 유지하기보다는 일정 기간 유지하되, 이와 같은 규칙은 사전에 개발자포털을 통해 공지하는 것이 바람직하다.
아래는 고객서비스와 이체서비스간 Contract의 관리를 위한 위 두가지 방식에 대한 처리 흐름을 정리한 이미지이다.

위와 같이 이체서비스가 제공하던 기존 API (A)에 이체 은행 코드가 추가된 신규 API (B)가 추가되었다. 이때 기존 제공하던 API 서비스를 제공하기 위한 방법에 대해 알아보도록 하자.

위 이미지는 현행 API (A) - Service (A) / 신규 API (B) - Service (B)로 각 API 별로 독립적인 Service를 구성하고, 일정 병행 유지 기간이 종료될 경우 현행 API와 Service를 종료하는 방식으로 처리한다. 이는 독립적인 서비스로 운영하기 때문에 안정적으로 운영이 가능하지만, 인프라 관점의 보다 많은 리소스가 필요하고, 필요시 각 API 버전 간 데이터 호환성을 유지할 필요가 있다. 따라서 이와 같은 운영 방식은 단기 병행 운영이 필요할 경우 적합한 방식이라 할 수 있다.

두번째 이미지는 현행 API (A)와 신규 API (B) 모두 신규로 개발된 Service (B)로 연결되는 방식이다. 다만, Service (B)는 API (A)를 호환하도록 개발한다. 이는 마이크로서비스의 복잡도가 증가한다는 문제는 있지만, 현행 API 보존에 대한 문제는 완전히 해소할 수 있다. 이는 장기 병행 운영이 필요한 경우 적합한 운영 방식이라 할 수 있다.
위 두가지 방식은 API를 호출하는 호출자입장에서 새로운 API에 대응할 수 있는 시간을 마련할 수 있다는 측면에서 의미가 있다.
이와 같이 문제점을 해소하면서 최대한 Contract를 유지하고자 노력하더라도 기존 서비스와의 호환성이 깨져 운영 중단되는 경우가 종종 발생할 수 있다. 이러한 문제는 빠른 롤백 메커니즘이 없는 경우 치명적일 수 있다. 항상 배포에 대한 충분한 테스트가 있었더라도 반드시 롤백을 빠르게 수행할 수 있는 매커니즘을 마련해 두어야 한다.

---

데이터 분할

모놀리식 어플리케이션을 마이크로서비스로 분할해 나가는 과정에서 데이터의 분할은 굉장히 민감한 요소임을 블로그 여러 게시글에서 강조한 바 있다. 자세한 내용은 아래 글을 참고하기 바란다.

• 마이크로서비스 분산DB 설계 (분산DB 조회 설계) : https://waspro.tistory.com/724

마이크로서비스 아키텍처를 통해 우리는 이 모놀리식 스키마를 분해하여 데이터 독립성을 유지하는 반면, 데이터 전반에 걸친 대규모 조인 작업과 관련되어 데이터를 제공하기 위한 ReadOnly 복제본을 제공하기도 한다. 그럼에도 불구하고 단일 DB를 사용하던 과거와 다르게 데이터가 논리적으로 격리된 여러 스키마에 분산되어 있으므로 이를 구현하는 것은 굉장히 어려운 일이다. 대표적으로 분산 데이터를 통합하여 조회하는 경우의 예를 들자면, 배치/리포팅을 들 수 있다. 배치/리포팅의 경우 여러 데이터베이스에 분리되어 있는 데이터를 조합해야 할 필요가 있다. 아래는 독립적으로 서비스하는 각 서비스 별 소유권을 갖는 DB와 배치/리포트를 처리하는 DB에 각각 Pooling하며, 서로 다른 비즈니스를 처리하는 방식이다. 이를 통해 배치/리포트 사용자의 특정 요구 사항을 염두에 두고 데이터베이스를 변경할 수 있다. 

먼저 직접 Pooling 하는 방식은 가장 Simple하게 구성이 가능하지만, 서비스간 결합도가 배치/리포팅 DB를 통해 상승할 수 있다는 문제가 있다.

두번째 Kafka를 통해 구성하는 방식은 비동기로 복제가 가능하지만, 일부 개발자 역할의 증가 및 데이터 복제에 대한 보장을 솔루션과 응용에서 수행해야 한다는 문제가 있다. 

마지막 세번째 CDC 도구를 사용하는 방식은 데이터의 정합성을 보장하여 복제하지만, 이기종 DB 간 복제나 비용적인 문제가 있다.

데이터 분할에 따른 조회 성능을 높이기 위한 여러 방안들은 앞서 제시한 포스팅을 참고하기 바란다.

---

Telemetry 확대 구축 및 장애 대응

마이크로서비스 아키텍처로 분할되며, 관리 대상 서버가 증가하고, 복잡한 호출관계에 따라 추적이 복잡해진다. 이로 인해 장애 대응을 위한 Telemetry 환경을 구성하는 것은 필수이다. Telemetry 환경이 구성된 경우 장애에 대해 대응하기 위한 기준을 정의해야 하는데, 이는 각 프로젝트 마다 상이하게 결정할 수 있다.

예를 들어 마이크로서비스는 클라우드 기반으로 구성되는 것이 기본이며, Kubernetes와 같은 Container 기반 어플리케이션을 구성할 경우 그 단위 하나하나가 굉장이 세분화된다. 또한 각 서비스는 Replica를 기준으로 복제되고 Resilience가 높아 가용성과 성능을 보장하는 방식으로 구성된다. 이때, 특정 Container 한대가 다운되었을 경우 어떻게 대처해야 할까?

또 다른 예로 모놀리스 어플리케이션에서 CPU가 오랫동안 100%에 머무른다면 큰 문제가 될 것이다. 수십 또는 수백 개의 프로세스가 있는 마이크로서비스 아키텍처에서 특정 한 프로세스만 CPU 100%를 유지할 경우 장애조치는 즉각적으로 이루어져야 할까?

마이크로 서비스 아키텍처가 성장함에 따라 문제 해결을 위한 대응 방식도 변화해야 한다. 위와 같은 경우 대응방안을 판단하기 위해 많은 경험과 기술력이 필요하며, 특히 비즈니스에 대한 명확한 이해가 있어야 한다. 이로 인해 기존 모놀리식 어플리케이션 운영관리와 다르게 MSA를 위한 SRE는 변화되어 관리되고 있다.

---

1) Logging

수 많은 서비스로 분할 된 마이크로서비스 환경에서 각 머신들에 대한 로그를 일일이 확인하여 상태를 진단하는 것은 사실상 불가능한 일이다. 특히 마이크로서비스 아키텍처는 각 서비스의 수명이 짧아 서비스 장애시 로그를 유실할 수도 있다. 이를 위해 통합로그시스템을 구축하고 모든 로그를 공용 공간에 저장하며, 검색, 색인, 추적 관리할 수 있도록 구성해야 한다. 대표적인 도구로 ELK 스택(Elastic search, Logstash/FluentD 및 Kibana), Splunk 등이 있다.

로그 수집은 구현하기 가장 간단한 메커니즘 중 하나이며 초기부터 구축되어야 한다. 로그의 수집은 초기 문제를 진단하는데 매우 유용하게 사용된다. 단순히 어플리케이션 로그 뿐만 아니라, 해당 프로젝트에서 사용하는 다양한 로그를 수집할 수 있다. 때로는 저널 로그, 인프라 로그를 함께 수집하여 각 서비스 환경에 일일이 접근하지 않고도 쉽게 로그를 확인할 수 있도록 구축해 두는 것은 확장되어 가는 마이크로서비스 점진적 이행 환경에 반드시 선행되어야 할 부분이라는 점을 인지해야 한다.

또한, 로그 수집과 함께 병행되어야 할 부분은 바로 로그를 남기는 방안에 대한 고려이다. 마이크로서비스 간 때로는 레가시 시스템과의 인터페이스가 발생할 경우, 비동기 이슈에 대한 추적 등을 어떻게 효과적으로 커버할 수 있을까 고민해 본다면 그 최적의 방안이 바로 로그이기 때문이다. 시스템간의 추적에 로그를 활용하기 위해서는 각 채널 별 공동으로 정의하는 로그 필드를 프로젝트 차원에서 정의/생성하고, 해당 필드를 Elastic search와 Kibana를 통해 추적관리하는 방식으로 구성할 수 있다.

2) Tracing

마이크로서비스 간의 호출이 실패한 위치 또는 지연 시간이 급증한 서비스를 찾아내는 것은 쉽지 않은 과정이다. 앞서 살펴본 로깅 시스템과 같이 추적을 위한 시스템을 구축하기 위해서는 추적대상 시스템에 공통으로 정의하는 추적 ID를 생성해야 한다.

이체 서비스가 요청을 받으면 최초 받은 요청을 받은 서비스에서 추적 ID를 생성한다. 계좌 서비스를 호출할때 생성한 추적 ID를 함께 전달한다. 이는 HTTP 헤더, 메시지 페이로드의 필드 또는 기타 메커니즘을 통해 수행될 수 있다. 일반적으로 초기 첫 마이크로서비스가 호출될 때 생성되는 추적 ID는 서비스 자체적으로 판단하여 생성할 수도 있지만, API 게이트웨이 또는 서비스 메시를 통해 생성되는 것이 일반적이다.

계좌 서비스는 요청을 처리할 때 동일한 추적 ID와 함께 로그를 기록할 수 있으므로 로그 수집 시스템을 사용하여 주어진 추적 ID와 연결된 모든 로그를 조회할 수 있다. 물론 saga와 같이 추적 ID를 사용하여 다른 작업을 수행할 수도 있다.

 

이와 같은 추적 시스템은 오픈 소스 Zipkine, Jaeger와 같은 분산 추적 시스템을 활용하여 Visualize하여 관리할 수 있다.

3) Monitoring

기존의 모니터링 및 알림 프로세스에서는 무엇이 잘못될 수 있는지 판단하고, 언제 문제가 발생하는지 정보를 수집하여 알림을 발생시키는데 사용되었다. 대체로 디스크 공간 부족, 서비스 인스턴스 미응답 또는 지연 시간 급증과 같은 알려진 문제의 원인을 처리하기 위해 모니터링 시스템을 구축하여 운영한다.
마이크로서비스로 변화하면서 시스템이 더 복잡해짐에 따라, 문제점을 사전에 예측하는 것은 점점 더 어려워지고 있다. 따라서 문제 발생 시 조기에 인지하고, 시스템이 지속적으로 동작할 수 있도록 돕는 동시에 향후 문제를 해결하기 위해 충분한 정보를 수집할 수 있도록 하는 것이 모니터링 시스템의 역할로 변모하였다.
이를 위해 모니터링 시스템은 서비스가 무엇을 하고 있는지에 대해 최대한 많은 정보를 수집할 수 있어야 한다. 장애 발생 초기에는 연속성에 포커싱을 맞추었다면, 문제가 해소된 이후에는 기존의 모니터링 시스템과 같이 장애를 진단하기 위해 모놀리식 어플리케이션 보다 더 많은 메트릭이 수집되어야 함은 당연한 사실이다.

4) Testing

테스트는 마이크로서비스로 변화하며, CI/CD 파이프라인 내의 기능으로 자동화 되도록 구현하는 것이 중요하다. 특히 배포 전에 어플리케이션의 품질을 검증하는 것이 중요하며, 운영환경에도 기능을 검증할 수 있도록 준비되어야 한다.
물론 그 수준의 문제는 있으며, 운영 환경의 신속 배포를 유지하기 위해 테스트 케이스나 종류를 제한하는 것이 일반적이다. 따라서 운영환경에서는 기존의 엔드 투 엔드 테스트 사례를 가져와 적용하는 것도 한가지 방법이 될 수 있다.

또한 CDC(Consumer-Driven Contract) 적용을 고려해 볼 수 있다. 서비스간 테스트는 Mock을 활용하는 테스트 전략이 일반적이다. 다만, 테스트 케이스의 정합성에 따라 테스트가 통과하더라도 실제 서비스에서 실패 할 수 있음을 인지해야 한다. 이를 보완하기 위해 Spring Cloud Contract 적용을 고려해 볼 수 있다.

---

복잡한 분산 환경에서 정확히 언제 문제가 생길지 예측하는 것은 굉장히 어려운 일이다. 특히 개발자와 테스터들이 운영하기 전 많은 테스트 케이스를 가지고 사전 검증을 수행하지만, 그럼에도 불구하고 어떤 부분에서 문제가 발생했는지 알아내는 것은 어려울 수 있다. 이와 같은 문제들을 해소하기 위해 반드시 Telemetry 환경을 구축하고, 진단을 위한 자동화 체계가 구성되어야 한다.

---

관리 플랫폼

점진적 마이크로 서비스 전환이 이루어짐에 따라 관리대상 인프라는 점점 증가하게 된다. 단일 애플리케이션을 관리하기 위한 기존 기술은 변화하는 환경에 대응하기 어렵고, 유연한 확장관리를 지원하지 않는다. 이로 인해 문제 해결에 소요되는 시간이 점점 더 증가할 수 있으며, 수동 작업에 의존할 경우 반복적인 실수가 발생할 수 있다. 이로인해 유지 보수를 위한 더 많은 인력을 요하거나, 서비스를 제공하는 팀이 문제를 해결하는데 더 많은 시간을 할애해야 한다.

이를 해소하기 위해서는 높은 수준의 자동화를 지원하고, 개발자가 배포 환경을 이상적으로 셀프 서비스할 수 있으며, 원하는 자동 상태 관리를 처리할 수 있는 도구가 필요하다. 마이크로서비스의 경우 쿠버네티스가 이 분야의 강자로써 떠올랐다. Kubernetes를 사용하면 경량화된 컨테이너 환경을 지원하며, 여러 시스템에 걸쳐 서비스 인스턴스를 배포하여 회복력을 개선하고 유동적인 부하를 처리할 수 있도록 자동확장 기능을 적용할 수 있다.

Kubernetes는 오픈소스로 Original Version인 바닐라 쿠버네티스만으로는 개발자/운영자에게 친화적인 환경을 지원하지 않는다. Kubernetes 장점의 이면에는 높은 러닝커브가 발생할 수 있다는 문제가 있어 즉시 활용에는 제약이 있는 상황이다. 이에 CSP 사인 AWS EKS, Azure AKS, GCP GKE 나, Private Cloud의 RedHat의 OpenShift, VMWare의 Tanzu, 국내에는 나무기술의 Cocktail Cloud, 맨텍의 Aaccordion, 티맥스클라우드의 HyperCloud와 같은 Kubernetes 패키지 버전을 채택하는 경우가 있다. 이 패키지는 Kubernetes를 Enterprise 환경 내에서 보다 쉽게 활용할 수 있는 도구를 함께 제공한다. 예를 들어, CI/CD를 위한 Tekton, S2I Builder 등을 함께 패키징하여 손쉽게 배포 프로세스를 제공하거나, Telemetry 모듈인 Grafana, Zipkin 등을 포함하여 손쉬운 추적관리 시스템을 구축할 수 있도록 제공하고 있다.

물론, Kubernetes와 같은 플랫폼은 여러 프로세스를 관리하는데 탁월하지만, 높은 러닝커브로 인해 반드시 시스템을 운영하는 부서에서 기술 내재화를 거쳐 구축/운영하는 과정이 필요하다. 따라서 빅뱅방식의 전환이 아닌 점진적 이행과 플랫폼 전환, MiniService 전환 등을 거쳐 MicroService로 전환해 가는 것이 바람직하다.

---

 

결론

이번 포스팅에서는 점진적 마이크로서비스 전환에 따른 영향도에 대해 살펴보았다. 기존 모놀리식 시스템을 분해하기로 결정했다면 점진적으로 진행하며, 빅뱅방식으로의 전환은 지양하는것이 좋다. 점진적인 접근 방식을 진행하면서 마이크로서비스에 대해 이해도를 높여가며 기술 내재화를 진행하고, 또한 방향성이 잘못된 서비스를 바로 잡아가며 전환하는 것이 바람직할 것이다.
모놀리식 시스템을 마이크로서비스 아키텍처로 옮기는 비용이 클 수 있고, 모든 것을 한 번에 수행하는 경우 매몰비용이 크게 작용할 수도 있다. 따라서 단위를 작게 세분화하여 요구사항에 맞는 서비스부터 점진적으로 전환해 나가는 것이 성공 가능성을 높일 수 있다.

최초 마이크로서비스를 전환하는데 걸리는 시간은 다소 오래 걸리 수 있다. 기반 인프라 구축 부터 프로세스 정립, 조직 변화 체계 수립 등 준비 과정이 필요하기 때문이다. 다만, 두번째, 세번째 점진적 전환을 시도할 경우 보다 빠르게 접근할 수 있다. 앞선 경험으로부터 이번 전환이 얻을 수 있는 이점을 판단해 볼 수 있고, 다음 단계를 더 쉽게 만들고 추진력을 얻을 수 있기 때문이다.