Cloud Computing On Demand

쿠버네티스 환경에서 자원들을 그룹 단위로 관리하기 위해서 사용하는 것이 labels 이다. labels 를 이용해 key-value 페어로 다양한 속성 값을 지정할 수 있으며, 이렇게 지정한 값들은 --selector 파라메터를 사용하여 아래와 같이 자원을 조회할 때 사용할 수 있다.

$ kubectl get pods --selector env=dev
NAME          READY   STATUS    RESTARTS   AGE
app-1-2k2pg   1/1     Running   0          71s
app-1-bbdsn   1/1     Running   0          71s
app-1-w7d94   1/1     Running   0          71s
db-1-dzcnf    1/1     Running   0          70s
db-1-f6f8m    1/1     Running   0          70s
db-1-lb72h    1/1     Running   0          70s
db-1-tlmjt    1/1     Running   0          70s

kubectl get 구문에서 자원의 형태에 관계 없이 목록을 가져오는 경우 all 을 쓰면 되는 것 같다. 

$ kubectl get all --selector env=prod
NAME              READY   STATUS    RESTARTS   AGE
pod/app-1-zzxdf   1/1     Running   0          6m43s
pod/app-2-hj6qs   1/1     Running   0          6m44s
pod/auth          1/1     Running   0          6m43s
pod/db-2-5nmrk    1/1     Running   0          6m43s

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
service/app-1   ClusterIP   10.106.145.187   <none>        3306/TCP   6m43s

NAME                    DESIRED   CURRENT   READY   AGE
replicaset.apps/app-2   1         1         1       6m44s
replicaset.apps/db-2    1         1         1       6m43s

--selector 는 여러개의 key, value 를 값으로 받을 수 있는데, 아래와 같이 콤마(,)로 구분자를 넣어서 필요한 labels 를 나열하면 된다.

$ kubectl get pods --selector env=prod,bu=finance,tier=frontend
NAME          READY   STATUS    RESTARTS   AGE
app-1-zzxdf   1/1     Running   0          10m

labels 를 활용하여 ReplicaSet 을 만드는 yaml 설정은 아래와 같다.

// replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: replicaset-1
spec:
  replicas: 2
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: nginx
        image: nginx
        
// Create replicaset
$ kubectl create -f replicaset-definition-1.yaml
replicaset.apps/replicaset-1 created

// Check
$ kubectl get pods --selector tier=frontend
NAME                 READY   STATUS    RESTARTS   AGE
app-1-2k2pg          1/1     Running   0          14m
app-1-bbdsn          1/1     Running   0          14m
app-1-w7d94          1/1     Running   0          14m
app-1-zzxdf          1/1     Running   0          14m
app-2-hj6qs          1/1     Running   0          14m
replicaset-1-9hcpb   1/1     Running   0          91s

열심히 공부하고 있는 강의는 위의 링크를 참고하세요!
제휴마케팅을 통해 소정의 수수료를 지급 받을 수 있습니다

grafana 를 쓰면서 각 차트에 alert 를 걸어두는 경우가 종종있습니다. alert 는 기본적으로 텍스트 메세지 템플릿을 사용하기 때문에 이미지가 포함되어 있지 않습니다. 그런데 쓰다보면 항상 알람을 받고 grafana 에 접속해서 차트를 확인하는 일이 빈번하게 발생합니다. false alert 때문에 이런 동작을 반복하다보면 alert 를 무시하다 사고로 이어지는 경우도 생기죠.

문득 든 생각이 <alert 메세지가 차트가 보이면 좋겠구먼> 이었고 공식 가이드에 기술된 내용에 따라 설정을 해보기로 했습니다. 대략 방식을 보면 헤드리스 브라우저를 띄우고 해당 차트에 진입해서 png 파일을 생성해주고 고유 URL 을 만들어 주는 방식처럼 보입니다. 자세한 건 실제로 돌려봐야 알 수 있겠죠?

grafana 에 이미지 렌더링 플러그인 설치하기

이미지 렌더링을 위해서 먼저 grafana lab 에서 제작한 Grafana Image Renderer 플러그인을 설치해야 합니다. 플러그인을 설치하기 위해서는 먼저 Grafana 가 설치된 서버에서 grafana-cli 를 이용해 플러그인을 다운로드 받아야 합니다.

$ sudo /usr/sbin/grafana-cli plugins install grafana-image-renderer
installing grafana-image-renderer @ 2.0.0
from: https://grafana.com/api/plugins/grafana-image-renderer/versions/2.0.0/download
into: /var/lib/grafana/plugins

✔ Installed grafana-image-renderer successfully

Restart grafana after installing plugins . <service grafana-server restart>

rpm 으로 설치해서 그런것인지 OS 버전을 인식하지 않고 메세지를 내보내는 건지 모르겠습니다만, 플러그인 설치후 CentOS 6.x 기준으로 작성된 service 명령 안내가 나옵니다. 7.x 이후 버전을 쓰고 계시다면 아래와 같이 grafana 서버를 재기동 해주셔야 합니다. 

$ sudo systemctl restart grafana-server

차트를 이미지 파일로 렌더링하기

