클라우드 개발자 앙몬드

람다를 4년가까이 썼는데, 모르는게 아직도 많은 것 같다

글로벌 선언 시 최초 콜드스타트 시점에 일반 오브젝트들만 유지하는게 아니라 커넥션도 유지하는거였다는 사실을 왜 이제 알았을까

람다의 라이프사이클 얘기가 나오는데, 최초 초기화 때 커넥션 재사용하는 부분이 나와있다.

하나 또 잘 배웠다 굳

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle-ib

최근 재미있는 업무 요청이 있었댜

EKS로의 접근 구간 게이트웨이는 대개 LB를 배치해서 진입 구간을 제한한댜 (인그레스)

그게 L4가 되었든 L7이 되었든...

AWS ELB들을 레버리징하는 EKS의 LB들은 SSL 오프로드가 LB레벨에서 이루어진댜

자세한건 밑의 AWS 레퍼런스를 보쟈

https://aws.amazon.com/ko/blogs/aws/elastic-load-balancer-ssl-support-options/

이 떄, 인그레스로 접근 시, path별 리스너가 모두 따로 나뉘게 된댜

/a -> A SVC오브젝트

/b -> B SVC 오브젝트

그리고 호스팅하는 도메인 주소는 AWS 디폴트 주소가 되었든 혹은 SSL 인증서를 입힌 도메인 주소가 된댜

따라서, 이 도메인을 myeks.com 이라고 가정하고, a 앱으로 요청하려면 하기 구조를 가진댜

myeks.com/a  ->  EKS내의 A SVC오브젝트 (쿠버프록시) -> A파드

이슈는 바로 반드시 /a 라는 컨텍스트 패스를 클라이언트가 명시해야한댜.

마이그레이션 하는 클라이언트는 기존에 xyz.com 이라는 도메인만 호출하고, HTTP 메서드도 유지해야 하는데...

처음 생각해본 리디렉션 프록시는 ALB 리디렉션 리스너이댜

https://aws.amazon.com/ko/premiumsupport/knowledge-center/elb-redirect-to-another-domain-with-alb/

여기서 xyz.com -> myeks.com/a  로 보내는 형태이다.

단 이 ALB 리디렉션은 큰 문제가 있댜

바로 301 / 302 응답만 리디렉션이 된댜

우리는 대개 2xx, 4xx, 5xx 응답만을 주로 보고 3xx 응답은 왠만하면 크게 볼일이 없댜

이번에 3xx 응답을 볼줄은...

만약 POST 메서드로, 고객이 xyz.com > myeks.com/a 로 ALB가 리디렉션하게 되면, 무조건 GET 메서드로 치환된다.

이는 301 / 302 응답을 좀 더 확인해볼 필요가 있댜...

다른 멋진 분이 3xx 응답에 대한 정의 다이어그램을 정리해두었으니, 가서 보쟈

https://perfectacle.github.io/2017/10/16/http-status-code-307-vs-308/

클라이언트가 POST로 요청하면, ALB 리디렉션은 이를 모두 GET으로 치환한댜

위와 같은 방법을 유지하고, HTTP Method도 유지할 수 있는 방법은?

307 / 308 응답을 주어서 메서드를 유지하며 리디렉션하는 것!

개인적으로 찾은 회피책은 CF와 람다엣지 조합이댜

xyz.com > CF > 람다엣지 - 307/308 응답 > myeks.com/a

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html

코드는 그리 어렵지 않댜

유의 사항으로, AWS 클라우드프론트 (CloudFront. CF. 클라우드포메이션 아님) 는 글로벌이고 각 리전 네트워크 엣지에서 서비스를 수행한댜

CF 도메인에 SSL 인증서 (AWS ACM) 을 입혀본 경험이 있는 사람은 바로 눈치챌 것이댜

CF 인증서는 us-east-1, 노스 버지니아에서 따서 입혀야 한다는 것을.

마찬가지로 CF에서 요청을 인터셉트하여 리디렉션을 수행하는 람다엣지 또한 노스 버지니아에 배포한 뒤, CF 요청을 트리거링해야 한댜

람다 콘솔에서 트리거 추가할 떄, 다른 리전과는 달리 us-east-1 에서 람다 트리거 항목에 유일하게 CloudFront가 있는 것을 확인할 수 있댜

