Cloud Computing On Demand

참 오래걸렸습니다.
처음 CKA 자격증을 취득해 보자고 생각했던 것이 작년 이맘때이니
정확히 1년되는 시점에 자격증을 취득했습니다. 

이걸 정확히 기억하는 이유가, 시험 응시를 계획하던 시점에
리눅스 파운데이션에서 CKA 자격시험 50% 할인 쿠폰을 뿌리고 있었기 때문입니다 ㅎㅎ
50%는 잘 나오지 않는다고 알고 있어서 유효기간 1년임을 확인하고 바로 등록했던 것이죠. 
25% 짜리 나왔다고 좋아서 글올렸던 흔적도 남아 있군요!

여튼, 등록한 시험 유효기간 1년이 9월 8일에 종료되니
어서 시험을 신청하라는 메일을 받고 부랴부랴 재정비에 나섰습니다. 

CKA 시험 No show 패널티에서 살아 돌아오다!

CKA 시험은 자격 시험 접수권(?)을 구매하면 1회의 시험을 볼 수 있습니다. 
재미있는 것은 1회 시험에서 불합격하면 한번 더 시험을 보는 기회를 줍니다. 
단, 1회 시험을 접수해 놓고 No show로 탈락한 경우 re-take 기회가 주어지지 않습니다.

사실 저도 그랬습니다. 
시험을 등록해 두고 날짜를 까먹고 있다가 하루 지난후에 시험을 못친 것을 확인했습니다. 
이 비싼 시험을 놓치다니... 하고 한탄만 하기에는 비용이 너무 비쌌습니다. 
지금은 환율이 1400원/달러가 넘어가고 있으니 더 비싸졌죠?

어떻게 구제 받을 수 없을지 폭풍 검색을 해봤지만 답은 없었습니다. 
하지만 포기할 제가 아니었죠. 
Linux Foundation 트레이닝 센터에 로그인 한 후 Support 티켓을 열고
시차 계산을 잘못해서 놓쳤다... re-take 할 수 있게 어떻게 안되겠냐 사정을 했습니다. 

몇 번의 이메일을 주고 받고 최종적으로 받은 답은 바로 재시험 기회 부활!
두드리면 얻을 것이다라는 격언을 몸소 느낄 수 있는 시간이었습니다!
혹시 저처럼 시험 스케쥴링 해두고 No show로 탈락하신 분들은 
re-take 기회 부활에 대해 문의를 꼭 해보시기 바랍니다!
375달러 1400원 환율은 정말 큰 돈입니다 ㅠㅠ

어떻게 공부해야하나?

요즘 많은 자격시험이 그러하듯, CKA도 실무형 시험입니다. 
시험 자체가 단답식이 아니라 가상 k8s 환경에서 문제를 찾고 해결하는 것이 대부분입니다. 
그러다보니 실무에서 k8s를 빡세게 쓰지 않는 분들이 다소 불리합니다.

그런 상황 때문인지 많은 CKA 자격증 강의 및 강사들은 
udemy 등을 통해 강의를 수강하는 사람들을 대상으로
자신이 운영하는 트레이닝 서비스에서 k8s 랩을 해볼 수 있도록 해주고 있습니다. 

시험 범위가 꽤나 넓기 때문에 udemy 등에서 강의를 한번 들어보는 것을 추천드리고 
시험이 임박해오면 각 강의에서 제공하는 Mock Exam과 
랩 과제 중심으로 반복 연습하면서 부족한 지식들을 채우고 까먹은 것을 다시 공부하는게 효과적입니다. 
추천 드리는 udemy 강의는 다음과 같습니다. 

시험 문제는 뭐가 나오나요?

시험은 크게 세가지 배점으로 나뉘어 집니다. 
13점짜리 가장 배점 높은 문제와 중간 난이도의 7점 짜리 문제들.
그리고 다소 쉬운 4점짜리 문제들로 구성되어 있습니다. 

4점짜리 문제들은 설정되어 있는 쿠버네티스 클러스터의 정보를 확인하는 것이 주류입니다. 
확인된 정보를 특정 경로에 파일로 떨어뜨려 제출하거나 
클러스터 구현에서 빠진 간단한 설정을 업데이트 하는 것이 주류입니다. 
즉, 기본적인 k8s 지식을 바탕으로 kubectl 명령으로 비교적 쉽게 풀어낼 수 있습니다. 

7점짜리 문제들은 조금 난이도가 있습니다. 
구현 되어 있는 클러스터의 중간 난이도 문제점들을 확인하고
문제점을 해결하는 과제들이 주어지게 됩니다. 
4점짜리에 비해 다소 어렵지만 차근히 풀면 못풀 문제도 아니긴 합니다. 
k8s의 다양한 리소스 개념을 잘 인식하고 있어야 당황하지 않고 풀 수 있습니다. 

