클라우드 네이티브·오케스트레이션·서버리스

서버 여섯 개를 원한다고 쓰면 여섯 개가 일하는가

한빛도서관은 접수일에 맞춰 예약 응용의 실행 수를 여섯 개로 늘리려 한다. 관리 화면에는 목표 6, 실행 중 5, 요청을 받을 준비가 된 것 4가 보인다. 설정에는 6이라고 적혀 있지만 실제로 처리할 수 있는 자원은 다르다. 잘못된 이미지나 부족한 자원 때문에 나머지가 시작하지 못할 수도 있다.

이 절은 바라는 상태를 선언하고 실제 상태를 관찰·조정하는 운영을 설명한다. 컨테이너를 쓰는 것, 여러 실행 단위를 조정하는 것, 서버 관리를 서비스에 맡기는 것은 서로 관련되지만 같은 선택이 아니다. 가상머신·컨테이너와 클라우드 공유책임을 바탕으로 읽는다. 수치와 도서관 구조는 자체 교육용이다.

앞선 DevOps 가치흐름과 연결

DevOps는 개발·배포·운영을 자동화와 피드백으로 이어 변경의 실제 결과를 확인하는 흐름이다. 클라우드 네이티브에서는 이를 선언형 실행·관찰·조정과 안전한 변경으로 확장한다.

1. 클라우드 네이티브는 도구 목록을 모두 설치하는 일이 아니다

클라우드 네이티브는 변화하는 환경에서 확장·회복·관찰·자동화가 가능한 응용과 운영을 설계하는 접근이다. CNCF는 느슨한 결합, 관리·관찰 가능성과 반복 가능한 변경을 강조하며 컨테이너·서비스 메시·마이크로서비스 등을 기술의 예로 든다.¹ 예시 기술을 모두 사용해야만 좋은 시스템이라는 뜻으로 읽지 않는다.

한빛도서관의 작은 개발팀은 업무 모듈을 분리한 단일 응용으로도 명확한 계약·반복 배포·수평확장·관찰을 갖출 수 있다. 마이크로서비스는 독립 배포·확장이 필요한 업무를 나눌 수 있지만 원격 호출·부분 실패·데이터 일관성·운영 책임을 늘린다. 팀과 변경 경계의 실제 필요 없이 기능마다 별도 서버를 만드는 안은 기각할 수 있다.

불변 배포물은 실행 중인 서버를 제각각 고치기보다 검증한 새 배포물을 식별해 교체하는 관점이다. 이전 파일을 보존하는 것과 취약한 옛 버전의 무기한 실행을 허용하는 것은 다르다. 변경 근거와 실제 실행 판본을 연결하고 지원이 끝난 실행 경로를 정리한다.

선언형 관리는 수행할 명령의 긴 순서보다 원하는 상태를 적고 현재와의 차이를 조정하는 방식이다. 선언이 틀리면 잘못된 상태를 반복해서 만들 수 있으므로 승인·정책·실제 결과 확인이 필요하다. 자동화가 검토할 책임을 없애지는 않는다.

2. 이미지와 실행 중인 컨테이너를 구별한다

앞에서 배운 컨테이너는 커널을 공유하는 실행환경의 격리다. 이미지는 그 실행환경을 시작하는 데 필요한 파일과 정보를 묶은 배포물이고, 컨테이너는 그 배포물로 시작한 실제 실행이다. 같은 이미지라도 환경설정·권한·외부 데이터가 다르면 결과가 달라질 수 있다.

이미지의 태그는 사람이 붙인 이름이고, 다이제스트는 내용 식별에 쓰는 값이다. 사용한 실제 내용과 출처를 연결하되 해시가 같다는 사실이 프로그램의 정확성·안전성을 증명하지는 않는다. 구성요소 목록과 취약점 확인, 빌드 출처와 승인된 변경 범위도 필요하다.

