인스턴스로 다른 작업 수행

다음은 인스턴스로 수행할 수 있는 그 밖의 작업입니다.

시작하기 전에

인스턴스와 로컬 컴퓨터 간에 파일 복사

Linux 인스턴스와 로컬 컴퓨터 간에 파일을 전송하려면 gcloud compute scp를 사용합니다.

gcloud compute scp my-instance:~/file-1 \
    my-instance:~/file-2 \
    ~/local-dir

로컬 머신에서 인스턴스로 파일을 복사하려면 다음 명령어를 사용합니다.

gcloud compute scp ~/local-dir/file-1 \
    my-instance:~/remote-destination

Compute Engine에서 실행 여부 감지

일반적으로 시스템에서는 특정 클라우드 환경에서 실행되고 있는지 감지하려고 합니다. 다음 안내를 사용하여 Compute Engine에서 실행 중인지 감지할 수 있습니다.

메타데이터 서버 사용

메타데이터 서버를 사용하여 Compute Engine 인스턴스 내에서 애플리케이션 또는 스크립트가 실행되고 있는지 쉽게 감지할 수 있습니다. 서버에 요청하면 메타데이터 서버의 모든 응답에 Metadata-Flavor: Google 헤더가 포함됩니다. 이 헤더를 찾으면 Compute Engine에서 실행 중인지 확실하게 감지할 수 있습니다.

예를 들어 다음 curl 요청은 Metadata-Flavor: Google 헤더를 반환하며 이는 Compute Engine 인스턴스 내에서 요청이 수행되고 있음을 나타냅니다.


me@my-inst:~$ curl metadata.google.internal -i


HTTP/1.1 200 OK
Metadata-Flavor: Google
Content-Type: application/text
Date: Thu, 10 Apr 2014 19:24:27 GMT
Server: Metadata Server for VM
Content-Length: 22
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN

0.1/

computeMetadata/

기타 메소드 사용

Linux

Linux 인스턴스의 경우 dmidecode 도구를 사용하여 /proc/mem의 DMI/SMBIOS 정보에 직접 액세스할 수 있습니다. 다음 명령어를 실행하면 dmidecode 도구가 'Google Compute Engine'을 출력하여 현재 Compute Engine에서 실행 중임을 나타냅니다.

my@myinst:~$ sudo dmidecode -s system-product-name | grep "Google Compute Engine"
Google Compute Engine

Windows

Windows 인스턴스에서 'Google'은 시스템 제조업체 및 모델로 나열됩니다. msinfo32.exe와 같은 유틸리티를 사용하여 이 정보를 찾을 수 있습니다. 예를 들어 msinfo32에는 다음 정보가 표시됩니다.

msinfo32 screen displaying Google as manufacturer and model (click to enlarge)
Google이 업체 및 모델로 표시된 msinfo32 화면(확대하려면 클릭)

이 정보를 Windows 인스턴스에서 프로그래매틱 방식으로 확인해야 하는 경우 일부 수정Windows Management Instrumentation(WMI) 애플리케이션을 만들 수 있습니다.

인스턴스 장애 처리 방법

개별 인스턴스에는 때때로 장애가 발생합니다. 이는 예기치 못한 정전, 하드웨어 오류, 기타 시스템 장애 등 다양한 이유로 인해 발생할 수 있습니다. 따라서 영구 디스크를 사용하거나 정기적으로 데이터를 백업하여 이러한 상황이 미치는 영향을 완화해야 합니다.

인스턴스에 장애가 발생하면 장애가 발생한 때와 동일한 루트 영구 디스크, 메타데이터, 인스턴스 설정으로 해당 인스턴스가 자동으로 재시작됩니다. 인스턴스의 자동 재시작 동작을 제어하려면 일정 예약 옵션 설정 방법을 참조하세요.

일반적으로, 단일 인스턴스의 장애가 애플리케이션에 치명적인 영향을 미치지 않도록 강력한 시스템을 설계해야 합니다. 자세한 내용은 강력한 시스템 설계를 참조하세요.

UUID를 통한 인스턴스 식별

