전승호의 nz피클

1. prometheus 로 웹서비스 모니터링 하기 – blackbox_exporter 연계하기

특정 웹서비스를 모니터링 하는 과정을 기록.

pulling metrics

회사에서 운영하는 대외 서비스의 서비스를 모니터링 하기 위해 그 유명하다는 prometheus 를 사용해 보았다. 공식 홈페이지의 기본 예제로 진행해 보았다. 내 식대로 이해해보면 prometheus 는 단순히 metric 이라는 것을 긁어서 저장하는 크롤링 서버다. (pull metrics)

무엇을 크롤링 하는가? 프로메테우스가 이해하기 좋은 형태의 시시각각 새로고침 되는 상태 정보다. 프로메테우스 설정에 등록된 모든 서버들에 프로메테우스가 주기적으로 접속해서 내용을 계속 긁어온다.

exporter

프로메테우스가 데이터를 잘 긁어갈 수 있도록 준비된 서버들이 필요하다. 이것을 보통 exporter 라고 부르며 이것이 준비 되어야 프로메테우스가 긁는 역할을 담당할 수 있다. exporter 는 독립실행형 프로그램이므로 프로메테우스를 설치 하기 전에 실행 할 수 있다. 따라서 잠시 프로메테우스에 대해서 잊도록 하자.

프로메테우스에게 긁힐만한 정보를 가진 서버들은 xx_exporter 라 불리우는 “추출기” 서비스가 기동되어 있어야 한다. 그 서비스의 포트로 프로메테우스가 주기적으로 접속해서 내용들을 주기적으로 가져간다. 물론 xx_exporter 는 계속 내용을 갱신하기 때문에 프로메테우스는 시시각각 변하는 서버의 정보를 끊임없이 모을 수 있게 된다.

아래와 같이 프로메테우스에 등록된 어떤 URL 이 있다고 할 때 그 metric 지표는 아래와 같이 plain_text_key value 쌍으로 구성된 단순 text 여러줄의 모음이다. 중간에 주석이 많은데 그냥 고마운 설명이라 생각하고 넘어가자.

http://somehost.com:9115/metric

# HELP probe_dns_lookup_time_seconds Returns the time taken for probe dns lookup in seconds
# TYPE probe_dns_lookup_time_seconds gauge
# plain_text_key value
probe_dns_lookup_time_seconds 0.199540841
# HELP probe_duration_seconds Returns how long the probe took to complete in seconds
# TYPE probe_duration_seconds gauge
probe_duration_seconds 2.299759862 # 웹서버의 응답시간

이런 정보가 프로메테우스에 수집되면 그 plain_text_key 키값 그대로 검색을 할 수 있고 시시각각 변하는 값이 그래프로 나타나게 된다.

blackbox_exporter

프로메테우스에게 데이터를 모두 주기위해서 많은 서버들이 스스로 exporter 가 작동하는 등의 노력을 할 수도 있겠지만 내가 관리 할 수 없는 특정 API 의 상태를 체크 하고 싶다면 그 API 를 찔러보는 서버를 대상 서버 밖의 다른 곳에 두는 수 밖에 없다. 따라서 blackbox_exporter 를 이용하면 부족하나마 서비스를 모니터링 할 수 있다.

blackbox.yml

modules:
  http_2xx:
    prober: http
    timeout: 5s
    http:
      preferred_ip_protocol: "ip4" # 이 설정이 매우 중요
      method: GET
      valid_status_codes: [200, 302]
      headers:
        User-Agent: "Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Mobile Safari/537.36 Edg/96.0.1054.34"
  http_post_2xx:
    prober: http
    http:
      method: POST

여기에는 어떤 서버를 모니터링 할지는 안 나와 있고 blackbox_exporter 자체의 속성만 편집한다. 여기서

  preferred_ip_protocol: "ip4"

가 매우 중요한데, ipv6 를 지원하지 않는 서버의 상태를 조회 할 때 저것을 명시 하지 않으면 조회하지 못한다는 에러가 난다. (보통 다 그럴 것이다)

proxy

blackbox_exporter 는 일종의 proxy 이다. 프로메테우스는 blackbox_exporter 를 경유해서 서버의 상태를 조회하며, blackbox_exporter 는 서버의 상태를 프로메테우스가 이해하기 쉬운 형태로 그 결과를 변환 해 준다.

target 서버를 뭘로 인자를 주느냐에 따라서 그 서버의 http 상태 정보를 추출할 수 있다. prometheus 의 영어 사전을 리턴하는 네이버의 응답 속도를 모니터링 하고 싶다면

blackbox_exporter 의 probe API 에 target 인자로 그 URL 을 주면 된다. 이렇게 target 인자를 프로메테우스가 필요에 따라 설정할 수 있도록 하면 된다.

Prometheus 에서 조회 대상 target 설정

prometheus 에서 조회 대상 설정
blackbox_exporter 서버가 대신 조회
응답을 prometheus 용으로 생성
prometheus 가 시시각각 변하는 metric 지표를 저장

prometheus

드디어 prometheus 를 시작해보다. 기본 설정에서 blackbox_exporter 관련 설정만 추가 한다.