설정·비밀값·영속 데이터를 이미지에 무조건 함께 넣지 않는다. 응용의 일시적 작업 파일과 예약 원장은 수명이 다르다. 실행 단위를 삭제해도 보존해야 하는 데이터에는 별도 저장·권한·백업이 필요하다. 반대로 필요 없는 비밀값과 로그를 남겨 놓고 컨테이너만 지웠다고 종료하지 않는다.

상태 없는 작업자라는 말은 업무에 데이터가 전혀 없다는 뜻이 아니다. 후속 처리의 상태를 특정 작업자의 메모리에만 두지 않고 필요한 공통 상태를 별도 서비스·원장에 두는 설계다. 외부 저장소의 장애와 동시성은 여전히 처리해야 한다.

3. 오케스트레이터는 어떤 역할로 원하는 상태를 맞추는가

컨테이너 오케스트레이션은 여러 실행 단위의 배치·유지·교체·연결·자원을 조정하는 활동이다. Kubernetes는 그 구현의 하나이며 클라우드 네이티브의 동의어가 아니다. 단일 서비스에는 관리형 실행환경이나 더 작은 운영 구조가 적합할 수 있다.

Kubernetes는 실행·배치의 기본 단위를 Pod(파드)라고 부른다. 아래 역할에서 쓰는 Pod와 그 밖의 객체를 이 절의 4항에서 자세히 구별한다. Kubernetes의 클러스터는 제어평면과 작업 노드로 구성된다. API 서버는 관리 요청을 받는 접점, etcd는 관련 API 상태를 저장하는 일관된 저장소, 스케줄러는 아직 배치되지 않은 Pod를 적합한 노드에 연결하는 역할이다. 컨트롤러는 원하는 상태와 실제 상태를 조정하고 노드의 kubelet과 런타임은 실행을 관리한다.²

승인된 원하는 상태는 API·정책을 거쳐 상태에 등록되고, 컨트롤러의 차이 조정과 배치 결정을 통해 노드의 실제 실행·준비 상태로 이어진다. 관찰·오류·차이 보고는 다시 API 상태에 연결된다. 아래 기존 원하는 실행 수가 실제 준비 수가 되는 조정 고리를 사용하며, 이 관리 흐름과 예약 원장의 업무 요청을 구분한다.

이 도식은 관리 흐름이다. 이용자의 요청이 매번 스케줄러와 etcd를 통해 예약 원장에 저장된다는 뜻이 아니다. 클러스터 상태 저장소를 애플리케이션의 예약 데이터베이스와 혼동하지 않는다.

Kubernetes 객체의 spec은 원하는 상태, status는 관찰된 상태를 표현한다. 둘이 다를 수 있으며 원인을 조사해야 한다.³ 노드에 자리가 없거나 이미지·스토리지·권한이 잘못됐다면 선언을 반복 적용하는 것만으로 해결되지 않는다.

4. Pod·Deployment·Service·StatefulSet은 역할이 다르다

Pod는 함께 배치·실행하며 네트워크와 일부 자원을 공유하는 한 개 이상의 컨테이너 단위다. 일반적인 응용의 실행 단위를 이루지만 Pod 하나가 영구히 같은 상태로 존재하는 것은 아니다. 노드 장애·갱신에 따라 교체될 수 있다.

Deployment와 StatefulSet의 기능은 공식 객체 설명에서, Service의 연결 역할은 해당 문서에서 확인한다.⁴⁵ 이름에 Stateful이 있다고 어떤 데이터베이스든 설정 없이 고가용성이 되는 것은 아니다. 저장장치와 데이터베이스의 실제 일관성·복구 방식은 따로 설계한다.

HTTP 요청 경로를 여러 서비스에 연결하는 게이트웨이나 Ingress 같은 수단도 있다. 네트워크 접점을 만들었다는 사실은 모든 내부 기능을 공개하라는 뜻이 아니다. 관리 API와 데이터 원장의 접근 범위를 최소화한다.

5. 시작·생존·준비 검사는 다른 질문이다

