클라우드에서 애플리케이션 배포

9분

클라우드 애플리케이션을 디자인하고 개발한 후에는 애플리케이션을 배포 단계로 이동하여 고객에게 릴리스할 수 있습니다. 배포 프로세스는 여러 단계로 구성될 수 있으며, 각 단계에서는 애플리케이션의 목표가 충족되는지 확인하는 일련의 검사가 포함됩니다.

프로덕션 환경에 클라우드 애플리케이션을 배포하기 전에, 애플리케이션을 필수 및 권장 모범 사례 목록과 대조 평가하는 데 도움이 되는 검사 목록을 준비해 두는 것이 좋습니다. 예를 들어 AWS 및 Azure의 배포 검사 목록을 사용할 수 있습니다. 많은 클라우드 공급자는 Azure의 이 문서와 같이 배포에 도움이 되는 포괄적인 도구 및 서비스 목록을 제공합니다.

배포 프로세스

클라우드 애플리케이션의 배포는 앱 개발 종료시점부터 시작하여 프로덕션 리소스에 애플리케이션을 릴리스하는 시점까지 이어지는 반복적인 프로세스입니다.

코드 배포 프로세스.

그림 1: 코드 배포 프로세스

일반적으로 클라우드 개발자는 애플리케이션을 다음과 같이 다양한 단계에 파이프라인 방식으로 배포하기 위해 여러 버전의 애플리케이션이 동시에 실행되도록 유지합니다.

테스트
준비
프로덕션

각 단계의 리소스와 구성이 동일한 것이 가장 이상적입니다. 그러면 개발자가 애플리케이션을 테스트 및 배포하고, 환경 및 구성의 변화로 인해 불일치가 발생할 가능성을 최소화할 수 있습니다.

파이프라인 애플리케이션 변경

위의 그림처럼 일반적인 Agile 애플리케이션 개발 시나리오에서는 일종의 이슈 추적 메커니즘을 사용하여 이슈와 버그를 해결하는 엔지니어와 개발자들이 애플리케이션을 유지 관리합니다. 코드 변경 내용은 코드 리포지토리 시스템(즉, svn, mercurial 또는 git)을 통해 유지 관리되며, 코드 릴리스를 위해 별도의 분기가 유지됩니다. 코드 변경, 검토 및 승인을 통과한 후에는 코드를 테스트, 준비 및 프로덕션 단계로 전달할 수 있습니다. 이 작업은 다음과 같은 여러 가지 방법으로 수행할 수 있습니다.

사용자 지정 스크립트: 개발자는 사용자 지정 스크립트를 사용하여 최신 버전의 코드를 가져온 다음, 특정 명령을 실행하여 애플리케이션을 빌드하고 프로덕션 상태로 전환할 수 있습니다.

미리 준비된 가상 머신 이미지: 개발자는 애플리케이션을 배포하는 데 필요한 모든 환경과 소프트웨어가 포함되어 있는 가상 머신을 프로비저닝하고 구성할 수도 있습니다. 구성이 끝나면 가상 머신의 스냅샷을 작성하여 가상 머신 이미지로 내보낼 수 있습니다. 이 이미지를 다양한 클라우드 오케스트레이션 시스템에 제공하여 자동으로 배포하고 프로덕션 배포에 적합하도록 구성할 수 있습니다.

연속 통합 시스템: CI(연속 통합) 도구를 사용하여 프로덕션 인프라를 구성하는 다양한 머신에서 완료해야 하는 작업(예: 리포지토리에서 최신 버전 검색, 애플리케이션 이진 파일 빌드, 테스트 사례 실행)을 자동화하면 배포와 관련된 다양한 작업을 간소화할 수 있습니다. 인기 있는 CI 도구로는 Jenkins, Bamboo 및 Travis가 있습니다. Azure Pipelines는 Azure 배포에 사용하도록 설계된 Azure 관련 CI 도구입니다.

가동 중지 시간 관리

애플리케이션의 특정 부분을 변경하면 애플리케이션의 백 엔드에 변경 내용을 적용하기 위해 애플리케이션 서비스의 일부 또는 전체를 종료해야 합니다. 개발자는 일반적으로 애플리케이션을 사용하는 고객의 불편을 최소화하기 위해 특정 시간을 예약해야 합니다. 연속 통합을 위해 디자인된 애플리케이션은 서비스 중단을 최소화하면서 또는 중단 없이 프로덕션 시스템에서 이러한 변경 작업을 실시간으로 수행할 수 있습니다.

중복성 및 내결함성

애플리케이션 배포 모범 사례는 일반적으로 클라우드 인프라가 항상 작동하는 것이 아니라 언제든지 사용할 수 없게 되거나 변경될 수 있다고 가정합니다. 예를 들어 IaaS 서비스에 배포된 가상 머신은 SLA 유형에 따라 클라우드 공급자의 재량대로 종료되도록 예약할 수 있습니다.

애플리케이션은 데이터베이스, 스토리지 엔드포인트 등의 다양한 구성 요소에 대해 하드 코딩을 수행하거나 정적 엔드포인트를 가정하지 않아야 합니다. 잘 설계된 애플리케이션이란 서비스 API를 사용하여 동적으로 리소스를 쿼리 및 검색하고 연결하는 애플리케이션입니다.

예고 없이 리소스 또는 연결의 치명적 오류가 발생할 수 있습니다. 중요한 애플리케이션은 이러한 오류를 예측하여 설계해야 하며 장애 조치(failover) 중복성을 구현해야 합니다.

많은 클라우드 공급자가 데이터 센터를 지역 및 영역에 디자인합니다. 지역은 완전한 데이터 센터가 있는 특정 지리적 현장이고, 영역은 데이터 센터 내에서 내결함성을 위해 격리된 개별 섹션입니다. 예를 들어 데이터 센터 내에 있는 영역마다 별도의 전원, 냉각 및 연결 인프라를 구축하면 한 영역의 오류가 다른 영역의 인프라에 영향을 주지 않습니다. 일반적으로 클라우드 서비스 공급자는 고객과 개발자가 이 격리 속성을 활용할 수 있는 애플리케이션을 디자인하고 개발할 수 있도록 지역 및 영역 정보를 제공합니다.

따라서 개발자는 여러 지역 또는 영역의 리소스를 사용하도록 애플리케이션을 구성하여 애플리케이션의 가용성을 개선하고 영역 또는 지역에서 오류가 발생하더라도 서비스가 중단되지 않도록 보장할 수 있습니다. 개발자는 여러 지역 및 영역의 트래픽을 라우팅하고 분산할 수 있는 시스템을 구성해야 합니다. 또한 요청이 시작된 위치에 따라 각 영역의 특정 IP 주소에 대한 도메인 조회 요청에 응답하도록 DNS 서버를 구성할 수 있습니다. 이렇게 하면 클라이언트의 지리적 근접성에 따라 부하를 분산할 수 있습니다.

프로덕션 환경의 보안 강화

퍼블릭 클라우드에서 인터넷 애플리케이션을 실행할 때는 신중을 기해야 합니다. 클라우드 IP 범위는 주요 공격 대상이 되는 잘 알려진 위치이므로, 엔드포인트와 인터페이스가 안전하게 보호되도록 클라우드에 배포된 모든 애플리케이션이 모범 사례를 준수해야 합니다. 다음은 준수해야 하는 매우 기본적인 원칙입니다.