EMD Blog

[GCP] Compute Engine에 대해 알아보자(3) - 스테이트풀 MIG/디스크 구성 본문

Public Cloud/GCP

[GCP] Compute Engine에 대해 알아보자(3) - 스테이트풀 MIG/디스크 구성

EmaDam 2022. 1. 27. 21:24

이전 게시글에서 스테이트리스를 구성했으니 이제 스테이트풀 구성을 해보도록 하자.

실수로 윈도우 인스턴스로 구성한다는 것을 리눅스 인스턴스로 구성해버리는 바람에 다음 포스팅에서 리소스를 다시 정리했습니다. 

 

2022.02.16 잘못 된 내용 확인 후 수정 하였습니다. 

스테이트풀 MIG

스테이트풀은 간단하게 말하면 인스턴스가 재생성되더라도 상태가 유지되도록 하는 MIG 구성이다. 상태가 유지되는 대신 오토스케일링을 지원하지 않기 때문에 일괄 작업이나 데이터 베이스, 모놀리식 어플리케이션 등에 주로 사용된다. 

 

참고로 MIG라면 재생성이나 자동 복구 시 이름은 유지되니 이름을 고정하고 싶은 경우라면 스테이트풀로 구성할 필요가 없으며, IP를 고정하고 싶은 경우에도 고정 IP를 따로 설정할 수 있기 때문에 스테이트풀 구성이 필수는 아니다. 

 

스테이트풀의 모든 내용을 적으면 내용이 너무 많아지니 자세한 설명이 궁금하면 이 문서를 참고해보자. 

 

기본 사용법

MIG를 스테이트풀 방식으로 구성하기 위해서는 기존 MIG 생성에서 두 가지를 추가로 구성하면 된다. 

- 스테이트풀 정책

- 인스턴스별 구성

참고로 스테이트리스 MIG도 위 구성을 추가하면 스테이트풀 MIG가 된다. 그럼 스테이트풀 정책과 인스턴스별 구성은 무엇일까? 스테이트풀 정책은 MIG에서 생성되는 모든 인스턴스에 적용될 보존 항목을 정의한 것이고 인스턴스별 구성 특정 인스턴스를 지정해 보존될 항목을 설정한 것이다. 내용을 들으면 감이 왔겠지만 공통적으로 보존해야할 것들은 스테이트풀 정책으로 구성해야할 것이고, 인스턴스 별로 보존 항목이 다른 부분이 있다면 인스턴스별 구성으로 보존 항목을 설정해야 할 것이다. 

 

그럼 바로 스테이트풀 구성 해보도록 하자. 스테이트풀 정책이든 인스턴스별 구성이든 보존하고 싶은 항목을 설정한다고 했었다. 그 말은 항목별로 보존여부를 설정해야 한다는 뜻이다. 

먼저 스테이트풀 정책으로 디스크를 보존하도록 설정해보자. 스테이트풀은 이전에 생성된 MIG에 적용할 것이다.

gcloud compute instance-groups managed updatea 명령어

gcloud compute instance-groups managed update study-managed-instance-group \
--zone=asia-northeast3-a \
--stateful-disk device-name=study-web-dev-2,auto-delete=on-permanent-instance-deletion

 

instance-groups managed update 명령어를 보면 스테이트풀 디스크를 구성하였다. 스테이트풀 디스크를 구성하기 위해서는 디스크명과 삭제 시 디스크를 어떻게 할 것인지에 대한 것만 지정해주면 된다. 디스크명은 인스턴스 템플릿에서 지정한 디스크 명과 동일하게 지정해주고, auto-delete는 두 가지 옵션이 있으니 하나를 선택하면 된다. 

never : 디스크를 절대로 삭제하지 않음. 

on-permanent-instance-deletion : 인스턴스를 수동으로 삭제하거나 그룹 크기를 줄일때 삭제함.

