[컴퓨터월드] 마이크로서비스 아키텍처(MSA)에는 독립적으로 배치, 확장, 운영될 수 있는 서비스 설계가 요구된다. 마이크로서비스를 설계하는 기술 전문가들은 성공적인 전송을 보장하기 위해 적절한 인터페이스와 구현, 데이터 지속성, 의존성 관리 패턴을 사용해야 한다.

MSA는 개발팀이 보다 빠르게 기능을 제공하고 개발 조직을 확장하도록 지원하며, 서비스가 필요에 따라 빠르고 정확하게 확장되도록 만들어준다. 이러한 기능은 복잡한 단일 시스템을 독립적으로 개발, 배치 및 운영될 수 있는, 느슨하게 묶이고 좁은 범위로 제한되는 구성 요소 서비스로 해체했을 때 구현된다. 그러나 이렇게 민첩성과 확장성을 늘리기 위해서는 비용이 든다. 서비스 세분성이 높아질수록 다음과 같은 사항도 함께 증가한다.

■ 여러 개의 독립 부분으로 구성된 애플리케이션 설계 및 관리의 어려움
■ 서비스를 지원하는 데 필요한 ‘외부 아키텍처’의 복잡성
■ 분산된 다중언어 시스템의 문제 해결에 대한 노력

아키텍처는 시스템 내의 변화를 관리하기 위해 지능적인 균형을 만드는 것이며, 비즈니스 가치를 제공할 때 시간과 에너지를 어디에 투자할지에 대해 실용적인 입장을 취하는 것이 중요하다. MSA를 채택할 때의 목표는 예산, 기술 및 조직 제약에 부합하는 세분성과 해체 간 적절한 균형을 찾는 것이다.

가트너는 이러한 균형을 찾기 위해 완전히 새로운 애플리케이션을 생성하는 경우에도 낮은 레벨로 세분화된 서비스와 애플리케이션 중심적 구축 모델로 시작하는 것을 추천한다. 단순한 애플리케이션 아키텍처를 구축하고 배치하는 것은 구성요소의 세분성과 독립성이 높아짐에 따라 더 민첩해지도록 만들고, 이를 통해 개발이 가장 높은 가치를 목표로 할 수 있도록 만들어 준다.

이해당사자들이 특정 기능을 특정 날짜에 제공받고자 요구한다면 이들은 마이크로서비스의 민첩성과 유연성에서 오는 이점을 누리지 못할 것이다. 이 경우 마이크로서비스가 기술적인 적합성보다는 문화적인 적합성에 아직 맞지 않는 것이라고 볼 수 있다. 마이크로서비스가 필요하지 않은 상황이거나 조직이 이에 투자할 준비가 되지 않았다면, MSA를 도입하지 않아야 한다.

가트너의 접근법

마이크로서비스 설계에 대한 가트너의 접근법은 ‘느슨한 결합’의 원칙에 초점을 맞추고 있다. MSA의 이점을 실현하기 위해서는 가능한 모든 곳에서 분리되는 서비스를 설계 및 개발하고, 가능한 한 느슨하게 결합된 의존도를 유지하는 것이다. 이 접근법을 이용하면 독립적으로 각각의 서비스를 개발하고 배포할 수 있다. 이러한 독립성은 결과적으로 비즈니스 요구에 부응해 빠르게 변화하고 서비스를 개별적으로 확장할 수 있도록 한다.

가트너의 접근법은 MSA를 사용하는 시스템에 관련된 모든 팀이 이러한 실천사항을 공유하고 수용할 것을 요구한다. 지침에 포함된 사항들은 정적이거나 규범적이지 않기 때문에 각 팀들은 데브옵스(DevOps) 원칙을 따라야 한다. 또한, 팀은 다음과 같은 사항을 수행할 수 있어야 한다.

■ 제약이 되는 부분과 병목 현상을 찾아내고 이를 해소하기 위해 작업한다.
■ 위험을 식별하고 이를 줄이기 위한 조치를 취한다.
■ 실무를 개선하기 위한 기회를 파악하고 행동을 취한다.