각 가상 머신에는 Linux 이미지용 dmidecode 도구를 통해 액세스할 수 있는 범용 고유 식별자(UUID)가 있습니다. UUID는 가상 머신의 프로젝트 ID, 영역 및 인스턴스 이름에서 계산됩니다. 인스턴스의 UUID는 Compute Engine 가상 머신 간에 고유하며 인스턴스의 수명 기간 동안 안정적입니다. UUID는 가상 머신이 다시 시작되어도 유지되며, 가상 머신이 삭제되어 동일한 프로젝트 및 영역에 동일한 인스턴스 이름으로 다시 생성되는 경우 UUID가 동일하게 유지됩니다.

Linux 인스턴스에서 인스턴스의 UUID를 찾으려면 가상 머신에서 다음 명령어를 실행합니다.

me@myinst:~$ sudo dmidecode -t system | grep UUID

도구에 다음과 유사한 응답이 출력됩니다.

  UUID: FE0C672D-324F-25F1-052C-6C50FA8B7397

패키지 설치 및 인스턴스 구성

인스턴스 생성자는 프로젝트에 추가하는 모든 인스턴스에 대해 관리자 권한을 가지며 SUDO 목록에 자동으로 포함됩니다.

인스턴스에 관리자로 로그인한 경우, 일반 Linux 상자와 동일한 방식으로 패키지를 설치하고 인스턴스를 구성할 수 있습니다. 예를 들어 아래와 같이 Apache를 설치할 수 있습니다.


user@myinst:~$ sudo apt-get update && sudo apt-get install apache2
Reading package lists... Done

Building dependency tree
Reading state information... Done
The following extra packages will be installed:

[...]

인스턴스와 로컬 컴퓨터 간 파일 복사에 설명된 대로 gcloud compute scp를 사용하여 로컬 컴퓨터와 인스턴스 간에 파일을 옮길 수 있습니다.

apt-get을 실행하려면 머신에서 인터넷에 액세스해야 합니다. 따라서 외부 IP 주소인터넷 프록시에 대한 액세스가 필요합니다.

Compute Engine에서는 대기 중인 인프라 유지관리 이벤트의 일부로 가상 머신을 실시간 이전이나 종료한 다음 다시 시작하기 직전에 가상 머신의 메타데이터 서버의 특수 속성을 변경합니다. maintenance-event 속성은 이벤트 전후에 업데이트되며 이를 통해 이러한 이벤트가 임박했음을 알 수 있습니다. 이 정보를 사용하여 유지관리 이벤트 전후에 실행하려는 스크립트 또는 명령어를 자동화할 수 있습니다.

자세한 내용은 메타데이터 서버 문서 페이지의 투명한 유지보수 알림 섹션을 참조하세요.

모든 인스턴스 나열

instances list를 호출하여 프로젝트의 모든 인스턴스 목록을 볼 수 있습니다.

gcloud compute instances list
NAME               ZONE          MACHINE_TYPE  INTERNAL_IP    EXTERNAL_IP     STATUS
example-instance   us-central1-a n1-standard-1 10.105.155.92  173.255.114.53  RUNNING
example-instance-2 us-central1-a n1-standard-1 10.181.215.203 146.148.32.59   RUNNING

기본적으로, gcloud compute는 이용 가능한 모든 영역에 걸쳐 모든 리소스에 대한 집계 목록을 제공합니다. 단일 영역의 리소스 목록을 원하는 경우 요청에 --zones 플래그를 제공하세요.

API에서는 집계 리소스 목록이나 영역 내의 리소스 목록을 가져오려면 2가지 다른 메소드에 대해 요청을 해야 합니다. 집계 목록을 가져오기 위한 요청을 하려면 리소스의 aggregatedList URI에 대해 GET 요청을 하고 프로젝트를 자신의 프로젝트 ID로 바꿉니다.

https://www.googleapis.com/compute/v1/projects/myproject/aggregated/instances

클라이언트 라이브러리에서 instances().aggregatedList 함수에 대한 요청을 합니다.

def listAllInstances(auth_http, gce_service):
  request = gce_service.instances().aggregatedList(project=PROJECT_ID)
  response = request.execute(auth_http)

  print response

영역 내 인스턴스 목록을 가져오기 위한 요청을 하려면 다음 URI에 대해 GET 요청을 하고 프로젝트를 자신의 프로젝트 ID로 바꾸고 영역을 인스턴스의 영역으로 바꿉니다.

https://www.googleapis.com/compute/v1/projects/myproject/zones/us-central1-f/instances

API 클라이언트 라이브러리에서 instances().list 요청을 합니다.