scrape_configs:
  - job_name: "blackbox_exporter"
    metrics_path: /probe
    params:
       module: [ http_2xx ]  # Look for a HTTP 200 response.
    static_configs:
      - targets:
         - https://nz.pe.kr

         - https://curious.com/api/someapi?hello=world
    relabel_configs:
           - source_labels: [__address__] # 1
             target_label: __param_target
           - source_labels: [__param_target] # 2
             target_label: instance
           - target_label: __address__ # 3
             replacement: localhost:9115 # The blackbox exporter.

localhost:9115 에 떠 있는 blackbox_exporter 에게 targets 에 명시된 서버들을 조회하라는 설정이다. relabel 을 prometheus 의 유연성 중 하나로 언급되기도 한다.

이 설정은 blackbox_exporter 와 연계하여 호환 설정하는 내용이 아님을 명심하자. 사실 prometheus 는 blackbox_exporter 가 주는 값만 중요할 뿐이지 blackbox_exporter 인지는 중요하지 않다.

이 설정은 단지 job_name (배치 job?) 에 대한 시시각각 변경되는 값을 가져오기 위해서 URL 을 어떻게 조합해 갈 것인가에 대한 트릭이 담겨있는 설정이다. 위와 같이 설정하고 나면 prometheus 는 아래와 같이 target 에 명시된 URL 을 크롤링 하기 위한 blackbox_exporter 용 URL 을 생성하여 그것을 pulling 한다.

* localhost:9115/probe?module=http_2xx&target=https://nz.pe.kr # target 뒤의 값은 URL encoding 된다.
* localhost:9115/probe?module=http_2xx&target=https://curious.com/api/someapi?hello=world

#1 여기서 __address__ 는 target 내의 서비스들을 말하는데 [] 로 감싸져있어 배열이다. (그래서 labels 도 복수형) 이것이 __param_ 이 된다. 즉 blackbox_exporter 의 target 파라미터로 대체되어 들어간다.

#2 또한 그 target 들은 prometheus 의 instance label 이 된다. 표시되는 그래프에서 구별해 볼 수 있는 구분자 라벨이다. 즉 #1의 target_label 은 __param_ 이 prefix 이므로 파라미터로 전환되는 것이고 #2는 prefix 가 없으므로 그대로 label이 된다.

#3 마지막으로 마지막으로 __address__ 즉 조회할 서버 (target_label) 의 주소는 localhost:9115 로 대체된다.

targets 정제하기

static_configs:
  - targets:
     - https://nz.pe.kr/too/too/too/too/so/so/long/user?hello=world#GET_USER
     - https://nz.pe.kr/too/too/too/too/so/so/long/and/again/long/point?hello=world#GET_POINT
