Skip to content

test

Jump to bottom
Jsim6342 edited this page Nov 12, 2021 · 3 revisions
💡 전체적으로 가장 익숙한 툴을 우선적으로하여 활용 기술을 선정하였다.

버전관리

버전관리 시스템

  • Git
  • SVN
  • Mercurial

Git 웹 호스팅 서비스

이슈 관리 도구(이슈 트래커)

Git GUI

버전관리

  • Git: Git은 버전을 스냅샷으로 관리하여 성능 이슈가 적고, 브랜치를 도입할 수 있다. 또한 다른 버전관리 시스템에 비해 가장 익숙하다는 점에서 Git을 선택하게 되었다.
  • GitHub: GitHub는 가장 대중적인 웹 호스팅 서비스로 현재 내게 가장 익숙한 서비스이다. 또한, GitHub 자체적으로 내장되어 있는 이슈 트래커를 포함한 풍부한 서비스를 활용할 수 있다고 판단했다.
  • GitHub Issues & Projects: GitHub 자체 내에서 활용할 수 있다는 점이 가장 크다. 각 이슈에 대해 작업자를 assign 할 수 있으며, 커뮤니케이션과 라벨 활용, 이슈 상태 등을 구분하는 등 충분한 기능을 할용할 수 있다고 판단했다.

ComputeEngine 결정 & 서버 배포 및 배포 자동화

컴퓨팅 파워 출처

  • PC
  • 서버용 하드웨어를 구입해 홈서버 운영
  • 서버호스팅
  • 클라우드 플랫폼

클라우드 플랫폼

  • AWS(Amazon Web Service)
  • GCP(Google Cloud Platform)
  • Microsoft Azure

컴퓨팅 엔진(AWS 기준)

  • EC2(Elastic Compute Cloud)
  • Beanstalk
  • ECS(Elastic Container Service)
  • ECS+Fargate
  • Lightsail
  • Lambda

배포 자동화 서비스

  • Travis-CI
  • CircleCI
  • Amazon CodeBuild와 CodeDeploy를 함께 사용
  • Amazon CodeBuild만 사용

컴퓨팅 엔진 결정 & 서버 배포

  • 클라우드 플랫폼: 현재 서비스를 만드는 단계에서 가장 유동적으로 서버 환경을 설정할 수 있으며, 비용 또한 상황에 맞게 선택하여 서버를 구축할 수 있다는 점에서 클라우드 플랫폼을 선택하였다.
  • AWS: 대중적이며 평소에 가장 자주 사용하고 익숙한 AWS 플랫폼을 활용하였다.
  • EC2: 현재 가장 익숙한 컴퓨팅 엔진이다. 처음 데모 버전 서버를 구축하고 테스트 한다는 점에서는 충분하다고 판단하였다.

API 설계 원칙, 문서화 방식, 직렬화 포맷 ****

API 설계 원칙

  • HTTP API
  • REST API
  • GraphQL

API 문서화 방식

  • Excel
  • Swagger
  • 소스코드에 문서 임베딩
  • ReDoc을 직접 관리
  • ReDoc을 GitHub Pages(github.io)에서 관리
  • Slate를 직접 관리
  • Slate를 GitHub Pages(github.io)에서 관리
  • GitBook

직렬화 포맷

JSON key 네이밍 룰

  • 신경쓰지 않는다. ex) 'signindate'
  • 공백으로 분리한다. ex) 'signin date'
  • 카멜 케이스(Camel Case)를 사용한다. ex) 'signinDate'
  • 파스칼 케이스(Pascal Case)를 사용한다. ex) 'SigninDate'
  • 스네이크 케이스(Snake Case)를 사용한다. ex) 'signin_date'

API 설계 원칙, 문서화 방식, 직렬화 포맷

  • HTTP API: 여기서 의미하는 HTTP API는 대중적으로 사용되는 REST API의 의미이다. 실제 REST API를 구현하기 위해서는 HATEOAS 원칙을 지켜야하기 때문에 HTTP API로도 충분하다고 판단되었다.
  • Excel, SwaggerHub: 가장 익숙한 툴인 Excel을 선택하였다. 상시 업데이트를 위해 Google Sheets를 활용할 예정이다. 또한, 엑셀만으로 API를 명세하는 단점을 보완하고자 Swagger를 활용하고자 한다.
  • JSON: 가장 익숙한 포맷이며, 타 직렬화 포맷에 비해 경량화되고, 가독성도 좋다. 결정적으로 협엽하는 프론트엔드 분도 JSON 포맷에 익숙한 점에서 선택하게 되었다.
  • 카멜 케이스: Java 네이밍 컨벤션에 가장 적합하여 타 네이밍에 비해 사용하기 편리하며, 프론트 개발자와 상의 하에 결정하였다.

사용자 인증 방식

인증 정보의 위치

  • request body
  • 요청의 query parameter
  • Cookie 헤더
  • Authorization 헤더

인증 스키마

  • Basic
  • [비표준] OAuth 1.0a를 사용하는 Bearer
  • OAuth 2.0을 사용하는 Bearer
  • [비표준] JWT, 또는 JWT를 사용하는 Bearer
  • Digest
  • HOBA

