카테고리 없음

최종 프로젝트 기술스텍

suuuki 2025. 1. 7. 21:41

1. 기술적 의사 결정

1. 인프라는 어떻게 설계하는게 좋을까?

도입

  • 클라우드 서비스 전체에서 32%를 점유하고 있는 AWS 서비스를 이용
  • 부하 분산에 유리한 인프라 설계

문제상황

  • 외부 사용자가 백엔드 서버에 바로 접근할 수 없어야 함
  • 데이터 탈취가 일어나지 않아야 함
  • 부하가 분산되어야 함
  • 스케일업보다 스케일아웃을 활용

의견 조율

  • NLB vsALB 사용 여부 결정
    • NLB
      • L4계층에서 동작하며, 트래픽 부하 분산만 제공
      • TCP/UDP 트래픽 처리
      • 여러 개의 NLB를 사용해야 하므로 비용이 증가
    • ALB
      • L7계층에서 동작하며, 도메인 별로 분기 처리를 지원
      • HTTP/HTTPS 트래픽 처리
      • ALB 하나만으로 모든 도메인 요청을 각 백엔드로 분기 처리 가
  • RDS 사용 여부 결정
    • RDS
      • 고가
      • 데이터 안정성
      • 비교적 제어력이 떨어짐
      • 고가용성을 위한 장애조치를 지원
    • EC2 및 Docker
      • 저가
      • 서버 초기 설정을 해야 함
      • 비교적 유연한 설정이 가능함
      • 모니터링 시 직접 관리가 필요
  • Docker Swarm or ELB (EC2 Load Balancer)
    • Docker Swarm
      • Dokcer에서 제공하는 컨테이너 오케스트레이션 도구
      • 무료로 사용이 가능
      • 내장형 컨테이너 로드 밸런싱 제공
    • ELB
      • AWS에서 제공하는 로드 밸런싱
      • 사용량 기반 비용 발생
      • 애플리케이션 및 네트워크 로드밸런싱이 가능
      • 높은 트래픽과 복잡한 로드밸런싱의 요구사항이 있는 경우 유리

결정

  • NLB vsALB
    • 프론트엔드 구현을 위해 애플리케이션 계층의 로드 밸런싱(ALB)을 사용
  • RDS를 사용하지 않고 EC2에 Docker를 이용해 DB를 구축하기로 결정
    • EC2는 RDS보다 더 유연한 비용 구조를 제공
    • 데이터 관리의 유연성
  • Docker Swarm or ELB (EC2 Load Balancer)
    • ELB를 사용하기로 결정
      • Docker Swarm은 직접 노드를 구성하고 클러스터를 유지해야 하지만, ELB는 AWS가 모든 관리를 수행하여 관리가 간편함
      • AWS Auto Scaling과 연동하여 손쉽게 수평 확장이 가능함

2. 인증, 인가 시 JWT vs Session 결정

도입

  • JWT를 도입하여 사용자 인증/인가를 구현

문제상황

  • 분산 서비스에 유리해야 함
  • 서버에 부담을 최소화해야 함
  • 권한 확장이 유리해야 함
  • SNS 로그인 연동이 가능해야 함

의견 조율

  • JWT
    • 서버 간 세션 동기화가 필요하지 않으므로 서버 수평적 확장이 용이
    • 서버로부터 받은 토큰만을 사용하여 인증을 진행하므로, 서버 측에서 상태를 유지할 필요 없음
  • Session
    • 사용자의 인증정보를 서버에 저장하기 때문에 서버에 부하를 줄 수 있음
    • 서버 간 세션 동기화가 필요하여, 여러 서버를 사용하는 분산 시스템에서는 관리가 복잡

결정

  • 기존의 세션 방식은 확장성과 서버 부하 관리 측면에서 한계가 있어, 무상태 인증을 지원하고 분산 서비스에 더 유리한 JWT를 사용하기로 결정

3. CI/CD 자동화 배포 툴 결정

도입

  • Docker와 Github Actions를 도입

