Skip to content

HowBaChu/Backend

Repository files navigation

header


🎬 서비스 소개

소셜 네트워크 서비스(SNS)는 뉴스, 엔터테인먼트, 정치, 기술 등 다양한 주제에 관한 정보가 빠르게 공유되고 확산하는 현대의 중심입니다. 하지만 다양한 정보 소스 중에서도 특정 사이트나 플랫폼은 종종 편향된 의견에 치우치며 여론에 부정적인 영향을 미칠 수 있습니다. 이에 대한 방안으로 우리는 다양한 시각과 의견을 모으고 토론을 통해 하나의 결론에 도달하기 위해 토론 플랫폼 서비스를 개발했습니다. 서비스의 목표는 민주적인 토론을 촉진하고, 토론의 교육적인 가치를 강조하며, 다양한 시각을 수용할 수 있는, 특정 연령대를 위하지 않는 공동의 토론 플랫폼으로 발전하는 것입니다.



👨‍👨‍👧 팀원 소개

프론트 백엔드 백엔드



오현의 고명성 이희건


📚 기술 스택

항목 내용
언어
프레임워크
라이브러리
데이터베이스
도구
배포


📑 기능명세서

분류 기능 목록
USER 회원가입, 로그인, 로그아웃, 회원정보 수정, 회원탈퇴, 회원정보 조회
TOPIC 주제 조회, 주제 검색
COMMENT 댓글 조회, 댓글 작성, 댓글 수정, 댓글 삭제, 댓글 신고, 댓글 좋아요, 대댓글 작성
VOTE 투표, 투표 통계 조회


⁉️ 개발 이슈와 고민사항

1️⃣ Redis 캐싱 전략

토론 플랫폼에서 사용자가 가장 자주 사용하는 데이터를 고르자면 댓글입니다. “하우바츄”에서는 메인페이지에서 토론이 진행되기 때문에 어떤 데이터보다도 자주 읽히고 자주 쓰일 것입니다. “결과의 약 80%는 20%의 원인에서 비롯된다” 라는 파레토 법칙이 가장 잘 적용될 케이스라는 생각을 하게 되었고 캐싱을 통해 서비스의 성능을 향상하기로 하였습니다.

캐싱은 Redis 를 이용했습니다. 인메모리 기반 데이터베이스 중 가장 대중적이면서 레퍼런스가 많았고 장애 발생 대처 방안 또한 자체적으로 제공해주는 솔루션이 있었기 때문입니다. 캐싱 전략으로는 Write Back 전략과 Read Through 전략을 결합했습니다. 최신의 데이터는 캐시에만 저장하고 주기적인 데이터베이스 업데이트를 실시하며 사용자는 캐시에서만 데이터를 읽어 항상 최신의 데이터를 읽을 수 있다는 장점을 얻을 수 있었기 때문입니다.

하지만 캐싱을 진행하는 과정에서 리스트를 캐싱하는 과정에서 많은 어려움이 있었습니다. 단일 객체나 자료형에 대한 캐싱은 많은 레퍼런스가 존재했지만 리스트에 대한 캐싱은 찾아보기 어려웠습니다. 캐싱된 리스트 안의 댓글 일부가 수정될 때마다 항상 해당 캐시를 지우고 다시 캐시를 저장해야하는 문제가 있었습니다.

이에 대한 방법으로 캐시에 단일 댓글들만 저장하고 서버 안에 캐싱된 댓글을의 ID를 리스트로 관리해보았습니다. 이 방법을 사용했을 때 수정과 갱신에는 용이했지만 MySQL 데이터베이스에서 JPA 기본 메서드로 데이터를 불러올 때보다 2배 가량 느린 속도를 보였습니다.

이 과정에서 한 가지 선택을 하게 되었는데 쓰기 성능을 뒤로 미루고 읽기 성능을 향상하는 트레이드 오프를 결심하게 된 것입니다. 이유는 한 기사에서 “대부분의 애플리케이션은 읽기와 쓰기의 비율이 100:1 ~ 1000:1이다” 라는 글을 읽었기 때문입니다. 토론 플랫폼에서도 글을 작성하는 사용자도 분명 많을 것이지만 그보다는 읽기 API를 호출하는 경우가 많을 것이라 생각했고 쓰기 연산을 캐시에 저장해두었다가 주기적으로 DB에 업데이트하는 방식으로 쓰기 성능을 향상하고 읽기 성능을 더 큰 폭으로 향상하는 선택을 하였습니다.

2️⃣ 리프레쉬 토큰 탈취 시나리오 대응

회원관리는 JWT를 이용해 인증인가를 구현했습니다. 그 안에서는 회원의 정보를 가지고 직접적인 인증 인가를 처리하는 Access Token 과 이 토큰의 재발급을 위해 존재하는 Refresh Token 을 사용했습니다. 일반적으로 Access Token은 인증 인가에 직접적으로 사용되기 때문에 탈취 위험성을 고려해 30분 정도의 짧은 유효기간을 설정하고 Refresh Token은 2주 정도의 긴 유효기간을 설정합니다.

이 인증인가 과정에서 저는 “만약 Refesh Token이 탈취당한다면 어떻게 할까?” 라는 의문을 가지게 되었습니다. 공격자가 긴 유효기간을 가지는 Refresh Token 탈취에 성공한다면 지속적인 Access Token 발급을 통해서 서비스에 큰 위협이 될 것이라고 생각했습니다. 따라서 이에 대한 대응방안으로 Refresh Token Rotate 라는 기법을 도입했습니다.

Refresh Token Rotate 기법은 리프레쉬 토큰을 일회용으로 생성하여 공격자가 탈취하더라도 사용자의 로그인을 통해 공격의 지속성을 줄일 수 있습니다. 리프레쉬 토큰을 사용할 떄마다 새로운 리프레쉬 토큰을 발급하고 DB에 저장함으로써 토큰을 사용한 사용자가 가진 리프레쉬 토큰과 비교하고 이 비교가 불일치가 된다면 탈취당한 것으로 판단합니다. 이런 방식으로 공격자는 탈취한 리프레쉬 토큰을 사용할 수 없고 Access Token이 만료되면 공격을 이어갈 수 없다는 해결방안을 적용할 수 있었습니다.



🏛️ 서비스 아키텍쳐



🧬 ER 다이어그램

img.png


About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published