슬슬 12월의 AWS 요금이 결제될 것이라는 것은 알고 있었는데 5만원이라니. 뭔가 이상하다 싶어 AWS billing console에 들어가봤다. 사실 0 하나가 더 안 붙은게 어디인가 싶긴 한데, AWS lambda로 돌아가고 있는 서비스라 아무리 생각해봐도 이 금액이 나올 게 아니었다.
원인을 찾아보니 RDS 서비스에서만 약 25달러가 결제되고 있었다.
현재 RDS는 세 개의 개발 환경을 그대로 반영해서 prod, dev, test 총 3개의 인스턴스를 띄우고 있었다. 그래서 요금이 세 배로 나온 것으로 추측했다.
하지만 이런 식이면 요금을 유지할 수 없었기에... 일단 RDS를 지우기로 했다. 아직 사용 중인 서비스가 아니라서 괜찮다는 판단을 내렸다.
그리고 멘토님이 예전에 조언을 해 주셨던 구글 드라이브 동기화 방식이나 Firebase 등의 DB를 사용하는 방식으로 바꿔 보기로 했다.
바로 RDS에서 세 개의 인스턴스를 지워주었다.
이제 이에 맞춰서 DB를 사용하는 코드를 전부 Google Drive/iCloud를 사용하도록 바꿔 주어야 했다. 새삼 예전에 Java를 찍먹하면서 배웠던 설계 원칙 중 추상화가 덜 되었다는 생각이 들었다. 원칙대로라면 DB가 바뀌어도 구현 클래스를 추가로 만들면 view(controller) 단에서는 코드가 바뀌지 않아야 한다. 문득 Django에서도 개인이 코드를 작성하여 이런 DB 계층의 추상화를 할 수 있을지 궁금해졌다. 다음에 코드를 짜면서 알아보자.
현재는 수동으로 aws lambda에 직접 배포를 해야 하는 상황인데, main이나 develop 브랜치에 코드를 올리면 자동으로 zappa 명령어를 통해 변경 내용이 lambda에 반영되도록 하기
1번부터 실행해 보았다. 개발 환경으로 앱을 띄우는 명령어를 입력하니 초기 화면까지는 잘 나왔다. 그런데 그 다음부터가 되지 않았다. 'Apple로 로그인' 버튼을 누르고 이메일과 비밀번호를 입력해 주었더니 아무런 반응이 없다.
일단 원인으로 추측되는 부분은, 서버와 google developer console 등의 설정 문제로 ios에서 받아온 ios client id가 유효하지 않을 수 있다는 것이었다. 다행히 sentry를 활성화시켜둔 덕분에 에러 리포팅을 받아볼 수 있었다.
추측상 앱에서 api를 통해 ios clinet id를 받아오는 작업까지는 잘 진행된 것으로 보이고, 이후 해당 ios client id를 통한 애플 로그인까지도 잘 진행된 것 같다. 왜냐하면 앱 자체에서 애플 로그인이 잘 진행된 다음에 오류가 난 해당 api를 호출하기 때문이다.
그런데 쓰다보니 벌써 늦은 밤이다. 멀쩡한 월요일을 위해 오늘은 여기까지 해 보고, 다음에 InvalidAudienceError의 원인을 파악해 보자.
이제 다음 스텝으로 넘어갈 수 있어서 뿌듯하기도 하고, 그동안 모호한 상황에서 나름의 우여곡절을 겪었기에 이를 기록해서 정리해 보려고 한다.
연결하는 과정에서 필요한 서비스들은 다음과 같다. 내가 개발했던 과정에서는 이 외의 다른 서비스와 상호작용하지는 않았었다.
aws lambda
aws api gateway
aws certificate manager
porkbun
맨 처음으로는 api lambda가 퍼블릭 엔드포인트에서 잘 동작하는지를 확인해 주어야 하겠다. 그래야 api gateway를 통해 연결했을 때에도 잘 동작할 것이니 말이다.
그 다음으로는 aws certificate manager의 issued(발급 완료)된 인증서가 필요하다. 나는 이 문제로 헤매기 전에 이미 발급받은 인증서가 있는 상태였어서 어떻게 내가 이걸 발급했었는지 잘 기억이 나지 않았다. 그래서 다른 블로그의 글을 가져와봤다. 여기서 '도메인 SSL/TLS 인증서 추가하기' 부분에 해당 과정이 잘 설명되어 있어서 복습하는 데 도움이 많이 되었다.
그 다음으로는 api gateway로 이동해서 custom domain을 생성해야 한다. api gateway 서비스로 이동하면 좌측 메뉴에 '사용자 지정 도메인 이름'이라는 메뉴가 있다. (영어로는 아마 'custom domain'이 포함된 메뉴일 것이다.) 여기로 들어오면 나의 경우는 이미 연결해 둔 도메인이 있어서 하나의 레코드가 나오고, 없으면 추가하면 된다. '도메인 이름 추가' 버튼을 누르면 된다.
그러면 추가 페이지가 나오는데, 나는 '도메인 이름'과 'ACM 인증서'를 할당해주는 것 빼고는 설정을 바꾸지는 않았었다. 이런 식으로 할당했다.
도메인 이름을 입력해주고, 특정 VPC 내부에서만이 아닌 일반 URL 엔드포인트로 접근이 가능하게 하는 것이 목적이므로 '퍼블릭'으로 할당해줬다.
'API 엔드포인트 유형'의 경우 사실 잘 모르는 부분이었다. 그래도 REST API만 지원하도록 했다가 나중에 일부 기능이나 API가 동작하지 않는 경우가 있을 수도 있다고 생각해서 '리전별(권장)'으로 입력했었다.
최소 TLS 버전과 상호 TLS 인증 역시 기본값으로 두었다. 마지막의 ACM 인증서의 경우는 드롭다운 메뉴를 클릭해서 맞는 인증서를 할당해주면 된다. 나의 경우는 앞에 dev라는 서브도메인을 할당하려고 했기 때문에 *(와일드카드)가 붙은 인증서를 선택해 주었다.
이 부분은 처음 Certificate Manager에서 인증서를 발급받을 때 결정해야 한다. 그냥 도메인(stepby.one)과 와일드카드가 붙은 도메인(*.stepby.one) 총 두 개에 대해 인증서를 발급하면 편했다.
그리고 '도메인 이름 추가'를 눌러주자. 그 다음에는 이렇게 만든 custom domain 설정을 기존에 잘 동작하던 api gateway와 연결해주면 된다. api gateway 서비스로 다시 들어가보면 방금 생성된 '사용자 지정 도메인 이름(custom domain)'이 생겼을 텐데, 이 도메인 이름을 눌러서 들어가보자.
그러면 하단에 'API 매핑' 섹션이 보이고 아직은 아무것도 없을 것이다. 여기서 'API 매핑 구성'을 눌러서 매핑을 추가해주자. 나의 경우는 미리 할당해 둔 상태라서 이렇게 'backend-dev'라는 api gateway가 custom domain에 연결되어 있다.
그러면 이렇게 현재 활성화된 api gateway들 중 어떤 것을 해당 custom domain에 연결할지를 선택할 수 있다. 원하는 api gateway를 선택해 주고 저장 버튼을 누르자.
이제는 porkbun 사이트로 다시 들어간 다음 구매한 도메인에 대해서 cname 레코드를 추가해 주어야 한다. porkbun 사이트에서 로그인을 하고 우상단 메뉴의 'account' 메뉴를 클릭하면 드롭다운으로 하위 메뉴들이 나오는데, 여기서 'Domain Management'를 클릭해주자. 그러면 본인이 구매한 도메인 레코드들을 볼 수 있다.
여기서 본인이 구매한 도메인 이름에 마우스를 올리면 'DNS | NS' 라는 레코드가 나오고 클릭할 수 있다. 우리는 이미 연결된 도메인에 대해서 서브도메인을 추가로 설정하는 것이니 NS 부분은 건드릴 필요가 없고, DNS를 클릭해주자.
그러면 이런 화면이 나오면서 레코드를 추가할 수 있다. 우리는 서브도메인을 추가할 것이므로 CNAME 타입으로 설정하고, Host 부분의 이름은 설정하려는 서브도메인의 값을 입력해준다.
여기서 Answer / Value 부분이 중요한데, 이 값은 api gateway의 custom domain 상세보기 페이지로 들어가면 얻을 수 있다. api gateway의 '사용자 지정 도메인 이름' 메뉴로 들어가서 아까 추가한 레코드를 클릭해보자. 그러면 이런 화면이 나오는데, 여기의 'API Gateway 도메인 이름' 값을 입력해주면 된다.
그러면 이런 cname 타입 레코드가 생긴다.
해당 도메인의 레코드가 DNS 서버에 전파되어 접속이 가능하게 되려면 시간이 필요하다고 알고 있다. 정확한 시간은 없지만, TTL이 600초라서 나는 10분 내외를 예상했었다. 실제로는 약 1시간 정도의 시간이 걸렸던 것 같다(40분 이후에 시도해봤는데도 되지 않았기 때문에 그렇게 추측했다).
✅ 궁금한 점
CNAME 레코드는 보통 subdomain에 대해 매핑을 추가할 때 할당하는 레코드라고만 알고 있었다. 정확한 CNAME 레코드의 정의가 무엇일지 궁금하다. 정확히는 CNAME 타입이 무엇이길래 서브도메인을 추가하려면 CNAME 타입의 레코드를 추가해야 하는 것인지가 궁금하다.
전체 구조가 어떻게 되는 것인지 대강 말로는 설명할 수 있지만 그림이 그려지지는 않는다. 그림을 한번 그려보자.
문득 코딩웨일이라는 개발자 유튜브를 보다가 '일 잘 하는 개발자가 되려면 어떻게 해야 하는가'에 대해 생각해보게 되었다. 크게 두 가지의 인사이트를 얻었다. 하나는 내가 무의식적으로 생각하고 있던 부분이었고, 다른 하나는 아마 나를 비롯한 많은 신입 개발자들에게 있을 '임포스터 증후군'에 대한 위로이자 통찰이었다.
회사에서 원하는 개발자는 개발만 잘 하는 개발자가 아니라, 개발로 문제를 해결하는 개발자이다.
재능의 영역도 물론 있다. 하지만 소위 말하는 '잘 하는 개발자'가 되고 싶다는 거라면 이 부분은 잘 설정된 노력과 학습으로도 어느 정도 가능하다.
✅ '나 자신'과 '회사' 모두에 대해 이해하는 개발자가 되자
이런 종류의 영상을 보면서 항상 느끼는 점이 있는데, 개발자도 결국 하나의 직업이며 이 직업의 수요나 채용은 사회와의 관계(수요와 공급) 속에서 결정된다는 거였다. 예전에 소마에서 우리 엑스퍼트님이 해주신 말씀과도 맥락이 통한다. 그때 당시에는 취업 관련 조언으로 이 말을 해 주셨는데, 지금 생각해 보면 이 인사이트는 커리어를 쌓아 나가는 과정에서도 계속 유효하다고 생각한다. (정확히는 기억나지 않지만 이런 맥락이었다.)
채용은 '나'와 '회사' 사이의 핏을 맞춰 나가는 과정이다. 그렇기에 이력서를 쓰거나 면접을 볼 때에도 내가 생각하는 '나 자신'이 있고, 내가 생각하는 '회사'가 무엇인지를 말해 주고, 이 둘이 어떻게 핏을 맞춰 나갈 수 있을지를 드러내야 한다. 왜냐하면 회사에서는 회사에서 성과를 낼 개발자를 채용하려는 것이므로, '이 개발자는 어떤 사람인지'와 '그래서 우리 회사에 맞을지'가 궁금한 것이겠다. 이 두 가지를 이력서나 면접에서 풀어내려면 내가 현재 갖고 있는 '개발자로서의 나 자신'에 대한 생각과, '내가 지원하려는 회사'에 대한 생각을 정리해 봐야 하겠다.
그러니까 단순히 '나는 A라는 능력이 있다' 라는 개발자가 아니라, '나는 A라는 능력이 있고, 내가 이해하기로는 회사에서 B라는 업무를 하는데 여기서는 A라는 능력이 필요하다고 알고 있다. 그러므로 나는 회사에 적합한 인재이다' 라는 식으로 풀어나가는 것이 조금 더 맞다는 생각이었다.
✅ 업무 처리 능력 != 개발 실력
그리고 잠시나마 실무를 찍먹해 본 입장에서도 위의 인사이트에 공감했다. '개발을 잘 한다'고 하면 보통 코드를 간결하거나 빠르게 만들거나, 코드를 가독성 있게 짜거나, 전공지식이 탄탄한 경우를 생각하곤 했다. 그런데 그게 항상 업무를 잘 하는 걸로 이어지지는 않는다. (물론 대체로 이런 사람들이 실무를 더 잘 하기는 하는데, 인과관계는 아니라는 뜻이다.)
1년차 미만 개발자인 내가 보기에 실무를 잘 하는 주니어 개발자의 특징을 정리해 보았다. (시니어 개발자의 영역은 아직은 내가 알 수 없는 영역이라 제외했다.)
요구사항이 무엇인지를 잘 파악한다.
마감 기한을 잘 지킨다.
커뮤니케이션을 잘 한다. 가령 여러 문제로 마감 기한이 늦어질 위기에 처하는 경우가 있을 수 있다. 하지만 이 경우 자신의 문제 상황을 잘 공유하고 피드백을 구해서 잘 적용한다.
사실 이 정도가 생각난다. 그리고 생각보다 주니어 개발자를 평가할 때 순수한 코딩 실력으로만 이를 평가하지는 않을 것이다. 이전의 업무 경험에서는 나는 이런 피드백을 받았었다.
(두 사수분에게 모두 받았던 피드백) 모르는 것이나 어려움이 있을 때 꽁꽁 숨기지 말고, 시도해 본 다음에 안 되면 바로 질문해 줬으면 좋겠다. 그게 효율적이다.
(코드 리뷰 때 받은 피드백) 가독성이 좋게 코드를 짜는 것은 매우 중요하다. 내가 짠 코드를 후에 다른 개발자가 맡아서 작업할 수도 있기 때문이다.
(회식 때 받은 피드백) 문서화를 잘 하셔서 일이 어디까지 진행되고 있는지 알아보기가 편했다.
(마감 데드라인이 밀렸을 때 / 다른 분들이 예상하신 것보다 더 시간이 걸렸을 때) 일을 하면서 겪은 다른 어려움이 있는지 궁금하다. 작업을 방해한 다른 요소가 있는지 궁금하다. -> 책임을 물으시려는 의도가 아니었고 원인을 알아내서 같이 제거해 주려는 목적으로 여쭤보셨다.
이러한 것들이 생각난다. 여기서 느낀 점은, 생각보다 주니어에게 대단한 무언가를 기대하지는 않는다는 거였다. 네 개의 피드백 모두 어떻게 보면 커뮤니케이션 영역과 관련이 깊었다. 입사 후 바로 조직에서 성과를 낼 수 있는 주니어면 정말 좋겠지만, 내가 생각하기에 나는 그런 '슈퍼 신입'은 아니었다. 그걸 인정하고 다시 피드백을 보니, 최소한 조직이 돌아가는 방식이나 협업 프로세스를 빨리 파악하고 여기에 적응하는 주니어를 선호하는 것은 분명해 보였다.
그래서 나는 '슈퍼 신입'이 되려는 대신 전략을 바꿨다.
✅ 임포스터 증후군 극복하기
많은 신입들이 가면 증후군이 있다고 한다. 가령 '나는 회사의 기대를 충족할 만큼 잘 하고 실력 있는 사람이 아닌데, 근데 그걸 어떻게 잘 숨겨서 뽑힌 것이다. 내 실제 실력을 알면 실망할 것이다'와 비슷한 생각이다. 나도 이 가면 증후군이 있었고, 여전히 있다.
내가 실력이 좋아서 뽑힌 것은 아니라고 생각한다. 그저 괜찮아 보이는 몇 가지의 조건들이 충족되어서 서류를 통과했고, 면접관 입장에서는 크게 부정적인 방향으로 눈에 띄는 사람은 아니었기에 면접을 통과한 것이라고 생각한다. 절대 내가 잘 해서 뽑힌 게 아니라고 생각하고, 살면서 나는 이런 면에서 꽤 객관적이었던 만큼 실제로도 그럴 것이라고 생각한다.
그래서 불안하냐고 하면 그건 맞는데, 그래도 앞으로 어떻게 할지가 더 중요하다는 답을 내렸다. 그 전에 '나는 어떤 개발자가 되고 싶은가'에 대한 답을 내려야겠다.
문제를 기한 안에 해결하는 개발자
소통이 잘 되는 개발자
나는 1번 영역에 대해서 더 자신이 없다. 예상했던 것보다 일을 늦게 처리한 경험이 몇 번 있었기에, 오히려 1번 영역이 나의 콤플렉스에 가깝다. 그리고 지금까지 나는 문제를 기한 안에 해결하는 것 자체가 코딩을 잘 한다는 것이고, 나에게는 없는 재능이며, 순수한 재능의 영역이라고만 생각했었다.
그런데 발전시킬 수도 있지 않을까?
앞서 언급한 코딩웨일 유튜브를 보고 그런 생각이 들었다. 모두가 천부적인 재능으로 개발자를 하는 게 아니라면 나도 가능하지 않을까?
다만 깃털 같은 희망만을 품어서 될 일은 아니었다. 어떤 노력을 해서 이 능력을 좀 끌어올릴 수 있을지를 생각해 봤다. 내가 생각하기에는 나의 부족함을 빨리 맞닥뜨리는 연습이 필요한 것 같다. 가령 안 풀리는 부분이 있으면 빨리 공유해서 이에 대한 피드백을 받고, 새로운 방법을 모색하는 것이겠다.
그동안은 도움을 요청한다는 것 자체가 내가 혼자 해결해야 할 일인데 남에게 도움을 요청한다는, 어찌 보면 의존적이라는 생각이 들어서 잘 요청하지 못했었다. 그런데 아이러니하게도 주니어 개발자의 경우, 혼자 시도한 다음에 풀리지 않는 일이라면 피드백을 요청하고 그 피드백을 잘 수용하려고 노력하는 과정을 통해 더 빨리 발전할 수 있겠다는 생각이 들었다.
그러니까 이를 위해서는 나의 완벽주의를 좀 버려야 하겠다. 잘 하는 것처럼 보이고 싶고, 혼자 일을 완벽하게 해내고 싶은 마음을 잘 눌러야겠다. 열심히 시도해 보다가 모르면 현재의 나는 이걸 잘 모른다는 것을 겸허히 인정한 뒤 내가 할 수 있는 다른 방법, 피드백을 요청하는 것을 기꺼이 해야겠다.
회사 입장에서 중요한 것은 '내가 문제를 느리더라도 처음부터 끝까지 혼자 해결하는 것'이 아니라 '내가 효율적으로 빠르게 문제를 해결하는 것'일 테니 말이다. 일하면서 나 자신뿐만 아니라 '동료'와 '회사'가 나와 같이 일하고 있다는 것을 잃지 말자.
그리고 그렇게 나의 부족함을 계속해서 발견하고, 부끄럽고 민망하겠지만 이에 대한 조언이나 피드백을 구하고, 그걸 적용하려는 연습을 하다보면 분명 혼자 꽁꽁 싸매던 예전의 나보다는 더 빨리 발전할 수 있을 것이라는 확신이 든다.
4일 만에 이슈를 다시 잡았다. 여전히 배포를 목표로 했던 도메인 주소를 입력하니 사이트에 연결할 수 없다는 메시지가 뜬다. 그래서 이번에는 api gateway에서 lambda 함수로 잘 연결을 하고 있나 싶어서 api gateway의 퍼블릭 엔드포인트를 입력했더니 request timed out 메시지가 떴다.
그렇다는 것은 api gateway가 lambda에 제대로 연결하지 못했거나, lambda 자체에 문제가 있어서 실행이 종료되었을 수 있다는 거였다. 구체적인 lambda 로그를 봐 보았다. 'zappa tail dev' 명령어를 입력했더니 'calling tail for stage dev...' 라는 로그만 출력하고는 아무 반응이 없다. 그러다가 이런 반복적인 패턴의 로그를 출력하더라.
[1735266140183] Instancing..
[1735266155772] Instancing..
[1735266170217] 2024-12-27T02:22:50.217Z e11db634-ef8a-4258-9d46-0b5e878cd834 Task timed out after 30.03 seconds
[1735266170235] INIT_START Runtime Version: python:3.12.v38 Runtime Version ARN: arn:aws:lambda:ap-northeast-2::runtime:7515e00d6763496e7a147ffa395ef5b0f0c1ffd6064130abb5ecde5a6d630e86
대강 이런 형식의 로그가 반복되는 것으로 봐서, 초기화를 시도했다가 task가 모종의 이유로 timed out 되었다는 것까지만 추측했다. 그리고 예전에 warm callback으로 설정했던 것처럼 2분마다 해당 로그가 반복되고 있었다.
그렇다면 왜 timed out이 되었을까? 30초 이후에 task가 timed out이 되었다고 나와 있다. 일단 내가 이해한대로 질의를 해 보자.
현재 zappa를 사용해서 python(django)코드를 aws lambda에 배포한 상태야. 그리고 api gateway의 퍼블릭 엔드포인트를 통해 url로 람다 함수를 호출할 수 있도록 설정해 놓았어. 그런데 두 가지 [문제]가 있어. 이 문제에 대한 [추측]을 보고 [추측]이 합당한지 말해주고, 합당하지 않다면 다른 가능성은 무엇이 있을지 말해줘
[문제] 1. api gateway의 퍼블릭 엔드포인트로 접속하면 request timed out 오류가 발생한다. 2. 'zappa tail dev'를 통해 배포 로그를 보면 다음과 같은 패턴이 반복된다. 2-1. 'Instancing.... '이라는 초기화 로그가 찍힌다. 2-2. 'Task timed out after 30 seconds' 라는 문구가 찍힌다.
[추측] 1. api gateway에서 request timed out 오류가 나는 이유는 문제 2번의 task timed out 오류 때문이다. 2. 문제 2번에서 task timed out 오류가 나는 이유는 lambda 함수가 실행되는 데 30초가 넘게 걸려서일 수 있다.
문제는 aws lambda를 처음 api gateway를 통해 퍼블릭 엔드포인트로 접속할 수 있도록 설정했을 때는 접속이 잘 되었다는 거야. 시간이 지났을 때 접속이 불가능해지는 것도 가능할까? [추측]이 그럴듯한지 말해주고 그럴 가능성이 없다면 다른 대안을 제시해줘
[추측] 매번 lambda 함수를 호출할 때마다 로그나 메모리가 쌓이고, 이것이 기존 설정해 놓은 메모리 값을 초과하여 lambda 함수가 제대로 응답하지 못할 수 있다.
GPT가 제시한 오류 가능성들은 다음과 같았다.
lambda의 cold start로 인해 실행시간이 길어지고, 이로 인해 api gateway나 lambda의 timeout 시간을 넘어서는 경우
lambda 함수가 사용하는 메모리가 zappa로 설정해 준 메모리 값을 초과하는 경우
cloudwatch 로그가 과도하게 쌓이는 경우 (그런데 왜 이게 lambda 실행에 영향을 주는지는 정확히 이해하진 못했다)
VPC의 네트워크 대역폭 제한으로 인해 접근이 불가능해서 발생하는 오류
비록 GPT가 제시해 주었으나 각 항목별로 개인적으로는 이해가 잘 되지 않는 부분들이 있었다.
cold start의 경우, 이미 2분 간격으로 ping을 쏘고 있는데 cold start가 일어난다는 것이 아이러니했다.
메모리 값을 초과하는 경우, 애초에 처음부터 아예 접속이 안 되었어야 한다. lambda는 stateless해서 이전 요청의 메모리를 저장하지 않는다고 했는데, 그렇다면 초기에는 잘 동작하다가 이후부터 동작이 안 되는 것을 설명하기 애매하다.
cloudwatch의 로그가 lambda의 직접적인 실행에 영향을 미치는지 잘 모르겠다.
VPC의 네트워크 대역폭 제한으로 접근이 불가능하려면 처음부터 접근이 불가능했어야 했다.
우선은 이 원인들 중 2번의 메모리와 3번의 cloudwatch 로그의 경우 추가적인 처리를 해줄 수 있는 원인들이었으므로 처리를 해 주기로 했다.
2번의 경우 'zappa update dev' 명령어를 통해 설정을 바꾸면 되려나 싶었다가도, 이게 단순 코드 변경 사항만 반영되는 것인지가 헷갈렸다. 즉 lambda 함수에 할당된 메모리 값을 바꾸려면 zappa_settings.json 파일을 직접 수정해야 하는데 이 수정사항이 deploy가 아닌 update 명령어로도 반영될지를 모르겠었다.
zappa 공식문서를 읽어보니 update 명령어와 별개로 redeploy 명령어도 있었다. redeploy 명령어를 실행하면 왠지 모르게 .json 설정 파일의 설정들도 반영이 될 것 같았다. 그렇다면 update와 redeploy의 차이점은 뭘까?
기본적으로 zappa update는 기존의 실행 중인 lambda 함수/리소스에 변경된 사항만 덮어쓰는 명령어인 반면, redeploy 명령어는 아예 기존에 실행 중인 리소스를 종료하고(내리고) 새 컨테이너나 리소스를 다시 만들어서 올리는 작업을 수행한다고 한다. 그래봤자 결과는 똑같은 거 아닌가? 라는 의문이 들었다. 결론적으로 결과값이 아예 똑같은 건 아니었고, 무언가를 변경할 때 update로만 가능한 경우가 있고 redeploy 명령어를 써야 하는 경우도 있었다.
대표적인 경우가 코드나 라이브러리만 설치할 때와 api gateway, iam 설정 등을 모두 변경하는 경우의 차이였다. 전자는 lambda 외부의 리소스를 변경하는 것이 아니라서 update 명령어로 가능하지만, 후자는 lambda 외부의 리소스(api gateway, iam)를 변경하는 것이라서 update 명령어로 반영이 안 되고 redeploy 명령어를 써야 한다고 이해했다.
메모리 크기를 변경하는 경우는 lambda 외부의 리소스를 변경하는 것이 아니라서 update 명령어로도 반영이 가능하다고 했다. 그런데 우선은 지금 lambda 함수에 얼만큼의 최대 메모리가 할당되어 있고, 해당 함수는 지금 어느 정도의 메모리를 쓰고 있는지를 알아봐야 할 것 같았다. 이건 cloudwatch의 로그로 확인할 수 있다고 한다.
로그를 확인해보니 의외로 1번 원인인 cold start에 주목하게 되었다. 왜냐하면 21초 정도에 'Instancing' 이라는 컨테이너 초기화 로그가 뜨고, 30초간 아무 로그가 없다가 task가 timed out 되면서 request timed out 요청이 떨어진 것으로 보였기 때문이다. 그리고 이 로그는 약 2분 간격으로 반복되고 있었다. 즉 warm callback 함수는 잘 적용되었는데 그럼에도 불구하고 cold start 패턴이 보였다. 이게 가능한가? 그런데 그렇다면 왜 배포 당일에는 이런 문제가 없었을까?
우선은 2가지 문제가 있어 보였다.
cold start가 발생하는 문제
cold start가 발생할 때 초기화 시간이 api gateway, lambda의 timeout 시간인 30초보다 길게 걸린다는 문제
1번도 문제이지만 2번도 제법 문제라고 생각했다. 단순히 api gateway, lambda의 timeout을 늘리고 cold start를 방지한다고 해도, 몇 초가 걸리는 것이면 모르겠는데 30초 이상이면 분명 문제가 있다고 생각했다. 문제는 나는 뭐 때문에 이렇게 길게 걸리는지를 알고 싶은 것인데, 로그에는 그 정보가 다 안 담겨 있다는 거였다. 더 자세한, 아예 실행 환경에서의 로그를 볼 수 있는 방법은 없을까?
여기서 API gateway 이후의 작업은 현재 상황에서는 일단은 동작하는 것으로 이해했다. 그렇다면 그 이전의 작업인 '우리 서버 도메인 엔드포인트로 요청을 보냈을 때 API gateway를 찾아내는 작업'을 해 주면 되겠다.
즉 지금은 api gateway에 기본으로 할당된 길고 이상한 도메인 주소를 입력하면 연결은 되는데, 그걸 바라지는 않는다. 간결하고 깔쌈한 도메인 주소를 입력했을 때 연결이 되도록 바꿔보자.
원래는 route53이라는 aws의 호스팅 서비스를 사용하려고 했다. 다만 기존에 porkbun이라는 사이트에서 구매해 둔 도메인 레코드가 있어서 그걸 쓰려고 하는데, 이걸 route53과 연결하면 되지 않을까? 라는 생각이 들었다.
다만 기존과는 상황이 좀 달라진 게, 기존에는 route53에 ALB 레코드를 연결해서 사용했었다. 그런데 이제는 lambda를 사용하기 때문에 이 lambda를 호출하는 일종의 프록시 역할을 해 주는 api gateway를 route53과 연결해야 한다고 이해했었다.
그런데 또 찾아보니 api gateway에는 custom domain(사용자 지정 도메인 이름)이라는 기능이 있었다. 이를 통해서 내가 원하는 도메인 이름을 지정한 다음에, 그 도메인 이름을 내가 갖고 있는 api gateway의 api와 연결시킬 수 있었다.
물론 당연히 아무 이름이나 연결하면 바로 사용할 수 있는 것은 아니었다. 사용하려는 도메인 이름을 입력한 다음에는 그 이름을 사용할 수 있음을 입증하는 aws certificate manager의 인증서가 필요했다. 이 인증서는 또 어떻게 발급받을 수 있냐 하면, aws certificate manager 서비스로 이동해서 인증서를 만든다. 여기에는 옵션으로 'DNS 인증'과 '이메일 인증'이 있는데, 본인이 도메인을 직접 타 혹은 aws route53 사이트 등에서 구매했다면 DNS 인증을 누르면 된다. 그리고 그냥 완료를 누르면 인증서가 생성된다.
다만 이 인증서는 처음에 생성되었을 경우에는 '검증 대기 중'일 것이다. 정확히 어떤 검증 과정이 일어나는지는 모르지만(모르니까 일단은 블랙 박스로 가정하고 넘어가자), 검증이 완료되면 'issued(발급됨)' 이라고 뜬다. 이렇게 말이다.
물론 아무것도 안 하고 마법처럼 발급이 되는 것은 아니다. 나의 경우 porkbun이라는 외부 사이트를 사용했는데, 이처럼 외부 사이트를 사용한 경우에 대해서만 간단하게 기록해 보겠다.
우선 인증서가 발급이 완료되면 'cname 레코드'라는 것이 생성된다.
이 키-값 형태의 레코드를 가지고 porkbun이나 기타 본인이 등록한 외부 사이트에 로그인해서 내가 구매한 레코드의 편집 화면으로 가 보자. 나의 경우는 다음과 같다.
여기서 레코드에 상세 정보 등을 보면 NS 또는 DNS 레코드를 편집할 수 있다. (porkbun의 경우는 있다.) 이런 화면에서 DNS 레코드를 추가해 준다. 이때 cname 타입의 레코드를 추가하고, host name과 value의 값을 입력해야 한다. 이 값은 위에서 aws certificate manager 인증서를 발급했을 때 나온 키와 값을 그대로 적어주면 된다. 그리고 기다리면 된다.
이 기다리는 과정이 제법 난관이었던 것이, 몇 초만에 반영이 되는 게 아니고 최대 24시간을 기다려야 한다. 물론 대부분은 몇 분 이내 발급된다. 그러나 몇 분이 애매하게 지나면 아직 발급이 안 된 건지 아니면 내가 뭘 잘못 작성한건지 싶어서 조금씩 손을 보게 된다. 나도 10분 이상은 기다린 것 같은데, 대략 10분 정도가 넘었는데 별 소식이 없다면 한 번쯤 잘못 작성한 부분이 있나 점검해보는 것도 좋을 것 같다.
암튼 이렇게 해서 api gateway의 custom domain 설정을 위한 aws certificate manager의 인증서를 발급받았다. 이제 이 인증서를 사용해 주자. api gateway 서비스의 '사용자 지정 도메인 이름'으로 들어가서 '도메인 이름 추가'를 눌러주자.
그러면 총 6가지를 선택하라고 나온다. 사실 정답은 없지만 나의 경우 두 가지만 직접 설정해주면 되고 나머지 기본으로 되어있는 옵션은 그대로 둬 봤다.
도메인 이름: 연결하고 싶은, 정확히는 아까 aws 외부/내부에서 등록했던 도메인의 이름을 적는다.
도메인 퍼블릭/프라이빗 여부: 공용에서 접근할 수 있는 것을 원한다면 기본값인 퍼블릭으로 두면 되겠다.
api 엔드포인트 유형: 나는 권장하는 옵션인 '리전별(권장)'으로 두었다.
최소 TLS 버전: 기본값인 1.2를 그대로 두었다.
상호 TLS 인증 사용: 안 사용하는 기본값으로 두었다.
ACM 인증서: 방금 전 발급받은 certificate manager의 인증서를 넣어주자.
그러면 이런 기쁜 소식을 접할 수 있다.
그래서 나는 다 된 줄로만 알았다. 호기롭게 postman에 새로 발급받은 도메인을 입력해 보았을 때 말이다. 그런데 안 되는 게 아닌가. http로 연결하면 기본 주소로 돌아오고, https로 연결하면 '지원되지 않은 프로토콜을 사용한다'고 떠서 추가적인 처리가 필요하다고 생각했다.
GPT 질의로 간단하게 알아볼 수 있겠지만 우선 혼자서 생각해 봤다. 뭐가 더 필요할까?
HTTP로 연결하면 기본 주소로 돌아오는 경우, route53 등의 aws 서비스에 추가적인 연결이 필요할 수도 있겠다. 왜냐하면 현재는 porkbun의 레코드로 호스팅이 되는 상태이고, 그런데 정확히는 porkbun의 ns(name server) 레코드 값으로 route53에서 새로 호스팅 영역을 생성했을 때 받은 기본 ns 레코드의 값을 넣어 주었다. 그러니까 현재는 아마도 해당 도메인으로 연결이 들어오면 'DNS 서버 -> porkbun -> route53' 식으로 요청이 전달된다고 나는 이해했는데, 이 route53과 api gateway의 custom domain을 별도로 연결해 준 적이 없어서 aws lambda로 요청이 전달되지 않는다고 볼 수도 있겠다.
HTTPS로 연결하면 '지원하지 않는 프로토콜'이라고 뜨는 경우, 도메인 그 자체보다는 프로토콜의 문제이므로 ACM 인증서와 관련된 문제일 것이라고 추측했다.
이제 이 답을 가지고 GPT 질의를 해 보자.
[문제 상황]과 [문제 상황에 대한 추측]을 바탕으로 [문제 상황에 대한 추측]이 적절한지 알려주고 만약 아니라면 다른 해결책을 제시해줘
[문제 상황] 현재 porkbun이라는 외부 사이트에서 도메인을 하나 구입하고, route53에서 호스팅 영역을 하나 생성한 뒤 기본으로 생성된 ns 레코드의 값을 porkbun에서 구매한 도메인의 ns 레코드 값으로 넣어 주었다. 또한 api gateway의 api에서 이 도메인을 사용하는 것이 목표였으므로 api gateway의 api에 대해서 custom domain 레코드를 만들어 주었다. 이를 위해서 porkbun 도메인에 대한 acm 인증서도 만들어 주었다.
그러나 postman에 새로 발급받은 도메인을 입력해 보았을 때, http로 연결하면 기본 주소로 돌아오고, https로 연결하면 '지원되지 않은 프로토콜을 사용한다'는 문제가 발생하여 추가적인 처리가 필요하다고 생각했다.
[문제 상황에 대한 추측] 1. HTTP로 연결하면 기본 주소로 돌아오는 경우, route53 등의 aws 서비스에 추가적인 연결이 필요할 수도 있겠다. 왜냐하면 현재는 porkbun의 레코드로 호스팅이 되는 상태이고, 그런데 정확히는 porkbun의 ns(name server) 레코드 값으로 route53에서 새로 호스팅 영역을 생성했을 때 받은 기본 ns 레코드의 값을 넣어 주었다. 그러니까 현재는 아마도 해당 도메인으로 연결이 들어오면 'DNS 서버 -> porkbun -> route53' 식으로 요청이 전달된다고 나는 이해했는데, 이 route53과 api gateway의 custom domain을 별도로 연결해 준 적이 없어서 aws lambda로 요청이 전달되지 않는다고 볼 수도 있겠다. 2. HTTPS로 연결하면 '지원하지 않는 프로토콜'이라고 뜨는 경우, 도메인 그 자체보다는 프로토콜의 문제이므로 ACM 인증서와 관련된 문제일 것이라고 추측했다.
답으로는 1번, 2번의 추측 모두 상당히 가능성이 높다는 평을 받았다. GPT가 제시한 방법도 모두 1번, 2번에 해당하는 방법들이었다. 이 정도면 나름의 신빙성을 1차로 확보한 셈이니 우선 이 방법들을 실행해 보기로 했다.
우선 1번부터 실행해 보자. Route53 서비스에 A(alias)타입 레코드를 생성하고, '별칭'을 활성화시켜서 api gateway에서 등록한 custom domain 레코드를 등록해 주었다.
그런데 좀 이따 깜빡한 것 하나를 알았다. api gateway의 custom domain 페이지로 가 보면 아래 'api 매핑'이라는 것이 있는데 이걸 안 해줬다. 즉 custom domain 레코드를 생성한 다음에 api gateway의 api와 매핑을 해 주었어야 했다. 나는 이걸 깜빡했어서 뒤늦게 추가해 주었다.
그런데도 안 된다. 현재까지 내가 이해한 연결 과정을 정리해보고, 빠뜨린 부분이 있는지를 찾아보자.
✅ 궁금한 점
aws certificate manager 서비스에서는 어떤 과정을 거쳐서 인증서를 검증할까?
api gateway의 custom domain은 무슨 역할을 하는 서비스이며, route53 서비스와는 어떤 차이점이 있을까?
우선 원인을 알 수가 없는데... 분명 그저께까지 오류가 나던 'zappa update dev' 명령어에서 오류가 안 난다. 왜인지를 몰라서 답답하긴 한데 암튼 그렇다. 기본 URL 엔드포인트를 입력하면 404 에러가 뜨는데, 이건 말 그대로 해당 URL에 매핑된 view가 없어서 나는 에러였다. 토큰이나 개별 권한이 필요 없는 단순 조회 API를 검색해 봤더니 바로 잘 뜨더라.
이제 문제는 프론트 앱에서 이 엔드포인트를 사용하게 하는 것이다. 어떻게 가능하게 할 수 있을까? 내가 걱정되는 부분은 다음과 같았다.
AWS lambda는 stable한가? 즉 갑자기 서버가 죽는 일이 없을까? 있다면 얼마나 빈번하게 일어날까?
AWS lambda의 과금은 괜찮은가? 사용자가 없는 상태에서는 당연히 괜찮을 것 같긴 한데, 한 달에 어느 정도의 요금을 예상해볼 수 있을까?
응답 시간은 괜찮을까? lambda와 일반 ecs-ec2 서비스의 동작 방법의 차이를 아직 잘 몰라서, 너무 느리지는 않을까 걱정이다.
이 정도의 문제가 있었다. 여기에 대한 내 예상 답변은 다음과 같았다.
'절대로' 죽지 않는 서버나 서비스는 아마도 없을 것이다. 중요한 것은 멘토님도 언급하셨던 graceful shutdown이 아닐까. 갑자기 처리하던 요청을 다 뱉고 그냥 죽어버리는 게 아니라, 그 유예기간 안에 notification을 받을 수 있고 그 안에 들어온 요청을 deny하거나 최대한 처리할 수 있도록 하는 것이 바람직하겠다.
내가 예상할 수 없다. 이 경우 대략적인 수치를 예상한 다음에 GPT에게 계산을 부탁하는 것이 낫겠다.
우선 '너무'의 기준을 정해야 하겠다. 그리고 GPT에게 동작 방법의 차이를 물어보자.
질의를 통해서도 한번 알아보았다. 우선은 1번 질문처럼 AWS lambda의 동작 방식이 기존의 ECS-EC2 동작 방식에 비해 더 안정된 것인지(서버가 갑자기 죽는 일이 덜한지)가 궁금했다. 마치 내가 면접관이 된 것처럼 GPT에게 꼬리 질문들을 통해 나름의 답을 구해 보았다.
AWS의 배포 방식 중 ECS, EC2를 같이 사용하는 방법과 AWS lambda를 사용해서 서버리스로 배포하는 방법 중 어떤 것이 더 서버가 죽는 일이 덜하고 안정적인지가 궁금해
여기서는 aws lambda와 aws ecs-ec2 배포의 차이(장단점)를 다음과 같이 언급했다.
aws lambda는 서버리스인 반면(실제로 서버라는 개념이 아예 없는 것은 아니고, 서버 리소스 등의 관리를 aws에게 위임하는 방식으로 이해했다), aws ecs-ec2는 서버 내부에 사용자가 접근해서 구체적인 대응과 모니터링이 가능하다.
aws lambda는 ecs로 배포했을 때처럼 장애에 직접적으로 대응해야 한다는 단점이 없는 반면, 오랫동안 리소스가 사용되지 않는 경우 발생하는 cold start 문제(일정 시간 이상 aws lambda가 호출되지 않으면 나중에 호출되었을 때 새로운 컨테이너가 초기화되는데, 그 과정에서 시간이 지연되는 문제)가 있다. 그리고 이 문제를 완화하기 위해서는 주기적으로 ping을 보내거나, provisioned concurrency라는 것을 사용하면 지정된 수의 컨테이너를 항상 활성화 상태로 유지할 수 있다고 한다. 다만 후자의 경우 비용은 추가될 수 있다.
나는 주기적으로 ping을 보내는 것도 괜찮지만 굳이 얼마인지 정확하게 알 수 없는 유휴 시간을 위해 ping을 보내서 불필요한 트래픽을 만드는 것보다는 provisioned concurrency를 통해서 컨테이너를 항상 활성화 상태로 유지하는 방법이 더 낫다고 생각했다. 다만 비용이 추가된다고 하니 얼마인지는 대략이나마 알고 싶었다.
cold start 문제를 완화하는 방법들 중 provisioned concurrency 방법을 사용하고 싶어. 내가 배포하려는 서비스는 트래픽이 많지는 않아서 cold start가 많이 발생할 것이라고 판단했기 때문이야. 만약 이 방법을 사용한다면 추가 비용이 어느 정도 발생할지도 궁금해
여기서는 lambda의 기본 요금 + provisioned concurrency의 추가 요금을 합해서 총 요금을 계산했다고 이해했다. 다만 lambda의 경우 매월 백만 건의 요청과 40만GB/초의 실행 시간이 무료라고 한다(사실 뒤의 부분은 잘 이해를 못 하고 넘어갔다). 어쨌든 하루에 최대 500개의 요청을 가정해도 한 달에 3만 건이기 때문에 lambda에서 발생하는 기본 비용은 일단은 0으로 가정하고 넘어갔다.
provisioned concurrency의 경우, 자세한 건 실행 후의 요금을 봐야 하겠지만 대략 '최소한의 동시 실행 환경 수 * 시간 * 리전 별로 다르게 적용되는 요금(GB/초)'이 최종 가격이라고 한다. GPT는 다음과 같은 상황을 가정해서 총 금액을 계산했다.
하루 평균 요청 수: 500개
Lambda 함수의 평균 실행 시간: 100ms
메모리: 512MB (메모리의 크기와 Lambda 함수의 평균 실행 시간이 반비례하는 것으로 보였다)
총 금액: 약 12달러 이내 (약 18,000원 이내)
한 달에 서버비 2만원 이내면 나름 괜찮은 환경이라고 생각했다. 위 질문들을 통해 기존의 2번과 3번 질문에 대해서도 답을 얻었다. 결국 몇 개의 컨테이너(provisioned concurrency)를 사용하고, 메모리의 크기를 얼마로 설정하는지 등에 따라서 달라지는 값이었다. 그리고 사용자가 초기에 당연히 많지는 않을 것이므로, 이 상황에서 월 2만원 이내의 비용은 합리적이라고 생각했다.
그럼 이제 provisioned concurrency를 통해 aws lambda를 cold start 문제 없이 사용해 보자.
콘솔과 CLI 모두 가능했는데, 콘솔이 더 간단해 보여서 콘솔로 설정해보려고 했다. 우선 기존 버전에는 provisioned concurrency가 적용되지 않았으므로 새 버전을 배포해야 한다고 해서, 버전을 배포해 주었다.... 그랬는데 안 된다. 콘솔에서는 다음과 같은 에러가 나왔다.
그래서 CLI로 실행해 보았더니 맥락상 비슷한 에러가 나왔다.
맥락 상 추측해보면 '예약되지 않은 최소 계정 동시성'은 당장 사용할 수 없는 값이라고 이해했고, 사용하려면 이 값을 10이 아닌 8(2개의 동시성을 사용하고자 하는 경우라면) 등으로 줄여 줘야 한다고 이해했다. 그래서 아래와 같은 명령어도 입력해 보았다.
이후 다시 실행해 봤지만 똑같았다. 여기서 다시 고민했다. 여기서 에러를 계속 디버깅해 볼 수도 있겠지만, 저번에도 그러다가 4시간의 삽질을 한 것이 생각났다.
만약 provisioned concurrency 방법의 대안이었던 ping을 쏘는 방법도 비용적으로 괜찮은 선택지라면 그 방법을 써도 되지 않을까? 바로 물어봤다.
아까 위에서 네가 'cold start 문제를 완화하는 방법'들에 대해서 알려줬잖아. 여기서 두 가지 방법(provisioned concurrency, ping) 중 하나를 사용하고 싶어. 만약 1일간 호출이 500개가 되지 않는 서비스라면 비용 면에서 어떤 방법이 더 나을지 설명해줘
놀랍게도 1분 간격으로 ping을 쏜다고 가정했을 때 ping을 쏘는 방법이 더 저렴했다. 그렇다면 굳이 provisioned concurrency를 사용할 이유가 없었다. 녀석(GPT)은 만약 운영 중 트래픽이 늘거나, ping을 사용했음에도 cold start가 지속적으로 발생한다면 그때는 provisioned concurrency를 사용할 것을 추천해줬다.
그렇다면 그래도 cold start 발생 가능성을 더 줄여봐야 하지 않나 싶어서 다시 질의해봤다.
ping 방식을 사용했을 때 cold start 문제가 최대한 발생하지 않도록 하고 싶어. 하지만 cold start 문제의 경우 최대 몇 초/분간 요청이 없어야지만 cold start 현상이 나타나는지를 정확히 알 수 없다는 문제가 있는 걸로 알고 있어. 이 경우 ping 방식을 사용할 때 어느 정도의 간격으로 ping을 보내야 cold start 문제가 발생할 확률을 1% 이내로 줄일 수 있을지 알려줘
GPT가 제시하는 1%의 cold start 확률 이내의 ping 간격은 2분이었다. 즉 아까보다 ping을 덜 쏘아도 provisioned concurrency를 선택했을 때보다 현재 상황에서는 비용이 저렴하다고 이해했다. 그래서 provisioned concurrency 대신에 ping을 쏴 보기로 결정했다.
그런데 aws lambda에게 ping을 쏘는 주체는 누구일지도 궁금했다. 질의를 통해 알아보니 cloudwatch event에서 쏜다고 했다. cloudwatch는 모니터링 툴이라고만 알고 있었는데 여기서 ping을 쏜다니 의아했다. 이것도 물어보니 cloudwatch 서비스의 하위 기능들 중 cloudwatch event를 제공해서, 이벤트를 직접 발생시키거나, 특정 이벤트가 발생했을 때 이를 기반으로 다른 작업을 수행할 수 있도록 해 준다고 했다. 여기서 ping을 쏘는 것은 이벤트를 직접 발생시키는 경우에 속할 것이다.
그러면 cold start를 방지하기 위해서 aws lambda에게 ping을 주기적으로 쏘도록 cloudwatch event를 설정해 보자. 'cloudwatch' 서비스를 입력해서 들어간 뒤, 왼쪽 메뉴에서 이벤트>규칙을 눌러봤다. 신기하게도 이미 warm callback이라고 된, 즉 방금 얘기한 것과 같이 cold start를 방지하기 위한 콜백용 이벤트를 발생시키고 있었다.
다만 간격이 2분이 아닌 4분이라서, 확률 상 cold start가 발생할 수도 있다고 판단했다. 그래서 해당 시간 간격만 2분으로 줄여 주었다.
이제 cloudwatch에서 2분마다 이벤트를 발생시켜서 aws lambda 함수를 호출한다. 이 warm callback을 통해서 cold start를 방지할 수 있을 것이다.
✅ 궁금한 점
aws lambda가 aws ecs-ec2였다면 직접 대응을 해야 하는 상황이지만 서버리스라서 직접 대응을 안 해도 되는 경우가 있을 것이다. 구체적으로 어떤 경우들이 있을지 궁금하다.
