최근 라이센스를 판매하며 유지보수를 진행하는 프로젝트에서 메이저 업데이트를 진행했는데, 기존에 배포하던 방식대로하기에는 어플리케이션의 용량이 상당히 커져서 서버에서 사용자에게 어플리케이션을 전송해주는 방식으로 대체하여 배포하기로 배포방식을 바꾸게 되었다. 게다가 매번 수동으로 파일을 건네주는것도 개발자 입장에서도 사용자 입장에서도 여간 불편했었으니까 이 기회에 확 바꿔보자 마음먹었다.

그래서 기존에 파일만 전송해주던 방식과는 다르게 서버와 데이터베이스, 그리고 백엔드가 필요했는데, 여기서 기존처럼 VPS를 할당받고 서버를 돌리는 방식을 택하는것보다 예전부터 마음먹었던 서버리스 아키텍처에 도전해보기로 결심해보았다.

서버리스 아키텍처를 선택하게 된 이유는 다음과 같았다.

1. 서버를 사용하는데 있어서 사용한 시간만큼 내고싶었다. 사용자들 평균 사용시간인 오후 7시부터 새벽2시까지의 시간동안만 서비스가 돌아가면 충분했다.
2. 보안이 어느정도 필요한 서비스였다. 하지만 보안에 관련되어 머리를 싸메고싶지 않았다.
3. 장애시 즉각 대응이 필요한 서비스가 필요했다. 하지만 서버를 모니터링 하면서 재부팅 시키거나 메모리 부족으로 고생하고싶지 않았다
4. 내가 서버 운영자가 아니기도 하고 일일이 설치한 패키지의 결함에 대한 즉각적 대응이 불가능했다
5. 공짜 최고 AWS 프리티어 최고

라는 이유로 서버리스 아키텍처를 적용하였고 간단한 어플리케이션임에도 불구하고 실 개발 약 1주, 소요기간 2주라는 시간이 걸려첫 서버리스 아키텍처가 적용된 서비스를 배포하게 되었다.

서버리스 서비스와 프레임워크 선택하기

서버리스 아키텍처의 인기가 올라간만큼, 다양한 클라우드 혹은 cdn들에서 서버리스 아키텍처의 서비스를 제공하고 있었다.

비교할 시간보다 어플리케이션을 배포해야 될 데드라인이 더 촉박했었다. 그렇기에 비교시간이 짧아 정확한 데이터로 비교하진 않았지만 AWS의 신뢰도, 그리고 AWS S3 및 DynamoDB까지 사용해보진 않았지만 이름은 친숙한 서비스들도 있었기에 결국 AWS Lambda를 선택했다. 그중에서 내가 해당 서비스들을 선택하지 않은 이유를 적어볼까 한다.

• Microsoft Azure Function
  • Azure를 필두로 최근 마이크로소프트의 클라우드가 상승세라 큰 관심을 두었지만, AWS 프리티어쪽이 훨 나았던걸로 기억한다.
  • Azure에서 전화돌려서 체하게 만든걸 아직도 가슴속에 쌓아두고있다. 제발 기업회원 아니면 전화돌리지말아줬음 한다.
    • 혹시 몰라서 적어둔다 장난이다
• Google Cloud Functions
  • AWS는 컴퓨팅 시간을 ms로 잡아서 ms단위로 받는데 비해 보안으로 인해 암호화가 많은 어플리케이션이여서 CPU 사용량이 많은 컴퓨팅에 불리하다 판단했다.
• Cloudflare Workers
  • CDN 서비스인 클라우드플레어 답게 캐싱을 강점으로 내세웠지만, 보안이 중요해서 캐싱은 독이였다. 게다가 인터넷을 찾아도 큰 사용 사례를 찾아볼 수 없어서 더 불안했다. 그리고 프리티어 한도에 도달하면 서비스도 끊기는게 최대 단점이였다.
• Zeit
  • 정적 사이트 호스팅과 결합되면 강점이라고 생각했지만, 내가 개발할 사이트들은 정적 사이트 호스팅을 진행할게 없었고, 프리티어 규모가 상당히 작았다.

그리고 나서 프레임워크로는 내게 가장 눈에 띄었던건 이전에도 블로그 피드의 글들로 자주 접했던 Serverless Framework였다. 프레임워크의 품질보다는 처음 개발이기 때문에 문서로 우선시 했기 때문이다. Serverless는 실제로 블로그에서 제공하는 문서들로 인해서 개발중에 막히는것이 존재하면 구글링하면 나오는것중에 10분의 9가 Serverless의 블로그 문서들이였었다. apex의 up도 눈에 띄었지만 apex의 up은 서버리스 아키텍처를 클라우드의 처음으로 도전해보려는 나에게 있어서 추가적인 진입장벽이 될것같은 느낌이 존재했다.

순탄치 않았던 개발과정

개발을 시작한다고 호언장담하고 서버리스 프레임워크까지 깔았지만 AWS를 완전히 모르고 시작했기에 IAM의 권한관리와 API Gateway, 그리고 Cloudformation, CloudWatch, KMS까지 모르는것들이 머릿속에 무더기로 더 들어왔다. 이렇게나 많은 모르는것들은 다시금 러닝커브로 돌아온다. 빡빡한 스케쥴에 러닝커브라니.

결국 서버리스 아키텍처로 하겠다는 내 욕심은 끝이 없었고 결과론적으로 프로젝트의 파일 배포는 2주나 밀리게 되었다. 게다가 프로젝트를 위해서 약 1달 넘게 개고생했던 내 예전 과거가 되돌아오는 느낌이였다. 넌 야근이다 임마 라는 내면의 악마가 속삭였다.

