AWS 서버리스 헤딩기 1편 : API GW + Lambda

지난 6개월간 마이크로서비스 ,  스프링클라우드 , 도커, 쿠버네티스 ... 등 헤딩을 하다가 어느정도 실체를 알아가려는 즈음 

과거 그냥 무심코 지나쳤던 서버리스가 마음속에 조금씩 자리 잡기 시작했다. 

서버리스 또한 한계 or 불편한 상황에 부딪치겠지만 그래도 찔러나보자.

일단 회고를 잠깐 해보자면 

마이크로서비스
: 꼭 마이크로서비스라는 단어가 아니여도 사실은 기존에 조금씩 하고 있었던 아키텍쳐였지만, 이론적으로 정립하고 적용하려다 보니, 역시 현실은 쉽지 않았다.  쉽게 생각하면  시스템 패키지 단위로 서비스를 쪼개고 각각의 인터페이스를 정의해서 연동하면 되지 싶었는데.  기존 서비스가 엔터프라이즈를 지향하고 있다보니 트랜잭션, 성능 , 인증  문제해결이 매우 어렵다  결국엔 적당한 선에서 쪼개는 걸로 합의 

멀티테넌시
: 테이블 필드로 테넌트를 구분할지 ,  DB 단위 , 스키마 단위  혹은  DBMS 전체 단위 로 구분해야할지 고민이 많았다. 
현재 상황에서의 잠정적인 결론은 유저수가 많고 데이터양이 많으면  테이블 필드로 구분 , 
유저수가 적고 DB 양이 많으면 : DB 단위  
우리는 업무시스템 성격에 가까운 상황이라 DB 단위로 테넌트를 분리했다. 

 

스프링 클라우드 

: 유레카 , 터빈 , 집킨 오 하나하나 모두 놀라운 기능이였다.  그런데 spring-boot 의 무거움이 점점 발목을 잡기 시작하고 STS 의 간헐적인 Maven 빌드오류에 조금씩 지쳐가고 있긴하지만 현재로서는 마이크로서비스를 해야하는 상황이라면 스프링클라우드 구조가 최선이라 생각한다.

쿠버네트스 

: 초기 진입장벽이 높다는 말만 듣고 별로 시도해보지 않았는데 쿠버네티스 교육을 통해 궁금한 것들 대부분을 알게되서 실습도 해보았다. 

모든게 다 좋다. 하지만 돈이 문제다.  그리고 쿠버네티스 자체는 특정 클라우드에 의존적인 기술이 아니지만 제공하는 PaaS 에 따라 조금씩 사용방법이다르고  특히 현재는 구글클라우드가 단연코 짱인 상황.   내부에서 테스트 환경을 운영할려면 너무 빡시다. 

또 주저리주저리 하다 보니 글이 길어 졌다. 

암튼 현시점에 서버리스에 관심을 두는 이유는 

서버 운영에 고민 X 

스케일 아웃 고민 X 

반면 앞으로 주의깊게봐야하는 부분은 

 TDD 용이한지? , 디플로이 프로세스는 간편한지? , 기존 시스템과의 연계는 쉬운지 등이다. 

물론 AWS 에 의존적일수 밖에 없는 상황은 이미 가정하고 시작하는거다. 
(현재까지 AWS 가 문서도 많고  서비스도 많고  비용적으로 가장 합리적(=쓰는대로 돈내기) 이라는 판단) 

진짜 이제부터 살펴보자! 

; 근데 AWS 는 문서는 참 많은데 먼가..내용이 와닿지가 않고 어디부터 봐야하는지 헤메기 일쑤라 내가 이해력이 부족한건지 , 사전지식이 부족한건지, 아님 마음이 너무 조급한건지 잘 모르겠지만 . 암튼 결론은 잘안된다. 
그냥 내맘대로 이해하고 내 의식의 흐름대로 정리해놓자.

일단 하고 싶은건  아래 형태의 단순한 응답을 하는 Rest API  이다. 

유저 -----RESTful API ----->  (API GW)   -------- (lambda)

1. lamda 메뉴 

https://ap-northeast-2.console.aws.amazon.com/lambda/home?region=ap-northeast-2#/home

함수 만들기를 선택
새로 작성 탭을 선택하고 
이름 : fnHello   

런타임 : 8.10  기본값이라서 그대로 사용 

역할, 기존역할, 음....이건멀까...  일단  role_lambda_hello 라고 이름짓고 다음으로 진행! 

2. 생성 성공 
: 신기방기하구만 일단 그래픽컬하게 아래와 같이 보여지고 자동으로  클라우드 왓치 로그가 달려있는 상태로 보여진다. 

3. API GW 연결 

; 친절하게 왼쪽 목록에 있는 API 게이트웨이를 선택하니 알아서 아래와 같이 된다. 

일단 모두 기본값으로 둔상태로 저장! 

4. API 엔드포인트 확인 

; API GW 선택하니 아래와 같이 보인다. 

실제 브라우저로 접속해봐도 결과 응답이 왔다.

OK! 조아써! 

저 길고 이상한 URL 을  내가 원하는 URL 로 바꿔보자.  찾아보니  Route53 서비스를 이용하면 된다고 한다. 

휴~ 한숨돌리고 

2편으로~