Azure Devops를 통해 단일 인스턴스에서 DownTime 없이 IIS로 배포하는 방법 -보통

고수만/필드에서 써먹은 것들

Azure Devops를 통해 단일 인스턴스에서 DownTime 없이 IIS로 배포하는 방법 -보통

JumBack2 2025. 1. 6. 17:49

시작 제목부터 뭔가 어려운 말들이 써있어서 대단한 내용인가 싶지만 별거 없다.

예전에는 모든 사이트들이 점검을 걸고 웹이나 어플의 업데이트를 진행하였지만 지금은 사용자들이 거의 느끼지 못한다.

거의 게임 정도나 점검 페이지를 볼 수 있을까?

바로 무중단 배포가 대부분 구축이 되었기 때문이다.

( 다운 타임 없이 배포 = Zero DownTime 배포 = 무중단 배포 )

무중단 배포에는 다양한 배포 방법이 존재하고

우리가 알아 볼 것은 그 중 블루 그린 배포이다.

<블루 그린 배포(Blue Green Deployment)는 무중단 배포 전략(Zero DownTime Deployment Strategy) 중 하나이다.

대표적으론 Blue Green, Rolling, Canary 배포 등이 있다.>

1. Blue Green 배포란?

만약 우리가 pc로 무언가를 요청을 한다면 서버는 그 요청에 대한 응답을 반환해준다.

응답은 성공이라는 결과 코드일 수도 있고 우리가 원하는 결과 값일 수도 있다.

그런데!! 우리에게 결과를 알려주는 서버가 변신 중이라면 어떻게 해야될까?

어렷을 때 보았던 만화를 생각해보자.

주인공이 변신이나 합체 중에는 대응을 할 수가 없다. 그래서 원래 악당들이 기다려주는 것이 국롤인데

아래의 무자비한 만화는 공격을 한다.

서버가 변신을 위해 배포 중이면 당연히 대응을 못 한다!!

그렇다면 어떻게 해결을 할까??

그것은 바로!

간단하게 서버를 2개 만들면 된다! (가격도 2배!!)

하나가 변신 중일 때 기존 서비스를 제공하여 가용성(availability) 를 높이면 된다.

이것이 Blue Green 배포 전략의 핵심이다.

2.Blue Green 배포 전략의 단점

그런데 문제는 무중단 배포전략을 사용하는데 비용이 더 든다는 것이다!

아니 그런데 말이 쉽지. 요즘 같은 불경기에 자원을 아껴도 모자를 마당에

인스턴스를 2배라니..

예를 들어 블루 그린 배포를 생각해보자.

기존의 인스턴스를 2개 이용 중 이라고 가정하면

2개의 인스턴스가 블루(구버전) 추가적으로 2개의 인스턴스 그린(신버전)이 필요하다.

리소스가 2배가 든다는 것이다!

이것은 생각보다 큰 단점이다.

그럼 인프라 환경 추가 없이 무중단 배포 전략을 사용할 순 없을까?

물론 존재한다. 여러가지 방법으로!

그래서 여러 방법들 중 ARR을 사용하여 한정된 리소스를 활용하여 Blue Green 배포에 대해 이야기 하려고 한다.

인프라 리소스 추가가 부담이라면 롤링배포로 그냥 인스턴스 2개를 순차적으로 업데이트 하면 다운타임 없이 가능하지 않나? 라는 나쁜 말은 하지 말도록 하자.

ARR을 이용한 블루 그린 배포와 롤링배포는 한정적인 리소스에서 사용하면 좋다는 공통점은 존재하나 롤백의 속도나 테스트 환경의 독립성 등 차이점들이 존재하기 때문이다. 이는 추후 배포 전략에 대한 글에서 이야기 하겠다.

3. 단일 인스턴스에서 IIS의 Application Request Routing를 활용해 Blue Green 배포 구성 방법

오늘 이야기 해보고 싶은 것은 IIS의 추가 기능을 사용해 웹서버를 여러 개 띄워 단일 인스턴스에서 블루 그린 배포를 구현하는 것이다.

1. IIS 추가 모듈 설치

필수조건:

IIS 7 이상

ARR(Application Request Routing) 과 URL Rewrite 모듈을 추가로 설치 해줘야 한다.