플러그인 설치후 grafana 재기동까지 끝났다면 이제 렌더링이 잘 되는지 시험해 볼 차례입니다. 화면을 그냥 캡쳐하는 것과 무엇이 다르냐 하겠습니다만, 우리의 목적은 단순 캡쳐가 아니라 alert 메세지에 이미지를 포함시키는 것이 목표임을 잊지 마시기 바랍니다. 

각 차트 상단의 toggle 버튼을 누르면 팝업 메뉴에서 `Share` 를 찾을 수 있습니다. 이 버튼을 누르면 나오는 `Share Panel` 에서 가장 아래에 있는 `Direct link rendered image` 버튼을 누르면 짠~ 하고 이미지가 나와야 합니다. 네, 꼭 나와야 합니다. ㅜㅜ

하지만 신은 저를 버리셨는지 차트가 나오지 않고 에러 페이지가 나왔습니다. 무엇이 문제인지 상세히 알려주지 않기 때문에 지금부터 grafana 와 렌더링 오류에 대한 원인을 찾기 위해 씨름을 좀 해야 합니다. 

grafana 렌더링 관련 디버그 로그 설정

공식 가이드에서는 디버깅을 위해 grafana.ini 의 [log] 항목에서 이미지 렌더러를 필터로 걸어서 쓸 것을 권고 하고 있습니다. 하지만 꼭 그렇게 설정하지 않아도 에러 로그를 확인하는데는 문제가 없습니다. 하지만 필요하다면 아래의 내용대로 grafana.ini 를 수정하고 재기동 하면 되겠습니다. 참고로 grafana.ini 의 경로는 패키지 설치 기준으로 `/etc/grafana/grafana.ini` 입니다. 

[log]
filters = rendering:debug

제 경우 굉장히 명확하게 에러가 나왔기 때문에 디버그로 설정할 필요는 없어 보였습니다. grafana 인스턴스와 이미지 렌더러 플러그인이 동일 머신에서 실행중이었기 때문에 localhost 콜을 했지만 https 로 호출된 것이 이유였습니다. 인증서 정보가 맞지 않아 ERR_CERT_COMMON_NAME_INVALID 에러가 발생한 것을 확인할 수 있습니다. 참고로 에러 로그의 경로는 `/var/log/grafana/grafana.log` 입니다. 

t=2021-01-20T17:51:05+0900 lvl=eror msg="Browser request failed" logger=plugins.backend pluginId=grafana-image-renderer failure=net::ERR_CERT_COMMON_NAME_INVALID url="https://localhost:3000/d-solo/Sr8H67hWz/system-metrics?orgId=1&from=1611129063221&to=1611132663221&var-Cluster=All&var-Instance=All&panelId=7&width=1000&height=500&tz=Asia%2FTokyo&render=1" method=GET

grafana.ini 의 [rendering] 설정 수정

SSL 인증서의 문제는 해결이 어렵지 않습니다. grafana-image-renderer 가 사용할 프로토콜은 grafana.ini 에서 지정할 수 있습니다. grafana.ini 파일을 열고 아래와 같이 설정하시기 바랍니다. 로컬 환경에 대한 설정이기 때문에 https 연결 과정의 에러를 무시해도 괜찮습니다.  

[plugin.grafana-image-renderer]
rendering_ignore_https_errors = true

설정을 변경했으면 grafana-server 를 재기동 해줍니다. 

$ sudo systemctl restart grafana-server

재기동이 완료되면 앞서 진행했던 것처럼 차트에서 Share 메뉴를 선택하고 `Direct link rendered image` 를 선택합니다. 이번에는 문제 없이 이미지가 화면에 출력되었습니다. 이렇게 생성된 PNG 파일은 아래의 경로에서 확인할 수 있습니다. 

$ sudo ls -al /var/lib/grafana/png
total 444
drwx------ 2 grafana grafana    134 Jan 21 10:53 .
drwxr-xr-x 5 grafana grafana     66 Jan 21 12:04 ..
-rw-r--r-- 1 grafana grafana 111403 Jan 21 10:46 96YKmq7MmGRTm8rArAMY.png
-rw-r--r-- 1 grafana grafana 109553 Jan 21 10:14 IQkelP0MQ70KVvFyEdeO.png
-rw-r--r-- 1 grafana grafana 111403 Jan 21 10:48 npMRvBsSuPxwDhRESL2n.png
-rw-r--r-- 1 grafana grafana 112893 Jan 21 10:53 xsCpyt0Idc39bKVjf9FL.png

이미지 렌더링에 대한 요청이 많은 것이 아니라 그랬을까요? 공식 문서에서 권장하는 16GB 의 메모리 공간에 택도 없이 부족한 경량 가상머신 장비였지만 렌더링 속도도 느리지 않았고 생성 과정에서 문제도 발생하지 안았습니다. 

Slack Notification 의 설정? 결국 실패

