마이크로서비스: 확장 가능한 소프트웨어를 신속하게 전달

공유

마이크로서비스란?

마이크로서비스는 단일 용도의 서비스를 지속적으로 우선 제공하기 위해 독립된 팀이 사용하는 아키텍처 접근 방식을 의미합니다. 마이크로서비스 모델은 자주 전달되지 않으며 하나의 단위로서 규모가 정해져 단단하게 통합되는 기존의 모놀리식 소프트웨어의 대척점에 있습니다. 일부 조직과 애플리케이션에서는 모놀리식 접근 방식이 잘 맞기도 하지만 좀더 강화된 민첩성과 확장성이 필요한 기업들 간에는 다른 일부 애플리케이션, 마이크로서비스가 점점 더 인기를 얻고 있습니다.


Microservices Cartoon


왜 마이크로서비스인가?

고객의 요구에 좀더 적극적으로 반응

마이크로서비스 아키텍처를 도입한 기업들은 고객들이 원할 때 고정된 릴리스 일정에 발목잡히지 않고 신속하게 해당 성능들을 전달할 수 있습니다.

더욱 우수한 소프트웨어 팀 처리량

마이크로서비스는 Agile 및 DevOps 원칙 위에 빌드되며 소프트웨어 팀이 특정 성능에 대해 반복 작업하는 동안에도 병렬 실행하도록 돕습니다.

개선된 시스템 확장성과 신뢰성

성공적인 마이크로서비스 아키텍처는 그냥 계속 나아갑니다. 반복 가능한 자동화 시스템에 크게 의존하고 있고, 세심하게 조정된 서비스를 지원하며, 개별 구성 요소가 고장인 상태에서도 시스템은 계속 실행되도록 설계된 패턴을 사용합니다.




마이크로서비스와 Pivotal

Pivotal은 고성능 마이크로서비스 아키텍처를 디자인하고 구현된 마이크로서비스를 실현할 최정상급 환경을 제공합니다.



마이크로서비스 아키텍처 고려 시
염두에 두십시오.

마이크로서비스가 모든 조직이나 애플리케이션에 적합한 것은 아니며, 적절히 구현되지 않으면 높은 비용 부담으로 이어질 수 있습니다. 마이크로서비스를 도입하기 전에 아래 사항들을 고려하십시오.

조직이 준비되어 있습니까?

마이크로서비스 전환은 조직의 전환뿐만 아니라 그에 상당한 기술적 전환이기도 합니다. 팀은 자동화 중심의 지속적인 전달 접근 방식을 받아들여 소프트웨어를 구축할 준비가 되어 있어야 합니다. 귀사는 기능형 사일로를 제거할 준비가 되어 있으며 서비스를 구축하고 운영할 자급자족형 팀이 있습니까? 귀사의 변경 관리 프로세스는 직원의 개입없는 배포 파이프라인을 견딜 수 있습니까?

개발자들이 열성적입니까?

모든 애플리케이션이 마이크로서비스 처리를 보장하지는 않습니다. “무조건 마이크로서비스” 분위기가 만연한 가운데 개발자들은 굳이 변경할 비즈니스 요인이 없는 기존 애플리케이션에 대해서도 상당한 시간을 코드 작성에 투자해야 할지도 모릅니다. 느리게 변화하는 애플리케이션이나 중대한 업무 기능을 수행하는 애플리케이션인 경우 모놀리식 상태를 유지하는 것이 나을 수도 있습니다. 마이크로서비스는 복잡성을 추가하는 대신 민첩성을 높여줍니다. 새로 계약을 맺기 전에 기존의 구성이 더 필요한 것은 아닌지 확인하십시오.

귀사의 서비스는 조화롭게 구성되어 있습니까?

마이크로서비스는 상호 간에 느슨하게 연결되어 있는데다 지속적으로 변경됩니다. 현행 서비스 URL이나 탄력적인 서비스 인스턴스 루트 트래픽을 어떻게 찾으십니까? 서비스는 어떻게 데이터를 교환합니까? 대부분의 경우 서비스 검색, 부하 분산, 메시징을 처리하기 위해 현재 구현되어 있는 기술은 마이크로서비스가 도입하는 역동성에는 참담할 정도로 부적합합니다.

