BE 기술 스택 선택 이유
기술 스택 & 사용 이유 정하기
spring boot 지원 기간 : https://spring.io/projects/spring-boot#support
위의 스프링부트 버전별 지원 기간을 살펴보면 2.7은 End of Support가 2023-11-18 임을 확인할 수 있습니다.
기존에 진행중인 베이스가 없는 새 프로젝트에서 프로젝트 시작시점부터 EoS까지 5달도 안남은 버젼을 선택해야 할 이유가 없다고 판단했습니다.
후에 프로젝트를 유지하기 위해 버젼 마이그레이션을 하는 리소스를 줄이기 위하여 3.x 버젼을 선택하게 되었습니다.
위에서 선택한 Spring Boot의 버젼은 3.x 버젼부터는 java 17이상을 필수로 하여 17버젼을 사용하게 되었습니다.
- RestDocs VS Swagger 비교 분석
| Rest Docs | Swagger | |
|---|---|---|
| 장점 | - 통합 테스트를 통해 문서가 생성되어 정확성을 보장 - 사람이 이해하기 쉬운 AsciiDocs 또는 Html 형식의 문서 생성 - 서비스 코드에 영향을 주지않고 문서화 가능 |
- 지정한 URL을 자동으로 문서화하여 작성이 편리함 - 문서 내에서 API 테스트가 가능함 - 기계가 판독할 수 있는 문서화 형식(YAML,JSON)으로 문서 생성 |
| 단점 | - 테스트를 통해 예제를 직접 생성해야 하는 만큼 자동화 생산이 어려움 - 애플리케이션과 별도로 호스팅 해야 하므로 추가 설정이 필요 |
- 테스트 기반 문서가 아닌 만큼 정확성을 담보하기 어려움 - 서비스 코드에 어노테이션을 추가해야함 |
- RestDocs 선정 근거
- 팀바팀은 다음과 같은 가치를 근거로 RestDocs를 문서화 도구로 선정했습니다.
- ‘편의성’ 보다는 ‘정확성’ ‘RestDocs’는 ‘Swagger’에 비해 자동화 생산이 어려운 만큼, 학습과 적용에 상대적으로 리소스가 많이 들었습니다. 하지만 프로젝트의 기능이 다양하고 복잡한 만큼 문서의 정확성이 무엇보다 중요하다고 판단했습니다. 따라서 통합 테스트를 기반으로 문서를 생산하는 ‘RestDocs’를 적합한 문서화 도구로 선정했습니다.
- 개발자 친화적인 API 문서 팀바팀의 프로젝트에는 프론트와 백엔드 간 유기적인 협업이 중요한 요소였습니다. 가장 중요한 소통수단이 API 문서인 만큼 모든 개발자가 이해하기 쉬운 형식의 문서로 구성할 필요가 있었습니다. ‘RestDocs’는 실제 테스트 케이스를 문서로 출력하는 만큼 문서화의 맥락을 파악하기에 비교적 용이했습니다. 따라서 기계 판독에 유리한 문서 형식을 가진 ‘Swagger’에 비해 ‘RestDocs’가 더욱 적합하다고 판단했습니다.
- 간결한 서비스 코드 팀바팀은 기능 구현 만큼이나 가독성 좋은 클린 코드를 중요시 합니다. ‘RestDocs’를 활용하면 서비스 코드에 영향을 주지 않고 문서화가 가능하기 때문에, 간결하고 보기 좋은 개발 코드 작성이 가능하다고 판단했습니다.
- 팀바팀은 다음과 같은 가치를 근거로 RestDocs를 문서화 도구로 선정했습니다.
- Github Action VS Jenkins
CI, CD 툴로 Github action과 Jenkins를 두고 고민을 하였습니다.
각각의 툴을 비교 대상으로 선정한 이유는 아래와 같습니다.
- github action : git remote repository 관리 툴로 사용중인 github에서 제공하여 pr, merge등의 작업에 자동으로 연결하기 쉬움
- jenkins : 사용 레퍼런스등이 많아 참고하고 공부할 자료가 많음
우선 CI의 경우 pr요청을 트리거로 하여 자동으로 실행시키고, 다양한 action들을 사용하여 테스트 결과에 대한 리포트를 pr에 코멘트로 남겨주고, 테스트 실패시 merge를 막아주는 등 연동성이 좋기 때문에 바로 github action의 사용을 결정했습니다.
CD의 경우 아래의 이유로 Github Action을 선택하게 되었습니다.
간단한 비교 테이블
| Github Action | Jenkins | |
|---|---|---|
| 자료양 | 상대적으로 적은 커뮤니티 및 레퍼런스 | 다양한 레퍼런스 ,커뮤니티 |
| 추가기능 | yml 파일에 action 추가하여 실행 | 플러그인 설치 필요 |
| 실행 위치 | Github Runner + Selfhoste Runner |
인스턴스 |
Jenkins가 나온지 더 오래된 기술로 사용과 공부에 대한 레퍼런스 자료를 찾기 쉽지만, Github Action이 공식문서에 정리가 잘 되어있음을 확인했습니다. 추가기능을 위해서도 Github Action은 work-flow yml파일에 action을 추가만 하면 되어서 플러그인을 따로 설정해야하는 jenkins보다 적용이 쉽다고 생각했습니다.
그래서 학습곡선적인 측면에서 Github Action을 적용할 수 있을것이라 판단하였습니다.
성능적으로는 Github Action을 사용합면 ec2 에 설치한 self-hosted runner 뿐만 아니라 제공해주는 Github Runner를 사용할 수 있어, 빌드작업을 aws ec2인스턴스에서 수행할 필요가 없어, 한정된 자원만 사용해야하는 현 상황에서는 instance들을 효율적으로 사용하는데 빌드도 직접 해야하는 jenkins에 비해서 더 적절하다고 판단하였습니다.
- Logback vs Log4j2
Spring Boot에서 기본적으로 제공하는 spring-boot-starter-logging 에서는
대표적으로 다음과 같은 2가지 로깅 프레임워크를 제공하고 있습니다.
1. Logback
2. Log4j2
(Spring 공식 문서)
두 가지 중 어느 프레임워크를 사용할지 고민해봤을 때, 2가지 기준을 생각해봤습니다.
- 성능
- 다양한 레퍼런스
첫 번째로, 성능을 비교해봤을 때는 멀티 스레드 환경에서 스레드가 늘어날수록
Log4j2가 Logback보다 성능이 좋은 것을 알 수 있었습니다.
(log4j2 공식문서 성능 비교)
두 번째로, 레퍼런스를 비교했을 때 Logback이 Log4j2보다 레퍼런스가 다양한 것을 알 수 있었다.
레퍼런스가 많은 원인은 로깅 프레임워크의 발전에 있는 것 같았습니다.
로깅 프레임워크의 발전은 다음과 같습니다.
- log4j 등장
- log4j의 취약점을 보완한 logback 등장 → Spring Boot에서 기본 로깅 프레임워크로 설정
- 이후에 log4j의 취약점을 보완하고 logback을 개선한 log4j2 등장 → Spring Boot에서 기본 로깅 프레임워크에 추가
해당 과정에서, log4j2가 등장하기 전에 logback으로 개발자들이 많이 사용해왔기 때문에,
log4j2보다 logback의 레퍼런스가 훨씬 많은 것을 알 수 있었습니다.
성능이 log4j2가 좋긴 하지만, 레퍼런스가 적어서 러닝 커브가 적은 logback을 우선 사용하고,
이후에 성능이 문제가 된다면 log4j2로 마이그레이션할 예정입니다.
- CloudWatch vs 그라파나 + 프로메테우스
EC2로 배포, 운영, 개발 환경, 그리고 DB를 구성하는 상황에서 모니터링을 구성해야 하게 되었습니다.
처음에는 기존에 RDS를 사용하지 않고 EC2에서 MySQL을 설치하여 사용하는 방식처럼, 그라파나와 프로메테우스를 설치해 사용하려고 하였습니다.
다만모니터링 환경은 모니터링 대상과 독립적인 환경으로 구성되는 것이 안정적일 것이라고 판단하게 되었고, 이를 실천하려고 하였으나 기존에 사용중인 EC2 인스턴스 3대에 추가로 그라파나와 프로메테우스를 구성하고 운영하는 것은 어려움이 있었습니다.
이러한 상황 속에서 CloudWatch를 활용하면 EC2 인스턴스를 이용하는 것과 비교해 비용 측면에서 저렴하고, 환경을 구성하기가 조금 더 용이한 장점이 있음을 인지하게 되어, CloudWatch를 활용하게 되었습니다.
| EC2에 직접 구성 | CloudWatch | |
|---|---|---|
| 비용 | t3g.small 가격: 약 15$/M | CloudWatch 대시보드: 3$/M (+ 로그/지표 저장 비용 추가) |
| 학습곡선 | 직접 구성해야 되어 상대적으로 높음 | AWS에 통합되어 상대적으로 낮음 |
| 유연성과 커스터마이징 | 대부분의 구성을 할 수 있어 상대적으로 높음 | 비 AWS의 지표에 대해 상대적으로 낮음 |