결국 중요한 것은 이렇게 만든 이미지가 슬랙과 같은 서비스로 잘 연동되는지가 중요합니다. 문제는 이렇게 생성된 이미지들이 슬랙에서 보이려면 퍼블릭 인터넷 환경에서 접근이 가능해야 한다는 점이었습니다. 특히 회사 내부에서 사용하는 시스템의 중요한 지표라면 외부에서 아무나 액세스 할 수 있는 공간에 차트를 저장하는 것은 보안상 문제가 될 수 밖에 없습니다. 

결론을 먼저 말씀드리긴 했습니다만, 이렇게 생성한 슬랙으로 전달되지 않았습니다. grafana notification 은 발송이 되지만 이미지 주소가 내부 도메인, 내부 주소를 사용하고 있기 때문에 슬랙이 읽어들여 채널에 렌더링 할 수가 없었습니다. 

grafana 는 위와 같이 Notification 의 대상이 될 수 있는 type 을 제공하고 있습니다. 세번째 컬럼에서 <external only> 로 표기된 서비스들은 설명드린 것처럼 퍼블릭 인터넷 구간에서 접근이 가능한 스토리지를 사용해야만 합니다. S3 와 같은 것이 대표적이겠죠. 이 표기가 없는 Type 의 경우 local 스토리지를 사용할 수 있다고 이해하고 슬랙을 사용해보고자 했지만, 결과적으로는 잘 동작하지 않았습니다. 

에필로그

grafana 에서 슬랙을 액세스 하는 방식은 Incoming Webhook 입니다. 이 방식에서는 파일의 업로드가 제공되지 않습니다. 메세지만 전송할 수 있는 것이지요. 내부 주소를 쓰게 되면 외부 환경에서 VPN 등의 연결이 필요한 상황이 또 발생하니 좋은 접근이 되기는 어렵습니다. 애초부터 문제 상황을 한번에 알기 위해서 이미지를 메세지에서 보여주려는 것이었는데 보안상 불가하다가 된 상황입니다. 

외부 액세스가 문제 없는 이미지들이라면 (과연 존재할까요?) 공식 문서의 external_image_storage 섹션을 확인하여 S3 등을 타겟으로 설정해서 쓰시면 되겠습니다. 결과적으로 도움이 안되는 포스팅이 되버린 것 같아 속상합니다만...ㅎㅎ 사내용 이미지를 grafana notification + slack 으로 해결해 보신 경우가 있다면 댓글로 도움 말씀 부탁드리겠습니다!

한 번 설치해서 잘 돌아가는 시스템을 업그레이드 하는 것은 참 귀찮은 일입니다. 하지만 새로운 버전에서만 쓸 수 있는 기능이 생겼고 이를 사용해야 하는 경우엔 어쩔수 없이 업그레이드를 선택하게 되죠. 여기저기에서 마구 설치해서 사용하고 있는 grafana 역시 새로운 버전이 종종 등장하고 있어 가끔씩 업데이트 해줘야 새로운 기능을 활용할 수 있습니다. 

오래전에 설치해 사용하던 grafana 를 업그레이드하려다 보니 혹시나~ 하는 생각이 들어서 방법을 정리해 봅니다. 쓰시는 분이 많지 않아 업그레이드의 부담은 없었지만, grafana 공식 페이지의 문서가 보기가 좀 불편한 점들도 있어서 추후 작업을 위해 이력을 남기는 차원입니다 ㅎㅎ

설치된 grafana 버전 확인하기

꼭 필요한 과정은 아니지만 설치된 grafana 패키지의 버전을 확인해보겠습니다. 권한에 따라 sudo 명령을 곁들여 주시면 맛이 더욱 훌륭합니다. 6.6.1 버전이니 오래된 유물급까지는 아니지만 꽤 오래된 버전입니다. 제 경우 yum 으로 설치하긴 했지만, grafana 의 공식 repo 를 쓰지 않고 grafana 웹 페이지에서 rpm 을 다운로드 받아 yum 으로 localinstall 했습니다. 

$ sudo yum list grafana
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
Installed Packages
grafana.x86_64                      6.6.1-1                        installed

grafana.db 파일 백업하기

grafana 의 설정을 sqlite (기본 값) 로 해두었다면 grafana.db 파일을 백업해야 합니다. mysql 등의 다른 DB 를 사용했다면 해당 DB 의 데이터베이스나 테이블 내용을 백업해야 합니다. sqlite 는 파일 기반 DB 라 백업도 간편하죠. 패키지를 설치했을 경우 경로는 아래와 같으며, 파일을 그대로 다른 경로에 옮겨두면 나중에 복원시 사용할 수 있습니다. 

$ mkdir backup
$ cp /var/lib/grafana/grafana.db ./backup/

새로운 버전의 rpm 다운로드 받기

기억이 맞다면 repo 를 등록해서 yum 으로 패키지 설치를 하지 못했었는데... 일단 현재는 가능한 것 같습니다. repo 를 등재하여 별도 다운로드 없이 패키지를 설치하셔도 되고, 저처럼 rpm 을 받아 설치해도 무방합니다. 

# RPM 다운로드 경로 : grafana.com/grafana/download

# yum repo 등록후 설치 가이드 (CentOS 기준) : grafana.com/docs/grafana/latest/installation/rpm/