startup 검사는 시작 과정이 끝났는지 확인한다. 설정한 startup 검사가 성공하기 전에는 liveness와 readiness 검사를 시작하지 않는 동작을 이용해 긴 초기화를 보호할 수 있다. liveness 검사는 재시작이 필요하다고 판단할 실행 장애를 탐지하도록 설계한다. readiness 검사는 현재 요청을 받을 준비가 되었는지 확인한다.⁶

이 검사는 사람이 정한 조건을 평가하는 수단이지 모든 장애의 원인을 알아내는 판정기가 아니다. liveness 실패의 설정된 임계에 따라 재시작이 일어나므로, 단순 외부 DB 지연을 여기에 넣으면 DB는 고치지 못하고 작업자 재접속 폭주만 만들 수 있다. 재시작으로 회복할 상태와 일시 대기·원인 복구가 필요한 상태를 구별한다.

반대로 프로세스가 살아 있다고 모든 요청을 보내면 시작 중인 캐시·필수 자료를 읽지 못할 수 있다. readiness에는 자신의 업무에 필수인 조건을 반영하되 값비싼 검사나 부작용으로 부하를 만들지 않는다. 검사 통과는 모든 예약이 정확하다는 시험 성적도 아니다.

준비 상태를 바꾸는 것과 모든 접근을 막는 것은 다르다

일반적인 Service의 엔드포인트 선택은 Pod의 준비 상태를 반영한다. 그러나 readiness는 방화벽·인가 통제가 아니다. 직접 Pod에 접근하는 경로, 이미 맺어진 연결, 종료 중인 요청은 각각의 연결·응용 동작을 확인해야 한다. publishNotReadyAddresses를 사용하는 Service는 준비되지 않은 주소를 노출하는 별도 설정도 있으므로 실제 서비스 설정을 함께 읽는다.⁷

따라서 ‘readiness가 실패하면 모든 경로에서 즉시 어떤 요청도 들어오지 않는다’고 보장하지 않는다. 허용 경로를 제한하고, 새 요청 수락·진행 작업·종료를 응용과 접점에서 제어한다. 불충족인 요청에는 재시도 가능 여부와 보류 상태를 명확히 반환하며, 성공 응답으로 꾸미지 않는다.

자체 CN-R1의 목표 6개·실행 중 5개·준비 완료 4개에서 준비 달성은 4/6≈66.67%다. 실행 중 집단에서는 4/5=80%지만 목표는 충족되지 않았다. 미준비 1개와 아직 실행되지 않은 1개의 원인을 나누어 본다.

6. 따라 계산 CN-C1: 배치 자원과 HPA의 분모

자원 request는 배치 시 필요한 자원을 판단하는 기준이고 limit는 실행 중 허용 범위를 제한하는 설정이다. 사용량은 request를 넘을 수 있으며 CPU 제한과 메모리 부족의 동작은 다르다. CPU는 제한으로 실행이 억제될 수 있고 메모리는 부족·한도 초과 조건에서 실행 종료 문제가 생길 수 있다.⁸ request를 작게 썼다고 실제 사용량이 줄거나 노드 용량이 늘어나는 것은 아니다.

CN-C1은 노드 2개가 각각 응용에 할당 가능한 CPU 3단위·메모리 6GiB를 갖고, Pod 하나가 CPU 0.75·메모리 1GiB를 요청한다고 가정한다. 다른 제약·추가 Pod·부가자원은 제외한다. GiB는 2의 30승 바이트 단위다.

CPU 기준으로 노드당 3/0.75=4개, 메모리 기준으로 6개다. 작은 값 4개가 노드당 한계이므로 두 노드 합계 8개다. 전체 CPU와 메모리를 합쳐 아무 배치나 가능하다고 가정하지 않는다. 여기서는 요청이 동일하고 다른 제약이 없어 단순 계산이 가능하다.