제 경우 13점짜리 문제는 문제가 발생한 클러스터를 복구하는 문제였습니다. 
쿠버네티스 뿐만 아니라 간단한 리눅스 시스템에 대한 이해가 필요했고
k8s와 리눅스 전반에 걸쳐 문제점을 찾아나가는 접근을 해야 했습니다. 
정확히 1분 남기고 이 문제를 풀었던 것이 합격의 최종 관문이었습니다 ^^;;

시험 환경은 어떤가요?

리모트로 시험을 보면서 온라인으로 진행되는 만큼 당황할만한 요소가 꽤 있습니다. 
시험 시작 시간 30분 전에 미리 접속해서 필요한 클라이언트 다운로드 등을 진행하는게 좋습니다. 
막상 다운로드가 느리거나 잘 안되면 마음이 또 조급해 지기도 합니다 ㅜㅜ

시험은 리눅스 파운데이션의 트레이닝 포털을 통해 진입합니다. 
Scheduled/In Progress에 시험 안내가 나오고 있지요?
사전에 `click HERE` 등의 링크를 눌러서 환경 점검을 하시고 
마음의 준비가 끝나면 `Launch Exam`을 눌러 시험에 환경으로 진입합니다. 

2022년 6월부터 시험 환경이 변경되었습니다. 
기존에는 (저는 쳐보지 못했습니다만) 자신의 로컬 브라우저를 이용했고
시험 환경에도 터미널로 접근했던 것 같기도 한데... 자세히는 모르겠구요 ㅎㅎ
변경된 시험환경은 브라우저 내에 가상 리눅스 GUI 환경이 제공되고 
가상 리눅스 GUI 환경에서 브라우저, 터미널 등을 사용한다고 보시면 됩니다. 

네, 더럽게 느립니다 ㅜㅜ 
그리고 습관적으로 cmd-tab 을 누르는데 자꾸 로컬 환경에서 동작하는 바람에 여러가지로 당황할 수 밖에 없었습니다. 
보안 브라우저를 설치하고 시험 시작을 누르면 보안 브라우저가 실행중인 앱을 모두 종료 시킵니다. 
그런데 제 경우 제대로 죽지 않은 프로그램이 있어서 cmd-tab 누를때마다 자꾸 그 화면이...
심지어 한글로 된 내용이 떠있는 상태라 부정 행위로 떨어지나... 걱정했었습니다.
고로.. 시험 시작전에 로컬 앱은 일단 다 죽여주시기 바랍니다!

PSI 시큐어 브라우저의 화면구성은 크게 2단으로 되어 있습니다. 
화면 좌측으로 문제가 나오는 영역이 있고, 우측이 가상 리눅스 GUI 환경입니다. 
시험이 시작되면 GUI 환경에서 터미널을 직접 실행해야 합니다. 

시험 꿀팁

1. 
친절하게도 문제 영역에는 문제와 관련된 k8s 공식 문서 링크를 제공해 줍니다. 
CKA 예전 시험에는 이렇게 제공되지 않았던 것 같은데 (물론 안쳐봐서 정확한 건 아닙니다 ㅎㅎ)
k8s 공식 문서를 탐색하는 스킬을 굳이 연습하지 않으셔도 큰 지장 없다고 생각하시면 됩니다. 
그저 문제 위에 나열된 2~3가지 링크를 빠르게 활용하는 것이 문제를 푸는 지름길입니다!

2.
가상 환경 속의 터미널에 뭔가 붙여 넣기 해야 할일이 무척 많은데
키보드 숏컷이 약간 차이가 있으니 주의해야 합니다. 
가상 환경이 시작되면서 해당 부분에 대한 안내가 나오긴 합니다만 
습관이 무섭다고... 단축키를 이용하면서 계속 실수를 연발했습니다. 
문제 후반부부터는 그냥 마우스로 클릭~ 클릭~ 하면서 복사했네요 

3.
배점이 낮은 문제를 먼저 푸는게 좋습니다. 
저는 가장 처음에 13점짜리 문제가 나와서... 한참 헤메다 보니 시간이 와르르...
중간에 멘탈을 붙잡아서 다행이었습니다만 정말 당황했었습니다. 
시험 문제는 앞뒤로 왔다갔다 할 수 있고 까리한건 플래그 걸어두고 다시 확인할 수 있습니다!

4.
시험 시작전에 시험 보는 환경에 대해서 꼼꼼하게 검사를 합니다. 
저는 1인 미팅실을 빌려서 들어가서 이용했는데요, 노트북을 들고 내장 카메라로 구석구석을 보여달라고 합니다. 
채팅으로 영문으로 지시사항을 내려주기 때문에 잘 보고 하라는 것을 잘 하면 됩니다. 