$ wget https://dl.grafana.com/oss/release/grafana-7.3.7-1.x86_64.rpm
--2021-01-20 16:29:54--  https://dl.grafana.com/oss/release/grafana-7.3.7-1.x86_64.rpm
Resolving dl.grafana.com (dl.grafana.com)... 151.101.198.217, 2a04:4e42:2e::729
Connecting to dl.grafana.com (dl.grafana.com)|151.101.198.217|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 53729497 (51M) [application/x-redhat-package-manager]
Saving to: ‘grafana-7.3.7-1.x86_64.rpm’

100%[============================================================================>] 53,729,497  13.5MB/s   in 5.6s

2021-01-20 16:30:00 (9.07 MB/s) - ‘grafana-7.3.7-1.x86_64.rpm’ saved [53729497/53729497]

FINISHED --2021-01-20 16:30:00--
Total wall clock time: 6.1s
Downloaded: 1 files, 51M in 5.6s (9.07 MB/s)

yum 으로 rpm 업그레이드 하기

이제 다운로드 받은 파일을 설치하도록 하겠습니다. `yum localinstall` 로 설치한 rpm 패키지는 `yum localupdate` 로 업데이트 할 수 있습니다. yum repo 를 사용하는 경우 `yum install` 과 `yum update` 를 설치와 업그레이드에 각각 사용하는 것과 마찬가지입니다. 

$ sudo yum localupdate grafana-7.3.7-1.x86_64.rpm
Loaded plugins: fastestmirror, langpacks
Examining grafana-7.3.7-1.x86_64.rpm: grafana-7.3.7-1.x86_64
Marking grafana-7.3.7-1.x86_64.rpm as an update to grafana-6.6.1-1.x86_64
Resolving Dependencies
--> Running transaction check
---> Package grafana.x86_64 0:6.6.1-1 will be updated
---> Package grafana.x86_64 0:7.3.7-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

======================================================================================================================
 Package                 Arch                   Version                 Repository                               Size
======================================================================================================================
Updating:
 grafana                 x86_64                 7.3.7-1                 /grafana-7.3.7-1.x86_64                 170 M

Transaction Summary
======================================================================================================================
Upgrade  1 Package

Total size: 170 M
Is this ok [y/d/N]:y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : grafana-7.3.7-1.x86_64                                                                             1/2
  Cleanup    : grafana-6.6.1-1.x86_64                                                                             2/2
POSTTRANS: Running script
  Verifying  : grafana-7.3.7-1.x86_64                                                                             1/2
  Verifying  : grafana-6.6.1-1.x86_64                                                                             2/2

Updated:
  grafana.x86_64 0:7.3.7-1

Complete!

확인!

이제 문제 없는지 확인을 해야겠죠? 웹 브라우저로 grafana 에 접근하여 좌측 하단에 있는 ? 버튼을 눌러 버전을 확인해 봅니다. 다행히도 백업한 파일을 사용할 일 없이 마무리가 잘 된 것 같습니다. 

Kubenetes 를 사용하면서 namespace 를 통해 큰 단위의 리소스 구분을 해줘야 하는 경우가 종종 생깁니다. namespace 를 감안하여 사용할 수 있는 몇 가지 명령어들 중 udemy 강의 실습에서 나온 커맨드를 정리해 봅니다. 몇 일 쉬고 다시 들으려니 또 까먹은 것들이 많아서 당혹스럽네요 ㅜㅜ 듣고 있는 CKA Udemy 강의는 아래 링크입니다. 

redis 이미지를 사용하는 간단한 pod 생성 코드

apiVersion: v1
kind: Pod

metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis

Pod 를 특정 Namespace 에 생성하기

kubectl create -f pod.yaml --namespace=finance

모든 Namespace 의 Pod 목록 확인하기

kubectl get pods --all-namespaces

특정 Namespace 의 Pod 목록 확인하기

kubectl get pods --namespace=research

redis 이미지를 사용하는 간단한 pod 생성 코드 + namespace 지정

apiVersion: v1
kind: Pod

metadata:
  name: redis
  nemaspace: finance <-- 추가된 부분
spec:
  containers:
  - name: redis
    image: redis

기본 namespace(default) 를 특정 namespace 로 고정하기

// 현재의 context 를 가져온 뒤 research namespace 를 기본 값으로 변경
kubectl config set-context $(kubectl config current-context) --namespace=research

namespace 의 생성

// yaml 을 이용하는 방법
// namespace.yml
apiVersion: v1
kind: Namespace
metadata:
  name: new-namespace

// 생성한 파일을 이용하여 namespace 생성 
$ kubectl create namespace -f namepsace.yml

// 커맨드라인 명령으로 namespace 생성
kubectl create namespace new-namespace

본 포스팅은 제휴마케팅 링크를 포함하고 있으며 소정의 수수료를 지급받을 수 있습니다. 

CKA (Certified Kubenetes Administrator) 시험을 꽤 실무적인 시험으로 알려져 있습니다. 단답형 지식을 묻는 질문이 주류를 이루고 있어 스펙을 많이 기억해야 하는 다른 시험과 달리 실제 터미널 환경에서 쿠버네티스에 대한 컨트롤을 얼마나 잘 하고 이해하고 있는지를 확인하는 시험입니다. 네, 아직 취득한건 아닙니다 ㅎㅎ 

