클라우드 개발자 앙몬드

#AWS 시스템매니저 & SSM 을 이용한 프로세스 체크용 유틸



데이터 = 'root 12345 1 0 Sep28 ? 01:34:51 java -Xms1024m -Xmx4096m -Djava....jar'

b = " ".join(데이터.split()).split(" ")

for idx, value in enumerate(b) :

    print(f"{idx} / {value}")

from datetime import datetime

현재시간 = datetime.today()

기준시간1 = datetime(현재시간.year, 현재시간.month, 현재시간.day, 8,0,0)

기준시간2 = datetime(현재시간.year, 현재시간.month, 현재시간.day, 15,0,0)



if 기준시간1 <= 현재시간 and 현재시간 <= 기준시간2 :

    print("문자 발송 가능시간")

else :

    print("가능시간 아님")

print(현재시간)



-----------------------

[유닉스 에포치 타임으로도 가능]

시작원본 = datetime(2020,9,24,0,0,0).timestamp()

종료원본 = datetime(2020,9,24,23,59,59).timestamp()

기준1 = datetime(2020,9,24,9,0,0).timestamp()

기준2 = datetime(2020,9,24,13,0,0).timestamp()

기준3 = datetime(2020,9,24,18,0,0).timestamp()

 

예시_에포치타임 = 1600915320 #2020년 9월 24일 목요일 오전 12:00:00 #1600873200

# 1600873200 (0시)

# 1600873800 (0시 10분)

# 1600915320 (11시 42분)

print(datetime.fromtimestamp(예시_에포치타임))

 

if 기준1 <= 예시_에포치타임 and 예시_에포치타임 <= 기준2 :

    print("범위 안에 들어왔다")

elif 기준2 <= 예시_에포치타임 and 예시_에포치타임 <= 기준3 :

    print("2번 범위안에 들어왔다")

else :

    print("범위 바깥")

클라우드 개발자 앙몬드의 람다를 정리하다보니, 구 버전 파이썬 람다를 살펴

볼일이 요즘 많습니다.

쿠버네티스에 대한 파이썬 스크립트를 사용하다보니, 과거 보토스 (boto3) 에 대한 AWS API들을 살펴보고 있죠.

오늘은 그와 더불어, 제가 EC2 에 탑재된 EBS 볼륨의 태그 네이밍을 자동화하는 람다를 리뷰할 겸, 본 글을 올립니다.

해당 이슈는, 본 블로그의 하기 테마로 분류되어 있습니다.

devloper-angmond.tistory.com/10?category=867517

import boto3
import os
import sys
import uuid, json
from urllib.parse import unquote_plus

"""
EC2 인스턴스 네이밍을 이용한, EBS 네임태그 자동화 람다

@auth : 클라우드 개발자 앙몬드
@since : 2020-05-20

 * 확인 이슈
    (1) EC2 고정 인스턴스의 경우, 내 소유의 인스턴스로 판단하여, ec2.describe_instances() 결과로 포함되나,
        ECS (도커스웜) / EKS (쿠버네티스) 로 스케일링아웃 (ASG그룹) 된 인스턴스들은,
        결과가 포함되지 않는 이슈가 있어, 100% EBS 네임태그 자동화가 불가함.
    (2) 상기 이슈에 대해서는 AWS 확인 필요
    (3) 참조 레퍼런스
        - https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_instances

 * ec2.describe_instances API 명세서 요약

    Describes the specified instances or all of AWS account's instances.
    
    If you specify one or more instance IDs, Amazon EC2 returns information for those instances. 
    If you do not specify instance IDs, Amazon EC2 returns information for all relevant instances. 
    If you specify an instance ID that is not valid, an error is returned. 
    If you specify an instance that you do not own, it is not included in the returned results.
    ...(이후 생략)

"""

