클라우드 네이티브 아키텍처

과거 IT 시스템에서는 하드웨어가 중심이었기 때문에 시스템을 확장하기 위해서는 추가적인 하드웨어 구매가 필요했고 비용적인 측면에서 부담으로 다가왔다. 그렇기에 소프트웨어 변화가 어려웠고 깨지기 쉬운 시스템이 많이 존재했다.

 

기술의 발전으로 인해 하드웨어의 가격은 안정화되었고 초점을 소프트웨어로 돌리기 시작했다. 이로 따라 안정적이고 성능 높은 서비스를 개발하기 위해 큰 노력을 하게 되었고 시스템 분산화가 등장하게 된다.

 

최근에는 시스템을 로컬 환경에서 운영하는 것이 아닌 클라우드로 이전하게 되었고 탄력적인 시스템을 구축할 수 있게 되었다. 그렇다고 비용이 증가한 것인가? 비용 또한 직접 저렴하게 사용할 수 있다. 이러한 시스템 아키텍처를 클라우드 네이티브 아키텍처라고 한다.

 

앞으로도 지속해서 발전하고 상용화될 클라우드 네이티브 아키텍처에 대해 알아보고자 한다.

Cloud Native Architecture

정의

클라우드 네이티브 아키텍처란 시스템의 빌드, 배포, 운영을 클라우드 환경에서 진행하고 클라우드 컴퓨터 모델을 최대한 활용하는 방식을 의미한다. 대표적인 클라우드 컴퓨팅 기술로는 AWS, Heroku, Naver Cloud Platform 등이 존재한다.

등장 이유

기술이 등장하게 된 가장 큰 이유는 비용에 있다. 다음과 같은 상황을 예로 들 수 있다. 수영복을 파는 사이트는 여름에 사용자가 많은 것이고 평소보다 서버에 많은 트래픽이 발생할 것이다. 이러한 부하에도 평상시와 동일하게 서비스를 제공하기 위해서는 추가적인 자원 할당이 필요하다. 여름에만 증가하는 트래픽을 처리하기 위해서 하드웨어를 구매해야 하는가?

 

이를 위해 등장한 것이 클라우드 네이티브 아키텍처이다. 클라우드 네이티브 아키텍처는 확장에 유연하고 탄력적이기에 이러한 상황을 잘 대처할 수 있다. 시스템이 자동으로 자원의 변화를 감지해서 필요한 만큼 증가시키거나 사용하지 않으면 감소시키는 역할을 한다. 이렇게 된다면 낭비되는 자원도 발생하지 않을 것이고 자원이 추가로 필요한 상황에서도 대처할 수 있는 능력이 생기는 것이다.

특징

확장 가능한 아키텍처

• 애플리케이션(컨테이너) 단위의 패키지로 구성하여 시스템 수평적 확장
• 시스템의 분산 부하를 통해 가용성을 보장
• 가상의 서버, 가상의 스토리지, 가상의 네트워크를 빌려 비용을 최소화
• 실시간적인 모니터링

탄력적 아키텍처

• 분할된 서비스 구조로 각각의 서비스는 생성, 통합, 빌드
• 서비스 추가/삭제를 자동으로 감지하여 환경 변화에 대한 대응 시간을 단축
• 변경된 서비스 요청을 동적으로 처리
• 무상태 통신 프로토콜로 서비스는 독립적인 동작이 가능

장애 격리

• 특정 서비스에 오류가 발생해도 전체 시스템 영향을 주지 않는다.
• 특정 서비스의 독립적인 배포가 가능하기에 가능하다.

Cloud Native Application

정의

클라우드 컴퓨팅 모델의 가장 큰 장점인 민첩성과 확장성을 최대한으로 활용하기 위해 개발된 애플리케이션을 의미한다. 또한 클라우드 환경에서 분산적이고 탄력적으로 동작할 수 있도록 설계되어있다.

특징

마이크로서비스 형태로 개발