• 불필요한 물건은 주변에서 다 없애세요
• 마스크 벗어놓은 것도 치우라고 하더군요 -_-+
• 노트북 아래, 마우스 아래, 책상 아래... 방 한바퀴 돌아보기... 등을 시켰습니다

시험 보자마자 팁을 정리하려고 했는데 많이 늦어졌네요. 
시험 문제도 많이 기억이 났었는데... 늙어서 그런지 몇 일 사이에 기억에 남는게 하나도 없습니다 ㅜㅜ

여튼, 흥미롭게 볼 수 있는 시험이었고 공부도 정말 많이 할 수 있는 시간이었습니다. 
이제 어디가서 k8s 관련해서 명함 살짝~ 내밀 수 있는 수준이 된 것 같아
회의 시간에도 당당하게 어깨를 펼 수 있게 된 것이 가장 큰 수확입니다 ㅎㅎ

CKA를 준비하는 모든 분들의 앞날에 합격의 영광이 가득하길 기원합니다!
udemy 가 제공하는 CKA 강의중 한글 자막이 있는 것은 아직 못본 것 같은데요 
한글 자막이 필요하다면 전체 CKA 주제 강의 목록 살펴보시면서 찾아보시는 것도 좋겠습니다. 

마지막으로... 자랑하고 마칩니다. 

본 블로그의 많은 글들은 제휴 마케팅을 통해 소정의 수수료를 지급받을 수 있습니다. 

엊그제 CKA (Certified Kubenetes Administrator) 자격을 취득했습니다.
AWS Solutinos Architect Associate 취득이 거의 3년전이었으니
3년만에 또 하나의 자격증을 추가하는 <게으름>을 선보였습니다 ㅎㅎ

CKA 취득후 좀 쉴까 했더니, AWS SAA 자격이 11월 만료라고 갱신하라는 알람이 똬악...
그래서 부랴부랴 유데미 Udemy 에서 강의를 검색해 봤습니다. 
SAA 취득할때는 Ryan 님의 강의로 도움을 많이 받았는데, 
Ryan님의 회사 Cloud Guru가 다른 회사에 인수되면서 강의가 다 내려갔습니다 ㅜㅜ

고심끝에 고른 강의는 Neal Davis님의 SAP 강의 
일단 20시간 VOD라 짧고 굵게 공부할 수 있을 것 같고 
본인이 운영하는 Digital Cloud Training 이라는 서비스에서
실습할 수 있는 환경을 제공해 주는 것 같아 과감히 선택했습니다. 

가격도 정가 49000원 대비 추석 맞이 할인 71% 적용중이라 
14000원으로 아주아주 착해서... 과감히 결제했습니다 ㅋ
이제 11월까지 한번 또 달려봐야겠습니다!

그나저나 이거 공부하면 또... 번역 작업은 언제하나 싶은 생각이 듭니다. 
아직 챕터 1도 안끝났는데... 역시 잠을 줄여야 합니다 ㅜㅜ
강의를 자세히 살펴보려면 아래 링크로~ 샘플 강의 몇 가지를 들어볼 수 있습니다. 

http://app.ac/83IusLJ03

본 포스팅은 제휴마케팅을 통해
소정의 수수료를 지급받을 수 있습니다. 

쿠버네티스 클러스터의 네트워크 구성에 문제가 생기면
다음과 같은 에러를 만날 수 있습니다. 

root@controlplane:/# k get all -n triton
NAME                                READY   STATUS              RESTARTS   AGE
pod/mysql                           0/1     ContainerCreating   0          67s
pod/webapp-mysql-54db464f4f-5jtq2   0/1     ContainerCreating   0          67s
...
...
root@controlplane:/# k describe pod/webapp-mysql-54db464f4f-5jtq2
Events:
  Type     Reason                  Age                From               Message
  ----     ------                  ----               ----               -------
  Normal   Scheduled               14m                default-scheduler  Successfully assigned triton/webapp-mysql-54db464f4f-648sr to controlplane
  Warning  FailedCreatePodSandBox  14m                kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "7fba1fad2f3e8297e080cfd1ab1d75615f1d036acf0eb6182514dcebbf2cf089" network for pod "webapp-mysql-54db464f4f-648sr": networkPlugin cni failed to set up pod "webapp-mysql-54db464f4f-648sr_triton" network: unable to allocate IP address: Post "http://127.0.0.1:6784/ip/7fba1fad2f3e8297e080cfd1ab1d75615f1d036acf0eb6182514dcebbf2cf089": dial tcp 127.0.0.1:6784: connect: connection refused, failed to clean up sandbox container "7fba1fad2f3e8297e080cfd1ab1d75615f1d036acf0eb6182514dcebbf2cf089" network for pod "webapp-mysql-54db464f4f-648sr": networkPlugin cni failed to teardown pod "webapp-mysql-54db464f4f-648sr_triton" network: Delete "http://127.0.0.1:6784/ip/7fba1fad2f3e8297e080cfd1ab1d75615f1d036acf0eb6182514dcebbf2cf089": dial tcp 127.0.0.1:6784: connect: connection refused]
  Normal   SandboxChanged          4m (x47 over 14m)  kubelet            Pod sandbox changed, it will be killed and re-created.

