오션뷰 개발 일지 - v2 Dolphin

해대인 개발 이후, 스타트업 취업에 성공하였다. 실제로 AWS에 배포도 해보고, api운영도 해보면서 많은것들을 배울 수 있었다. 해대인도 생각보다 많은 사람들이 이용해주었고, 학교에 남아있던 친구들이 개선요청도 해주었다. 개선요청이 쌓이면서 같이 개발하던 동료들중 시간되는 사람들이 뭉쳐 v2를 만들기로 하였다. v2의 프로젝트 명은 Dolphin으로 결정하였다.

Dolphin 🐬

서버도 새로 만들기로 하였는데, 기존의 서버가 작동하지 않아서는 아니고, TypeScript로 변경하고싶었고, AWS를 사용해보고 싶어서 새로 만들기로 결정하였다.

그리고 이번에는 나 혼자 서버를 만드는것이 아닌 3명이서 만들기로 하였고 PR 머지나, 배포, 초기세팅등 전체적인 큰 틀은 내가 담당하였다.

기술 결정하기

회사에서 TypeScript를 사용하였기 때문에, TypeScript를 사용하였고, node에 AWS Lambda를 사용하기로 하였다. 똑같이 FaaS를 사용한이유는 저번 글에서도 언급했듯이 사용량이 많지 않고, 운영에 대한 부담을 덜고 싶었기 때문이다.

확장 고려하기

람다를 사용하기로 하였으므로 handler 안에 모든 로직을 다 넣어서 사용할 수도 있을것이다. 하지만 그 경우, lambda가 아닌 ec2로 전환한다면? 아니면 cloud function으로 다시 변경하는 상황에 대처하기 힘들것이다.

따라서 보편적으로 사용하는 controller, service , repository에서 controller를 lambda의 경우 handler를 controller로 생각하고 service를 따로 분리하였다. (repository는 따로 만들지 않았다) service에 로직을 넣었고 데이터는 저번과 같이 하드코딩해서 사용하였다.

이렇게 하면 handler에서 원하는 서비스를 import해서 사용하고, 다른 express나 nest.js를 사용하는 경우 router나 controller, service에서 import해서 사용하면 기존 코드의 수정 없이 새로운 서비스를 도입하기 용이할것이다.

배포 자동화하기

AWS Lambda를 사용하는 경우 serverless라는 프레임워크를 사용하면 손쉽게 배포할 수 있는데, 여러 사람이 작업하는것이므로 내가 동료들에게 IAM 권한을 주고, 로컬에서 직접 배포하거나, 아니면 내가 요청을 받아 로컬에서 배포하는 불편한 방법들이 있었다. 그래서 github Action을 도입해서 원본 repository에서 serverless를 사용해서 개발자 누구나 버튼 하나로 배포할 수 있는 방식을 택했다.

Github Action

깃허브에서 제공해주는 runner로 회사에서 gitlab runner를 사용해보았기때문에 어렵지 않게 작업할 수 있었다. AWS configuration을 깃헙 레포지토리에 설정해둘 수 있어서 편리했다. 실제로 자동 배포를 도입하면서 작업시간을 획기적으로 줄일 수 있었다.

테스트 코드 도입하기

lambda는 serverless offline이라는 플러그인으로 로컬에서 함수를 실행시킬 수 있었는데 이 방식으로 로컬에서 테스트할 수 있지만, 수정할때마다 하나씩 다 실행시켜가면서 테스트하기에는 어려움이 있다. 어쨌든 테스트 코드의 중요성은 백번 강조해도 모자르기때문에 여기서 따로 언급은 하지 않을것이고, 최소한의 테스트 코드를 도입하였고 깃헙 액션 파이프라인에서 테스트를 통과하지 못하면 배포도 할 수 없도록 설정하였다.

테스트 코드

  describe('190 depart test', () => {
  it('getDepart190 test - 1', (done) => {
      const result = busService.getNextDepartBus();
      expect(result).toBeTruthy();
      done();
  });
  });

  describe('shuttle depart test', () => {
  it('getNextShuttle test - 1', (done) => {
      const result = busService.getNextShuttle();
      expect(result).toBeTruthy();
      done();
  });
  });

GitHub 배포 설정

  steps:
      - uses: actions/checkout@v2
      - name: Use Node.js $
          uses: actions/setup-node@v1
          with:
          node-version: $
      - name: Install dependencies
          run: npm install
      - run: npm ci
      - run: npm run build --if-present
      - run: npm test

개선할 점

테스트 코드

테스트 코드가 너무 부실했다. 실행되는지 확인만 하는 정도.. 실패 테스트를 더 넣어야 할듯하다.
Lambda의 한계(최적화…)

Lambda라는게 호출때마다 인스턴스가 생성되기 때문에 인메모리 캐시를 붙여놔도 동시 요청하면 새로운 인스턴스에서 함수가 실행되므로 캐싱의 의미가 없다. DB를 붙여도 잘못 관리하면 connection이 너무 많아지는 단점이 있다.(상태를 둘 수 없음) 만약 인메모리 캐시라도 붙이려면 ec2 같은 서비스로 교체하는것이 좋다.
DB의 부재

앱을 운영하다보니, 유저에게 푸시를 보내고 싶은데 그러려면 DB에 유저의 토큰을 저장해야했다. 여러 선택지가 있지만 현재 상황에서 RDS같은 서비스를 쓰기엔 오버스펙인듯 그리고 repository 인터페이스를 만들어서 DBMS를 변경하는 상황에 대비해도 좋았을듯 하다.
모니터링

모니터링을 전혀하지 못하고 있다ㅠㅠ 이 부분이 제일 아쉽다. 로그라도 추가해서 봤어야 했는데 로그 추가해 놓은 것이 없다. 데이터를 가지고 의사결정을 해야하는데 그렇지 못한 부분이 아쉽다.
운영

사실 팀원들이 모두 학교를 졸업했다 보니, 유저의 개선요청이 아니면 어떤 것이 문제인지 파악하기 어려웠다. 매일 신경쓰지 않으면 버스 시간이 틀린지, 학사 일정이 변경됐는지 알수가 없다.

후기

v1인 해대인보다는 기술적으로 많이 성장했고, 다운로드수도 예상했던것보다 훨씬 많았다. 사용자를 확보한만큼 새로운 기능을 붙여보고 싶은데 모니터링 대응, GA도 없고 졸업한 상태라 어떤 기능을 붙이면 좋은지, 그게 정말 유저가 원하는 건지?에 대해 고민이 된다. 현재는 v3인 오션뷰를 개발중이다.

Chaeyeon