완전 관리형 오라클 컨테이너 가용성 서비스 출시

안녕하세요. 테크넷 김재벌 입니다.

지난 15여년은 클라우드의 성장과 IaaS 에서 PaaS , SaaS로의 변화와 더불어 멀티클라우드로의 전환이 가속화되고 있습니다.
한 7-8년 전부터 클라우드 네이티브에 대한 관심과 성장이 폭발적으로 있었던 시기 였는데, 
그중에서도 컨테이너에 대한 관심과 성장은 가히 폭발적이었씁니다.

도커를 시작으로 컨테이너는 폭발적으로 성장했는데 
(사실 솔라리스 ZONE 컨테이너나 LxC같은 서비스가 더 오래 되긴 했는데.... 아...세월이여... 벌써 16-17년전 이야기 네요..ㅠㅠ)

 

당연하게도 대부분의 퍼블릭클라우드 CSP는 컨테이너 서비스를 오래전 부터 제공하고 있었죠.

오라클 클라우드 역시 OKE 등을 통해 관리형 쿠버네티스 같은 서비스를 이미 제공하고 있구요. 물론, 도커와의 호환성을 제공하는 OCCS (Oracle Cloud Container Service)도 기존에 존재 했구요.

이번에 신규로 발표 된 오라클의 컨테이너 서비스는 "서버를 관리하지 않고도 컨테이너를 즉시 실행할 수 있는 서버리스 컴퓨팅 서비스"인 OCI(Oracle Cloud Infrastructure) 컨테이너 인스턴스 서비스 입니다.

오늘날 기업들은 클라우드에서 애플리케이션을 패키징하고 실행하기 위해서 컨테이너를 적극적으로 채택하고 있습니다. 오라클 클라우드의 경우 관리형 Kubernetes 서비스인 OKE(Oracle Container Engine for Kubernetes)는 OCI 고객들이 컨테이너를 대규모로 실행하기 위해 널리 사용하고 있죠

대규모 환경이 아닌데 쿠버네티스(Kubernetes)를 활용하기엔 너무 복잡도가 커지는 경우도 있을 수 있는데, 이경우  쿠버네티스(Kubernetes)를 사용하지 않고 컨테이너화된 애플리케이션을 실행하는 간단한 방법이 필요한 경우 컨테이너를 선택해 볼 수 있습니다.

하지만, 이 경우 컨테이너 구동을 위해서 VM(가상 머신)을 프로비저닝하고  컨테이너 런타임을 설치하고 여기에서 애플리케이션을 실행해야 합니다.

하지만 이런 과정은 VM과 서버를 관리하고 운영 체제를 패치하고 컨테이너 런타임을 정기적으로 업데이트해야 하므로 여전히 운영 복잡성과 관리부담을 가중시킵니다.

OCI Container Instances는 이러한 모든 운영상의 복잡성을 없애고 인프라를 관리하지 않고도 컨테이너화된 애플리케이션을 실행할 수 있도록 합니다. 

애플리케이션을 실행할 컨테이너 이미지를 제공하면 OCI가 기본 컨테이너 런타임과 컴퓨팅 리소스를 관리합니다. 컨테이너는 컨테이너 워크로드에 최적화되고 향상된 보안을 위해 강력한 워크로드 격리를 제공하는 완전 관리형 컴퓨팅에서 실행됩니다.

컨테이너 인스턴스를 사용하면 선택한 구성에 대해 일반 OCI 컴퓨팅 인스턴스와 동일한 가격 으로 CPU 및 메모리 리소스 비용을 지불합니다 . 더 이상 비용 절감을 위해 직접 관리하는 VM에서 실행 중인 컨테이너를 선택할 필요가 없습니다. OCI 컴퓨팅의 뛰어난 가격 대비 성능과 초당 청구를 통해 컨테이너 인스턴스는 클라우드에서 컨테이너를 실행하기 위한 최고의 가치 있는 옵션 중 하나 일 것입니다.

완전 관리형 컨테이너 서비스를 활용하면 아래와 같은 이점이 있습니다.

1. 간단하고 빠르며 유연한 배포
컨테이너 인스턴스는 가볍고 더 빠른 시작을 제공 합니다. 몇 초 만에 서비스 컨테이너를 배포합니다. CLI, API 또는 Oracle Cloud Console을 통해 컨테이너 이미지와 몇 가지 간단한 매개변수를 지정하여 하나 이상의 컨테이너로 새 컨테이너 인스턴스를 쉽게 생성할 수 있습니다. 컨테이너 인스턴스를 생성할 때 할당할 기본 컴퓨팅, CPU 및 메모리 리소스와 컨테이너 인스턴스가 상주하는 VCN 서브넷에 대해 선호하는 형태를 유연하게 지정할 수도 있습니다.

