마이크로서비스 아키텍처의 채택
마이크로서비스 아키텍처 기술은 최근 기업의 인프라 영역에서 가장 주목받고 있음이 분명합니다. 그 근거를 뒷받침하는 자료로는, Gartner와 같은 조사 기관의 조사 결과, 대형 기업들의 적 사례 등이 있습니다.
IDC의 '국내 애플리케이션 현대화 서비스 전망, 2022-2026 ‘보고서에서는 국내 애플리케이션 현대화 서비스 시장이 2023년 전년 대비 5.8% 성장하며 3,967 억 원의 규모를 형성하고 2026년까지 연평균 성장률 4.7%를 기록할 것이라고 전망했습니다. 기업들이 디지털 퍼스트 전략을 확대하면서 애플리케이션 현대화가 클라우드 효용성 검증 수단을 넘어 디지털 트랜스포메이션에 필요한 기반 작업이라는 인식이 확대되면서 시장 성장에 기여한 것으로 분석했습니다. 또한 보고서에서는 장기적으로 봤을 때 IT 환경에서 비즈니스 가치 실현화 같은 효용성 확보는 애플리케이션 현대화 서비스 성장의 기반이 될 것으로 보이고 디지털 비즈니스 요구 사항에 맞춘 방법으로 마이크로서비스 아키텍처로의 전환, 클라우드 네이티브 환경 구현, 데브옵스 문화 도입과 같은 움직임이 강조될 것이라고 봤습니다.
마이크로서비스 아키텍처가 필요한 순간
현대 기업의 경쟁력은 새로운 아이디어를 빠르게 제품화하는 동시에 사용자에게 전달하는 역량을 의미합니다. 이에 따라 IT 기업에게는 필요한 곳에 유연하게 자원을 할당하고 현업의 요구를 민첩하게 수용하는 역량이 요구됩니다.
애플리케이션 현대화는 마이크로서비스 아키텍처를 채택해 애플리케이션의 각 구성 요소를 독립적으로 배포하고 확장하며, 신규 애플리케이션과 서비스를 빠르게 생성하고 배포하는 여정을 말합니다. 하지만 모놀리식 아키텍처가 기반이 되는 경우 애플리케이션 내 단일 구성 요소의 로드 혹은 성능 문제를 해결하기 위해서는 전체를 수정해야 하기 때문에 상당한 시간과 비용이 소요됩니다. 또한 작은 변화가 시스템 전체의 안정성에 영향을 미칠 수 있어 문제 발생의 가능성이 커집니다.
아마 배포 후 예상하지 못했던 오류를 경험하거나 테스트의 범위가 넓어 자주 정기 배포를 해야 하는 경우 모놀리식 애플리케이션의 한계를 분명히 체감하고 있을 것입니다. 대형 이벤트가 발생할 때 시스템 장애를 여러 번 겪는 조직 역시 마찬가지입니다. 이럴 때에는 애플리케이션 현대화를 검토해 보는 것이 좋습니다.
MSA 전환을 위한 전략
MSA 전환을 성공적으로 이끌기 위해서는 먼저 기존의 모놀리틱 시스템을 MSA로의 전환을 한 번에 시행할 것인지, 레거시 시스템을 조금씩 점진적으로 MSA로 이행할 것인지 먼저 정해야 합니다. 전자의 경우 규모에 따라 1~2년 정도의 시간이 소요되는데 아키텍처 플랫폼을 한 번에 변경하기 때문에 IT 인프라 전체를 단번에 혁신할 수 있다는 장점이 있습니다. 그러나 충분한 경험과 지식 그리고 준비 없이 진행할 경우 오히려 혼란만 가중될 수 있습니다. 후자의 경우 하나의 애플리케이션을 작은 단위로 쪼개며 진행하기 때문에 속도는 더딘 듯 느껴지지만 아키텍처, 프로세스, 조직 등 내재화를 진행하며 도입할 수 있고 우선순위에 따라 작업할 수 있어 효율적입니다.
MSA 전환이 필요할 때에는 아래와 같은 사항들을 고려해야 합니다.
비즈니스 로직 분해
기존의 모놀리틱 아키텍처를 분석해 비즈니스 로직을 식별하고, 비즈니스 로직을 수행을 위한 각각의 서비스 분리가 필요합니다. 이를 위해서는 철저한 분석과 설계가 필요한데, 한 개의 시스템을 여러 개의 시스템으로 어떻게 분해할 것인지, 서비스 간의 트랜잭션을 어떻게 유지할 것인지, 데이터를 어떻게 조합하여 사용할 것인지를 확인해야 합니다.
서비스 간 통신 방식
서비스 간의 통신 방식은 RESTful API, Message Queue, gRPC 등 다양한 방식이 있는데, 각 방식에 따라 서비스 간의 통신 구조가 달라질 수 있습니다.
모니터링 및 로깅
서비스를 운영하는 동안에는 모니터링과 로깅이 필요합니다. 각 서비스에서 발생하는 로그를 수집, 서비스 상태를 모니터링하여 운영 효율성을 높일 수 있습니다. 따라서 각 서비스들 간의 상태 변화를 어떻게 확인할 것인지에 대한 고민을 해보아야 합니다.
배포 및 확장성
MSA에서는 각각의 서비스가 독립적으로 배포되기 때문에 배포 및 확장성도 고려해야 합니다. 어떻게 서비스들을 배포할 것인지, 자동화 및 확장할 수 있는 방법을 고민해야 합니다.
보안
서비스 간의 통신에서 발생할 수 있는 보안 이슈에 대해 고려해야 합니다. 각각 서비스에 필요한 보안 조치를 취하고 서비스 간의 통신에서 발생하는 보안 위협을 방지할 수 있는 방법, 여러 서비스들 간의 보안을 어떻게 설정할 것인지 고민해야 합니다.
인프라 및 도구 선택
MSA 전환에는 많은 인프라와 도구가 필요합니다. 각각의 서비스를 운영할 알맞은 인프라를 선택하고 서비스 개발 및 배포를 위한 도구를 선택해야 합니다.
테스트 및 검증
MSA 전환 후에는 각각의 서비스가 정상적으로 동작하고, 서비스 간의 통신이 정상적으로 이뤄지는지 검증해야 합니다. 이를 위해서는 테스트 자동화, 검증 프로세스를 설정할 필요가 있습니다.
이 외에도 각 서비스의 인터페이스, API, 데이터 구조 등을 문서화하고 조직 문화 및 역량, 초기 비용 및 투자 계획을 세우는 등의 고려를 하며 MSA의 전환을 성공으로 이끌 수 있습니다.
실제 OpenMSA™ 도입 4단계 (C.A.D.V)
OSC코리아는 기업이 MSA로 전환할 때 경험할 시행착오의 가능성을 최소로 줄이고, 기대했던 효과를 실현할 수 있도록 OpenMSA™를 공급하고 있습니다. OpenMSA™는 오픈소스 기반의 MSA, 컨테이너 운영 플랫폼으로 오픈소스 표준 기술 지원을 통해 벤더 락인을 피하고 안정적인 기능 그리고 SLA 보장을 위한 Enterprise Add-Ons로 구성되어 있습니다. 실제 OpenMSA™가 도입될 때에는 크게 아래의 4단계를 거치게 됩니다.
1단계 MSA 기술 컨설팅 (Consulting)
첫 번째 단계에서는 MSA 도입 적합성을 검토합니다. 기존의 서비스를 9가지 영역에서 분석해 MSA를 도입하는 것이 타당한지 검토하는 것입니다. 즉, 서비스의 현황과 요구사항, 이슈, 향후 방향성을 종합적으로 검토해 MSA 원칙에 부합하는 고도화 방안 및 로드맵을 제시합니다.
2단계 분석/설계 단계 (Analysis and Architecting)
MSA 내/외부 아키텍처의 도출 단계입니다. 1단계의 적합성 검토 결과를 종합해 내부 아키텍처(Inner, Domain Specific)와 표준화할 수 있는 외부 아키텍처(Outer) 영역을 설계합니다. MSA 원칙에 입각해 세분화된 업무 흐름도와 프로세스 정의서 작성을 위한 가이드 및 표준화된 구현 방안을 제시합니다.
3단계 개발/구축 단계 (Development)
마이크로서비스 아키텍처에 따른 개발과정을 지원하고 신기술 및 공통기능을 지원합니다.
4단계 검증/운영 단계 (Verification)
테스트 방법론에 대한 가이드를 비롯하여 성능 및 품질을 검증할 수 있는 방안을 제시합니다.
오늘날 많은 기업에서 MSA 전환을 시도하고 성공한 사례가 들려오지만, 도입 실패 사례도 적지 않습니다. 서비스를 식별하고 개별의 마이크로서비스가 온전하게 독립성을 가질 수 있도록 하는 정교한 설계는 결코 쉽지 않기 때문입니다. 따라서, 기업이 실제로 겪는 어려움을 해결할 수 있는 현실적 해법을 제시하는 솔루션을 선택해야 합니다.
OpenMSA™에 대한 자세한 내용은 아래 링크를 확인해 주세요.
참고
IDC - Korea Application Modernization Services Forecast, 2022-2026
