[프로젝트 일기] 서버 아키텍처를 설계 하면서 - 구상

이번 학기에 대학교 총학생회 홈페이지 개발의 백엔드 팀에 합류하게 되었습니다.

저는 이번 스프린트에서 서버 아키텍처 설계 및 문서화라는 업무를 맡게 되었고 이 과정에서 고민했던 점들을 정리해 볼까 합니다.

현재 상황

1. 학교측으로 부터 클라우드 서버를 지원 받았지만 무턱대고 큰 용량의 인스턴스 타입을 사용할 수는 없었습니다. 비용등을 고려하면서 리소스를 최적화 해야만 했습니다.
2. 개발 서버를 운영 서버와 최대한 동일하게 구성해서 테스트하고, 테스트가 완료되면 사용한 리소스를 일괄 삭제하고 싶었습니다.
3. 만약에라도 사용자가 많아진다면 기능 배포뿐만 아니라 스케일 아웃까지 고려를 해야하는 상황이었습니다. 보다 안정적인 서비스와 효율적인 배포를 위해서 배포시간을 최적화 해야만 했습니다.

이러한 상황을 종합해봤을때 도커를 사용한 컨테이너 환경으로 서버를 구축해야 겠다는 생각을 하게되었습니다.

그리고 컨테이너만 도입할 것인지, 아니면 더 많은 기능을 위해 오케스트레이션 툴을 도입할 지도 고민을 하게되었습니다.

이 부분에 대해서 팀원들과 얘기를 나눈 결과 쿠버네티스를 사용해 보자는 이야기가 나왔습니다.

쿠버네티스.. 해본적 없는데

쿠버네티스를 들어만 봤지 프로젝트에 도입해본 경험도 없을 뿐더러 제대로된 개념을 알지도 못했습니다.

이러한 상황에서 쿠버네티스를 직접 구현하자니 많은 공부량과 리소스가 투자되어야 할 것 같았습니다.

주어진 기한안에 직접 구현하기에는 조금 무리가 있다고 판단되었고 저는 대신에 NHN Cloud에서 제공하는 NHN Kubernetes Service(NKS) 를 서비스에 최적화해서 사용하기로 결정했습니다.

NKS를 사용하면 세밀한 기능은 부족하지만 관리 복잡도가 낮고 사용자에겐 직접 구현과 동일한 사용자 경험을 제공한다는 점이 장점입니다.

걱정은 아직도 태산입니다

한번 해보자는 생각으로 컨테이너와 쿠버네티스를 사용하기로 결정하였지만 마음 한켠에는 과연 내가 잘 할 수 있을지에 대한 걱정이 있었습니다.

1. 내가 제대로 알고 하는걸까?

   도커에 대한 발표를 한적은 있지만 과연 그것만으로 컨테이너에 대해 잘 안다고 할 수 있을까?

   좋은 아키텍쳐가 뭔지도 모르고 특히 쿠버네티스는 러닝 커브가 크다고 들었는데, 너무 과한거 아닐까?

2. 서비스 개발할 시간도 부족할거 같은데?

   안그래도 여러 사정 때문에 개발 일정이 밀린 상황인데 인프라 작업까지 다 할 시간이 있을까?

3. 도입해도 운영중에 계속 장애 나면 어쩌지?

   장애 대응을 내가 빠르게 대처할 수 있을까?

지금 안하면 언제 해보겠어

처음 접하는 기술에 대한 겁이 이렇게 많아서야 개발로 밥 벌어 먹을 생각을 한 사람인가 싶었습니다.

백문이 불여일타 이듯이, 실제 운영 서비스에 기술을 도입해서 다양한 장애도 겪어봐야 제 지식이 될 수 있다고 생각합니다.

시스템을 직접 구축하게 되면 예상되는 장애에 더 철저히 대비할 수 있고 이슈가 발생했을 때 더 빠르게 대응할 수 있습니다. 이러한 설계를 구축해놔야 후배들이 서비스 유지보수를 이어받더라도 부끄럼 없는 선배로 기억에 남지 않을까 하여 더 철저히 준비하고자 했습니다.

서버 아키텍처

다음은 제가 설계한 서버 아키텍처입니다.

Product 환경

• Nginx로 Reverse Proxy 구성
  • 로드 밸런싱 적용 $($헬스 체크로 WAS 상태 주기적으로 확인 → 진행 상황과 일정 고려하여 도입 여부 결정)
  • 블루/그린 무중단 배포 적용
• 운영 WAS 2대 사용하여 단일 장애점 예방
• Redis로 캐싱 구현
  • 비 로그인 상태에서 메인 페이지 캐싱하여 조회 성능 최적화
• NHN Object Storage 사용해서 이미지, 파일 업로드

CI/CD 파이프라인

• PR 생성되면 Jenkins는 CI를 위한 SonarQube 실행
  • Sonar-Scanner 사용하여 정적 분석 진행, sonarQube 서버를 통해 퀄리티 게이트 체크
  • SonarQube 파이프라인이 실패한 경우, PR Merge 방지
• PR이 Merge 되면 Jenkins로 CD 파이프라인 진행
  • docker build를 통해서 docker image 생성하여 NCR $($NHN Container Registry)에 Push
  • Helm 사용하여 어플리케이션을 배포.
• NHN NKS
  • NKS를 사용하여 관리형 서비스를 최대한 활용
  • Prometheus 사용하여 쿠버네티스 metric을 모니터링
  • Grafana를 구축하여 현재 쿠버네티스의 상태를 Dashboard를 통해서 모니터링
    • $($Container의 CPU, Memory, Pod 등)

참고 자료 📚

왜 굳이 도커(컨테이너)를 써야 하나요? - 컨테이너를 사용해야 하는 이유

[우리는 불편함을 어떻게 마주하고 있는가

우아한형제들 기술블로그](https://techblog.woowahan.com/2696/)