VM 인스턴스
- GCP문서
https://cloud.google.com/compute/docs/instances?hl=ko
Instance groups, instance templates
- GCP 문서
https://cloud.google.com/compute/docs/instance-templates?hl=ko
| 스테이트풀(Stateful) MIG | 스테이트리스(Stateless) MIG | |
| 워크로드 | VM 재생성 작업 시 디스크, IP 주소, 메타데이터가 보존되는 스테이트풀(Stateful) 워크로드 | 가용성이 높고 확장 가능한 스테이트리스(Stateless) 워크로드(수평 확장, 자동 복구, 자동 업데이트, VM 재생성 시 디스크와 IP 주소가 처음부터 다시 생성) |
| MIG 기능 | • 자동 복구 • 자동 순차적 업데이트 • 다중 영역 배포 | • 자동 복구 • 자동 순차적 업데이트 • 다중 영역 배포 • 자동 확장 |
| 보관 가능한 항목 | • 인스턴스 이름 • 인스턴스 템플릿에 정의되지 않은 디스크에 대한 지원을 포함한 영구 디스크 • 인스턴스별 메타데이터 • IP 주소(미리보기) | 인스턴스 이름 |
정리 : VM재생성시 디스크, IP주소, 메타데이터가 보존되어 있는 것이 스테이트풀 스테이트풀을 사용해야되는 경우는 아래 링크 참조
https://cloud.google.com/compute/docs/instance-groups/stateful-migs?hl=ko#when_to_use_stateful_migs- GCP 문서
https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances?hl=ko#deleting_groups
- GCP 문서
https://cloud.google.com/compute/docs/instance-groups?hl=koSole-tenant node
단독 테넌트란 신청시 프로젝트의 VM만 GCP가 보여하고 있는 물리서버에 단독으로 서비스 해주는 서비스 아래 그림을 보면 이해가 쉬운데, 멀티 테넌트의 경우 각 고객들이 GCP가 가진 물리적인 서버를 나누어 서비스를 받으나, 단독 테넌트의 경우 해당 물리적인 서버
단독 테넌트가 필요한 경우 소프트웨어 중 코어또는 프로세서별 라이센스가 필요하거나, 아래의 경우에 사용
- 성능 요구사항이 있는 게임 워크로드
- 보안 및 규정 준수 요구사항이 있는 금융 또는 의료 워크로드
- 라이선스 요구사항이 있는 Windows 워크로드
유의사항으로는 물리적인 서버이므로, 예를들어 n2 단독 테넌트로 선택했다면 생성할려는 VM들은 n2로 이어서 생성되어야함
- GCP 문서
https://cloud.google.com/compute/docs/nodes/sole-tenant-nodes
Disk Bakcup
GCP에서 DISK를 백업하는 방식은 스냅샷 서비스임 증분식(Incremental Backup)으로 백업을 진행함 (증분은 전체백업 이후 백업을 할때 변경된 데이터만 백업하는 방식 / 반대인 차등 백업은 사용하지 않음 차등백업은 머신 이미지에서 사용) 아래와 같이 처음에는 전체 백업을 받은 후, 그 이후에는 신규나 수정된 데이터만 받는 증분백업으로 진행
스냅샷을 통해 디스크의 현재 상태를 캡쳐하고, 그상태로 새 디스크에 복원도 가능함 실행 중인 가상 머신(VM) 인스턴스에 연결된 상태에서도 디스크에서 스냅샷을 할 수 있으며 (VMware처럼) 실행 중인 VM 인스턴스에 연결된 디스크에서 생성된 스냅샷의 수명 주기는 VM 인스턴스의 수명 주기와 무관 스냅샷을 만들 때 스토리지 위치를 지정할 수 있지만, 생성 한 후에는 변경할 수는 없음
비용관련 스토리지 비용과 네트워크 비용이 발생됨 디스크를 멀티 리전으로 해두면, 생성과 복원시에 네트워크 요금이 발생됨므로, 굳이 멀티 리전을 사용할 것이 아니라면 리전에서만 스냅샷을 사용하는 것을 권장 Cloud Storage에 대한 가격은 링크 참조
https://cloud.google.com/storage/pricing#network-pricing
- GCP 문서
https://cloud.google.com/compute/docs/disks/snapshots?hl=koGCP의 A 프로젝트의 인스턴스를 B 프로젝트로 이전
인스턴스 이동시 요구사항이 존재함 - 프로젝트 할당량 : 이동하고자 하는 프로젝트에 디스크, IP주소와 같은 리소스 할당량(쿼터)여유가 있는지 확인 - 디스크 : 영구디스크의 경우 타 VM과 연결되지 않음 - 로컬SSD : 로컬SSD는 임시로 VM을 종료시 보존되지 않음으로, 미리 복제 필요 - GPU : GPU는 사용할 수 있는 영역이 별도로 있으므로, 이전할려는 영역에서 지원하는지 미리 확인필요 - 서브네트워크(서브넷) : 리전 이동시 신규 서브넷을 생성해야됨
- 이동방법
- 인스턴스를 선택하여 B프로젝트로 이동하는 것이 아님
- 이전할 인스턴스(VM)에 대해 디스크의 자동 삭제를 해지(false)
- VM의 메타데이터 저장
- 디스크 스냅샷을 이용하여 데이터 백업생성 (예방조치)
- 기존 VM삭제
- 부팅 디스크, 데이터 디스크의 스냅샷 생성
- 해당 스냅샷으로 영구 디스크를 생성 (부팅, 데이터)
- 이전할 영역에서 VM 생성 위의 디스크들을 연결 메타데이터, 외부, 내부IP를 기존과 같이 할당 (리전간 이동이면 IP는 이동불가)
이동은 인스턴스를 선택하고 A→ B 이동하는 것이 아닌 디스크 스냅샷을 하고, 그 이후 스냅샷을 통해 복구한다는 개념이다.
- VM이동에 대한 GCP 문서
https://cloud.google.com/compute/docs/instances/moving-instance-across-zones?hl=ko#moving-an-instance-manually
- GCP 문서
https://cloud.google.com/compute/docs/instances/moving-instance-across-zones?hl=koCUD, SUD의 개념
TPU
TPU : Tensor Processing Unit Google에서 머신러닝을 위해 설계한 하드웨어 가속기 / 신경망 작업 부하에 특화된 행렬 프로세서
아래의 경우에 GPU, CPU외에 사용하는 것이 좋음
- 행렬 연산이 주를 이루는 모델
- 기본 학습 루프 내에 커스텀 TensorFlow/PyTorch/JAX 작업이 없는 모델
- 몇 주 또는 몇 달간 학습시키는 모델
- 유효 배치 크기가 큰 대형 모델
- GCP 문서
https://cloud.google.com/tpu/docs/intro-to-tpuL/B에서 사용하는 Health check 방식
백엔드 인스턴스가 트래픽에 제대로 응답하는지 확인하는 상태 확인 카테고리, 프로토콜별로 상태확인을 구성 기존 상태 확인 : 레거시 상태 확인이라고 하며, 백엔드에 보낸 https, http 응답이 HTTP 200 코드로 응답된다면, 성공으로 보는 확인방법 리다이렉션 (301, 302)을 포함한 다른 응답코드는 비정상으로 체크됨 상태 확인 : 위의 기존 상태 확인이 아닌 프로토콜, 범위, 포트, 프로토콜등 각기 필요한 정보를 입력하여 백엔드의 상태를 확인할 수 있음
위 그림과 같이 상태 확인 프로토콜은 HTTP / HTTPS / SSL / TCP가 있으며, 이것을 조합하여 백엔드 서비스에 대한 체크를 진행할 수 있다. 이때 상태 확인을 위해 GCP내부에서 체크를 하게 되는데 해당 소스 IP범위는 아래와 같다.
- 35.191.0.0/16 130.211.0.0/22
- GCP 문서
https://cloud.google.com/load-balancing/docs/health-checksBastion host
용어의 정의 : 공격을 견디도록 특별히 설계 및 구성된 네트워크의 특수 목적 컴퓨터 원래는 방화벽을 뜻하였으며, 침입 차단 소프트웨어가 설치되어 내부와 외부 네트워크 사이에서 일종의 게이트 역할을 수행하는 호스트
Infra에서 보는 베스천 호스트는 외부에서 접근할 수 있는 public IP를 가지고 있으며, 또한 내부로 접근이 가능한 게이트 역활을 수행하는 것 즉 유일하게 외부에 노출되는 호스트 아래 그림처럼 운영자가 내부의 시스템을 접근할려면 베스천 호스트만이 가능하다. 외부에 노출되는 서버이기 때문에 사용자 접근 이력, 수행한 작업 히스토리를 꼭 남겨두도록 설정이 필요
위 그림이 잘 표현을 하였는데, 외부에서 SSH로 접근하고 Bastion Host만이 다시 SSH를 통해 접근을 하는 것을 볼 수 있다. 다른 포트로는 접속 못하게 Firewall Rules로 설정은 필수
VM 인스턴스 로그
Compute Engine(VM)에 대한 감사로그 즉 누가, 언제, 어디서, 무엇을 했는지 볼 수 있는 부분
위의 그림처럼 감사 로그를 선택하여 확인할 수 있음 아래 표를 통해 Compute Engine에 대한 관리자, 데이터, 시스템이벤트까지 확인할 수 있음 리소스에 대한 모니터링은 Cloud Logging에서 Agent를 설치하여 받아 볼 수 있음
| 감사 로그 카테고리 | 하위유형 | Compute Engine 작업 | 예시 |
| 관리자 활동 감사 로그 | 해당 사항 없음 | • 리소스 만들기 • 리소스 업데이트/패치 • 메타데이터 설정/변경 • 태그 설정/변경 • 라벨 설정/변경 • 권한 설정/변경 • 리소스 속성(커스텀 동사 포함) 설정/변경 | • compute.instances.insert
• compute.instanceGroups.removeInstances
• compute.instances.setMetadata
• compute.instances.setLabels
• compute.instances.setTags
• compute.instances.setIamPolicy |
| 데이터 액세스 감사 로그1 | ADMIN_READ | • 리소스에 대한 정보 가져오기 • 리소스 나열 • 범위 전체 리소스 나열(집계 목록 요청) | • compute.instances.list
• compute.images.get
• compute.interconnectAttachments.aggregatedList |
DATA_READ | 직렬 포트 콘솔의 콘텐츠 가져오기 | compute.instance.getSerialPortOutput | |
| 시스템 이벤트 감사 로그 | 해당 사항 없음 | • 호스트 유지보수 시 • 인스턴스 선점 • 자동으로 다시 시작 • 인스턴스를 재설정했습니다. • 직렬 포트 연결/분리2 | • compute.instances.migrateOnHostMaintenance
• compute.instances.automaticRestart
• compute.instanceGroupManagers.resizeAdvanced
• google.ssh-serialport.v1.connect |
- GCP 문서
https://cloud.google.com/compute/docs/logging/audit-logging?hl=koExternal Disk(Data disk) 추가 구성
GUI(console), gcloud, Compute Engine API를 사용해 디스크를 추가할 수 있다. 추가 방법
- VM인스턴스를 선택하고 세부정보 페이지로 이동
- 추가 디스크에서 새디스크 추가 선택
- 디스크 이름설정, 소스 유형은 빈 디스크로 선택
- 완료, 저장을 통해 새디스크 추가
- Linux에서는 디스크 인식 → 포맷 → 마운트 → 재시작시 자동 마운트 되도록 설정
console에서 디스크 추가
해당 인스턴스 기동 후 디바이스 정보 확인
sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/DEVICE_NAME
참고 : lazy_itable_init - inode테이블 초기화 옵션 (0은 실행, 1은 실행하지 않음) lazy_journal_init - journal은 변경사항을 기록하는 곳으로 비활성화를 해야 mkfs에 의해 포맷이 전부 진행됨 (0비활성화 1활성화) 즉 활성화시 journal부분의 inode를 다 삭제하지 않는 것이고, 비활성화면 inode를 삭제 후 진행한다는 것
포맷 후에는 아래와 같이 UUID가 발급됨
마운트를 아래와 같이 진행한다.
sudo mount -o discard,defaults /dev/DEVICE_NAME /MOUNT_DIR참고 : discard - 파일이 지워질때마다 TRIM을 실행해주는 옵션 해당 옵션을 넣는 이유는 하드의 경우에는 파일 삭제 후 덮어쓰기를 하지만, SSD는 덮어쓰기를 하지 못하고, 계속 inode위치만 삭제 되는 것으로 실제 파일은 남아있기에 성능을 위해 사용하는 옵션 defaults - 기본 옵션인 rw, suid, dev, exec(바이너리실행), auto, nuser, async 속성을 다 주어 사용하는 것 ubuntu mount Man페이지 참고
https://manpages.ubuntu.com/manpages/xenial/man8/mount.8.html
df -hP로 확인
우선 기동 중인 인스턴스에 디스크 추가는 완료되었으나, 재부팅 후에도 마운트를 유지하려면 /etc/fstab에 수정작업을 해주어야함
lsblk -f (파일시스템, UUID 항목추가), blkid명령어로 디스크의 UUID를 확보한다.
fstab파일을 백업해 두고, 아래의 형식처럼 등록을 한다. mount 옵션이 다양하므로, 상황에 맞게 확인 후 진행한다.
UUID=UUID_VALUE /mnt/disks/MOUNT_DIR ext4 discard defaults MOUNT_OPTION 0 2
UUID=ec4a3a7d-af73-4377-bba9-3fc310c0f410 /test_disk ext4 discard defaults MOUNT_OPTION 0 2
Windows의 경우 자동으로 디스크가 붙으니, 디스크과리자에서 포맷 후 파일시스템 할당하면 완료
- GCP 문서
https://cloud.google.com/compute/docs/disks/add-persistent-disk디스크의 용량 증설 방법
온프레미스의 경우 vg에 용량이 남아있으면, lvextend한 다음 resize2fs로 하면 되는데.. 클라우드에서는 방법이 좀 다르다.
먼저 GCP Console에서 Compute Engine → 디스크로 이동 증설하려는 디스크 선택 후 수정선택
원하는 용량으로 수정을 진행한다.
lsblk를 사용해 현재 상태를 파악 (현재 10GB)
parted 유틸리티를 열고, 아래의 순서대로 진행한다. resizepart 입력 partition number : 1번 입력 현재 파티션이 사용 중인데, 그래도 진행할 것인가? → YES 용량 증가에 따른 100% 입력 후 종료
resize2fs명령어로 위 parted에서 정의한 파일시스템을 실제로 확장시킨다.
sudo resize2fs /dev/sdb
df -hP로 현 파일시스템 확인
https://cloud.google.com/compute/docs/disks/resize-persistent-disk디스크의 용량 축소 방법
결론적으로 GCP에서 디스크 자체를 용량 축소할 방법은 없다. 파일시스템은 아래와 같이 umount 후 resize로 조정이 가능하지만, 어차피 디스크 자체의 용량을 줄 일 수 없기 때문에 의미가 없다. 아마도 VG, LV관리를 GCP에서 직접 하는 거 같아서 안되는거 같다.
sudo umount /test_disk (MOUNT_POINT)
sudo resize2fs -f /dev/sdb 10G (용량 재설정)
sudo mount -o discard,defaults /dev/sdb /test_disk
꼭 필요하다면, 신규 디스크 생성 후 복사한 후 줄이는 방법이 있을 것 같다.
VM의 유지보수를 위한 startup, shutdown 시 자동 실행 방법
VM에서는 시작 스크립트, 종료 스크립트를 각각 실행할 수 있음
- 시작스크립트
Windows, Linux모두 가능 제약사항으로는 네트워크를 사용할 수 있을때만 시작 스크립트가 동작 gcloud과 terraform을 이용해도 되고, console에서 직접 전달도 가능하다.
VM에서 rc.local에 등록하는 것과 무슨차이가 있나면 부팅전에 미리 설정하는 것과 이미 시스템을 구성 후 시작하는 차이가 있는 것으로 보인다. 즉 커널레벨에서 실행하는 것이 다를 것로 생각됨 (다만 이것에 대한 문서는 못찾았음..중요한게 아니라서 그런건지)
설정은 다음과 같이 자동화 부분에 원하는대로 넣는다.
아래와 같이 쉘스크립트를 등록 해두면 해당 VM기동과 동시에 웹서버가 기동된다.
#! /bin/bash
apt update
apt -y install apache2
cat <<EOF > /var/www/html/index.html
<html><body><p>Linux startup script added directly.</p></body></html>위의 방법 외에도 로컬PC에서 gcloud로 생성
gcloud compute instances create VM_NAME \
--image-project=debian-cloud \
--image-family=debian-10 \
--metadata-from-file=startup-script=FILE_PATHCLoud Storage(bucket)에서도 스크립트를 넘길 수 있다.
- 시작스크립트 GCP문서
https://cloud.google.com/compute/docs/instances/startup-scripts
- 종료스크립트
인스턴스가 중지되거나, 다시 시작하기 바로전에 명령어를 실행 하는 것 다만, 종료 명령을 내리고 한정된 시간에 진행되는거라 스크립트를 생성할 때 너무 오래걸리는 명령은 지양해야된다.
console에서 하는 방법은 메타데이터에서 키 값을 shutdown-script을 주고 명령을 주면 됨
shutdown-script: 이 키로 종료 스크립트 콘텐츠를 직접 제공합니다. Google Cloud CLI를 사용할 경우 --metadata-from-file 플래그와 shutdown-script 메타데이터 키를 사용하여 종료 스크립트 파일의 경로를 제공할 수 있습니다.
shutdown-script-url: 이 키로 종료 스크립트 파일의 Cloud Storage URL을 제공합니다.
스크립트관련해서 권한은 아래의 권한이 필요하다.
- 인스턴스를 생성하는 데 필요한 모든 권한
- 인스턴스에 대한
compute.instances.setMetadata권한
- 종료스크립트 GCP문서
https://cloud.google.com/compute/docs/shutdownscript
Compute Engine 종류 / 가격
머신별 타입이 미리 존재하고, 커스텀하게도 가능
GCP에서 추천하는 워크로드는 아래와 같으니 참고로 알아두자
N1, E2, C2등 워크로드 모델에 다라 CPU유형이 다름 다음 링크에 정리가 잘 되어있으니 참조하자
https://cloud.google.com/compute/docs/machine-types?hl=ko#machine_type_comparison
- VM인스턴스 가격
https://cloud.google.com/compute/vm-instance-pricing?hl=ko
- Compute Engine 의 머신 유형(PVM, Custom, Confidential)
Confidential개념 데이터와 애플리케이션이 사용 중에도 비공개로 유지되고 암호화되도록 보장하는 Compute Engine VM 유형 AMD EPYC CPU에서만 동작하며, 지원되는 운영체제는 Linux 계열만 지원
https://cloud.google.com/compute/confidential-vm/docs/about-cvm
PVM : (Preemptible Virtual Machine) 우리말로하면 선점형 인스턴스 AWS의 spot instance와 비슷한 서비스 일반 VM에 비해 80%까지 저렴하게 사용할 수 있지만 그대신에 제약사항이 있다. 1. 24 시간 뒤에 자동으로 삭제된다. 2. 다른쪽에서 해당 리소스를 사용하게 될 경우 내 PVM이 자동 종료될 수도 있다. (Preemptible단어가 -선점가능한) 타 사용자가 선점해서 자동 종료되는 경우 종료 30초 전에 노티스를 준다.) 3. 한정된 compute enginge resource이므로 항상 사용가능한것은 아니다. 4. auto restart 불가능하고 live-migration 작업도 불가능하다 5. PVM instance는 interruption 발생으로 종료될경우 재실행은 불가능하지만 managed instacne groups 기능을 통해서 PVM instance 종료시 다른 PVM instance를 기동하는 방법으로 설정은 가능 PVM은 그래서 테스트 및 단시간내 실행되는 batch process job, fault tolerant 한 application에 사용하기 적합함 즉 하나의 Cluster에 여러 instance가 동작하는 구조라면, 저렴한 가격에 사용하기 좋은 옵션
https://cloud.google.com/compute/docs/instances/preemptible
Custom
사전에 GCP에서 정의한 머신에 사용자가 원하는대로 수정하는 것 vCPU, 메모리를 수정이 가능하며 커스텀한 용량에 따라 가격은 별도로 매겨진다. 커스텀한 사양이라도 지속 사용할인(SUD)는 받을 수 있음
- 커스텀 유형으로 VM 생성관련 문서
https://cloud.google.com/compute/docs/instances/creating-instance-with-custom-machine-type
- VM OS 패치 정책
SaaS가 아닌 Iaas서비스에 패치 정책이라 해서 좀 의아했는데, GCP에서 패치 작업관리를 통해 시각화 및 자동화 해주는 서비스와 같은 것 서비스 이름은 VM Manager 가격은 100대는 무료 그 이상부터는 시간당 0.003$를 청구 (근데 이러면 datadog쓰는게 훨 나을텐데?) MS의 WSUS처럼 VM들의 패치를 정리, 적용, 배포, 시각화를 해주는 점에서 좋아보인다. 당연한 이야기지만 OS에 에이전트가 설치되어야함
OS를 패치 하지 않는다고해서, 제약이나 그런건 없음
- 유지보수 정책
VM에서 이벤트 발생시 유지보수 정책을 설정할 수 있음 GCP에서 유지보수를 위해 VM을 중지할 경우 인스턴스를 라이브 마이그레이션 하여 넘기는게 기본설정 그 외 VM이 비정상 종료되면 자동으로 Compute Engine이 재시작하거나 종료되는 것 VM에서 응답이 없을 때 재시작 (무조건 재시작이며, 대기하는 시간을 조절할 수는 있음)
GCP에서 설명하는 유지보수 이벤트
유지보수 이벤트는 Compute Engine에서 VM을 중지하여 하드웨어 또는 소프트웨어 업데이트를 수행하는 경우입니다. 라이브 마이그레이션 호스트 유지보수 정책을 사용 설정하면 Compute Engine에서 VM을 새 호스트로 이동하며 애플리케이션이 중단되지 않습니다.
유지보수 이벤트 중의 VM 동작은 VM 테넌시에 따라 다를 수 있습니다. 다음 표에서는 유지보수 이벤트 중 멀티 테넌트 VM과 단독 테넌트 VM 동작의 몇 가지 차이점을 보여줍니다.
| 호스트 테넌시 | 대략적인 빈도* | 새 호스트로 라이브 마이그레이션 | 호스트 선택 |
| 멀티 테넌트 | 2주마다 | 예 | Compute Engine |
| 단독 테넌트 | 4~6주 간격 | 호스트 유지보수 정책에 따라 다름 | 호스트 유지보수 정책에 따라 다름 |
위 빈도는 대략적인 수치이며 보장되지 않습니다. Compute Engine에서 유지보수를 더 자주 수행할 수도 있습니다.
또한 Compute Engine은 백그라운드에서 일부 가벼운 하이퍼바이저 업그레이드와 네트워크 업그레이드를 중단 없이 적용합니다.
- VM호스트에 대한 유지보수 정책문서
https://cloud.google.com/compute/docs/instances/setting-vm-host-options?hl=koUploaded by N2T