클라우드 네이티브란?
[Column] 클라우드 네이티브란?
by Column 2021-02-08클라우드 컴퓨팅을 도입하는 것이 시기상조라고 여겨질 때가 있었습니다. 그때에는 클라우드를 왜 사용해야 하는지, 클라우드의 장점과 필요성에대해 초점을 맞췄다면, 이제는
cloudmt.co.kr
클라우드 네이티브를 위한 주요 4가지 요소
- DevOps 애플리케이션 개발-운영 간의 협업 프로세스를 자동화하는 것을 말하며 결과적으로 애플리케이션의 개발과 개선 속도를 빠르게 합니다.
- CI/CD 지속적인 통합(Continous Intergration)은 개발자가 작업한 코드를 자동으로 테스트하고 테스트에 통과하면 코드를 통합하여 저장합니다. 지속적인 배포(Continuos Deployment)는 작업한 코드 및 변경사항들은 테스트를 거쳐 리포지토리에 업로드되고 실 서비스 배포로 릴리즈까지 자동화하는 것을 말합니다.
- 컨테이너 기반 인프라 가상화 기술 중 하나로, 시스템을 가상화하는 것이 아니라 애플리케이션을 구동할 수 있는 컴퓨팅 작업을 패키징하여 가상화한 것입니다.
- Microservice 애플리케이션을 구성하는 서비스들을 독립적인 작은 단위로 분해하여 구축하고 각 구성 요소들을 네트워크로 통신하는 아키텍처로 서비스 안정성과 확장성(scaling)을 지원합니다.
[컨테이너]
IT 기술의 컨테이너도 물류 분야의 컨테이너처럼 이동성을 실현하기 위한 기술입니다. 즉, 어느 환경이나 어느 인프라로든 쉽게 이동할 수 있다는 말인데요, 컨테이너는 애플리케이션을 실행하기 위한 컴퓨팅 작업을 패키징하여 이미지로 만들기 때문에 경량화되어있고, 서버나 OS 환경에 종속적이지 않아 진정한 애플리케이션 이식성이 실현됩니다.
이해를 돕기 위해 컨테이너와 대조되는 하이퍼바이저 기반의 가상화와 비교해보겠습니다.

하이퍼바이저 기반의 가상화(VM 방식)는 애플리케이션이 돌아갈 수 있는 OS 환경이 포함됩니다. 그렇기 때문에 애플리케이션을 실행하기 위해서는 VM을 띄워 자원을 할당한 다음, OS를 부팅한 후 애플리케이션을 구동할 수 있기 때문에 시간이 오래 걸립니다.
반면, 컨테이너 기반의 가상화 방식은 프로세스 간 벽을 만들어 애플리케이션이 구동되는 환경이 격리(컨테이너화)되어 있기 때문에 각 각의 APP에 OS를 개별로 구성해줄 필요 없이 하나의 OS 커널*을 공유하여 사용합니다. OS가 필요하지 않음으로 더 가볍고 크기도 작아 복제와 배포에도 간편합니다
따라서, 애플리케이션을 구동하기 위해서 OS가 필요하지 않아 가볍고, 애플리케이션 실행에 필요한 모든 것(라이브러리, 바이너리, 기타 구성 파일 등)을 패키지로 묶어 컨테이너 이미지를 만들어 사용하기 때문에 컨테이너가 작동하는 환경이라면 어디서든지 실행시킬 수 있다는 장점이 있습니다.
*커널이란? : 운영 체제의 핵심으로 하드웨어의 자원(CPU, Memory, Devices)을 각 프로세스에 사용할 수 있도록 나눠주고, 프로세스 및 메모리 제어 등 시스템의 모든 것을 통제합니다.
특징을 정리해 보면,
- 경량화 – 앱 구동을 위해 게스트 OS가 포함되지 않습니다.
- 효율성 – 호스트 OS 커널을 공유하므로, 자원을 미리 할당하지 않고 애플리케이션 동작에 필요한 컴퓨팅 자원만 필요로 합니다.
- 이식성 – 컨테이너가 작동하는 환경이라면 어디든지 작동시킬 수 있습니다.
- 안정성 – 호스트 OS 커널을 공유하는 구조로 장애 발생 시, 다른 컨테이너들이 영향을 받을 수 있습니다.
[마이크로서비스]
마이크로서비스 아키텍처는 애플리케이션을 이루는 서비스들을 기능 단위로 쪼개서 구축하는 것을 말합니다. 서비스끼리는 프로그래밍 언어에 구속받지 않는 API(Application Programming Interface)를 통해서 통신하며 각 서비스는 각각 자체 DB를 가지게 됩니다.
모놀리식 아키텍처와 비교해 본다면,