목표 Pod 6개는 정상 시 배치할 수 있다. 그러나 노드 하나가 고장 나면 남은 노드는 4개만 수용하므로 2개가 부족하다. 컨트롤러가 대체 Pod를 만들려고 해도 CPU를 만들어 낼 수 없다. 같은 노드 3개라면 하나의 장애 뒤 8개를 배치할 자원이 남지만, 장애영역·스토리지·연결·정책까지 확인한 보장은 아니다.

HPA(Horizontal Pod Autoscaler)는 관찰한 지표로 목표 Pod 수를 조정한다. 여기서 CPU의 목표를 사용률(Utilization)로 정했다면 분모는 해당 컨테이너들의 CPU request다. 노드 전체 CPU나 limit에 대한 비율로 바꾸어 계산하지 않는다. 원시 사용량 목표는 별도의 방식이다.⁹

HPA 예제 CN-H1: 분모만 바꾸어도 계산값이 달라진다

동일한 단일 컨테이너 Pod 4개가 모두 준비돼 있고 각 request가 0.75CPU, 관측 사용이 0.5625CPU라고 하자. 지표 누락·허용오차·안정화·상한은 제외한다. 각 사용률은 0.5625/0.75=75%이고 목표 50%를 사용한 기본식은 올림(4×75/50)=6개다. 현재 관측한 총사용량은 4×0.5625=2.25CPU이고 목표 사용률에서 같은 크기의 Pod 하나가 맡을 사용량은 0.75×0.5=0.375CPU다. 이 관측량을 동일한 Pod로 나누는 기본 계산은 2.25/0.375=6개이며, 4개에 사용률 비 75/50=1.5를 곱한 것과 같다. 나눈 결과가 정수가 아니면 부족하지 않게 올림한다. 이 산술이 실제 처리량의 균등 분산이나 준비 완료를 입증하지는 않는다.

이때 request를 1.5CPU로 바꾸되 같은 수의 Pod에서 관측한 사용량이 0.5625로 같다는 별도 조건을 두면, 사용률은 37.5%이고 같은 기본식은 올림(4×37.5/50)=3개다. 수치가 75%에서 37.5%로 낮아졌어도 실제 사용량이나 프로그램 효율이 좋아진 것은 아니다. 배치 기준도 노드당 3/1.5=2개로 바뀐다. 총량·분모·배치·서비스 성과를 함께 해석한다.

실제 HPA는 누락된 지표·미준비 Pod·허용오차·안정화·최대/최소 등의 조건을 더 고려한다. 관련 request가 설정되지 않아 사용률을 정의할 수 없는 경우를 사용량 0으로 채우지 않는다.⁹ 계산으로 나온 목표와 실제 배치·준비·처리 성능은 여전히 다른 단계다. 위 숫자는 설정 변경의 이해를 위한 예이며 실제 조정값 권장이 아니다.

7. 변경은 새 실행과 진행 중인 업무를 함께 다룬다

롤링 갱신은 실행을 순차적으로 교체하고, 블루·그린은 별도 새 환경으로 전환하며, 카나리는 일부 요청에서 먼저 관찰하는 방식이다. 무엇을 선택해도 새 코드·설정·데이터 의미가 맞아야 한다. 갱신 옵션도 가용 실행과 추가 실행의 수를 제어하는 수단이지 전체 업무 무중단 인증이 아니다.⁴

새 버전이 준비되지 않았는데 옛 작업자를 모두 지우면 용량이 끊긴다. 새 작업자의 준비를 확인하고 옛 작업자의 새 요청 수락을 제한하며 진행 중인 작업의 완료·중단·재시도를 대사한다. 종료 유예시간과 최대 작업시간이 다르면 미완료 작업을 어떻게 회수할지 정한다. 준비 상태 변경·엔드포인트 반영·진행 연결 정리가 같은 시각에 완료된다고 가정하지 않는다.