def listInstances(auth_http, gce_service):
  request = gce_service.instances().list(project="myproject",
    zone="us-central1-f")
  response = request.execute(auth_http)

  print response

선점형 인스턴스를 통해 비용 절감

Compute Engine은 일반 인스턴스에 비해 훨씬 낮은 가격으로 만들고 실행할 수 있는 선점형 인스턴스를 제공합니다. 애플리케이션에 내결함성이 있어 인스턴스의 불안정성에도 큰 문제가 없다면 선점형 인스턴스를 사용하여 Compute Engine 비용을 크게 절감할 수 있습니다. 자세한 내용은 선점형 인스턴스 문서에서 확인하세요.

네트워크 시간 프로토콜(NTP) 인스턴스 설정

이벤트의 세밀한 시퀀싱에 의존하는 많은 소프트웨어 시스템에서는 안정적이고 일관된 시스템 시계를 사용합니다. 대부분의 서비스에서 작성되는 시스템 로그에는 시스템의 다양한 구성요소 간에 발생하는 디버그 문제를 지원하는 타임스탬프가 포함됩니다. 시스템 시계가 동기화 상태를 유지할 수 있도록 Compute Engine 인스턴스는 네트워크 시간 프로토콜(NTP)을 사용하도록 사전 구성됩니다.

서버 시간의 동기화 상태를 유지하는 것 외에도 NTP는 드물지만 윤초가 발생하는 경우에도 유용합니다. 윤초는 지구 회전의 변화로 인한 오차를 조정하기 위해 UTC 시간이 1초 조정되는 것입니다. 지구의 회전 속도가 기후 및 지질학적 사건에 대한 반응으로 불규칙적으로 변화하기 때문에 윤초는 규칙적인 간격으로 발생하지 않습니다. 따라서 이전의 윤초는 웹의 다양한 서비스 및 애플리케이션에 대혼란을 가져왔습니다. 하지만 NTP 서버는 윤초 이벤트 동안 모든 서버가 동일한 시간을 보고할 수 있도록 지원합니다.

이 섹션에서는 윤초가 발생하는 경우에 가상 머신의 NTP 서버가 제대로 동작하도록 구성하는 방법을 설명합니다.

Google NTP 서버 및 윤초 스미어(smear) 처리

Unix 시간에서 윤초는 일반적으로 하루 중 마지막 초를 반복하여 구현됩니다. 이로 인해 타임스탬프가 증가하기만 할 것으로 예상하는 소프트웨어에서 문제가 발생할 수 있습니다. 이 문제를 해결하기 위해, Google에 있는 시간 서버는 20시간(윤초 이벤트 전후로 10시간씩) 동안 추가 초를 '스미어(smear)' 처리하여 컴퓨터가 모두 한꺼번에 추가 초를 반복된 타임스탬프로 인식하지 못하도록 합니다. 그러면 일관된 타임스탬프에 의존하는 시스템에서 위험을 줄일 수 있습니다. 따라서 모든 Compute Engine 가상 머신 인스턴스에서 Google NTP 내부 서비스를 사용하도록 구성하는 것이 좋습니다.

인스턴스의 NTP 구성

Google에서는 pool.ntp.org와 같은 외부 NTP 서비스에서 윤초를 처리하는 방법을 예측할 수 없습니다. 가능한 경우 Compute Engine 가상 머신에 외부 NTP 소스를 사용하지 않는 것이 좋습니다. 심지어 Google의 NTP 서비스와 외부 서비스를 모두 사용하면 시스템 시간에 예측할 수 없는 변경사항이 발생할 수 있습니다. 단일 외부 NTP 소스만 사용하는 것이 혼합하여 사용하는 것보다는 낫지만, pool.ntp.org와 같은 외부 NTP 서비스에서는 윤초를 처리하기 위해 스테핑을 사용할 가능성이 높습니다. 그러면 결과적으로 가상 머신에서 반복되는 타임스탬프를 인식할 수 있습니다.

가장 안전한 방식은 단일 NTP 서버(Google에서 제공하는 내부 NTP 서버)를 사용하도록 Compute Engine 가상 머신을 구성하는 것입니다. 외부 NTP 서버와 Google NTP 서버를 혼용하지 마세요. 이는 예기치 않은 동작을 초래할 수 있습니다.

가상 머신이 올바르게 구성되었는지 확인하려면 다음 안내를 따르세요.

