클라우드 개발자 앙몬드

50메가바이트로 한참동안 고생했던 웹크롤러입니다...

금일 안에 작성예정...

아 Aㅏ Ah.. 회사내에서 보직이동에 뭐에..

요즘 쿠버네티스 꿀잼에 빠졌습니다.

AWS ECS (DockerSwarm) vs K8S 비교하며, 뭔가 요새 조금 더 레벨업 하는 분위기가 나네요.

하는게 아니라, 이거 깜빡하고 있었습니다.. (근 2달가까이 작성도 안하고 내비둔 내 작은 일기 ㄷㄷㄷ...)

람다는 서버리스, 즉 Server Configurationless 정도로, 호스팅 환경 설정을 최소화시킨 상태로, 내가 원하는 어플리케이션 코드를 실행시켜줍니다. 그래서 Function as a Service, FaaS 라는 카테고리로 취급됩니다.

이런 함수형 서비스들은 특히, 용량에 따른 제약사항을 많이 받습니다.

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

특히 배포패키지 크기, 하나의 어플리케이션을 압축했을 때, 그 패키지 용량 제한이 50MB라는 점이, 이번 주제, 람다 웹 크롤러이자 Lambdium (Lambda + Chrome + Selenium)이 됩니다.

답은 간단합니다. 원하는 언어의 람디움을 가져다가 사용하면 됩니다. (응?)

아니.. 사실 이걸 람다 레이어로 다 해보려고 했는데, 의존성 순서 다 깨지고.. 동작 안하더라구요... 라는 뒷담화가 있어서.... 트러블슈팅도 귀찮기도 했고...

그래서, 용량 제한 람다에 대해, 셀레늄부터 시작해, 웹브라우저 드라이버, 그리고 람다까지 오게되며 탄생된 람디움에 대해서 알아보는 시간을 가져보도록 하죠.

(1) 셀레늄 (Selenium)

셀레늄을 검색하면, 대개 한가지의 공통 단어가 나옵니다. 바로 웹 크롤러죠. 셀레늄은, 웹 브라우저 테스팅 도구 등 여러 무림의 고수들이 설명을 잘 해주시고 계시나, 클라우드 개발자인 제 입장에서의 셀레늄은, 인터넷 익스플로러, 크롬, 파폭, 오페라와 같이, 어플리케이션 런타임 중 웹 브라우저를 실행시키기 위한 도구입니다. 한장의 그림으로 설명되니, 먼저 크롬으로 들어가보죠.

(2) 크롬

수많은 웹 브라우저 중, 하나입니다. 구글이 만들고, 자바스크립트 엔진은 V8 입니다. 노드js의 심장부이죠. 라이브러리를 다운받을 때, Chromium이라는 녀석이 나오게 되는데, 크롬 + 셀레늄의 합성어입니다. 2개의 기능을 하나로 합쳐놓은 것이죠. 셀레늄은 웹 브라우저를 실행시킬 때, 크롬을 쓸지, 익스를 쓸지, 파폭을 쓸지 등을 결정해야 하며, 이 때 원하는 브라우저 바이너리 파일도 있어야 합니다. 따라서, 어플리케이션 > 셀레늄 > 브라우저는 다음 그림과 같은 의존성을 가집니다.

이런 웹 브라우저는 다음과 같은 의존성을 가지게 되겠죠.

(1) 파이썬, js 등 스크립트 언어는 웹 브라우저와 동작하기 위해, 셀레늄에 액션 코드를 주입합니다.

(2) 셀레늄은 명령이 내려진, 어플리케이션의 코드를 수행하고자, 브라우저를 탑재합니다.

(3) 셀레늄은 탑재한 브라우저를 오픈시켜, 어플리케이션의 명령 코드를 수행합니다.

따라서, 어플리케이션이 브라우저와 대화할 수 있는 중간 레이어 셀레늄을, 웹 드라이버라고 칭하는 것입니다.

마치 컴퓨터와 프린터가 직접 대화를 못하니, 프린터 드라이버를 설치해 대화하는 것 처럼, 어플리케이션이 이기종인 브라우저와 직접 대화를 못해 중간 매개체인, 웹 드라이버가 있는 것처럼 말이죠.