에러 메세지를 보면 CNI 문제인 것처럼 보입니다.
이때 클러스터가 사용중인 CNI 를 확인할 필요가 있겠죠?

/opt/cni/bin 경로 확인

/opt/cni/bin 경로에서 클러스터에 설치된 CNI 플러그인을 확인할 수 있습니다. 

root@controlplane:/# ls /opt/cni/bin/ -al
total 81676
drwxrwxr-x 2 root root     4096 Sep  4 00:52 .
drwxr-xr-x 3 root root     4096 Aug 25  2021 ..
-rwxr-xr-x 1 root root  4159518 May 13  2020 bandwidth
-rwxr-xr-x 1 root root  4671647 May 13  2020 bridge
-rwxr-xr-x 1 root root 12124326 May 13  2020 dhcp
-rwxr-xr-x 1 root root  5945760 May 13  2020 firewall
-rwxr-xr-x 1 root root  3069556 May 13  2020 flannel
-rwxr-xr-x 1 root root  4174394 May 13  2020 host-device
-rwxr-xr-x 1 root root  3614480 May 13  2020 host-local
-rwxr-xr-x 1 root root  4314598 May 13  2020 ipvlan
-rwxr-xr-x 1 root root  3209463 May 13  2020 loopback
-rwxr-xr-x 1 root root  4389622 May 13  2020 macvlan
-rwxr-xr-x 1 root root  3939867 May 13  2020 portmap
-rwxr-xr-x 1 root root  4590277 May 13  2020 ptp
-rwxr-xr-x 1 root root  3392826 May 13  2020 sbr
-rwxr-xr-x 1 root root  2885430 May 13  2020 static
-rwxr-xr-x 1 root root  3356587 May 13  2020 tuning
-rwxr-xr-x 1 root root  4314446 May 13  2020 vlan
lrwxrwxrwx 1 root root       18 Sep  4 00:52 weave-ipam -> weave-plugin-2.8.1
lrwxrwxrwx 1 root root       18 Sep  4 00:52 weave-net -> weave-plugin-2.8.1
-rwxr-xr-x 1 root root 11437320 Sep  4 00:52 weave-plugin-2.8.1

/etc/cni/net.d/ 경로에서 CNI 플러그인 설정 확인하기

그러면 사용중인 CNI 플러그인의 설정은 어디 있을까요?
바로 /etc/cni/net.d/ 경로에 있습니다.
weave 설정 파일만 존재하고 /opt/cni/bin 경로의 내용을 미루어 봤을 때
이 클러스터는 CNI로 weave를 쓰도록 구성되어 있다는 추론이 가능합니다.

root@controlplane:/# ls -al /etc/cni/net.d/
total 12
drwxr-xr-x 2 root root 4096 Sep  4 00:52 .
drwxr-xr-x 3 root root 4096 Sep  4 00:52 ..
-rw-r--r-- 1 root root  318 Sep  4 00:52 10-weave.conflist

weave pod 존재 유무 확인

그렇다면 왜 에러가 발생했고 어플리케이션 pod 가 구동되지 않은 것일까요?
weave는 CNI 플러그인이고 설치 및 동작되고 있는 경우 
weave pod이 kube-system 네임스페이스에서 확인되어야 합니다.

root@controlplane:/# k get all -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
pod/coredns-74ff55c5b-s8jgh                1/1     Running   0          33m
pod/coredns-74ff55c5b-vnsv7                1/1     Running   0          33m
pod/etcd-controlplane                      1/1     Running   0          34m
pod/kube-apiserver-controlplane            1/1     Running   0          34m
pod/kube-controller-manager-controlplane   1/1     Running   0          34m
pod/kube-proxy-6jssm                       1/1     Running   0          33m
pod/kube-scheduler-controlplane            1/1     Running   0          34m

어라?
그런데 시험 환경에는 weave 관련된 이름이 보이지 않습니다.
weave.works 웹 사이트에서 아래 경로를 방문하여 
커스텀 k8s용 설치 manifest 파일을 확인해 봅시다.

