[NCP] 네이버 클라우드 스터디 후기(2024.08.17)

지난 8월 17일 또 한번의 네이버 클라우드를 학습할 기회가 있어 참석했습니다.

이번에는 DNS와 GSLB를 통해 CSP를 이용한 이중화 방법에 대해 알아보고 테라폼을 통해 서비스를 배포해 보았습니다.

 

스터디자료

https://brunch.co.kr/@topasvga/3938

21탄-1. DNS로 CSP이중화 -2024-08

 

클라우드 환경에서의 DNS?

클라우드 환경에서 DNS을 운영한다면 DNS서버를 굳이 안해도 된다.(비용절감)

Route53은 DNS와 GSLB의 기능을 동시에 할 수 있다

재해복구에 대비하는 방법은 DNS레코드, GSLB를 사용하는 방법이 있다.

GSLB를 이용한 복구는?

• 현업에서는 의사결정권자의 결정이 있어야 작업을 수행하기 때문에 자동으로 복구하는 시스템이 마냥 좋은 것만은 아니다.
• 수동으로 살리는 방법 - 안정성 중요
• 자동으로 살리는 방법 - 빠르게 살리는게 중요(deamon 이용)

GSLB를 구성하는 방법

1. 정책을 설정한다
2. 도메인을 설정한다.
3. DNS record CNAME을 등록한다.

멀티 클라우드 운영시 고려할 사항

1. Network block 운영에 대한 관리계획이 중요하다(네트워크 설계)
2. 비용처리 계획
   - AWS Organizations
   - Payer 계정을 묶어서 처리하기(세금계산서를 하나로 발급)

NLB뒤에 ALB를 구축하는 아키텍처?

대부분의 로드밸런서는 유동IP를 제공하고 기업에서는 해당 IP를 고정하는 요구사항이 있다.(제한된 네트워크 환경), 여기서 ALB의 앞단에 NLB를 사용한다면 고정된 IP로 ALB와의 연결을 유지할 수 있다.

Architecture에는 정답이 없다.

• 기업의 규모 환경에 따라 기업이 적용할 수 있는 아키텍처에는 한계가 있다.
• 금융권은 ISMS, 망분리 규제에 따른 엄격한 규제가 따른다. → 이중화 및 재해복구 요구사항이 존재(즉, 비용이 많이 든다)

아키텍처는 무조건 안정적이고 이중화 구성이 필수적이라고 생각했는데 이 말을 듣고 보니 기업의 상황에 맞는 인프라 구조를 생각해야 하는 것을 알게 되었습니다.

인프라를 코드로 관리하는 방법

처음부터 코드로 인프라를 작성하기란 쉽지 않다. 콘솔로 생성 이후 코드로 변환하는 작업이 필요하다. → 어떤 구성요소가 필요한지 파악해야 한다.

전자금융, ISMS 등에서 인프라를 코드로 관리해서 휴면에러를 줄일 수 있도록 구성한다.

실습 [Terraform으로 NKS 배포]

테라폼을 이용하여 NKS환경을 구축하고 2048게임과 슈퍼 마리오를 배포해 보았습니다.

실습코드

#ncloud CLI 다운로드
wget https://www.ncloud.com/api/support/download/files/cli/CLI_1.1.20_20240620.zip
unzip CLI_1.1.20_20240620.zip
cd CLI_1.1.20_20240620/
cd cli_linux/
cp ncloud /usr/bin/
ncloud help

ncloud configure
#액세스 키 입력  
#시크릿 키 입력


#테라폼 설치하기
sudo yum install -y yum-utils shadow-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo
sudo yum -y install terraform
terraform -version


#사용을 위한 인증
#ncp-iam 설치
curl -o ncp-iam-authenticator -L https://github.com/NaverCloudPlatform/ncp-iam-authenticator/releases/latest/download/ncp-iam-authenticator_linux_amd64

chmod +x ./ncp-iam-authenticator

mkdir -p $HOME/bin && cp ./ncp-iam-authenticator $HOME/bin/ncp-iam-authenticator && 
export PATH=$PATH:$HOME/bin

echo 'export PATH=$PATH:$HOME/bin' >> ~/.bash_profile

ncp-iam-authenticator help


쿠버네티스 인증
cd
ncp-iam-authenticator create-kubeconfig --region KR --clusterUuid [Cluster-UUID] --output kubeconfig.yaml

#kubectl 명령어 설치
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

#환경변수 추가
vi  ~/.bash_profile  

맨 아래줄에 아래 내용 추가
alias k='kubectl --kubeconfig="/root/kubeconfig.yaml"'
alias kw='watch -d kubectl get deploy,svc,pods --kubeconfig="/root/kubeconfig.yaml"'

source ~/.bash_profile
k get nodes

 

테라폼으로 NKS구축

main.tf

provider "ncloud" {
  support_vpc = true
  region      = "KR"
  access_key  = var.access_key
  secret_key  = var.secret_key
}

