마이크로서비스 및 마이크로서비스 아키텍처
마이크로서비스의 장단점과 모놀리스와 어떻게 다른지 알아보세요.
얼마 전까지 소프트웨어 애플리케이션을 구축하는 데 선호하는 방법은 하나의 자율적 유닛인 모놀리식 아키텍처였습니다. 이 접근 방식은 애플리케이션의 복잡성이 증가할 때까지는 많은 개발자에게 효과적이었습니다. 모놀리식 시스템에서 코드의 작은 부분을 수정하는 경우 전체 시스템을 다시 구축하고 전체 시스템에서 테스트를 실행하며 완전히 새로운 버전의 애플리케이션을 배포해야 합니다.
그 후 소프트웨어 시스템을 자율적으로 개발 및 배포하는 더 작은 유닛으로 나누는 접근 방식인 마이크로서비스가 등장했습니다. 마이크로서비스 아키텍처는 새로운 기능, 버그 수정 및 보안 개선과 같은 업데이트를 자주 제공하려는 DevOps 운동에 의해 전개됩니다. 또한 많은 경우 기업이 최신 프로그래밍 언어를 사용하여 레거시 애플리케이션을 다시 작성하고 기술 스택을 업데이트하는 경로가 되었습니다.
마이크로서비스는 크고 복잡한 애플리케이션을 지속적으로 제공하고 배포하는 소규모 유닛의 모음입니다.
마이크로서비스란 무엇입니까?
간단하게 “마이크로서비스”라고도 하는 마이크로서비스 아키텍처는 분산되고 자율적으로 개발되는 독립적으로 배포 가능한 일련의 서비스로 애플리케이션을 구축하는 접근 방식입니다. 이러한 서비스는 느슨하게 결합되어 있으며, 독립적으로 배포 가능하고 유지 관리가 쉽습니다. 모놀리식 애플리케이션은 나눌 수 없는 단일 유닛으로 구축되는 반면, 마이크로서비스는 단일 유닛을 더 큰 전체에 기여하는 독립적인 유닛 모음으로 나눕니다. 마이크로서비스는 팀이 사용자 요구 사항에 빠르게 적응할 수 있도록 하는 지속적 배포 관행의 기반이기 때문에 DevOps의 필수적인 부분입니다.
마이크로서비스는 도메인 로직의 한 부분을 담당하는 웹 서비스입니다. 여러 마이크로서비스가 결합하여 애플리케이션을 만들며, 각 마이크로서비스는 도메인에 대한 하나의 기능을 제공합니다. 마이크로서비스는 REST 또는 gRPC와 같은 API를 사용하여 서로 상호 작용하지만 다른 서비스의 내부 작동에 대해서는 알지 못합니다. 마이크로서비스 간의 이러한 조화로운 상호 작용이 마이크로서비스 아키텍처입니다.
개발자는 마이크로서비스 아키텍처를 사용하여 다양한 스택과 분리된 배포를 통해 서로 다른 서비스를 전문으로 하는 소규모 팀을 구성할 수 있습니다. 예를 들어 Jira는 여러 마이크로서비스로 구동되며, 각 마이크로서비스는 이슈 검색, 이슈 세부 정보 보기, 댓글, 이슈 전환 등의 특정 기능을 제공합니다.
마이크로서비스의 특징
마이크로서비스 아키텍처에 대한 공식적인 정의는 없지만 알아야 할 몇 가지 일반적인 패턴이나 특징이 있습니다.
자율적인 구성 요소
마이크로서비스 아키텍처의 기본 빌딩 블록은 구성 요소이며, 소프트웨어, 웹 서비스 또는 리소스의 패키지, 애플리케이션 또는 일련의 관련 기능을 포함하는 모듈이 될 수 있습니다. 또는 더 간단하게 Martin Fowler는 "소프트웨어 구성 요소는 독립적으로 교체 및 업그레이드가 가능하다"라고 설명했습니다.
마이크로서비스 아키텍처에서 각 구성 요소는 다른 서비스의 기능이나 애플리케이션의 무결성을 손상시키지 않으면서 개발, 배포, 운영, 변경 및 재배포할 수 있습니다.
구성 요소는 다른 구성 요소와 함께 사용되어 고객 경험 또는 비즈니스 가치를 제공합니다. 가장 일반적인 것은 서비스와 라이브러리로, CLI 도구, 모바일 앱, 프런트 엔드 모듈, 데이터 파이프라인, 머신러닝 모델 및 마이크로서비스 아키텍처 내에서 적용할 수 있는 기타 여러 개념을 캡슐화할 수 있습니다.
깔끔한 인터페이스
개별 구성 요소가 확립된 후에 RPC, HTTP를 통한 REST 또는 이벤트 기반 시스템과 같은 커뮤니케이션 메커니즘을 통해 서로 커뮤니케이션하려면 상당한 양의 로직이 필요합니다. 이러한 메커니즘은 동기식 또는 비동기식일 수 있으며 마이크로서비스는 두 방법의 조합을 사용할 수 있습니다.
가장 중요한 측면은 각 마이크로서비스가 해당 서비스의 소비자가 서비스를 사용할 수 있는 방법을 설명하는 명확하고 직관적인 계약을 제공해야 합니다. 이것은 일반적으로 서비스와 함께 게시된 API를 통해 수행합니다.
직접 구축하고 직접 운영
"직접 구축하고 직접 운영"한다는 DevOps 철학은 팀이 어떻게 구성되어 있는지 고려하지 않고는 아키텍처를 마이크로서비스로 변경할 수 없다는 점을 강조했습니다. DevOps는 개발, QA, 릴리스 엔지니어링, 운영과 같은 기능적 역할 전반에 걸친 인센티브를 고품질 소프트웨어 구축이라는 공통의 목표를 가진 단일 팀으로 다시 정렬합니다. CI/CD, 자동화된 테스트 및 기능 플래그와 같은 DevOps 관행은 배포를 가속화하고 시스템 안정성과 보안을 유지하는 데 도움이 됩니다. 또한 각 팀은 다른 팀에 영향을 주지 않고 자신이 소유한 마이크로서비스를 구축하고 배포할 수 있습니다.
클라우드의 진화로 마이크로서비스의 구축, 배포 및 운영이 간소화되었습니다. 지속적 통합, 지속적 배포, 자동화된 테스트와 같은 인프라 자동화 기술은 팀을 지원합니다.
서비스 지향 아키텍처와 마이크로서비스 비교
서비스 지향 아키텍처(SOA)와 마이크로서비스는 웹 서비스 아키텍처의 두 가지 유형입니다. 마이크로 서비스와 마찬가지로 SOA는 서로 독립적으로 작동하는 다시 사용 가능한 특수 구성 요소로 구성됩니다. 두 아키텍처 유형 간의 차이점은 서비스 유형의 관료적 분류입니다.
SOA에는 다음과 같은 네 가지 기본 서비스 유형이 있습니다.
- Business
- Enterprise
- 애플리케이션
- 인프라 서비스
이러한 유형은 기본 서비스의 관련 도메인별 책임을 정의합니다. 그에 비해 마이크로서비스에는 기능 및 인프라의 두 가지 서비스 유형만 있습니다.
두 개 아키텍처는 모두 엔터프라이즈의 여러 계층에서 동일한 표준 집합을 공유합니다. 마이크로서비스 아키텍처는 SOA 패턴의 성공에 달려 있습니다. 따라서 마이크로서비스 아키텍처 패턴은 SOA의 하위 집합입니다. 여기에서 주요 초점은 각 서비스의 런타임 자율성에 있습니다.
마이크로서비스의 이점
민첩성
작은 독립적인 팀이 일반적으로 마이크로서비스 내에서 서비스를 구축하기 때문에 팀이 애자일 관행을 채택하도록 장려합니다. 팀이 독립적으로 작업하고 빠르게 마이그레이션할 수 있어 개발 사이클 타임이 단축됩니다.
유연한 확장
마이크로서비스는 설계에 따라 분산되고 클러스터에 배포될 수 있으므로 서비스 경계를 넘어 동적인 수평 확장이 가능합니다. 마이크로서비스가 부하 용량에 도달하면 해당 서비스의 새 인스턴스를 포함하는 클러스터에 신속하게 배포하여 부담을 완화할 수 있습니다.
자주 릴리스
마이크로서비스의 주요 장점은 릴리스 주기가 빈번하고 빠르다는 것입니다. 지속적 통합 및 지속적 배포(CI/CD)의 핵심 요소인 마이크로서비스를 통해 팀은 새로운 기능을 실험해 보고 문제가 발생할 경우 롤백할 수 있습니다. 따라서 코드를 보다 쉽게 업데이트하고 새로운 기능의 시장 출시 시간을 단축할 수 있습니다.
기술 유연성
마이크로서비스 아키텍처는 반드시 하나의 도구 체인으로 설정된 접근 방식을 따를 필요는 없지만 팀이 원하는 도구를 자유롭게 선택할 수 있도록 합니다.
품질에 집중
비즈니스 문제를 독립적인 마이크로서비스로 분리한다는 것은 해당 서비스를 소유한 서비스 팀이 완성된 품질 결과물에 집중한다는 것을 의미합니다.
높은 안정성
마이크로서비스는 기능을 분리함으로써 업데이트를 릴리스할 때 전체 애플리케이션 또는 코드 베이스를 손상시킬 위험을 줄입니다. 또한 개별 서비스의 결함과 버그를 쉽게 격리하고 해결할 수 있습니다. 전체 애플리케이션을 중단하지 않고 특정 서비스에 대해서만 변경 사항을 배포할 수 있으므로 안정성이 향상됩니다.
마이크로서비스의 도전 과제
무분별한 개발 확장
모놀리스에서 마이크로서비스로의 마이그레이션은 복잡성이 증가함을 의미합니다. 더 많은 장소에 여러 팀이 만든 더 많은 서비스가 있습니다. 따라서 각기 다른 구성 요소가 서로 어떻게 관련되어 있는지, 특정 구성 요소를 누가 소유하고 있는지, 종속 구성 요소에 부정적인 영향을 미치지 않으려면 어떻게 할지 파악하기가 어렵습니다. 무분별한 개발 확장을 관리하지 않으면 개발 속도가 느려지고 운영 성능이 저하되는 결과가 나타납니다. 시스템이 성장함에 따라 아키텍처의 지속적인 재배포와 빈번한 변경을 관리하려면 숙련된 운영 팀이 필요합니다.
명확한 소유권 부족
마이크로서비스 아키텍처는 누가 무엇을 소유하고 있는지 더욱 혼란스럽게 만듭니다. DevOps 팀은 사용자가 애플리케이션을 배포할 수 있도록 API, 구성 요소 라이브러리, 모니터링 도구 및 Docker 이미지의 조합을 실행할 수 있습니다. 소유자, 리소스 및 다른 구성 요소 간의 진화하는 관계를 포함하여 구성 요소의 정보에 대한 인사이트를 갖는 것이 중요합니다. 관련된 모든 직원이 제품을 이해하는 데 필요한 지식을 쉽게 찾을 수 있도록 여러 팀 간에 정확한 커뮤니케이션과 조정이 필요합니다.
기하급수적인 인프라 비용
프로덕션 배포에 추가되는 각각의 새로운 마이크로서비스에는 테스트 도구, 배포 플레이북, 호스팅 인프라, 모니터링 도구 등에 대한 자체적인 비용이 포함됩니다.
조직 오버헤드 추가
마이크로서비스 아키텍처 팀 간의 업데이트와 인터페이스를 조정하려면 또 다른 커뮤니케이션과 공동 작업이 이루어져야 합니다.
디버깅
각각 고유한 로그 집합이 있는 여러 마이크로서비스를 포함하는 애플리케이션을 디버깅하는 것은 어려울 수 있습니다. 여러 시스템에서 하나의 비즈니스 프로세스를 실행할 수 있으므로 디버깅이 더욱 복잡합니다.
인시던트 대응
마이크로서비스 사용자, 마이크로서비스 배포 위치, 마이크로서비스 배포 방법, 문제 발생 시 연락할 대상과 같은 정보를 포함하는 마이크로서비스 인시던트 대응 인텔리전스를 갖추는 것이 중요합니다.
마이크로서비스 및 DevOps의 관계
마이크로서비스의 복잡성과 종속성이 증가함에 따라 배포, 모니터링 및 수명 주기 자동화에 대한 DevOps 관행은 마이크로서비스 아키텍처에 필수적인 것으로 간주됩니다. 이것이 바로 마이크로서비스가 DevOps 문화를 수용하는 첫 번째 단계로 간주되는 이유이며, 이를 통해 다음과 같은 이점을 얻을 수 있습니다.
- 자동화
- 확장성 향상
- 관리 편의성
- 민첩성
- 더 빠른 제공 및 배포
마이크로서비스 아키텍처를 위한 주요 기술 및 도구
컨테이너, Docker 및 Kubernetes
컨테이너는 단순히 애플리케이션과 모든 종속성을 패키징한 것이므로 쉽고 일관되게 배포할 수 있습니다. 컨테이너에는 자체 운영 체제의 오버헤드가 없기 때문에 기존 가상 머신보다 작고 가볍습니다. 더 빠르게 가동하고 중단할 수 있으므로 마이크로서비스 아키텍처 내에서 발견되는 소규모 서비스에 매우 적합합니다.
서비스와 컨테이너가 확산됨에 따라 대규모 컨테이너 그룹을 오케스트레이션하고 관리하는 것이 필수적입니다. Docker는 개발자가 컨테이너를 구축, 배포 및 실행하도록 지원하는 널리 사용되는 컨테이너화 플랫폼 및 런타임입니다. 그러나 Docker만으로는 대규모 컨테이너를 실행하고 관리하기 어렵습니다. Kubernetes를 비롯해 Docker Swarm, Mesos, HashiCorp Nomad 등과 같은 기타 솔루션은 대규모 컨테이너화 문제를 해결하는 데 도움이 됩니다.
컨테이너화 및 컨테이너 배포는 분산 인프라의 새로운 패턴입니다. Docker와 Kubernetes는 신속하게 배포하고 폐기할 수 있는 완벽한 컨테이너로 서비스를 패키징합니다. 이러한 인프라 도구는 마이크로서비스 아키텍처를 보완합니다. 컨테이너 관리 시스템을 사용하여 마이크로서비스를 컨테이너화하고, 쉽게 배포하고 관리할 수 있습니다.
API 게이트웨이
마이크로서비스 아키텍처의 개별 서비스는 잘 정의된 API를 통해 서로 커뮤니케이션합니다. API 게이트웨이는 API 호출을 수락하고 이를 이행하기 위해 서비스 제공자를 수집하고 결과를 반환함으로써 역방향 프록시 역할을 합니다. API 게이트웨이는 API가 여러 마이크로서비스에서 서비스되는 경우에도 단일 API 엔드포인트를 제공하는 추상적 개념을 제공합니다. API 게이트웨이는 속도 제한, 모니터링, 인증, 권한 부여 및 적절한 마이크로서비스로의 라우팅과 같은 문제를 통합할 수도 있습니다.
메시징 및 이벤트 스트리밍
마이크로서비스의 분산된 특성으로 인해 팀은 상태 변경 및 기타 이벤트를 공유할 수 있는 수단이 필요합니다. 메시징 시스템은 마이크로서비스 간에 커뮤니케이션하므로 일부 마이크로서비스가 기본 인터페이스의 일부로 이벤트를 처리할 수 있습니다. 예를 들어 Confluence 페이지를 변경하면 페이지를 보는 사용자에게 검색 및 알림에 대한 재색인을 트리거하는 이벤트가 발생합니다.
로깅 및 모니터링
마이크로서비스에서는 여러 서비스 중에 문제를 식별하고 해결하기가 어렵습니다. 따라서 로깅, 모니터링 및 추적을 위한 가시성 도구를 갖추는 것이 중요합니다. 이렇게 하면 마이크로서비스의 작동 방식을 이해하고, 잠재적인 문제를 식별하고, 문제를 해결하고, 장애를 디버깅할 수 있습니다.
지속적 통합/지속적 배포
마이크로서비스의 주요 장점은 릴리스 주기가 빈번하고 빠르다는 것입니다. CI/CD의 핵심 요소인 마이크로서비스를 통해 팀은 새로운 기능을 실험해 보고 문제가 발생할 경우 롤백할 수 있습니다. 따라서 코드를 보다 쉽게 업데이트하고 새로운 기능의 시장 출시 시간을 단축할 수 있습니다.
개발자 포털
분산 아키텍처의 복잡성이 증가함에 따라 개발 팀은 엔지니어링 결과물 및 팀 공동 작업에 대한 정보를 한곳에서 통합하는 도구를 활용할 수 있습니다. 예를 들어 Atlassian Compass는 DevOps 도구 체인 전반에 걸쳐 데이터와 인사이트를 제공하므로 팀이 마이크로서비스의 무분별한 확장을 관리할 수 있습니다.
마이크로서비스의 미래
컨테이너화 및 컨테이너 배포는 이제 분산 인프라의 일반적인 패턴입니다. Docker 및 Kubernetes와 같은 도구는 신속하게 배포하고 폐기할 수 있는 완벽한 컨테이너로 서비스를 패키징합니다. 마이크로서비스는 컨테이너 관리 시스템을 사용하여 컨테이너화하고 쉽게 배포하고 관리할 수 있으므로 이러한 새로운 인프라 도구는 마이크로서비스를 보완합니다.
마이크로서비스 채택은 팀의 즉각적인 목표가 아니라 여정이라고 생각해야 합니다.
분산 시스템의 기술적 요구 사항을 이해하고 개별 구성 요소를 확장하려면 소규모로 시작하는 것이 도움이 될 수 있습니다. 그런 다음 경험과 지식을 쌓으면서 점차 더 많은 서비스를 추출할 수 있습니다.
Compass를 사용하여 마이크로서비스 탐색
마이크로서비스 아키텍처로 작업할 때 Atlassian의 Compass는 확장 가능한 분산 아키텍처의 복잡성을 관리합니다. Compass는 엔지니어링 결과물에 대한 단절된 정보와 팀 차원의 공동 작업을 검색 가능한 중앙 위치로 모으는 확장 가능한 개발자 경험 플랫폼입니다. Compass는 컴포넌트 카탈로그를 통해 마이크로서비스의 무분별한 확장을 줄이는 데 도움이 될 뿐만 아니라 성과 기록표를 사용하여 모범 사례를 수립하고 소프트웨어 상태를 측정하며, Atlassian Forge 플랫폼에 구축된 확장 기능을 사용하여 DevOps 도구 체인 전반에 걸쳐 데이터와 인사이트를 제공할 수 있습니다.