2. 리소스 제약 없이 복잡한 워크로드 실행
컨테이너 인스턴스를 사용하면 가벼운 애플리케이션뿐만 아니라 리소스 집약적인 애플리케이션도 실행할 수 있습니다. 기본 컴퓨팅 구성에서 제공하는 모든 CPU 및 메모리를 단일 컨테이너 인스턴스에 할당하여 까다로운 워크로드를 실행할 수 있습니다. 
예를 들어 E3 또는 E4 Flex 형태를 선택하여 단일 컨테이너 인스턴스에 최대 64개의 코어(128 vCPU) 및 1,024GB 메모리를 할당할 수 있습니다.

3.강력한 워크로드 격리
컨테이너 인스턴스는 보안 향상을 위해 컨테이너의 효율성과 VM의 강력한 격리를 결합합니다. 
컨테이너 워크로드에 최적화된 컨테이너 인스턴스는 하이퍼바이저 수준에서 격리되며 기본 OS 커널, CPU 또는 메모리 리소스를 다른 컨테이너 인스턴스와 공유하지 않습니다. 
이 두 번째 방어 계층을 사용하면 서로 다른 애플리케이션의 컨테이너가 더 이상 동일한 OS 커널을 공유하지 않아 공격 표면이 줄어듭니다.

컨테이너 인스턴스 서비스의 내부구조

컨테이너 인스턴스는 VM과 컨테이너의 장점을 결합한 형태로 Oracle Linux 기반 구조를 가집니다. 아키텍쳐에 대해서는 별도 포스팅을 통해 다루도록 하겠습니다.

(혹시 오해가 있을 수 있어서 추가 업데이트 합니다. Oracle Linux 기반이지, Oracle Linux 를 사용하는 것이 아닙니다. LightWeight OS (초경량 OS)를 제공합니다. 

컨테이너 구동에 필요한 부분 이외에 70% 가까운 라이브러리 등을 제거 하였다고 합니다.)

컨테이너 인스턴스 서비스를 사용해야 하는 이유
컨테이너 인스턴스는 Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼이 필요하지 않은 컨테이너화된 워크로드에 적합합니다. 완전한 통합 및 배포(CI/CD) 파이프라인의 일부인 빌드 및 배포 작업, 클라우드 운영을 위한 자동화 작업, 데이터/미디어 처리 등과 같은 임시 워크로드를 실행하는 데 최적이라고 할 수 있습니다. 컨테이너 인스턴스를 사용하면 컨테이너를 실행하는 것이 API 호출 또는 CLI 명령만큼 간단하므로 DevOps, 운영 또는 데이터 처리 워크플로의 일부로 컨테이너화된 작업을 쉽게 실행할 수 있습니다.

컨테이너 인스턴스는 격리된 웹 애플리케이션 또는 RESTful API를 실행하는 데에도 적합합니다. 원하는 프레임워크를 사용하여 애플리케이션을 개발하고, 컨테이너 이미지로 패키징하고, 컨테이너 인스턴스에서 실행할 수 있습니다. 애플리케이션은 단일 컨테이너 또는 컨테이너 그룹으로 구성될 수 있습니다. 동일한 컨테이너 인스턴스에서 실행되는 컨테이너는 함께 배치되고 localhost를 통해 또는 전체 스택 애플리케이션 배포 및 사이드카와 같은 패턴을 지원하는 루프백 인터페이스를 사용하여 통신합니다.

컨테이너 인스턴스는 레거시 모놀리식 애플리케이션을 클라우드로 이전하는 데 활용할 수도 있스니다. 일반적으로 이러한 애플리케이션은 Kubernetes와 같은 클라우드 네이티브 플랫폼용으로 구축되지 않았습니다. 예를 들어 스케일 아웃(Scale-Out : 수평확장) 이 불가능하거나 손상시 데이터에 대한 손실로 이루어질 수 있습니다.  서버나 VM을 프로비저닝, 패치 및 문제 해결하는 운영 오버헤드 없이 이러한 독립 실행형 애플리케이션을 컨테이너화하고 컨테이너 인스턴스에서 실행할 수 있습니다. 가장 까다로운 애플리케이션의 요구 사항을 충족하는 데 필요한 CPU와 메모리를 할당할 수 있습니다.

또한 컨테이너 인스턴스를 사용하여 개발 및 테스트 환경을 신속하게 만들고 해체할 수 있습니다. 로컬 워크스테이션을 사용하거나 VM을 관리하는 대신 개발자는 컨테이너 인스턴스에 쉽게 의존하여 생산성을 향상하고 로컬 워크스테이션의 리소스 제한에 부딪히거나 알 수 없는 워크로드를 실행할 위험을 피할 수 있습니다. 개발자는 또한 이를 사용하여 개발 또는 테스트 중에 애플리케이션이 액세스해야 하는 테스트 백엔드를 신속하게 설정할 수 있습니다.

 

정리하면

OCI Container Instances 서비스는 서버를 관리하지 않고 컨테이너를 실행하는 간단하고 빠르며 안전한 방법을 제공합니다. 다른 클라우드 공급자와 달리 OCI Container Instances의 서버리스에 대해 추가 비용을 지불할 필요가 없으므로 클라우드에서 컨테이너를 실행하기 위한 최적의 FinOPS 옵션을 제공합니다.