사용자 인증 방식

  • Authorization 헤더: 인증 데이터는 메타 데이터 성격이 강해 request body와 어울리지 않으며, 쿼리 파라미터의 경우 보안상 좋지 않다. 또한, 쿠키는 앱 개발 부분에서는 클라이언트가 쿠키 저장소를 따로 구현해야하기 때문에 Authorization 헤더가 가장 적합하다고 판단했다.
  • JWT: 가장 익숙한 방법이며, 쉽게 전달될 수 있다. 서비스 내에서 로그인 유지 정보에 대한 필요성이 없으며, 세션에 대한 관리 부분과 서버 자원을 절약할 수 있다는 점에서 선택하였다.

데이터베이스 선정

데이터베이스

  • RDB
  • NoSQL

DB 호스팅 위치

  • EC2
  • RDS(Relational Database Service)

데이터베이스 엔진

  • Aurora
  • MySQL
  • MariaDB
  • PostgreSQL
  • Oracle
  • SQL Server

MySQL Driver(클라이언트)

  • HeidlSQL
  • MySQL Workbench
  • DataGrip

데이터베이스 선정

  • RDB: 가장 익숙한 RDB를 택하였다. 구현하려는 서비스 특성상 트래픽이 집중되는 서비스 보다는 안정적인 서비스로 가는 것이 좋을 것이라고 판단하여 RDB가 더 적합하다고 판단했다.
  • RDS: EC2에 호스팅할 경우, 서버 문제가 DB까지 영향을 미칠 수 있으며, 무료로 제공되는 EC2의 성능을 고려했을 때 분리하는 것이 좋다고 판단되었다. 따라서, DB를 서버와 분리한 RDS를 활용하는게 적합하다고 판단했다.
  • MySQL: 가장 많이 사용했으며, 익숙한 데이터베이스 엔진이기에 선택하였다.
  • DataGrip: 데이터 추출과 저장이 간편하며, 쿼리 및 데이터 임시 저장 기능, 자동 완성 기능 등 편리한 기능을 많이 갖추고 있다.

기술 스택 정의 & 의존성 관리도구

프로그래밍 언어

  • Python
  • Scala
  • Java
  • Go
  • Node.js

프레임워크

  • Spring Boot
  • Spirng Web
  • Spring Security
  • Spring Data
  • Spring Batch
  • Spring Cloud

DB 접근 기술

  • JDBC
  • JdbcTemplate
  • Mybatis
  • JPA
  • 스프링 데이터 JPA
  • QueryDSL

의존성 관리 도구

  • .pip
  • npm
  • yarn
  • gem
  • maven
  • gradle

라이브러리

  • Lombok
  • Springfox Boot Starter
  • Bean Validation
  • Thymeleaf

기술 스택 정의 & 의존성 관리도구

  • Java: 가장 익숙한 언어이다.
  • Spring Boot: 기본 Spring에 비해 라이브러리 관리, 설정의 자동화, 라이브러리 버전관리 자동화, 테스트 환경과 내장 Tomcat 등 환경 설정 부분에서 편리한 부분이 많기 때문에 선택하게 되었다.
  • JPA: RDB에 사용하기 적합하며, 데이터를 객체와 매핑하여 다룰 수 있다는 점에서 효율적으로 관리할 수 있다고 생각함. 구현할 서비스가 통계 처리와 같은 복잡한 로직이 필요한 서비스가 아니기 때문에 JPA 내에서 충분히 구현이 가능할 수 있다고 생각하여, 생산성과 유지보수 등을 살리고자 했다.
  • QueryDSL: JPA만으로는 다루기 힘든 동적 쿼리를 함께 다루고자 사용할 예정이다.
  • gradle: Java에 맞는 의존성 관리 도구이며, maven에 비해 관리가 쉽고, 가독성이 좋다고 판단. 결정적으로 가장 익숙한 의존성 관리 도구이다.
  • Lombok: 보다 편리한 어노테이션 관리를 하기 위함.
  • Springfox Boot Starter: Swagger를 통한 API 문서 관리, 테스트를 적용하기 위해 사용.
  • Bean Validation: 검증 처리를 가장 생산성 있게, 효율적으로 할 수 있다고 판단. 검증부를 DTO에서 처리하기 때문에 검증 로직을 제외한 클린코드를 만들 수 있다고 생각된다.

어플리케이션 레벨 의사결정

시각 데이터 저장 방식

  • Unix time
  • Asia/Seoul 기준의 시각 문자열
  • UTC 기준의 시각 문자열
  • ISO 8601 format 문자열

시각 데이터 표현 방식

  • YYYY-MM-DD HH:mm:ss.SSS
  • Unix time
  • YY-MM-DD HH:mm:ss.SSS
  • ISO 8601 format(YYYY-MM-DDTHH:mm:ss.SSS±hh:mm)
  • RFC 3339 format

시각 데이터 의사결정

  • 시각 데이터 저장: UTC가 국제 표준시로서 기준점이 되기도 하며, 시각을 다루는 지역이 기준이 된다는 점에서 local timezone에 의존하며 생길 수 있는 실수를 방어하기에 좋다. 또한 데이터 저장의 경우에는 일반적인 시간 데이터에 UTC를 기준으로 한 차이값 데이터가 더해진 ISO 8601 표준을 사용하기에는 과한 부분이 있다고 판단했다.
  • 시각 데이터 표현: 클라이언트와 상의 후, 저장된 UTC를 형태 그대로 활용할 수 있는 YYYY-MM-DD-HH:mm:ss.SSS 표현 방식을 선택했다.

세부정보는 사이드바를 이용해주세요👀 ➡️➡️

🏠 Home

📅 Planning

📑 Dev Document

👨‍💻 Develop

👨‍🏫 TIL

📚 Ground Rule

Clone this wiki locally