Code Engine 플랜

IBM Cloud® Code Engine 다음과 같은 기본 워크로드 유형을 지원합니다: 애플리케이션, 작업, 함수, 플릿.

애플리케이션 또는 앱은 코드를 실행하여 HTTP 요청을 제공합니다. 기존 HTTP 요청 외에 IBM Cloud® Code Engine은 WebSocket을 통신 프로토콜로 사용하는 애플리케이션도 지원합니다. 앱의 실행 중인 인스턴스 수는 들어오는 요청과 사용자의 구성 설정에 따라 자동으로 확장되거나 축소(0개까지)됩니다. 앱에는 하나 이상의 개정이 포함되어 있습니다. 개정은 앱 구성 특성의 불변 버전을 나타냅니다. 앱 구성 특성을 업데이트할 때마다 앱 개정이 새로 작성됩니다.

작업은 실행 가능 코드의 하나 이상의 인스턴스를 병렬로 실행합니다. HTTP 요청을 처리하는 애플리케이션과 달리 작업이 한 번 실행되고 종료되도록 설계되었습니다. 작업을 작성할 때 작업이 실행될 때마다 사용될 워크로드 구성 정보를 지정할 수 있습니다.

함수는 HTTP 요청에 의해 호출될 때 작업을 수행하는 상태 저장소 없는 코드 스니펫입니다. IBM Code Engine 기능을 사용하면 확장 가능한 서버리스 방식으로 비즈니스 로직을 실행할 수 있습니다. IBM Code Engine 기능은 짧은 지연 시간과 신속한 스케일아웃 시나리오를 지원하는 최적화된 런타임 환경을 제공합니다. 함수 코드는 특정 Node.js 또는 Python 버전이 포함된 관리형 런타임에서 작성할 수 있습니다.

서버리스 플릿이라고도 하는 플릿은 지정된 작업 집합을 완료하기 위해 하나 이상의 사용자 코드 인스턴스를 실행합니다. 플릿은 대규모 컴퓨팅 집약적인 워크로드를 처리하고 머신 프로필을 제어할 수 있으며 GPU 리소스에서 실행할 수 있습니다. 플릿은 단일 테넌트이며 동적 작업 대기열을 구현하고 머신 프로필 구성을 완벽하게 제어할 수 있습니다. 또한, 차량은 가상 프라이빗 클라우드(VPC)에 연결하여 사용자 데이터와 서비스에 안전하게 액세스할 수 있습니다.

Code Engine 의 애플리케이션, 작업, 기능 및 차량군 비교
특성	애플리케이션	작업	기능	Fleet
실행 시간 (지속 기간)	장기 실행 (요청당 10분)	장기 실행 (최대 24시간)	단기 실행 (2분이하)	장기 실행(몇 분~몇 주)
시작 대기 시간	중간	예정 시작	낮음	낮음
종료	계속 실행	완료 시까지 실행	완료 시까지 실행	완료 시까지 실행
호출	요청 시 또는 영구적으로 실행 중인 경우	스케줄됨	요청 시, 인스턴트	스케줄됨
프로그래밍 모델	컨테이너 기반 빌드 및 실행	컨테이너 기반 빌드 및 실행	언어 특정 소스 코드 파일 및 종속성 메타데이터	컨테이너 기반 빌드 및 실행
병렬 처리	병렬 실행, 유연성	낮은 병렬 실행에서 중간 병렬 실행	높은 병렬 실행	높은 병렬 실행 및 대기열
Scale-out	요청 수 기반	작업 워크로드 정의 기반	이벤트 또는 직접 호출 기반	작업 및 동시 인스턴스 수 기준
격리	다중 테넌트	다중 테넌트	다중 테넌트	싱글 테넌트
GPU 지원	아니오	아니오	아니오	예
기계 구성에 대한 제어	제어 없음	제어 없음	제어 없음	전체 제어
VPC 연결	‘사적인 길’을 통해	‘사적인 길’을 통해	‘사적인 길’을 통해	네이티브 (서브넷 풀을 통해)
최적화 대상	장기 실행, 매우 복잡한 워크로드 및 온디맨드 용량 확장	높은 자원 수요가 있는 스케줄된 또는 계획된 워크로드	시작 시간 및 빠른 용량 확장	대규모의 연산 집약적 워크로드

Code Engine 유스 케이스

Code Engine에 대한 유스 케이스는 매우 다양합니다. 다음은 시작할 몇 가지 유스 케이스 예입니다.

