Microservice의 등장 배경 (2)

what is cloud native?, Oracle

앞 글에서 소개한 것처럼 2010년대 부터 IT 시스템은 기존의 온프레미스 환경에서 클라우드 환경으로 옮겨지면서 저비용으로 지속적인 확장성과 안정성을 갖출 수 있게 되었음. 하지만 기존의 온프레미스 환경의 시스템을 클라우드 환경으로 옮겨지게 되면서 위와 같이 Anti Fragile의 특성을 갖추는 것이 중요해지게 됨. 이러한 Anti Fragile을 지향한 클라우드 환경에서의 시스템 구조를 Cloud Native Architecture라고 칭하게 됨. 

이번 글에서는 이러한 Cloud Native Architecture에 대해 서술해보겠음.

Cloud Native Architecture의 특징

클라우드 네이티브 아키텍처의 특징을 간략하게 정리하면 아래와 같음.

 

확장 가능한 아키텍처

• 시스템의 수평적 확장이 가능해짐에 따라 저비용으로 더 많은 유저들의 요청을 처리할 수 있게 되었음.
• 이러한 확장된 시스템을 통해 부하를 분산시킴과 동시에 가용성을 보장할 수 있게 됨.
  • 보편적으로 시스템 확장을 의미하는 스케일링은 크게 두 가지로, 시스템의 성능을 높이거나 하드웨어의 성능 업그레이드를 의미하는 스케일 업(scale-up)과 시스템의 부하를 외부로 분산하며 시스템을 다수 배치해 분산 처리하는 것을 스케일 아웃(scale-out)이라 함. 
  • 클라우드 서비스를 제공하는 업체를 통해 가상의 서버, 스토리지, 네트워크 등을 빌려 사용함으로써 하드웨어에 들어가는 비용을 낮출 수 있게 되었음.
  • 예시로 사용자의 요청이 증가하여 시스템의 확장이 필요해지면 클라우드 서비스로 부터 리소스를 일시적으로 추가로 빌려서 사용자 요청 처리 능력을 상승 시키고, 사용자의 요청이 감소하면 빌렸던 리소스를 반납함으로써 기존에 하드웨어적으로 들던 비용을 줄일 수 있게 됐다는 것임.
• 시스템 또는 서비스 애플리케이션 단위의 컨테이너 기반 패키지
  • 클라우드 서비스를 활용하기 위해 가상화 기술이 필수적으로 필요하게 되었음.
  • 컨테이너 가상화의 활용이 도커를 통해 보편적으로 널리 퍼지게 되었으며 이로 인해 리소스가 효율적으로 최적화된 상태의 가상 서버를 클라우드 환경에 배포할 수 있게 됨.
  • 복잡한 과정 없이 필요한 만큼만 리소스를 사용할 수 있게 되어 비용을 줄일 수 있게 됨.
  • 이러한 컨테이너 가상화의 특징이 클라우드 서비스의 확장성과 결합되어 강력한 비용 절감의 시너지를 일으키게 됨.
• 모니터링
  • 클라우드 환경에서 구축된 가상 서버와 리소스들은 다양한 모니터링 도구를 사용해 상태를 추적하고 대비할 수 있음.

 

탄력적 아키텍처

• 하나의 서비스를 이루는 시스템들을 분리해서 관리함. 이렇게 분리된 서비스들은 지속적인 통합-배포 파이프라인을 구축함으로써 비즈니스 환경 변화에 대한 대응 시간을 단축하게 됨.
  
  • 엔터프라이즈 애플리케이션으로 갈수록 다양한 개발 환경, 테스트 환경, 비즈니스에 따른 실제 운영 환경, 예비 서버 등에 대비해야 함. 이러한 환경들은 적게는 3, 4개 부터 많게는 수십, 수백에 이름.
  • 개발자가 일일히 다양한 환경에 대한 테스트, 빌드 및 배포를 수동적으로 수행하게 되면 개발을 수행하는 시간보다 이러한 빌드, 배포 작업에 시간을 더 쓰게 된다는 것임.
  • 이러한 테스트, 빌드, 배포 과정을 자동화하는 작업이 CI/CD 자동화 파이프라인 구축인 것이며 이를 통해 개발자는 비즈니스 환경 변화에 따른 애플리케이션의 확장에만 집중할 수 있게 되는 것임.
• 분할된 서비스 구조를 갖음.
  • 전체 서비스를 구성하고 있는 도메인의 특성에 따라 분리하여 서비스를 개발해야함.
• 무상태 통신 프로토콜를 사용함.
  • 분할된 서비스들은 서로 간 원활한 통신을 위해 종속성을 최소화 시켜야 함. 이에 따라 상태를 갖지 않는 서비스를 제공하도록 노력해야 함.
• 서비스의 추가와 삭제를 자동으로 감지해야 함.
  • 유연한 확장성을 가진 클라우드 환경에서의 애플리케이션들은 자신이 배포될 때, 자신들의 위치가 어디인지 자동으로 등록이 되어야 함.
  • 클라우드 환경에서 새로이 배포되면 매번 새로운 IP를 할당받기 때문에 자신의 위치를 자신과 연결된 다른 서비스들이야 시스템에 공유할 필요가 있다는 것임.