문제상황

  • 수동 배포를 하면 초기 설정은 간단하나, 지속적인 유지보수가 필요함
  • GitHub 레포지토리와 밀접하게 통합되는 것이 좋음

의견 조율

  • Jenkins or Github Actions
    • Jenkins
      • 1,800개 이상의 플러그인 제공
      • 무료로 사용 가능하며 커스터마이징 가능
      • 거의 모든 언어와 플랫폼 지원
      • 초보자에게 설정과 관리가 어려울 수 있음
      • UI가 오래돼서, 현대적인 인터페이스와는 다소 거리감이 있음
      • 유지보수와 업데이트가 필요
    • Github Actions
      • GitHub 리포지토리와 원활하게 연동
      • YAML 파일만으로 워크플로 작성 가능
      • 기본 사용량은 무료(GitHub Free Plan)
      • GitHub 외부 서비스와의 통합은 제한적
      • 복잡한 배포 환경에서는 한계

결정

  • 결론적으로, 셋업과 유지보수가 간단하면서도 안정적이고 확장 가능한 CI/CD 환경을 구축할 수 있는 Docker, Github Actions을 사용하여 DockerFile로 빌드 및 자동 배포가 되도록 결정함

4. 이미지 업로드 방법은 무엇을 사용할까?

도입

  • S3(Simple Storage Service)를 도입하여 이미지를 저장

문제상황

  • 이미지 저장 시 서버에 부하를 주지않고 서버 용량을 효율적으로 사용해야함
  • 저장공간을 자유롭게 확장할 수 있어야 함

의견 조율

  • S3사용과 로컬 스토리지에 이미지를 저장하는 방법
    • S3
      • 무제한에 가까운 저장공간을 제공
      • 트래픽 증가나 저장소 확장이 필요한 경우에도 유연하게 대처 가능
      • 글로벌 접근성
      • 하드웨어 관리 최소화
      • 비용 증가 및 네트워크에 의존성이 높음
    • 로컬 스토리지
      • 서버 내부에 저장되므로 속도가 매우 빠름
      • 비용이 절감됨
      • 저장공간이 부족해지면 디스크 추가 등의 OS에 추가 작업이 필요함
      • 서버 장애나 데이터 손실에 취약함

결정

  • S3를 사용하여 이미지 저장 시 유연한 저장공간 확장과 하드웨어 관리 최소화 결정

5. Google지도 API를 사용할때 적합한 DB는 무엇일까?

도입

  • PostgreSQL를 도입

문제상황

  • 구글 지도 API를 활용한 위치 기반 서비스 개발을 위해, 위치 데이터를 효율적으로 처리 할 수 있는 데이터 베이스가 필요

의견 조율

  • PostgreSQL + PostGIS
    • 공간 데이터를 처리하는 데 매우 강력한 기능을 제공
    • 위도/경도와 같은 공간 데이터를 효과적으로 저장하고, 거리 계산, 영역 검색, 반경 검색 등의 고급 공간 쿼리를 처리하는 데 뛰어남
    • SQL 표준을 잘 준수하는 데이터베이스로, 복잡한 쿼리와 트랜잭션 처리에서 안정적인 성능을 제공
    • 오픈소스로, 많은 커뮤니티와 다양한 문서가 있어 기술 지원을 받기 쉬움
  • MySQL
    • 설정과 사용이 비교적 간단하며, 많은 웹 애플리케이션에서 기본 데이터베이스로 널리 사용
    • 읽기 중심의 워크로드에서 높은 성능을 발휘
    • 정규화된 데이터 구조에서 성능이 좋으며, 단순한 쿼리에서 빠른 성능을 자랑
    • 공간 데이터를 처리할 수 있는 기능이 존재하지만, 공간 인덱싱은 효율적이지 않음
    • 거리 계산이나 복잡한 공간 쿼리에서는 성능이 떨어질 수 있음

결정

결론적으로, 위치 기반 서비스나 공단 데이터를 처리할 때 가장 적합한 PostgreSQL + PostGIS를 사용하기로 결정

2. 안건

아래에 자유롭게 작성!

PostGIS 추가 확장할지, 아니면 docker에서 바로 이용할지