04. NHN Container Service (NCS)

정세현·2026년 7월 22일

NHN AX Internship Notes

목록 보기
9/16

0. 한 문장 정의

클러스터를 만들거나 관리하지 않고, 컨테이너 사양만 정의하면 바로 실행해주는 서버리스 컨테이너 서비스.

AWS로 치면 ECS Fargate에 가깝다. 노드(서버)라는 개념이 사용자에게 노출되지 않는다.

1. NKS와의 근본적 차이

NKSNCS
추상화 단위클러스터 → 노드 → 파드템플릿 → 워크로드 → 작업
노드 관리사용자가 사양·개수 결정없음 (사용자가 신경 안 씀)
학습 곡선높음 (K8s 전체)낮음 (콘솔 폼 작성 수준)
유연성매우 높음 (생태계 전체 활용)제한적
kubectl / Helm / ArgoCDox
적합MSA, 복잡한 배포 전략단순 API, 배치, 짧은 GPU 작업

판단 기준: "이 워크로드에 쿠버네티스의 복잡성을 지불할 가치가 있나?"
API 서버 1~2개면 NCS가 훨씬 빠르다. 서비스가 10개 넘어가면 NKS.

2. 핵심 개념 3층 구조

템플릿 (Template)          "어떤 컨테이너를 어떻게 만들지" — 설계도
     │ 참조(Reference)
     ▼
워크로드 (Workload)        "그 설계도로 몇 개를 어떻게 띄울지" — 실행 명세
     │ 생성(Create)
     ▼
작업 (Task) × N            실제로 돌아가는 컨테이너 묶음 — 실체

2-1. 템플릿

컨테이너의 사양을 정의한다. 여기에 들어가는 것:

기본 정보

  • 이름, 설명
  • 연결할 VPC / 서브넷

컨테이너 사양 (1개 이상)

  • 컨테이너 이미지 URL (보통 NCR 주소)
  • CPU / Memory / GPU 사용 여부
  • 컨테이너 포트
  • 연결할 NAS 스토리지 여부

템플릿을 만들어도 컨테이너는 생기지 않는다.
템플릿은 워크로드를 만들기 위한 틀일 뿐이다. 워크로드를 생성해야 컨테이너가 뜬다.
템플릿을 유지해두고 필요할 때만 워크로드를 생성해 컨테이너를 굴리는 사용법도 가능하다.
(→ 배치 작업, 이벤트성 워크로드에 유용)

2-2. 워크로드

템플릿을 참조해서 실행 방식을 정의한다.

  • 참조할 템플릿
  • 워크로드 실행 수 (= 몇 개의 작업을 띄울지)
  • 로드 밸런서 사용 여부
  • 플로팅 IP 사용 여부

2-3. 작업 (Task)

워크로드를 생성하면 템플릿에 정의된 컨테이너들이 작업 하위에 만들어진다.

  • 작업 하나에는 VPC 서브넷에서 할당받은 IP가 부여된다
  • VPC 내부에서는 작업IP:컨테이너포트로 직접 접근 가능
  • 워크로드 실행 수만큼 작업이 복제된다

쿠버네티스 대응: 작업(Task) ≈ Pod.
템플릿의 컨테이너 여러 개가 하나의 작업 안에 함께 뜨는 것도 Pod와 같은 구조다.

3. 첨부 다이어그램 해석

Step 1 — 템플릿 정의

Template
├─ Basic Info:  Name, Description
├─ VPC to connect: Subnet
├─ Container 1: 이미지 URL, CPU/Mem, GPU 없음, 포트 80,  스토리지 없음
└─ Container 2: 이미지 URL, CPU/Mem, GPU 없음, 포트 443, 스토리지 Online NAS

컨테이너 사양 2개를 한 템플릿에 정의했다.

Step 2 — 워크로드 정의 (템플릿 참조)

Workload
├─ Basic Info: Name, Description
├─ Number of Running Workloads: 2   ← 작업 2개
├─ Load Balancer: Use
└─ Floating IP: Use

Step 3 — 실제 구성 결과

                 ┌──────────── Load Balancer ────────────┐
   Floating IP ──┤  포트 80  → 각 작업의 Container 1로 분배 │
   + 도메인      │  포트 443 → 각 작업의 Container 2로 분배 │
                 └───────┬───────────────────┬────────────┘
                         │                   │
                ┌────────▼────────┐ ┌────────▼────────┐
                │     Task 1      │ │     Task 2      │
                │ ┌────┐ ┌──────┐ │ │ ┌────┐ ┌──────┐ │
                │ │C1  │ │ C2   │ │ │ │C1  │ │ C2   │ │
                │ │:80 │ │:443  │ │ │ │:80 │ │:443  │ │
                │ └────┘ └──┬───┘ │ │ └────┘ └──┬───┘ │
                │    IP     │     │ │    IP     │     │
                └───────────┼─────┘ └───────────┼─────┘
                            │                   │
                            └────► Online NAS ◄─┘
                                   (Volume 공유, 같은 Mount Point)
                                        IP
        ──────────────────── VPC Subnet ────────────────────