코드를 되돌려도 이미 바뀐 예약과 발송은 사라지지 않는다. 데이터 형식·설정·권한의 복원 가능성을 확인하고, 해석할 수 없는 구판을 무리하게 살리는 대신 검증된 범위로 기능을 제한한다. 목적은 옛 경로의 영구 호환이 아니라 현재 지원하는 동작의 안전한 변경이다.

인프라를 코드로 관리한다는 것은 자원·정책·설정을 검토 가능한 선언으로 관리하는 관점이다. 승인된 선언과 실제 상태가 다르면 원인을 확인한다. 비밀값을 공개 선언에 넣거나 잘못된 정책을 빠르게 확산시키지 않도록 검토·권한·감사를 둔다.

8. 서버리스는 서버와 운영 책임이 사라지는 것이 아니다

서버리스는 개별 서버의 생성·유지·확장 등 일부 기반 관리를 직접 하지 않도록 서비스가 추상화하는 접근이다. FaaS는 함수 단위 코드를 호출 조건에 따라 실행하는 서비스다. 서버리스가 함수 실행만을 뜻하는 것은 아니다.¹⁰

도서관에서 승인된 공지의 작은 형식 변환은 함수로 실행할 수 있다. 사용이 드물고 짧게 끝나는 작업에는 편리할 수 있지만 실행시간·동시수·메모리·연결·요금 경계를 확인해야 한다. 새 실행환경을 준비하는 콜드 스타트와 외부 서비스의 대기 때문에 지연이 달라질 수도 있다.

함수의 임시 파일·메모리가 다음 호출까지 반드시 남는다고 의존하지 않는다. 반대로 호출이 끝날 때마다 반드시 모두 지워진다고 가정해서도 안 된다. AWS Lambda는 실행환경을 재사용할 수 있고, 공식 지침은 호출 간 유출 위험 때문에 그 환경에 사용자 자료나 보안상 중요한 상태를 보관하지 않도록 주의시킨다.¹¹

재사용 가능한 연결·안전한 정적 캐시와 사용자별 일시 자료를 나누고, 필요한 영속 결과와 처리 상태는 권한 있는 저장소에 둔다. 이전 사용자의 전역 변수나 임시 파일을 다음 요청의 입력으로 섞지 않도록 생명주기를 관리한다. 실행환경 재사용의 세부 계약은 서비스마다 확인하며 모든 제품이 같은 격리·삭제 동작을 한다고 일반화하지 않는다.

함수 종료와 고객에게 메일이 도착한 사실도 다르다. 서버리스여도 코드·데이터·권한·비용·오류·사용자 대응은 남는다.

9. 이벤트와 함수의 재시도는 외부 효과를 반복할 수 있다

이벤트는 어떤 일이 일어났다는 메시지다. 이벤트를 받은 함수가 예약 알림을 보내고 완료 응답을 잃으면 같은 이벤트를 다시 받을 수 있다. AWS Lambda 문서도 호출 방식과 경유 서비스에 따라 재시도 책임이 다르고, 함수가 일부 또는 전부 실행됐을 수 있다고 설명한다.¹²

CN-E1은 이미 확정된 예약의 안내만 대상으로 한다. 이벤트 ID·예약 ID·수신대상·문안 판본을 연결하고 같은 이벤트를 다시 받으면 기존 상태와 실제 결과를 확인한다. 외부 발송 서비스의 멱등 기능·결과 조회가 있는지 확인하며 로컬에 ‘처리됨’을 적는 것만으로 정확히 한 번의 발송을 보장하지 않는다.

CN-E2: 기록 순서만 바꾸어서는 두 실패를 동시에 없애지 못한다

이 사례는 로컬 처리 기록과 외부 발송을 하나의 원자적 거래로 묶지 못한다고 가정한다. 두 실행은 다음처럼 다르게 실패할 수 있다.

