질문정리

프론트엔드 구현을 위해, 렌더링 방식은 어떻게 정하셨을까요? (CSR, SSR 등)

CSR을 채택했습니다. 사용자가 초기 페이지를 빠르게 확인 할 수 있기 때문에 사용자 경험이 향상됩니다. 또한 사용자 경험을 더 높이기 위해 자바 스크립트를 이용해 동적인 웹을 구축할 수 있기 때문입니다. 서버에 대한 부하를 감소 시킬 수 있을 뿐 아니라, 최신 웹 개발 트렌드가 CSR인만큼 현업에서 요구하는 기술 스택을 이용해볼 수 있었습니다.

CI/CD 구축을 하는 것을 목표로 하셨는데, 어떻게 파이프라인을 구축할 것이며, 어떤 배포 전략을 구현하실건가요? (블루/그린, 카나리 등)

프로젝트의 CI/CD 파이프라인을 구축하고자 할 때, 여러 대중적인 도구들이 있습니다. 이 중에서 Jenkins는 무료이면서 다양한 플러그인을 제공하여 사용자들에게 많은 선택의 폭을 제공해줍니다. 그러나 작은 규모의 프로젝트에서는 리소스를 낭비할 수 있고, 지라와의 연동이 불편하거나 완벽하지 않을 수 있습니다.

다음으로 Travis는 GitHub와 연동이 용이하며 빌드 과정을 시각적으로 이해하기 쉽다는 장점이 있습니다. 그러나 로컬에서 CI 환경과 동일한 빌드 환경을 제공하지 않는 단점이 있습니다.

저희는 이러한 고려 사항을 바탕으로 GitHub Actions를 선택했습니다. GitHub Actions는 복잡한 설정 없이 GitHub에서 직접 사용할 수 있으며, 다양한 언어와 프레임워크를 지원하며 젠킨스보다 실행 속도가 빠르다는 장점이 있습니다.

배포 전략은 Client-Side Rendering (CSR)을 사용하여 정적 리소스를 효율적으로 처리하기로 결정했습니다. 이를 위해 AWS S3와 Docker를 활용합니다. S3는 정적 리소스를 저장하는 데 특화되어 있고, Docker를 통해 애플리케이션을 패키지화하고 배포이미지를 생성하여 효율적으로 배포합니다. 이를 통해 초기 로딩 속도를 향상시키고, 정적 리소스를 효율적으로 관리할 수 있게 해줍니다. GitHub Actions를 사용하여 자동화된 빌드 및 배포를 설정하고, 필요한 경우 블루/그린 또는 카나리 배포 전략을 구현할 수 있습니다. 이와 함께 환경 변수와 보안에 대한 신경을 쓰며, AWS의 다양한 기능들을 활용하여 모니터링 및 로깅을 설정하여 언제든지 문제가 발생할 경우 빠르게 대응할 수 있도록 할 계획입니다.

채팅을 구현하는 방법에는 여러가지가 있는데 (WebSocket, Polling, LongPolling, SSE 등) 어떻게 구현하실 건가요?

채팅 기능구현에는 WebSocket을 사용한 STOMP 프로토콜을 사용하여 구현하였습니다. 처음 설계에는 Http Polling도 고려하였지만 Http Polling은 단방향 서비스의 한계로 메세지가 상대방 에게 전송이 되어도 상대방이 새로고침 등을 통해 수신 요청을 서버로 보내야만 그 결과를 볼수있다는 한계점이 명확하여 WebSocket방식을 채용하게 되었습니다. 또한 단순 WebSocket은 각각의 채팅방의 구분이 없기때문에 구성원 모두가 참여하는 채팅방에는 적합할지 몰라도 1대1채팅방, 클럽별 채팅방 등에는 적합하지 않았기 때문에 추가로 STOMP 프로토콜을 사용하여 우선은 1대1 채팅방을 구현하였고 향후 클럽별 단체 채팅방을 방향성으로 기능을 확장할 계획입니다.

전체 서비스 아키텍처가 어떻게 되나요? (서버, DB, 프론트 ... ) 이 외에도 서비스를 구성하는 컴포넌트가 더 있을까요?

Spring Security, Spring Data JPA 등을 이용해서 스프링부트 프로젝트를 개발했습니다. 로컬에서 개발한 프로젝트를 ec2를 통해서 배포합니다 DB는 MySQL을 사용했으며 RDS를 통해 관리합니다. 또한 Redis를 이용해서 휘발성이 강하고 먼저 조회해야할 데이터를 관리합니다. 사용자에 의해 업로드된 파일들은 S3를 이용해서 저장합니다. 프론트에서는 타임리프를 사용해서 초기데이터와 html을 넘겨주고 브라우저와 서버간의 비동기적 데이터 처리를 위해서 JavaScript를 이용한 ajax로 동적 데이터를 RestAPI를 통해 받고있습니다. 또한 이후 CI/CD구축을 위해 깃허브액션와 도커를 이용해서 CI를 구축하고 도커에 Spring과 Redis를 올리고 EC2에 올려서 CD를 구축할 예정입니다.

검색 기능을 구현해야 하는 상황인데, JPA에서 해결해야 하는 동적쿼리 문제를 어떻게 해결하실 건가요? JPQL, QueryDSL 등

