본문 바로가기
DEV/AWS

Pyhton(v3.6)으로 AWS를 활용한 분산 처리 #1

by 김 민 준 2019. 5. 11.

Pyhton(v3.6)으로 AWS를 활용한 분산 처리 #1 (현재글)

Pyhton(v3.6)으로 AWS를 활용한 분산 처리 #2

 

null

 

프로젝트 내용 

 


1. SAP 의 데이터를 취합하여 SAOP로 AWS Lambda 에 I/F 를 진행 
2. AWS Lambda 에서 취합한 데이터를 나누어 Amazon SNS(Simple Notification Service) 를 이용함. 

3. Amazon SNS에서 또 다른 AWS Lambda 로 분산하여 데이터를 던지고, AWS Lambda 에서는 관세청 (UNIPASS API)를 SAOP 로 호출하여 XML 기반 데이터를 리턴 받음.

4. 리턴 받은 데이터는 SAP 로 I/F 진행함.

5. 동일하게 Web 에서도 조금 더 빨리 확인할수 있기를 원하는 데이터가 존재할수 있기에 기능을 넣음.

6. 기능은 위에서 사용한 로직을 재활용하여 API Gateway 로 값을 던질수 있도록함.

5. 진행중에 발생한 오류역시 Amazon SNS 를 이용하여 오류처리용 AWS Lambda 로 던짐.

6. 오류처리용 AWS Lambda 에서는 사내 RDBMS에 로그를 남김. (에이전트를 통해 운영담당자에게 메일 발송)

 

 


파이썬을 접하게 된 계기

 

2018년에 알고리즘 문제풀기 스터디그룹을 참여하고 있었는데,  
'Python 으로 한번 해볼까?' 라는 생각을 갖게되었다.

 

'책장에 파이썬책이 한 권 있긴한데..' 하며 책을 찾았고, 슬슬 보기 시작했다.

 

이 책은 2017년 12월중 한빛미디어의 송경석님 FB의 '파이썬 코리아' 그룹에서 
출간 이벤트를 진행하였고 당첨되어 '헤드 퍼스트 파이썬 (Python3)개정판'을 받았다.
(하지만 제대로 본적은 없었음...죄송)

 

null

 

 

null




그래서 2018년 12월에 처음 책을 펴보았다.
12월 중순경부터 해커랭크의 문제들을 python 으로 풀이하기 시작했다.

 


파이썬의 기본 학습에 도움 받은 사이트


점프 투 파이썬 https://wikidocs.net
파이썬 자습서 https://docs.python.org/ko/3/tutorial/index.html 

 

 



 

 

프롤로그 

 

업무중에 도와달라는 요청이 왔다.

종량제서버(윈도우서버)에 배치에서 오류가 발생한것 같은데 업체에서 대응이 느리니 좀 봐줄수 있냐고..

일단 끄덕끄덕하고 서버를 접속해보니 대충봤을때 java로 만든 수 많은 agent 가 실행되고 있었다.

신세계였다. 이게 관리가 될까? 심지어 서비스로 올리거나한것도 아닌 정말 창 하나하나 떠있다는...

도대체 이녀석들이 무엇을 위해 존재하는 애들인지 궁금해서 확인해보니.. 

관세청에 데이터를 SAP에 I/F 해주는 프로그램이라고 하더라..

관리자용 프로그램도 없고 그냥 agent 를 수십개를 띄워놓고 돌리고 있다니..

충격에 관세청 사이트를 접속해보았다. API를 제공하더라.. 그때부터 짐작이 가기 시작했다.

그래서 이거 얼마주고 쓰고 있는거냐 하니 XXXX만원이라고 하더라..

와... 세상에는 많은 사기꾼이 있다. 

그때부터였다. 내가 이걸 손대기 시작한것은...

 

 

 

 

1. 시작

 

 간단했다. 그냥 공공기관의 API를 호출해서 리턴받아 넣기만 하면 끝.

문서를 살펴보고 키값을 할당받아서 혼자서 값을 던져보고 리턴데이터를 확인해보니 예상대로 별거 없었다.

갑님에게 살포시 메일을 던졌다. '아마도 그 업체의 방식은 이러할것입니다.' 하고...

그러더니 각도기로 각을 재기 시작하더니 몇 가지 물어보더라.