monolithic-vs-microservices <그림 참고 : Red Hat Site>
모놀리식은 전체 애플리케이션이 하나의 통합된 패키지 형태로 구성되어 있고 구성 모듈들이 의존적으로 연결되어 있기 때문에 기능 하나를 변경하려면 전체 애플리케이션을 재배포해야 하는 번거로움이 있습니다. 같은 이유로 특정 모듈만 확장하기가 어렵고 애플리케이션을 담고 있는 서버 자체를 늘려야 하는 비효율적 구조입니다. 또한, 개발 초기에 사용한 기술 스택에 고정되어 사용 해야 한다는 제약이 있습니다.
반면, 마이크로서비스 아키텍처는 애플리케이션을 작은 기능으로 나누어 구축하기 때문에 개별 서비스들을 더 쉽게 변경하거나 확장할 수 있으며, 서비스마다 다른 언어, 프레임워크, 라이브러리를 사용할 수 있다는 장점이 있습니다. 하지만, 모놀리식 보다는 구조가 복잡하고 여러 서비스에 데이터가 분산되어 있어 데이터 관리가 어렵다는 단점이 있습니다.
특징을 정리해 보면,
- 확장성 – 전체 애플리케이션을 담고 있는 서버를 추가하거나 사양을 늘리는 것이 아니라, 리소스를 더 필요로 하는 모듈만 수평, 수직적으로 쉽게 확장할 수 있습니다.
- 생산성 – 개발자는 해당 기능(서비스)에만 집중하여 개발할 수 있으며 테스트/배포에 걸리는 시간도 줄일 수 있어 생산성을 높일 수 있습니다.
- 안정성 – 모놀리식 구조에서는 하나의 장애가 전체 애플리케이션에 영향을 줄 수 있으며 찾아내기도 어렵습니다. 반면 서비스들이 분리된 독립적인 구조에서는 장애를 그 서비스에 한정적으로 격리할 수 있습니다.
- 복잡성 – 여러 서비스가 분산되어 얽혀 있기 때문에 복잡성이 높으며, 분산시스템을 어떻게 구성할 것인지에 대한 어려움이 있습니다.
- 수평 확장(Scale Out) : 서버 대수를 늘림
- 수직 확장(Scale Up) : 서버 사양을 늘림
[DevOps와 CI/CD]
DevOps는 ‘개발과 IT 운영 간의 프로세스를 통합하여 궁극적으로는 고객에게 뛰어난 품질의 서비스를 빠르게 제공한다’는 개발 방법론입니다. 그렇다면 개발(Dev)과 운영(Ops)의 업무는 다른데 왜 통합하려고 하는가? 인데요,
과거 새로운 서비스를 출시하기 위해서 오랜 기간 작업 후 배포했던 것과 달리, 현재는 서비스 출시 속도가 빠르고 업데이트 주기 또한 빈번해졌습니다. 그렇기 때문에 개발된 소프트웨어가 시스템의 안정성을 유지하면서 사용자에게 빠르게 제공될 수 있도록 [개발-테스트-배포-운영]의 업무 사이클을 자동화된 단일 워크플로우로 통합할 필요성이 생긴 것입니다.
DevOps를 하려면,
• 소스 코드 제어(SCM, Source Code Management)
서비스는 보통 팀 단위로 개발되는데, 서로 다른 팀에서 개발한 코드에 대한 버전과 이력을 관리해야 합니다.
• CI/CD
CI/CD는 위에서 설명한 것 같이 지속적인 통합과 배포를 통해 애플리케이션 개발 단계를 자동화하여 고객에게 보다 짧은 주기로 서비스를 제공하고 개선하는 방법입니다.
• 모니터링
업데이트 빈도가 늘어남에 따라 일반적으로 요구되는 엄격한 테스트를 매번 수행할 수가 없습니다. 따라서, 데브옵스 환경에서는 실시간으로 앱 및 성능 모니터링을 통하여 오류, 개선사항을 찾아 해결하는 것이 중요합니다.
• 문화
지난 컬럼에서도 이야기한 바와 같이 DevOps는 개발과 운영 방식을 너머 사일로(silo, 부서 이기주의)를 없앤 ‘협업 문화’라고 볼 수 있습니다. <참고 : DevOps를 하려면 무엇부터 해야 할까?>
[Column] DevOps를 하려면 무엇부터 해야 할까? – CLOUDMATE (cloudmt.co.kr)
[Column] DevOps를 하려면 무엇부터 해야 할까?
by Column 2020-09-05‘데브옵스(DevOps)를 도입한 조직은 개발과 운영 업무를 통합하여 개발 주기를 앞당기고, 고객 서비스의 품질을 높인다’는 이야기를 어디서 한 번쯤 들어보았을 것이다. 이름만
cloudmt.co.kr