원격으로 감독관이 컴퓨터 환경을 감시(?)하며 시험이 진행된다고 알려져 있어서 따로 정리한 레퍼런스를 활용하는 것이 어렵다고 합니다. 따라서 유용한 커맨드들을 기억해 두고 시험에 임하면 좋다고 하네요. 듣고 있는 강의에서 정리해준 몇 가지 커맨드를 잊지 않기 위해 정리해 봅니다. 

NGINX Image 를 이용하여 NGINX Pod 생성하기

kubectl run nginx --image=nginx

Deployment 생성하기

kubectl create deployment --image=nginx nginx

Deployment 구성을 위한 Yaml 템플릿 생성하기 (단, 배포 없이)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Deployment 구성을 위한 Yaml 템플릿을 4개 ReplicaSets 를 갖는 구성으로 생성 (단, 배포 없이)

kubectl create deployment --image=nginx nginx --dry-run=client --replicas=4 -o yaml > nginx-deployment.yaml

예제 시험문제를 몇 가지 풀다보니 손으로 Yaml 파일을 구성해야 하는 시나리오가 종종 나오는 것 같습니다. 시행착오를 줄이고 시간을 단축하기 위해, 위의 명령들로 템플릿을 생성해서 변경하는 방식이 아무래도 시험 볼 때 마음을 편안하게 해주겠죠? 기초적인 명령들이지만 익숙하지 않다보니... 일단 여기까지!

본 포스팅은 제휴마케팅 링크를 포함하고 있으며 소정의 수수료를 지급받을 수 있습니다. 

2021년이 밝았습니다. 새해가 되면 여러가지 계획을 세우기 마련인데요, 작심삼일이 되지 않도록 3일마다 마음을 다잡을 필요가 있습니다. 계획성 있게 하기에 좋은 것이 역시 자격증 취득인지라, 기술 습득과 자격 취득을 한번에 할 수 있는 좋은 자격 프로그램들이 많습니다.

그 중에서도 IT 직군에 계신 분들이 가장 관심이 많은 것이 AWS 의 자격증들일 것입니다. 그 시작점이라고 할 수 있는 자격증이 Solutions Architet Associate 라고 생각합니다. 저 역시 2019년 11월에 취득을 했는데요, 공부 방법을 간단하게 정리해 보았습니다.

AWS SAA 시험의 개요

AWS 의 Solutions Architect 시험은 AWS 의 제품들을 잘 이해하여 비즈니스 요구사항을 수용할 수 있는 인프라 환경을 설계할 수 있는 능력을 시험합니다. 방대한 AWS 제품들을 공부해야 하기 때문에 계획성 있게 학습하는 것이 중요합니다. 

특히 SAA 시험은 고객의 비즈니스 상황, 문제 시나리오에 대하여 어떤 식으로 대응할 것인지를 묻는 문제들이 여럿 출제됩니다. 따라서 문제 상황을 잘 이해하고 적절한 해결 방안을 AWS 의 제품, 그리고 제품의 특징을 활용하여 해소할 수 있는 방법을 제시해야 합니다. 이같은 시험 문제 패턴은 시험 요강에서도 확인할 수 있습니다. 

상당히 실무적인 시험이기 때문에 실전 경험이 많다면 자격증을 준비하는 것이 훨씬 수월합니다. 하지만 실전 경험이 부족하다 하더라도 다양한 자료를 통해서 학습하고 시험에 응시하여 충분히 취득할 수 있는 자격이기도 합니다. 어떤 방향으로 공부를 해야 하는지 역시 공식 가이드에 잘 나타나 있습니다. 

공식 시험 가이드 및 자료

시험에 대한 공식 가이드가 상당히 자세히 제공됩니다. 가장 먼저 보면 좋은 자료는 예제 문항과 시험 안내서입니다. 흔히 자격시험은 기출문제 풀이나 족보를 찾기 십상인데요 제대로 실력을 함양하기 위해서는 덤프는 가능한 보지 않을 것을 권장드립니다. 대신 온라인 강의 등에서 챕터별로 제공되는 연습문제를 충실히 풀어내면 합격하는데 큰 지장은 없습니다. 

> AWS 공식 시험 준비 가이드 [바로가기]
> AWS 시험 안내서 [바로가기] - 출제 비중에 관한 내용이 언급되어 있습니다
> SAA 시험 공식 예제 [바로가기] - 공부 시작전에 꼭 읽어보시기 바랍니다!

글을 적으며 Udemy 에 들어가보니 2021 년 새해를 맞이하여 Udemy 에서 연습문제를 20달러에서 9.99달러로 할인 판매를 하고 있습니다. 1월 4일까지 할인이라고는 하지만 연장될 수도 있으니 관심 있는 분들은 구입해 보시는 것도 좋겠습니다! 참고로 AWS 공식 시험 등록 센터에서는 20달러에 판매됩니다. (65문항씩 6개의 시험 자료가 들어가 있습니다)