결국 현업에게 전달되고, 계산기를 두드리기 시작하더라.. 그쯤에 느꼈다. 조만간 오겠구나 하고..

 예상대로 요청이 왔다. 처음에는 종량제 서버에 그냥 배치파일을 만들어서 돌리자고 하더라.

그런데 클라우드 팀에서 Serverless를 영업하기 시작했다.

그거에 또 혹하고 넘어가고선 배의 방향이 틀어지기 시작했다.

 

아래 구조도 처럼 처음에는 아주 심플하게  설계를 했다. 

 

SAP에서 데이터를 받아 관세청API 호출 목록을 만들고, 그 목록을 호출 한다.

null

더 이상의 설명이 필요할까? 간단한거다. 

 

도구는 정해졌고, 이제 언어를 골라보자~~

우선시하는 언어는 역시 C#이였다. 하지만 Python을 맛보기 시작한 입장에서는 다른 욕구가 생기기 시작하더라...

 

'Python 이 크롤링에 많이 쓰이던데... '

 

'어차피 스크래핑이나 크롤링이나...' 하면서 Python 으로 찔끔찔끔 예제를 만들어보기 시작했다.

물론 .NET Core 2.1로 진행하는것에 대해서는 다른 개발자에게 맡기고서...

혼자 조용히 몰래 몰래 Python 으로 코딩을 틈틈히 하였는데, 나는 다 했는데 .NET Core 2.1로 진행하고 있는 개발자가 느리다. 이때다 싶어 내가 Python 으로 이미 다 만들어서 테스트도 해봤는데 잘 돌더라 Python 으로 가는것이 어떠냐 하고선 제의를 해보았다. 

 

처음에는 유지보수하는 개발자들도 C#이 주언어이기에 심한 반대를 하였으나, 결국 이미 Python으로 코딩이 종료되었음을 인정하고 힘이 빠졌나보다. Python으로 가는것에 수긍하기 시작했다.

 

 

AWS Lambda란 무엇입니까?

AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스입니다. AWS Lambda는 필요 시에만 코드를 실행하며, 하루에 몇 개의 요청에서 초당 수천 개의 요청까지 자동으로 확장이 가능합니다. 사용한 컴퓨팅 시간에 대해서만 요금을 지불하면 되고 코드가 실행되지 않을 때는 요금이 부과되지 않습니다. AWS Lambda에서는 사실상 모든 유형의 애플리케이션이나 백엔드 서비스에 대한 코드를 별도의 관리 없이 실행할 수 있습니다. 

 

[출처] https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/welcome.html

 

2. AWS 에 올려보자

 

 여러개의 람다를 한번에 올려보니 '공통된 라이브러리로 동작을 하는데 뭉탱이로 이렇게 무식하게 하나씩 올려야하나?' 라는 생각을 갖게 되었다. 

클라우드팀에서 공통소스는 '레이어를 사용하세요' 라고 안내를 해주었다. 

 

null

Layers 이라고 존재하는것을 확인 했다. 요놈의 특징은 버전별로 엎어치기 개념이다. (하지만 과거 버전도 Lambda 에서는 사용이 가능하다.)

우선 pip list 로 사용한 라이브러리들을 확인하고 경로에 들어가 복사하여 하나의 폴더에 몰아 넣었다. 

 

그런데 레이어를 올리는 폴더구조에도 규칙이 있더라.

(https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/configuration-layers.html)

 

 

null

Python 의 경우는 위의 사진처럼  [폴더명/python/라이브러리] 의 구조로 만들어야 한다.

폴더명은 아무거나해도 상관없다. 대표적인 라이브러리명이나 해당 레이어의 특성에 맞추어 네이밍을 하면 될 것같다.

 

 

AWS Lambda 계층

Lambda 함수는 추가 코드와 콘텐츠를 계층의 형태로 가져오도록 구성할 수 있습니다. 하나의 계층은 라이브러리, 사용자 지정 런타임 또는 그 외 종속성을 포함하는 ZIP 아카이브입니다. 배포 패키지에 라이브러리를 포함시킬 필요 없이 계층을 통해 함수에서 라이브러리를 사용할 수 있습니다.

 

[출처] https://docs.aws.amazon.com/ko_kr/lambda/latest/dg/configuration-layers.html

 