CF의 네트워킹 구간은 4개로 나뉜다.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html

- 뷰어 리퀘스트

- 오리진 리퀘스트

- 오리진 리스판스

- 뷰어 리스판스

리디렉션 코드를 수행해야 하는 부분은 당연히 최초 요청이 진입하는 뷰어 리퀘스트 구간이므로, 이 구간에 람다 엣지로 인터셉트하여 리디렉션을 돌린댜

오리진 리퀘스트 구간에서는 수행해보진 않았는데 한번 테스트 돌려보길 희망할 수 있지만, 괜히 네트워크 레이턴시를 CF에서 뒤로 또 돌리는걸 원치 않아 뷰어 리퀘스트에서 이를 낚아챘댜

추가로, CF에서 람다엣지 인터셉트할 때, event 객체 안에 요청자의 uri path와 쿼리스트링이 들어있는 것을 조합해서 리디렉션해야한댜

이건 지금 참조페이지가 어딨는지 까먹었댜... 검색을 해보도록 하쟈

이슈가 생겼습니다...

서버리스 프레임워크를 계속 사용하여 람다 컨테이너들에 대한 형상 관리를 하다보니,

이력이 계속 쌓였는지 75GB 용량 초과 알림이 떠서 커스텀으로 만들 수 없더군요..

조금 더 파악해보고 오겠습니다..

클라우드 개발자 앙몬드입니다.

인프라 CA분에게서 요청이 왔던 AWS 리전들의 Public IP 변경에 대하여, 알림 및 SG 자동업데이트에 대한 람다 개발을 자동화하는 것이었죠.

해당 건에 대해서는, 굳이 형상관리를 할 필요없다고 판단하였습니다. 이슈가 생긴다면, AWS SES/SNS 알림을 받고, 그것을 그때 고치면 되는 것이었죠. (물론 그 사이 서비스가 장애가 났다 하면 앙몬드 책임)

    - SNS + Lambda Fan-Out 패턴을 통한 AWS Region 간 Public IP 자동화 이슈링크 : devloper-angmond.tistory.com/category/IT/AWS%20%EB%A6%AC%EC%86%8C%EC%8A%A4%20%EA%B0%84%EB%9E%B5%EC%A0%95%EB%A6%AC%20%26%20%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C%EA%B0%9C%EB%B0%9C%20%ED%8A%B8%EB%9F%AC%EB%B8%94%EC%8A%88%ED%8C%85

콘솔에서, 스크립트를 생성하려는데 문제가 생깁니다.

AWS Lambda 의 경우 제한에 대해서는 저 또한, 컨테이너 하나당 용량 50MB & 동시실행 1000개만 숙지하고 있었죠.

75GB 에 대한 이슈의 AWS 화이트페이퍼는 하기와 같이 설명합니다.

docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html

이상한것은, 제 람다 함수 어플리케이션 용량 총합이 1GB도 되지 않는데 어째써 75기가로 인식을 하였을까?

해당 용량 공식은 다음과 같습니다.

AWS Lambda Function & Layer Storage's Total Limit = Lambda Fuctions's ALL Versions + ALL Layers

예를 들면, A람다 함수 50메가짜리의 버전이, 1000개 관리되고 있고, 레이어는 쓰지 않는다면,

람다 용량 = A람다 50MB * 1000 = 50GB

그리고 75GB 를 초과하여 배포 시에는, 다음과 같은 에러를 뱉습니다.

CodeStorageExceededException

앙몬드가 찾은 방법은 다음과 같습니다.

1. AWS 서포트를 받아, 용량을 늘린다. -> 당연히 비용 증가 예상 가능

2. 구 람다 버전들을 형상관리하지 않고, git 으로만 관리하며, 구버전들 전부를 없앤다.

앙몬드는 당연히 2번을 선택하였구요.

어렵지 않게 파이썬 코드를 찾아 해결할 수 있었습니다.

물론 약간의 한계가 있고, 모든 이슈가 해결된 것은 아니지만, 약 99퍼 정도는 위 이슈는 해결 가능하였습니다.

이후, 이에 대한 조금 더 고도화는 되어야겠죠.