따라서 준비·요청·확인·실패·미확인을 구별하고, 외부 서비스가 제공하는 동일 요청 식별자·멱등성 범위·유지기간·결과 조회를 실제로 확인한다. 같은 식별자를 다른 수신자나 다른 문안에 재사용하지 않는다. 여러 작업자가 동시에 같은 이벤트를 처리할 수 있다면 로컬 처리권 획득도 조건부 변경 등으로 중복되지 않게 해야 하지만, 이 조치 하나가 외부 효과까지 원자적으로 만드는 것은 아니다.

외부에서 결과를 확인할 방법이 없다면 어느 쪽으로든 단정할 수 없다. 무조건 재발송할지 말지가 아니라 누락·중복의 영향과 업무 규칙을 확인해 담당자에게 미확인 상태를 인계한다. 이미 발송된 안내의 수정·취소 가능성도 별도다. 시스템의 성공 문구가 아니라 실제로 확보한 근거까지 완료로 표시한다.

반복 실패를 별도 보관하는 대기열에는 이유·원본 식별·다음 담당·재처리 조건을 둔다. 오류를 큐로 옮겼다고 해결된 것은 아니다. 권한 거절·잘못된 대상·실제 발송 미확인·일시 장애를 구별하고 원인이 고쳐지지 않은 요청을 끝없이 반복하지 않는다.

자체 집계에서 고유 이벤트 100개 중 80개는 1회, 20개는 1회 추가 시도됐다면 실행 시도는 120번이다. 이 값만으로 실제 전달이 100번인지·120번인지 알 수 없다. 정상적인 중복 제한과 결과 대사를 별도로 마친 경우에만 확인된 업무 결과를 보고한다. 사건 수·시도 수·확인된 전달 수의 분모를 구별한다.

10. 따라 계산 CN-F1: 평균 동시수와 실제 수용 한도

CN-F1은 안정된 상태에서 초당 20개 작업이 완료되고 평균 실행시간이 0.3초라고 가정한다. 대기시간은 실행시간에 포함하지 않으며 손실·미완료가 장기 누적되지 않는다. 단위시간의 실행시간을 합하면 평균 실행 동시수는 20×0.3=6개다. 평균이므로 어떤 순간에도 6개를 넘지 않는다는 뜻은 아니다.

0.3초를 점유하는 작업이 200개/초 지속 유입되면 평균적으로 60개의 실행 자리가 필요하다. 한도가 40이고 각 실행이 정확히 0.3초를 점유하는 단순 모형의 최대 완료율은 40/0.3≈133.33개/초다. 이 한도 아래에서 유입 200을 그대로 완료율로 넣어 안정된 평균 동시수를 계산하면 전제가 모순된다. 대기·거절·기한 만료와 상한을 설계해야 한다.

별도 계측 예에서 1,000번의 실행이 각각 0.3초·메모리 0.5GB를 과금 기준으로 사용한다면 1,000×0.3×0.5=150GB·초다. GB는 해당 가상 과금 단위이며 요금·반올림·최솟값·요청비·전송비는 주어지지 않았다. 이 값만으로 청구액이나 전체 서비스 비용을 계산하지 않는다.

11. 완성 실행안 CN-G1

CN-G1은 핵심 예약 원장을 별도 일관된 데이터 서비스에 두고, 요청 처리와 이미 확정된 예약의 알림을 구별한다. 작은 운영팀이라는 가정에서는 관리형 실행환경의 모듈화된 응용을 우선 비교한다. Kubernetes의 배치·정책·복합 실행 요구가 필요하면 아래 구조를 평가한다. 학습용 역할 설명과 제품 도입 권장은 다르다.

적용 후보는 목표 복제 수·이미지 내용·자원 request/limit·준비 조건·연결·권한을 명시한다. Service의 준비 상태와 예외 설정을 확인하고 원장·비밀값·이력은 실행 수명과 분리한다. CN-C1의 목표 6개에 대해 단일 노드 장애 뒤 남은 4개의 부족을 확인하며, HPA의 사용률 분모가 request라는 점과 실제 배치 가능성을 함께 관리한다.

