서버/프론트엔드 디플로이 의존 분리

slowwalker2·2020년 5월 23일
0

개요

앞으로 회사에서 한 일들을 적어보려 한다. 왜냐면 그거 말고 쓸게 없음. 이번 글의 주제는 우리 서비스가 가진 고질적인 문제의 해결에 대한 이야기이다.

왜 의존 분리를 했는가요?

서버/프론트엔드 디플로이 의존 분리 를 했는가요? 라고 물으면 답변은 아래와 같다.

기존 프론트엔드의 빌드 프로세스가 서버의 빌드 프로세스의 일부로 포함되어있는 똥같은 구조였다. 때문에

  • 프론트엔드가 독자적인 개발주기를 갖기 어려움
  • FE가 왜때문인지 서버의 빌드프로세스를 알고있지 않으면 안된다
    • capistrano 스크립트라던가
    • AMI 작성스크립트라던가
  • 프론트엔드 단독 릴리즈가 불가능
  • 당연히 개발환경 디플로이도 단독으로 불가능하기 때문에 불필요한 대기시간이 늘어남
    • 개발 사이클이 늘어진다... 🐌

애초에 왜 의존관계가 있었는가요?

우리 서비스의 프론트엔드는 어중간한 SPA 이다. 지금도 그렇다.
8년정도 운영된 서비스인데 중간중간 개선해가는 과정에서 현재에 도달했다는 얘기를 들었다. 일부 화면이 서버에 의존하는 (지금도 잔존하는) 문제로 서버는 manifest.json 을 갖고있어야 한다.

지금까지는 서버의 빌드프로세스 안에서 프론트엔드 빌드를 하고, 그로인해 생성된 manifest.json 을 서버의 일부로써 포함한 상태로 AMI를 작성하고 있었다. 이건 어떻게봐도 비정상적인 구조인데, 누구도 이걸 개선하려하지 않았다. 왜냐면, 잘 동작하니까. 그리고 당장 앞에 닥친일이 산더미같으니까. 그걸 내가 주워서 한거나 왜냐면 난 회사 공식 잉여인력이기때문에! ^^

어떻게 개선했는가요?

지금까지의 방법이 서버에 manifest.json 을 밀어넣는 push 형태이라고 했을 때, pull 형태로 바꿔서 개선했다.
프론트엔드의 디플로이를 빌드 & S3 업로드만으로 완결시키고, 서버는 주기적으로 S3 저장된 manifest.json 을 가져오는 것.
조금 더 적어보면 최종 업데이트시간을 memcached 로 관리하고, 유저의 리퀘스트가 있었을 시 최종 업데이터로부터 일정시간이 경과했으면 manifest.json 을 갱신하고 리스폰스를 하는 그런 구조이다.

결론

간단한 개선이지만 결과 SE/FE 는 예전보다 더 독자적인 개발, 그리고 릴리스사이클을 갖게되었다.
굳 굳 베리굳.

profile
띨띨함

0개의 댓글