Documentation index for AI agents

GS2-Deploy 를 사용한 설정

GS2-Deploy 를 사용하여 마이크로서비스에 리소스를 생성한다
Tags:

관리 콘솔을 사용한 설정은 손쉽게 실행할 수 있다는 점이 매력입니다.

하지만 “같은 환경을 하나 더 만들어 달라"는 요청을 받았을 때, 당신은 분명 절망하게 될 것입니다. 게임 개발에서는 일반적으로 “개발 환경”, “검증 환경”, “운영 환경"과 같이 여러 서버 환경이 필요합니다.

각 환경에서 관리 콘솔상의 동일한 조작을 반복하며 GS2 설정을 실수 없이 수행하는 것은 불가능하다고 할 수 있습니다.

GS2-Deploy

그래서 GS2 에는 환경 구축을 위한 마이크로서비스인 GS2-Deploy 가 준비되어 있습니다.

당신이 클라우드에 정통한 엔지니어라면, AWS 가 제공하는 Cloud Formation 의 GS2 버전이라고만 말해도 이 마이크로서비스의 역할을 이해할 수 있을 것입니다. 이해했다면 더 이상 이 페이지를 읽어나갈 필요는 없습니다. GS2 는 Cloud Formation 과 같은 기능을 사용하여 마이크로서비스를 오케스트레이션할 수 있습니다.

그렇지 않은 분도 안심하세요. 여기서부터 GS2-Deploy 에 대해 자세히 설명하겠습니다.

Infrastructure as Code

관리 화면을 사용하여 GS2 설정을 반영하는 것이 얼마나 어리석은 일인지, 이미 당신이 이해하고 있다고 믿습니다. 이러한 어리석음에 맞서기 위해, 서버 인프라의 세계에서는 다양한 개선이 이루어져 왔습니다.

그리고 그 성과가 바로 Infrastructure as Code(IaC) 입니다.

20년 전에는 서버를 새로 세팅하게 된 인프라 엔지니어가 한 대 한 대에 명령어를 입력하여 환경을 구축했습니다. “HTTP 서버 설치”, “HTTP 서버 설정 파일 갱신”, “데이터베이스 서버 설치”, “데이터베이스에 스키마 등록” 이러한 작업은 한 대라면 문제없지만, 100대의 서버에 설정한다면 어떨까요?

1주일에 걸쳐 100대의 서버를 세팅했지만, 그중 몇 대는 설정 실수로 동작하지 않는 일이 벌어지곤 했습니다.

2006년에 Amazon 이 현대 클라우드의 기초라 할 수 있는 Elastic Compute Cloud 를 출시했습니다. 그러자 이전까지는 발주하고 나서 서버가 손에 들어오기까지 몇 개월을 기다려야 했지만, 발주 후 5분 만에 서버를 손에 넣을 수 있는 상태가 되었습니다. 이는 서버 인프라 세계에 격변을 가져왔습니다.

지금까지는 하드웨어 리드타임이 몇 개월이나 걸렸기 때문에, 서버를 세팅하고 실수가 있으면 수정하는 작업에 1주일을 들이더라도 비효율을 감출 수 있었습니다. 하지만 5분 만에 서버를 조달한 후 1주일을 들여 서버를 세팅하는 것은 뭔가 이상하다는 사실을 깨달은 사람들이 있었습니다.

그래서 서버 세팅 절차를 자동화하여 세팅에 걸리는 시간을 단축하려는 동기가 높아졌습니다. 그 결과물로 등장한 것이 서버 세팅 절차를 코드화하는 IaC 입니다. IaC 에 의해 서버 세팅 시간은 빠르고 정확해졌습니다.

IaC 의 접근 방식

IaC 에는 2가지 접근 방식이 존재합니다. 첫 번째는 명령형, 두 번째는 선언형입니다.

명령형은 “apt install httpd"와 같은 세팅 절차의 명령어를 나열하고, 이를 실행함으로써 자동화하려는 사고방식에 기반합니다. 이는 사람이 수행하던 세팅 절차를 자동화하려 할 때 자연스러운 발상입니다.

선언형은 “웹 서버가 필요하다"는 것을 명시합니다. 이때 웹 서버를 만들기 위해 필요한 절차는 고려하지 않습니다. 자, 당신은 이 두 가지 방식 중 어느 쪽이 더 우수하다고 생각하십니까?

이 두 가지 접근 방식의 우열을 가리려면, 실무에 기반한 예시를 드는 것이 이해하기 쉬울 것입니다. 당신은 100대의 서버가 있는 서비스를 맡고 있습니다. 그런데 서비스 이용자가 줄어들어 서버 대수를 절반으로 줄이라는 요구를 받았습니다. 50대를 남기고, 나머지 50대는 전원을 껐습니다.

그 반년 후, 서비스가 호조를 보이면서 전원을 껐던 50대의 서버를 다시 사용하여 100대의 서버를 준비하라는 요구를 받습니다. 자, 반년 만에 전원을 켠 서버를 최신 상태로 만들어야 하는데, 이때 명령형과 선언형의 차이가 명확해집니다.

명령형은 지난번에 어디까지 명령을 실행했는지 알 수 없습니다. 반면 선언형은 현재 상태와 새로 선언된 상태의 차이를 알 수 있다면, 그 차이를 메우기 위한 갱신만 하면 됩니다.

이러한 과거 사례를 참고하여 GS2-Deploy 는 선언형 IaC 를 구현하고 있습니다.

템플릿

GS2-Deploy 는 템플릿 파일에 GS2 의 각 마이크로서비스에 요구하는 상태를 선언하고, 이를 적용함으로써 환경 구축을 할 수 있도록 되어 있습니다. 관리 콘솔을 통해 GS2-Inventory 에 리소스를 생성했던 절차를 그대로 템플릿으로 만들어 봅시다.

GS2TemplateFormatVersion: "2019-05-01"
Resources:
  InventoryNamespace:
    Type: GS2::Inventory::Namespace
    Properties:
      Name: test

  InventoryMasterData:
    Type: GS2::Inventory::CurrentItemModelMaster
    Properties:
      NamespaceName: test
      Settings: {
        "version": "2019-02-05",
        "inventoryModels": [
          {
            "name": "inventory",
            "initialCapacity": 5,
            "maxCapacity": 10,
            "itemModels": [
              {
                "name": "Potion",
                "stackingLimit": 99,
                "allowMultipleStacks": true,
                "sortValue": 1
              }
            ]
          }
        ]
      }

이것으로 test 라는 이름의 네임스페이스를 생성하고 마스터 데이터를 등록하는 템플릿이 완성되었습니다. 이 파일을 GS2-Deploy 에 업로드함으로써 환경 구축을 할 수 있으므로, 이제 환경을 새로 만드는 것도 더 이상 두렵지 않겠지요.

갱신

GS2-Deploy 는 갱신 처리에서도 영리하게 동작합니다. 이전에 업로드한 템플릿과 새로 업로드한 템플릿의 차이를 감지합니다.

  • 늘어난 것이 있으면 생성
  • 줄어든 것이 있으면 삭제
  • 변경된 것이 있으면 갱신

이러한 동작 덕분에, 하나의 템플릿 파일을 여러 개발자가 편집하더라도 문제가 되지 않습니다.