2.1. 클라우드 컴퓨팅의 발자취
소프트웨어 아키텍처는 그때그때의 기술적 동향에 영향을 받으며, 시대의 필요에 따라 발전하게 된다. 마이크로서비스도 그런 소프트우어 아키텍처 중 하나로 클라우드 컴퓨팅의 영향을 받았다.
2.1.1. REST
2000년대 등장한 웹 2.0의 유행이 가져온 본질적인 가치는 '타인이 제공하는 서비스를 인터넷을 통해 호출하면서 클라이언트 요청을 처리한다'는 것이다. RESTful 웹서비스가 이러한 새로운 모델의 보급에 큰 기여를 했다.
W3C를 중심으로 SOAP/WSDL/UDDI 등 웹서비스 프토로콜이 정비돼 있었다. 하지만 HTTP 프로토콜뿐만 아니라 그 위에서 동작하는 다양한 웹시비스 프로토콜을 이해해야만 했다. 또한, 엔터프라이즈 서비스(ESB) 등 IT 벤더가 제공하는 웹서비스 관련 미들웨어 사용을 강요하는 경우도 적지 않았다. 학습 난이도와 사용 미들웨어 구입 비용이 웹서비스 적용에 장애물이었다.
REST란 아키텍처 스타일로, 주로 HTTP 프로토콜을 사용한 소프트웨어 설계에 대해 논하고 있으며, 그중에서도 HTTP 메서드와 URI (Uniform Resource Identifier)에 대한 언급은 이후 웹 서비스에 큰 영향을 주었다. 이 설계 원칙은 매우 간단하고 이해하기 쉬우며, 전용 미들웨어를 요구하지 않는다. RESTful 웹서비스는 SOAL/WSDL 등의 구시대 웹서비스 프로토콜을 대체하고 SaaS(Software-as-a-Service) 애플리케이션의 API로 사용된다.
2.1.2. 클라우드 서비스 모델
SaaS 회사는 방대한 요청 및 트랜잭션을 축적하고 있어 그 노하우를 적용하면 확정성과 높은 가용성, 안전한 엔드 유저 시스템을 구축할 수 있다고 봤다. 여기서부터 AWS아 Auzre와 같이 서버나 네트워크 등의 컴퓨팅 플랫포을 클라우드 서비스로 제공하는 IaaS(Infrastructure-as-a-Service)가 등장한다. 그리고 이와 관련된 서버나 네트워크 가상화 기술, 서버 구성 및 배포 자동화 기술이 새록게 개발, 추가됐으며, 인프라 구축의 속도 및 품질 향상을 도모할 수 있었다.
클라우드 컴퓨팅을 활용한 인프라 기술 혁신은 상위 계층에도 영향을 주었고, 그 중 하나가 PaaS(Platform-as-a-Service)이다.
IaaS는 서버, 스토리지, 네트워크 등 인프라 자원을 가상화하여 제공하는 반면, PaaS는 운영체제, 미들웨어, 런타임 환경까지 포함된 플랫폼을 서비스로 제공한다. 이를 통해 애플리케이션 개발자는 인프라 구성이나 운영체제 설정 없이 개발에만 집중할 수 있다.
대표적인 PaaS로는 Google App Engine, AWS Elastic Beanstalk, Microsoft Azure App Service 등이 있다.
또한, 애플리케이션 개발/운영의 속도 향상과 유연성을 실현하기 위해 CI/CD, 데비옵스, 애자일 개발 프로세스와 같이 클라우드 컴퓨팅과 직접적인 관련이 없었던 기법들이 클라우드 커퓨팅을 형성하는 방법으로 자리잡았다.
마이크로서비스는 클라우드 플랫폼상에서 실행되는 애플리케이션을 개발 및 운영하기 위한 아키텍처 스타일로 주목받게 됐다. 마이크로서비스란, 인프라 구축의 빠른 속도에 맞추어 애플리케이션 개발과 운영(변경작업)을 적시에 진행하기 위한 설계, 개발, 운영 기법을 모은 것이다. 여기서 핵심이 되는 것은 서비스라고 하는 독립적으로 개발 및 실행되는 소프트웨어 컴포넌트를 여러 개 조합해서 하나의 애플리케이션으로 만드는 소프트웨어 구조에 있다. 각 서비스는 개별적으로 개발되며, 각각 독립적으로 특정 환경에 배포할 수 있는 구조를 가지고 있다. 개별 서비슬르 교체하므로 애플리케이션을 간단히 변경할 수 있는 구조다.
클라우드는 인프라를 신속하게 구축하고 똑똑하게 운영하는 것 뿐만 아니라, 클라우드 기반에 맞는 애플리케이션을 만들어서 빠르고 유연하게 시스템을 구축, 운영할 수 있게 해준다. 이런 클라우드를 전제로 설계, 구축, 개발, 운영하는 컴퓨팅 스타일을 클라우드 네이티브 컴퓨팅이라고 한다.
2.3. 클라우드 네이티브 컴퓨팅을 지탱하는 기술 요소
클라우드 네이티브 컴퓨팅에는 다양한 기술 분야가 있지만 저자가 중요시하는 것은 컨테이너화(Containerization), 오케스트레이션과 어플리케이션 정의(Orchestration & Application Definition), 마이크로서비스, 그리고 데브옵스(CI/CD)다.
컨테이너와 오케스트레이션은 인프라 혁신의 중심이고, 마이크로서비스는 애플리케이션 혁신의 중심이다. 초기 클라우드 네이티브를 구성하는 세가지 기술 요소에 추가로 데브옵스를 중요시하는 이유는 두가지다. 첫 번째는 애플리케이션 개발/운영을 신속하게 하려면 개발/운영 기법을 개선해야 하기 때문이다. 또한, 데브옵스는 클라우드 네이티브 컴퓨팅뿐만 아니라 기존 시스템이나 애플리케이션 개발에도 유용하다.
2.3.1. 컨테이너
컨테이너는 서버 가상화를 실현해주는 소프트웨어 솔루션이다. 컨테이너의 특징은 리눅스 커널 기능을 이용해서 OS 수준의 가상 환경을 실현했다는 것이다. 한편 컨테이너 등장 이전에 폭넓게 사용됐던 하이퍼바이저형 가상화는 하드웨어 수준에서 가상 환경을 실현했다. 즉, 하나의 하드웨어상에 여러 가상 환경을 호스팅하는 것이다. 하이퍼바이저형 가상화에서는 가상 환경이 각각 별도의 OS 이미지를 가지고 있지만, 컨테이너형에서는 가상 환경이 각각 OS 이미지를 사용하는 것이 아니라 하나의 OS를 공유한다. 이런 차이가 가상 환경 이미지의 크기에도 영향을 준다. 컨테이너형에서는 각 가상 환경 이미지(컨테이너 이미지)가 OS를 지니지 않아도 되므로 가상 환경 배포나 실행이 빠르다는 장점이 있다. 또한, 컨테이너는 오픈소스로 릴리스되어 있고, 사양도 표준화되어 있어서 대표적인 클라우드 벤더들이 모두 컨테이너 기술을 지원한다. 컨테이너형 가상화에서는 컨테이너화된 애플리케이션을 다른 곳에 이식하기도 쉬워서(이동성이 높음) 비용 투자 관점에서도 장점이 있다.
2.3.2. 컨테이너 오케스트레이션
프로덕션 시스템을 운영함에 있어서 보통은 가용성과 확장성을 담보하기 위해서 여러 개의 애플리케이션 서버로 구성된 클러스터를 구축한다. 클라우드 네이티브 컴퓨팅에서 컨테이너는 마이크로서비스의 각 실행 환경으로 이용된다. 마이크로서비스 스타일의 설계를 한 경우 하나의 애플리케이션을 여러 개의 컨테이너를 사용해 구성한다. 기존 아키텍처에 비해 클라우드 네이티브에서 관리해야 할 클러스터 멤버(컨테이너) 수가 훨씬 더 늘어나는 것이다. 이 컨테이너들을 일일이 명령어를 입력해서 구성, 관리하는 것은 현실적이지 않으며, 이 때 필요한 것이 바로 컨테이너 오케스트레이션이다.
컨테이너 오케스트레이션은 컨테이너 클러스터 관리 및 운영을 중심으로, 컨테이너 클러스터 배포, 이름 해결(name resolution), 라우팅(routing), 서비스 검색(service discovery), 부하분산(load balance), 확장(scalability), 장애 시 자가 복구(self-healing) 등의 기능을 제공한다. 즉 인프라 운영 기능을 제공하고, 컨테이너 애플리케이션의 생명 주기를 관리하는 것이 컨테이너 오케스트레이션의 역할이다.
2.3.4. 클라우드 네이티브 컴퓨팅을 진행하는 이유
클라우드 네이티브 컴퓨팅의 핵심 기술로 컨테이너, 오케스트레이션, 마이크로서비스, 데브옵스를 추천하는 이유는 아래와 같다.
- IT 시스템 개발/운영 속도 향상 및 품질 향상
- 인프라와 애플리케이션 배포 자동화
- 빠른 개발 및 테스트
- 조작 실수 최소화로 품질 향상
- 이미 릴리스한 시스템도 적절한 타이밍에 유연하게 변경 가능
- 인프라와 애플리케이션 배포 자동화
- 확장성과 고가용성
- 오케스트레이션 프레임워크를 활용하면 컨테이너 애플리케이션의 클러스터 손쉽게 작성, 관리 가능
- 퍼블릭 클라우드와 온프레미스를 같이 사용하는 하이브리드 클라우드 환경 구축 가능
- 부하분산, 확장, 자가 복구 등의 기능을 사용해서 프로덕션 운영에 필요한 확장성과 고가용성 실현
- 비용 절감
- 컨테이너나 오케스트레이션 프레임워크는 클라우드 제품이 지원하는 기술로, 컨테이너 애플리케이션을 한 번 만들어 두면, 최소한의 수정으로 다른 클라우드 서비스가 제공하는 플랫폼으로 쉽게 마이그레이션 가능
- 여러 클라우드 서비스 플랫폼을 함께 사용하는 멀티 클라우드 환경 비교적 쉽게 구축
2.4. 마이크로서비스란?
마이크로서비스란, 클라우드 네이티브 컴퓨팅의 핵심이 되는 기술로 클라우드 기반에 특화된 애플리케이션, 즉, '클라우드 네이티브 애플리케이션' 개발/운영 아키텍처 스타일이다.
2.4.1. 마이크로 서비스 아키텍처
마이크로서비스 아키텍처의 핵심은 독립적으로 개발 및 실행되는 소프트웨서 컴포넌트(서비스)를 여러 개 조합해서 하나의 애플리케이션을 구축하는 소프트웨어 구조에 있다. 이것을 구체화하기 위한 기술로 컨테이너, 오케스트레이션, REST, 메시징 등이 있으며, 기법으로는 데브옵스, 애자일 개발 프로세스, CD, DDD가 있다.
- 마이크로서비스 장점
- 전체를 한번에 릴리스하는 빅뱅형 기법이 아니라, 일부를 단계적으로 릴리스 및 변경하게 하는 유연성을 가져다준다.
- 특정 서비스만 확장/축소할 수 있어 시스템 리소스 최적 사용 및 가동률 개선
- 서킷브레이커와 조합하면 장애 영향 범위 국소화할 수 있다.
- CD를 사용한 잦은 빈도의 배포에 적합
- 마이크로서비스 운영시 고려 사항
- 서비스 간 통신 발생 가능성이 있어, 성능에 영향을 준다. (서비스 간 통신 지연)
- 데이터도 분산 배치되므로 DB간 일관성이나 동기화 기법, 운영 및 감시 구조를 정비해야 한다.
- 서비스 모델링 기법의 학습 난이도와 각 서비스를 포함한 시스템 전체 설계의 일관성도 고려해야 한다.
이런 어려움이 있는데도 불구하고 마이크로서비스를 적용하는 이유는 무엇일까? 가장 큰 이유는 유연한 모듈 구조(소비스)로 애플리케이션의 개별 유지/부수를 실현할 수 있다는 것이다. 신속하게 시스템을 릴리스할 수 있는 속도와 적시에 시스템을 변경 및 운영할 수 있는 유연성이 필요하다. 이런 요구에 부응할 수 있는 기반 기술이 컨테이너이며, 애플리케이션의 경우 마이크로서비스다.
2.5. 마이크로서비스의 특징
- 서비스를 사용한 컴포넌트화
- 비즈니스 기능을 기준으로 한 팀 편성
- 프로젝트가 아닌 제품을 파악해서 개발 및 운영
- 지능적인 엔드포인트와 단순한 파이프
- 비중앙집권적인 언어와 툴 선택
- 비중앙집권적인 데이터 관리
- 인프라의 자동화
- 장애와 오류를 전제로 한 설계
- 선진적인 설계
[참고자료]
그림으로 공부하는 마이크로서비스 구조 (https://product.kyobobook.co.kr/detail/S000061532860)
'프로그래밍_도서 > 그림으로_공부하는_마이크로_서비스_구조' 카테고리의 다른 글
| 3. 마이크로서비스 아키텍처의 기본 (1) | 2025.07.09 |
|---|