마지막으로, 여기에서 언급되는 지침만으로는 MSA를 성공시킬 수 없다는 점을 이해해야 한다. 마이크로서비스가 구축, 배포 및 실행될 운영 환경과 분산된 관리 플랫폼을 제공할 필요가 있다. 외부 아키텍처는 향후 설계 및 구축될 마이크로서비스에 대한 맥락을 제공하며, 서비스 대 서비스 통신 관리, 송수신 관리, 서비스 상태 모니터링, 서비스 구축 및 배포 자동화 등의 기능을 아우른다.

지침 프레임워크

마이크로서비스를 성공적으로 설계하기 위해서는 다음과 같은 지침을 수행해야 한다.

■ 마이크로서비스가 올바른 아키텍처인지 확인하고 조직이 이를 활용할 준비가 되었는지 확인한다.
■ 서비스 간 의존성을 관리하는 방법을 정의한다.
■ 서비스가 상호 간에 어떻게 소통할 것인지 정의한다.
■ 서비스의 수명을 어떻게 관리할 것인지 정의한다.
■ 분해 전략을 이용하여 추출 또는 창출할 서비스를 확인한다.
■ 느슨하게 결합된 서비스를 설계한다.

위험과 함정

마이크로서비스를 채택하고 설계 지침을 따를 경우 아래와 같은 위험요소와 함정이 있을 수 있다.

함정: 호환되지 않거나 부적절한 프로세스와 문화, 스킬, 플랫폼

MSA를 사용해 애플리케이션을 제공하는 것은 훈련과 민첩성을 필요로 하는 고차원적인 접근법이다. 서비스를 분리하는 것은 이러한 민첩성의 초석이 되며, 조직이 이러한 방식을 확립하고 유지하기 위한 올바른 환경을 조성하는 데 투자하지 않으면 마이크로서비스의 장점은 사라지게 된다. 훈련된 분리 없이는 변화에 취약하고 배치 및 운영이 복잡한, 단순히 분산된 애플리케이션 아키텍처를 얻는 데 그치게 된다.

이러한 함정을 피하기 위해서는 편의성보다 분리를 위해 필요한 엔지니어링 분야를 지원하는 프로세스와 문화, 스킬, 플랫폼을 구축해야 한다. 이러한 노력의 일환으로 MSA 도입 전 애자일 개발 방식과 CI/CD(Continuous Integration/Continuous Delivery)를 도입해야 한다.

함정: 너무 이른 시기에 지나치게 세분화하는 것

아키텍처 측면에서 MSA가 빠지기 쉬운 유혹 중 하나는 가능한 한 작은 ‘초소형’ 서비스를 만드는 것이다. 이러한 세분성은 서비스, 서비스 의존성, 서비스 운영의 관리를 더 복잡하게 만든다. 이처럼 과하게 세분화된 해체로 인해 비즈니스 상 이익을 얻지 못할 수도 있다.

이러한 함정에 빠지지 않기 위해서는 아키텍처가 민첩성을 저해한다는 확신이 있을 때에만 애플리케이션을 보다 세분화된 서비스로 해체해야 한다. 마이크로서비스의 복잡성을 도입하기 전에 프로세스, 플랫폼, 자동화 구축, 테스트 및 배치 스킬을 최적화해 기존 애플리케이션 아키텍처의 민첩성을 개선해야 한다. 또한 애플리케이션을 해체하기 시작할 때는 낮은 수준으로 세분화된 서비스를 해체하는 것에서 시작해야 한다. 명확하고 측정 가능한 이점이 보일 때에만 더 세분화된 서비스로 넘어가야 한다.

위험: MSA가 제공하는 민첩성이 필요 없는 경우

MSA는 지속적인 변화를 가능하게 하도록 설계돼 있다. 조직에서 애플리케이션을 빈번하고 지속적으로 변경할 필요가 없는 경우에는 마이크로서비스로 애플리케이션을 구축하는 데에서 오는 이점을 거의 또는 전혀 얻을 수 없다. 마이크로서비스는 보통 ‘아키텍처의 다음 논리적 단계’로 홍보된다. 마이크로서비스가 제공하는 민첩성에 대한 진정한 필요성을 검증하지 않고 단지 이러한 이유로 마이크로서비스를 추구하는 조직은 MSA의 이점을 깨닫지 못한 채 유지 비용만 부담하게 된다.