추천 온라인 강의 - Udemy

유튜브나 블로그에도 좋은 자료를 정리해 주신 분들이 많습니다. 하지만, 개인적으로 추천드리는 것은 Udemy 의 아래 강의입니다. 영어 발음도 또렷해서 듣기에 어렵지 않고, 시험을 영어로 치는 경우에 많은 도움이 됩니다. 짧은 동영상들로 구성되어 있어 출퇴근길에 한 두개씩 듣거나, 화장실, 산책길에 틈틈히 학습하기에 좋습니다. 

요즘 강의 시장도 경쟁이 치열하다보니 구입한 강의에 대한 유지보수(?)도 잘 됩니다. AWS 는 지속적으로 개선되고 진화하고 있기 때문에 주기적으로 시험도 갱신이 됩니다. 이 강의를 제공하는 Ryan 님도 [SAA-C02] 등으로 최신 시험 범위에 맞추어 컨텐츠를 계속 업데이트 해주고 있습니다. 

지금 보니 제가 구입한 이 강의도 9.99 달러로 2021년 얼리버드 할인이 진행중이네요! 저는 거의 2만원돈 주고 샀던것 같은데... 여러분 꿀 기회를 놓치지 마십시오! 뭘 하던간에 연초에 하나 정도 몰아쳐야 한다는 것, 다들 아시죠? 인간의 의지는 박약합니다!

[ Udemy - AWS SAA-02 시험 강의 살펴보기 (바로가기) ]

(2021.08 업데이트) Cloudguru가 Pluralsight에 인수되면서 강의들이 Udemy에서 일단 다 빠진 것 같습니다. 그 다음으로 대권(?)을 잡은 강의를 추천해 드립니다! Cloudguru의 Ryan님이 미국 스타일의 발음으로 유쾌한 강의를 해주었다면, Stephane님의 아래 강의는 제2외국어로 영어를 배운 사람의 느낌으로 조금 더 편안한(?) 발음으로 강의를 해주고 있습니다. 그래도 꼼꼼히 시험에 필요한 것들과 AWS의 기초 지식을 잘 챙겨주고 있다는 점에서는 동급 최강이라 하겠습니다! 2021년 버전으로 업데이트가 되었으니 한 번 살펴보시기 바랍니다!

[ Stepane님의 AWS SAA-C02 시험 강의 살펴보기 (바로가기) ]

시험 등록

재미있는 것은 시험을 위한 연습 시험도 유료로 볼 수 있습니다. 최근에 취득한 자격이 AWS 자격증 하나이다보니 다른 기술 자격증도 이런 유료 연습 시험이 있는지는 잘 모르겠습니다. 비용은 20달러로 크게 부담되지 않지만 꼭 쳐봐야 하는 것은 아닙니다. 앞서 말씀드린 것처럼 연초 얼리버드 할인 9.99 달러 행사중이니 필요하신분은 공식 사이트 대신 Udemy 에서 구입하시면 좋을 것 같습니다.

시험은 150 달러로 비싼편은 아닙니다. 한국어로 시험을 볼 수도 있지만 그냥 영어로 보는 것이 훨씬 편합니다. AWS 의 한글 자료들이 잘 되어 있는 편이긴 하지만 꼼꼼히 보다보면 번역기를 돌렸거나 비전공자가 번역하여 문제가 있는 경우들이 종종 발견됩니다. 영어로 보고, 영어로 시험 보는 것이 베스트입니다.

[ 시험등록하러 가기 (바로가기) ]

올 한해는 연초부터 좀 달려보려고 이것저것 공부를 하고 있습니다. AWS 도 SAA 취득한지 1년이 넘었으니 다른 자격증을 준비해 보려는 중입니다. 여러분들도 힘차에 2021년을 시작하는 의미에서 자격증 취득 어떠십니까? :-)

본 포스팅은 직접 돈내고 취득한 AWS 자격증 이야기 입니다.
다만, 제휴마케팅을 통해 소정의 수수료를 받을 수 있습니다.

두 번의 포스팅을 통해 VPC 와 Gateway 를 생성했습니다. 그럼 EC2 를 바로 만들면 되나요? 라고 생각하실 수 있겠습니다만 일단은 생성한 VPC 가 Gateway 를 통해 인터넷과 교감을 할 수 있도록 라우팅 테이블 Routing Table 을 설정하는 작업을 먼저 진행해 보겠습니다. 사실 순서는 큰 상관이 없지만 <네트워크에 대한 작업> 을 마무리하고 <서버에 대한 작업>을 한다고 생각하시면 좋겠습니다. 

1.4 Routing Table 조정

라우팅 테이블 Routing Table 은 VPC 로 들어오는 트래픽과 나가는 트래픽에 대한 경로를 지정해 주는 역할을 합니다. 물론 라우팅 테이블만 설정했다고 하여 모든 통신이 정상적으로 이루어지는 것은 아닙니다. 말 그대로 경로에 대한 지정일 뿐, 실제 트래픽을 허용할 것인지는 Network ACL 과 Security Group 을 통해 IP 주소 대역, 포트 단위로 결정됩니다.