resource "ncloud_login_key" "key_scn_01" {
  key_name = var.name_vpc
}

resource "ncloud_vpc" "vpc_vpc" {
  name            = var.name_vpc
  ipv4_cidr_block = "10.0.0.0/21"
}

resource "ncloud_subnet" "subnet_pub1" {
  name           = var.name_pub1
  vpc_no         = ncloud_vpc.vpc_vpc.id
  subnet         = "10.0.2.0/24"
  zone           = "KR-1"
  network_acl_no = ncloud_vpc.vpc_vpc.default_network_acl_no
  subnet_type    = "PUBLIC"
  // PUBLIC(Public) | PRIVATE(Private)
}

 

variables.tf

variable name_vpc {
  default = "agame-dev-vpc"
}

variable name_pub1 {
  default = "agame-dev-pub1"
}

variable client_ip {
  default = "3.3.3.3"
}

variable access_key {
  default = "NCP ACCESS KEY"
}

variable secret_key {
  default = "NCP SECRET KEY"
}

versions.tf

terraform {
  required_providers {
    ncloud = {
      source = "navercloudplatform/ncloud"
    }
  }
  required_version = ">= 0.13"
}

클러스터 생성완료

게임 Deployment 생성

2048

cat <<EOF | k create -f -

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-2048
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: app-2048
  replicas: 2
  template:
    metadata:
      labels:
        app.kubernetes.io/name: app-2048
    spec:
      containers:
      - image: alexwhen/docker-2048
        name: app-2048
        ports:
        - containerPort: 80
EOF

 

실행명령어

k expose deployment deployment-2048 --port=80 --type=LoadBalancer

mario

cat <<EOF | k create -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mario
  labels:
    app: mario
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mario
  template:
    metadata:
      labels:
        app: mario
    spec:
      containers:
      - name: mario
        image: pengbai/docker-supermario
---
apiVersion: v1
kind: Service
metadata:
   name: mario
spec:
  selector:
    app: mario
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080
  type: LoadBalancer
EOF

실행명령어

k expose deployment mario --port=80 --type=LoadBalancer

 

 

결과

kw

 

 

2048배포 성공~

 

마리오 배포성공~!

 

추가실습 GSLB구성

Route53 도메인 등록

가중치기반 테스트

동작확인

접속 시 번갈아가며 접속이 된다.

 

장애조치 라우팅 테스트

상태검사 구성

 

레코드 수정(가중치 → 장애조치)

Secondary 장애조치 레코드 구성(마리오 게임)

 

테스트

실행 중인 2048 서비스 replica 0으로 줄이기

k scale deployment deployment-2048 --replicas=0

페이지 미동작 확인

상태검사 확인

 

상태검사를 구성하고 테스트를 했는데 내 생각처럼 마리오 게임으로 넘어가지 않았다. 그래서 다시 확인해 보니...

장애조치 레코드 2048, 마리오 게임의 상태검사를 동일한 것을 사용하고 있었기 때문에 2048이 내려갔어도 라우팅이 되지 않은 것 즉, 2048이 다운되면 Route53은 상태검사 시 정상인 마리오 게임으로 넘어갔어야 했는데 동일한 상태검사를 사용하고 있어 둘 다 Fail이 나버린 것이었다. 그래서 2048과 마리오 게임에 대한 상태검사를 각각 구성해 주었다.

상태검사 재구성

2048 레코드와 마리오 게임에 대한 상태검사를 별도로 구성하고 레코드가 참조하는 상태 확인 ID도 수정해 주었다.

장애조치 라우팅 확인(2048 Failover → Mario)

2048 서비스 복구

장애조치 복구 확인(Mario → 2048)

 

추가(네이버 클라우드 서버 인증키 삭제)

테라폼으로 실습 진행 시 다시 실행할 경우 서버인증키 중복으로 인해 apply 중 에러가 발생함(키중복)

Services > Server > [서버관리 및 설정 변경] > 인증키 관리에서 키 삭제 가능

마치며

이번 스터디에서는 저번 스터디에서 구성했던 코드를 가지고 2048게임과 마리오 게임을 배포해 보았는데 2번째로 하니 진행이 수월했습니다. 물론 도메인을 가지고 계시는 분이 많지 않기 때문에 집에 와서 GSLB, DNS를 테스트해보았는데 실제로 Fail이 되었을 때 전환을 해주는 것을 보니 신기했고 직접 구성해 보는 것은 처음이라 힘들었지만 조금은 더 알아가는 것 같습니다.(역시 실습이 최고...)

사실은 쿠버네티스에 대한 개념을 파악하고 사용해야 한다는 주의라 실습을 잘 안 해왔었는데 쿠버네티스는 실제로 구축, 배포를 해보며 서비스를 뜯어보는 게 이해가 잘 되는 것 같아 앞으로 많이 사용해보려 합니다.

실습 따라 하시는 분들은 참고해서 하시면 좋을 것 같습니다. 긴 글 봐주셔서 감사합니다!