AWS Certified Developer Associate (DVA-C02) 을 취득한지 어언 1년 후,
이번에는 AWS Certified Advanced Networking - Specialty (ANS-C01) 을 취득하게 되었다.
다른 자격증을 두고 이걸 도전하게 된 이유는,
회사에서 대부분의 Cloud 아키텍처가 온전히 Cloud Native가 아닌, Hybrid 아키텍처가 대부분이었기 때문이었다.
대다수의 서비스들이 Transit Gateway (TGW) 을 통해 Multi-VPC 를 통합하여 east-west communication 및
Direct Connect 전용선으로 기존 data center와의 bidrectional communication을 수행하고 있었다.
처음에 아키텍처를 봤을 땐 대체 뭐가 뭔지 알 수 없었고 각 서비스들이 뭔지 모르니
traffic의 대체 왜 여기서 저기로 흐르는 지도 알 수 없었다.
그래서 결국 AWS의 Networking Service들을 공부할 겸 ANS-C01를 취득해보기로 했다.
공부 방법
처음에는 무작정 dump로 풀려고 했다. DVA-C01을 그런 방식으로도 충분히 취득했었기 때문이었다.
근데 VPC, ELB, Route53 까지는 그럭저럭 document를 참고하면서 풀 수 있었는데
Transit Gateway
Site-to-Site VPN
Direct Connect
이 3개는 진짜 document를 몇 번이고 참고해도 쉽사리 문제를 풀 수 없었다.
게다가 저 3개는 문제에서 한 개만 나오는 게 아니라 최소 2개씩은 결합된 아키텍처에 관해 묻는 경우가 많아서 제대로 알아둬야 했다.
그래서 일단 dump를 푸는 건 잠시 중단하고 바로 udemy에서 관련 강의를 검색해서 들었다.
AWS 자격증을 취득하려는 사람들이 많이 보는 Stephane Maarek 선생님의 강의.
근데 ANS-C01 강의는 Stephane 선생님이 처음에 인사만 해주실 뿐 나머지 강의는 죄다 Chetan Agrawal 분이 다 해주신다;
인도 출신이셔서 그런지 처음에 영어 발음을 알아듣기 힘들어서 허들이 좀 있었지만 영어 자막 켜놓고 듣다 보면 상당히 익숙해진다.
어쨌거나 가격은 거의 10만원 가까이 하는 고가이지만 허구한날 세일을 때리는 Udemy 덕에 14000원을 주고 결제했다.
모든 강의를 다 듣지는 않았고, 위의 저 3가지 (Transit Gateway, Site-to-Site VPN, Direct Connect) 만 들었다. 시간만 더 있었으면 Route 53 쪽의 DNS 관련 부분 (Private Hosted Zone, IB/OB endpoint) 들도 듣고 싶었는데, 일단 저 3개만 들어도 어지간한 덤프는 다 풀 수 있었다.
덤프는 examtopics에서 7만원 넘게 주고 263개의 문제를 전부 구매했지만 실질적으로 140개밖에 못 보고 시험장에 들어가긴 했다;
시험 후기
DVA-C01도 그렇고 이번 시험도 어김없이 실제 시험장에 가서 시험을 쳤다.
내가 시험을 친 곳은 강남역 바로 인근의 HWG Testing Center.
시험시간은 16:45 ~ 17:45 였는데 실제로 시험시간은 한 2시간 넘게 준다.
45분보다 일찍 도착해도 그냥 시험자 신원 확인하고 난 뒤 바로 시험을 칠 수 있게 해준다.
신분증이랑 신용카드(체크카드) 둘 다 준비해서 가면 감독관님께서 신원 확인하시고 시험장으로 안내해주신다.
그리고 준비된 컴퓨터에서 바로 문제를 풀고 다 풀고 나면 CCTV 쪽으로 손을 들면 감독관님께서 시험 종료 확인해주시고 밖으로 보내주신다.
시험은 한국어로 응시했는데, 한국어로 해도 영어 원문을 볼 수 있게 해주니 기계 번역의 어색함으로 인해 문제를 해석하기 힘들다면 그냥 영어 원문을 참고하면 된다. 나는 덤프를 영어로 푸는 연습을 해서 그런지 한국어 문제를 빠르게 읽을 수 있었다.
총 65문제였고, 좀 미심쩍은 문제는 플래그(flag) 표시를 해두고 나중에 다시 그 문제로 돌아와서 검토할 수 있다.
결과
총 65문제였고, 문제를 다 풀고 시험을 치고 나오니 배고픔이 밀려들어서 결과는 잊어버리고 그냥 밥 먹고 자유를 만끽하며 노는 데만 집중했던 것 같다. 그러다가 지금쯤 결과 나왔으려나? 하고 20시쯤 메일함을 열어봤는데,
합격이었다!
사실 풀면서 대부분의 문제가 덤프랑 똑같아서 (제시문 순서도 안 바꾸고 그대로 낸 문제들이 많았다;) 어지간한 이상은 대부분 다 풀었던 것 같다. 다만 점수는 내 예상보다 좀 많이 낮았다.
800점은 넘었을거라 생각했는데.. 여전히 제대로 이해하지 못하고 헷갈려한 부분들이 있었나 보다... 어쨌거나 합격했으니 됬다.
어쨌거나 공부하면서 aws hybrid architecture를 봐도 더 이상 아무것도 몰라서 헤매지는 않을 것 같다.
위의 명령어를 수행하면 아래와 같이 '/registry/pods/'로 시작하는 모든 경로를 가져오는 것을 확인할 수 있다.
위의 명령어를 좀 더 자세히 설명해보자면 다음과 같다.
kubectl exec -it \ # etcd-minikube 파드에 접속하여 명령을 실행하기 위해 'kubectl exec' 사용, -it 옵션은 인터랙티브 모드 설정
-n kube-system etcd-minikube \ # 'kube-system' 네임스페이스의 'etcd-minikube' pod를 지정
-- sh -c 'ETCDCTL_CACERT=/var/lib/minikube/certs/etcd/ca.crt \ # CA 인증서 경로 설정, etcd 서버 인증서 검증용
ETCDCTL_CERT=/var/lib/minikube/certs/etcd/peer.crt \ # 클라이언트 인증서 경로 설정, etcd 서버와의 통신용
ETCDCTL_KEY=/var/lib/minikube/certs/etcd/peer.key \ # 클라이언트 인증서에 대응하는 프라이빗 키 경로 설정
ETCDCTL_API=3 \ # etcd API 버전을 v3로 설정
etcdctl \ # etcd와 상호작용하기 위한 CLI 도구 실행
get \ # etcd 데이터베이스에서 데이터를 조회하는 명령
--keys-only \ # 키만 가져오도록 설정, 값은 포함하지 않음
--prefix=true \ # 지정된 prefix와 일치하는 모든 키를 검색
"/registry/pods/" ' # Kubernetes의 모든 pod 정보가 저장된 경로 prefix
+) etcd 에 값 저장하고 읽기
etcd는 데이터베이스니까 값을 저장하고 읽는 것도 가능하다.
etcd pod의 container shell에 접속해서 키-값을 저장하고 읽는 명령을 실행해보도록 하겠다.
소위 '소셜로그인'이라 부르는 타사 플랫폼의 개인정보를 이용해 서비스에 로그인할 수 있게 하는 걸 구현하기 위해선
Oauth 2.0 표준에 맞게 백엔드를 구현해야 한다.
Oauth 의 구성요소
Oauth 인증의 구성요소, 즉 역할은 4가지가 있다.
Client: 리소스를 요청하는 주체
'리소스'는 단순 유저의 개인 정보뿐만이 아니라 구글 캘린더, 네이버 블로그 포스트 등 다양한 정보가 될 수 있음
Resource Owner: 리소스에 대한 접근을 제어하고 권한을 부여하는 주체.
e.g.) Google, Naver와 같은 플랫폼
Authorization Server: Access Token을 발급해주는 서버
Resource Server: Access Token을 가진 요청을 검사하여 리소스를 반환하는 서버
Oauth 플로우
(출처) RFC 6749
간략히 정리하면 이러하다.
1. Client가 Access Token을 발급받기 위한 인가(Authorization)을 요청한다.
2. 1에서 받은 인가를 통해 리소스를 발급받기 위한 Access Token을 요청한다.
3. Access Token을 통해 리소스를 요청한다.
하지만 아무 Client나 인가나 리소스를 요청할 수 있는 건 아니고, 어떤 Client가 인가와 리소스를 요청할 것인지Authoriation Server에 등록해둬야 한다.
즉, 구글이나 네이버의 소셜로그인을 구현하고자 하는 경우, 해당 제공자들의 Oauth 콘솔 같은 데 들어가서 Client를 등록하고 그 Client임을 식별할 Credentials(client id, secret)를 취득해 둬야 한다.
그리고 이 Client가 접근할 수 있는 리소스의 종류와 범위(scope, e.g. 이메일은 필수 동의, 성별은 이용자 선택 제공 등)를 정해준다.
이 때, 웹 페이지에서 인가를 얻고자 하는 경우, 정상적인 endpoint에서 요청을 보내는지 검사하기 위해 redirection URI 라는 것을 별도로 등록해야 한다. redirection URI를 등록해두고 해당 Client가 추후 올바른 Credential과 redirection URI를 가지고 인가를 요청한 경우, Authorization Server가 해당 redirection URI 뒤에 쿼리스트링으로 인가 코드를 포함시켜서 리턴해준다.
그렇게 얻은 인가 코드를 가지고 Credential(client id, client secret)과 redirection URI과 함께 다시 Authorization Server에 보내어 Access Token을 요청한다. 그러면 Authorization Server가 Credential을 검사하고 해당 인가코드와 그 인가코드가 발급된 uri와 redirection URI가 일치하는지 확인한 후에 Access Token을 발급해 준다.
(리소스 제공자에 따라 추가 프로퍼티가 필요할 수 있다)
그리고 나서 발급받은 Access Token을 가지고 리소스를 요청하면 지정해놓은 scope에 해당하는 리소스들을 Resource Server가 반환하는 식이다.
구글, 네이버, 카카오 통합하기
소셜로그인은 딱 3개 구현해 봤다. 구글, 네이버, 카카오.
이전에는 각 제공자별로 Guard를 따로 구현해 줬는데 잘 생각해보니 셋 다 Access Token과 user profile을 조회하는 url만 좀 다를 뿐이지 쿼리스트링으로 포함시켜줘야 할 프로퍼티는 똑같았다.