3. 환경의 문제 

 

 처음부터 문제가 발생했다. 나의 작업환경은 윈도우 AWS Lambda 는 리눅스....

lxml 라이브러리를 사용하였을때 AWS Lambda 에서 동작이 불가능했다. 
파이썬 코리아 그룹에 질문글을 작성하고, Zeep 의 github에서 동일한 이슈가 존재하는지 확인해봤다.

(참고로 SAOP 통신은 Zeep 라는 라이브러리를 사용했고, 라이브러리 내부에 lxml이 존재한다.)


확인해보니 동일한 증상을 겪는사람이 있었음!!!

 

null


https://github.com/JFox/aws-lambda-lxml 에 AWS Lambda 환경과 동일한 환경에서 
Build 를 진행한 사람이 올려둔 소스를 발견 하였다.


lxml 라이브러리에는 헤더파일이 존재하였고 Build 를 해야 처리가 가능하단점을 알게 되었다.

null


동시에 파이썬 코리아 그룹에서도 알려주시는 고마운분이 있었다.

 

null

 

그리고 아는 사람들중 가장 기만하신분이 따로 또 알려주시기도 했다. ㅋ

 

null

 

덕분에 github 에 조용히 접속 하여 클론하였고, 실행해보니 성공.

 

 

4. 첫 번째 벽을 느끼다. 

 

 어찌어찌 돌아가는 모습을 볼 수 있었다. 그런데 생각보다 많은 양을 처리해야 하기 때문에 러닝타임이 길더라...

(역시나 예상대로 뻗어버리기 시작한다. )

 

 원래는 심플하게 AWS Lambda 한 개의 함수로 모두 처리를 하고자 하였으나, 데이터의 양에 따라 처리하는 시간이 오래 걸리더라. 그래서 병렬처리를 진행해야봐야겠다 싶었는데 먼저 Python으로 해결을 해보고자 하는 마음에 병렬처리를 멀티스레드나 멀티프로세싱으로 해보자 했다. 

로컬에서는 성공적이였으나 처리 시간이 20분이 넘는 상태였다. (물론 직렬로 진행하면 로컬에서도 뻗어버림)

그래서 AWS Lambda의 메모리를 올리면서 계속 테스트를 진행을 해봤는데... 하다 하다가 너무 많은 메모리에 느린 처리 시간에 이거는 cron 기준 타임보다 오래 걸린다. 이렇게 진행할 바에는 그냥 서버 하나에 agent 만들어서 24시간 돌리는 게 나을 거 같다라는 생각까지 하게 되었다...

 

- AWS Lambda의 사양에 맞추어 봤을 때 상당히 비효율적이었음. (돌다가 뻗어버림)

 

AWS Lambda를 SAP에서 I/F 해서 데이터를 가공하는 놈

가공한데이터를 받아서 관세청에 던지고 리턴받은 데이터를 가공하여 SAP로 I/F 처리하는 놈 

 

총 2개로 나누어봤다. 

 

null

 

하지만 여전히... 뻗음..

 

 

 

AWS Lambda 는 러닝타임과 메모리사용량에 비례하여 청구되는데, 해당 프로젝트는 실시간에 가까운 데이터 폴링 작업이라 비용에 대한 이슈보다는 안전한 데이터 폴링이 주된 목표였다. 원래 세 개의 기능정도가 있는데 워크 로드를 알기 어려워서 각각의 영향도를 낮추기 위해서 세 개로 분리했다. 어느정도 도움은 된듯하나 역시 원활하지 않았다.

 

 

 

null

 

결국엔 AWS 서비스를 활용해서 처리하는 방법을 고안하는데 SQS, SNS 두 가지에서 많은 고민을 했었다.

Amazon SNS 를 사용하니 원하던 분산처리가 자연스럽게 처리가 되었다.

 

 

Amazon Simple Notification Service란 무엇입니까?

Amazon Simple Notification Service(Amazon SNS)는 구독 중인 endpoint 또는 클라이언트에 메시지 전달 또는 전송을 조정 및 관리하는 웹 서비스입니다. 

 

[출처] https://docs.aws.amazon.com/ko_kr/sns/latest/dg/welcome.html

 

 

Pyhton(v3.6)으로 AWS를 활용한 분산 처리 #1 (현재글)

Pyhton(v3.6)으로 AWS를 활용한 분산 처리 #2 (다음글)