# 	ebs-name-tagging-lambda
def lambda_handler(event, context):
    
    # (0) ec2 클라이언트 오픈 & 현재 어카운트의 인스턴스 정보 get
    list_ec2_instances = boto3.client('ec2').describe_instances(MaxResults=999)["Reservations"]
    
    print("원본 개수 : " + str(len(list_ec2_instances)))
    # 콘솔 상의 EC2 인스턴스 개수와, CLI / boto3-sdk 인스턴스 개수와 다르다면,
    # 해당 어카운트의 인스턴스가 스케일 아웃된 사례가 존재하는 것으로 판단함.
    
    # (1) ec2 클라이언트 오픈 & 현재 어카운트의 인스턴스 정보 get
    list_dict_of_instances_for_ebs_naming = []
    for instance in list_ec2_instances :
        instance = instance["Instances"][0]
        list_dict_of_instances_for_ebs_naming.append( 
            {
                "InstanceId" :  instance["InstanceId"],             # 인스턴스의 ID
                "Tags" :        instance["Tags"],                   # 해당 인스턴스의 태그 전체 (Name 포함)
                "EBS" :         instance["BlockDeviceMappings"],    # 해당 인스턴스에 붙은 EBS 정보
            }
        )
    
    # (2) EC2 인스턴스에서 가져온 볼륨 정보를 통해, EBS 네임태그 생성.
    #       볼륨에 접근하기 위해서는, client가 아니라 resource 레벨에서 접근해야합니다.
    ec2 = boto3.resource('ec2')
    for instance in list_dict_of_instances_for_ebs_naming :
        
        # (a) 인스턴스의 네임 태그값을 추출한다.
        instance_name = ""
        for dict_tag in instance["Tags"] :
            if dict_tag["Key"] == "Name" :
                instance_name = dict_tag["Value"]
                break
        
        # (b) 2개 이상의 볼륨이, 한 인스턴스에 마운트된 경우도 있으므로,
        #       instance["EBS"] 에 대하여 루프를 태운다.
        #       루프 안에서는 하기와 같은 작업을 실행한다.
        #       (b-1) a에서 추출한 인스턴스 이름을 이용하여, EBS 네임태그를 룰에 맞게 생성한다.
        #       (b-2) EBS 볼륨 id를 추출해, EBS 네임태그를 생성한다.
        #       (EBS 네임태그 예시) vol-ec2-prd-seoul-bo-01/dev/xvda
        
        for ebs_info in instance["EBS"]:
            #(b-1) 
            ebs_tag_name = "vol-" + instance_name + ebs_info["DeviceName"]
            
            #(b-2)
            tag = ec2.Volume(ebs_info["Ebs"]["VolumeId"]).create_tags(
                Tags=[ { 'Key': 'Name', 'Value': ebs_tag_name } ]
            )

이전에 람다를 만들 때 실력이 쬐끔 녹스는 느낌이 들기에, 복습겸 공유겸 ELB 태그 네임 자동화 스크립트를 한번 쭉 훑어보고 있습니다.

퓨어한 파이썬3의 문법 내용은 아니므로, 스크립트 스캔 시 유의!

본 글은, ECS 클러스터 인스턴스 태그 네이밍 자동화 시, 같이 개발된 파이썬 런타임 람다 스크립트입니다.

devloper-angmond.tistory.com/10?category=867517

import boto3
import os
import sys
import uuid, json
from urllib.parse import unquote_plus

"""
ELB 유니크 네임을 이용한, ELB 네임태그 자동화 람다

@auth : 클라우드 개발자 앙몬드
@since : 2020-08-10
"""

# elb-name-tagging-lambda
# (CLB + ALB + NLB)
def lambda_handler(event, context):
    # (0) ELB 버전_1 (Classic Load Balancer) 커넥터 생성
    clb = boto3.client('elb')
    list_clb = clb.describe_load_balancers()["LoadBalancerDescriptions"]

    # (1) ELB 버전_1 에 대하여, Name 태그 추가하기
    for lb in list_clb :
        clb.add_tags(
            LoadBalancerNames = [ lb["LoadBalancerName"] ],
            Tags = [
                {
                    "Key" : "Name",
                    "Value" : "clb-" + lb["LoadBalancerName"],
                }]
        )
    
    # (2) ELB 버전_2 (ALB & NLB) 커넥터 생성
    elbv2 = boto3.client('elbv2')
    list_elbv2 = elbv2.describe_load_balancers()["LoadBalancers"]

    # (3) ELB 버전_2에 대하여, Name 태그 추가하기
    #       ELB_v2 는, 네트워크로드밸런서 & 어플리케이션로드밸런서, 타입이 2개이므로, 이에 따라 네이밍 분기조건이 필요
    for lbv2 in list_elbv2:
        lbv2_tag_name = ""
        if lbv2["Type"] == "application" : 
            lbv2_tag_name = "alb-" + lbv2["LoadBalancerName"]
        else :
            lbv2_tag_name = "nlb-" + lbv2["LoadBalancerName"]
        
        elbv2.add_tags(
                ResourceArns=[ lbv2["LoadBalancerArn"] ],
                Tags=[
                    {
                        'Key': 'Name',
                        'Value': lbv2_tag_name
                    }]
        )

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퍼 정도는 위 이슈는 해결 가능하였습니다.

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

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

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