마이크로서비스 프로젝트를 구현하는 방법(3부)
마이크로서비스 애플리케이션 개발에 관한 이 6부 분량의 시리즈에서는 현재의 요구 사항에 가장 적합하고 장기적인 클라우드 도입 결정을 준비하는 클라우드 기반 파일럿 프로젝트를 정의하는 데 필요한 컨텍스트를 제공합니다.
3부에서는 사용자 고유의 마이크로서비스 프로젝트를 구현하는 방법을 제시합니다.
기존 애플리케이션 발전시키기
이제 다양한 규모의 특정 마이크로서비스 애플리케이션 개발 여정에 대한 방향을 설정하는 방법과 기존 애플리케이션을 어떻게 소규모에서 대규모로 변환할지에 대해 더 자세히 알아보겠습니다.
사전 애플리케이션 없이 마이크로서비스 프로젝트를 구축하는 것이 관련성이 있고 중요하지만, 마이크로서비스를 구축할 때는 "모노리스 우선" 접근 방식에 동의합니다. 간단히 말해서, 이는 먼저 아이디어를 검증하기 위해 가능한 모든 방법으로 애플리케이션을 구축한다는 것을 의미합니다. 그런 다음 이 블로그 시리즈의 원칙을 적용하여 초기 모노리스를 마이크로서비스 프로젝트로 확장하고 발전시킵니다. 비즈니스에 가치를 제공하지 않는 순수한 아키텍처를 갖춘 마이크로서비스를 만드는 것은 아무런 가치가 없습니다.
성공적인 마이크로서비스 프로젝트를 구현하려면 비즈니스, 문화와 스킬 세트, 기술이라는 세 가지 영역을 이해해야 합니다.
비즈니스 요구 사항 이해 및 정의
마이크로서비스로 전환하려는 이유는 무엇인가요? 많은 기업에서는 보다 빠르게 비즈니스에 가치를 제공하고 더 나은 사용자 경험을 제공하기 위해 보다 효율적인 소프트웨어 개발 및 운영 관행이 필요합니다.
마이크로서비스 프로젝트가 기존 애플리케이션과 인프라에 미치는 영향을 이해하기 전에, 만족스러운 결과를 내기에는 너무 느리게 진행되고 있는 비즈니스 부분이 어디인지 파악해야 합니다. 많은 경우, 조직의 참여 시스템(SOE)이 둔화의 원인입니다. 이러한 시스템은 웹, 모바일, API 등 다양한 채널을 통해 제공됩니다. 속도 부족은 마이크로서비스 기반 아키텍처로 전환하는 주된 이유입니다.
마이크로서비스 중심 접근 방식을 채택하기 전에 여러분과 여러분의 비즈니스 이해관계자는 시장에 충분히 빨리 출시되지 않는 것이 무엇인지 알아야 합니다. 애플리케이션의 어느 부분이 더 빠르게 만들기 위해 개선되고 수정되어야 하나요? 해당 질문에 답하려면 기존 모노리스의 어느 부분을 마이크로서비스로 전환해야 하는지 알아야 합니다.
사용자 경험 흐름이나 아키텍처 다이어그램을 사용하여 팀이 히트맵 스타일 주석을 통해 기존 모노리스의 섹션을 빠르게 분리할 수 있도록 돕습니다. 다음은 빨간색-노란색-녹색 척도를 사용하여 문제점의 우선순위를 정한 예인 매장을 위 웹 애플리케이션 아카이브입니다.
이 시점에서 깐깐하지 않고 반복적인 접근 방식을 허용하는 평가의 주요 목표는 다음과 같습니다.
모노리스가 제공하는 별도의 비즈니스 기능 식별
해당 비즈니스 기능을 변경하는 데 필요한 상대적 속도와 복잡성 이해
특정 비즈니스 기능에 대한 더 빠른 피드백 주기를 원하는 비즈니스 소유자의 욕구 이해
조직의 문화와 스킬 세트 이해
마이크로서비스 기반 아키텍처에만 국한되지는 않지만, 조직의 팀, 문화, 기술 세트에 대한 철저한 이해는 성공적인 디지털 혁신에 매우 중요합니다.
일반적으로 엔지니어링 모노리스에서 대부분의 조직은 사일로 내에 구축되어 있으며, 팀은 소프트웨어 개발 라이프사이클 전반에 걸쳐 필요에 따라 참여합니다. 이로 인해 명확한 경계가 생기고, 많은 경우 그 경계를 따라 제한적인 역할과 책임이 생깁니다.
마이크로서비스 아키텍처는 팀이 소프트웨어 개발 및 운영 라이프사이클 전체를 소유할 수 있는 권한을 가질 때에만 성공할 수 있습니다. 모든 역할과 책임을 대표하는 기능 간 팀을 구축하는 것은 마이크로서비스 기반 아키텍처를 구현하는 데 기본이 됩니다. 디자인부터 개발, 운영, 비즈니스 소유자까지 모든 사람이 긴밀히 협력하며 종종 같은 장소에 배치됩니다.
디자인, 개발, 운영 부문의 모든 이해관계자가 팀에 참여하므로, 사용자 경험을 개선하여 비즈니스 목표를 달성하는 데 중점을 두고 업무를 보다 빠르고 효율적으로 진행할 수 있습니다.
또한, 교차 기능 팀은 팀 전체에서 개인 기술이 빠르게 성장할 수 있도록 지원합니다. 팀이 마이크로서비스가 책임지는 모든 것, 즉 설계부터 운영, 런타임 데이터까지 모든 요소를 소유하는 경우, 그 어떤 팀원도 단 하나의 작업도 수행하지 못합니다. 많은 경우 프런트엔드 엔지니어는 종종 데이터베이스 관리 기술을 개발하며, 운영 중심의 팀원은 사용자 인터페이스 프레임워크의 차이점에 대해 자세히 알아봅니다. 이런 식으로 기술 세트를 확장하면 IT 조직 전체가 마이크로서비스를 통해 성공하는 데 도움이 됩니다. 끊임없이 매우 특정한 역할을 채울 전문가를 찾는 대신 모든 면에서 우수한 팀원으로 구성된 새로운 팀을 구성하는 일이 훨씬 쉽기 때문입니다.
기술 이해
비즈니스 문제와 팀의 문화와 기술 세트를 해결하지 않으면 마이크로서비스 기술을 효과적으로 구현할 수 없으며 동일한 프로세스와 구조를 그대로 유지하게 됩니다.
기존 기술 스택에 대한 적절한 분석은 조직마다 크게 다르지만, 여기에서 설명하는 단순화된 접근 방식은 마이크로서비스 프로젝트의 초기 성공과 지속적인 성공을 보장하는 데 도움이 됩니다. 작게 시작해서 반복적이고 점진적인 성공을 정의하는 것은 화려하게 모든 것을 한꺼번에 바꾸는 접근 방식보다 훨씬 더 달성 가능하고 성과가 도출되는 접근 방식입니다.
기술을 이해하는 첫 번째 단계는 기존 모노리스에 있는 대략적인 서비스를 식별하는 것입니다. 이러한 체계적인 서비스를 식별하면 데이터 구조의 복잡성, 현재 구성 요소 간의 결합 수준, 이러한 새로운 체계적인 서비스를 담당하는 팀 등을 이해하는 데 도움이 됩니다. 성공적인 서비스 후기를 통해 특정 서비스의 내부와 여러 서비스 간 데이터 경계를 명확하게 이해할 수 있습니다.
세분화된 서비스를 식별한 후에는 이러한 세분화된 서비스를 세분화된 마이크로서비스로 발전시키는 방법에 대한 계획을 수립해야 합니다. 이전 작업에 기반한 이러한 마이크로서비스는 모두 유사한 데이터로 작업하고, 자체 데이터를 소유하고, 다른 서비스에서 어떤 데이터를 어디에서 읽고 써야 하는지 이해해야 합니다. 여기에서 개별적으로 세분화된 마이크로서비스의 복원성, 확장성, 민첩성을 식별하고 구현할 수 있습니다.
API와 마이크로서비스는 더 큰 전체의 두 부분입니다. 세분화된 마이크로서비스를 더 잘 이해하면 인터페이스도 더 잘 이해하게 됩니다. 즉, 어떤 인터페이스가 중요 경로에 있는지, 어떤 인터페이스가 선택 사항인지, 어떤 인터페이스가 더 이상 필요하지 않은지 알 수 있게 됩니다. 기존 인터페이스나 API를 세분화된 마이크로서비스나 세분화된 마이크로서비스 중 하나에 매핑할 수 없는 경우, 대부분 해당 인터페이스나 API를 없앨 수 있습니다.
마이크로서비스 관련 노력의 규모 조정
비즈니스를 이해하고, 팀 구조를 이해하고, 기술을 이해하는 어려운 작업은 모놀리스가 개념 증명 범위, 파일럿 범위 또는 대규모 진화 범위 중 어디에 있든 팀과 더 큰 조직이 특정 모노리스의 마이크로서비스 진화 전체를 이해할 준비가 되도록 합니다.
모든 분석 및 계획 작업이 완료되면 다음 단계는 일정, 전달 속도, 예상 결과를 정의하는 것입니다.
다음 게시물에서는 마이크로서비스 전환을 수행하는 데 적용할 수 있는 개발 및 운영 패턴을 살펴보겠습니다.
여기에서 수행할 작업:
모놀리식 애플리케이션을 현대화하고 리팩토링하려면 자세한 아키텍처 진행 상황을 참조하세요.
Roland Barcia(IBM 수석 엔지니어/CTO)와 Rick Osowski (선임 기술 직원)가 이 게시물의 작성을 위해 Kyle과 협업했습니다.