비유로 배우는 클라우드 네이티브 핵심 용어

현대 IT 환경의 핵심 키워드, 바로 '클라우드 네이티브'입니다.

하지만 MSA, 컨테이너, 서비스메시, API Gateway, Immutable Infrastructure 등 생소한 용어들 때문에 클라우드 네이티브의 문턱이 높게 느껴질 수 있습니다. 걱정하지 마세요! 이 글에서는 복잡하고 어렵게만 느껴지는 클라우드 네이티브의 핵심 개념들을 우리에게 친숙한 비유를 통해 쉽고 재미있게 풀어드릴 예정입니다. 마치 맛있는 요리를 배우듯, 지금부터 클라우드 네이티브라는 흥미로운 여정을 함께 시작해 봅시다!

온프레미스 vs. 클라우드

기업에서 물리 서버를 직접 관리하던 온프레미스 시대에서 벗어나, AWS, Azure, GCP와 같은 클라우드 서비스 제공업체(CSP)의 유연한 인프라를 임대하여 사용하는 클라우드 시대로 전환되었습니다.

• 온프레미스 (On-premise)
  • '내 소유의 식당 건물'과 같습니다. 건물(서버)을 직접 짓고, 주방 설비(소프트웨어)를 구매하며, 전기 및 수도(네트워크, 전기)까지 모든 것을 직접 관리해야 합니다. 초기 비용이 많이 들고 확장이 어렵지만, 모든 것을 내 마음대로 제어할 수 있습니다.
• 클라우드 (Cloud)
  • '공유 주방(키친 인큐베이터) 입점'과 같습니다. 이미 모든 주방 설비와 인프라가 갖춰진 공간을 필요한 만큼 빌려 쓰는 것입니다. 손님이 몰리면 더 넓은 공간을 빌리고, 손님이 적으면 공간을 줄이며 비용을 효율적으로 관리할 수 있습니다.

모놀리식 (Monolithic)  vs. 마이크로서비스 (MSA)

• 모놀리식 (Monolithic)
  • '한 명의 셰프가 모든 요리를 다 하는 거대한 식당'입니다. 한식, 중식, 양식을 한 주방에서 모두 만듭니다. 주방의 한 코너(기능)에 문제가 생기면 식당 전체가 마비될 수 있고, 새로운 메뉴(기능 추가)를 개발하기도 매우 복잡합니다.
• 마이크로서비스 (MSA)
  • '푸드코트(Food Court)'와 같습니다. 파스타 가게, 초밥 가게, 햄버거 가게가 각자 독립된 주방(서비스)을 가지고 운영됩니다. 파스타 가게에 문제가 생겨도 다른 가게들은 정상적으로 영업할 수 있으며, 새로운 가게를 입점시키기도 훨씬 쉽습니다.

MSA 컴포넌트: 서비스 메시 & API 게이트웨이

서비스 메시와 API 게이트웨이는 언뜻 보면 비슷해 보이지만, API 게이트웨이는 '외부'에서 '내부'로 들어오는 요청을 관리하는 '대문'이고, 서비스 메시는 '내부' 서비스들끼리 통신하는 것을 관리하는 '신호등'입니다.

• 서비스 메시 (Service Mesh)
  • '푸드코트 내부의 총괄 매니저'와 같습니다. 파스타 가게가 샐러드 가게로부터 바질을 받아야 할 때, 이 통신 시스템을 통해 요청합니다(서비스 탐색). 만약 샐러드 가게의 재료가 갑자기 떨어져 응답이 없으면, 총괄 매니저가 이를 파악하고 다른 가게에 영향을 주지 않도록 잠시 주문을 막습니다(서킷 브레이커). 모든 가게 간의 재료 요청은 안전하게 전달됩니다(보안).
  • 대표적인 서비스메시로는 Istio가 있습니다.
• API 게이트웨이 (API Gateway)
  • '푸드코트의 정문 안내 데스크'와 같습니다.
    손님(외부 클라이언트)은 푸드코트에 들어와 안내 데스크에 "파스타 주세요"라고 주문합니다. 그러면 안내 데스크 직원이 주문을 받아), 결제가 유효한지 확인하고(인증), 파스타 가게로 주문을 정확히 전달해 줍니다(라우팅). 손님은 파스타 가게가 어디에 있는지 알 필요가 없습니다.

가상머신(VM; Virtual Machine)과 컨테이너(Container)

• 가상머신(VM; Virtual Machine)
  • 하이퍼바이저라는 땅 위에 각자 고유한 기반 시설(수도, 전기, 가스관)을 갖춘 여러 채의 단독 주택을 짓는 것과 같습니다.
  • 여기서 하이퍼바이저는 한 대의 물리적인 컴퓨터(호스트) 위에 여러 대의 독립적인 가상 컴퓨터(가상 머신, VM)를 생성하고 관리하는 소프트웨어입니다. 각 VM은 독립적인 운영체제(OS)와 필요한 모든 자원(CPU, 메모리, 저장공간)을 가집니다.