읽어낼 포인트

  1. 템플릿 1개 × 실행 수 2 = 작업 2개, 각 작업에 컨테이너 2개씩 → 총 컨테이너 4개
  2. LB가 포트별로 다른 컨테이너에 분배한다
    • 80 → 두 작업의 Container 1
    • 443 → 두 작업의 Container 2
  3. Online NAS 볼륨은 여러 작업이 공유한다 (Container 2가 모두 같은 마운트 포인트 사용)
    → K8s의 ReadWriteMany 개념. 블록 스토리지로는 안 되는 구조
  4. 모든 구성 요소가 같은 VPC 서브넷 안에 있고 각각 IP를 가진다
  5. 플로팅 IP를 켜면 LB에 FIP와 도메인이 붙어 외부 접근이 가능해진다

지정한 VPC 서브넷에 인터넷 게이트웨이가 연결되어 있지 않으면 플로팅 IP와 도메인을 사용할 수 없다.
외부 노출이 목적인데 접속이 안 되면 이걸 제일 먼저 확인.

4. 쿠버네티스 개념 대응표

NCSKubernetes설명
템플릿Pod Template (Deployment의 spec.template)컨테이너 사양 정의
워크로드Deployment / ReplicaSet몇 개를 어떻게 실행할지
워크로드 실행 수replicas복제 개수
작업 (Task)Pod실행 단위, 자체 IP 보유
컨테이너Container동일
로드 밸런서Service (type: LoadBalancer)트래픽 분배
플로팅 IP + 도메인EXTERNAL-IP + DNS외부 노출
Online NAS 마운트PVC (ReadWriteMany)공유 영속 볼륨
VPC 서브넷클러스터 네트워크네트워크 격리

이 표가 학습에 유용한 이유: NCS를 먼저 만져보면 K8s의 추상 개념이 훨씬 잘 이해된다.
반대로 K8s를 알면 NCS 콘솔은 30분이면 익힌다.

5. NCS를 선택하면 좋은 경우 / 아쉬운 경우

잘 맞는 경우

  • 단일 API 서버, 간단한 웹 앱
  • 주기적 배치 작업 (템플릿만 유지하다 필요할 때 워크로드 생성)
  • 짧게 쓰는 GPU 워크로드 (템플릿에서 GPU 사용 설정 가능)
  • 인프라 담당자가 없는 소규모 팀
  • PoC / 데모 / 해커톤 — 빠르게 띄우는 게 최우선

아쉬운 경우

  • 서비스가 많고 서로 호출하는 MSA (서비스 디스커버리를 직접 처리해야 함)
  • Canary / Blue-Green 등 정교한 배포 전략
  • Helm, ArgoCD, Istio 등 K8s 생태계 도구 활용
  • 커스텀 오퍼레이터, CRD가 필요한 경우
  • 세밀한 스케줄링(affinity, taint 등) 제어

6. 실습 시나리오 제안

목표: 같은 Spring Boot 앱을 NCS와 NKS 양쪽에 배포해 차이를 체감하기

  1. NCR에 my-api:1.0.0 이미지 push (03 문서 참고)
  2. NCS
    • 템플릿 생성: 이미지 URL = NCR 주소, CPU 1 / Mem 2GB, 포트 8080
    • 워크로드 생성: 실행 수 2, LB 사용, 플로팅 IP 사용
    • 발급된 도메인으로 /actuator/health 호출 확인
    • 워크로드 실행 수를 4로 변경 → 작업 개수 변화 관찰
  3. NKS
    • 동일 이미지로 Deployment(replicas: 2) + Service(LoadBalancer) 배포
    • kubectl scale deployment my-api --replicas=4
    • 이미지 태그를 1.0.1로 올려 롤링 업데이트 → kubectl rollout undo로 롤백
  4. 비교 정리
    • 첫 배포까지 걸린 시간
    • 스케일 조정 방법의 차이
    • 롤백이 가능한가 / 얼마나 쉬운가
    • 로그·메트릭 확인 방법

이 비교를 직접 해보고 정리해두면, 나중에 "왜 K8s를 썼는가"를 설명할 근거가 생긴다.

7. 체크리스트

  • 템플릿과 워크로드의 차이를 설명할 수 있다
  • 템플릿만 만들면 컨테이너가 안 뜬다는 걸 안다
  • 작업(Task)이 K8s의 Pod에 대응된다는 걸 이해했다
  • LB가 포트별로 다른 컨테이너에 분배되는 구조를 그림으로 그릴 수 있다
  • 플로팅 IP가 안 될 때 인터넷 게이트웨이를 먼저 확인해야 함을 안다
  • NCS와 NKS 중 어떤 상황에 무엇을 쓸지 판단 기준이 있다
profile
정세현
I'm the best
이전 포스트

03. NHN Container Registry (NCR)

0개의 댓글