Soft Delete VS Hard DeleteSoft Delete와 Hard Delete는 데이터 삭제 방식을 구분하는 개념이다.Soft Delete: 데이터를 물리적으로 삭제하지 않고, 삭제 여부를 나타내는 플래그(예: is_deleted, deleted)로 표시만 하는 방식 Hard Delete: 데이터를 DB에서 완전히 제거(DELETE) 하여 복구 불가능하게 만드는 방식 Soft DeleteSoft delete는 삭제 여부를 판단할 수 있는 컬럼을 추가해 데이터가 삭제되었는지, 아닌지에 대한 값을 넣어서 표시한다.삭제 할 데이터가 추후에 조회해야 하거나, 실수로 삭제했을 시 복원 가능해야 하는 중요한 도메인일 경우에 사용한다.UPDATE Users SET deleted = true WHERE i..

@Secured,@PreAuthorize, @PostAuthorize활성화 설정@Configuration@EnableWebSecurity // 스프링 시큐리티 필터가 스프링 필터체인에 등록@EnableMethodSecurity(securedEnabled = true, prePostEnabled = true) // 중요public class SecurityConfig {@EnableMethodSecurity(securedEnabled = true, prePostEnabled = true)SecurityConfig 파일에 해당 애노테이션을 적용해야 @Secured,@PreAuthorize, @PostAuthorize 이 애노테이션들을 사용할 수 있다.@PreAuthorize만 사용할꺼면 @EnableMet..

서버 환경 : ubuntu-server 24.04 LTS 기존 테무린 jdk 17을 사용하다가 테무린 JDK 21로 업그레이드를 하기로 결정했다.# 시스템 업데이트 및 필요 패키지 설치sudo apt updatesudo apt install -y wget apt-transport-https gnupg# 올바른 방식으로 GPG 키 추가wget -O - https://packages.adoptium.net/artifactory/api/gpg/key/public | sudo gpg --dearmor -o /usr/share/keyrings/adoptium-archive-keyring.gpg# 시스템 코드명 자동 감지하여 저장소 추가echo "deb [signed-by=/usr/share/keyrings/ado..

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.스프링에 레디스를 도입해서 간단한 게시판 서비스의 조회 성능을 개선하는 코드 기본적인 애플리케이션 설정application.yml# local 환경spring: profiles: default: local datasource: url: jdbc:mysql://localhost:3306/mydb username: root password: password driver-class-name: com.mysql.cj.jdbc.Driver jpa: hibernate: ddl-auto: update show-sql: true data: redis: host:..

CQRS는 CUD(Command)와 R(Query)를 분리하는 것이다.기존의 CRUD 서비스 구조는 보통 하나의 클래스나 API에서 create, read, update, delete 전부 처리한다.CQRS는 이를 명확히 나눠서,Command (명령): create, update, deleteQuery (조회): read이 두 가지를 서로 다른 책임으로 나누는 패턴이다. CQRS 패턴을 도입하는 이유역할이 다르기 때문Command는 상태를 바꾸는 작업.Query는 상태를 읽기만 함. 성능 최적화 가능예를 들어 Command는 트랜잭션 안전성과 정합성 위주로, Query는 빠르게 결과만 제공하도록 설계할 수 있다. 코드 유지보수 편리로직이 복잡해질수록 읽기와 쓰기를 분리하는 게 유리하다. CQRS는 단순히..

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.기본 문법GitHub Actions에서 가장 중요한 파일은 deploy.yml인데, 이 파일의 위치는 git으로 관리되는 최상위 루트의 .github/workflows/ 폴더에 저장되어 있어야 한다.-> 최상위루트/.github/workflows/deploy.yml(deploy.yml 의 이름은 변경해도 상관없다.)# Workflow의 이름# Workflow : 하나의 yml 파일을 하나의 Workflow라고 부른다. name: Github Actions 실행시켜보기# Event : 실행되는 시점을 설정# main이라는 브랜치에 push 될 때 아래 Workflow를 실행on: push: branches: ..

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.부하 테스트를 하면서 목표로 설정해놓은 Throughput, Latency를 달성하기 위해 성능 개선을 해야 한다.병목 지점이 어디서 발생하느냐에 따라 성능 개선의 방법이 달라진다. 병목 지점에 따른 성능 개선EC2(WAS)가 병목 지점일 경우애플리케이션 로직에서 비효율적인 부분 개선정적 파일 서버(S3, Cloudfront) 분리로드밸런서(ELB)를 활용해 수평적 확장수직적 확장 RDS(데이터베이스 서버)가 병목 지점일 경우비효율적인 쿼리 개선 (인덱스 활용, SQL문 튜닝, 역정규화 등)수직적 확장읽기 전용 데이터베이스(Read Replica) 도입캐시 서버 도입주의위 순서가 절대적인것은 아니다. 일반적으로 ..

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.모니터링과 병목지점부하 테스트 과정 중에 성능을 개선하려면 병목 지점을 먼저 파악해야 한다.병목 지점을 파악하기 위해서는 각 컴퓨터의 CPU 사용률과 메모리 사용률과 같은 값들을 지속적으로 확인할 수 있어야 한다.여기서 얘기하는 컴퓨터는 로드 밸런서(ELB), 백엔드 서버(EC2), DB(RDS), 캐시(ElastiCache) 등을 얘기한다. 무언가 요청을 받아서 처리하는 형태의 서비스는 전부 컴퓨터에서 처리하기 때문이다.컴퓨터가 무언가를 처리하려면 CPU와 메모리 같은 자원이 필요하다. 만약 컴퓨터가 처리할 수 있는 최대한의 요청을 처리하고 있다면, CPU 사용률 또는 메모리 사용률과 같은 값이 100%에 가까운..