컨테이너와 클라우드 인프라

개발자 laptop에서는 한 process가 local database와 같은 network에 있고 test data도 작기 때문에 timeout, DNS, certificate와 resource limit 문제가 잘 드러나지 않습니다. 운영에서는 여러 instance, load balancer, secret store와 외부 service가 연결되고 부분 장애가 일상적으로 발생합니다. “내 컴퓨터에서 동작함”은 기능 가설의 시작이지 배포 가능성의 증거가 아닙니다.

환경 차이를 줄이려면 source뿐 아니라 dependency lock, runtime version, configuration schema와 build 절차를 version으로 묶어야 합니다. Secret과 환경별 endpoint는 image에 넣지 않고 배포 시 주입하되 누락되면 조용히 기본값으로 production을 향하지 않도록 시작 단계에서 실패시킵니다. 동일 artifact를 staging과 production에 승격하고 차이는 명시된 configuration으로만 남기는 편이 재현과 rollback에 유리합니다.

Container image는 압축된 application 폴더 하나가 아니라 content digest로 연결된 read-only layer와 실행 설정의 묶음입니다. Base image, package 설치와 source 복사를 어떤 순서로 배치하는지에 따라 cache 재사용과 취약점 범위가 달라집니다. Container는 이 image 위에 writable layer와 namespace, resource limit을 더한 실행 instance입니다.

Tag는 사람이 읽기 쉬운 별칭이라 같은 이름이 다른 digest를 가리킬 수 있습니다. 운영 release와 SBOM, signature, scan 결과는 tag가 아니라 immutable digest에 연결해야 합니다. Build stage에는 compiler와 credential이 필요해도 final image에는 실행 binary와 최소 runtime만 복사하고, build secret이 layer history에 남지 않는지 확인해야 공급망 경계를 설명할 수 있습니다.

웹 application이 API와 PostgreSQL을 필요로 할 때 Compose는 service별 image, network, volume과 환경 변수를 한 파일에서 정의해 개발자가 같은 topology를 반복해서 띄우게 합니다. Service name을 DNS로 사용할 수 있지만 `depends_on` 순서만으로 database가 query 가능한 상태까지 기다려 주는 것은 아니므로 health condition과 application retry가 필요합니다.

Volume을 붙였다는 사실도 data 보호를 의미하지 않습니다. Schema migration, backup과 restore는 별도 절차이며 container를 지울 때 named volume이 남는지 명확히 알아야 합니다. Compose는 한 host의 개발과 작은 운영에 유용하지만 여러 node의 scheduling, 자동 복구와 rolling update가 필요하면 orchestrator가 제공하는 더 큰 상태 관리 계약을 검토해야 합니다.

Kubernetes에서 사용자는 특정 container process를 직접 유지하라고 명령하기보다 Deployment의 replica 수와 image 같은 desired state를 API에 저장합니다. Controller는 현재 Pod와 기대 상태의 차이를 반복해서 관찰하고 생성하거나 교체합니다. Node가 사라졌을 때 새 Pod가 다른 곳에서 생기는 것은 이 reconciliation loop의 결과이지 기존 process가 순간 이동한 것이 아닙니다.

K3s는 packaging과 기본 component를 단순화해 설치와 작은 footprint에 유리하지만 Kubernetes의 핵심 API와 운영 책임을 없애지는 않습니다. Resource request, persistent data, network policy, upgrade와 backup은 여전히 설계해야 합니다. 단일 node 실습에서 Pod가 다시 뜨는 것과 node 자체가 사라져도 서비스가 지속되는 고가용성은 구분해야 합니다.

Liveness probe는 process를 다시 시작해야 할 막힘을 찾고 readiness probe는 새 요청을 받을 준비가 됐는지 판단합니다. 시작이 느린 application에는 startup probe가 초기화를 보호할 수 있습니다. Database가 잠시 느리다는 이유로 liveness가 모든 Pod를 재시작하면 오히려 장애를 확대하므로 probe마다 어떤 조치를 유발하는지 기준을 다르게 정해야 합니다.

Rolling update는 새 replica를 조금씩 늘리고 old replica를 줄이지만 새 version의 응답이 업무적으로 옳은지는 자동으로 알지 못합니다. Readiness, error rate와 latency뿐 아니라 migration 호환성과 대표 사용자 결과를 canary에서 확인해야 합니다. Rollback도 image만 되돌리면 끝나는지, 이미 변경한 schema와 message가 구 version에서 읽히는지 사전에 검증해야 합니다.

교육용 보고서 작업은 원본 읽기, 임시 파일 쓰기, 최종 이름 확정의 세 단계라고 가정합니다. 임시 파일을 쓰는 중 컨테이너가 종료되면 다운로드 목록에는 아직 나타나지 않아야 합니다. 재시작한 작업자는 장부를 읽고 미확정 결과만 다시 처리합니다. 임시 파일 이름과 작업 식별자를 연결해야 재시작 후 어느 잔여 파일을 회수할지 판단할 수 있습니다.

