검색결과 리스트
플랫폼 개발에 해당되는 글 1건
- 2020.05.19 AWS 태그 네이밍 람다 스크립트 트러블슈팅 일지
글
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 서비스 내부에 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들 화이팅!
그리고 영어를 열심히 공부합시댜.....
'IT > AWS Lambda & Resources Trouble Shooting' 카테고리의 다른 글
AWS System Manager / SSM을 이용한, 머신 컨트롤링 스크립트 (0) | 2020.10.14 |
---|---|
AWS Lambda 에서의 웹크롤링 고찰 (0) | 2020.06.07 |
AWS 람다 SAM 배포 75GB 용량 이슈 (0) | 2020.05.21 |
AWS Fan-out 람다를 이용한 Security Group 제어 (0) | 2020.05.21 |
AWS Elasticsearch & Lambda & Kibana 트러블슈팅 일지 (0) | 2020.04.15 |