처음보는 천장이다

다행히 서버리스의 기본설정은 정말 간단했다. ‘기본설정’말이다. 테스트용으로 Lambda 어플리케이션의 헬로월드를 띄우고 난 뒤까지는 자신만만했다. 그리고 어플리케이션을 작성하자마자 멘붕이 시작됐다.

• Cloudformation? API Gateway? 이게 다 뭐야?
• 왜 devDependencies 로 저장된 패키지는 안올라가지? 아 내가 프로덕션을 올린건가? 아닌데 dev 스테이지에 들어가있는 어플리케이션인데? 왜 안올라가지?
• yaml말곤 설정파일 수정 못하나 포맷적응이 안되는데
• 왜 deploy 커맨드를 넣을때마다 서버리스는 모니터링 서비스 끼워팔기 로그를 출력하는거지?
• 로컬에서 확인할순 없나? 로컬에서 디버깅해서 올리면 deploy 시간을 줄일텐데
• 로컬에서 테스팅해서 올리니까 로컬에선 되는데 왜 Lambda에선 안먹히지?
• CORS? 헤더를 추가해서 넣어줬는데 왜 안되지?
• 등등..

여기서 다행이였던건, 위에도 적어뒀지만 막히는 모든 과정중에 거의 90%가 Serverless 프레임워크의 블로그 (opens new window) 게시물에 존재했다. 서버리스 프레임워크 최고.

나중에 기회가 되면 Apex의 up도 사용해보고싶다. 근데 확실한건 지금 당장 필요한 서버리스 아키텍처의 서비스가 있다면 당장 서버리스를 사용할것같다

서버리스 아키텍처 외의 추가 서비스들의 장벽

부제에 걸맞는 이야기다. 파일 관리 서비스인 S3와 NoSQL 데이터베이스인 DynamoDB에 대해서 이야기해볼까 한다.

DynamoDB

DynamoDB는 인스턴스(서버)를 빌리지 않고도 사용이 가능한 key-value 저장 형태의 NoSQL 데이터베이스다. 데이터베이스의 갱신이 별로 이루어지지 않는 내 서비스에 적합하다 판단했고, 실제로 유효한 전략이었다는걸 알게 되었다.

개발과정중 문제라고 하면 DynamoDB에서 취급하는 데이터 형태가 잘 감이 잡히지 않았었고, 인터넷에 나와있는 DynamoDB와 관련된 내용들은 상당히 오래전 문서들이였다. 심지어 공식문서에서도 업데이트 되지 않은 항목들로 인해서 꽤 골치아팠다. 버린자식인가 싶었을정도다. 문서 접근성도 상당히 떨어졌다.

옛날 문서들로 링크되는 대다수의 검색결과들은 현재 사용하는 sdk와 맞지 않는 내용들이 다수 존재했고, 데이터 포맷을 미리 지정하여 내용을 입력해야되는 내용들로 왜 에러가 뜨는지 한참헤멨다.

그 외의 문제점이라고 하긴 애매한 사항들에 대해서는 읽기/쓰기 용량의 1/1의 차이와 2/2의 응답속도 차이가 어마무시하게 차이났다는것이다.

S3

Simple Storage Service라길래 진짜 간단할줄 알았던 S3를 이용했다. 처음엔 CloudFront라는 CDN까지 이용해야하나 했었지만, S3만으로 간단하게 해결이 가능했었다.

파일의 보안을 위한 signed url(서명된 URL)기능을 제공하고, 파일별 http 캐시 및 권한 설정도 가능하고 기간도 설정이 가능했다.

S3은 꽤 마음에 들었다. 단점은 API가 정말 직관적이지 못하다는것. 아마 나중에 S3을 쓰면 API 래퍼를 별도로 작성해서 쓰지 않을까 싶다.

실 서비스 배포

실 서비스를 이 글을 작성하는 같은년도 같은월의 12일자로 배포했다. 배포하는 과정에 있어서 논리오류로 인하여 어플리케이션에 문제가 발생했지만, 코드를 조금만 고치고 deploy 한번으로 바로 사용자들에게 다시 재배포 하여 문제없이 해결이 가능했다.

첫 고생이 힘들었지 나중에 힘들진 않았다.

서버리스는 완벽한 도구는 아니다

모든 개발을 마치고 내린 결론은 다음과 같았다.

서버리스 아키텍처에서 제대로 돌아갈지 로컬에서 테스트 해도 실제 서비스에서 작동하지 않는 경우가 있었고, 정확한 로그가 표시되지 않는 오류 혹은 논리오류가 발생하면 정말 멘붕에 빠졌다. 물론 제대로 된 테스트 환경을 갖추지 않고 ESLint 하나에만 의존하여 버그를 찾는 습관이 낳은 결과지만 말이다.

AWS만의 특성인지 모르겠지만, 서버리스라고 해도 실제론 서버에서 작동하기에 서비스에 일정 시간동안 액세스가 없으면 유휴상태로 돌아가는 콜드 스타트로 인하여 초기 딜레이가 존재하는 등의 문제도 존재한다. Lambda가 만능도구는 아니지만, 나와 같이 혼자 개발하는 자원, 인력등의 리소스가 부족한 환경에서 사용하기에는 적합한 환경이라고 본다.

서버리스 아키텍처를 생각하고있는 입문자들에게 어느정도 도움이 됐으면 좋겠다.