배포 슬롯 만들기
조직에서 배포 전에 테스트하기 위해 격리된 환경에서 웹앱을 실행해야 하는 경우가 많습니다. 또한 사용자에게 영향을 주지 않고 신속하게 배포해야 합니다.
소셜 미디어 시스템에서 웹앱을 배포하는 효율적인 방법으로 슬롯을 사용할지 여부를 결정하려고 한다고 가정합니다. 배포 슬롯이 배포 중 가동 중지 시간을 단축하는지 여부, 롤백을 쉽게 하는지 여부, Azure에서 설정할 수 있는지 여부 등을 확인하려고 합니다.
여기서는 배포 슬롯이 새 코드의 테스트 및 출시에 어떻게 도움이 되는지를 알아봅니다.
배포 슬롯 사용
단일 Azure App Service 웹앱 안에 여러 배포 슬롯을 만들 수 있습니다. 각 슬롯은 해당 웹앱의 개별 인스턴스로, 호스트 이름이 각기 다릅니다. 슬롯마다 웹앱의 다른 버전을 배포할 수 있습니다.
한 슬롯은 프로덕션 슬롯으로, 사용자가 연결할 때 표시되는 웹앱입니다. 이 슬롯에 배포된 앱이 안정적이고 잘 테스트되었는지 확인해야 합니다.
추가 슬롯을 사용하여 새 버전의 웹앱을 호스트합니다. 이러한 인스턴스에 대해 통합 테스트, 승인 테스트, 용량 테스트 등과 같은 테스트를 실행할 수 있습니다. 코드를 프로덕션 슬롯으로 이동하기 전에 모든 문제를 해결합니다. 추가 슬롯이 자체 App Service 인스턴스처럼 동작하므로, 테스트가 프로덕션에서 앱이 실행되는 방식을 보여준다고 확신할 수 있습니다.
새 앱 버전의 테스트 결과가 좋으면 슬롯을 프로덕션 슬롯으로 교환하여 배포합니다. 코드 배포와 달리 슬롯 교환은 즉시 이루어집니다. 슬롯을 교환하는 경우 슬롯 호스트 이름이 교환되며, 프로덕션 트래픽을 새 버전의 앱으로 즉시 전송합니다. 슬롯 교환을 사용하여 배포하는 경우 앱이 부분 배포된 상태로 공용 웹에 공개되지 않습니다.
신중하게 테스트했지만 새 버전에 문제가 있을 경우 다시 슬롯을 교환하여 버전을 롤백할 수 있습니다.
슬롯을 별도의 Azure 리소스로 이해
웹앱에 대해 둘 이상의 배포 슬롯을 사용하는 경우 해당 슬롯이 웹앱의 개별 인스턴스로 처리됩니다. 예를 들어 Azure Portal의 모든 리소스 페이지에 별개로 나열되며, 각각 고유한 URL이 있습니다. 그러나 각 슬롯은 가상 머신 메모리, CPU 및 디스크 공간을 포함하여 App Service 요금제의 리소스를 공유합니다.
배포 슬롯 및 계층 만들기
웹앱이 표준, 프리미엄 또는 격리 서비스 계층의 App Service 계획을 사용하는 경우에만 배포 슬롯이 제공됩니다. 다음 표에는 만들 수 있는 최대 슬롯 수가 나와 있습니다.
| 서비스 계층 | 최대 스테이징 슬롯 수 |
|---|---|
| 무료 | 0 |
| 공유 | 0 |
| 기본 | 0 |
| 표준 | 5 |
| 프리미엄 | 20 |
| 격리 | 20 |
교환 중 콜드 부팅 방지
개발자가 웹앱을 만드는 데 사용하는 대부분의 기술은 최종 컴파일 및 기타 작업이 서버에서 수행되어야 페이지를 사용자에게 제공할 수 있습니다. 이러한 작업은 대개 앱이 시작되고 요청을 받을 때 완료됩니다. 예를 들어 ASP.NET을 사용하여 앱을 빌드하는 경우 첫 번째 사용자가 페이지를 요청할 때 코드가 컴파일되고 뷰가 완성됩니다. 해당 페이지에 대한 후속 요청은 코드가 이미 컴파일되었으므로 더 빠르게 응답을 받습니다.
초기 지연을 콜드 부팅이라고 합니다. 슬롯 교환을 통해 프로덕션으로 배포하여 콜드 부팅을 방지할 수 있습니다. 슬롯을 프로덕션으로 교환하면 작업에서 요청을 사이트의 루트로 전송하므로 앱이 “준비”됩니다. 준비 요청은 모든 컴파일 및 캐싱 작업이 완료되도록 합니다. 교환 후에 사이트는 며칠 동안 배포된 것처럼 빠르게 응답합니다.
배포 슬롯 만들기
슬롯을 만들기 전에 웹앱이 표준, 프리미엄 또는 격리 서비스 계층에서 실행되고 있는지 확인합니다.
Azure Portal에서 웹앱 페이지를 엽니다.
배포 슬롯 창을 선택합니다.
슬롯 추가를 선택합니다.
슬롯을 이름을 지정합니다.
다른 슬롯의 설정을 복제할지 여부를 선택합니다. 복제를 선택하면 지정한 슬롯의 설정이 새 슬롯에 복사됩니다.
참고 항목
설정은 새 슬롯으로 복제할 수 있지만 콘텐츠는 복제할 수 없습니다. 새 슬롯은 항상 콘텐츠 없이 시작됩니다. Git 또는 다른 배포 전략을 사용하여 콘텐츠를 배포해야 합니다. 복제 작업은 구성을 새 슬롯에 복사합니다. 설정을 복제한 후 두 슬롯의 구성을 독립적으로 변경할 수 있습니다.
추가를 선택하여 새 슬롯을 만듭니다. 이제 배포 슬롯 페이지의 목록에 새 슬롯이 있습니다. 슬롯을 선택하여 해당 관리 창을 표시합니다.
슬롯에 액세스
새 슬롯의 호스트 이름은 웹앱 이름과 슬롯 이름에서 파생됩니다. 배포 슬롯 페이지에서 슬롯을 선택하면 이 호스트 이름이 생깁니다.
프로덕션 슬롯에 배포할 때와 같은 방식으로 새 슬롯에 코드를 배포할 수 있습니다. 사용하는 배포 도구 구성에서 새 슬롯의 이름 또는 URL만 대체하면 됩니다. FTP를 사용하여 배포하는 경우 슬롯의 URL 바로 아래에서 FTP 호스트 이름 및 사용자 이름을 확인할 수 있습니다.
새 슬롯은 사실상 호스트 이름이 다른 별개의 웹앱입니다. 따라서 인터넷에서 누구나 해당 호스트 이름만 알면 액세스할 수 있습니다. 슬롯을 검색 엔진에 등록하거나 크롤링된 페이지에서 슬롯에 연결하는 경우를 제외하고, 슬롯은 검색 엔진 인덱스에 표시되지 않습니다. 일반 인터넷 사용자에게는 계속 알려지지 않습니다.
IP 주소 제한을 사용하여 슬롯에 대한 액세스를 제한할 수 있습니다. 슬롯에 대한 액세스를 허용할 IP 주소 범위 목록이나 슬롯에 대한 액세스를 거부할 범위 목록을 만듭니다. 범위 목록은 방화벽에서 설정할 수 있는 허용 범위 및 거부 범위와 같습니다. 이 목록을 사용하여 회사 또는 개발팀에 속한 컴퓨터에만 액세스를 허용할 수 있습니다.