AWS 태그 네이밍 람다 스크립트 트러블슈팅 일지

반응형

오늘은 참 신기한 일이 있었댜...

어쩌면 지금까지 맹신하고 있었던 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입니다.

보토3으로 ec2 클라이언트 생성 (보토스..?)
EC2 인스턴스들의 정보 호출 시, 파라미터들. 아무것도 없으면, 전체 다 가져온댜

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

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

 

EC2 — Boto 3 Docs 1.13.12 documentation

ExportTaskId (string) -- [REQUIRED] The ID of the export task. This is the ID returned by CreateInstanceExportTask .

boto3.amazonaws.com

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

describe_instances 함수 리턴 중, Instances[0]["InstanceId"] 가 보인댜
마찬가지로, 쭉 내려오다보면, EBS 매핑 정보도 보인댜.. 리스트인 것을 보면 유추가능하듯, 하나의 인스턴스에 여러개의 볼륨을 매핑해도 다 가져온댜. EC2의 EBS API를 쓰기 위해서는, VolumeId가 필요하댜!
또오 마찬가지로, EC2 인스턴스의 네임 태그도 가져온댜

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

하기와 같습니다.

유의하실 점으로ㅡ boto3.resource 를 이용한 커넥터와 boto3.cliner 를 이용한 커넥터 생성의 차이입니다. 둘의 차이는 후에 포스트로 남기도록 하죠!

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들 화이팅!

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

 

반응형

설정

트랙백

댓글