반례는 응답을 먼저 성공으로 보내고 나중에 파일을 확정하는 구현입니다. 종료 직전 성공을 받은 사용자는 없는 파일 링크를 갖게 됩니다. 응답 시점과 저장소 확정 시점을 따로 기록하면 probe가 모두 정상이었던 배포에서도 이 오류를 찾을 수 있습니다. 사용자에게 보낸 완료 시각이 결과 확정보다 앞섰는지가 이 사례에서 직접 확인할 불일치입니다.

검증에서는 대기 중, 임시 저장 중, 확정 후라는 서로 다른 지점에서 종료를 주입합니다. 최종 파일의 개수뿐 아니라 내용의 완전성과 장부 상태를 비교합니다. 중복 전달이 발생해도 결과 하나와 일관된 완료 상태가 남아야 합니다. 강제 종료를 피한 정상 경로도 남겨 복구 로직 때문에 원래 작업이 중복되는지 비교합니다.

Kubernetes 배포 상태는 인스턴스 교체의 관찰 자료로 사용하고 작업 장부는 사용자 결과의 자료로 사용합니다. 두 자료의 시각과 작업 식별자를 연결합니다. 인스턴스 수가 목표와 같다는 사실만으로 미완료 보고서가 복구됐다고 결론 내리지 않습니다. 교체 완료 시각 뒤에도 미확정 작업이 남았다면 별도 복구 대상을 기록하고 배포 성공과 구분합니다.

교육용 예약 시스템이 하나의 연락처 문자열을 종류와 값으로 나누려 합니다. 이전 코드는 기존 열만 읽으므로 새 열을 추가한 직후 기존 열을 없애면 되돌리기가 깨집니다. 기존 읽기와 새 읽기를 비교하는 기간을 두고 변환 실패 행을 따로 처리합니다. 연락처 구분을 추측할 수 없는 값은 임의로 이메일로 채우지 않고 검토 대상이라는 상태를 남깁니다.

변환 도중 새 예약이 추가되면 일괄 변환의 시작 시점 이후 행이 빠질 수 있습니다. 처리한 행의 경계와 새 쓰기 경로를 함께 기록합니다. 모든 행을 처리했다는 주장에는 시작 때 센 개수만이 아니라 미변환 행을 다시 조회한 결과가 필요합니다. 변환 진행 중 들어온 예약을 별도 표본으로 넣으면 배치 밖 쓰기 경로의 누락을 발견할 수 있습니다.

반례는 새 버전에서만 테스트하고 배포 도구의 되돌리기 버튼을 복구 계획으로 적는 것입니다. 데이터가 새 의미로만 저장되면 이전 이미지로 돌아가도 해석하지 못합니다. 이전 코드가 새로 쓴 행을 읽는 시나리오를 실제 호환성 검사에 포함합니다. 복구 후보가 구동되는지뿐 아니라 새 행을 수정한 뒤 다시 읽을 수 있는지도 확인해야 합니다.

검증 표는 이전 읽기, 새 읽기, 이전 쓰기, 새 쓰기를 나누고 공존 구간별 허용 조합을 적습니다. 변환 전후의 가명 예약을 같은 업무 질문으로 조회합니다. 값이 같아 보이더라도 검색 누락과 중복 예약 여부까지 확인한 뒤 이전 열 제거를 판단합니다. 각 조합의 실패가 구문 오류인지 값의 의미 손실인지 구분해 필요한 수정 계층을 좁힙니다.

교육용 자료 보관 서비스는 파일과 파일 설명 행을 서로 다른 저장소에 둔다고 가정합니다. 데이터베이스만 복원하면 목록은 보이지만 다운로드가 실패할 수 있습니다. 파일만 복원하면 소유자와 공개 범위를 잃어 권한을 판정할 수 없습니다. 따라서 두 저장소를 독립적으로 성공 처리하지 말고 같은 자료 식별자에 대한 연결을 검사합니다.

훈련에서는 같은 복구 기준 시점의 목록과 파일을 연결해 가명 사용자별 읽기를 확인합니다. 공개 자료와 비공개 자료를 각각 선택하고 내용의 해시와 접근 거절을 검사합니다. 단순한 행 개수 비교는 잘못된 파일 연결이나 권한 누락을 놓칩니다. 거절 사례가 통과하면 복구 중 비공개 자료를 공개로 바꾼 결함도 목록 정상 표시와 별도로 잡습니다.

반례는 복원된 서버가 켜지고 로그인 화면이 보였다는 사실로 복구를 완료하는 것입니다. 이 관찰은 프로세스 시작을 보여 줄 뿐 자료의 완전성을 증명하지 않습니다. 오래된 자료와 가장 최근 허용 시점 자료를 모두 열어 실제 복구 범위를 좁힙니다. 사용자가 기대하는 최신 자료가 없다면 서버 시작 시간이 짧아도 복구 목표를 충족하지 못합니다.

최종 기록에는 사용한 이미지, 백업 식별자, 복원 시작과 종료 시각, 읽기 실패 목록을 남깁니다. 실패한 파일이 있으면 범위를 숨기지 않고 부분 복구로 보고합니다. 다음 훈련에서는 수정한 연결과 권한 조건을 같은 데이터로 다시 확인합니다. 다음 담당자가 같은 백업을 찾아 비교할 수 있도록 기록 위치와 읽기 절차도 함께 제공합니다.