relabel_configs:
       - source_labels: [__address__]
         target_label: __param_target
       - source_labels: [__param_target]
         regex: .*(#.*)
         replacement: $1
         target_label: instance
       - target_label: __address__
         replacement: localhost:9115 # The blackbox exporter.

너무 target 이 길면 나중에 prometheus 에서 조회한 URL 이 너무 길고 나중나중에 grafana 로 연계 할 때도 안 좋기 때문에 (#.*) # 뒤에 오는 것을 $1번 변수에 담아서 instance 라는 라벨에 할당할 수 있다. 나중에 화면 볼때 쓸데 없이 긴 라벨이 없어 깔끔하다.

서비스별 응답시간

여기까지 prometheus 에 웹서버의 상태를 표시하기 위한 여정을 마친다. metric 을 쭑 훑어보면 웹서버의 응답 시간을 나타내는 probe_duration_seconds 를 찾을 수 있고 최종적으로는 등록된 API 들에 대한 측정치를 확인 할 수 있다.

다음은 응답시간을 받아올 수 없을 때, 즉, blackbox_exporter 의 조회 API 인 probe API 의 조회 실패 케이스 probe_success 0 일 때 slack 으로 알림을 받는 방법을 알아본다.

좀 오래된 go 책을 사서 따라 하다가 안될 때는 GO111MODULE 부터 봐야 할 듯.

몇년된 go 책을 보면 거의 뭔가 안되는데

GO111MODULE 때문인것 같다.

C:\src\learninggo\src\anydir>go run anyfile.go
anyfile.go:3:8: package greet is not in GOROOT (C:\Program Files\Go\src\greet)

C:\src\learninggo\src\anydir>set GO111MODULE=off
or
go env -w GO111MODULE=auto

C:\src\learninggo\src\anydir>go run anyfile.go
Hello greeting pack

책의 go version 과 요즘음의 go version 의 차이로 module 의 기본 사용이 강제 되는 듯.

회사 코드도 컴파일이 안되는게 이것 때문인듯. 오히려 예전 버전의 go를 설치 하고 있는 것도 문제.

windows 에서 docker 로 띄운 container 에 옆/외부 컴퓨터에서 접속할 수 없는 경우 개인 네트워크 공용 네트워크 그리고 윈도우 방화벽

예를 들어서 nginx를 9999 포트로 띄운다고 가정해보자.

docker run -p 9999:80 nginx

localhost:9999 로 붙으면 당연히 잘 될 것이다.

이 컴퓨터의 ip 가 192.168.0.2 라고 가정해 보자.

옆 컴퓨터에서 붙어 보자.

192.168.0.2:9999

이 때 안되는 경우에 대한 이야기를 시작한다.

일단 결론적으로 나의 경우 안되었던 이유는 docker container 를 띄운 windows 컴퓨터가 붙은 공유기를 “공용 네트워크” 로 선택했기 때문이었다.

컴퓨터를 세팅한 첫날부터 잘못된 선택이었다. 처음에는 outbound 로 인터넷만 하는 컴퓨터라 신경을 안 썼는데 “서버” 로 돌릴 host 컴퓨터라면 당연 “개인 네트워크”로 선택하는 것이 좋겠다. 왜냐하면 host 컴퓨터의 입장에서는 내 공유기가 “공용 네트워크” 로 “선언” 했다는 것은 마치 커피숖 wi-fi 붙은거랑 같게 보안을 강화해 달라는 설정을 한 것이나 다름 없기 때문이다.

그러니 옆에 컴퓨터에서 host 컴퓨터에 붙으려고 해도 대부분 기본 차단된다. 이는 커피숖의 다른 누군가가 내 컴퓨터에 접속 시도하는 것을 죄다 막는 “공용 네트워크” 설정 때문이다.

host 컴퓨터가 붙은 wi-fi 가 “개인 네트워크” 설정을 했다면 기본적으로 외부 컴퓨터에서 host 컴퓨터가 열어 놓은 port 에 접속이 잘 되기 마련인데 이는 docker for desktop 등을 설치 했을 때, 처음 서버를 기동 했을 때 windows 가 분명히 물어봤을 것이다.

시작>실행> wf.msc 에서 나오는 인바운드 규칙을 보면 나의 경우는 docker 프로그램이 여는 모든 포트가 허용되되 개인 프로필 즉, 개인 네트워크에 붙어 있을 때에만 허용하고 “공용 프로필” 은 명시적으로 거절하도록 되어 있다.

이것이 무슨 포트인지는 중요하지 않다. docker 로 실행된 모든 포트는 허용을 하게 된다.

windows 에서 리스닝 중인 포트에 대해서 어떠한 프로그램이 그 포트를 열고 있는가를 거꾸로 찾아 들어가는 방법이 있다.

netstat -aon 과 linux 의 grep 격인 findstr 를 조합하면 된다. 9998 을 열고 있는 프로그램의 ID 를 찾는다.

프로그램 ID 를 찾았다면 이제 프로그램이 무엇인지 단번에 알아낼 수 있다.

linux 의 ps -ef 격인 tasklist 이다. 여기서도 findstr 를 조합한다.

com.docker.backend.exe 가 결국 9998 포트를 열고 있는 프로그램인 것을 알 수 있다.

com.docker.backend.exe 프로그램의 fullpath 를 아는 방법은 아래의 명령으로 가능하나 외우기가 어렵다. 따라서 작업관리자 > 세부정보 탭에서 파일 위치 열기를 하는 것이 낫겠다.

C:\Users\nzin4>wmic process where “name=’com.docker.backend.exe'” get executablepath
ExecutablePath
C:\Program Files\Docker\Docker\resources\com.docker.backend.exe

이제 옆 컴퓨터에서의 테스트가 끝났다면 공유기 외부에서의 접속을 시도해볼 차례다. 공유기는 각 공유기 제조사마다 “포트 포워딩” 가이드를 제공하고 있다. port forwarding 설정을 잘만 한다면 host 즉, windows 컴퓨터의 외부에서의 접속 테스트는 완료된 상태이므로 무리없이 진행될 것이다.

개인 라이센스로 구매한 소프트웨어 (SecureCRT) 회사에서 업무용으로 쓸 수 있는가? :: YES

회사에서 몇가지 s/w 를 구매해야 하는데 그냥 법카로 사서 청구하라고 해서 개인용으로 구매하라는 뜻인지.. 결론적으로 s/w 회사에서 license 를 개인용 / 업무용을 명확하게 나누지 않고서야 개인용으로 구매해도 문제가 없다는 생각이 든다. 즉, 개인용으로 귀속시키면 내 전용 s/w 가 되고 어딜 가서 사용해도 괜찮다는 의미가 되겠다.

SecureCrt 에 문의 메일을 보내서 가능하다는 답변을 받았다.

구매 라이센스는 computer 에 귀속된다.

제목: Re: Can I use personal license S/W at my company? [T02035873:002]

Hello,

Thank you for your e-mail.

Providing you stay in compliance with our End-user License
Agreement and are authorized by your company to install a
personal License on your work computer there should not be
an issue.

That being said SecureCRT is licensed per “computer” as
defined in section 3 of the SecureCRT EULA which can be
found at the following location:

https://www.vandyke.com/pricing/licensing.html

As defined in the SecureCRT EULA, a “computer” can be one of
the following:

A client machine running a client operating system like
Windows 10, macOS or Linux.
A “seat” which is defined as a software or hardware
client that has access to use SecureCRT on a terminal
or RDS server.

You will need 1 SecureCRT License for each “computer” that
has access to use SecureCRT locally or remotely.

A single SecureCRT License can be used by a single
individual to register SecureCRT on one additional
“computer” as defined in the SecureCRT EULA as long as the
individual has SecureCRT running on a single “computer” at a
time.

Please let me know if there is anything else I can do for you.

Misty Buck
VanDyke Software, Inc.
505-332-5710
505-332-5701 (fax)
sales@vandyke.com
www.vandyke.com

outlook 에서 보낸 메일 중 응답 오지 않은 메일 확인하기

gmail 을 주력으로 쓸 때도 관심 있는 주제였는데 회사를 바꾸고 outlook 을 주력으로 쓰다보니 찾아보게 된다.

인터넷 검색하면 아래와 같은 filter 를 SQL 란에 넣으라는 글이 많이 보이는데 당췌 되지 않는다.

NOT (“http://schemas.microsoft.com/mapi/proptag/0x10810003” = 102 OR “http://schemas.microsoft.com/mapi/proptag/0x10810003”

(?) 포기 하고 좀 지내다 보다가 괜찮은 방법을 발견했다. 참조에 항상 나를 넣고 보낸 편지함에 도착하게 된 내 편지 중 보낸 사람이 나인 경우에 내가 보낸 편지함으로 이동 시킨다. (이것이 보낸 편지와는 좀 성격이 르다.)

이제 받은 편지함에서 내가 보낸 편지함으로 규칙 이동 된 내 편지에 flag 를 걸어두고, 주기적으로 flag를 확인하면 된다.

초등학교 원격 수업 노트북 대비 패드의 단점 vs

코로나 4차 대유행 / 4단계 거리두기가 시작 되었다. 2학년인 둘째는 원격수업을 안 하다가 이번에는 시작하게 되었다. 컴퓨터 방에 컴퓨터가 옹기종기 모여 있지만 수업을 같이 하기에는 안 좋을 것 같아서 거실에서 수업을 들을 계획인데 노트북으로 수업을 하는 첫째에게 패드로 수업 듣는 친구가 있냐 물었더니 많다고 한다.

그래서 그냥 패드로 수업을 듣게 하려다가.. 첫째에게 패드로 수업 듣는 친구가 혹시 수업 듣기 어려운 점이 있는지 물었더니 의외로 많이 있길래 적어 본다.

수업시간에 손들기를 시키면 실제로 드는 경우도 있으나 이모지로 표현하는 경우가 있는데 패드의 경우 접근성이 떨어져서 순발력/순서에서는 느리다고 한다.
PC에서는 멀티보기로 선생님을 항상 고정하고 여러 친구의 모습을 볼 수 있는데 타블렛은 그참여자 한눈에 보는 슬롯이 적어 선생님을 항상 보면서 수업을 듣기 어려운 모양이다.
학교에서 학습지를 받아오지 못한 경우 출력을 위한 파일을 전달 받게 되었는데 패드에서 프린터 설정을 해 놓지 않았다면 인쇄를 못하는 친구가 있다고 한다.
타 사이트 오픈
- 선생님이 수업에 참고되는 사이트 링크를 주는 경우가 있는데 아이패드 사용자의 경우 카메라 연결이 끊기는 모양.
- 참고 사이트는 마우스 대응으로 되어 있고 터치 되응이 안되는 사이트가 적은 모양
- 영어는 퀴즐렛 과학은 가상 용수철 중력 실험 사이트
미술시간에 그림판으로 그리기를 하는데 패드는 할 수 없다.
카메라 위치 변경
- 노트북이나 패드는 카메라 방향 조정이 번거로운데 가끔 과제를 손으로 쓰고 있는 모습의 촬영이나 체육 시간에는 서서 율동하는 모습을 보여주려면 카메라 위치 조정이 수월해야 할 것 같다.
성능
- 타블렛 성능에 따라 원격수업 중에 화면이 끊기거나 급기야 선생님 목소리가 끊겨 들리는 듯 보인다고 한다.

꼰대는 왜 변하지 않는가? 직장생활에서 꼰대가 되지 않는 방법 – 첫 마음가짐대로 될 것이다.

Table Of Contents

나이가 만 41살이 되었다. 직장에서 꽤 높은 위치에 있는 것 같다. 나 스스로는 아직 젊다고 생각하고 사원 대리급과 농담 따먹기도 잘 한다고 생각하는데 그들은 나를 어떻게 생각할까? 마침 아내가 공직에서 30~40명을 거느린(?) 팀장이 되어서 처음 팀원들을 만날 때의 인상에 대한 얘기를 하다가 급 깨닫는 것이 있어 정리해 본다.

친한 친구와의 거침없음

나에게는 좋아하는 동생 둘이 있는데 나를 포함해서 3명이 있는 카톡방에서 그렇게들 서로 거침 없이 말을 뱉는다. 지금이야 익숙해 졌지만 사이가 안 좋거나 싸우는 줄 알았다. 시간이 지난 후 그들이 불알친구고 그럴 수 밖에 없다는 것을 알았다.

그런데 그 느낌이 뭔지 알 것 같다. 나도 학창시절 친구들을 만나면 그 때의 나이로 돌아가 말투가 그 때로 돌아간다. 그야말로 욕도 하면서 서로 까고 논다. 그러면서도 우리는 기분이 나쁘지 않고 즐겁다. 그 모습 또한 누가 보면 싸우는 것 같이 보이기도 할 것 같다.

가끔 만나는 친구들. 그 친구를 처음 만났을 때 그 느낌으로 대화 분위기가 바뀐다. 내가 몇 살이 되든 상관이 없다. 이렇듯 회사에서 만나는 사람과도 그 대화 방식이 고정이 되는 것을 느낀다. 물론 처음 어색할 때와 조금 친해지고 나서 조금은 바뀔 수는 있다.

첫 만남 그대로

처음부터 말을 놓는 사람은 나중에 더 가까워지면 꼰대가 되는 것 같고 처음에는 존대를 하다가 가까워져서 말을 놓는 하는 사람은 그래도 말투만 친해졌지 여전히 마음가짐과 태도에는 변화가 없는 것을 느낄 수 있다.

그래서 첫 인상이 중요하다고 하는가? 일종의 목표를 갖고 처음부터 확 휘어잡고 싶은 사람은 처음부터 말을 놓는 경우가 많다. 그것이 결국 그가 만나는 사람들과의 관계의 출발선이다. 처음부터 지위의 격차를 강조하고자 하는 사람이 만나는 사람은 아무리 친해지고 싶어도 이미 첫 인상이 그렇기에 반감이 생기고 굳어지게 마련이다. 그래서 그 이후에는 잘 하고 싶어도 결코 가까워질 수 없는 벽이 생기는 것 같다.

가족도 마찬가지

이 원리는 아버지와 나와의 관계에서도 나타나는데 아빠는 항상 나를 어린아이로 보는 것 같다. 아빠가 나를 이제는 어른으로 대해주길 바라지만 이미 성인이 된지 20년이 흘렀는데도 여전히 나는 아버지에게 어린아이다. 바꿀 수 없다.

나는 개발자니까 웬만하면 편하게 입는 편이지만 면접을 보거나 첫 만남을 가질 때는 거의 비즈니스룩을 하는 편이다. 그러면 꼭 편하게 입어도 되는데~ 라고 거드는 사람이 있다. 그렇지만 나는 첫 인상을 중요하게 여기므로 바뀌지 않는 편이다.

사람간의 관계에서 처음 굳어진 그 관계를 깨기란 어려운 것 같다. 그렇다면 나는 직장 생활에서 만나는 사람과의 관계를 어떻게 정리해야 할 것인가? 첫인상 첫 마음가짐 그것이 관계를 만드는 것이다.

windows findstr 주변 검색 (select-string context)

grep 은 -C 로 내가 찾고 싶은 단어 위아래로 검색 하게 해주는데 windows 에서도 찾아봤는데 findstr 로는 안되고 powershell 명령어인 Select-String 으로 되는 것을 확인

Yaml 형태의 문법인 경우 유용하게 사용 가능하다.

PS C:\Users\nzin4> kubectl describe po flask3 | Select-String -Pattern 'Label' -Context 2,3

  Node:         minikube/192.168.49.2
  Start Time:   Wed, 07 Jul 2021 15:41:04 +0900
> Labels:       app=test
                run=flask3
  Annotations:  <none>
  Status:       Running

긴 결과에 대해서 Select-String 으로 pipe 로 넘긴 후 -Pattern 인자로 검색 -context 로 검색 되었다면 그 위의 2줄, 아래로는 3줄을 보여라 라는 명령을 호출하면 된다.

PS C:\Users\nzin4> kubectl describe po flask3 |Select-String -Pattern 'Label' -Context 2,3

  Node:         minikube/192.168.49.2
  Start Time:   Wed, 07 Jul 2021 15:41:04 +0900
> Labels:       app=test
                run=flask3
  Annotations:  <none>
  Status:       Running

뭔가 내가 지정한 것보다 하나 더 많이 검색 하는 것 같다.

Select-String -Context

aws certified Solutions Architect / Developer – Associate 동시 취득 후기 동시 취득의 장점과 온라인 시험 경험담

# full stack 개발자로서의 아키텍쳐 진입

S/W는 그 접근성이 누구에게나 열려 있는데 반해

장비, 네트워크 분야는 물리적인 H/W를 필요로 하는지라 공부에 대해 이론적 접근성 대비 실습과 그 실행에는 어려움이 많았습니다.

full stack 개발자로서 항상 아쉬운 것이 방화벽과 네트워크 서브네팅과 이중화 구성이었고

H/W의 제약사항을 없앤 것이 저에게는 클라우드 컴퓨팅의 매력이었습니다. 거기에 스케일링과 비용 효율화는 덤입니다.

그래서 이번에 full stack 개발자 + 아키텍팅 까지 다 해보자라는 생각이 들었습니다.

# 동시 취득을 목표로 하면 노력대비 성과가 좋음

그래서 aws solutions architect (이하 SAA) 공부를 시작했고 연속해서 certified Developer(이하 DVA) 까지 연속 취득 하였습니다.
각설하고 결론부터 말하자면 누구든 시작을 결심 한다면 이왕이면 2개를 동시에 따면 좋겠다는 것입니다.

합격에 도움이 되는 블로그가 많이 있어서.. 구지 제가 또 어떻게 하면 합격하는데 도움이 되겠다라며 적는 것은 정보 과잉을 양산하는 것이라 지양하고자 합니다. 2가지 시험을 보고 나니 거의 절반 이상의 내용이 겹쳐 있고 이왕이면 한번에 2개를 따면 좋겠다는 글과 코로나 시국에 aws 자격증 외에 언젠가 치루게 되실 온라인 시험에 대한 제 경험담을 적어보고자 합니다.

가용성을 지원하는 시스템 아키텍쳐, 네트워크 설계를 위한 Solutions Architect 를 공부하면서 배운 것 중에 절반은 Developer 공부에 중복되면서도 반드시 필요한 부분이었습니다. 그래서 Developer 공부는 매우 수월했고 복습하는 기분으로 훑고 지나가 공부 기간은 절반에 가까웠는데도 불구하고 합격 점수가 훨씬 더 높았습니다.

SAA를 따고 나서 하루이틀 결과 발표를 기다리는 와중에 사내 게시판에 자격증 2개 동시취득자의 글이 올라와 자극을 받게 되었습니다. 그 때 DVA 도 따버리자 라고 생각했는데 지금 생각하면 매우 잘 한 것 같습니다. 오히려 동시 취득을 안 했으면 억울 했을 것 같습니다. (그만큼 범위가 겹치는 부분이 많습니다.)

SAA 때는 대충 긴가민가 알고 넘겼던 것을 DVA 딸 때 더 깊이 공부할 수 있었고 DVA 공부하면서 알던 것을 SAA 할 때도 알았으면 더 높은 점수를 받지 않았을까 싶습니다. 그만큼 서로의 자격증이 상호 보완적입니다. 이런면에서도 2개 동시 취득을 강력하게 추천하고 싶습니다.

SAA는 전체적으로 모든 솔루션을 훓게 되며 DVA는 Code series (commit, build, deploy, pipeline) 그리고 cli 명령어의 파라미터의 이름과 DynamoDB 의 RCU, WCU 계산, 그리고 서버리스구축을 위한 aws gateway / lamba 그리고 cognito 에 집중됩니다. 또한 cloudformation 과 SAM 의 개념도 알아야 합니다.

# 공부방법 (유료 강의와 유료 덤프)

SAA 는 약 3주간 평일 풀타임 (15 업무일) 으로 공부를 하였으며 DVA는 2주 (10 업무일) 의 시간이 소요 되었습니다. 아마 반대 순서로 땄으면 거꾸로 DVA 15일, SAA 10일 걸렸을 것 같습니다.

Udemy에서 강의를 검색해서 들었는데 난생 처음 듣는 영어 강의였 습니다.

그런데 모두 그림이 친절하고 강의 특성상 엄청 천천히 발음을 친절하게 강의를 해줘서

사실 처음에는 지레 겁먹었지만 강의가 후반부에 갈 수록 1.5배속에 심지어 1.75배속으로 듣고 있는 저를 발견하게 되었습니다.

2개의 강의가 앞의 절반은 겹치고 뒷부분 반이 영역이 약간 나뉘게 되어서 DVA 강의 앞의 절반은 건너 뛰어 시간을 절약했습니다.

Udemy 에 예상문제 각각 6회 강의를 추가로 구매하였습니다.
유료 문제 풀의 강의의 강점으로는 내가 어느 부분에 취약한지 카테고리를 분석해 주고
문제 번호와 보기의 랜덤 배치로 재 시험을 치룰 수 있습니다.
또한 실제 시험과 같은 자세를 취할 수 있도록 도와줍니다.

Udemy 는 최초 가입시 모든 강의가 만원 중반으로 결제 할 수 있고, 다음 강의는 장바구니에 넣어두고 결제 안하고 있으면 이메일로 왕창 할인 해줄테니 결제 해달라고 쿠폰이 오고 아니면 이메일을 여러개 만들어서 결제 하면 됩니다. 모두 만원대에 결제 하였습니다.

일단 강의 1회 수강
예상 문제를 풀고 틀린것에 대해서 aws 공식 문서를 읽고
시험 전날, 다시 다 풀어보고 그래도 또 틀린 것을 다시 aws 공식 문서를 보는 순으로 진행 하였습니다.

# 시험은 aws FAQ 문서에서

강의 외 내용이 시험에 나오면 구글에서 검색을 하면 거의 모든 문서가 검색이 되기는 하는데 aws 공식 문서의 한글 버전은 대부분 기계 번역이라 잘 이해 안되는 것은 영어로 보거나 본문을 구글 번역기로 돌리면 훨씬 이해하기 쉽습니다. FAQ 에는 사례와 해결 방법이 많이 나오는데 모두 다 시험 예상 문제 입니다.

다른 블로그를 참고해도 덤프 보는 것보다 FAQ를 정독하라는 얘기도 많이 볼 수 있습니다.

덤프를 공유해 달라는 등의 요청을 가끔 받게 되는데 인터넷에 널린게 덤프입니다. 찾아내는게 어렵지가 않습니다. 다만 몇가지 풀어보니 오답이 너무 많습니다. 오답을 외우는 사람이 없기를 바랍니다.

위에서도 썼지만 udemy 에서는 유료 예상 문제 과정을 제공합니다. 질문하면 답도 잘 달아주고 특히 SAA는 한글 문제 풀이 과정이 있어서 수월했습니다. (문제는 기계번역된 FAQ로 문제를 낸거라 문제 자체의 이해가 어려움)

바쁜 현대인에게 필요한 것이 덤프로 합격하는 것인지 강의를 듣고 배움을 내재화 하는 것인지는 본인이 판단하면 되겠습니다. 그럼에도 덤프는 여전히 필요합니다. 공부를 하고, 내가 모르는게 무엇인지 체크하는 최적의 방법입니다. 하지만 공부를 하기 전에 일단 덤프로 모르는 것을 하나씩 찾아 나가는 것도 틀린 방법은 아니라 하겠지만.. 전체적인 흐름을 한번이라도 보는 것이 여전히 고집스럽게 좋은 방법이라고 말하고 싶습니다.

# 시험 문제와 현행화 준비

실제 시험 문제가 랜덤이라 아까 낸 문제를 왜 또 내지? 싶은 문제도 있습니다. 혹은… 특정 제품의 사용을 밀고 싶어서 시험응시자들를 세뇌시키는 것은 아닌가 싶기도 했습니다. aws 시험문제가 재밌는게 5줄이라 치면 4줄은 거의 상황 설명이고 마지막 한두줄만 시험에 필요한 내용이라 시험을 치면서도 이럴때 이렇게 하면 되겠구나라는 상상의 나래를 펼치게 만들어 주어서 문제를 읽어 보는 것 만으로도 많은 배움을 얻게 됩니다.

시험문제의 현행화가 꽤 변수입니다. 불과 몇개월 전까지만해도 되지 않던 기능이 “이제 됩니다!!” 라고 홍보 기사가 올라 오면 그게 시험문제로 나오는 경우가 있습니다. 기존 경험으로는 당연히 안되던 것인데 이제는 오답일 수 있습니다. 예를 들어 s3 의 GetObject 는 원래 eventual consistency 인데 2020년 12월 부터는 strong consistency 입니다.

시험은 한글로 신청 하면 기계 번역된 한글 문제가 나오는데 “English” 라는 버튼을 누르면 원문을 볼 수 있어 대조 이해가 가능합니다. English 에 자신이 있다고 하더라도 한글 버전과 영문 버전을 동시에 볼 수 있는 것이 문제의 이해에 도움이 될 것 같다는 생각이 듭니다.

# 온라인 시험 준비

시험은 온라인 (피어슨뷰) 으로 치루었는데 노트북 화상카메라를 통해 감독관이 계속 쳐다보고 있는 가운데 치뤄지게 됩니다.

당일 예약은 안되는 것 같고 익일 24시간 중에 선택 할 수 있는데 일요일은 그 시간이 매우 한정적이라 없다고 보면 됩니다.
시험 날짜가 몇가지로 정해져 있으면 좋은데 내가 마음껏 선택할 수 있으니 자꾸 하루이틀 미루게 되는 것 같습니다. 목표일자를 정하지 않으면 공부 기간이 길어져서 점점 피곤해 집니다. 내일 보자! 고 결정하는 결심히 매우 중요합니다. 결제는 회사 법인카드 (visa 카드임) 로 진행합니다.

시험 10분 전에 피어슨뷰 등 싸이트에 로그인해서 전용 시험 코드를 확인 하고 미리 다운로드 해둔 전용 브라우저에 코드를 입력해서 로그인, 휴대폰에 전송되는 링크를 통해 시험실 동서남북을 사진찍어서 업로드 해야 하고 여권도 찍어 올려야 합니다.

시험이 시작되면 감독관과 약간의 대화를 하게 되는데 pardon? text me please~~ 등으로 하면 친절하게 채팅으로 대화를 전환한다.

노트북을 들어서 책상 밑을 찍어보라는 둥 몇가지 요구사항을 충족하면 시험을 시작한다. 저의 경우는 토즈 독서실의 2인 회의실에서 시험을 치뤘습니다. 시험 치루는 중에 손이 닿는 곳에서는 아무것도 없어야 한다는 조건을 만족시키기에 적절한 공간이었습니다. 벽면에 토즈 독서실 이용하는 방법에 대한 코팅 인쇄물이 붙어 있어 첫 시험에는 가림판으로 가렸고 두번째 시험에서는 뜯어버려야 했습니다.

전용 브라우저를 PC/mac 에 미리 설치해서 시스템 호환성을 미리 체크 하세요. 크롬북은 안될 수 있습니다. 참고로 호환성 체크할 때는 문제가 없었는데 막상 시험 때 휴대폰 테더링으로 시험을 시작하니 영상이 안 보인다 하여 급히 토즈 wifi 로 변경하여 겨우 시험을 치뤘습니다. 두번째는 랜선을 가져가서 유선으로 시험을 치루었습니다.

# 온라인 시험 단축키 팁

마우스로 정답을 찍어도 되고 단축키를 이용해도 됩니다. 보기 abcd 는 키보드로 타이핑 하면 정답이 체크 되고 다음 문제는 alt+N 이전 문제는 alt+P 등을 이용해 네비게이션 할 수 있습니다. 갑자기 단축키가 잘 안되는 경우가 있는데 몇번 해보니까 alt+tab 을 눌러보면 (실제로 화면 전환은 없지만) 갑자기 다시 잘 됩니다. 단축키에 익숙해 지시면 시험에 더욱 집중하는데 도움이 되실 것 같습니다. 주의할 점은 abcd 를 한번 더 누르면 정답 체크 한 것이 uncheck 가 되어 나중에 전체 검토 화면에서 풀지 않은 문제로 표기 됩니다. alt+F 로 flag 를 걸어서 헛갈리는 문제만 나중에 검토할 수 있습니다. ctrl +- 로 문제 폰트의 크기를 키우거나 줄일 수 있습니다. 폰트가 너무 커서 미처 보기를 다 보지 못할 정도로 확대 되었다고 판단되며 보기가 더 있는데 다음 문제 풀거냐는 경고도 친절하게 해줍니다.

# 온라인 시험 마무리

시험 문제 검토 후, 제출 버튼을 누르면 진짜 제출하겠냐는 조마조마한 버튼이 또 한번 나오고. 돌이킬 수 없는 버튼을 누르는 순간 합격 여부가 표시 됩니다. 혹시 떨어진 경우의 실망감을 감독관이 감당할 필요 없도록 하는 배려인지 제출 버튼을 누른 순간부터 감독관도 사라져 버립니다. 그래서 카메라는 켜 있는 와중에 그냥 노트북 뚜껑을 닫아버리고 집에 가도 무관합니다. 이미 당락은 결정 난 것입니다.

# 다음 목표

다음 시험으로는 Solutions Architect Pro 또는 DevOps Pro 로 다음 자격증을 노려보려고 합니다. 이 또한 많은 부분이 겹칠 것이나 pro 자격증은 여전히 객관식이지만 2개 심지어는 3개 이상의 복수 정답을 골라야 하므로 찍어서 맞추는 일은 없을 것 같습니다.

실기도 없는 객관식 자격증이라는 것이 꼭 아키텍처와 개발자 역량으로 확실히 구별지어지는 부분은 아니라서 (아느냐 모르느냐 vs 할 수 있느냐 없느냐) 일단 각각의 자격증의 예상 문제지를 풀어보고, 왠지 더 많이 알 것 같은 자격증을 노리는 것도 수월한 합격에는 도움이 될지도 모르겠습니다.

두번째 제안 작업을 시작하며 (제안은 면접처럼)

이번에 두번째 제안 작업을 시작하게 된다. 인생에서 처음으로 제안서를 썼을 때는 제대로 정리가 되지 않았던 것 같은데.. 이제 조금은 알 것 같다. 제안서도 일종의 면접이다. 내가 아는 기술을 총 동원 하되, 실제로 할 수 있는 범위 내에서 써야 한다. 내가 낸 답안지가 회사의 답안지고 고객이 채점을 한다. 그런데 고객 요청사항에 엉뚱한 대답을 했다면 그것을 채점하는 고객이 얼마나 민망할까? 우리 회사를 다시 쓰고 싶을까?

제안서는 우리 회사의 기술력이 대변되는 것이다. 혹시 떨어지더라도 다시 만날 준비는 되어야 하므로, 완전하지 못한 답변은 면접관 앞에서 헛소리를 하는 것이랑 다르지 않는 것 같다. 그래서 제안서 작업은 그야말로 “미리 준비된 자들의 집합”의 마스터 피스가 되어야 한다.
그런 관점에서 보면, 면접자가 면접에 합격을 하기 위해 최선을 다하듯 회사도 최선을 다 해야 한다.

그런데 최선을 다한다는 것이 무엇일까? 회사는 조직이다. 한순간 최선을 다한다는 명목으로 관련해서 아는 모든 직원을 한 곳에 모을 수는 없다. 다행인 것은 경쟁 관계에 있는 회사라고 해서 그렇게 하는 것도 아닐 것이다.

그래서 제안 요청사항의 전문적인 분야에 능통한 팀에 무언가를 부탁해서 제안서를 완성하는 것을 기대하는 것은 쉽지 않은 일이다.

그럼에도 제안이 선택되기 위해서는 마스터피스를 만들어야 한다면 기술 난이도가 깊은 사람도 필요하고 두루두루 알고 경험을 해 본 사람도 꼭 필요하다.
젊었을 때는 기술의 난이도만을 중요하게 생각했고 나이가 들어가면서 개발자에서 PL 이나 아키텍처로 가는 길은 되도록 피해왔던 것 같다. 하지만 누군가는 분명히 다방면의 기술을 아는 사람도 필요하겠다는 생각이 든다.

요즘과 같은 세상에는 어떤 문제에 대한 해결책을 찾아내고 제품을 선정하는 것은 어려운 일이 아닌 것 같다. 기술적으로 적용하는 것은 예제가 많아서 접근성이 좋다.
그러나 올바른 설계에 대해서는 해답이 없다. 다양한 best practice 를 탐독하고 경험하며 설계 자체의 고민을 할 수 있는 시간이 나에게 주어져서 다행이다.