[단축 URL 프로젝트 URLumberjack] - devOps 정의

0. 들어가며

 새 프로젝트를 시작하면서 가장 먼저 정해야 할 것은 서버 스펙입니다.
이를 정하는 데 있어서는 비용, 문서(공식 문서 및 구글링 문서량), 학습 난이도 세 가지가 가장 중요한 요소로 느껴졌습니다. 물론, 이는 상황에 따라 우선순위가 달라질 수 있지만요 ㅎㅎ

프로젝트를 진행할때 서버스펙에 관련하여 고민한 내용과 선택한 이유들을 정리해 보았습니다.

1. 서버스펙 overview

server spec table

2. NCP(Naver Cloud Platform) 선택 이유

https://www.ncloud.com

Cloud 비용이 가장 큰 비용 항목 중 하나이지만, 운이 좋게도 크레딧 지원을 받을 수 있게 되었기 때문에 이 큰 문제를 해결할 수 있었습니다. 또한, aws를 사용해온 경험이 있는 제게 NCP의 UI/UX는 쉽고 편안하게 사용할 수 있었습니다. 게다가 공식 문서가 한글로 작성되어 있어서, 검색을 통해 찾아보는 외부 문서도 양과 질이 뛰어나다 보니 매우 유용하다고 판단했습니다.

3. 서버/DB 구조를 1-2차에 나눠 scale out 하는 이유

 모든 개발 요소를 동시에 병행하는 것은 불가능하기 때문에, 선택과 집중이 필수적이라고 생각합니다.

왜냐하면, 각 단계에서 필요한 요소에 집중함으로써 보다 높은 품질과 안정성을 보장할 수 있기 때문입니다.

우선 핵심 비즈니스 로직의 품질을 확보하고, 이후에 안정적인 서비스 제공에 집중하기로 결정했습니다.

• 1차 개발 단계
  초기 개발 및 테스트 과정을 진행하는데 상대적으로 간단한 구조를 가진 시스템을 기반으로 핵심 서비스 구현 및 개발에 집중하여 안정성과 품질을 확보
• 2차 개발 단계
  시스템 확장성과 가용성을 높이기 위해, 다중 어플리케이션 서버와 다중 DB 서버를 구축하여 부하를 분산시키고, 장애 발생 시에도 시스템을 계속 운영할 수 있는 환경을 구축

 

4. CI/CD구현의 필요성과 CI/CD Tool 선택 이유

https://docs.github.com/ko/actions

CI/CD 구현시의 가장 큰 장점은 자동화된 테스트, 빌드, 배포로 인한 생산성 향상입니다.
이를 위해 Jenkins와 Github Action 두가지 서비스를 고민했는데, 결국 Github Action을 사용하기로 결정하게 되었습니다.
GitHub action은 비용, 요구되는 학습량, 문서량 삼박자가 모두 완벽하다고 생각됩니다

• GitHub Action을 사용하면 배포서버를 별도로 구축할 필요가 없다
  GitHub 자체 클라우드 서버에서 빌드 및 Docker 이미지 빌드, Docker hun push를 진해해 줍니다.
  그리고 어플리케이션 서버로 접속해 Docker Image pull 및 실행까지 작업을 수행할 수 있습니다.
  따라서 비용절감과 편의성 두마리 토끼를 잡을 수 있습니다.
• 낮은 학습커브
  YAML을 사용하여 간단하고 빠르게 작업을 구성할 수 있어 Jenkins에 비해 학습커브가 낮고 쉽게 적용이 가능합니다
• Github 통합환경의 장점
  GitHub와 통합된 환경에서 모든 GitHub 이벤트를 트리거로 설정할 수 있어 배포 자동화가 용이합니다.
  또한 코드 리뷰 및 이슈 트래킹 등과 같은 다른 GitHub 기능과의 연계도 용이합니다.

Github action 사용시에 주의할 점도 있는데요, 프로젝트가 piravite repo일 경우엔 GitHub Actions은 무료로 사용할 수 없습니다.🥲

https://choseongho93.tistory.com/295

 

5. 캐시/세션관리의 필요성과 Redis를 선택한 이유

