AWS Certified Solutions Architect – Associate 자격 취득

꾸준히 AWS관련 업무를 맡아왔다. 업무로 다뤄 본 영역은 잘 알지만 다른 영역들은 전혀 모르는 부분들이 많았다. 매뉴얼을 읽을 때마다 전체를 조망하는데 어려움을 느꼈고 한번쯤은 몰입해 살펴봐야겠다고 생각해왔다.

2020년 11월 쯤 되니 한 해가 가는 것에 대한 조바심이 들었다. 가시적인, 스스로를 위한 성과가 필요하다고 생각했다. 그래서 미뤄뒀던 AWS SAA자격 취득을 준비했다.

학습자료

우선 예전 할인 때 사놓은 Udemy의 관련강의를 들었다. 다만 PPT를 읽는 수준에 그쳤기 때문에 만족도는 생각보다 크지 않았다. 대신 AWS SAA-C02 Study Guide라는 Github리포를 프린트해서 자주 읽었다. 이 요약본보다 더 깊은 공부가 필요한 경우는 AWS 공식 블로그와 매뉴얼, 예전에 받아놓은 AWS 관련 EBook을 함께 읽었다.

시험

2021년 1월 2일에 시험을 봤다. 사실 2020년을 마무리하면서 보려고 했는데 정리가 좀 덜되어서 연초로 옮겨 본 것이었다. 주로 영어자료를 참고했기 때문에 시험은 영어로 쳤다.

시험은 비대면으로 진행했다. 내 방에서 진행하는 비대면 시험은 처음이어서 이런 저런 절차를 처리하는데 시간이 걸렸다. 우선 책상의 모든 물건을 치워야 했다. 덕분에 새해맞이 책상정리를 하게 됐다. 또 감독관과 영어로 채팅을 하는 것은 예상하지 못해서 좀 당황했다. 신원확인은 여권을 카메라에 보는 방식으로 진행했고 책상위의 “모든” 물건은 바닥으로 옮겼다. 방이 좀 지저분했는데 노트북을 들고 방의 모든 구석구석을 보여줘야 해서 부끄러웠다. 또 예상치 못한 잡음을 방지하기 위해 창문을 닫았다. 긴장 때문에 시험 전부터 식은 땀이 났다.

시험문제는 어려웠다. 실은 공부가 많이 모자란 탓 이었다. 푸는 도중에 ‘떨어질 수도 있겠다’ 생각을 두어번 했다. 역시나 점수는 그다지 만족스럽지 않았다.

결과

793/720 으로 합격했다. 크게 더 떨어지는 부분은 없이 전체적으로 못본 것..으로 나왔다.

회고

영어가 어려웠다기 보다는 시나리오 위주의 문제를 풀기에 스터디 가이드를 외우는 것으로는 부족했다고 생각한다. 대신 AWS공식블로그의 사례연구가 큰 도움이 되었다. 비슷하지만 조금 다른 특성들에 대해서는 차이점에 대해 정확하게 아는 것이 중요하고 이게 문제로는 어떻게 나올지 상상해보는 것이 좋겠다는 생각이 들었다.

사용하지 못한 기술들이 있기 때문에 다시 공부하지 않으면 잊혀지기 쉬울 듯 하다. 다음 단계의 시험을 조만간 준비해야 공부가 수월할 것 같다.

ECS – API애플리케이션 – S3 웹리소스 고정아이피 구성

ECS로 구성된 애플리케이션의 웹 리소스의 고정아이피 구성이 필요했다. 가끔 유용하게 활용할 수 있는 사례라 구성도를 따로 그려봤다.

문제정의

  • 애플리케이션 서버는 ECS – Fargate – ALB 환경으로 구축
  • S3에 웹 리소스가 배포됨.
  • 애플리케이션 서버와 웹리소스에 고정아이피 주소 필요
  • 백엔드와의 연결은 HTTP만 사용해도 됨.

해결

  • Network Load Balancer에 고정아이피를 설정
  • NLB는 포트라우팅만 지원하므로 Nginx의 virtual server 설정으로 애플리케이션과 웹리소스 라우팅
  • Task Definition상 Nginx와 애플리케이션 서버를 하나에 둠
  • Nginx는 리버스프록시(localhost)로 애플리케이션 연결, S3와의 연결도 리모트 리버스프록시 사용.
  • S3는 Bucket Policy를 이용해 VPC고정으로 연결

구성도

참고

AWS ALB Target Group의 Draining 이 너무 길다면

최근 ECS를 도입하면서 Rolling Deploy 를 적용했다. 이전에는 EC2인스턴스마다 방문하면서 배포를 했다면 이제는 새로운 Fargate기반 태스크가 생성되면서 기존 태스크는 없애는 방식으로 배포된다.

테스트를 진행하다보니 ALB Target Group에 등록된 아이템이 Draining에 걸리는 시간이 긴 것이 눈에 들어왔다. 기본값으로 이 값은 300초가 주어지기 때문에 트래픽이 많지 않거나 커넥션을 오래 유지할 필요가 없다면 이 시간만큼 Fargate인스턴스를 더 사용하는 셈이다.

타겟그룹의 Draining에 걸리는 시간은 “Deregistration delay”항목에서 수정할 수 있다.

참고: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay

Docker Entrypoint와 쉘 함수의 사용

Docker 컨테이너는 Entrypoint를 가지고 있어서, 컨테이너를 하나의 실행파일처럼 동작할 수 있게 해준다.

An ENTRYPOINT allows you to configure a container that will run as an executable.

https://docs.docker.com/engine/reference/builder/#entrypoint

이를 이용해 때때로 활용하는 기법이 있는데, Entrypoint를 쉘 함수로 엮어 사용하는 방법이다.

최근 Jenkins에 AWSCLI v2를 사용해야할 일이 있었다. 이미 aws v1이 시스템 전체에 설치되어 운영되고 있기 때문에 명령어 충돌을 피하기 위해 이 방법을 사용했다.

#!/bin/env bash -x 

docker pull amazon/aws-cli
aws () { docker run --rm amazon/aws-cli [email protected] }

참고로 Interactive Shell에서는 alias를 사용해도 되지만, Non-Interactive 쉘에서 alias를 사용하려면 shopt 설정이 필요하다.

AWS MySQL Aurora 최대 접속수 수정방법

오랜만에 Aurora MySQL의 최대 접속수를 다시 지정했다. 개발용도의 데이터베이스는 사용량은 작지만 여러 프로젝트들이 connection pool 을 생성하니 기본 정의값보다 올려서 사용하는 경우가 종종있다. max_connections를 다시 지정한 파라미터 그룹으로 교체하면 된다. 이건 TIL이라 할 것도 없다.

하지만 글로 남기는건 10분이면 될 일을 1시간이나 헤맸기 때문.

  1. 클러스터 파라미터그룹과 인스턴스 파라미터 그룹 양쪽에 max_connections가 있다.
  2. 파라미터 수정 후 apply immediately로는 동작하지 않아서 reboot 후 적용되었다.

변경된 수치는 다음쿼리로 확인가능하다.

mysql> select @@max_connections;
+-------------------+
| @@max_connections |
+-------------------+
|               300 |
+-------------------+
1 row in set (0.00 sec)