'전체 글'에 해당되는 글 93건

#aws lambda python test

1. Lambda 에 올릴 zip 패키지 만들기

패키지를 모두 zip으로 해야하므로

로컬에서 directory를 하나만들고

directory/main.py python 파일을 만든다.

그리고 패키지는 이런식으로 폴더 아래 설치 되도록 한다.

"pip install module-name -t /absolute/path/to/directory"

그다음 lambda_handler function을 만들고 람다가 할일을 코딩한다. 그리고 나서 directory폴더 안에 있는 파일들을 모두 선택한다음 zip으로 만들고 lambda에 업로드한다.

2. main.py연결

Lambda configuration에 보면 Handler가 있는데 이부분을 main.lambda_handler 라고 써주면된다. "파일명.함수명" 이다.

3. Test

만들어진 람다 function을 보면 테스트 시그널을 줘서 실행해볼수 있는데 실행하면 끝날줄 모른다. 알고보면 이미 끝나있을거니 그 실행로그는 cloudWatch에가서 보면된다. 

4. 삽질

- 람다에서 커넥션 안되면 에러를 튕기기보다 설정된 타임아웃시간까지 hang이 걸린다. 따라서 스텝이 안넘어가면 뭔가 네트웤 이슈가 있구나 라고 생각하면된다.

- 일단 람다란 녀석은 만들어진 vpc내의 통신만 되기 때문에 외부 DB나 s3의 서비스 연결은 기본적으로 불가하다 -ㅅ-ㅋ 그래서 s3같은경우는 VPC -> endpoints 를 하나 만들어줘야 접근이 가능하다. 그리고 다른 vpc에 있는 DB같은경우는 Peering을 만들어서 하면되는데 그냥 peering만 만들면 접근이 안되고, 람다가 속한 vpc의 route table에 peering 접근설정을 해줘야한다.
예) destination: 10.0.0.0/28, target: pcx-c37bdsfsa(peering)(http://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html)

람다가 속한 vpc내 resource만 사용할경우 vpc만 설정해주면되고
람다가 그냥 퍼블릭 주소에 접근하는 경우만 있을경우는 vpc를 설정 안해주면된다.

하지만 이 둘을 모두 사용할땐 NAT gateway가 필요하다.. 이건 또 따로 돈나가고.. 이 두가지 모두 해당되면 람다는 좀 아닌것 같다.

*참고

- http://docs.aws.amazon.com/lambda/latest/dg/python-programming-model-handler-types.html

- http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-how-to-create-deployment-package.html

- http://blog.hde.co.jp/entry/2016/05/19/102706

kinesis 에 보면

streams랑 firehose가 있는데 

stream은 그냥 진짜 stream만 받는것이고

firehose는 stream을 받아서 s3나 elastic search(es)로 보내는 역할을 하는녀석이다.

차이 설명: DemystifyingAmazonKinesis_infographic.pdf

목적지가 s3와 es, redshift정도라면 firehose만 쓰면된다.

시작하기전에 한가지 알아두어야할 사실은 "그림에 속았다" 이다.

kinesis를 보면 마치 firehose하나로 s3, redshift, es에 동시에 보낼수 있을것 같이 보인다. 

하지만 설정에 들어가보면 3개중 하나를 고르라고한다.. 잉? 그리고는 백업용으로 s3를 선택할수는 있다. 그럼 redshift랑 es에는 동시에 못하나?

https://stackoverflow.com/questions/44595655/multiple-destinations-for-kinesis

같은 생각을 갖고있는 사람들이 역시 있다. 좀 가시나무들이 있지만 방법은 있단다.. firehose에 람다 트리거를 붙여서 람다가 es에 쓰도록 하는것..

아무튼, file tailing을 이용한 firehose에 로그보내기를 

aws-kinesis-agent를 설치하고 테스트해보았다.

1. config

-> /etc/aws-kinesis/agent.json

이렇게 테스트함.

{

  "cloudwatch.emitMetrics": false,

  "firehose.endpoint": "",

  "log.level": "DEBUG", 

  "flows": [

    {

      "filePattern": "/test/debug2.log",

      "deliveryStream": "test",

      "maxBufferAgeMillis": 1000,

      "minTimeBetweenFilePollsMillis": 1,

      "dataProcessingOptions": [

                {

                    "optionName": "LOGTOJSON",

                    "logFormat": "SYSLOG",

                    "customFieldNames": ["@timestamp", "host", "filename", "lineno", "msg"]

                }

            ]

    }

  ]

}

2. kinesis log

-> /var/log/aws-kinesis-agent/aws-kinesis-agent.log

먼가 안뜨거나 모니터링 할때 용이함.

3. 삽질

- firehose는 deliveryStream으로 써야한다는것

- aws key는 json파일말고 /etc/sysconfig/aws-kinesis-agent 여기에 설정해줘야 한다는것 (IAM role에서 AmazonKinesisFirehoseFullAccess 권한을 준 계정을 만들어 사용한다.)

- 로그가 오해의 소지가 있을수있다는 것. 로그는 파일 append에 상관없이 일정시간동안 찍는데 나오는 값은 agent가 실행된순간부터 지금까지의 토탈이다.

- 저 위에 dataProcessingOptions는 그야말로 옵션인데, 기본 파일에 남는 로그가 json string이 아니면 es에서 먹지 않고 에러만 남는다. (s3엔 상관없이 잘써짐) 그런데 여기서 가능한 logFormat이 4개가 있는데 이중에서 젤 만만한 녀석이 SYSLOG라 이거로 골랐다. 어떻게든 

Mar 16 10:46:49 앞에 이 타임 형식만 잘 찍어주면 뒤에는 없는 부분은 - 로 써서 넘기면 된다.

예) Mar 16 10:46:49 - main.py[123]: message

- 진짜 최강삽질은 es에 기록이 된다음부터인데, 키바나에서 일단 시작하려면 index pattern에서 add New를 해줘야하는데 이때 Time-field name이 뜨질 않는다. Advanced Settings에 가면, dateFormat:scaled라고 해서 타입을 정해줄수있는데 IOS8601 기준밖에 안된다. 그러나 Mar 16 10:46:49 이 타임형식은 rfc3164라는것!! 그래서 여기서 막혔다....

참고:

http://docs.aws.amazon.com/firehose/latest/dev/writing-with-agents.html

https://www.sumologic.com/aws/demystifying-kinesis-streams-firehose-infographic/