복잡한 환경에 대한 2일차 관리는 어떻게 됩니까?

관리 대상 항목의 수가 늘어나면 운영 위험도 늘어납니다. 수백 또는 수천대의 서버에 그만큼의 마이크로서비스를 생성할 경우 새로운 접근 방식을 취하지 않는다면 틀림없이 관리할 때 난감할 것입니다. 기본 장비들의 패치나 업그레이드는 어떻게 됩니까? 종속성을 추적하고 위험 애플리케이션을 식별할 수 있습니까? 최신 애플리케이션 구성이 적용된 마이크로서비스 인스턴스들을 최신 상태로 유지하는 문제는 어떻게 됩니까? 마이크로서비스 플랫폼 빌드에 사용되는 구성 요소들과 이러한 구성 요소들과 서비스를 실행할 대상은 향후 수년 동안 조직의 민첩성에 크나큰 영향을 미칠 것입니다.



차이점 비교: 마이크로서비스 vs 기존의 아키텍처
마이크로서비스 아키텍처
기존의 아키텍처
단일 목표 집중식. 하나에 집중하되 잘 합니다! 마이크로서비스는 문제가 되는 특정 도메인을 대상으로 하고 데이터를 비롯해 관련 경험이 들어 있는 모든 것을 보유합니다. 마이크로서비스라는 용어에서 “마이크로"는 크기가 아니라 범위를 의미합니다.
광범위한 목표 범위. 단단하게 통합된 소프트웨어 패키지의 솔루션들은 동시에 많은 비즈니스 문제들을 해결하려 합니다.
느슨한 결합. 마이크로서비스 아키텍처는 가능하면 서비스 자급 자족화와 다른 서비스에 대한 하드 코딩 참조를 회피할 것을 요구합니다.
단단한 결합. 흔히 시스템은 주의깊게 구성된 단계별 절차를 따르지 않으면 배포 불가능한 독립적 구성 요소들이 거미줄처럼 엉켜있는 상태입니다.
지속적인 전달. 마이크로서비스는 요구가 지속적으로 변화하는 앱을 다루는 팀에 적합합니다. 최대한 신속하게 시장에 가치를 전달하기 위해 마이크로서비스는 자동화 과정을 거쳐 정기적으로 프로덕션에 전달됩니다.
정해진 일정에 따른 전달. 정해진 일정에 따라 애플리케이션을 개발하고 업데이트합니다. 대체로 분기나 년간 주기에 따라 진행됩니다.
고유한 서비스 수명 주기를 가진 독립팀 보유. 마이크로서비스 변환은 팀 구조뿐만 아니라 기술에도 적용됩니다. 마이크로서비스는 독립적인 팀에 의해 빌드, 전달, 실행됩니다. 모든 서비스에 필요한 것은 아니지만 비즈니스 중심 서비스를 위한 강력한 모델입니다.
다수의 팀에서 서비스 수명 주기 보유. 프로젝트 팀들은 소프트웨어의 최초 버전 구축을 담당하고 다음 프로젝트를 위해 각각 해체됩니다. 소프트웨어 관리는 운영팀으로 이관됩니다.
크기와 무관한 분산형 시스템을 강조하는 디자인 패턴 및 기술 보유 . 모놀리식 소프트웨어를 제작한 것과 동일한 접근 방식과 도구로는 마이크로서비스를 빌드하고 실행할 수 없습니다. 마이크로서비스 아키텍처는 서비스 검색, 메시징, 네트워크 라우팅, 오류 감지, 로깅, 스토리지, 정체성 등의 성능에 따라 달라집니다.
프로세스를 우선 적용하는 디자인 패턴 및 기술 보유. 프로덕션에 대한 핵심 개발 단계, QA, 제품 릴리스에 집중된 사일로형 도구와 프로세스가 모놀리식 소프트웨어를 생산합니다.