초기화는 startup, 재시작으로 회복할 실행 장애는 liveness, 현재 수용 여부는 readiness로 구별한다. 외부 원장 장애 때 모두 재시작하는 안을 기각하고 대기·보류·원인 복구와 제한된 재시도를 사용한다. 네트워크의 준비 상태만 믿지 않고 진행 연결·업무·종료와 응용의 수락·거부를 대사한다.

함수는 짧고 독립적인 후처리에 사용하되 사용자별 임시 자료를 재사용 환경에 남겨 섞지 않는다. CN-E2의 두 실패 구간을 확인하고 이벤트 ID·외부 결과·미확인·정정의 담당을 연결한다. CN-F1의 평균 6과 순간 최대·한도를 구별한다. 산출물은 실행 책임도·상태표·자원계획·변경/종료 절차·이벤트 대사표이며, 모든 구성은 필요한 최소 범위로 선택한다.

12. 자체 10점 문제와 완성 답안

선언형 오케스트레이션의 목표와 실제 상태, 준비·생존 검사, 서버리스 실행의 의미를 CN-C1·F1으로 설명하시오.

노드별 CPU와 메모리 중 작은 배치 한계를 먼저 구한다. HPA는 해당 request의 분모를 적고 계산 목표·실제 배치·준비·업무 결과를 나눈다.

13. 자체 25점 문제와 완성 설계 답안

예약 서비스의 클라우드 네이티브 실행안 CN-G1을 설계하시오. 구조의 단순성, 선언·자원·검사·변경·서버리스 후처리를 포함하시오.

구성: 필요한 업무 경계 → 실행·상태 → 실패 조건 → 운영 증거.

실행 중 원장 장애가 생길 때 재시작으로 회복되는지 먼저 판단한다. 발송 전 기록과 발송 후 기록의 두 실패를 모두 설명하고 실제 결과 조회·미확인 인계를 설계한다.

14. 자기교정

조건 변경과 해설

CN-C1의 Pod 메모리 요청이 2GiB가 되면? CPU는 4개가 가능하지만 메모리는 노드당 3개다. 두 노드는 합계 6개, 한 노드 장애 뒤 3개만 가능하다. request의 변화와 실제 사용량 감소를 혼동하지 않는다.

함수 평균 실행시간이 0.6초가 되면? 안정된 완료율 20작업/초에서 평균 실행 동시수 12개가 필요하다. 한도와 대기가 이 완료율을 허용하는지 먼저 확인한다. 호출마다 실행환경이 새것일 것이라고 가정해 사용자 상태를 남기지도 않는다.

외부 발송 뒤 완료 기록 전에 끊기면? 이벤트·발송 식별자와 외부 결과를 대조하고 미확인인 경우 담당자에게 인계한다. 반대로 기록을 먼저 하고 발송 전에 끊겨도 누락될 수 있으므로, 단순히 두 동작의 순서를 바꾸는 것을 완전한 해결책으로 제시하지 않는다.

독립 확인: CPU 분모와 상한을 함께 바꾸면

CN-C1의 두 노드와 같은 단일 컨테이너 Pod 4개가 모두 준비돼 있다. 각 request 0.75CPU, 각 실제 사용 0.6CPU, 목표 사용률 50%, 최대 Pod 6개라고 새로 정한다. 누락·허용오차·안정화는 제외한다. 기본 목표와 상한 적용 목표를 계산한다. 별도로 request만 1.5CPU로 바꾸고 같은 4개·사용 0.6을 관측하면 기본 목표와 정상 배치 한계는 어떻게 되는가?

풀이를 닫고 startup·liveness·readiness의 서로 다른 질문, CN-E2의 누락·중복 두 구간, 함수 환경의 재사용과 영속 저장·완전 초기화의 차이를 말한다.