근데 우리 그거 아세요? 우리의 테마는 람다라는 것.. (아 aㅏ ah)

람다 호스팅 환경은 이 셀레늄 웹 크롤러 자동화를 수행하는데 지옥입니다.

용량의 문제입니다. 람다 함수 패키지의 최대 크기는 50메가임을 위에서도 말했는데, 제가 그냥 람디움을 받으라는 이유가 여기서 증명됩니다..

headless-chromium. 즉, 셀레늄을 구동시키기 위한 크롬브라우저, gui나 기타 부가기능들을 다 제외한 저 크롬브라우저의 바이너리파일만 하더라도 100메가 가까이 육박합니다. 그러나 세상에는 용자가 많다보니, 이것에 대해 필요 라이브러리만 정확히 디펜던시를 모아 상기처럼 만든 것이, 바로 Lambda + Chromium = Lambdium 이 된 것입니다. (네. 혼종입니다.)

해당 패키지를 정확히 zip 아카이빙하면, 약 49.5 메가정도로, 아슬아슬하게 턱걸이로 걸치고, 약 수백키로바이트 정도의 웹 크롤링 자동화 코드를 작성할 여유가 생깁니다.

그래서 람디움 안의 모든 라이브러리 디펜던시가 교묘하게 엮여있고, 그걸 굳이 또 뜯어보기 귀찮았기에.. 람디움을 그냥 쓰라는 결론에 이른 것이죠.

아마도 클라우드 개발자 앙몬드가 람다 용량 문제로 겪은 첫번쨰 이슈이지 않았을까 합니다.

그러고보니 조금 늦은감이 있지만, 쿠버네티스 재미에 빠져있습니다. 쿠버네티스와 파이썬, 그리고 람다까지 잘 글을 다독이며, 훗날 이 작은 기억들을 잊지 않게 일기를 조금 자주 써야겠습니다 :)

이슈가 생겼습니다...

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

이력이 계속 쌓였는지 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 리소스들에 대한 API 명세서를 다시 한번 읽어보아야겠다는 의심을 가지는 하루..

먼저 플랫폼에 대한 아키텍처를 하기와 같이 간단하게 그려보았습니다.

1. 상황설명

  - AWS의 ECS 컨테이너 오케스트레이션 적용. EC2 컨테이너 인스턴스들, 오토스케일링 그룹

  - Launch Configuration 을 통하여, EC2 인스턴스 오토 스케일아웃 시, EBS 또한 자동 증설 및 마운트

  - EC2의 네임태그는 현재 관리가 되나, EBS 네임태그 관리되지 않아 파이썬을 통한 네임태그 자동화 스크립트 개발!

  - 해당 VPC 내부에 위치하는 람다를 이용하여, EC2의 정보를 읽어와 EBS의 네임태그 자동생성하는 것이 목적!

어찌보면 조금 간단합니다. 뭐 로컬에서 CLI나, 해당 VPC 내부에 임시 인스턴스, 혹은 저처럼 람다를 이용하여 개발하는 방법 등등 여러개가 있죠. 하지만 개발자 앙몬드는 람다의 재미에 빠져있기에 람다를 쓴댜 실시

람다를 사용하기로 한 앙몬드는, 파이썬3 런타임의 람다, 그리고 AWS에서 제공하는 파이썬용 AWS SDK boto3를 이용해, 상기 과제를 수행하기로 합니다. 작업 설계/계획은 다음과 같았죠.

2. 앙몬드가 생각한 작업 순서

 a. 람다에서, 해당 VPC 내부에 위치한 EC2 인스턴스들에 대한 정보를 가져온댜

 b. 인스턴스들에 마운트 (탑재) 된 EBS 정보를 리스트로 추출한댜

 c. EBS의 네임태그에 조합할, EC2 네임 태그도 같이 추출한댜

 d. EBS 태그 생성을 위해, 볼륨 ID를 추출한댜

 e. b/c/d 의 조합을 가진 리스트로, EBS 정보를 호출해 네임태그를 생성한댜

 *. EBS 네임태그 규칙 : volume--(탑재된_인스턴스_네임)--(마운트경로) / ex. volume--angmond_instance_1--/dev/xvda

어찌보면, 참 단순합니다. 단지, 저것에 해당하는 API가 무엇인지, 열심히 영문 API 명세서를 읽는 일이 문제였죠..