• 변경된 서비스 요청에 따라 사용자 요청 처리(동적 처리)
  • 분리된 서비스가 새로 배포됨에 따라 기존의 사용자 요청도 변경된 서비스 위치에 동적으로 전달되어야 하는 것임.
  • 새로 배포되는 서비스들의 위치를 기억하거나 타 시스템들에게 알려주는 역할을 수행하는 것은 Microservices에서 Service Discovery라고 하는 컴포넌트임. 이는 추후 Microservices를 다룰 때 한 번 더 다루겠음.

장애 격리(Fault Isolation)

• 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 최소화함.
  • 여러 개로 분리되어 개발된 마이크로서비스들은 하나의 독립적인 단위로 개발된 모듈이므로 특정 모듈에서 장애가 일어나게 되더라도 전체 시스템에 끼치는 영향을 최소화할 수 있음.
• 장애복구에 뛰어남.
  • 특정 마이크로서비스에 장애가 발생하면 해당 마이크로서비스에 대한 장애만 복구하면 됨.
  • 하나 고장났다고 전체 시스템을 내렸다 올릴 필요가 없다는 것임.

Cloud Native Application

클라우드 네이티브 아키텍처에 의해 설계되고 구현되는 애플리케이션을 Cloud Native Application이라 부름. 앞서 설명한 Cloud Native Architecture와 Anti Fragile의 특성을 갖기 때문에 아래과 같은 형태로 구현됨.

• 마이크로서비스(Microservices)로 구현됨.
• 구현된 서비스들은 CI/CD 파이프라인을 통해 자동으로 통합되고 빌드, 테스트, 배포가 이루어짐.
• 마이크로서비스에 문제가 발생하면 즉각적으로 수정하여 배포하는 작업을 반복적으로 수행할 수 있는 형태가 되는데, 이러한 특성을 데브옵스(DevOps)라고 부름.
  • 데브옵스는 처음에 시스템이 기획되고 구현되고 테스트되고 배포되는 과정을 시스템이 종료될 때까지 무한 반복하여 고객이 원하는 바를 지속적으로 발전시키는데 목적을 둠.
• 마이크로서비스들을 클라우드 환경에 배포하고 사용하기 위해 컨테이너(Containers)라는 가상화 기술이 활용됨.

 

이제 Cloud Native Application의 특징들을 좀 더 자세하게 살펴보도록 함.

CI/CD

CI/CD는 지속적인 통합(Continuous Intergration)과 지속적인 배포(Continuous Delivery 혹은 Continuous Deployment)라는 의미를 가짐.

• 지속적인 통합 CI(Continuous Intergration)
  • 통합 서버, 소스 관리(SCM), 빌드 도구, 테스트 도구를 의미함.
    
    • 여러 사람들이 함께 작업하고 있는 경우에 결과물을 통합하기 위한 형상관리를 의미할 수 있음.
    • 통합된 코드를 빌드하고 테스트하는 과정 자체를 의미할 수 있음.
  • 대표적인 제품으로 Jenkins, Team CI, Travis CI가 있음.
  • 사용자가 CI 파이프라인을 잘 구성하면, Git과 같은 형상관리 시스템에 commit, push됨과 동시에 빌드, 테스트를 실행해 다른 코드들과 문제가 발생하는지 여부를 바로 확인해볼 수 있음.
• 지속적인 배포
  • 두가지 의미를 내포함, 패키지화된 결과물을 실행되는 환경에 어떠한 형태로 전달하느냐에 따라 갈림.
    • Continuous Delivery(지속적인 전달); 패키지화된 결과물을 관리자의 개입으로 수동으로 실행환경에 전달
    • Continuous Deployment(지속적인 배포); 패키지화된 결과물을 관리자의 개입 없이 자동으로 실행환경에 전달

DevOps

• DevOps는 Development와 Operation이라는 단어가 혼합된 용어임. 개발 조직과 운영 조직의 통합을 의미함.
• 고객의 요구사항을 빠르게 반영하고 만족도 높은 결과물을 제시하는데 목적을둠.
• 기존의 엔터프라이즈 제품들은 짧게는 3개월, 6개월 길게는 1년에서 수년을 걸쳐 새로운 기능들을 릴리즈를 하게 됨.
  • 고객의 요구사항에 맞춰 도메인을 분석하고 시스템을 설계하며 구현, 테스트, 배포 과정을 거쳐야 했고, 개발 조직에 따라 별개의 프로세스나 조직적인 특성으로 인해 필수적인 과정이 추가될 수도 있음.
  • 이러한 과정에 의해 개발 기간이 대체적으로 길었음. 개발 기간이 길다는 것은 언제든 발생할 수 있는 변경사항이나 추가적인 요구사항에 바로 대응하기가 어렵다는 것임.