https://www.weave.works/docs/net/latest/kubernetes/kube-addon/

$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

위 명령을 수행하여 weave CNI 플러그인을 설치합시다.

weave pod 실행상태 확인

이제 weave plugin이 설치되었으니 pod가 구동되는지 확인해 보겠습니다. 

root@controlplane:/# k get all -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
pod/coredns-74ff55c5b-s8jgh                1/1     Running   0          40m
pod/coredns-74ff55c5b-vnsv7                1/1     Running   0          40m
pod/etcd-controlplane                      1/1     Running   0          40m
pod/kube-apiserver-controlplane            1/1     Running   0          40m
pod/kube-controller-manager-controlplane   1/1     Running   0          40m
pod/kube-proxy-6jssm                       1/1     Running   0          40m
pod/kube-scheduler-controlplane            1/1     Running   0          40m
pod/weave-net-9kbqw                        2/2     Running   0          43s

아까 보이지 않던 pod/weave-net-xxxxx가 보입니다. 
이제 서비스 클러스터의 pod 상태를 보겠습니다. 

root@controlplane:/# k get all -n triton
NAME                                READY   STATUS    RESTARTS   AGE
pod/mysql                           1/1     Running   0          12m
pod/webapp-mysql-54db464f4f-5jtq2   1/1     Running   0          12m

pod의 상태가 Running으로 바뀌었습니다. 
describe로 상태를 보면 특별히 CNI 이슈가 해소된 것에 대한 메세지는 남지 않는 것 같습니다. 
다만 pod가 잘 동작하는 것으로 이슈가 해소된 것을 알 수 있겠네요!

k8s 관리자라면 꼭 공부해야 하는 CKA는 아래 강의를 추천드립니다.
강사가 제공하는 별도 Lab 환경이 정말 진국인 강의입니다!

조금더 개발자에게 필요한 내용을 담은 CKAD를 준비한다면 역시 아래 강의가 좋겠습니다!

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급 받을 수 있습니다.

성능 측정은 인프라의 기본입니다.
특히 서버와 네트워크의 성능 측정은 현업에서 자주 요구되는 시험 중 하나입니다. 
다양한 방법의 시험이 있겠지만, 리눅스 환경에서는 iperf라는 걸출한 도구가 있어 시험이 쉽습니다. 
물론 실제 어플리케이션의 성능 측정 등은 nGrinder와 같은 부하 도구를 사용해야 합니다. 

CentOS 환경에 iperf3 설치하기

iperf의 가장 최신 버전은 3 입니다. 
각 리눅스 환경에서 패키지 매니저를 이용하여 쉽게 설치 가능합니다. 
제 경우는 CentOS 환경이라 yum 으로 설치를 진행했습니다. 

$ sudo yum install iperf3
...
...
Dependencies Resolved

======================================================================================================================
 Package                    Arch                       Version                         Repository                Size
======================================================================================================================
Installing:
 iperf3                     x86_64                     3.1.7-2.el7                     base                      79 k

Transaction Summary
======================================================================================================================
Install  1 Package

Total download size: 79 k
...
...
Running transaction
  Installing : iperf3-3.1.7-2.el7.x86_64                                                                          1/1
  Verifying  : iperf3-3.1.7-2.el7.x86_64                                                                          1/1

Installed:
  iperf3.x86_64 0:3.1.7-2.el7

기본적인 사용 방법 : 서버와 클라이언트의 구성

iperf3는 서버 역할을 할 데몬과 클라이언트 역할을 할 데몬을 실행함으로써 시험을 수행하게 됩니다. 
성능 측정을 하고자 하는 대상 장비, 인스턴스에서 iperf3를 서버 모드로 실행하고 
다른 장비에서 iperf3를 클라이언트 모드로 실행하여 성능을 측정합니다. 

서버 모드로 iperf3 실행하기

iperf3를 서버 모드로 실행하기 위해서는 -s 파라메터를 지정합니다. 
서버의 성능은 대역폭 혹은 전송량으로 표기되는데
-f 파라메터 뒤에 소문자 m, g, t 등을 사용하면 대역폭으로
-f 파라메터 뒤에 대문자 M, G, T 등을 사용하면 전송량으로 표기합니다.

iperf2는 기본적으로 5201 포트로 수신을 합니다만
다른 포트를 사용하기 위해 -p 파라메터와 포트 번호를 지정할 수도 있습니다.

// 서버 모드로 iperf3를 실행
$ iperf3 -s

// 서버 모드로 iperf3를 실행하되 대역폭을 Mbps로 표기
$ iperf3 -s -f m

// 서버 모드로 iperf3를 실행하되 대역폭을 Gbps로 표기
$ iperf3 -s -f g

