[FISTUDY] 서포트립에서의 기술 스택 선정 이유 - 백엔드

이번에는 백엔드 기술 스택 선정 이유에 대해 이야기해보겠습니다.

 

저번 글에서 잠깐 이야기했지만, 백엔드 기술 스택의 경우 프로젝트 요구 사항에 의해 Java와 Spring Boot를 사용했어야만 했습니다.

서포트립 백엔드 시스템 아키텍처

 

그리고 위 시스템 아키텍쳐를 보면 마이데이터 서버를 별도로 구축한 것을 확인할 수 있습니다. 실제 마이데이터 서버를 사용하기 위해선 마이데이터 사업자와의 계약이 필요하므로 저희 프로젝트에선 사용할 수 없었습니다. 따라서 저희는 마이데이터 데이터셋을 구성하거나, 마이데이터 서버를 흉내내는 별도의 서버를 구축하는 방법이 있었습니다.

저희 팀은 회의 결과 조금 더 현실적으로 서비스를 만들기 위해 마이데이터 API 명세에 맞는 별도의 마이데이터 서버를 구축했습니다.

마이데이터 서버의 빠른 구축을 위해 서포트립 핵심 API 서버에 사용했던 기술 스택들(Java, Spring Boot)을 그대로 사용해 구축하였습니다.

 

백엔드 기술 스택들

다음은 현재 백엔드에서 사용된 기술 스택들입니다.

서포트립 백엔드 기술 스택

 

JPA를 선택한 이유

JPA는 필수 요구 사항이 아니었습니다. 따라서 저희는 JPA와 MyBatis를 고려하였습니다.

	JPA	MyBatis
장점	- 객체와 RDB 매핑을 자동화하여 개발 생산성 향상 - 상대적으로 적은 SQL 쿼리 작성 - 트랜잭션 관리, 캐싱 등 다양한 기능 제공 - 많은 기업들에서 사용되므로 취업에 유리	- 학습 시간이 짧고, 코드가 간결 - 복잡한 Join, 동적 쿼리 등 SQL 쿼리 작성 용이
단점	- 학습 시간이 오래 걸림 - 잘못된 연관 관계 설계시 성능 저하 발생 (N+1 문제)	- 스키마 변경시 SQL 쿼리 직접 수정 필요 - 복잡한 쿼리의 가독성 저하

 

최종적으로 저희 팀은 수업 시간에 이미 JPA 기본을 학습했다는 점, 많은 기업들에서 JPA를 사용하므로 취업에 유리해진다는 점을 이유로 JPA를 선택했습니다.

 

OAuth2.0을 선택한 이유

카카오 소셜 로그인을 구현하기 위해서는 OAuth2.0이 필수였습니다.

 

JWT를 선택한 이유

저희 팀이 인증을 구현할 때 세션 방식과 JWT 방식을 고려했습니다.

 

	세션 방식	JWT 방식
장점	- 전달되는 SessionID는 아무런 의미가 없으므로, 탈취되더라도 세션이 종료되었다면 할 수 있는 것이 없음 (보안이 좋음) - 만약 서버에서 비정상적 접근을 탐지했을 경우 해당 세션을 종료하여 실시간으로 접근 차단 가능 - 상대적으로 구현이 쉬움	- 디지털 서명으로 JWT의 무결성을 보장 - 클라이언트쪽에서 JWT에 세션 정보를 저장하기 때문에 상대적으로 비용을 적게 사용함 - Scale Out에 적합
단점	- 서버쪽에서 세션 정보를 저장해야 하므로 비용 증가 및 사용자가 증가함에 따라 부하가 높아짐 - SPOF 등 Scale Out에서 고려할 사항이 있음	- JWT에 사용자 정보가 포함되므로, 탈취된다면 상대적으로 보안에 취약함 - 한 번 발급된 JWT는 수정 및 폐기가 불가능 - 보통 보안을 위해 Access Token, Refresh Token 방식으로 구현하기 때문에, 상대적으로 구현이 복잡함

 

저희 팀 모두 교육 과정에서 Spring Security를 이용하여 세션 방식 인증을 구현해본 경험이 있었고, 저의 경우에는 이전 프로젝트들에서 세션 인증을 다수 구현해본 경험이 있었기 때문에 학습을 위해서 JWT 방식으로 인증을 구현하기로 결정하였습니다.

 