라우팅 테이블을 설정하기 위해서는 VPC 제품 하위 메뉴에 위치한 <Route Tables> 를 통해 진행할 수 있습니다. 기본적으로 VPC 가 생성되면 VPC 에 대한 기본 라우팅 테이블이 자동으로 생성됩니다. 기본 라우팅 테이블은 VPC 에 할당된 IPv4, IPv6 주소를 대상으로 VPC 내에서 (=local) 통신이 가능하도록 하는 정책만 들어 있는 상태입니다.

우리가 해야하는 일은 위 이미지의 핑크색 상자에 들어 있는 내용과 같이 외부로 부터의 트래픽 송수신을 위한 정책을 추가하는 것입니다. IGW (Internet Gateway) 로는 SSH 접근을 위해 IPv4 에 대한 정책을 추가했고, EIGW (Egress Only Internet Gateway) 에는 실제 v6 주소 목적지에 대한 VPN 터널링을 위해 IPv6 주소에 대한 정책을 추가했습니다.

정책 추가를 위해 라우팅 테이블 목록에서 IPv6 용으로 만든 VPC 에 할당된 기본 라우팅 테이블을 선택합니다. Actions 버튼을 누르지 않아도 화면 아랫쪽에서 <Routes> 탭을 선택하면 라우팅 테이블에 대한 상세 정책 목록이 출력됩니다. 정책 추가를 위해 <Edit routes> 버튼을 누르겠습니다. 

IPv4 의 모든 주소를 나타내는 CIDR block 은 0.0.0.0/0 으로 표기되며, IPv6 의 모든 주소를 나타내는 CIDR block 은 ::/0 으로 표기합니다. 목적지 주소에 v4, v6 에 대한 CIDR block 을 추가하고 v4 는 IGW 로, v6 는 EIGW 를 이용하도록 대상(Target) 제품을 지정해 줍니다. 이미 생성한 IGW 와 EIGW 가 드롭 다운 목록에 노출되기 때문에 설정은 쉽게 하실 수 있습니다. 경로 입력이 끝나면 우측 하단의 <Save Routes> 버튼을 누릅니다. 

1.5 IPv6 주소를 갖는 EC2 인스턴스 배포

네트워크의 구성이 끝났으니 이제 실제 OpenVPN 바이너리가 구동되고 목적이 v6 주소까지 터널링을 해줄 EC2 인스턴스를 생성해 보도록 하겠습니다. 사용자가 얼마나 많은지, 트래픽 규모가 어떠한지에 따라 인스턴스 타입이 결정되어야 하겠지만, 이 포스팅에서는 AWS 무료 티어에서도 사용할 수 있는 t2.micro 타입의 인스턴스를 사용하도록 하겠습니다. 소규모의 사용량이라면 이 인스턴스로도 큰 문제가 없습니다. 

EC2 인스턴스의 생성은 많이들 해보셨을 작업이기 때문에 주의할 점을 중심으로 설명드리겠습니다. EC2 생성 마법사의 세번째 단계에는 IP 주소 할당에 대한 정책을 선택하도록 되어 있습니다. 우리가 진행하는 OpenVPN 은 단일 인스턴스 환경이기 때문에, 해당 서버가 사용자들로부터 IPv4 를 통해 VPN 연결을 시도할 수 있어야 하고, IPv6 주소를 보유하여 v6 주소를 갖고 있는 목적지 서버와 연결할 수 있어야 합니다. 

이 목적을 달성하기 위해서는 <3. Configure Instance> 단계에서 하단에 있는 <Auto-assign Public IP> 와 <Auto-assign IPv6 IP> 를 Enable 로 선택하여 v4 와 v6 를 통해 공인 IP 를 사용할 수 있도록 해야 합니다. 그런데 IPv6 는 왜 <Public> 이라는 말이 없을까요? 기본적으로 IPv6 주소 체계는 Private / Public 를 가지고 있지 않습니다. 따라서 옵션의 이름도 단순히 <Auto-assign IPv6 IP> 라고 되어 있다는 점 참고하시기 바랍니다!

EC2 생성 마법사를 완료하고 인스턴스 생성을 기다립니다. 생성이 완료되면 위와 같은 화면을 볼 수 있게 됩니다. 다른 기본적인 사항은 특별히 확인할 내용이 없고, 네트워킹 Networking 탭을 중심으로 살펴보면 됩니다. 설명했던 것처럼 v4 는 Private, Public 의 주소가 할당되지만 v6 는 하나의 주소만 할당된 것이 보입니다. 이제 인프라의 준비가 끝났습니다. 

다음 포스팅에서는 OpenVPN 을 인스턴스에 설치하는 작업을 해보도록 하겠습니다. 

9월에 첫 포스팅을 올리고 시간이 너무 많이 흘렀습니다. 기억이 더 가물가물 해지기 전에 OpenVPN 구축 포스팅을 마무리 해볼까 합니다. 지난 포스팅에서 우리는 `IPv6 대역을 갖고 있는 VPC 생성` 을 했고 `VPC 내에 Public Subnet 생성` 까지 완료했습니다. 자세한 내용은 아래 링크를 통해 지난 포스팅을 참고하시기 바랍니다!