2026-10-05 Kubernetes HPA 공식 문서의 기본식·request 분모와 Probe 공식 문서의 세 목적, AWS Lambda 지침의 재사용·사용자 자료 누출 경계를 직접 대조했다. Kubernetes 문서 상단 Versions 메뉴에는 v1.37이 표시되어 있으며 모든 설치 판본의 기본값이나 실제 클러스터 결과를 검증한 것은 아니다.

근거와 적용 범위

모든 수치·실행안·도식·문제·답안은 자체 교육 자료다. 실제 Kubernetes·함수·배포·장애 시험·독립 감수는 실행하지 않았다.

회독의 핵심

선언·배치·준비·업무 완료는 다르다. 자원 지표의 분모와 실행환경의 수명을 확인하고, 로컬 기록과 외부 효과 사이의 실패를 숨기지 않는다. 컨테이너·오케스트레이터·서버리스는 상태·권한·비용을 없애는 기술이 아니라 책임을 나누어 운영하는 수단이다.

보강 연습 1: 전체 여유가 충분해도 한 Pod가 들어갈 노드는 없을 수 있다

자체 배치 사례에서 기존 실행의 request를 제외한 여유는 노드 A가 CPU 1·메모리 4GiB, 노드 B가 CPU 4·메모리 1GiB다. 새 Pod 하나는 CPU 2·메모리 2GiB를 요청하며 하나의 노드에 배치돼야 한다. 다른 배치 제약·부가자원·init 컨테이너는 제외한다. ‘전체 여유 CPU 5·메모리 5이니 새 Pod 두 개를 배치할 수 있다’는 주장을 판단하라.

free = {"A": (1, 4), "B": (4, 1)}
request = (2, 2)
fits = [name for name, capacity in free.items()
        if all(available >= needed for available, needed in zip(capacity, request))]
assert fits == []
print(f"배치가능노드={fits}")

보강 연습 2: 일반 컨테이너 둘의 CPU request를 함께 계산한다

네 Pod가 모두 준비돼 있고 같은 두 일반 컨테이너를 실행한다. 각 Pod의 응용 컨테이너는 request 0.5CPU·사용 0.6CPU, 보조 컨테이너는 request 0.25CPU·사용 0.05CPU다. HPA는 Pod의 Resource CPU 사용률 목표 50%를 사용한다. Pod 수준 자원 설정·특정 컨테이너만의 지표·init 컨테이너·지표 누락·허용오차·안정화·최소/최대는 이번 기본 계산에서 제외한다.

사용률과 기본 목표 수를 계산하라. 응용의 request만 1CPU로 바꾸고 같은 사용량을 관측하면 결과가 어떻게 달라지는가? 실제 적용 설정에서 보조 컨테이너의 CPU request가 끝내 정의되지 않았다면 이를 0으로 채워 같은 계산을 할 수 있는지도 설명하라.

from fractions import Fraction
from math import ceil

used = Fraction(60, 100) + Fraction(5, 100)
for requested in (Fraction(50, 100) + Fraction(25, 100),
                  Fraction(1) + Fraction(25, 100)):
    utilization = used / requested
    target = ceil(4 * utilization / Fraction(1, 2))
    print(f"사용률={float(utilization * 100):.2f}%, 기본목표={target}")

보강 연습 3: 함수가 끝났어도 사용자 자료와 업무 상태를 다시 확인한다

자체 함수 설계가 전역 변수 lastRecipient와 임시 파일에 이전 사용자의 발송 대상·문안을 저장한다. 다음 호출에 수신자가 없으면 이전 전역값을 사용한다. 개발자는 ‘함수가 한 번 끝나면 실행환경도 사라진다’고 설명했다. 이어서 같은 이벤트 E9를 두 작업자가 동시에 처리하고, 첫 작업자는 외부 발송 뒤 로컬 완료 기록 전에 중단했다고 하자.

사용자 상태의 처리, 두 작업자의 처리권, 외부 발송의 확인을 각각 설계하라. ‘전역 변수를 지우고 로컬 완료 플래그를 넣었으니 정확히 한 번 전달됐다’는 답도 교정하라.