클라우드 네이티브 환경에 맞는 소프트웨어 설계하기

필요한 동작을 정하세요

클라우드 네이티브 방식은 퍼블릭, 프라이빗, 하이브리드 환경에서 반복 가능한 개발과 운영을 지원합니다. CNCF는 변화하는 동안에도 관리하고 관찰할 수 있으며 회복력을 유지하는 시스템을 강조합니다. 컨테이너와 오케스트레이션은 이 접근을 지원할 수 있습니다. 하지만 그것만으로 모든 특성이 갖춰지지는 않습니다.

가상의 보고서 서비스에서 시작해 보세요. AI 도구가 엔드포인트, 워커, 컨테이너 이미지를 만듭니다. 시연에서는 올바른 PDF가 생성됩니다. 프로덕션에 들어가기 전에 팀은 다른 질문에 답해야 합니다. 작업 도중 플랫폼이 워커를 교체하면 어떻게 될까요?

이는 인프라 문제인 동시에 애플리케이션 설계 문제입니다. 다시 시작하면 프로세스는 복구되지만 미완료 작업은 잃을 수 있습니다.

프로세스와 영속 상태를 분리하세요

프로토타입은 대기 중인 작업과 완성된 보고서를 컨테이너 디스크에 둡니다. 컨테이너를 교체하면 둘 다 사라질 수 있습니다. 워커를 늘려도 어느 워커가 요청을 받는지에 따라 다른 응답이 나올 수 있습니다.

수정한 설계는 영속적인 작업 저장소와 승인된 객체 저장소를 사용합니다. 요청이 작업 식별자를 기록합니다. 워커는 작업을 가져와 결과를 만들고 결과의 위치를 기록합니다. 사용자가 보고서를 다운로드할 때도 접근 검사는 적용됩니다.

비밀 정보는 이미지 밖에 두세요. 승인된 비밀 정보 시스템으로 제공하세요. 어떤 구성 변경에 새 릴리스나 프로세스 재시작이 필요한지 기록하세요.

워커를 추가하기 전에 재시도를 설계하세요

워커가 PDF를 저장한 뒤 작업 완료를 확인하기 전에 멈췄다고 가정해 보세요. 큐가 작업을 다시 전달합니다. 두 번째 시도가 고객에게 다시 요금을 청구하거나 서로 충돌하는 완료 메시지를 보내서는 안 됩니다.

적절한 경우 멱등성을 갖춘 작업을 사용하세요. 같은 논리적 요청을 반복해도 의도한 효과가 유지되어야 합니다. 안정적인 요청 식별자를 정하고 결과를 영속적으로 기록하며 각 실패 지점에서의 동작을 확인하세요. AWS는 안전한 재시도 지침에서 이 기법을 설명합니다.

재시도에도 한도가 필요합니다. 시간 제한, 재시도 횟수 제한, 반복 요청이 동시에 몰리지 않게 하는 지연을 사용하세요. 실패한 작업을 무한히 재시도하지 말고 조사할 수 있도록 보존하세요.

원하는 상태를 검토할 수 있게 하세요

선언적 구성은 의도한 배포 상태를 명시합니다. 컨트롤러는 그 상태를 유지하도록 작동합니다. 예를 들어 Kubernetes Deployment는 애플리케이션 복제본과 통제된 업데이트를 관리합니다. 애플리케이션 자체는 여전히 교체를 올바르게 처리해야 합니다.

인프라와 애플리케이션 구성의 버전을 관리하세요. 일반적인 소프트웨어 제공 프로세스로 변경을 검토하세요. 실제 작업 완료, 큐 대기 시간, 실패, 의존 서비스의 한도를 관찰하세요. 프로세스가 실행 중이어도 보고서를 만들지 못할 수 있습니다.

팀이 운영할 수 있는 플랫폼을 선택하세요

클라우드 네이티브라고 해서 모든 애플리케이션을 마이크로서비스로 바꿔야 하는 것은 아닙니다. 관리형 런타임에서 실행하는 모듈형 애플리케이션도 요구사항을 충족할 수 있습니다. 서비스가 늘면 인터페이스, 배포 결정, 운영 작업도 늘어납니다.

개발 에이전트에게 실제 플랫폼 계약을 제공하세요. 지원 런타임, ID 방식, 데이터 서비스, 배포 규칙, 필수 증거를 포함하세요. 성공하는 요청과 함께 중단 및 교체 동작도 테스트하세요. 가용성과 실패 경계에서 계속 학습하세요.