Spring Security를 선택한 이유

저희 프로젝트 요구 사항에 따르면 사용자와 관리자의 인가 구현이 필요했습니다. 저희는 스프링 인터셉터를 이용해 직접 구현하거나, Spring Security를 사용하는 방법을 고려하였습니다.

 

최종적으로는 신속한 구현과 학습을 위해 Spring Security를 사용해 구현하기로 결정하였습니다. 이미 JWT를 이용한 인증 구현이라는 요구 사항이 있는 상황에서, 이와 관련하여 인가를 구현하기 위해서는 Spring Security를 사용하는 것이 합리적이기 때문입니다. 따라서 Spring Security를 이용하여 Role 기반으로 사용자와 관리자 인가를 구현하였습니다.

 

Resilience4j를 선택한 이유

저희 서포트립 서버에서는 환전을 위해 외부 환율 정보 시스템로부터 환율 정보를 가져오고 있습니다. 현재는 마이데이터 서버를 자체 구축하였지만, 실제 서비스라면 여러 마이데이터 사업자로부터 정보들을 가져와야 합니다. 즉, 외부 시스템에 장애가 발생하였을때 저희 서비스에 크게 영향을 미칩니다. 특히 환율 정보 시스템에 장애가 발생한다면, 핵심 기능인 자동 환전이 불가하므로 사실상 전체 시스템 장애가 발생한 것으로 간주할 수 있습니다.

 

따라서 저희 팀은 외부 시스템간 통신하는 과정에 서킷 브레이커를 적용하여 더 안정적인 서비스를 구현하고자 노력했습니다.

 

---

서킷 브레이커에 대해 간단하게 설명해보자면, 외부 시스템간 통신에서 장애 발생시 마치 전기 회로 차단기처럼 작동하여 외부 시스템으로 가는 트래픽을 막고 선제적으로 에러를 발생시키는 장치입니다. 선제적으로 에러를 발생시키는 것에 의문이 생길 수도 있지만, 장애 전파 방지, 자원 보호, 응답 시간 향상 등 다양한 이점을 얻을 수 있습니다. 또한 단기간에 대규모 트래픽으로 인해 외부 시스템에 일시적으로 장애가 발생한 경우에 잠시 트래픽을 차단하면 자가 회복이 가능할 수 있습니다. 이때 재시도 등으로 계속 트래픽을 보내게 된다면 외부 시스템에 부하가 커져 더 큰 장애로 이어질 수 있습니다. 이때 서킷 브레이커를 사용한다면 조금 더 안정적인 서비스가 가능합니다.

서킷 브레이커 상태전이도

 

서킷 브레이커는 CLOSED, OPEN, HALF OPEN으로 총 3개의 상태가 존재합니다. 기본 CLOSED 상태에서 요청에 대한 에러율이 설정된 임계값을 넘어서면 OPEN으로 바뀌어 외부 요청시 에러를 발생시킵니다. OPEN 상태에서 일정 시간 이후 HALF OPEN 상태로 바뀌어 시스템에 요청을 보내며, 해당 요청 결과에 따라 OPEN과 CLOSED로 상태가 변경됩니다.

---

 

검색해보니 Java에서 Hystrix와 Resilience4j를 가장 많이 사용해 서킷 브레이커를 구현한다는 것을 알게되었습니다. Hystrix의 github 주소로 가보니 오픈소스 라이프사이클(oss lifecycle)에 maintenance로 되어있으며, 마지막 커밋이 작년으로 나와있었습니다.

Hystrix Github README

 

하지만 resilience4j는 당장 4일전에도 커밋이 존재하는 등 오픈 소스 프로젝트가 활성화되어있는 모습을 볼 수 있었습니다. 오픈소스에서 활성화 여부가 추후 지속적이고 신속한 업데이트, 커뮤니티 지원, 풍부한 리소스 등과 깊은 연관성이 있기 때문에 resilience4j로 기울었습니다. 그리고 검색시 많은 사람들이 다양한 이유들을 들어 Hystrix보다는 resilience4j를 추천하는 것을 보았고 최종적으로 resilience4j를 선택하였습니다.

 

결론

저희 팀은 기술 스택을 선정할때 왜 이 기술을 선택해야하는가에 대해 함께 고민을 하고 선택해왔고, 그로 인해 현 상황에서 최선의 서비스를 구현해왔다고 생각합니다.