Linux

  1. ssh를 사용하여 인스턴스에 연결합니다.

    콘솔

    1. GCP Console에서 VM 인스턴스 페이지로 이동합니다.
    2. 구성하고자 하는 인스턴스 옆에 있는 ssh 버튼을 클릭합니다.

      SSH 버튼의 스크린샷

    gcloud

    gcloud 명령줄 도구로 다음을 실행합니다.

    gcloud compute instances ssh INSTANCE
    

  2. 인스턴스에서 ntpq -p를 실행하여 NTP 구성의 현재 상태를 확인합니다.

    $ ntpq -p
    
    
         remote           refid      st t when poll reach   delay   offset  jitter
    
    ==============================================================================
    *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
    *217.162.232.173 130.149.17.8     2 u  191 1024  176   79.245    3.589  27.454
    

    metadata.google 또는 metadata.google.internal을 가리키는 단일 레코드가 표시되는 경우 변경할 필요가 없습니다. 메타데이터.google과 pool.ntp.org 같은 공개 소스가 혼합된 여러 소스가 표시되는 경우 소스를 업데이트하여 모든 외부 NTP 서버를 제거해야 합니다.

    이 예에는 2개의 레코드가 있으며, 그 중 하나는 metadata.google을 가리키고 다른 하나는 외부 주소를 가리킵니다. 여러 소스가 있으므로 *217.162.232.173 주소 삭제를 위해 NTP 서버를 업데이트해야 합니다.

    1. 외부 소스를 삭제하도록 NTP 서버를 구성합니다.

      NTP 서버를 구성하려면, 자주 사용하는 텍스트 편집기에서 /etc/ntp.conf 파일을 편집합니다. 구성의 servers 섹션을 찾고 Google NTP 소스가 아닌 모든 소스를 삭제합니다.

    $ vim /etc/ntp.conf
    
    ...
    # You do need to talk to an NTP server or two (or three).
    #server ntp.your-provider.example
    ...
    server metadata.google.internal iburst
    

    /etc/ntp.conf 파일을 편집한 후 NTP서비스를 다시 시작합니다. 다시 시작하는 명령어는 Linux 배포판에 따라 다를 수 있습니다.

    $ sudo service ntp reload
    1. 구성을 확인합니다. ntpq -p 명령어를 다시 실행하여 변경사항을 확인합니다.
    $ ntpq -p
    
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
    *metadata.google 255.28.23.83     2 u   27   64    1    0.634   -2.537   2.285
    

Windows

  1. GCP Console에서 VM 인스턴스 페이지로 이동합니다.
  2. 로그인하려는 Windows 인스턴스 옆에 있는 RDP 버튼을 클릭합니다.

    SSH 버튼의 스크린샷

  3. 로그인한 후, PowerShell 아이콘을 마우스 오른쪽 버튼으로 클릭하고 관리자 권한으로 실행을 선택합니다.

    PowerShell 아이콘의 스크린샷

  4. 명령어 프롬프트가 로드되면 다음 명령어를 실행하여 현재 NTP 구성을 확인합니다.

    PS C:\Windows\system32>w32tm /query /configuration
    [Configuration]
    ...
    Type: NTP (Local)
    NtpServer: metadata.google.internal,
    ...
    

    metadata.google 또는 metadata.google.internal을 가리키는 단일 레코드가 표시되는 경우 변경할 필요가 없습니다. metadata.google과 공개 소스가 혼합된 여러 소스가 표시되는 경우 외부 서버를 제거해야 합니다. NTP 서버를 구성하려면 Windows 가이드를 따릅니다.

Google NTP 서버의 윤초 스미어(smear) 처리 기능을 사용하면 시간에 민감한 시스템에서 초를 다시 재생하는 것과 관련된 위험을 편리하게 관리할 수 있습니다. 다른 NTP 서비스에서도 대부분의 소프트웨어 시스템에서 사용할 수 있는 해결방법을 제공할 수 있습니다. 중요한 것은 Google의 윤초 스미어(smear) 처리 NTP 서비스와 공개 NTP 스테핑 서비스를 혼합하지 않는 것입니다.

Google 클라우드 외부의 기기를 스미어(smear) 처리된 시간에 동기화하려면 Google 공개 NTP를 사용하세요. Google 공개 NTP에서는 Compute Engine 가상 머신 인스턴스에 제공된 것과 동일한 스미어(smear) 처리 기능을 사용합니다.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

Compute Engine 문서