• 컨테이너 (Container)
  • '한 아파트 건물(호스트 OS) 안에 여러 개의 규격화된 주방(컨테이너)을 만드는 것'과 같습니다. 모든 주방은 건물의 공용 수도, 전기, 가스(호스트 OS 커널)를 함께 사용하지만, 각 주방 안에는 자신만의 요리 도구와 재료(애플리케이션과 종속성)가 완벽하게 준비되어 있습니다.
  • 컨테이너는 VM과 달리 호스트 컴퓨터의 운영체제(OS) 커널을 공유합니다. 이 때문에 매우 가볍고, 몇 초 만에 수많은 컨테이너를 실행할 수 있어 효율성이 극대화됩니다.

코드로서의 인프라 (IaC)

• IaC(Infrastructure as Code)는 '주방 설비와 배치를 완벽히 기록한 레시피 북'과 같습니다.
• 어떤 화구를 쓰고, 오븐은 어디에 둘지 등 모든 인프라 구성(서버, 네트워크, 데이터베이스)을 사람이 직접 수동으로 설정하는 대신, 코드를 통해 정의하고 관리하는 방식입니다. 이 '레시피 북'만 있으면 언제 어디서든 클릭 몇 번으로 동일한 구조의 주방(인프라)을 오차 없이, 순식간에 차릴 수 있습니다. 이를 통해 일관성을 유지하고 휴먼 에러를 방지하며 빠른 배포를 가능하게 합니다.

선언적 API vs. 절차적 API

'코드로서의 인프라'라는 레시피 북을 사용하는 방식에는 두 가지 접근법이 있습니다.

• 절차적 방식 (Ansible 등)
  • "1. 가스레인지를 놓는다. 2. 오븐을 설치한다. 3. 싱크대를 연결한다."처럼 목표에 도달하기 위한 명령어의 순서와 과정을 하나하나 명시하는 방식입니다. 사용자가 모든 단계를 직접 정의해야 하므로 복잡할 수 있지만, 더 세밀한 제어가 가능합니다.
  • Ansible이 대표적인 절차적 도구입니다.
• 선언적 방식 (Terraform 등)
  • "이 주방은 가스레인지 1개, 오븐 1개, 싱크대 1개를 갖춘 상태여야 한다."라고 최종 목표를 선언합니다. 그러면 시스템이 알아서 그 상태를 만들어 줍니다.
  • Terraform이 대표적인 선언적 도구입니다.

가변 인프라 (Mutable Infrastructure)와 불변 인프라 (Immutable Infrastructure)

• 가변 인프라 (Mutable Infrastructure)
  • 가변 인프라는 '정성껏 가꾸는 정원'과 같습니다. 정원에 새로운 식물(소프트웨어)을 심거나, 기존 식물이 병들면(버그 발생) 직접 약을 쳐서(패치) 치료합니다. 시간이 지나면서 정원은 처음의 모습과 조금씩 달라집니다.
  • 가변 인프라 형태로 운영시 사소한 변경에 빠르게 수정이 가능하지만,
    시간이 지나면서 각 서버의 설정이나 버전이 미세하게 달라져 일관성이 깨지는 '설정 드리프트' 문제와 "어제는 잘 됐는데 왜 오늘 안 되지?"와 같이, 언제 어떤 변경이 문제를 일으켰는지 추적하기가 어렵습니다.
• 불변 인프라 (Immutable Infrastructure)
  • 불변 인프라는 '항상 새로 굽는 케이크'와 같습니다.
  • 케이크의 레시피(서버 이미지)를 변경해야 할 때, 기존 케이크를 수정하는 것이 아니라 변경된 레시피로 새로운 케이크를 구워 교체합니다. 모든 케이크는 항상 레시피와 동일한, 완벽한, 일관된 상태로 제공됩니다.
  • 불변 인프라는 모든 서버가 동일한 이미지로 생성되므로 설정이 달라질 위험이 없습니다. 따라서 가변 인프라에서 존재하는 문제점을 해결할 수 있습니다.
  • 새로운 이미지를 만드는 데 시간이 더 걸릴 수 있다고 생각할 수 있지만, 클라우드와 자동화 기술(DevOps)을 통해 해소가 가능합니다.
  • (참고) 전통적인 온프레미스 환경에서는 서버 한 대를 준비(프로비저닝)하는 데 며칠에서 몇 주까지 걸렸습니다. 이런 환경에서 문제가 생길 때마다 서버를 새로 만드는 것은 거의 불가능에 가까웠죠. 그래서 기존 서버에 접속해 직접 문제를 해결(수정)하는 방식이 일반적이었습니다. 하지만 클라우드 환경에서는 API 호출 한 번이나 클릭 몇 번으로 몇 분 안에 새로운 서버를 만들고, 필요 없어진 서버는 즉시 삭제할 수 있기 때문에 불변 인프라 구성이 가능합니다.