auto-delete를 지정하지 않으면 never가 적용된다. 위의 경우 on-permanent-instance-deletion를 지정했는데, 나중에 삭제하는 것을 잊어 버릴까봐 지정한 것이다. (디스크는 구성하면 사용하지 않더라도 무조건 과금된다.) 일반적인 경우라면 never를 사용하도록 하자. 어차피 디스크는 수동으로도 삭제 가능하니 안전하게 유지해서 나쁠 것이 없다.

 

위처럼 정책을 구성하면 내부적으로는 생성되어 있는 인스턴스들 디스크의 autoDelete 플래그(instances.disks[].autoDelete) 값을 변경한다. 이 동작은 비동기 방식으로 진행된다. 자세한 내용이 궁금하다면 이 문서를 참고해보자. 

 

여기서 왜 오토스케일링 설정을 삭제(또는 중지)하지 않고도 스테이트풀 구성이 정상적으로 적용되는지 의문이 들 수 있다. 오토스케일링 설정이 되어 있는 상태에서 스테이트풀 구성으로 업데이트 하면 자동으로 오토스케일링이 중지 된다. 중요한 것은 설정자체가 off되는 것이 아니고 그냥 작동을 안하는 것이다. 

 

스테이트풀 구성이 잘 적용되었는지 확인하고 싶다면 아래 명령어를 사용해 확인해 볼 수 있다. 

gcloud compute instance-groups managed describe 명령어

$ gcloud compute instance-groups managed describe study-managed-instance-group \
--zone asia-northeast3-a

...
statefulPolicy:
  preservedState:
    disks:
      study-web-dev-2:
        autoDelete: ON_PERMANENT_INSTANCE_DELETION
...

 

만약 정말로 디스크가 유지되는 지 궁금하다면 아래처럼 디스크에 파일 하나를 만들고 인스턴스 재생성 replace시켜 파일이 유지되는지 확인하면 된다.

gcloud compute scp 명령어

$ touch ~/test.txt
$ gcloud compute scp ~/test.txt study-web-dev-vvxv:~/ --tunnel-through-iap
No zone specified. Using zone [asia-northeast3-a] for instance: [study-web-dev-vvxv].
test.txt                                             100%   10     0.1KB/s   00:00

인스턴스에 접속해서 파일을 생성해도, 되고 위처럼 로컬머신에서 파일을 만든 후 SCP로 전송해도 된다. 참고로 SCP 전송 시 업로드할 디렉터리에 권한이 있어야 한다. 업로드가 잘 되었다면 인스턴스 접속 후 확인해보자.

$ gcloud compute ssh study-web-dev-vvxv --tunnel-through-iap
$ ls
test.txt

test.txt 파일이 잘 업로드 되었다. 이제 인스턴스를 다시 생성해보자.

gcloud compute instance-groups managed rolling-action replace 명령어

$ gcloud compute instance-groups managed rolling-action replace study-managed-instance-group \
--zone=asia-northeast3-a