이러한 종류의 위험을 완화하기 위해서는 조직에서 지속적인 변화 요구의 근원이 있는지, 빈번한 변화를 받아들일 의사가 있는지 확인해야 한다. 개발팀은 독립적으로 서비스를 출시하는 데 어려움을 겪지 않아야 한다.

위험: 마이크로서비스를 구축한 팀이 ‘멋진’ 다음 프로젝트로 넘어가는 것

조직이 마이크로서비스를 도입함에 따라, 몇몇 개발자들은 새로운 기술과 새로운 아키텍처 패러다임을 사용하고자 하는 욕구로 고무될 것이다. 초기 개발 단계를 거치고 생산 과정에서 마이크로서비스를 운영하고 있다면, 개발자들은 조직의 내부 혹은 외부에서 또 다른 ‘멋진’ 프로젝트로 넘어가고자 할 수도 있다. 개발자들이 다른 프로젝트로 넘어가게 되면 팀은 그들이 쌓아온 지식과 전문성을 잃게 된다. 팀은 새로운 구성원을 모집해야 할 것이고, 새로운 개발자들은 MSA가 어떻게 작동하는지 배우고 스킬을 쌓아야 한다.

개발 과정 중에 팀원들이 지식을 공유하도록 해야 한다. 페어 프로그래밍(pair programming)과 같은 기법은 팀 구성원들 사이에 지식을 전파하고 ‘특정 서비스에 대해 아는 유일한 사람’을 잃을 위험을 줄이는 효과적인 방법이다. 또한 위키(wiki)와 같이 정보를 기록하고 공유할 수 있는 수단을 제공하고 이를 사용할 것을 권장해야 한다. 마지막으로, 개발자들이 이탈할 위험을 줄이기 위해 개발자들이 직접 참여하도록 하거나, 무엇이 개발자들에게 동기를 부여하는지 알아내거나, 기존에 마이크로서비스 구축을 위해 들인 노력의 틀 안에서 ‘멋진’ 일을 할 기회를 찾아야 한다. 혹은 개발자들에게 더 많은 급여를 지급해 현 프로젝트에 계속 머무를 만한 직접적인 우대 조치를 제공할 수도 있다.

위험: 기술의 변화가 적응을 강제하는 것

MSA를 지원하는 기술과 툴, 프레임워크, 플랫폼 시장은 빠르게 확장 및 진화하고 있다. 이러한 기술은 수백 가지가 있으며, 이 중 다수는 로드맵이나 지원이랄 게 거의 없는 오픈 소스 프로젝트다. 몇몇 주요 업체들은 관련 플랫폼과 서비스, 툴을 제공하고 있으며, 다른 기술들은 마이크로서비스를 더 쉽게 구축하려는 일부 시장을 차지하려는 스타트업들이 지원한다. 이들 툴은 여전히 발전 및 개선되고 있다. 오늘 선택한 기술은 12~18개월 후에는 최적의 또는 최선의 기술이 아닐 수도 있다. 다만 기술과 툴의 성장은 마이크로서비스의 실행을 쉽게 만들겠지만, 해체 결정을 더 단순하게 만들지는 않을 것이다.

서비스 검색, 분산 구성, 혹은 API 게이트웨이 및 메시지/이벤트 기반 통신 등의 중요한 외부 아키텍처 기능을 지원하기 위해서는 마이크로서비스 플랫폼과 선택 사항을 지속적으로 재평가할 준비가 되어있어야 한다. 또한 명확한 로드맵과 유연한 기술을 가진 업체의 기업용 PaaS 제품에 외부 아키텍처의 기반을 둬야 한다. 이러한 제품 중 다수가 사용자의 요구에 부합할 때 다른 소스에서 추가 기능을 도입하는 옵션과 함께 내장형 외부 아키텍처 기능을 기본 제공한다.