행복한코딩생활

문제AWS 프리 티어 환경에서 EC2 인스턴스(기본 1GB 메모리)를 사용 중, 스프링부트 애플리케이션 실행 시 메모리 부족으로 인해 성능이 저하되거나 애플리케이션이 비정상적으로 종료되는 문제가 발생.해결 방안 분석문제를 해결하기 위해 두 가지 방안을 고려:Swap 메모리 설정장점:비용 추가 없이 현재 인스턴스에서 메모리 부족 문제를 완화할 수 있음.설정이 간단하고 빠르게 적용 가능.단점:디스크 기반으로 메모리를 확장하므로 I/O 성능 저하 발생 가능.높은 트래픽 상황에서는 여전히 불안정할 수 있음.설정 방법인스턴스 업그레이드장점:CPU와 메모리 모두 확장 가능, 애플리케이션의 안정성과 성능을 보장.Swap 설정 없이 물리적 리소스 증가로 I/O 병목 문제 해결.단점:프리 티어의 무료 범위를 벗어나 추가..

배경현재 프로젝트에서는 UserVO를 세션에서 가져와 권한을 확인하는 로직이 컨트롤러 메서드마다 반복되고 있습니다. 이러한 중복은 작동에는 문제가 없지만, 유지보수성과 코드의 가독성을 저하시킬 수 있습니다. 특히, 반복된 로직을 수정해야 하는 경우 모든 메서드를 업데이트해야 하며, 이는 일관성 유지에 어려움을 초래할 수 있습니다.따라서, 권한 확인 로직의 중복을 제거하고, 재사용성과 유지보수성을 높이는 방향으로 개선을 진행하려 합니다.개선 방향1. 메서드 추출 방식권한 확인 로직을 별도 메서드로 분리하여 각 컨트롤러 메서드에서 이를 호출하도록 단순화할 수 있습니다.구현private boolean isAdmin(HttpServletRequest request) { UserVO userVO = (Use..

문제 상황단일 Redis 인스턴스 사용 시 다음과 같은 문제가 발생할 위험이 있었습니다:Redis 장애 시 데이터 유실 위험단일 Redis 인스턴스가 장애를 겪으면 캐시 데이터가 모두 유실될 위험이 있었습니다.조회수나 포인트 랭킹 같은 실시간 데이터가 손실되면, 시스템 신뢰도가 크게 떨어질 가능성이 있었습니다.고가용성 부족단일 Redis는 장애 복구 기능이 없어, 서비스 중단이 발생할 수 있었습니다.실시간 처리가 중요한 우리 프로젝트 특성상, Redis 장애 시에도 서비스가 안정적으로 유지되어야 했습니다.도입 이유 및 해결 방안Redis Sentinel은 Redis의 고가용성을 보장하며, 장애 발생 시에도 데이터 유실을 방지하고 서비스의 연속성을 유지할 수 있었습니다.자동 장애 조치Redis Sentin..

문제 상황게시물 조회수와 포인트 랭킹 등과 같은, 데이터를 실시간으로 정확하게 처리해야 하는 것이 중요한 상황에서, 기존 시스템은 다음과 같은 문제(한계)를 가지고 있었습니다:DB 부하 및 응답 지연게시물 조회수와 포인트 랭킹(예: 실시간 유저 랭킹, 지난달 유저 랭킹 등) 등을 조회할 때 데이터베이스 조회가 느려졌습니다. 조회수가 많은 인기 게시물에서는 동시 조회 요청이 많이 쏟아지면서 DB에 과도한 부하가 발생했습니다.실시간 데이터 처리의 한계조회수를 DB에 저장하는 방식으로는 비정상적인 조회수 증가(어뷰징)를 실시간으로 확인하거나 조치하는 것이 어려웠습니다.Refresh Token 관리의 비효율성DB로 관리할 경우, 불필요한 부하와 비효율성이 발생하는, 사용자 인증을 위한 Refresh Token을..

문제 상황프로젝트에서 Docker 이미지를 효율적으로 저장하고 배포할 레지스트리가 필요했습니다. 이를 통해 배포 프로세스를 표준화하고 관리 편의성을 확보하고자 했습니다. 레지스트리를 선택하는 과정에서, AWS ECR과 Docker Hub 중 어떤 것을 사용할지를 검토하게 되었습니다.도입 이유 및 해결 방안선택지Docker Hub: Docker의 기본 이미지 저장소로, 다양한 환경에서 접근이 가능하고 설정이 간단합니다.AWS ECR: AWS 전용의 Docker 이미지 레지스트리로, AWS 서비스와 긴밀히 통합된 보안 및 관리 기능을 제공합니다.Docker Hub를 선택한 이유Docker Hub를 이미지 레지스트리로 선택한 이유는 다음과 같습니다:사용성과 접근성: Docker Hub는 Docker 커뮤니티의..

문제 상황기존의 수동 배포 과정은 속도 저하와 반복적인 작업으로 인한 비효율성을 초래했습니다. 이를 개선하기 위해 자동화된 CI/CD 프로세스를 도입하여 배포 과정을 최적화할 필요가 있었습니다.도입 이유 및 해결 방안선택지JenkinsGitHub Actions배경 당시 EC2 프리 티어 인스턴스(메모리 1GB)를 사용 중이며, Docker와 Jenkins를 동시에 구동하려 했으나 메모리 부족으로 성능이 크게 저하되는 문제가 발생했습니다. Jenkins는 일반적으로 2GB 이상의 메모리를 요구하며 Docker로 실행할 때에도 메모리가 더 필요하여, 현재 인스턴스에서는 Docker와 Jenkins를 동시에 운영하기 어려웠습니다. 결과적으로 CI/CD 작업을 안정적으로 수행하려면 최소 4GB 이상의 메모리가 ..

문제 상황포인트 이벤트 진행 시 많은 사용자가 몰려 동시성 문제가 발생하였고, 이로 인해 데이터 불일치 및 성능 저하가 확인되었습니다. 이를 해결하기 위해 다양한 동시성 제어 방법(낙관락, 비관락, 분산락)을 검토한 결과, 분산 락을 도입하게 되었습니다.시스템 내에서 데이터베이스 접근이 빈번하게 발생하면서 동시성 문제, DB 부하 증가, 그리고 데이터 일관성 저하 문제가 나타났습니다. 특히, 다수의 사용자가 동시에 데이터를 갱신하거나 조회하는 경우 트랜잭션 충돌이 빈번하게 발생해 응답 지연과 데이터 오류가 발생했습니다. 이러한 문제를 해결하기 위해 동시성 제어 방식을 단계적으로 개선하여 최적의 솔루션을 찾았습니다.동시성 제어 방식 발전 과정 및 선택 이유1. DB 바로 저장특징: 별도의 동시성 제어 없이..