오늘은 간단하게, 이에 대한 이슈잉과 어느정도의 해결책 람다 코드만을 만들어서 배포를 하도록 하고 종료하도록 하죠!

(앙몬드는 맥주를 먹으러 갈꺼댜)

인프라를 담당하시는 AWS Cloud Architect 분에게서 들어왔던 요청이 있었습니다.

EC2의 네트워크 Outbound 정책에 대하여, 나가는 대역을 애니오픈 0.0.0.0/0 에서 제한을 두자는 말이었죠.

사실 이에 대해서는 여러가지 고민해볼 필요가 있습니다.

EC2에서 실제 사용하는 서비스들에 대하여 VPC 엔드포인트를 모두 파악 / 구축해 아웃바운드를 둘 것인가.

혹은 AWS 에서 각 국가별로 사용하는 전체 AZ에 대한 Public IP를 찾아내 제어할 것인가.

* VPC 엔드포인트를 이용해 막아볼까?

  (1) 일반적으로, 프로젝트 초기 설계부터 빡세게 이를 알았다면 위 요건에 대한 문제는 쉽게 풀립니다.

  (2) VPC 엔드포인트는 외부망을 타지 않고, 나의 VPC 사설망에서 통신할 수 있게, 엔드포인트를 제공해주는 서비스입니다.

  (3) VPC EP 게이트웨이 (S3 & DynamoDB) / EP 엔드포인트 2가지로 나뉩니다.

  (4) 따라서, 프라이빗 엔드포인트가 생성될 시, 혹은 Public 게이트웨이 엔드포인트가 생성될 시, 이에 대하여 아웃바운드를 제어하면 만사 OK죠.

  (5) AWS 백서 참조 : docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-endpoints.html

이슈는 지금 구축 단계가 아니라, 현재 운영중인 엔터프라이즈 어플리케이션들에 대해서 이를 어떻게 네트워크를 틀어 막을 것인가 입니다.

아무리 처음부터 히스토리를 알고 있다고 하여도, 각 서버에서 무엇으로 통신하는지를 정확히 100% 파악해 틀어막을 수는 없습니다. 그러기엔 너무 위험부담도 크고, 또한 네트워크 블록킹 시 중요한 전문이나 오픈 API, Batch 작업이 돌아가지 않을 경우, 이에 대한 책임을 감당할 순 없을 겁니다.

그래서 생각한 나 (클라우드 개발자 앙몬드) 의 생각.

"어차피 물리적으로 아마존의 데이터센터가 한국에 위치해있다면, 그들이 사용하는 Public IP 또한 대역이 존재할 것 아닌가?"

"이를 통쨰로 파악하여 틀어막아보자."

하지만 한계도 있었죠. AWS의 Public IP들은 고정된 것이 아니라, 도약을 하기 때문에, 파악한 Public IP가 영원할 것이란 보장은 없었습니다.

흠.. 정답이 없을까.. 진짜 VPC 엔드포인트를 모두 위험을 감수하고서 SG 작업을 해야할까?

하지만 운좋게 2019년. AWS에서 멋진 기능을 제공해주기 시작했죠!

바로, AWS IP 대역 변경에 대해서, 이를 알려주는 서비스입니다.

aws.amazon.com/ko/blogs/korea/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/

잠깐 요약을 하면, 특정 SNS 토픽에 대하여 구독 (Subscription) 을 생성하면, 그 메서드로 알림/트리거가 간다는 내용입니다.

보시면, SNS 토픽 ARN이 아예 고정되어 있습니다.

주의 사항도 있어요!

이 SNS는 us-east-1 (North Virginia) 에서 생성을 해야합니다. 저 ARN을 리전과 내 AWS 어카운트 12자리로 바꾸어도, 인식하지 않습니다.

(다시 말하면 뭐다? 저 806199016981 은 AWS의 고유 계정이다.. 라는 건데 나한텐 전혀 쓰잘데기 없는 거..)

SNS 서브스크립션 없이도, 오픈 API를 제공해줍니다. 하기와 같으며, 지금 한번 호출해 result json 파일을 뜯어보았습니다.

ip-ranges.amazonaws.com/ip-ranges.json

하지만, 앙몬드는 저걸 일일이 계속 호출하기 싫으니, SNS 구독을 받아 람다를 호출하는 형태의 Fan-out 람다를 만들어 보기로하였습니다.