컨테이너에 대한 경험은 있지만 클러스터 관리에 대한 기술이나 예산이 없음: 사용자는 컨테이너에 대해 잘 알고 있는 개발자라고 가정합니다. 클러스터 관리의 복잡성이나 시간 낭비를 원하지 않습니다. Code Engine을 사용하면 클러스터 관리에 필요한 기술이나 시간에 대해 걱정할 필요가 없습니다. 대신, Code Engine을 사용하면 이러한 복잡성이 없어지며, IBM 팀에서 IBM Cloud 서비스의 일부로 인프라를 관리해 줍니다.
간헐적으로 급증하는 워크로드: 웹 사이트는 주말에 사용량이 많지만 주중에는 트래픽이 적습니다. 이 웹 사이트의 경우 이러한 폭발적인 활동 후에 비활성 기간을 거치기 때문에 Code Engine이 적합한 솔루션입니다. Code Engine을 사용할 경우 웹 사이트 애플리케이션은 트래픽 증가를 대비해 애플리케이션 인스턴스를 자동으로 확장한 다음 비활성 기간 동안 다시 축소합니다(0까지도 축소).
일괄처리 워크로드가 스토리지와 통합됨: 매월 말에 직원 급여를 처리하는 일괄처리 작업을 사용합니다. 이 작업은 매월 한 번씩 실행되기 때문에 대부분의 시간 동안은 유휴 상태이지만, 실행될 때는 CPU와 메모리를 많이 소모합니다. 결과를 저장하려면 일괄처리 작업을 스토리지와 통합해야 합니다. Code Engine을 사용할 경우 일괄처리 작업을 IBM Cloud Object Storage와 통합할 수 있으므로, 작업이 실행 중일 때 사용하는 리소스에 대해서만 비용이 청구됩니다. 작업이 유휴 상태일 경우 리소스가 이용되지 않으므로 비용이 발생하지 않습니다. 그러나 IBM Cloud Object Storage 인스턴스를 사용하면 작업에 비용이 발생할 수 있습니다.
워크로드 가져오기: 업무 중 일부는 이미지를 작성하고 배치하는 것입니다. 사용자는 컨테이너 이미지를 작성하고 배치하는 데 경험이 많지만 다른 태스크에 집중할 수 있도록 이 프로세스를 단순화하려고 합니다. Code Engine을 사용할 경우 동일한 인터페이스에서 직접 이미지를 빌드하고 배치할 수 있으므로, 일상적인 태스크를 단순화하고 더 많은 코드를 개발할 시간을 확보할 수 있습니다.
테스트, 개념 증명 또는 "타이어 킥": 사용자는 컨테이너 기반 아키텍처에 대해 자세히 알아보는 데 관심이 있습니다. 사용자의 팀은 애플리케이션을 개발했지만 관리자에게 제출하기 전에 애플리케이션을 테스트하려고 합니다. 이는 소형 애플리케이션이므로 소형 전용 클러스터에까지 비용을 쓰고 싶어하지 않습니다. 이 경우 애플리케이션을 테스트한 다음 전용 클러스터에서 요구할 수 있는 비용을 지불하지 않고 이해 당사자(stakeholder)에게 설계 개념 증명을 제공할 수 있습니다.

앱, 작업 또는 기능을 사용하는 경우

애플리케이션 및 작업은 매우 유사합니다. 결국에는 둘 모두 코드만 실행합니다. 하지만 코드를 앱이나 작업으로 구성하기로 결정할 때 고려해야 할 몇 가지 핵심 사항이 있습니다.

코드가 이벤트에 응답해야 합니까?: Code Engine의 컨텍스트에서 수신 HTTP 요청(웹 페이지를 로드하는 요청) 또는 REST API 호출은 이벤트로 간주됩니다. 앱 또는 작업 중에서 선택할 때 대개는 이벤트 기반 개념이 중요한 요소입니다. 정의상 앱은 HTTP 요청으로 인해 실행되는 반면 작업은 호출 결과로 실행되기 때문입니다.; 워크로드가 수신 HTTP 요청에 대해 응답함을 알고 있다면 앱은 올바른 선택입니다. 그러나 워크로드가 실행된 후 완료되는 경우 작업이 더 적합합니다.
코드가 어떤 방식으로 스케일링됩니까?: 앱 및 작업 모두 확장 가능합니다. 앱의 각 인스턴스는 한 번에 특정 수의 동시 요청만 처리할 수 있으므로 활성 수신 요청 수와 같은 측정 가능한 실시간 기준에 응답하여 앱이 스케일링됩니다. 작업이 작성되면 지정되는 인스턴스 수를 기반으로 작업이 스케일링됩니다.; 특성 수의 코드 인스턴스를 실행하려고 하고 수신 HTTP 요청 없이 각 인스턴스를 실행할 수 있는 경우 작업이 적합한 선택입니다. 그러나 인스턴스 수가 수신 HTTP 로드를 기반으로 동적으로 스케일링되어야 하는 경우 앱이 더 적합합니다.

Code Engine의 공통 시나리오

이러한 공통 시나리오 중 일부를 읽고 특정 유형의 워크로드를 선택하는 시기를 이해하십시오.