두 모듈을 모두 설치하게 되면 기존의 IIS 관리자에 Server Farms가 추가 된 것을 볼 수 있을 것이다.

2. Blue Green 웹 서버 생성

우선 사이트에 blue와 green의 웹서버를 만들어 준다. 그리고 기존 80 포트 이외의 다른 포트로 두 웹서버를

바인딩 해준다. 기존 80포트는 진입점 역할을 할 예정이다.

3. 도메인 호스트 설정

그리고 해당 사이트의 호스트를 만들어서 Server Farm이 생성될 때 각 고유의 호스트 이름이 서버 팜에서 서버 주소의 열할을 할 수 있도록 설정해 줘야 된다.

127.0.0.1 testweb
127.0.0.1 testweb-blue
127.0.0.1 testweb-green

4. Server Farm 생성

IIS의 Server Farm은 ARR(Application Request Routing) 을 추가하면 나오는데 ARR은 요청에 따라 하위 서버들에

정해진 규칙에 따라 로드벨런싱을 해주는 역할을 한다.

이게 가장 중요한 핵심인데 IIS 자체 내에서 로드벨런싱이 가능하기 때문에 사용 불가하거나 사용을 원치 않는 서버는 라우팅에서 제외함으로서 그린 서버에만 라우팅 되게 만드는 것이다.

웹서버는 두 개를 띄워놓지만 원하는 서버만 요청이 접근 가능하게 만드는 것이다.

5. Farm 하위 서버 생성

하위 서버는 기존에 생성했던 서버이름으로 각각 port까지 맞추어 준다.

위와 같이 두개의 서버가 준비되었다면 그다음은 건강 확인이다.

6. Health Checker 설정

안부는 어떤 사람이 탈 없이 편안하게 지내는지 그렇지 않은지에 대한 소식. 또는, 인사로 그것을 전하거나 묻는 일

우리는 자고로 동방 예의지국이라 예로부터 웃어른들의 안부와 건강을 묻곤 했는데

대상의 상태가 어떠한지 잘 지내는지의 기초는 바로 건강

건강이 무언가의 상태를 판가름 하는데 동서금론을 막론하고 가장 중요한 것이다. (여러분도 건강을 유의하도록 하자.)

따라서 우리도 사용하는 웹서버의 건강을 체크하여아 한다.

IIS의 Health Test는 웹 서버의 안부를 묻고 건강하지 않으면 사용 불가라 판단하고 라우팅에서 제외해버리는 역할을 한다.

Health Test에 설정 된 url은 Interval에 설정된 텀 만큼 반복적으로 요청 콜을 보내 Health Check를 하게 된다.

url 경로에 대한 응답 값에 up이라고 오는 서버만 정상 체크로 인지하고 라우팅을 이어 나갈 것이다.

up이 아닌 서버는 라우팅에서 제외된다.

어플리케이션에 api/healthcheck 라는 엔드포인트를 만들어 해당 어플리케이션 하위에 있는 health.html 파일 내의 text를 리턴하도록 만들어 준다.

health.html 에는 up/down 중 하나만 text로 가지고 있고 활성화 할 서버의 html안에만 up을 넣어주고 비활성화 서버의 html의 text는 down으로 설정해준다.

그리고 response match에 up이라는 text를 넣어 up만 체크가 되도록 만든다.

7. URL Rewrite 설정

IIS에서 요청 콜이 들어오면 기본 80포트로 들어오게 된다.

그러나 우리는 웹 서버를 8001 , 8002 로 설정해 놓았기 때문에 URL를 다시 재작성 해줘야 한다.

해당 내용은 URL rewrite 기능으로 인바운드 규칙을 잡아서 재설정 해준다.

8. Azure Devops에 Blue Green Switching 명령 추가

위 의 설정들이 모두 끝났다면 이제 실제로 Devops에 설정을 추가하여 실제 배포 시에 블루 그린 스왑이 일어나도록

파이프라인을 구축해줘야 한다.

여기서 Azure Devops 파이프라인을 구성하는 것을 설명하진 않겠다.

다만 배포가 일어나는 App Deploy 앞에는 어느 웹 서버가 live 상태인지 확인하는 작업이 필요하다.