마이크로서비스란 소프트웨어가 잘 정의된 API를 통해 통신하는 독립적인 서비스로 구성된 경우를 의미한다. 이러한 마이크로서비스는 전체적인 시스템의 확장을 용이하게 하고 각 서비스의 독립적인 개발이 가능하므로 개발 시간도 단축할 수 있다. 각각은 독립적인 서비스이기에 클라우드 네이티브 아키텍처의 특징인 장애 격리도 가능하고 서비스 역할이 구분되어 있기에 재사용성도 높고 유지보수도 용이하다.

 

이를 가장 잘 활용하고 있는 기업은 넷플릭스이다.

넷플릭스의 전체 구성은 사진에서 확인할 수 있듯 무수히 많은 마이크로서비스들의 결합으로 구성되어있다. 넷플릭스는 마이크로서비스를 도입함으로 서비스 간의 종속성을 낮추고 확장과 변화에 유연하며 다양성을 증가시킬 수 있었다고 한다.

개발된 서비스는 CI/CD를 통해 배포

해석하면 CI(Continuous Integration)는 지속적인 통합을 의미하고 CD(Continuous Deployment)는 지속적인 배포를 의미한다.

 

CI를 통해 빌드/테스트 과정을 자동화하여 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합되므로 여러 명의 개발자가 동시에 작업을 수행할 수 있다. 변경 사항을 정기적으로 커밋하여 모든 사람이 동일 작업을 제공하는 것으로 시작하는데 대표적인 형상 관리 도구로 깃이 존재한다.

 

CD를 통해 배포 단계를 자동화하는 방식을 극한까지 끌어올려 품질 저하없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있다. 신뢰할 수 있는 배포 파이프라인을 구축한다면 하루에도 여러번 릴리즈를 발생시킬 수 있다.

문제가 생길 경우 즉시 수정 후 배포 가능

핵심적인 단어로 나타내자면 DevOps를 의미한다. DevOps란 개발 조직과 운영 조직의 통합을 의미하며 이러한 구성을 작은 단위로 하여 더 많은 통합, 테스트, 배포가 가능하도록 구성해야한다.

클라우드 환경에 배포하고 사용하기 위해서는 컨테이너 가상화 기술 사용

컨테이너 가상화는 클라우드 네이티브 아키텍처의 핵심이라고도 할 수 있다. 컨테이너란 애플리케이션과 애플리케이션 구동 환경을 격리한 공간을 의미한다. 환경을 분리해두었기에 가볍고 서비스 시작 시작도 짧다. 또한 크기도 작기 때문에 컨테이너 복제와 배포에도 용이하다.

출처: https://kubernetes.io/ko/docs/concepts/overview/what-is-kubernetes/

전통적인 배포 방식에서는 애플리케이션을 물리 서버에서 실행했다. 하나의 물리 서버에서 여러 개의 애플리케이션을 실행하게 되었을 때 리소스의 할당 한계를 정의하는 것이 문제가 되었다. 만약 하나의 애플리케이션이 모든 리소스를 차지한다면 다른 애플리케이션은 동작할 수 없거나 성능이 저하되는 결과를 초래한다. 해결하기 위해서는 리소스의 추가가 필요하며 비용적인 부담으로 다가온다.

 

이를 해결하고자 나온 것이 가상화 배포 방식이다. 물리 서버 위 하이퍼바이저 기술을 통해 여러 개의 가상 시스템이 동작하게 된다. 각각의 가상 시스템은 독립적인 운영체제를 가지고 독립적인 애플리케이션을 실행한다. 시스템을 분리함으로 물리적 자원을 나누어 쓸 수 있게 되었다. 하지만 이는 물리적 자원에 많은 부하를 주고 시스템 확장이 어려운 단점이 존재한다.

 

컨테이너 가상화 기술을 사용한 컨테이너 배포 방식이 등장하게 되었다. 가상화 배포와 유사하지만, 애플리케이션과 운영 체제를 분리하게 되었고 애플리케이션 간 운영 체제를 공유하도록 하였다. 이를 통해 공통적인 라이브러리나 리소스는 공유해서 사용할 수 있다. 또한 운영 체제가 분리되었기 때문에 경량화된 컨테이너 관리가 가능하다. 각자 필요한 부분만 독립적인 영역에서 사용되기에 부하가 적고 가볍고 빠르게 운영할 수 있다는 장점이 존재한다.