1.3. Gateway 구성

1.3.1. Internet Gateway

OpenVPN 을 이용한 IPv6 VPN 구성시 VPC 에는 두개의 Gateway 가 필요합니다. 보통 v4 주소 환경에서 인터넷으로 나가고 들어오는 트래픽 처리를 위해 사용하는 Internet Gateway 가 첫번째 요소입니다. v4 주소라고 명기한 것은 다 이유가 있겠죠? Internet Gateway 는 나가는 트래픽, 즉 아웃바운드 트래픽에 대하여 IPv6 주소를 처리하지 못합니다. 이 때문에 별도로 Egress Only Gateway 를 구성해야 합니다.

정리를 잘 해두기 위하여 위의 내용은 취소선으로만 표기하고 나두었습니다. AWS 에서 제공하는 Gateway 에는 Internet Gateway 와 Egress Only Internet Gateway 가 있습니다. Internet Gateway 는 양방향 (Inbound, Outbound) 의 인터넷 트래픽을 위해 사용하는 구성 요소이고 Egress Only Internet Gateway 는 단방향 (Outbound) 전용 게이트웨이 입니다. 

왜 그렇게 기억하고 있었는지 모르겠지만 OpenVPN 을 통해 실제 IPv6 를 사용하는 서버까지 터널링을 위해서 꼭 Egress Only Internet Gateway 를 사용할 필요는 없습니다. 다만, 각 인스턴스로 IPv6 로 요청이 들어오지 않도록 확실히 분리할 필요가 있다면 IPv6 터널링 용으로 Egress Only Internet Gateway 를 사용하면 됩니다.

Internet Gateway 를 생성하기 위해 VPC 제품 페이지에서 Internet Gateway 메뉴로 들어갑니다. 별도의 VPC 를 만들었기 때문에 Default VPC 에 있는 Internet Gateway 를 사용할 수는 없습니다. Internet Gateway 는 VPC 단위로 연결할 수 있다는 것도 기억해 두면 좋겠습니다. 제 경우 구분을 위해 Tag 에 "ipv6" 를 넣어주었습니다.

Internet Gateway 가 생성되면 어떤 VPC 와도 연결되어 있지 않은 상태입니다. 아래의 화면에서 보이는 것처럼 Detached 라는 메세지가 연결된 VPC 가 없다는 것을 알려줍니다. 우측 상단의 "Actions" 버튼을 눌러 앞서 생성한 VPC 에 연결(Attach) 해보도록 하겠습니다. 

앞서 가이드 했던 것처럼 VPC 생성시에도 Tag 를 잘 달아두었다면 Attach to VPC 를 하는 과정에 어려움 없이 VPC 를 잘 선택할 수 있습니다. 물론 제 경우 VPC 가 하나라서 Tag 가 있고 없고 상관은 없습니다만 규모가 좀 되는 인프라를 운영중이시면 Tag 가 확실히 도움이 될 겁니다. VPC 를 선택후 <Attach internet gateway> 버튼을 눌러 연결 작업을 마무리 합니다. 

연결 작업이 정상적으로 완료되면 아래와 같은 Summary 화면을 보게 됩니다. 연결한 내용에 이상이 없는지 한 번 살펴보고 지나가시면 됩니다. 

1.3.2. Egress Only Internet Gateway

설명했던 것처럼 VPN 연결은 IPv4 로만 허용하고 터널링은 IPv6 를 쓰기 위해 Egress Only Internet Gateway 를 따로 만들어 보도록 하곘습니다. AWS 의 제품 설명 페이지를 유심히 읽어 보셨다면 아시겠지만 Egress Only Internet Gateway 는 IPv6 전용입니다. IPv4 를 터널링 한다면 Internet Gateway 만 사용하는 것으로 충분합니다. 

VPC 화면의 메뉴중 <Egress Only Internet Gateway> 를 선택합니다. 새로운 Egress Only Internet Gateway 를 아래 화면처럼 생성하도록 하겠습니다. 일반 Internet Gateway 와 특별히 차이가 없기 때문에 Tag 지정만 유의해서 진행하시면 되겠습니다. VPC 목록에도 Tag 가 표시되기 때문에 VPC 생성시 Tag 를 잘 달아두었다면 어려움 없으실 겁니다. 

생성된 Egress Only Internet Gateway 는 eigw 로 시작되는 고유 ID 를 갖게 됩니다. Internet Gateway 의 생성 화면과 달리 생성 할때 이미 VPC 를 지정했기 때문에 별로도 Attach 하는 과정이 나오지는 않습니다. 비슷한 제품인데 담당 조직이 다른지 생성 화면과 절차가 차이가 있네요? Egress Only Internet Gateway 가 훨씬 편한 것 같습니다 ^^

이번 포스팅에서는 두개의 Internet Gateway 를 생성해 보았습니다. 다음 포스팅에서는 VPC 의 라우팅 테이블을 설정하여 OpenVPN 트래픽이 정상적으로 EC2 를 통해 연결되고 터널링 될 수 있도록 해보겠습니다.