금요일 오전이었다.

AWS EKS(Elastic Kubernetes Service)에서 새로 만드는 Pod 생성이 안되기 시작했다. 로그를 보니 컨테이너 구동할 때 TypeORM에서 디비 서버를 접근하는데 접근을 못해서 에러가 발생하고 있었다.

Error: getaddrinfo ENOTFOUND blahblah.blahblah.ap-northeast-2.rds.amazonaws.com
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:69:26)

아니 이게 무엇? 위 주소 값은 쿠버네티스(이하 k8s)에서 시크릿으로 관리하던 키이고 다른 파드에서는 이 값으로 잘돌고 있는데 갑자기 안된다고? 불현듯 스치는 이유는

  1. AWS 장애
  2. k8s DNS
  3. 앱 실수

이 세 가지였다.

안타깝게도 장애는 없었고, DNS도 별 문제 없었다. 기술지원까지 붙어서 이 문제를 해결하려 노력했다. 메시지가 서버 주소를 찾을 수 없다하니, DNS를 파보기 시작했다. 쿠버네티스 공식 문서를 참조, 파드에 쉘로 접속하여 nslookup을 했는데도 문제점을 찾을 수 없었다. 이렇게 오전부터 시작된 트러블 슈팅은 저녁때까지 이어졌고…

그렇다면 앱 실수인데 뭘해도 안되서 앱의 문제가 아닐까 의심했다. 사실 주소가 잘못되었을수도 있다. 시크릿을 제대로 읽지못하고 있는게 틀림없었다. 테스트삼아 주소를 하드코딩해서 넣어서 배포해봤다. 잘 돈다.

와 어이없네… 그럼 k8s 시크릿으로 넣는 값이 잘못되었단 말인가?

$ echo blahblah.blahblah.ap-northeast-2.rds.amazonaws.com | base64
YmxhaGJsYWguYmxhaGJsYWguYXAtbm9ydGhlYXN0LTIucmRzLmFtYXpvbmF3cy5jb20K

혹시 base64를 내가 잘못쓰고 있을까 싶어서 온라인 base64 엔코더에 넣어보았다. 값은

YmxhaGJsYWguYmxhaGJsYWguYXAtbm9ydGhlYXN0LTIucmRzLmFtYXpvbmF3cy5jb20=

어 왜 끝이 다르지…. 과거 내 쉘 히스토리를 살펴보니…

$ echo -n blahblah.blahblah.ap-northeast-2.rds.amazonaws.com | base64

그렇다. -n 옵션, 즉 개행문자 제거 옵션을 안걸고 base64 인코딩을 해서 이 사단이 발생한거였다. 즉 EKS도 아무 문제 없었던거고… 내가 바보였다.

간만에 인프라에서 트러블이 터져서 다시 한 번 복기하는 거지만, 문제의 원인을 찾을 때는 가장 취약한 부분부터. AWS와 k8s개발팀과 우리. 누가 실수했을 가능성이 컸겠는가. 대가는 꼬박 12시간이었다.