Updated [https://www.googleapis.com/compute/v1/projects/project/zones/asia-northeast3-a/instanceGroupManagers/study-managed-instance-group].

roling-action에는 업데이트에 대한 다양한 명령어가 존재하는데 replace는 인스턴스를 교체해버리는 옵션이다. 

Updated가 출력됐다고 해서 바로 교체된 것은 아니고 교체가 시작됐다는 뜻이니 조금 기다렸다가 인스턴스가 생성된 것을 확인해보자.

$ gcloud compute instances list
NAME                ZONE               MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
study-web-dev-vvxv  asia-northeast3-a  f1-micro                   10.178.0.8   34.64.150.247  RUNNING

다시 생성된 것을 확인했으면 재접속 후 파일이 남아있는지 확인해보자.

$ gcloud compute ssh study-web-dev-vvxv --tunnel-through-iap
$ ls
test.txt

파일이 그대로 있는 것을 확인할 수 있다.

 

참고로 인스턴스를 교체할 때는 이름을 그대로 가져가는 방법과 이름을 바꿔버리는 방법이 있는데 기본적으로 스테이트풀 디스크를 구성하면 이름을 그대로 유지하는 것이 기본값이다. 만약에 이름을 바꿔서 교체하려하면 에러가 발생하는데 이때 아래 명령어로 업데이트를 자동에서 수동으로 변경해주면 된다. (꼭 이름을 바꿔야되는 상황이 아니라면 그냥 하지말자.)

gcloud compute instance-groups managed rolling-action stop-proactive-update 명령어

$ gcloud compute instance-groups managed rolling-action stop-proactive-update study-managed-instance-group \
--zone=asia-northeast3-a

 

이제 VM별로 스테이트풀 구성을 해야하는데 그 전에 스테이트풀 정책으로 설정해둔 디스크의 스테이트풀 구성을 삭제하자. 참고로 스테이트풀 정책에서 디스크의 스테이트풀 구성을 제거하더라도 인스턴스별 구성에 스테이트풀 구성이 남아있다면 해당 디스크는 스테이트풀로 유지되니 주의하자. 즉, 인스턴스별 구성이 우선순위가 더 높다.

$ gcloud compute instance-groups managed update study-managed-instance-group \
--zone=asia-northeast3-a \
--remove-stateful-disks=study-web-dev-2

위 처럼 하면 디스크가 다시 스테이트리스가 된다. 이 동작은 스테이트풀 구성을 할 때와 마찬가지로 중단없이 비동기 방식으로 진행된다. 이제 다시 위처럼 테스트를 해보자. 파일을 만든 뒤 인스턴스를 재시작 시키면 파일이 초기화된 것을 볼 수 있을 것이다. 

 

이제 스테이트풀 정책에서 디스크의 스테이트풀 구성을 제거했으니 인스턴스 별로 디스크 스테이트풀 구성을 진행해보자. 참고로 Google에서는 인스턴스 별 구성 보다는 스테이트풀 정책을 사용하는 걸 권장하고 있으니 참고하자. 

 

인스턴스 별로 디스크의 스테이트풀 구성을 진행하기 위해서는 이미 생성된 디스크가 있어야 한다. 디스크를 생성하면서 스테이트풀로 구성하는 것이 아니니 주의하자. 디스크를 가져오기 위해 독립형 인스턴스를 하나 생성하자. 

 이미 우리가 MIG로 생성한 인스턴스가 존재하지만 디스크를 분리하려면 인스턴스를 중지해야하고 현재 MIG 구성에서는 인스턴스를 중지하면 해당 인스턴스가 재생성(자동복구) 된다. 그래서 여기서는 독립형 인스턴스를 하나 만들어서 진행한다. (health check 주기를 늘려도 상관없다.)

인스턴스를 생성하려면 아래 명령어를 사용하자. 

gcloud compute instances create 명령어

$ gcloud compute instances create study-web-dev-temp \
--zone=asia-northeast3-a \
--machine-type=f1-micro \
--image=ubuntu-minimal-2004-focal-v20211209 \
--image-project=ubuntu-os-cloud \
--boot-disk-size=10GB \
--boot-disk-type=pd-balanced \
--boot-disk-device-name=study-web-dev-temp

NAME                ZONE               MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP    STATUS
study-web-dev-temp  asia-northeast3-a  f1-micro                   10.178.0.30  34.64.245.105  RUNNING

인스턴스를 생성했으니 디스크를 분리해보자. 디스크를 분리하려면 먼저 인스턴스를 중지시켜야 한다. 인스턴스 중지는 아래 명령어를 사용하면 된다.

gcloud compute instances stop 명령어

$ gcloud compute instances stop study-web-dev-temp \
--zone=asia-northeast3-a

Updated [https://compute.googleapis.com/compute/v1/projects/project/zones/asia-northeast3-a/instances/study-web-dev-temp].

인스턴스가 잘 중지되었으면 아래 명령어로 디스크를 분리하자. 

gcloud compute instances detach-disk 명령어

$ gcloud compute instances detach-disk study-web-dev-temp \
    --disk=study-web-dev-temp
    
Updated [https://www.googleapis.com/compute/v1/projects/project/zones/asia-northeast3-a/instances/study-web-dev-temp].

 

디스크가 성공적으로 분리되었으면 분리된 디스크의 URI를 확인해보자. 이 URI는 인스턴스 생성시 필요하다.

gcloud compute disks list 명령어

$ gcloud compute disks list --uri --filter="name:( study-web-dev-temp )"
https://www.googleapis.com/compute/v1/projects/project/zones/asia-northeast3-a/disks/study-web-dev-temp

전체 다 복사할 필요는 없고 projects/~ 부터 복사해놓자.

 

그리고 잊지말고 방금 만든 인스턴스를 삭제하자. 디스크를 분리했기 때문에 삭제해도 상관없다.

gcloud compute instances delete 명령어

$ gcloud compute instances delete study-web-dev-temp \
--zone=asia-northeast3-a

이제 MIG에 인스턴스를 생성할 준비를 해보자. 인스턴스를 새로 생성하려면 자동확장 기능을 꺼야 한다. 자동확장을 끄는 이유는 스테이트 풀로 생성할 것이기 때문이다. 스테이트풀 정책 구성과는 다르게 개별 인스턴스 설정은 사전에 자동확장을 중지시켜놔야 한다. 해야 한 후 수동으로 생성해야 한다. 이 작업은 아래 명령어로 수행할 수 있다. 

gcloud compute instance-groups managed stop-autoscaling 명령어

gcloud compute instance-groups managed delete-instances 명령어

# 자동확장 중지
$ gcloud compute instance-groups managed stop-autoscaling study-managed-instance-group \
  --zone=asia-northeast3-a
  
# 현재 실행 중인 인스턴스 확인
$ gcloud compute instances list
NAME                    ZONE               MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP      EXTERNAL_IP      STATUS
study-web-dev-dwa1      asia-northeast3-a  f1-micro                   xxx.xxx.xxx.xxx  xxx.xxx.xxx.xxx  RUNNING

# 위의 인스턴스 삭제
$ gcloud compute instance-groups managed delete-instances study-managed-instance-group \
  --zone=asia-northeast3-a \
  --instances=study-web-dev-dwa1
  
  Updated [https://www.googleapis.com/compute/v1/projects/project/zones/asia-northeast3-a/instanceGroupManagers/study-managed-instance-group].

기존 인스턴스를 삭제한 이유는 그냥 깔끔하게 하려고 한 것 뿐이니 그냥 두고 싶다면 삭제하지 않아도 상관 없다. 그리고 여기서 짚고 넘어가야 할 것이 있다. 인스턴스를 수동으로 생성할 경우 오토스케일링으로 설정했던 최소/최대 인스턴스 개수에 영향을 받지 않을까라는 의문이 들 수 있는데 오토스케일링으로 설정한 인스턴스 최소/최대 개수는 오토스케일링 시 자동 축소/확장 되는 것에만 영향을 받는다. 또한 MIG를 생성할 적에 지정 했던 인스턴스 사이즈는 초기에 생성되는 사이즈를 지정한 것이지 인스턴수 개수에 제한을 두는 설정이 아니다. 따라서 MIG size로 지정한 값과 무관하게 인스턴스는 수동으로 계속 생성할 수 있다. 

 

이제 아래 명령어를 사용해 인스턴스를 수동으로 생성해야 되는데 이때 스테이트풀 디스크로 아까 분리한 디스크 URI를 지정해주면 된다.  

gcloud compute instance-groups managed create-instance 명령어

$ gcloud compute instance-groups managed create-instance study-managed-instance-group \
  --instance study-web-dev-stateful \
  --zone=asia-northeast3-a \
  --stateful-disk device-name=study-web-dev-stateful,source=projects/project/zones/asia-northeast3-a/disks/study-web-dev-temp,auto-delete=never
  
  Creating instance....done.

auto-delete 옵션 값으로는 never와 on-permanent-instance-deletion를 지정할 수 있으며, 위에서 사용하던 것과 똑같이 수동삭제 시 디스크 자동삭제 여부를 지정하는 것이다.

 

인스턴스가 잘 생성되었다면 한번 디스크 내용이 잘 보존되는지 테스트 해보도록 하자.

 

다음 포스팅에서는 메타데이터, IP 같은 다른 요소들에 대해 스테이트풀 구성을 해보도록 하겠다.