BE 사용 기술 스택 및 선택 이유
Java 21
Java 17, Java 21
Java의 버전은 크게 LTS 버전과 non-LTS 버전으로 나뉘는데, 둘은 지원 기간에 차이가 있고 이는 안정성의 차이로 이어집니다. 실무에서는 LTS 버전을 선호합니다.
LTS 버전 중 8과 11을 고려하지 않은 이유는 현재 지원이 계속되는 중인 Spring Boot 3 를 사용하기 위해서는 17 이상을 요구하기 때문입니다.
또한, 팀원의 모든 개발자들이 Java 17 이상의 문법에 익숙하다는 점도 고려해 Java 17과 Java 21을 최종 후보로 선정했습니다.
Java 17과 Java 21의 가장 두각된 차이는 21에서 가상 스레드 기술을 적용해 I/O 동시성이 크게 향상되었다는 점입니다.
다만, 유의미한 성능 향상을 위해선 이런 기술을 더 명확히 이해하고 적소에 적용해야 한다는 단점이 있습니다. 그러나 Spring 진영에서 어플리케이션 개발자가 이를 신경쓰지 않아도 쉽게 가상 스레드를 사용할 수 있도록 지원합니다. 따라서, 가상 스레드에 대한 명확한 이해 없이 간단한 설정만으로 그 장점을 사용할 수 있을 것이라 판단했습니다.
Java 8 로 변경될 때 처럼 큰 변경이 있지 않아 Java 17의 스타일을 Java 21에서도 그대로 유지할 수 있습니다.
Spring Boot 3.2.7
번거로운 스프링 기술 설정과 임베디드 톰캣을 사용하기 위해 스프링 부트를 사용하기로 결정했습니다.
Spring Boot의 여러 버전 중 현재도 지원중인 버전은 3.2.x 와 3.3.x 입니다. 따라서 두 버전 중 하나를 고르는 것이 합당하다 판단했습니다.
두 버전 중 3.3.x 는 2024년 5월 23일에 첫 버전이 출시되었기 때문에 아직 채 2달이 되지 않았습니다. 아직 여러 버그가 남아있을 가능성이 상대적으로 더 높을 것이라 판단했습니다. 반면, 3.3.x 에서 새로 추가된 기능 중 우리에게 꼭 필요하다고 생각되는 기능은 없었습니다.
3.2.x 는 레벨 2 미션에서 사용한 버전이고, RestClient 등 팀원 모두에게 익숙한 기능을 제공하는 것도 선택의 근거가 되었습니다.
따라서 3.2.x 중 현 시점 가장 최신 버전인 3.2.7을 선택했습니다.
Nginx
프론트엔드와의 연동 과정에서 SameSite 쿠키 관련 문제가 발생했고 이를 해결하기 위해 프론트엔드 서버와 백엔드 서버에 도메인 연결과 HTTPS 적용이 필요했습니다. 그리고 이 중 HTTPS 적용과정을 손쉽게 하기 위해서 Nginx를 도입하기로 했습니다.
브라우저에서 경고를 표시하지 않는 HTTPS를 적용하기 위해서는 인증된 CA에서 발급받은 인증서가 필요합니다. 이를 해주는 많은 서비스들이 있지만, 유료 서비스가 많습니다. Let's Encrypt사에서는 무료로 인증서를 발급해주지만, 3개월의 짧은 유효기간으로 제공해줍니다. 따라서, 3개월에 한번씩 인증서를 갱신해야 합니다.
만약, Spring Boot 에서 직접 HTTPS 설정을 해준다면, 내장 톰캣이 실행될 때 관련 설정을 하게 되므로 인증서 갱신시 Spring Boot 어플리케이션을 재시작해야 합니다. 따라서 수 초 이상의 중단 시간이 발생합니다. Nginx는 특유의 아키텍처 덕분에 빠르게 설정을 적용하는 것이 가능해 인증서가 갱신된다면 이를 1초 남짓의 시간에 적용할 수 있습니다. 따라서 Spring Boot 앞단에 Nginx를 추가해 HTTPS 적용을 담당하게 했습니다.
Logback
-
Spring Boot와의 호환성:
- Spring Boot에서 별도의 의존성 추가 없이 기본적으로 사용할 수 있어 설정과 관리가 간편합니다.
-
성능 비교:
- 성능 면에서 Logback은 log4j2에 비해 다소 뒤처질 수 있지만, 프로젝트 초기 단계에서는 이러한 성능 차이가 크지 않을 것으로 예상됩니다.
-
러닝 커브:
- Logback은 log4j2에 비해 레퍼런스가 많아 학습하기 쉬워 팀의 러닝 커브를 줄이고, 문제 해결 시 보다 신속한 대응을 가능하게 합니다.
Loki + Prometheus + Grafana
-
레퍼런스의 풍부함:
- 이 조합은 많은 레퍼런스가 존재하여, 설정과 문제 해결 과정에서 도움이 되는 자료를 쉽게 찾을 수 있습니다.
-
Loki: 로그 관리
- 효율적인 인덱싱: Loki는 메타정보만 인덱싱하는 방식으로, 전체 내용을 인덱싱하는 Elasticsearch보다 더 간결하고 비용 효율적입니다.
- Prometheus와의 통합: Loki는 Prometheus와 동일한 레이블을 사용해 메트릭과 로그의 원활한 전환이 가능합니다.
-
Prometheus: 메트릭 관리
- 시스템 성능 측정: Prometheus는 시스템 성능을 모니터링하고, 데이터 수집을 위한 퓨어 풀 모델을 사용합니다. 이 모델은 클라이언트의 부하를 줄이고, 네트워크 문제 발생 시에도 데이터 수집의 안정성을 유지합니다.
-
Grafana: 시각화
- 데이터 시각화: Grafana는 수집된 로그와 메트릭 데이터를 시각화하여, 시스템의 상태를 한눈에 파악할 수 있도록 지원합니다. 이는 문제 탐지와 대응을 신속하게 할 수 있게 합니다.
MySQL 8.0
데벨업(devel-up)은 사용자, 게시글, 댓글 등 명확한 관계를 가진 정형 데이터를 다루는 게시판 기반의 서비스입니다. 이러한 데이터 구조에서는 관계형 데이터베이스(RDBMS)가 적합합니다. NoSQL 데이터베이스는 비정형 데이터나 스키마가 자주 변경되는 경우 유리하지만, 현재 저희 프로젝트에서는 이와 같은 특성이 필요하지 않으므로 관계형 데이터베이스(RDBMS)를 선택하였습니다.
오라클과 MSSQL은 기능과 안정성 면에서 우수하지만, 높은 라이센스 비용이 단점입니다. 현재 비용 효율성이 중요한 상황이기 때문에 비용 부담이 없는 오픈 소스 데이터베이스를 우선적으로 고려했습니다.
1) MySQL
-
성능 및 속도
- 데벨업은 게시판 데이터의 읽기 작업이 많습니다. MySQL은 읽기 성능이 뛰어나며, 특히 웹 애플리케이션에서 많은 읽기 작업을 효율적으로 처리합니다.
-
기능
- MySQL은 기본적인 데이터베이스 기능을 제공하며, 복잡한 기능이 필요하지 않은 애플리케이션에 적합합니다. 데벨업은 현재 복잡성이 낮은 테이블 구조를 가지고 있고, 복잡한 쿼리가 필요하지 않은 간단한 데이터 처리 구조를 가지고 있습니다.
-
커뮤니티 및 자료
- MySQL은 규모가 큰 커뮤니티를 가지고 있으며, 학습 자료가 풍부합니다. 이는 팀원들이 관련 문제를 해결하고 학습하는 데 있어 큰 도움이 됩니다.
2) MariaDB
-
관계 및 호환성
- MariaDB는 MySQL에서 파생된 오픈 소스 데이터베이스로, MySQL과 유사한 명령어와 기능을 제공합니다. MySQL과의 호환성을 유지하면서도 성능 개선과 새로운 스토리지 엔진을 도입했습니다.
-
커뮤니티 및 자료
- MariaDB의 커뮤니티도 활발하지만, MySQL에 비해 자료가 상대적으로 적습니다.
3) PostgreSQL
-
성능 및 기능성
- PostgreSQL은 복잡한 쿼리 처리와 대량의 쓰기 작업에 뛰어납니다. 또한, JSON 데이터 처리, Window Functions, Common Table Expressions(CTEs) 등 고급 기능을 지원합니다.
-
복잡성 및 러닝 커브
- PostgreSQL은 고급 기능이 많아 러닝 커브가 높으며, 설정과 관리가 보다 복잡합니다. 하지만 현재 데벨업에서 필요로 하는 기능은 상대적으로 단순하기 때문에 PostgreSQL의 고급 기능이 필요하지 않습니다.
-
커뮤니티 및 자료
- PostgreSQL은 활발한 커뮤니티를 가지고 있지만, MySQL에 비해 기술적인 자료가 상대적으로 복잡합니다.
EC2 인스턴스
-
장점:
- 직접 제어: 데이터베이스 엔진 설치, 버전 관리, 데이터 백업 등 모든 작업을 직접 관리할 수 있습니다.
- 비용 효율성: 유지보수에 추가 비용이 발생할 수 있지만, RDS에 비해 초기 비용이 낮습니다.
-
단점:
- 유지보수 부담: 데이터베이스의 모든 관리 작업을 직접해야 합니다.
- 고가용성 및 스케일링: RDS와 같은 자동화된 고가용성 기능을 제공하지 않으므로, 이를 직접 설정하고 관리해야 합니다.
위와 같이 데벨업의 요구사항을 종합적으로 고려한 결과, MySQL 8.0을 최종적으로 선택하였습니다. 선택 이유는 다음과 같습니다.
-
성능
- MySQL은 많은 읽기 작업을 효율적으로 처리하는데, 게시판 데이터의 읽기 작업이 많은 데벨업에 적합하다고 생각했습니다.
-
학습
- 상대적으로 풍부한 학습 자료와 활발한 커뮤니티가 있어 학습과 문제 해결이 용이합니다.
-
비용
- EC2 인스턴스를 통해 직접 관리하면서도 비용을 절감할 수 있습니다. RDS와 비교하여 초기 비용이 낮습니다.