◎ 먼저 마이크로서비스가 무엇인가?
■ 마이크로서비스는 아래 5가지의 특징을 갖는 서비스들의 조합으로 이뤄진 설계라고 할 수 있다.
- 유지보수에 유리하고, 테스트 가능해야 함
- 느슨하게 결합되어야 함
- 독립적으로 배포 가능함
- 비즈니스 역량을 중심으로 구성해야 함
- 작은 팀에 의해 소유됨
마이크로서비스를 말할때 아키텍처로 이야기 하는것은 마이크로서비스 또한
하나의 설계 방법이고 비즈니스 로직이 추구하는 방향에 맞추어 선택하는 요소라는 말을 먼저 하고 들어가겠다.
◎ 마이크로서비스와 반대 되는 전략 "모놀리식 아키텍처"
소프트웨어 프로그램의 전통적인 모델로, 자체 포함 방식이며 다른 애플리케이션과 독립적인 통합된 유닛으로 만들어지는 설계 전략이다.
■ 장점
-
손쉬운 배포 : 실행 파일 또는 디렉토리가 하나여서 배포가 더 쉽습니다.
-
개발 : 하나의 코드 베이스로 애플리케이션을 구축하여 개발이 더 쉽습니다.
-
성능 : 중앙 집중식 코드 베이스 및 리포지토리에서는 대부분 하나의 API만으로 마이크로서비스에서 여러 API가 수행하는 것과 동일한 기능을 수행할 수 있습니다.
-
테스트 간소화 : 모놀리식 애플리케이션은 하나의 중앙 집중식 장치이므로 분산된 애플리케이션보다 엔드투엔드 테스트를 더 빠르게 수행할 수 있습니다.
-
간편한 디버깅 : 모든 코드가 한 곳에 있으므로 요청을 따라가서 문제를 찾기가 더 쉽습니다.
■ 단점
-
느린 개발 속도 : 대규모 모놀리식 애플리케이션에서는 개발이 더욱 복잡해지고 속도가 느려집니다.
-
확장성 : 개별 컴포넌트를 확장할 수 없습니다.
-
안정성 : 모듈에 오류가 있으면 애플리케이션 전체의 가용성에 영향을 줄 수 있습니다.
-
기술 채택의 장벽 : 프레임워크 또는 언어를 변경하면 애플리케이션 전체에 영향을 미치므로
변경 시 비용과 시간이 많이 소요되는 경우가 많습니다. -
유연성 부족 : 모놀리스의 경우 모놀리스에서 이미 사용한 기술로 제한됩니다.
-
배포 : 모놀리식 애플리케이션을 약간만 변경하는 경우에도 전체 모놀리스를 다시 배포해야 합니다.
현대의 CI & CD를 통한 빠르고 잦은 배포가 중요해진 개발 흐름에서 모놀리식 아키텍처의 단점은 매우 치명적입니다. 따라서 이를 보완할 수 있는 설계 전략으로써 마이크로서비스가 대두되게 되었습니다. 이는 마이크로서비스의 장단점에서 뚜렷하게 나타나게 됩니다.
◎ 모놀리식의 한계를 극복하기 위한 "마이크로서비스 아키텍처"
마이크로서비스 아키텍처는 독립적으로 배포 가능한 일련의 서비스를 이용하는 아키텍처 방법으로
서비스를 작은 단위 배포하고 이를 정립된 API로 연결하여 운영한다.
업데이트, 테스트, 배포 및 확장은 독립된 각 서비스 내에서 이루어진다.
■ 마이크로서비스의 장점
-
애질리티(Azility) : 배포가 잦은 소규모 팀에서 애자일 작업 방식을 유도한다.
-
유연한 확장 : 마이크로서비스가 부하 용량에 도달하면 해당 서비스의 새 인스턴스를 포함하는 클러스터에 신속하게 배포하여 부담을 완화할 수 있습니다.
또한 여러 인스턴스에 고객이 분산되어 있는 다중 테넌트 및 무상태성(stateless)의 특징을 가진다. -
지속적 배포 : 더 자주 릴리스할 수 있다.
-
높은 유지 관리성 및 테스트 편의성 : 팀에서 새로운 기능을 실험해 보고 문제가 발생하면 롤백할 수 있습니다. 따라서 코드를 보다 쉽게 업데이트하고 새로운 기능의 시장 출시 시간을 단축할 수 있습니다. 또한 개별 서비스의 결함과 버그를 쉽게 격리하고 해결할 수 있습니다.
-
독립적 배포 가능 : 마이크로서비스는 개별적인 유닛이므로 개별 기능을 빠르고 쉽게 독립적으로 배포할 수 있습니다.
-
기술 유연성 : 마이크로서비스 아키텍처를 사용하면 팀에서 원하는 도구를 자유롭게 선택할 수 있습니다.
-
높은 안정성 : 전체 애플리케이션이 중단될 위험 없이 특정 서비스에 대한 변경 사항을 배포할 수 있습니다.
-
팀의 만족도 향상 : 마이크로서비스를 사용하는 Atlassian 팀은 더 자율적이며 풀리퀘스트가 승인될 때까지 몇 주씩 기다리지 않고도 직접 구축 및 배포할 수 있기 때문에 훨씬 더 만족도가 높습니다.
■ 마이크로서비스의 단점
-
무분별한 개발 확산 : 마이크로서비스의 경우 여러 팀이 더 많은 장소에 더 많은 서비스를 만들기 때문에 모놀리스 아키텍처에 비해 더 복잡해집니다. 무분별한 개발 확산이 적절하게 관리되지 않으면 개발 속도가 느려지고 운영 성능이 저하되는 결과가 나타납니다.
-
기하급수적인 인프라 비용 : 각각의 마이크로서비스는 테스트 도구, 배포 플레이북, 호스팅 인프라, 모니터링 도구 등에 대한 자체적인 비용이 발생할 수 있습니다.
-
조직 오버헤드 추가 : 팀에서는 업데이트 및 인터페이스를 조정을 위해 또 다른 커뮤니케이션 작업이 수반되어야 한다.
-
디버깅 문제 : 각 마이크로서비스는 자체적인 로그 집합을 가지고 있어 디버깅이 더 복잡합니다. 또한 여러 시스템에서 하나의 비즈니스 프로세스가 실행될 수 있으므로 디버깅이 더욱 복잡해집니다.
-
표준화 부족 : 공통 플랫폼이 없어 여러 언어, 로깅 표준 및 모니터링이 사용될 수 있습니다.
-
명확한 소유권 부족 : 더 많은 서비스가 도입됨에 따라 서비스를 실행하는 팀의 수도 늘어납니다. 시간이 지나면서 팀에서 어떤 서비스를 활용할 수 있는지, 그리고 지원을 받으려면 누구에게 문의해야 하는지 책임소재가 불명확해진다.
이처럼 마이크로서비스라고 장점만 존재하는 것이 아니다. 비효율적인 운영을 했을때는 오히려 최악의 결과를 초래할 수도 있기 때문에 옳바른 전략 수립과 상황에 맞는 선택이 필요하다.
◎ 마이크로서비스와 자주 함께하는 "서버리스"
서버리스는 말 그대로 서버가 없다는 표현으로 많이들 사용하지만
사실은 서버에 대한 고민을 하지 않는 것이라고 할 수 있다.
사용자가 관리해야하는 영역의 양이라는 관점에서 봤을때
IaaS (Infrastructure as a Service) > Paas (Platform as a Service) > SaaS (Software as a Service)
로 내용을 쉽게 떠올릴 수 있을것이다.
서버리스는 제공 단위가 Function (기능 단위)이므로 FaaS (Function as a Service)로 정의한다.
즉 code의 단위로 클라우드에 업로드하게 되며 run-time환경에 대한 관리를 신경쓰지 않아 전적으로 비지니스 로직에 집중할 수 있게 만들어준다.
마이크로서비스와 함께 사용될때의 서버리스는 Function 단위의 서버리스들을 독립적인 API 형태로 구성하여 배포함으로써 하나의 작은 단위의 마이크로 서비스 형태의 애플리케이션으로 구성한다.
이러한 서버리스의 요소들이 마이크로서비스 개발 구성에 적합한 형태이기에 마이크로서비스 개발 구성을 고려할때 서버리스를 많이들 채택하곤 한다.
하지만 이 또한 취사 선택의 문제이므로 반드시 서버리스를 채택해야 하는 것은 아니다.
■ 서버리스의 장점
-
낮은 비용 :
코드가 실행되고 나면 바로 종료되기에 매우 효율적인 비용 운영이 가능하다. -
간편한 확장성
서버리스 업체가 요청에 따라 확장을 모두 처리한다. 개발자는 코드에만 집중할 수 있다. -
간단한 백엔드 코드
개발자는 FaaS를 사용하여 API 호출 같은 단일 목적을 독립적으로 실행하는 간단한 기능을 만들 수 있습니다. -
시간 단축
서버리스 아키텍처는 시장 진출 시간을 크게 줄일 수 있습니다. 복잡한 배포 프로세스를 이용하여 버그 수정과 새로운 기능을 배포하는 대신 개발자는 필요에 따라 코드를 추가하고 수정할 수 있습니다.
■ 서버리스의 단점
-
콜드 스타트(Cold start)
서버리스 기능을 가상 프라이빗 클라우드에서 구동할 때 발생하는 문제로, 지연이 생기거나 기동 시간이 오래 걸릴 수 있다. 게다가 개발 언어에 따라 지연도 달라진다. 툴을 사용해 지연 시간을 분석해 워크로드에 미칠 영향을 파악할 수 있다. 모든 인프라가 서버리스로 구성되어져 있다면, 툴을 활용해 이를 모니터링 할 필요성이 있다. -
거리 지연
데이터가 그 데이터를 사용하는 핵심 서버리스 기능과는 다른 리전에 있을 때 거리 문제가 생긴다. -
성능이 부족한 런타임 환경 구성
서버리스 시스템은 기본적으로 메모리와 CPU가 모두 적게 할당되기에 성능상의 단점이 있을 수 있다.
이러한 서버리스에 대표적인 AWS 상품들로는 Lamda, ECS등이 있다.
