[AWS] Lambda + API Gateway 적용

Mineru·2021년 11월 25일
0
post-custom-banner

고~~~오급 컴퓨팅 기술을 적용해보았다.

📖 사전 스토리

대략 6만개의 데이터가 쌓였을 쯤부터였나, 더 이상 데이터 수집을 멈추고 수집한 데이터를 분류를 할 필요성을 느꼈다.

머신 러닝을 조금 공부해본 사람들이라면 알 것이다.

데이터가 많은 것이 당연히 좋지만, 질 좋은 데이터가 많아야지 더미 데이터만 한가득 있으면 머신 러닝 학습에 있어서는 전혀 도움이 되지 않는다.

그래서 사내 서비스로 데이터 분류 작업을 할 수 있도록 하는 웹 서비스를 1주일 만에 만들었고, 이후에 부족한 부분을 채워나가는데 2~3주 정도 더 쓴 것 같다.

🛠 적용 배경

누군가가 데이터를 분류하고 나면 그 데이터가 제대로 분류가 되었는지 검증이 되어야 신뢰 할 수 있는 데이터라고 할 수 있다.

누군가가 이건 이거고 저건 저거야 라고 말해줄 수 있는 상황이라면 정말 좋겠지만 안타깝게도 그러한 기준이 없기 때문에 직접 분류를 하면서 분류 기준을 만들어가야 한다. 그리고 이게 나만 알고 있어서는 안되고 다른 사람들도 이 메뉴얼을 보면 바로 분류를 할 수 있도록 문서화가 되어야 한다.

그래서 몇일간 직접 분류를 하면서 분류 메뉴얼을 만들고 이를 기반으로 검증 코드를 작성했다.
무한 if 문을 썼다가는 나중에 메뉴얼이 계속 업데이트가 되면서 지속적으로 반영이 안되는 형상을 막기 위해서 최대한 구조적으로 코드를 짜려고 노력했지만, 정말 x 같은 코드가 나오긴 했다... 그래도 일단 나는 유지보수가 가능하고 나름 주석 처리도 해서 코드 수정을 할 때 덜 힘들긴 했다. ㅎㅎㅎ

앞에 잡담이 너무 길었네;; 🥲

다른 것보다 일주일에 한번씩 데이터를 검증 하는데 이게 생각보다 돌리고 결과 복사 + 붙여넣고 다시 돌리고 복사해서 SQL로 집계 하는게 다라서 이 귀찮을건 좀 덜 하기 위해서 한번 시스템 개발을 시도하게 되었다.

🪚🪚삽질중🪚🪚

AWS Lambda의 존재는 2017년도 초반 개발 유튜버포프 님의 영상을 통해서 처음 접하면서 알고 있었지만, 이게 실제로는 언제 어떤 경우에 필요한 컴퓨팅인지 감이 잘 안잡힌채로 그냥 지식만 얻고 끝을 낸 상태였다.

그런데 이번 경우가 딱 이런 경우에 적절한 경우라 생각이 들었다.

데이터는 추가가 되거나 수정이 된다.
데이터가 추가가 되는 경우에는 기존에 디비에 아무런 내용이 없기 때문에 먼저 기존에 API 서버로 데이터가 추가가 된 후에 반환 된 값으로 검증 서버에 내용을 보내서 자동 분류를 시도한다.
데이터가 수정되는 경우에는 새롭게 수정 할 내용과 기존 디비에서 해당 내용을 가져온 뒤 새롭게 수정 된 내용과 자동 분류한 내용의 일치율을 계산을 하여 일치율이 너무 떨어지는 분류 작업에 대해서는 경고 메세지를 날리는 형태로 동작한다.

다른 것보다 기존에 만든 코드를 하나의 파일로 옮기는 일은 쉬웠지만, 생각보다 Lambda와 이를 REST 방식으로 호출하기 위한 API GateWay 연동 과정에서 조금 힘들었다.

AWS 서비스가 계속 업데이트가 되는 바람에 지속적으로 새로운 시스템 방식에서 적용한 글을 찾기가 쉽지 않아서 삽질을 좀 했다.

다 좋은데 기본 IAM 계정으로 할 수 있는 작업이 제한적인게 너무 아쉽다.

Lambda에 API GateWay 트리거를 연결하는 경우가 많을거다 보니 제일 상단에 배치를 했을 탠데 기본 정책을 그런 경우에 할 수 있는 범위를 너무 좁힌 것 같다.

AWSLambda_FullAccess 권한을 가진 IAM 계정을 생성해서 트리거 연동을 진행을 하니 계속 안되던 request body 데이터가 암호화 되지 않고 제대로 전달이 되었다.

profile
Daily Coding
post-custom-banner

0개의 댓글