(1) SNS 구독을 위 AWS IP 대역 변경에 대하여, 서울리전의 람다를 설정시킨다.

(2) IP대역 변경이 있을 시, 람다가 이를 실행한다. (SNS를 이용한 Fan-Out 패턴 살짝 변형)

(3) 람다는 SNS 이벤트에서, 대역 변경에 대한 정보 중, 서울리전의 Public IP 대역을 EC2 SG 아웃바운드 룰에 설정한다.

오늘은 앙몬드 또한, 이에 대하여 1번과 2번을 해보았지, 아직 3번에 대한 것을 해보진 않았습니다.

사실 그래봤자, 런타임에 따른 람다 SDK를 사용하는 것일 뿐이기에 큰 이슈는 없을 것으로 생각되네요.

(오히려 저 SNS 토픽 찾는게 더 힘들었음...)

만들게 되면, 3번에 대한 코드는 같이 포스팅하는 것으로 약속하죠 :)

* Fan-Out 에 대한 AWS 화이트페이퍼 레퍼런스 : aws.amazon.com/ko/getting-started/hands-on/send-fanout-event-notifications/

* 아마존이 설명하는 팬아웃은 SNS & SQS 조합이지만, 람다 조합도 팬아웃 패턴으로 인식해도 문제가 없다고 개인적인 판단이네요.. 근데 왜 SQS만 넣었는지는 조금 의문이긴 합니다..

[정리]

1. SNS -> SQS 를 이용한 조합을 AWS 팬아웃 아키텍처라고 합니다.

2. AWS AZ, 데이터센터 또한 명백히 사용하는 Public IP 대역이 있습니다.

3. 2번에 해당하는 Public IP는 고정이 아니지만, 바뀔 경우, SNS 혹은 API를 통해 인지할 수 있습니다.

AWS AZ 간 시간때문에 애를 먹었던 일이 있었는데 이번에 또 발생했어요.

클라우드 개발 시의 시간 참조별.. 까먹지 않게..!

1. AWS Lambda 실행 시간

 - 기본적으로는 UTC 0시 (영국) 기준으로 돌아가요.

 - 람다 실행 시, 타임존 (TZ)를 [Asia/Seoul] 즉, UTC 9로 맞추고 하면 Cloudwatch (CW) 에서 실행 로그를 보기 좋아요

당연히! 서울 AZ를 쓰는 입장에서, +9로 맞추어야지! 했는데.. 이게 엘라스틱서치와 키바나에서 꼬일줄은...

2. AWS Elasticsearch 시간

 - 데이터를 들이밀어 넣는 요청 측에서 시간 데이터를 결정합니다. 주는데로 받아먹는 ES.

 - 영국은 0시, 한국은 이 때 9시가 되겠죠.

 - 람다가 한국 시간 9시 데이터로 ES에 들이 밀어넣으니..

3. AWS ES Kibana 플러그인 조회..

 - 분명 현재 한국 시간으로 조회했는데..

 - 데이터가 왜 없을까.. 분명 람다에서 한국시간 9시 기준으로 집어넣었는데, 키바나 조회가 안되요.

 - 하지만 AWS 콘솔 상으로도, CLI 상으로도 ES에는 데이터가 존재한다고 나오는데...

[결론 : 키바나 검색 시, 브라우저의 로컬 타임존을 자동 보정해 데이터를 가져온다..]

즉, 위 상황에서 키바나는 한국시간 +9로 보정되어 집어넣은 데이터에, 키바나가 한번 더 +9를 하니, 영국시간 0시보다 +18시간 (욕 아님) 된 데이터를 찾으려고 하는 것...

첫 설계 시, 시간에 대하여 어떻게 보정할 지 로직/공통 가이드를 제공하는 것이 필수.....

(1) 람다의 실행 시간을 어느 것을 기준으로 할 것인가

(2) 엘라스틱서치에 시계열 데이터 삽입은 어떤 시간을 기준으로 할 것인가

(3) 키바나 조회 시, 브라우저 로컬 타임존 시간 보정 여부도 확인해서, 아키텍처가 잘 짜이게 만들어야한다.

캡처를 좀 해서 올려놔야 하는데.. 음..

(설마 누가 볼까)