redis

 캐시를 사용해 반복적으로 수행되는 작업을 저장하고 불러내어 불필요한 데이터베이스 요청을 줄일 수 있고, 세션을 사용하면 사용자의 인증정보와 같은 중요한 정보를 안전하게 전달할 수 있습니다. 단일 서버에서 이를 관리하는데에는 데이터베이스나 로컬캐시만으로도 충분합니다. 하지만, 다중 서버 구조로 구현하면 다음과 같은 문제가 발생하게 됩니다.

• 캐시 / 세션데이터 유실
  사용자의 인증정보나 캐시 데이터 등이 서로 다른 서버에 저장되어 있을 경우에 동일한 사용자의 다음 요청이 다른 서버로 전달될 경우 인증정보나 캐시 데이터가 유실되는 문제가 발생할 수 있습니다.
• 동시성 이슈
  각각의 서버에서 동시에 같은 데이터를 처리하는 경우가 발생할 수 있습니다. 일관성 있는 데이터 처리를 위해서는 서버 간에 데이터를 공유를 통해 동시성 제어가 필요합니다. 

 따라서, 다중 서버 구조에서 단축 URL 서비스와 같이 여러 서버에서 공통으로 사용해야하는 기능에 대해 데이터를 안전하게 공유할 수 있는 데이터베이스나 캐시 서버가 필요합니다. 하지만 데이터 공유를 외부 스토리지나 데이터베이스를 사용할 경우, 불필요한 I/O 작업으로 인해 응답 시간이 느려지는 문제가 발생할 수 있어, 메모리에 데이터를 저장해 read/write가 매우 빠른 In-memory 데이터베이스카 빌요하게 됩니다.

 

in-memory 데이터베이스도 종류가 굉장히 많지만, 저는 구축 및 사용이 처음입니다.
그래서 인기가 많아 자료를 구하기 쉽고 적용 케이스가 많다는 장점이 가장 크게 작용하여 Redis를 선택하게 되었습니다.

물론 단순 문서량이나 인기를 제외하고도 redis는 장점이 정말 많습니다.

1. 메모리 기반 데이터베이스의 빠른 응답 속도
2. 다양한 데이터 구조 지원
3. 여러 서버에 데이터를 분산할 수 있어 스케일 아웃이 용이
4. 디스크에도 데이터를 저장할 수 있어 장애시에 데이터 유실 방지 가능
5. 다양한 데이터베이스와 쉽게 통합하여 사용할 수 있어 확장성이 우수
6. 높은 인기로 인해 자료가 풍부

 

6. APM Tool의 필요성과 PinPoint 선택 이유

pinpoint

 APM 도구는 어플리케이션의 성능 모니터링을 통해 문제점을 미리 파악하고 성능 튜닝을 하거나 발생한 문제를 빠르게 탐지하여 안정적으로 서비스를 운영하는데 도움을 줍니다.

 

 PinPoint와 Scouter는 두 가지 선택지 중 하나를 고민했는데, APM tool을 처음 구축해 보는 거라, 최우선순위는 구축 가이드 및 문서와 낮은 학습 커브였습니다.
PinPoint는 네이버에서 오픈소스로 개발하여 NCP에서도 설치형 서비스로 제공하고 있어 문서도 잘 갖추어져 있어 선택하게 되었습니다.

 

7. 부하테스트의 필요성과 nGrinder 선택 이유

nGrinder

 부하 테스트는 대량의 request를 통한 데이터 처리를 시뮬레이션하여, 실제 사용 환경과 유사한 조건에서 시스템의 병목현상과 같은 예상치 못한 이슈를 파악하고 최적화하는 것입니다.
이를 통해 서버의 안정적인 운영을 위한 가이드라인을 세우거나 scale up 시기를 결정할 수 있습니다.
저는 주요 지표 중 TPS를 측정하여, 서비스에서 처리할 수 있는 트랜젝션의 수를 파악하고 제한할 커넥션 수를 가이드라인으로 설정하고자 하였습니다.

 

이번에 부하 테스트를 처음으로 시도해 보게 되서 자료가 많은 툴을 찾다 보니 JMeter와 nGrinder 두 가지 중에서 고민하게 되었습니다.
nGrinder는 네이버에서 오픈소스 프로젝트로 개발한 툴로써 공식문서도 한글로 존재하고 구글링시 자료도 상당히 많았습니다! 그리고 TPS 측정에 중점을 둔 기능을 가지고 있어 선택하게 되었습니다.
스크립트를 작성해야 된다는 단점이 있지만, 가이드와 많은 문서들로 이를 극복할 수 있다고 판단하였습니다.