// 서버 모드로 iperf3를 실행하되 전송량 GB/sec로 표기
$ iperf3 -s -f G

// 기본 포트(5201)가 아닌 지정된 포트로 서버 구동
$ iperf3 -s -f g -p 1234
-----------------------------------------------------------
Server listening on 1234
-----------------------------------------------------------

클라이언트 모드로 iperf3 실행하여 시험 수행하기

서버를 구동했다면 이제 클라이언트를 구동할 차례입니다. 
옵션은 서버로 쓸때와 비슷한데요
접속 대상 iperf3 서버 IP를 -c 옵션으로 지정한다는 정도의 차이가 있습니다. 

// 서버 10.20.30.40 으로 시험 패킷을 전송
$ iperf3 -c 10.20.30.40

// 서버 10.20.30.40를 1234번 포트로 연결하여 시험 패킷을 전송
$ iperf3 -c 10.20.30.40 -p 1234

// 시험 패킷을 전송하되 단위를 Mbps로 표기
$ iperf3 -c 10.20.30.40 -p 1234 -f m

// 시험 패킷을 전송하되 단위를 MB/sec로 표기
$ iperf3 -c 10.20.30.40 -p 1234 -f M

시험 심화 : UDP 시험

기본적으로 iperf3는 TCP 시험을 수행합니다.
그런데 UDP 도 널리 쓰이고 있기 때문에 시험이 필요할 수 있습니다.
이때는 다음과 같이 -u 옵션을 사용하면 됩니다. 
서버는 -u 옵션을 사용하지 않아도 되고, 클라이언트에서만 -u 옵션을 사용하면 됩니다.

$ iperf3 -c 10.20.30.40 -p 1234 -f M -u
Connecting to host 10.20.30.40, port 1234
[  4] local 10.20.30.50 port 32888 connected to 10.20.30.40 port 1234
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   116 KBytes  0.11 MBytes/sec  82
[  4]   1.00-2.00   sec   129 KBytes  0.13 MBytes/sec  91
[  4]   2.00-3.00   sec   127 KBytes  0.12 MBytes/sec  90
[  4]   3.00-4.00   sec   129 KBytes  0.13 MBytes/sec  91
[  4]   4.00-5.00   sec   127 KBytes  0.12 MBytes/sec  90
[  4]   5.00-6.00   sec   129 KBytes  0.13 MBytes/sec  91
[  4]   6.00-7.00   sec   127 KBytes  0.12 MBytes/sec  90
[  4]   7.00-8.00   sec   129 KBytes  0.13 MBytes/sec  91
[  4]   8.00-9.00   sec   127 KBytes  0.12 MBytes/sec  90
[  4]   9.00-10.00  sec   129 KBytes  0.13 MBytes/sec  91
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.24 MBytes  0.12 MBytes/sec  0.006 ms  0/897 (0%)
[  4] Sent 897 datagrams

iperf Done.

시험 심화 : 다중 TCP 연결 시험

현실의 서버들은 단일 TCP 연결이 아니라 다중 TCP 연결을 쓰게 됩니다. 
iperf3는 이런 상황을 대비하여 다중 스트림을 쏠 수 있는 기능도 제공합니다.
-t 옵션을 사용하면서 뒤에 스트림 숫자를 지정해 주면 됩니다. 

$  iperf3 -c 10.20.30.40 -p 1234 -f m -P 20

소개한 옵션들은 사실 기본적인 옵션들입니다. 
각자의 상황에 필요한 옵션은 공식 문서를 통해 찾아 보는게 좋겠습니다!

https://github.com/esnet/iperf

앞선 글에서 계속 이어집니다.
별 내용은 없습니다만, 앞의 글은 아래 링크로 보실 수 있습니다. 

• 증상을 모니터링해야 한다, 원인이 아니라...
• 너무 많은 알람은 도움이 되지 않는다

• 에러 버짓이 너무 빨리 줄어들면 -> 예산이 소진되기 전에 응답해야 한다
• 에러 버짓이 너무 천천히 줄어들면 -> 장기 개선 과제를 통해 펄스 알람을 피해야 한다

• 꼭 Stackdriver를 써야 하는 것은 아님
• SLO 모니터링은 어떻게 정의하는 가
  • 지연과 가용성중 어느 것을 기준으로 삼을 것인지 결정
  • SLI 임계치를 설정
  • 모니터링 윈도우(=컴플라이언스 기간) 정의
  • 요청수를 기준으로 할지 정상/비정상 시간을 기준으로 할지 결정
  • 결국 에러 버짓이 떨어질 때 알람을 발생시켜야 함

Stackdriver를 비롯하여 사용가능한 도구가 다르기 때문에... 장표 막 넘기고 4컷으로 요약