워크로드 대기 시간이 낮아야 하거나 대화식입니까?: 워크로드에서 클라이언트 또는 사용자가 요청의 응답 동안 동기적으로 대기해야 하고 응답이 거의 즉각적으로 사용 가능해야 하는 경우 애플리케이션을 사용하십시오. 애플리케이션은 외부에서 연결할 수 있는 엔드포인트를 제공하고 요청에 동기식으로 응답합니다. 해당 워크로드의 예는 웹 사이트, 챗봇, 모바일 애플리케이션입니다. 애플리케이션을 사용하십시오.
계산이 경량이고 낮은 CPU, 메모리, I/O가 필요합니까?: 워크로드가 경량이고 CPU, 메모리 및 I/O가 적게 필요한 경우, 애플리케이션에 사용할 수 있는 동시성 옵션이 유용할 수 있습니다. 일반적인 예는 기본 조작을 제공하고 NoSQL 데이터베이스를 지원하는 API 서버입니다. 이러한 유형의 요청은 일반적으로 적은 양의 데이터를 가지며 낮은 메모리 또는 더 적은 CPU 사이클이 필요합니다. 동시성이 높을수록 애플리케이션은 두 번째 요청이 I/O를 기다리는 동안 첫 번째 요청의 데이터를 처리할 수 있습니다. CPU 및 메모리 요구사항이 낮기 때문에 많은 요청을 동시에 실행할 수 있습니다. 애플리케이션을 사용하십시오.
계산이 CPU, 메모리 또는 I/O에 바인드되었습니까?: 특정 양의 데이터를 처리하려면(여기서 각 데이터 청크가 크고 대량의 CPU 및 메모리가 필요함) 일반적으로 작업을 선택하는 것이 더 좋습니다. 그러나 워크로드에 요청-응답 패턴이 필요한 경우 앱을 사용할 수도 있습니다. 두 경우 모두 단일 동시성으로 계산 태스크가 실행됩니다. 각 애플리케이션 인스턴스 또는 작업 태스크는 인스턴스에 대해 구성된 리소스를 완전히 활용하기 위해 하나의 요청 또는 데이터 청크만 동시에 처리합니다. 유사성은 인스턴스 또는 태스크 수로 달성되며, 이 경우 높은 리소스 제한조건으로 인해 추가 태스크 작성 비용은 매우 적습니다. 일반적인 예는 Object Storage 버킷에서 이미지 데이터의 처리 또는 기계 학습 모델 제공입니다. 애플리케이션 또는 작업을 사용하십시오.
계산이 오랜 시간 동안 실행됩니까?: 계산이 더 오랜 기간 동안 실행되는 경우 해당 비동기 네이처로 인해 작업을 선택하는 것이 더 좋습니다. 스케일에서 오픈 연결을 유지보수하는 것은 비용이 많이 들기 때문에 애플리케이션의 최대 지속 기간은 항상 제한됩니다. 일반적인 워크로드는 기계 학습 모델 또는 하이퍼 매개변수 최적화를 훈련하는 것입니다. 작업을 사용하십시오.
계산 선불의 동시성을 지정할 수 있습니까?: 수행해야 하는 계산 수를 아는 경우 완료될 때까지 정확한 수의 인스턴스로 작업을 실행할 수 있습니다. 일반적인 예는 하이퍼 매개변수 튜닝 또는 신경망 훈련입니다. 작업을 사용하십시오.
워크로드가 일부 이벤트에 반응합니까?: 저장소에 푸시되는 Git 커미트, Object Storage 버킷에 업로드되는 오브젝트, 데이터베이스 내에서 수정되는 문서와 같이 워크로드가 이벤트에 반응해야 하는 경우 애플리케이션을 사용하십시오. 애플리케이션은 이벤트 소스에서 이벤트를 수신하도록 구성할 수 있는 엔드포인트를 제공합니다. 애플리케이션을 사용하십시오.
이벤트 또는 요청에 응답하여 짧은 시간에 많은 양의 데이터를 처리해야 합니까?: 워크로드에 예측되지 않은 요청 또는 이벤트에 대한 빠른 응답이 필요한 경우 애플리케이션이 동적으로 스케일링되므로(0에서도) 애플리케이션이 일반적으로 더 적합합니다. 애플리케이션을 사용하십시오.
앱 및 작업 결합: 앱 및 작업을 결합할 수 있으며 여기서 애플리케이션은 특정 계산을 아웃소싱하기 위해 작업을 시작할 수 있습니다. 작업이 애플리케이션을 조회할 수도 있습니다. 작업 및 앱 결합의 일반적인 예는 기계 학습 모델의 훈련 및 제공입니다. 작업은 일반적으로 모델을 훈련하는 데 사용되며 애플리케이션은 모델을 제공하는 데 사용됩니다. 애플리케이션 및 작업을 사용하십시오.