우선 동적쿼리란 API 요청시 데이터가 달라지는 쿼리를 동적 쿼리라고 합니다. 검색기능을 구현하기위해서 JPQL과 QueryDSL 둘다 생각을 해보았고 QueryDSL로 결정하게됬습니다. QueryDSL로 결정한 이유는 JPQL은 문자열(String) 형태이기 때문에 개발자 의존적형태 이고 컴파일단계에서 Type-Check가 불가능하고 컴파일단계에서는 오류가 안나고 RunTime 단계에서 오류가 발견되는 단점들이 존재합니다. QueryDSL은 JPQL에 대한 보완을 위해 나온것이기 때문에 컴파일 단계에서 오류가 존재할 시 바로 확인이 가능 해서 그만큼 리스크가 줄게 되는 장점이 있습니다. 이러한 이유 때문에 QueryDSL로 결정을 하게되었습니다.

Redis와 같은 인메모리 DB에 저장해서, 빠르게 조회해야 할 정보는 없는지 고민해보세요! access Token의 만료 기한이 짧은 경우에는 Refresh Token 정보를 Redis에 저장함으로써 I/O 처리 시간을 단축시킬 수 있을 것 같은데, Redis 사용도 고려해보셨나요?

최초 설계 계획 당시에는 레디스를 통한 이메일 인증코드 저장, 로그아웃 시 Access토큰 블랙리스트 저장과 더불어서 메세지기능을 해당 레디스를 통해 구현하는 계획이었기 때문에 Redis에 너무 많은 서비스가 몰리는 것과 토큰 재발급과 로그아웃에만 관여하는 Refresh토큰을 자주 조회하는 경우는 그 빈도가 크지 않을 것이라 판단하여 MySQL을 사용하여 해당 토큰을 저장하였습니다. 구현 중 마감기한을 지키기 위해 상대적으로 어려운 Redis 메세지 기능을 MySQL로 바뀌었지만 향후에 해당 메시지 저장기능을 Redis로 이관할계획입니다.

세션 기반 인증 방식을 채택할 수도 있었는데, 토큰 기반 인증 방식을 채택하신 이유가 무엇인가요? 또 Refresh Token을 활용하여 로그아웃을 구현한다고 하셨는데, 어떤 방식으로 구현하신 것을 의미하는걸까요?

세션 기반과 토큰 기반 인증의 선택의 요지는 서버의 부담과 보안의 중요성 둘 중 어느 부분에 더 가중치를 두는냐에 따라 선택한다고 생각합니다. 이번 프로젝트에서는 개인정보 인증을 통한 개인정보 저장 등 유출 됬을때 치명적인 정보를 서버측이 수집하지 않기 때문에 상대적으로 보안의 중점을 낮게 두었습니다. 또한 공적인 첫 프로젝트 배포인 만큼 테스트 기간 중 부하의 정도를 가늠 할 수 없기 때문에 최대한 서버의 부담이 적은 토큰인증방식을 채택하였습니다.

현재 로그아웃 기능은 쿠키를 통해 전달받은 Access토큰을 Redis의 블랙리스트에 올려 해당 Access토큰을 무효화함과 동시에 로그인 시 발급과 동시에 서버에 저장된 Refresh토큰을 삭제함으로서 Access토큰이 만료됨에 따라 서버에서 재발급을 위해 요청으로 들어온 Refresh토큰과 서버에 저장된 Refresh토큰을 검증을 못하게 함으로서 로그아웃기능을 구현하였습니다.

채팅 내역은 어떤 DB에 저장하실 계획인가요? RDB와 NoSQL 중 어떤 DMBS를 쓰는 것이 좋을까요?

최초 계획에는 Redis의 장점인 빠른 조회속도를 통해 사용자의 사용편의성 증대를 위해 Redis로 계획하였지만 마감기한의 한계와 구현난이도 상승으로 RDB인 MySQL로 구현하였습니다. 하지만 채팅서비스에서 사용장의 편의성에 빠른 메세지 전송속도가 중요함과 동시에 단체 채팅방으로의 기능확장을 위해서는 기존 RDB의 한계가 명확하기 때문에 향후 Redis로 이전할 계획입니다.

일정에 맞게 개발하시는 데 있어서, 개발 프로세스를 효율화하기 위해 신경 쓰신 부분이 있을까요? (MVP, 애자일 방법론 등)

프로젝트 설계시에 MVP를 정하고 기능별로 역할을 분배하여 효율적으로 개발이 진행될 수 있도록 했습니다.코드컨벤션을 정하여 코드 수정에 소모될 시간을 줄이고, 깃플로우 전략을 통해 효율적으로 브랜치를 관리했습니다.

서비스의 확장성, 보안, 내가용성, 성능 등 비기능적 요구사항을 고려하여 설계하신 부분이 있을까요? 가령 해당 서비스의 예상 사용자 수는 몇 명으로 예상하며, 실제 해당 예상 인원이 동시 접속 했을 때 트래픽을 감당할 수 있도록 설계 되었나요?

보안에 있어서는 민감한 정보를 주고받는 서비스가 아니어서 보안보다는 성능쪽을 더 우선시 하게 되어 토큰기반인증방식을 선택했습니다. 실제 서비스 예상인원은 7명~20명 정도로 예상하고 있고, 대량의 트래픽에 대한 설계는 미흡해서 실시간 모니터링툴을 통해서 문제를 감지하고 해결하겠습니다.