일단 알러팅이 정확해야 지치지 않는다

하나씩 레이어를 치우면서 원인을 찾아보자

서로 다른 도메인의 데이터를 관계시켜 원인을 찾아보자

추적 데이터, 높은 빈도로 출현하는 데이터의 조합?
이를 바탕으로 가설을 세우고 시험해 보는 것은 빠른 원인 판단에 도움이 됨

구글이 NEXT 2018의 IO116 세션으로 발표했던
Improving Reliability with Error Budgets, Metrics and Tracing in Stackdriver를 읽으면서  일부 내용을 요약해 봤습니다. 

내용을 읽으면서 한번 요약을 해보고
이후에는 제가 생각하는 SRE의 R&R에 대해서 
이야기 해볼까 합니다. 

Agile이 동작하는 구간은 Business to Development 의 구간 
DevOps는 Development to Operations 구간에서 동작

DevOps = Practices, Guidelines, Culture
Site Reliability Engineering = Practices, Beliefs for Practices, Job role

SRE가 Operation을 대하는 자세는 
- 자동화에 큰 관심과 노력을 기울여야 하고 
- sysadmin 들이 보통 해오던 일들과 도구를 통해 같은 역할을 수행 
- 신뢰성 있는, 운영하기 좋은 서비스 아키텍쳐를 from the scratch 로 디자인

SRE = 시스템 엔지니어링과 소프트웨어 개발의 교차로

SRE가 신경써야 하는 Practices들.
오너십의 분산, 에러 예산 내에서의 에러 수용 -> 실패 비용 줄이기, 자동화, 측정

인터렉션은 어떻게 정의해야 하는가?
분산되어 있는 서비스 전반에 걸쳐 요청과 응답이 문제 없는가?

결국 이런것, 즉 정상 여부를 판별할 수 있는 기준이 필요하고
SLI (Service Level Indicator) = 좋은 상태인지 구분할 수 있는 측정치
SLO (Service Level Objective) = SLI가 도달해야 하는 최상단 목표 수치
SLA (Service Level Agreement) = SLO 추구의 결과
의 3종 셋트를 정의할 수 있어야 한다.

(To be continued...)

서비스의 세계에서 모든 것은 자동화, 데몬화 해두는 것이 좋습니다. 
그렇지만 어떤 이유로든 일회성, ad-hoc으로 작업해야 할 경우도 있기 마련입니다. 

서버 시간의 동기화도 마찬가지입니다. 
정석은 ntpd(ntp 데몬)을 활성화하여 지속적으로 동기화 하는 것입니다. 
다만 그렇지 못한 상황에서는 어떻게 하면 될까요?

ntpdate를 이용한 일회성 업데이트

CentOS 기준으로 /sbin 폴더 하위에 ntpdate 바이너리가 존재합니다. 
이를 이용하여 ntp 서버를 지정하면 일회성으로 서버의 시간을 동기화 해줍니다. 

sudo /sbin/ntpdate 202.28.116.236

명령을 수행하면 서버의 시간 정보를 지정된 NTP 서버 IP로부터 동기화를 하여 맞추게 됩니다. 
서버 시간 정보에 따라 어떤 조정을 했는지를 결괏값으로 알려줍니다.

// 서버 시간이 빠르거나 느린경우
ntpdate[86379]: step time server 202.28.116.236 offset -51.136374 sec
ntpdate[56913]: step time server 202.28.116.236 offset 55.014698 sec

// 미세한 차이로 인해 조정한 경우
ntpdate[46062]: adjust time server 202.28.116.236 offset 0.000091 sec

ntp 서버 정보는 어디에서?

인프라 규모가 꽤 큰경우 자체 NTP 서버를 운영할 때가 많습니다. 
하지만 영세하거나 얹혀서 서비스 하고 있는 경우 변변한 NTP 서버가 없기 마련입니다. 
Microsoft, Google 같은 곳에서도 NTP를 제공하긴 하지만
다음과 같은 비영리 단체를 통해서 NTP 서버를 공급(?) 받는 것도 좋습니다. 

해당 페이지에서 아시아쪽 서버를 탐색해보면 다음과 같은 다양한 지역 서버가 나옵니다. 
이 글을 쓰는 2022년 7월 12일 기준으로, 아시아 지역에는 336대의 NTP 서버가 운영중입니다. 

kr.pool.ntp.org 라는 주소를 쓰거나
가이드에 나온 것처럼 ntp.conf 파일을 정의해서 사용하면 되겠습니다!

메일링을 하다보면 스팸 처리를 신경쓰지 않을 수 없습니다.
사용자들에게 중요한 메일을 발송하거나 안내 메일을 보냈는데
메일이 스팸함에 들어가 버리면 무척 곤란하겠죠?

