10부. Day34 Serverless 프로그램 구조 잡기
지난 편 ▶︎ 9부. Serverless Framework에서 제공하는 Dashboard 살펴보기
이번 마지막 Chapter 에서는 Serverless Framework 으로 프로젝트를 어떻게 구조화 할 것 인지에 대한 부분을 공유하고자 한다. 먼저, 두 가지를 생각했다. 한 가지는 Serverless Framework Dashboard 기준으로 하나의 App 안에 서비스 모듈 별로 구조화 하는 방법과 다른 하나는 서비스별로 여러 개의 App 으로 만들어 서비스를 구조화 하는 방법이다. 글로만 봐서는 잘 이해가 되지 않으니 조건과 함께 그림으로 표현해 보도록 하겠다.
Serverless 로 가고자 하는 서비스 모듈들
1. KStarLive 인증 모듈 ( KStarLive Authentication )
2. 내부 통계 프로그램 API ( KStarLive Statistics )
3. 회원 관리 ( 로그인, 회원가입 등 )
4. 제휴로 인한 타사에 제공하는 Resource API ( KStarLive Resource API )
5. Chatting Notification 및 ChatBot API
6. Toy Project
앞으로 더 많은 서비스들이 생겨 날 수 있지만 우선 AS-IS 로 정리한 서비스는 이 정도 수준이다. 현재 있는 서비스들을 구조화 시키기 위해서 저자가 현재 최적이라고 생각하는 방식은 이러하다.
Single-App-Multiple-Service 방식
1) 먼저 KStarLive App을 만든다.
2) App 내부에 ALL SERVICES 라는 부분을 서비스 모듈들을 각각 만들어서 관리한다
이런 구조가 되려면 serverless.yml 에서 app 명은 동일하고 service 명만 구분 해주면 되는 방식이다. 명확하게 kstarlive App 안에서는 여러 서비스들이 존재하고 해당 서비스를 눌렀을 때는 그 서비스에서 제공하고 있는기능들이 존재한다.
Multi-App-Single-Service 방식
위의 방식이 하나의 App 에서 여러 Service 를 나누어 관리하는 방식이라면 이 방식은 서비스 별로 각각의 App 을 만들어서 각각 내가 서비스 하고자 하는 Service 단위를 1:1 로 Mapping 하는 방식이다. 사실 무엇이 맞다고 할 순 없다. Concept 으로 보았을 때 저자는 Single-App-Multi-Service 가 맞고 그 방식을 따랐을 뿐이고 다른 방식으로 관리해도 무방하다. 관리에 차이가 있을 뿐이다.
Git Repository 관리 전략은 서비스별로..
그렇다면 Git의 Repository를 어떻게 관리를 할까에 대해서 고민했다. 처음에는 아래와 같이 프로젝트의 각 1 depth 를 서비스 별로 구분하여 하나의 Repository 에서 관리 하도록 생각했다.
위의 방식을 곰곰히 생각해보니 구지 Auth(인증) 개발을 하는 사람은 Member (회원관리) 개발에 대한 영향을 받을 필요가 없다고 생각이 들었다. 그래서 최종적으로 내린 결론은 Repository를 많이 만든다고 해서 돈이 드는 것은 아니니 서비스별로 분리하는 것으로 결정하였다. 즉, 서비스별로 Repository 를 만들어 관리하는 방식이다.
결론..
Day34 Serverless 개발 시 App과 Service 를 구조화해서 개발하는 방식은 Single-App-Multiple-Service 방식으로 선정 하였고 형상관리는 Git 으로 각각의 Service를 Repository로 나누어 관리하는 방식으로 가기로 잠정적으로 결론을 지었다. 연구 공로가 큰 사람 독재 하에…….-ㅇ-
마무리
10부작의 연재가 드디어 피날레를 올리는 순간이다. 우리는 처음 Serverless 를 개발하는 조직이 아니라 V1 으로 이미 Serverless 환경에서 Start-up 기업이 부족하게 느끼는 개발 리소스와 코스트를 절감할 수 있는 서비스 개발의 전략적 도구로써 잘 사용하고 있었다.
그리고 앞서 2부에서 나누었던 기존 개발 방법에 문제를 해결하고 개선하고자 V2 를 연구하였고 어느정도 문제라고 여겼던 부분들을 연구를 통해 개선하였다.
회고를 하자면, 좀 아쉬운 점은 이 부분이였다.
AWS Lambda 에서는 Layer(계층)기능이 존재하다. 이 부분은 람다 함수들이 공통적으로 써야 하는 모듈을 Layer로 등록하여 버전 관리하며 쓰는 방식인데 이 부분을 차용하지 못한 것이다. 실제로 V1 에서는 사용하고 있었으나 Serverless Framework 을 통해 충분히 검증이 되지 않았고 오히려 불편하다고 여겼기 때문에 과감하게 제거했다.. 여러모로 오랜 기간 읽어 주고 따라와 준 독자 여러분들에게 감사의 표시를 전하며 이상 “Serverless로 하루만에 개발하기”를 마치고자 한다.
감사합니다.