(누가 boto3 한글 번역좀 내주소!!!!)

3. boto3 API를 모아보쟈

EC2 인스턴스를 호출하기 위한 API입니다.

리턴 포맷까지 봐야하는데.. 너어어어무 기니까 우선 레퍼런스로 남길게요... (사실 출처도 필요했어!)

  출처 : boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_instances

하지만, 추출 시 필요한 녀석들은 캡처를 했죠 (흐뭇)

자.. 아무튼 요렇게 3가지를 이용했고, 이제 EC2 서비스 내부에 EBS 통신 커넥터를 생성해보죠!

하기와 같습니다.

ec2.Volume의 id는 EC2 인스턴스 id가 아니라, EBS 볼륨 ID입니다. 주의하세요!

그래서 describe_instances 시, EBS 매핑정보에서 VolumeID를 추출한거죵!

이제 다 왔습니다. EBS 볼륨에 태그 생성 함수를 호출해 끝내죠!

AWS 콘솔에서 이제 자동 완성된 EBS 네임태그를 한번 구경후 끝내려는데.. 이슈가 나옵니다.

대다수 EBS에 네임태그가 생성되었는데, 생성이 안된 녀석들이 있네..? (나닛!)

4. 트러블슈팅 시작

이제부터 또 트러블슈팅 들어가야죠.. 뭐가 문제였는지..

사실 가장 먼저 떠오른건..

    ****** EC2 인스턴스 정보를 못가져왔나?

그리고 그 불길한 예감은 맞았습니다.

콘솔 확인결과, 100개의 인스턴스가 제 눈에 보였는데,

boto3.client("ec2").describe_instances() 에는 100개보다 적은 90개만 보였기 때문이죠.

음? 왜? 뭐지? AWS가 고장났다

한참을 고민한 끝에.. 오랜만에 영문 독해를 다시 시작하고서야 깨닫는군요..

다시 아키텍처를 보죠.

우리가 처음에 고정 인스턴스를 사용자 혹은 어카운트 오너가 직접 생성합니다.

그러나, ECS에 묶인 ASG EC2 클러스터들은 유저가 생성하는 것이 아니라, ASG 즉 AWS 자체에 의해서 & 내가 정한 규칙에 의해 생성됩니다.

즉, 규칙은 내가 정했으나, EC2 실제 생성은 AWS에 위임한 것이죠.

그리고 EC2 describe_instances API 명세서에 그 단서가 나옵니다. 다시 찬찬히 읽어보죠.

형광펜 칠한 부분이 보이시나요?

"내가 소유하지 않은 인스턴스를 명세할 시, describe_instances 함수의 결과값으로 반환되지 않습니다."

즉, 저 100개 중, 10개는 ECS 오토스케일 아웃 정책으로 확장되었기에, 내가 직접 만든 인스턴스가 아니라고 판단하는 것으로 추정되는 것.

따라서, 100개의 정보가 아니라, 90개만, 내가 직접 생성한 것만 넘어온 것이며, 시스템에 의해 오토스케일 아웃된 EC2 인스턴스들은 이 API의 결과로 얻을 수 없었습니다.

프로덕션 단계의 서비스에 대하여 만든 스크립트이기에, 강제 스케일 인 하여 결과를 확인해보진 않았지만, 이에 대한 정확한 답은 AWS에 이슈잉을 하여 정확한 답변을 들어봐야겠습니다.

물론 지금 위에 있는 것은, 어디까지나 앞뒤 상황을 맞추어서 제가 추론해본 것이기에 정확하지 않습니다.

아니 어쩌면 앙몬드가 틀렸을 수도 있죠..

5. 앙몬드와 회고

단지 이게 보토스 (boto3) 의 오류만인지는, 내일 AWS CLI를 직접 날려보아 보토스와 결과가 같은지를 확인해보아야 겠습니다.

만약 둘 모두 결과가 동일하다면, CLI를 사용하여 클라우드에 액션을 취하는 행위도 굉장히 조심스럽게 될 수 밖에 없을 것 같습니다.

전국의 Cloud Architect들 화이팅!

그리고 영어를 열심히 공부합시댜.....

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

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

(설마 누가 볼까)