스팸 처리와 관련하여 메일을 수신한 서버가 발신자를 검증하는 방법은 여러가지입니다. 
그 중에서도 가장 기본적인 것이 SPF 레코드입니다.

SPF 레코드란?
SPF는 Sender Policy Framework의 약어로 특정 도메인에서 이메일을 보낼 수 있도록 승인된 모든 서버를 열거하는 DNS TXT 레코드의 한 가지 유형입니다.
(출처 : https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-spf-record/)

수신된 메일 원문/헤더 확인하기

가령 네이버 메일을 이용하여 구글 메일 주소로 메일을 발송하면
구글 메일 서버가 정말로 네이버 메일 서버를 통해 발송된 것인지
확인하기 위해 참조하는 정보가 SPF 레코드라 보시면 됩니다. 
실제로 한 번 보내보도록 하겠습니다. 

Gmail로 수신된 네이버에서 보낸 메일의 헤더 정보를 살펴보겠습니다. 
우측의 More 메뉴를 누르면 `Show Original` 이라는 옵션이 보입니다. 
이것을 눌러 메일 헤더 정보를 살펴보겠습니다. 

화면 하단에는 Raw 헤더 정보가 존재하고, 상단에는 위 그림처럼 
메일에 대하여 SPF, DKIM, DMARC 검증 요약 결과가 출력됩니다. 
SPF 검증이 126.209.224.234 IP 로 확인되었다고 하는데 
이 과정을 한번 살펴보도록 하겠습니다. 

Raw 헤더 정보에서 `Return-path` 확인하기

SPF 검증을 위해서는 메일을 보낸 도메인의 DNS를 통해 SPF 값을 확인해야 합니다. 
이 때 사용되는 도메인이 꼭 메일 주소의 도메인과 같지 않을수도 있습니다. 
수신 서버는 메일 헤더 정보에서 `Return-path`를 보고 SPF를 조회할 도메인을 결정합니다.
네이버의 경우 메일 주소의 도메인과 동일한 도메인을 쓰긴 하네요. 

SPF 정보 확인하기

구글 메일 서버는 Return-Path에 지정된 naver.com 으로부터 SPF 정보를 획득합니다. 
dig을 이용해서 naver.com의 SPF 정보를 조회해 보겠습니다. 
참고로 SPF는 리소스 레코드 타입으로도 규격이 존재하긴 하지만
오늘날 실제로는 TXT 레코드의 값으로 지정하는 것이 일반적입니다. 

% dig naver.com TXT +short | grep spf
"v=spf1 ip4:111.91.135.0/27 ip4:125.209.208.0/20 ip4:125.209.224.0/19 ip4:210.89.163.112 ip4:210.89.173.104/29 ip4:117.52.140.128/26 ~all"

`v=spf`로 시작하는 이 값은 유효한 메일 발신 서버를 알려주는 역할을 수행합니다. 
`ip4`로 지정된 주소에서 메일이 발신되었는지를 비교한다 생각하시면 되겠죠? 
실제로 include 등의 지시자를 통해 다른 도메인에서 SPF 정보를 참조하는 것도 가능하지만 
네이버의 경우에는 그렇게 구성되어 있지는 않은 것으로 확인됩니다. 

자, 그러면 이제 메일 헤더에서 발신 서버의 주소를 확인해 보겠습니다.
위의 이미지에도 있지만 친절하게 한번 더 보겠습니다. 

발신서버 확인하기

발신 서버 주소는 메일 헤더에서 `Received` 값을 확인하면 됩니다. 
제가 보낸 메일은 cvsmtppost019.nm.naver.com 서버를 통해 발송되었고 
이 서버 도메인을 질의해보면 125.209.224.234 주소가 나오는 것으로 보입니다. 

% dig cvsmtppost019.nm.naver.com +short
125.209.224.210
125.209.224.234

SPF 레코드의 값들 중 `ip4:125.209.224.0/19` 에 매칭된다는 것을 확인할 수 있겠죠?
이 과정을 통해 구글 메일 서버는 적법한 서버를 통해 메일이 발송되었고 
스팸 처리를 하지 않아도 된다고 판단한 후, 제 구글 메일의 inbox 에 메일을 넣어주었다고 보시면 되겠습니다. 

메일은 구닥다리처럼 보이지만 여전히 광범위하게 사용됩니다. 
메일은 지금도 진화하고 있고 앞으로도 진화할 겁니다.
따라서 메일에 대해 잘 이해하고 활용하는 것이
여러분, 혹은 여러분이 속한 회사의 비즈니스에 중요하다는 것은 명확해 보입니다!

본 포스팅은 제휴마케팅을 통해
소정의 수수료를 지급받을 수 있습니다.