본문으로 건너뛰기

2023.07.12

· 약 9분

1. 내부 툴 개발​

요즘 회사 내부 툴을 개발하고 있다. 누가 시켜서 한 건 아니고 일하면서 불편하고 비효율적인 부분들 자동화를 위해서 개발하고 있다. 처음에는 script cli로 개발했는데 불편한 점이 여러개였다.

  1. script 실행시킬 때 해당 프로젝트로 가서 실행시켜야 한다.
  2. 누가 script를 업데이트하면 다른 사람들이 모두 git pull을 받아야 한다.

1번은 어찌 해결할 수 있겠지만 2번이 문제였다. 그래서 웹서버를 만들 계획을 하게 되었다. 리소스는 좀 들겠지만 cli는 관리도 힘들고 처음에는 사용해도 점점 사용을 하지 않게되는데 웹서비스는 여러 기능들을 한 곳에 모아둘 수 있고 좀 더 직관적이기 때문이다.

지금 테스트계정으로 인프라 셋팅을 한 상태라 도메인도 못붙히고 http로 동작하고 있는데 나중에 계정도 변경하고 인프라셋팅도 전부 업데이트할 필요가 있다. 우선 vpn으로 연결해야만 접속가능하게 보안셋팅만 했다.

추가로 ec2에서 git clone을 못해서(github enterprise) ecr을 이용했는데 이부분에서 진짜 많이 배웠고 재미도 있었다. github action에서 next standalone mode로 docker image build하여 ecr에 등록하고 ec2에서 iam 계정으로 ecr 로그인하여 image pull 받아 돌리도록 했는데 이런 플로우를 처음으로 셋팅해서 트러블 슈팅도 많이했고 배운것도 많았다.

dockerfile 관련된 내용은 정리도 해보고 싶다. 웹에서 관련 내용 찾기도 너무 어려웠다 ㅠ

추가로 cd 과정에서 ecr 자동업로드 까지는 했는데 ec2에서 image 받아 돌리는건 아직 수동이라 이것도 자동화하는 작업이 필요하다.

2. 회사 Framework 논의​

회사 팀 내에서 Framework를 정하는 논의를 시작하기전 간단하게 정리해보았다.

1. 논의 항목​

  1. CSR vs JAM Stack vs SSR 선택하기
  2. Framework 선택하기 (이건 거의 정해진 것 같아요)
  • CSR: vite
  • JAM Stack, SSR: NextJs

2. CSR vs JAM Stack vs SSR​

  • ReactNative는 논의에서 제외시켰어요. 현재 리소스에서는 불가능하다고 판단되어 논의 항목에 넣기에는 무리라고 생각해서에요. https://toss.im/slash-23/session-detail/A1-4
  • 혹시 위 영상을 보지 않았다면 꼭 봤으면 좋겠어요. 지금 사용하지 않는 방법이지만 방법을 알고 있느냐 없느냐는 천지차이라 생각하기 때문이에요.

개선점 + 한계점​

  • CSR
    • 현재 방식이라 따로 적지는 않을께요.
  • JAM Stack
    • 토큰을 사용하지 않는 페이지 (비회원, 이벤트)들에 대해 미리 html을 만들어둬요.
    • 홈을 예시로 들면 비회원 홈에 이벤트 리스트들이 있고 이벤트 리스트들을 동적으로 관리한다고 했을 때 html을 만들때 api 찔러 이벤트 리스트를 받아와 html을 만들어두었기에 유저 입장에서 속도도 빠르고, client에서 api를 찌르지 않아도 되어요.
    • 크론잡처럼 배치로 서버를 돌려 html을 만들껀데 30분 주기로 설정할 수도 있고 서버를 돌리는 api를 만들어 api를 쏘면 빌드를 하도록 할 수도 있을 것 같아요.
  • SSR
    • 모든 페이지들에 대해 html이 만들어진 후 렌더링이 될꺼라 유저 경험이 극도로 좋아져요.
    • 토큰 인증 방식이 먼저 개선되어야만 모든 페이지들에 대한 ssr이 가능해요.
      • 토큰 인증 방식이 개선되지 않는다면 토큰을 사용하지 않는 (비회원, 이벤트) 페이지들만 ssr이 가능해요.
    • 인증을 담당할 bff도 next server에 들어가면서 next가 엄청 많은 트래픽을 받게 될꺼에요. apiGateway보다 더 많은 트래픽을 받을꺼에요.
      • 이때 운영상 리소스가 많이 발생할꺼에요.
      • 문제가 발생하면 FE가 우선적으로 대응을 해야할껀데 이게 쉽지 않을 것으로 예상돼요.

리소스 & 리스크 분석​

이관 리소스 분석​
  • CSR (1)
    • 기존에 사용하는 방식이라서 다른 방식을 측정하기 위한 기준점으로 정해볼께요.
  • JAM Stack (3)
    • Framework(NextJs)를 새로 도입하고 이관하는 과정이 필요해요.
    • S3 + Cloudfront + Lambda(or EC2 or ECS) 인프라 셋팅과 구성이 필요해요.
    • (ECS로 돌린다고 했을 때 서버 관리를 위한 모니터링 툴(ArgoCD , Grafana)도 필요해요.)
      • 최대한 리소스 안드는 lambda or ec2가 좋을 것 같아요.
      • 서버쪽 인프라 구성과 동일하게 하려면 ecs로 해야겠지만..
  • SSR (8)
    • Framework(NextJs)를 새로 도입하고 이관하는 과정이 필요해요.
    • S3 + Cloudfront + ECS 인프라 셋팅과 구성이 필요해요.
    • 서버 관리를 위한 모니터링 툴(ArgoCD, Grafana) 셋팅이 필요해요.
    • 로그를 쌓고 보기 위한 elastic logstash 셋팅이 필요해요.
      • 서버쪽과 동일한 구성으로 진행될 것 같아요.
운영 리스크​
  • CSR (0)
    • AWS에 장애가 있지 않는 이상 없어요.
    • 정적인 리소스들이라 운영이 필요하지 않아요.
  • JAM Stack (3)
    • 일정 주기마다 실행될 서버자원에 대한 모니터링이 필요해요. (아마 slack 알림정도)
    • 서버가 실행되지 않았거나 api를 쏘고 제대로 markup이 되지 못한 경우에 대한 작업이 필요해요.
      • 서버 자원이 죽더라도 유저에게 직접적인 문제가 발생하지는 않기에 리스크는 매우 적어요.
  • SSR (10)
    • 실시간 모니터링이 필요해요.
    • 인프라팀이 도와주시겠지만 FE 자원이 지금보다 훨씬 많이 들 것 같아요.
    • 서버 배포에 문제가 생길 경우, 서버 운영에 문제가 생길 경우 slack과 연동시키고 온콜이 필수적으로 필요할 것 같아요.