글 목록 바로가기

SODA 글 목록 바로가기
Kernel360(백엔드 심화 부트캠프)에서 진행한 프로젝트
개발사와 고객사의 업무 현황을 파악할 수 있는 서비스
설계 및 트러블슈팅 내역 모음
Ontime 글 목록 바로가기
교내 개발 학회 Devkor에서 진행한 프로젝트
지각방지/시간관리 애플리케이션 Ontime
설계 및 트러블슈팅 내역 모음

SODA 주요 아티클

[4주차] 중간발표: 트러블슈팅(Service Layer 과책임) / 트러블슈팅(로깅시 양방향 순환참조) / 백엔드 아키텍쳐
·
스프링 프로젝트 - SODA
4주차에는 중간발표가 있어지금까지 진행한 사항들을 정리할 수 있는 시간이었다. 백엔드 아키텍쳐도 그려보고, 발표에서 공유할 트러블슈팅 내용 2가지를 정리하여 이를 글로 남기려고 한다. 백엔드 아키텍쳐중간발표 수준이여서 많은 내용이 담겨있지는 않다. JWT 리프레시 토큰은 스프링 애플리케이션이 떠있는 ec2서버에 도커 컨테이너로 레디스를 띄워 해당 레디스에 저장하고 있다. 조회속도도 빠르고 TTL(만료시간), 블랙리스트 관리에 용이하다. 그리고 스프링 애플리케이션과 동일한 ec2서버에 있어 캐시로서의 레디스의 효과를 크게 누릴 수 있다.기본적으로 모든 엔티티 데이터들은 RDS의 MySQL에 저장되고 있다.파일과 같은 대용량 데이터는 S3에 저장하고 있고 CDN인 CloudFront를 이용해 캐싱을 통해 조..
[3주차] MongoDB를 활용한 로깅 시스템 구축 (시스템/데이터 로그 저장)
·
스프링 프로젝트 - SODA
개요서비스를 운영하다 보면 로깅은 단순한 기능이 아니라, 장애 발생 시 문제를 빠르게 추적하고, 사용자의 행동 이력을 기록하며, 운영 품질을 높이는 데 필수적인 요소입니다.이 글에서는 다음과 같은 요구사항을 만족시키는 Spring Boot 기반 로깅 시스템 아키텍처를 구축한 경험을 정리합니다:시스템 로그: 로그 레벨별 시스템 이벤트 저장 (INFO 이상)데이터 로그: 엔티티의 생성/수정/삭제 이력 기록MongoDB 사용 이유: 유연한 스키마, 삽입 성능 우수, Spring Boot와의 쉬운 연동확장성 고려: 추후 ElasticSearch 이관 고려시스템 로그 저장: Logback + MongoDB구성 배경기존에는 시스템 로그를 콘솔 혹은 파일로 저장하는 방식이 일반적이지만 이보다는 로그를 중앙집중적으로 ..
[1주차] Jenkins 백엔드 서버 CICD 구축
·
스프링 프로젝트 - SODA
CICD 아키텍처구성한 CICD 아키텍쳐이다.Github에서 develop브랜치에 merge가 되면 Jenkins에 웹훅이 전달돼 스프링 애플리케이션이 실행된다.안정성을 위해 빌드서버와 실행서버를 분리하였으며, 보안에 민감한 환경변수는 Jenkins의 Credentials로 관리하여 빌드시에만 .env파일에 주입하는 방식으로 환경변수를 다루고 있다. 도입 배경2달 동안 SODA라는 프로젝트 관리 서비스(Jira의 B2B 버전) 개발을 하게되었고, SODA에서 BE서버 CICD 구축을 맡게되었다.이전 프로젝트에서 Github Action(workflow)으로 CICD를 구축했던 경험이 있어 다른 방법으로 CICD를 구축해보고 싶었다.여러 방법을 고민하다 실무에서 가장 많이 쓰인다는 Jenkins를 이용해 ..

Ontime 주요 아티클

[성능개선] 부하테스트 및 API 응답속도 개선
·
스프링 프로젝트 - Ontime
도입25년 2월 교내 개발학회 컨퍼런스에서 부하테스트를 하고 병목지점을 분석한 뒤 API의 응답속도를 개선하는 내용을 바탕으로 발표를 했었습니다.이 발표 내용을 공유하려합니다. 부하테스트 진행 배경이 때 당시 MVP 배포를 목적으로 하고 있었고 백엔드는 기능구현은 완료된 상태였습니다.배포 이전에 유저들이 사용가능한 수준으로 동작할지에 대한 고민과 우려가 생겨 이에 대한 테스트 즉, 부하테스트를 진행하고 병목지점을 분석한 뒤 이에 대한 성능을 개선하는 것의 필요성을 느껴 부하테스트를 진행했었습니다.일반적으로 부하테스트는 실제 API 호출 비율별로 분배해서 트래픽을 쏘는 것으로 알고있으나 이 때 당시 어플리케이션이 출시 전이여서 호출비율을 알지 못하고, 부하테스트에 대한 지식이 부족하였습니다. 따라서 보다..
[트러블슈팅] 유저계정삭제 API 호출시 외래키 제약조건으로 인한 오류 해결 (500 Internel 서버 에러)
·
스프링 프로젝트 - Ontime
얼마 전 유저 계정삭제 API에서 500 Internel Server Error가 발생한다는 제보가 FE 측에서 들어왔다. 로그를 확인해 보니 User 데이터 삭제 시 Preparation_User 테이블 데이터가 같이 삭제되는데(∵ @OnDelete롬복의 Cascade옵션) 이때 Preparation_User의 next_preparation_id 필드가 다른 Preparation_User를 참조하고 있어 외래키 제약조건으로 인해 삭제가 안 되는 현상이었다. 당시에는 FE에서 급하게 요청을 해 시급히 해결해야 하는 상황이었기 때문에, 아래 사진처럼 userRepository에서 user를 삭제하기 전에 preparationUserRepository에서 문제가 되는 필드인, 해당 유저의 Preparatio..
무슨 일이든 과정을 즐기자 😀
준범's BE Development Stroy