그래서 Powershell 명령어를 통하여 서버의 up/down 상태를 확인해 live와 staging 서버를 먼저 구분한다

아래는 prepare 작업으로 서버 구분을 하는 예시 코드이다.

$bluePath = "c:/testweb-blue/health.html"
$greenPath = "c:/testweb-green/health.html"

if (-not(Test-Path -Path $bluePath -PathType Leaf)) {
      Set-Content -Path $bluePath -Value 'up'
}

if ((Get-Content $bluePath) -contains "up") {
    $Live = "blue"
    $Staging = "green"

} else {

    $Live = "green"
    $Staging = "blue"

}

그리고 App Deploy로 down 서버에 배포를 한다음

배포가 잘 마무리 되었는지 확인하면서 워밍업을 수행하는 코드이다.

현재 staging 서버를 확인 후 응답 속도를 만족할 때까지 반복적으로 http 요청을 보낸다.

요청이 설정 시간보다 짧으면 그 다음 단계로 넘어간다.

$minTime = 400
$instanceToWarm = 'testweb-$(Staging)'
$warmUpPath = '$(HealthCheckPath)'
$serverFarmName = 'testweb'

# Determine the port of the instance we want to warm up
$port = if ($instanceToWarm -match "blue") {
    8001
} else {
    8002
}

# The path we'll use to warm the instance up
$stagingSite = "http://${serverFarmName}:${port}/${warmUpPath}"

# Loop until we have a satisfactory response time
Do {
    $time = Measure-Command {
        $res = Invoke-WebRequest $stagingSite -UseBasicParsing
    }
    $ms = $time.TotalMilliSeconds
    
} While ($ms -ge $minTime)

위에서 배포된 스테이징 서버가 잘 배포되어 응답한다는 것을 확인 했기 때문에 이제 스왑을 해줄 차레이다.

마지막으로 스위칭 하는 명령어이다.

기존의 비활성 서버를 up 시키고 활성 서버를 down 시키는 것으로 스위칭을 한다.

Set-Content -Path 'c:\testweb-$(Staging)\health.html' -Value 'up'
Set-Content -Path 'c:\testweb-$(Live)\health.html' -Value 'down'

4.IIS ARR 방식의 문제점과 한계

일반적인 인프라 이중화를 통한 블루 그린 배포 파이프라인 대신 IIS 기능을 사용하여 블루 그린 배포 파이프라인을 만들었지만 당연히 장점만 있는 것은 아니다.

첫째. 모든 요청이 ARR를 거치게 만들어져 요청에 대한 오버헤드가 발생한다.기존에는 IIS에 로드벨런싱이 없었지만 로드벨런싱을 하기 위해선 모든 요청을 검사를 해야한다. 당연히 느려질 수 밖에 없다. 네트워크 관련하여 Latency가 생길 수 밖에 없으며 CPU 사용량 역시 증가할 수 있다.

물론 일반 사용에는 느끼지 못할 정도의 크기이겠지만 고성능. 대규모 트레픽의 경우 적합하지 않을 수 있다.또한 부하가 많은 환경에선 성능 병목이 발생 할 수도 있다.

둘째. 리소스의 충돌 가능성하나의 인스턴스에 두 개의 웹서버를 띄워 놓는 것이기 때문에 만약 한쪽의 서버가 많은 리소스를 사용한다면 다른 환경에 영향을 줄 수도 있다. 예를 들어 사용하지 않는 블루 서버에 엄청 큰 리소스를 잡아먹는 버전이 배포되었다면 혹은 메모리를 갈아먹는 버그 버전이 배포 되었다면 사용 중인 그린 서버가 느려지거나 문제가 생길 수 있다.

셋째. 헬스 체크의 한계IIS 내의 로드벨런싱을 사용하고 문자열 매칭으로 판다하기 때문에 복잡한 어플리케이션 상태나, CPU 사용률 , DB 연결 상태 등을 기반으로 상태 판단이 어렵다.

따라서 ARR를 사용한 무중단 배포 파이트라인 구성은 한정적인 리소스 환경에서 구성을 해 사용하는 것이 바람직해 보이며 대규모 환경이나 안정적인 배포를 원한다면 기존의 인프라 이중화 파이프라인으로 구성하는 것이 적합해 보인다.