• 고객의 요구사항은 언제 어디서든 변경될 수 있음.
• 변경사항, 오류사항 등은 기존 개발 방식에서는 시스템 개발 막바지에 추가적인 수정으로 반영되기 일수였음.
• 필요할 때마다 바로바로 수정되고 반영되는 프로세스의 필요성이 대두되었고, 작게 분리된 마이크로서비스(Microservices)에서는 이러한 프로세스가 가능하게 됨.
• 애플리케이션을 수정, 빌드, 테스트, 배포하는 과정이 전체 시스템을 내렸다 올려야 하는 것이 아니라 분리된 서비스들 중 필요한 부분만 진행하면 되기 때문에 가능해진 것임.
• 이러한 사정에 의해 기존보다 사용자의 피드백을 더 자주 반영하며, 더 자주 통합, 더 자주 테스트, 더 자주 배포하는 구조를 이루는 것이 DevOps임.

Container 가상화

CloudSigma AG

컨테이너 가상화는 Cloud Native Application의 가장 큰 특징 중에 하나임. 기존 로컬 환경에서 운영하여야 했던 서비스를 최소의 단위로 가상화하고 운영배포할 수 있게 해준 핵심적인 요소, 이를 이용해 클라우드에 최소한의 리소스를 반영할 수 있게 됐음.

• 컨테이너 가상화 기술은 클라우드 네이티브 아키텍처의 핵심임.
  • 기존에 로컬환경에서 유지하고 운영했어야 했던 환경에서 적은 비용으로 탄력성 있는 시스템을 클라우드에 서비스를 올리고 운영할 수 있게 해준 핵심 기술임.
  • 하드웨어 가상화 또는 서버 가상화에 비해 적은 리소스를 사용하는 특징이 있음.

Why Containerised Deployment, Archana Goyal

• 전통적인 방식의 개발 시스템은 하드웨어 시스템 위에 운영체제를 올리고 애플리케이션을 운영함.
• 다음으로 가상 머신(가상화, Virtualization)은 시스템이 가지고 있는 물리적 하드웨어, 코스트 시스템을 쪼개서 사용하게 되는 개념으로 각각의 가상머신은 독립적인 운영체제를 가지고 실행될 수 있음. 하지만 이 또한 호스트 시스템에 부하를 줄 수가 있고 확장에 한계가 있음.
• 컨테이너 가상화 기술은 운영체제 위에 컨테이너 가상화를 기동하기 위한 소프트웨어 서비스를 기동하게 되고 컨테이너 가상화 내에서 필요한 공통적인 라이브러리나 리소스를 공유하여 사용할 수 있음. 각자 필요한 부분에 대해서만 독립적인 영역에서 실행할 수 있으므로 기존의 하드웨어 가상화 기술보다는 적은 리소스를 사용하며 컨테이너 가상화 위에서 운영되는 서비스들은 가볍고 유연하게 운영할 수 있다는 특징을 가짐.

---

이처럼 Anti Fragile을 지향하는 Cloud Native Architecture에 의해 설계되고 어플리케이션을 Cloud Native Application이라 부름.

 

컨테이너 가상화 기술과 클라우드 서비스의 등장으로 기존의 로컬 환경에서 하드웨어적으로 IT시스템을 구축할 때 발생하던 불편함과 비용 문제를 해소하고 저비용으로 탄력적이고 안정적인 IT 시스템을 구축할 수 있게 됐음.

 

또한, 하드웨어와 네트워크 속도의 발전으로 전체 시스템을 한 덩어리에 뭉쳐놓을 필요가 없게 됐고 작은 단위로 서비스를 분리해도 된다는 점이 부각 됐으며 이렇게 컨테이너 가상화 기술과 클라우드 서비스를 활용한 마이크로서비스(Microservices) 구조가 탄생하게 됨.

 

결과적으로 작은 단위로 서비스들을 각각 독립적으로 관리할 수 있게 되니 고객의 요구사항을 즉각적으로 반영할 수 있게 됨.

 

이렇게 작은 단위로 쪼개진 마이크로서비스를 독립적인 단위로 개발&운영할 수 있게 되어 작업 결과물의 통합과 배포가 자주 발생하게 됐으며 이 작업에 들어가는 비용을 처리하기 위한 CI/CD 자동화 기술이 발전하게 됐음.

 

마지막으로 짧게 한 번 더 정리해 봄. 마이크로서비스는 고객의 피드백을 즉각적으로 반영하기 위해 필요했으며, 이를 가능케 한 건 컨테이너 가상화 기술과 클라우드 서비스의 조합임. 또한, 작은 단위로 찢어진 마이크로서비스들을 통합, 빌드, 테스트, 배포하는데 드는 비용을 최소화하기 위한 기술로 CI/CD가 발전 하였음.

 

이것이 Cloud Native Application의 핵심 구성 4가지인 컨테이너 가상화, 마이크로서비스, DevOps, CI/CD이며 그 중 핵심이 되는 마이크로서비스에 대해서는 다음 포스팅에서 작성하겠음.

 

참조

- Scalable Architectures, Jakob Jenkove, 2014

- What is cloude native?, Oracle

- Why Containerised Deployment, Archana Goyal

---

이전글

2023.11.24 - [Study/etc] - Microservice의 등장 배경 (1)

Microservice의 등장 배경 (1)

다음글

2024.01.02 - [Article] - Microservice의 등장 배경 (3)

Microservice의 등장 배경 (3)