Final 버전 배포
4주차에 MVP 버전을 개발 및 배포 후에 5주차 FINAL 버전을 개발해야 했다.
기존에 구현해놓았던 기능들을 개선하는 것과, FINAL 버전에만 구상해놓았던 기능들을 개발하는 것이 이번 주차의 주 업무였다.
CI/CD -> GitHub Action / Docker
이번 주차부터는 기능 브랜치에서 변경되는 사항이 서로간의 검토를 거친 후에 dev 브랜치로 병합되었을 때, 자동적으로 배포 버전이 업데이트 되는 CI/CD 파이프라인을 구축하기로 계획하였다.
업데이트가 될때마다 서버 콘솔로 접속하여 pull 하는 것은 전부터 생각했지만 너무나 비효율적이라고 판단했기 때문이었다.
우선 CI/CD 플랫폼으로 Github Actions을 결정했는데, 이유는 GitHub Actions는 GitHub 저장소와 직접 통합되어 있어, 코드 저장소와 CI/CD 파이프라인을 별도의 서비스로 관리할 필요가 없기 때문이었다.
또한 코드 통합, 테스트, 배포 등 다양한 개발 단계를 자동화할 수 있다는 장점은 너무나 크게 다가왔는데, 예를 들어서 풀 요청이나 커밋이 발생할 때 자동으로 테스트를 실행하거나, 코드 병합 시 자동으로 배포할 수 있습니다.
Github Action으로 배포된 버전을 기존 코드가 있는 서버에 적용시키기 위해서는 Jenkins 와 Docker를 고려했다.
Docker를 사용하면 애플리케이션을 컨테이너화하여 일관된 환경에서 배포 및 실행할 수 있다는게 굉장히 큰 이점으로 느껴졌다. GitHub Actions와 함께 Docker를 사용하여 애플리케이션의 빌드 및 배포 과정을 표준화하고, 서버 환경에 관계없이 동일한 방식으로 애플리케이션을 실행할 수 있다는 것은 Docker의 사용 방법과 컨테이너화 전략을 잘 활용하는 것이라고 생각해 Docker를 선택하였다.
HTTPS 프로토콜 및 리버스 프록시 적용
사용자 유저의 개인 정보가 요청에 담겨 서버에서 전송하는 과정에서 보안을 고려하는 것이 필수적이라고 판단했다.
예전이었다면, 서버에서 난수를 생성하고 클라이언트에서 해당 난수에 맞는 단방향 암호화 처리후에 전송을 하는 챌린지-응답 인증(Challenge-Response Authentication)을 고려했어야 했다.
그러나 현재는 모든 요청과 응답이 암호화되어 네트워크에 전송되는 HTTPS 프로토콜이 있었기에 적용하지 않을 이유가 없었다.
전송되는 '데이터'를 암호화 하는 방법도 좋지만, 데이터가 전송되는 '채널' 자체가 암호화 된다면 사용자 입장에서 '데이터 탈취' 자체에 대한 걱정을 덜 할 수 있으므로 HTTPS를 더욱 고려하게 되었다.
SSL 인증서 + 리버시 프록시의 역할을 할 서버구축
Nginx Web Server는 모든 트래픽이 거쳐가는 중심점으로, 비동기 이벤트 기반의 구조를 가지고 있어 높은 동시성을 낮은 메모리 사용량으로 처리할 수 있다는 점이 큰 장점이었다.
SSL 인증서를 Nginx에 구성하여 HTTPS 프로토콜을 적용함으로써 데이터의 안전한 전송을 보장할 수 있었다.
또한, Nginx는 리버스 프록시 기능을 기본적으로 지원하여, 보안을 강화하면서 클라이언트 요청을 NCloud VPC 내부의 다른 서버로 안전하게 전달할 수 있다. 추후에 웹 애플리케이션 서버(WAS)에 클러스터링을 적용하거나 여러 서버 인스턴스를 추가할 때 로드 밸런싱 기능을 활용할 수 있다는 점도 큰 이점으로 여겨졌다.
Nginx를 적용한 어플리케이션 통신 과정
Object Storage Image Resizing
어플리케이션 통신 과정을 어느정도 구성한 후, 트래픽 모니터링 전에 UX를 통한 기능 개선을 먼저 이루고자 하였다.
사용자에게 받은 피드백으로써는 첫째로 Image의 업로드 및 로딩 시간이 길다는 것이었다.
때문에 프로젝트에서는 오브젝트 스토리지를 이용하여 이미지를 관리하고 있었는데,
최적화를 위해 이미지를 서버에 업로드하기 전에 리사이징 처리를 적용했다.
이로 인해 한 번 리사이즈된 이미지는 클라이언트의 다운로드 속도를 400% 향상시켰다.
이 변경은 초기 업로드 시간이 길어지는 트레이드오프를 감수하는 대신, 사용자 경험을 개선하고 네트워크 대역폭 비용을 절감하는 장기적인 이점을 제공했다.
해당 과정에서는 큰 고민 과정이 있었는데, 서버에서 Presigned-Url을 클라이언트에게 제공하여 일정 시간 내에 클라이언트가 직접 Object Storage에 저장하도록 하는 방법과, 모든 데이터가 서버로 전송되게 한 후 서버에서 자체적으로 resizing을 처리 후에 Object Storage에 업로드 하는 방법이 있었다.
전자의 경우, 서버의 traffic 부하 감소라는 장점이 있었지만 후자는 서버 측에서 이미지를 리사이징하기에 결과물의 품질을 일관되게 유지할 수 있었다. 이는 서비스 및 사용자 경험의 일관성을 높인다고 판단했기에 후자의 방법을 선택하고 서버에서 트래픽을 감소시킬 수 있는 클러스터링, 쿼리 자체 개선 등을 적용하기로 했다.
