• 기존의 프로그램에서 버그를 수정을 위해 코드를 수정하여 docker compose를 이용해 로컬에 spring 프로젝트들을 띄워 두었다.

• redis의 설정 파일

  spring:
  data:
    redis:
      host: host.docker.internal
      port: 6379

spring.config.activate.on-profile: local spring: data: redis: host: host.docker.internal port: 6379

spring.config.activate.on-profile: dev spring: data: redis: host: ${redis.host} port: 6379

- 위와 같이 local 환경과 dev 환경의 redis.host가 분리되어 있다. dev 환경의 redis.host는 aws의 Elasticache 주소로 설정되어 있고, 로컬에서 레디스를 띄워 테스트를 진행해 볼 예정이었기에 프로파일 설정을 local로 변경하여 진행하려 하였다.

- 현재 Dockerfile의 상태

```DockerFile
# build 에서 사용할 이미지
FROM gradle:8.10.2-jdk21 AS build

WORKDIR /app

ARG FILE_DIRECTORY

COPY $FILE_DIRECTORY /app

# 실제 컨테이너로 만들 이미지 베이스
FROM openjdk:21-jdk-slim

# build 단계로부터 파일을 가져올 수 있음!
# AS build로 선언해놨기에 --from=build!
COPY --from=build /app/build/libs/*SNAPSHOT.jar /app.jar

CMD ["java", "-Dspring.profiles.active=dev", "-jar", "app.jar"]

• 위와 같이 -Dspring.profiles.active가 dev로 설정되어 있기에 local로 변경하고 docker compose를 이용해 스프링 프로젝트들을 실행시켰다.

• 실행 후 모든 프로젝트의 콘솔 창을 살펴 보니

  The following 1 profile is active: "dev"

  라는 문구와 함께 레디스에 연결할 수 없다는 오류가 나타났다.

해결 과정

• DockerFile의 -Dspring.profiles.active를 local로 설정하였음에도 불구하고 왜 이미지에 반영이 되지 않는 것일까?

Solution #1.

docker-compose up 명령어는 기존 이미지가 존재할 시에, 이미지를 재빌드하지 않는다. 따라서 기존에 이미지가 있다면 Dockerfile 이 수정되었더라도 이미지에 변경사항이 적용되지 않는다.

• 따라서 이미지를 모두 지운 뒤 gradle을 이용해 clean 및 build를 수행하고 다시 이미지를 띄워 보았다.

$ ./gradlew clean

$ ./gradlew build

$ docker compose up --build

• 그러나 오류는 해결되지 않았고, 같은 오류가 반복되어 나타났다.

Solution #2.

build 를 해도 Dockerfile 의 변경사항을 캐시로 처리해서 변경이 되지 않는 경우가 있다고 한다. 그럴 때는 이미지 빌드 시 캐시를 사용하지 않도록 옵션을 붙혀주면 된다.

$ docker compose up --force-recreate

• 역시나 같은 문제가 반복되었다.

solution #3.

docker 에서는 layer를 쌓을 때 cache를 이용해서 이미지 빌드와 컨테이너 생성 시간을 줄인다. 이 cache 데이터는 이미지와 컨테이너를 제거하더라도 로컬에 남아있다. cache 가 계속 쌓이는 것이 장점이 크긴 하지만 단점도 있다.

• 혹시 몰라 로컬의 캐시를 모두 제거 후 다시 이미지를 빌드해보았다.

$ docker system prune -a

• 나도 몰래 13GB나 쌓여있었던 캐시가 삭제되었고, 이미지를 다시 빌드해 보았다.

The following 1 profile is active: "local"

• 위의 문구와 함께 버그가 잘 수정되었다❗❗

금주의 트러블 슈팅

• 위는 현재 진행중인 멀티 모듈 프로젝트의 모듈 구조이다. 평소와 같이 개발을 진행하던 도중, 예외 처리 및 에러 핸들링을 하는 과정에서 다음의 문제가 발생했다.

• 우선 api 모듈의 Controller단에서 domain 모듈의 Service단을 호출하고, Service단의 메소드에서 try-catch문으로 예외 발생을 감지하고, 해당 오류를 support-api 모듈에 정의된 Api Response 클래스로 감싸서 반환한다.

• Service 단에서의 여러 분기(없는 Entity 조회, 권한 부족 등)에 따른 예외를 발생시키기 위해 직접 구현한 ErrorType 코드, Exception 클래스가 필요했다.

• 그러나 ErrorType, Exception 클래스는 support-api 모듈에 정의되어 있어 Service 로직에서 참조가 불가하였다.

• 그래서 고안한 방법들 아래와 같다.

Solution #1

• 기본적으로 domain 모듈은 support-api 모듈을 참조하는 것이 불가하지만, api 모듈은 최상위 모듈이기에 다른 support 모듈들을 참조할 수 있도록 설계되어 있다.
• 따라서 Custom Exception 관련 코드들을 support-domain 모듈로 옮기게 되면 api 모듈에서 참조할 수 있었다.

문제 발생

• 그러나 support-api 모듈의 Api Response를 구현한 패키지에서 Custom Exception을 구현한 패키지 내의 코드를 재사용하고있었다.
• support 모듈끼리는 서로 참조가 불가했기 때문에 이 부분에서 오류가 발생하는 것을 확인할 수 있었다.
• 발생한 연쇄적인 오류를 해결하기 위해 support-api 모듈과 support-domain 모듈이 상호작용하도록 설계를 하게 되면 DDD를 구현한 의미가 퇴색된다고 판단되어 다른 방법을 모색하기로 하였다.

Solution #2

• Custom Exception을 구현한 코드를 위와 같이 domain 모듈에도 두면 Service 단에서도 예외 처리를 구현할 수 있다.

문제 발생

• 코드에 중복성이 생기게 되어 좋은 코드는 아니다.

• Custom Exception 관련 코드 중 하나의 클래스인 ErrorType에 정의된 코드 중 DEFAULT_ERROR(HttpStatus.INTERNAL_SERVER_ERROR, ErrorCode.E500, "An unexpected error has occurred.", LogLevel.ERROR) 와 같이 HttpStatus enum을 사용하려면 'org.springframework.boot:spring-boot-starter-web' 의존성을 주입해야 한다.

• support-domain 모듈은 기본적으로 spring boot 의존성을 모두 배제하고 순수 자바코드만 사용하기로 컨벤션이 정의가 되어있던 상태라, 의존성을 주입하기 애매한 상황이다.

Solution #3

• 최종적으로 수정된 구조이다. 공통적으로 사용되는 error 모듈을 새로운 공통모듈로 생성하여 api 모듈, domain 모듈에 주입하여 사용할 수 있었다.
• 추가로 Api Response를 구현한 클래스에도 Custom Exception을 구현한 클래스의 ErrorType이 필요하기에 순환 참조만 주의하여 support-api 모듈에 support-error 모듈을 주입하면 Solution #1의 문제도 해결할 수 있다.

• Week I Learned, 이번 주 프로젝트를 수행하며 겪은 일들, 배운 내용들을 정리하는 시간을 가져 보자.

먼저, 노션의 5분 기록 보드를 활용해 프로젝트를 진행하며 기록했던것들을 리마인드해보자.

• 챕터 초반부인 만큼, 기획, 설계와 관련된 부분들이 많았다. 요구사항을 정의하고, 관련 자료들을 찾아 용어들을 정리하며 팀원들과 함께 프로젝트에 대한 이해도를 높였다.
• 이후 API 명세서, 테이블 명세서, ERD를 작성하며 설계하는 시간을 가졌고 프로젝트의 목표 중 기본 기능 구현을 제외하고 도전과제까지 정의할 수 있었다.

프로젝트 요구 사항

• 사용자 관리
  • 사용자 정보 관리:
    • 사용자 엔티티는 모든 사용자 정보를 관리하며, 사용자 비활성화 시 is_deleted 필드 사용
  • 권한 관리:
    • 마스터 관리자만 생성, 수정, 삭제가 가능하며 사용자 본인만 자신의 정보를 조회할 수 있습니다. 마스터 관리자는 모든 사용자 정보를 조회할 수 있음
    • MASTER, USER, LAWYER(변호사) 권한 존재
• 변호사 관리
  • 변호사 등록:
    • 변호사 등록을 위해 사이트에서 변호사 등록 신청을 받고 MASTER 관리자의 승인이 필요함
    • 변호사는 등록 신청 시 변호사 소개, 자격 정보, 경력 사항들을 함께 업로드
    • 승인이 완료되면 변호사 목록 페이지에 해당 변호사의 정보가 업로드 됨
  • 상담 신청:
    • 변호사 정보 조회 시 변호사의 이름, 이메일, 소개, 자격 정보, 경력 사항들이 제공되며 변호사 초대 버튼 클릭시 변호사에게 상담 신청 요청
      • 변호사 수락시 기존 대화에서 변호사와 셋이서(예비 채권자, 예비 채무자, 변호사) 대화 가능
  • 변호사 역할:
    • P2P 대출이 이루어질 때, 유저는 변호사에게 사업 정보를 제공 (관련 자료 → 클릭)
      • P2P 대출의 구조 및 영업 방식
      • 상품 유형별 누적 대출 금액
      • 차용증
      • 전자 서명
  • 변호사 리뷰:
    • 계약이 체결되면 사용자는 상담을 신청했던 변호사에게 리뷰를 달 수 있음
    • 별점과 코멘트를 남김
• 채팅방 관리
  • 채팅방 정보 관리:
    • 사용자는 누구든 원하는 상대와 채팅을 할 수 있고, 본인의 채팅방만 조회 가능
    • 마스터 관리자만 타인의 채팅방을 조회, 수정, 삭제가 가능
    • 기본적인 정보(채팅방의 UUID, 소속된 유저들의 정보 등)는 RDB에 저장
    • 여러 조인들로 인한 성능 저하 방지를 위해 세부 정보들(채팅 내역)은 NoSQL로 저장
• 게시글 관리
  • 게시글 정보 관리:
    • 모든 사용자는 게시글을 조회할 수 있고 자신의 게시글만 등록, 수정, 삭제가 가능
    • MASTER 관리자는 모든 게시글의 등록, 수정, 삭제가 가능
    • 게시글에는 ‘대출해드립니다’, ‘대출받습니다’ 두 개의 카테고리가 존재
    • 게시글에는 해당 대출에 적용되는 계약 상태를 게시글 상단에 노출시켜야 함
      • 모집 중(OPEN) → 대출자를 모집 중인 단계
      • 진행 중(IN_PROGRESS) → 대출이 진행중인 단계
      • 계약 완료(COMPLETED) → 계약이 체결된 단계
    • 계약이 생성되거나 해당 계약이 성사되면 게시글의 상태가 업데이트됨
• 계약 관리
  • 계약 관리 :
    • 계약은 게시글에 종속된 상태
    • 계약은 게시글에서 채권자, 채무자 간 합의에 의해 생성
      • 한쪽의 계약 생성 요청 후 상대의 요청 허가 후 생성
      • 계약이 생성된 후 게시글의 상태는 계약 완료로 변경
    • 일반 사용자는 자신의 계약을 조회 가능
    • 계약 이해 관계자 간 합의가 있다면 계약 수정 가능
      • 계약은 수정 요청후 상대방의 요청 허가 후 수정 반영
    • MASTER 관리자는 모든 계약의 조회 가능
  • 계약 상태:
    • 모든 계약은 다음의 상태를 가짐
      • 채무 이행중
      • 채무 완료

• 위의 요구사항 중 내가 맡은 부분은 게시글 관리와 계약 관리였고, 현재까지는 게시글 도메인에서 유저 권한에 따른 분기, 예외 처리, 에러 핸들링을 제외하고 기본 CRUD + Search 기능까지는 구현이 된 상태이다. 계약 도메인 또한 비슷하게 진행되고 있는 상태이다.
• 내가 맡은 부분의 도전 기능으로는 배포 시 S3를 이용한 계약서 파일 업로드 기능을 구현하기로 정해졌다.

트러블 슈팅

• 멀티 모듈 프로젝트도, DDD 구조로 된 프로젝트도 처음이었기에 두 구조가 결합된 프로젝트를 구현하는것은 쉽지 않았고, 그 과정에서 Lombok이 제대로 동작하지 않는 경우가 발생했다.

• 프로젝트 모듈의 구조는 아래와 같이 설계되어 있다.

• 각 App에서 api, domain, storage 모듈을 구분하고 support 모듈에서 대응되는 각 모듈에게 의존성을 주입하여 support 모듈에 정의된 클래스들을 사용하게 된다.
• 각 서포트 모듈에서 아래의 코드를 공통적으로 주입하고 있었는데, 대응되는 상위 모듈들에서 Lombok이 적용되지 않는 경우가 발생했다.

api 'org.projectlombok:lombok'
annotationProcessor 'org.projectlombok:lombok'

Support 모듈이 아닌 각 모듈에

compileOnly 'org.projectlombok:lombok'

annotationProcessor 'org.projectlombok:lombok'

위의 두 코드를 넣어 해결하였다.

Support 모듈에서는 위 두 의존성이 전파되지 않는 것을 확인할 수 있었다.

그 외 배운점

1. QueryDSL의 like vs contains

• like(str)은 쿼리가 나갈 때 str자체가 나간다
  • 즉, 정확히 일치해야한다
  • like는 내가 % 연산을 선택할 수 있다
• contains(str)은 쿼리가 나갈 때 %str%가 나간다

2. 무분별한 @Transactional 사용의 개선

• 다른 App으로부터 Feign Client를 통해 Entity를 불러오거나 다른 테이블과의 조인을 통해 여러 CRUD 기능이 한 서비스 함수에 몰려있는 경우 문제 발생 시 한번에 롤백하기 위해 트랜잭션 관리가 필요하지만 하나의 쿼리만 수정하는 함수에서는 @Transactional 어노테이션을 붙여 트랜잭션 관리를 할 필요가 없다.

3. JPAQuery< T >.fetchOne()

JPAQuery<ContractEntity> query = queryFactory.selectFrom(contractEntity)
                                .where(contractEntity.contractUuid.eq(contractUuid));

                List<ContractEntity> result = query.fetch();

• 위의 코드에서 contractUuid 는 기본키이므로 쿼리는 하나임이 보장될 때, list가 아닌 단일 entity로 반환하는 방법은? → fetchOne(); 을 사용

JPAQuery<ContractEntity> query = queryFactory.selectFrom(contractEntity)
                .where(contractEntity.contractUuid.eq(contractUuid));

        return query.fetchOne();

멀티 모듈 프로젝트를 설계 후 빌드 중 위와 특정 모듈에서 같은 오류가 났다.

해결 방법

터미널을 열고 루트 폴더로 이동 후 ./gradlw format 을 실행한다.

빌드가 잘 되는 것을 확인할 수 있다.

CI/CD 전략과 관련하여 페이즈와 Branch 전략에 대한 특강을 들었다.

1. 개발 서버 Phases

1. 개발 (Dev)

• 목적: 개발(Dev) 환경은 개발자가 코드를 작성하고 초기 테스트를 수행하는 공간! 새로운 기능을 구현하거나 버그를 수정하며, 시스템을 개선해 나감.
• 특징:
  • 자주 업데이트되며 불안정한 상태.
  • 각 개발자가 자신의 로컬 환경이나 공유된 개발 환경에서 작업할 수 있음.
  • 빠른 반복 작업을 지원하는 지속적 통합 도구와 연계됨.

2. 스테이징 (Stage)

• 목적: 스테이징(Stage) 환경은 프로덕션(Prod) 환경을 미리 시뮬레이션하는 공간으로, 실제 서비스가 배포되기 전에 애플리케이션의 동작을 테스트하는 단계. 모든 개발 작업이 완료된 후에 새로운 기능이나 수정 사항을 확인하는 용도로 사용됨.
• 특징:
  • 생략된 회사가 생각보다 많음
  • 프로덕션 환경과 최대한 유사하게 설정된 안정적인 환경
  • QA(품질 보증) 테스트, 사용자 수용 테스트(UAT), 성능 테스트 등에 사용됨
  • 새로운 기능이나 버그 수정이 프로덕션 환경에서 예상대로 작동하는지 확인함.
  • 데이터는 프로덕션 데이터의 익명화된 복사본이거나, 가상의 데이터일 수 있음
  • 스테이징 단계에서는 코드가 고정되고, 주요 버그 수정만 허용됨

3. 프로덕션 (Prod)

• 목적: 프로덕션(Prod) 환경은 애플리케이션이 실제 사용자에게 서비스되는 라이브 환경!
• 특징:
  • 매우 안정적이며, 성능, 보안, 확장성을 최적화
  • 변경 사항은 신중하게 관리되며, 보통 예정된 릴리즈나 업데이트를 통해 배포됨
  • 가동 시간이 매우 중요하며, 다운타임을 최소화하기 위해 모니터링 시스템과 백업이 필요함
  • 실제 데이터를 사용하므로 데이터 백업은 필수
  • 프로덕션에서 발생하는 문제는 사용자에게 직접 영향을 미치므로, 앞선 환경에서 충분히 테스트한 후 릴리즈가 이루어짐

환경 간의 흐름

1. 개발 환경에서 코드가 작성되고 테스트됨
2. 안정화되면 스테이징 환경으로 이동하여 정밀한 테스트를 거침
3. 스테이징 환경에서 테스트가 성공적으로 완료되면 프로덕션 환경으로 배포되어 사용자에게 제공됨

Trunk-Based-Development

• 개요: 개발자들이 코드 변경을 자주 main(또는 trunk) 브랜치에 병합하는 방식! 짧은 주기로 코드를 통합하고 배포하는 것을 목표로 한다. 모든 개발이 짧은 피드백 루프 안에서 이루어지며, 장기적으로 코드 병합을 지연시키지 않기 때문에 더 빠른 배포 주기가 가능하다!

• CI/CD와의 적합성:

  • 지속적인 통합: Trunk-Based Development는 자주 병합이 이루어지므로, 코드가 항상 통합된 상태에서 테스트와 배포가 이루어 짐. 이는 빠른 피드백을 제공하여 코드 품질을 유지하고 배포 속도를 높임
  • 단기 브랜치 사용: 기능 개발이 단기 브랜치에서 이루어지며, 완료되면 바로 trunk로 병합됨. 병합 시점에 CI/CD 파이프라인이 자동으로 테스트와 배포를 실행하여, 최신 코드를 항상 배포 가능한 상태로 유지
  • CI/CD 장점:
    • 빠른 피드백 루프와 높은 배포 빈도.
    • 병합 충돌 감소와 간소화된 브랜치 관리.
    • 자동화된 테스트 및 배포를 통해 언제든지 최신 코드를 배포 가능.

Git Flow

• 개요: develop와 master 같은 장기 브랜치를 사용하여 개발과 배포를 관리한다. 기능 브랜치, 릴리즈 브랜치, 핫픽스 브랜치 등 여러 브랜치를 사용하여 코드의 상태를 관리하며, 특히 대규모 프로젝트에서 구조화된 배포 전략을 제공한다.

• CI/CD와의 적합성:

  • 긴 통합 주기: Git Flow는 develop 브랜치에서 코드 개발이 이루어지며, master에 병합하기 전에 충분한 테스트와 검증 과정을 거침. 이는 릴리즈 빈도를 줄이고 안정성을 높이는 반면, CI/CD 파이프라인이 더 복잡해질 수 있다.
  • 여러 브랜치 관리: 각 브랜치에 대한 별도의 CI/CD 파이프라인이 필요할 수 있으며, 특히 릴리즈 브랜치와 핫픽스 브랜치가 별도로 존재하는 경우 파이프라인 관리가 복잡해진다.
  • CI/CD 장점:
    • 릴리즈를 위한 명확한 주기와 더 많은 통제 가능.
    • 대규모 조직이나 긴 개발 주기를 요구하는 프로젝트에 적합.
    • develop 브랜치를 통한 지속적인 개발 진행이 가능하나, 배포는 주로 master에서 이루어진다.

비교

결론

• Trunk-Based Development는 빠른 배포와 CI/CD를 중점으로 두는 애자일 팀에 적합. 자주 병합하고 작은 변경을 지속적으로 배포할 수 있어 마이크로서비스나 빠른 피드백이 중요한 프로젝트에 매우 유리.

• Git Flow는 더 구조화된 배포 주기와 릴리즈 관리를 선호하는 팀에 적합. 큰 프로젝트나 조직에서는 Git Flow가 더 많은 통제력을 제공하지만, CI/CD 속도가 느려질 수 있고 관리 복잡성이 증가할 수 있음. 각 방법은 팀의 요구와 프로젝트의 성격에 따라 달라질 수 있으며, CI/CD 자동화 수준에 따라 두 가지 전략을 혼합하여 사용하는 것도 가능함.

• 아래는 실제 특정 회사에서 사용중인 브랜치 전략

• dev-deploy(s) 브랜치는 개발 서버에서 빠르게 내 작업에 대한 테스트를 해보기 위한 브랜치

• https://github.com/asd0236/SpartaHubFlow

MSA를 이용한 Ch.4의 물류관리 및 배송 시스템 프로젝트가 끝이 나고 Swagger를 통해 API 명세서를 작성하던 중 Swagger Editor에서 다음과 같은 오류가 발생했다.

Errors
Hide

Semantic error at paths./api/v1/orders/{orderId}.delete.requestBody
DELETE operations cannot have a requestBody.
Jump to line 223

• 지금까지는 크게 인지하지 못하고 있었는데, DELETE Mapping을 진행할 때에는 RequestBody를 사용하지 않는 것이 일반적이라고 한다.

• 더 정확히 이야기 하자면, HTTP DELETE 요청은 바디를 가지지 않는 것이 일반적

대체 방법으로는?

• @DeleteMapping 을 통해 데이터 전달이 필요한 경우 @PathVariable, @RequestParam을 사용하거나
• @PutMapping 을 대신 사용하는 것도 방법이 될 수 있다!

물류 관리 및 배송 시스템을 MSA 구조로 구현하며 Docker를 사용하여 프로젝트 실행하였다. 이번 포스팅에서는 해당 과정에서 겪은 일들을 회고하여 정리하여 보자.

개요

• 물류 관리 및 배송 시스템을 MSA 구조로 구현하였다.

• 위의 ERD에서 내가 기능 구현을 맡은 테이블은 p_company, p_product, p_order였다. 세 개의 기본 CRUD+Search 기능을 구현하였고, 권한에 따른 요청 관리는 Gateway에서 처리하도록 하고, 권한에 따른 기능 분리는 각 App의 서비스단에서 처리한다.

• Swagger를 적용하여 API 명세서 생성을 자동화하였다.

• Gemini API와 연동하여 각 App마다 AI와 질문을 주고받고 대화 내역을 DB에 저장하도록 하였다.

• Docker를 사용하여 각 Application을 실행하도록 하였다.

Docker를 사용하며 알게 된 것

• local 환경에서와는 다르게 DB를 사용할 경우 DB 또한 Docker를 사용해 컨테이너를 생성해야 한다.

• MSA 구조와 같이 APP이 여러개라면 docker compose를 사용해 여러 APP의 컨테이너화 과정을 단순화하는 편이 훨씬 편하다.

Dockerfile 작성

• 각 App마다 실행에 별 다른 차이가 없어 모두 같은 Dockerfile을 사용했다.

  # build 에서 사용할 이미지
  FROM gradle:8.10.1-jdk17 AS build
  

WORKDIR /app

ARG FILE_DIRECTORY

COPY $FILE_DIRECTORY /app

RUN gradle clean bootJar

실제 컨테이너로 만들 이미지 베이스

FROM openjdk:17-jdk-slim

build 단계로부터 파일을 가져올 수 있음!

AS build로 선언해놨기에 --from=build!

COPY --from=build /app/build/libs/*SNAPSHOT.jar /app.jar

CMD ["java", "-jar", "app.jar"]

### docker-compose.yml 작성

- 우선 eureka-server, gateway, product, order, company App만 도커 이미지로 띄워 실행했다.

```yml
services:
  database:
    image: postgres
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: 1234
      POSTGRES_DB: spartahubflow
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U admin -d user"]
      interval: 10s
      retries: 5
      start_period: 30s
      timeout: 10s

  eureka:
    build:
      dockerfile: Dockerfile
      args:
        - FILE_DIRECTORY=./eureka-server
    ports:
      - "8761:8761"

  gateway:
    build:
      dockerfile: Dockerfile
      args:
        - FILE_DIRECTORY=./gateway
    ports:
      - "8080:8080"

  product:
    environment:
      AI_SECRET_KEY: ${AI_SECRET_KEY}
    build:
      dockerfile: Dockerfile
      args:
        - FILE_DIRECTORY=./product
    depends_on:
      database:
        condition: service_healthy
    ports:
      - "5:5"

  order:
    environment:
      AI_SECRET_KEY: ${AI_SECRET_KEY}
    build:
      dockerfile: Dockerfile
      args:
        - FILE_DIRECTORY=./order
    depends_on:
      database:
        condition: service_healthy
    ports:
      - "4:4"

  company:
    environment:
      AI_SECRET_KEY: ${AI_SECRET_KEY}
    build:
      dockerfile: Dockerfile
      args:
        - FILE_DIRECTORY=./company
    depends_on:
      database:
        condition: service_healthy
    ports:
      - "88:88"

• 위와 같이 environment: 아래에 각 application.yml에서 사용되는 환경 변수 할당해줄 수 있다.

• 그렇다면 docker-compose.yml 파일에서의 환경변수는 어떻게 처리하게 될까?

  • application.yml에 넣을 환경 변수를 주입하기 위해 docker-compose.yml 파일에 그대로 값을 넣은 후 github에 업로드 할 수는 없는 노릇이다.
  • 때문에 위와 같이 또 다시 환경변수로 등록을 하고 같은 디렉토리 내에 .env 파일을 만들어 그 곳에 주입하고 싶은 값을 넣어주면 된다!
  • AI_SECRET_KEY=my_secret_key 와 같은 형식으로 넣어주면 된다.

• 이후 실행 시 프로젝트들이 잘 실행되는 것을 확인할 수 있다.

Spring Boot를 통해 애플리케이션을 생성한 후 실행하며 위의 에러가 발생했다. 컨트롤러단, 서비스단, 레포지토리 세 부분에서 모두 같은 오류가 동시에 발생했다.

에러 발생 원인

구글링 결과 설정파일이나 DB 쿼리문에 문제가 있을 수 있다고 하였다. 설정파일에는 큰 문제가 없어보였고, DB 쿼리를 살펴보았다.

@Query("UPDATE Product p SET p.deletedAt = : deletedAt, p.deletedBy = :deletedBy, p.isDeleted = true " +
            "WHERE p.productId = :productId")

자세히 보면 p.deletedAt = : deletedAt의 deletedAt 앞에 공백이 하나 있는 것을 확인할 수 있다.

해결 방법

deletedAt 앞의 공백을 제거하여 해결할 수 있었다.

@Query("UPDATE User u SET u.deletedAt = :deletedAt, u.deletedBy = :deletedBy, u.isDeleted = true " +
            "WHERE u.userId = :userId")

프로젝트를 마치며 발표 준비 중 Spring Data Jpa의 Batch 처리에 대해 궁금한 점이 생겼다.

Batch Insert란?

• 여러 개의 SQL Statement를 하나의 구문으로 처리할 수 있다.
• hibernate 에서 위 기능(jdbc batch 기능)을 이용해 처리하는 것이다.
• 여러 개의 구문을 여러 번 network를 통해 보내는 것이 아니라 합쳐서 하나로 보내는 것이기에 성능을 향상시킬 수 있다.
  • JPA의 경우 트랜잭션이 commit 되는 순간 한꺼번에 flush가 이루어짐
  • batch_size 옵션이 없다면 단건으로 데이터를 network를 통해 보낼 것이다.
  • 그러나 batch_size 옵션을 설정 시 해당 사이즈만큼 네트워크를 통해 데이터를 보낼 것이다.

아래 예시인 3개의 insert statements를 하나의 PreparedStatement로 실행해준다는 것이다.

# 옵션 켜기 전
insert into test (column01, column02) values ('test01', 'test02');
insert into test (column01, column02) values ('test03', 'test04');
insert into test (column01, column02) values ('test05', 'test06');

# 옵션 켠 후
insert into test (column01, column02) 
values ('test01', 'test02'),
       ('test03', 'test04'),
       ('test05', 'test06') 

Spring Data Jpa Batch Insert를 사용하는 방법

• 설정 파일에서 hibernate.jdbc.batch_size을 설정해준다. 최대 몇 개 까지 statements를 batch 처리를 할 것인지에 대한 옵션이다.

• 즉, 한 번에 데이터베이스로 보낼 최대 구문을 의미한다

• application.yml

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
          batch_size: 1000

Insert 구문 외에도 사용할 수 있을까?

• Spring Data JPA의 Batch 기능은 기본적으로 Insert 작업에 주로 사용되지만, Update 및 Delete 작업에도 적용할 수 있다. Batch 기능은 동일한 유형의 SQL 쿼리를 한 번에 여러 개 실행함으로써 성능을 최적화하는 방법이다.

• Spring Data JPA의 Batch 기능은 Select 작업에는 적용되지 않는다.

• Batch 기능은 주로 데이터베이스에 변경을 가하는 작업(Insert, Update, Delete)에 최적화되어 있으며, 동일한 유형의 SQL 명령을 묶어서 실행하는 방식이다. Select 작업은 데이터를 조회하는 것이므로, Batch 처리와는 개념적으로 맞지 않다.

hibernate.order_updates, hibernate.order_inserts

• 위 batch_size 옵션 외에도 이 2개 옵션은 jdbc batch 기능을 더욱 효과적으로 사용할 수 있도록 도와준다.

• 위 기능을 먼저 살펴보고 넘어가면 update, insert 문의 실행 순서를 정렬해주는 옵션이다. 예를 들면 아래와 같다.

• 이렇게 되면 jdbc batch 기능을 통해 일괄 처리를 할 때, 더욱 효율적으로 처리가 가능하다.

# before apply option
update test set column01 = 'test3' where regdate = '20210510';
update test2 set column02 = 'test5' where regdate = '20210511';
update test set column01 = 'test4' where regdate = '20210512';
update test2 set column02 = 'test6' where regdate = '20210513';

# after apply option
update test set column01 = 'test3' where regdate = '20210510';
update test set column01 = 'test4' where regdate = '20210512';
update test2 set column02 = 'test5' where regdate = '20210511';
update test2 set column02 = 'test6' where regdate = '20210513';

• application.yml

spring:
  jpa:
    properties:
      hibernate:
        jdbc:
        order_inserts: true
        order_updates: true

• 오늘 진행한 일
  • User Role 관련 코드 리팩토링
  • ai api 에러 로그 작성
  • Payment, Ai API 도메인 구현 마무리 및 PR 요청
  • 전반적인 API 테스팅

User Role 관련 코드 리팩토링

아래와 같이 UserRole을 Enum으로 구현하였다.

• API 요청을 주고받을 때에는 Stirng 형식(USER, OWNER, ADMIN)으로 요청 및 응답이 되지만 DB 상에서는 Enum 값이 정수형(USER라면 1, OWNER라면 2, ADMIN이라면 3)으로 저장이 된다.

• 이런 경우에 enum 타입이 변경되거나 UserRole이 추가되면 예기치 못한 문제가 발생할 수 있기 때문에 DB에도 String으로 저장해주는 것이 안전하다.

해결 방법

아래와 같이 User Entity에 있는 UserRoleEnum role 필드 위에 @Enumerated(EnumType.STRING) 어노테이션을 붙여주면 된다.

    @Column(nullable = false)
    @Enumerated(EnumType.STRING)
    private UserRoleEnum role;

Ai API 에러 로그 작성

Gemini api를 불러와 사용하는 도중 에러가 발생하였다. 에러의 내용과 원인 및 해결 방법은 아래 링크에서 확인할 수 있다.

링크

전반적인 API 테스팅

구현된 API의 양이 꽤 많아 reqeust를 하나씩 만들어가며 폴더로 정리하고 테스팅을 진행했다.

• 테스팅을 진행하며 오류 발생 시 로그를 확인하여 원인을 찾고 기록 후 팀원들에게 공유하였다.

API 테스트를 하던 도중 제목과 같은 오류가 발생하였다. 조사 결과 처음에는 쿼리문 작성에 있어 오류가 있는줄 알았다. 'userId' 필드를 찾을 수 없다는 오류가 발생했다.

    @Query("SELECT a FROM AiChat a WHERE a.user.userId = :userId AND a.isDeleted = false")
    Page<AiChat> findChatForAUser(@Param("userId") Long userId, Pageable pageable);

그러나 해당 필드는 외래키를 통해 제대로 참조되고 있었다.

그렇다면 왜 오류가 나게 된걸까?

원인 및 해결 방법

위와 같이 GET 요청을 보냈을 때 오류가 발생하였다. 정렬 기준(sort)이 userId로 되어있는 것을 확인할 수 있다.

• 페이지 객체로 반환될 entity에는 user라는 필드가 다대일로 매핑되어있고, userId는 존재하지 않는다. 이 때문에 오류가 발생한 것이다.

• entity에 존재하는 필드 이름을 넣어 정렬 기준으로 정해주면 응답이 잘 돌아오는 것을 확인할 수 있다.

Spring Data JPA를 사용해 Soft Delete를 구현하던 중 제목과 같은 오류가 발생했다.

• 아래와 같이 @Query를 사용하여 UPDATE문을 사용하였다.

@Query("UPDATE User u SET u.deletedAt = :deletedAt, u.deletedBy = :deletedBy, u.isDeleted = true " +
            "WHERE u.userId = :userId")
    void deleteById(@Param("userId") Long userId, @Param("deletedAt") LocalDateTime deletedAt,
                    @Param("deletedBy") Long deletedBy); // userId : 삭제될 유저, DeleteBy : 삭제하는 유저

원인

로그의 내용과 같이 @Query 어노테이션을 사용할 경우 SELECT문에만 사용할 수 있다. 그렇다면 나머지 C, U, D 연산은 어떻게 해야할까?

해결 방법

아래와 같이 @Modifying 어노테이션을 붙여 수정 쿼리를 사용할 수 있다.

@Modifying
@Query("UPDATE User u SET u.deletedAt = :deletedAt, u.deletedBy = :deletedBy, u.isDeleted = true " +
        "WHERE u.userId = :userId")
void deleteById(@Param("userId") Long userId, @Param("deletedAt") LocalDateTime deletedAt,
                @Param("deletedBy") Long deletedBy); // userId : 삭제될 유저, DeleteBy : 삭제하는 유저

• 스프링 시큐리티를 적용하여 필터를 구성하고 Security Config 파일 작성을 마쳤다. Postman을 사용하여 api 테스트를 진행해보았는데, 회원 가입 페이지, 로그인 페이지는 모두 .prtmitAll()을 통해 요청 허가를 했는데도 불구하고 403 Forbidden에러가 난 것이다.

• 로그를 살펴보니 회원 가입 로직은 잘 수행되어 DB에 저장된 모습을 볼 수 있었다. 그런데 왜 200 응답이 아닌 403 응답이 오게 된 것일까?

에러 발생 원인

• 에러 자체가 발생한 원인은 아래 제작된 컨트롤러 메소드를 보면 리턴값이 Dto인데 @ResponseBody 가 없어서 404 에러가 발생하게 되는 상황이었다.

    @PostMapping
    public UserDto.Response createUser(@RequestBody UserDto.Create userDto) {

        UserDto.Response createdUser = userService.createUser(userDto);
        log.info(createdUser.toString());

        return createdUser;
    }

?? 그렇다면 왜 404 에러가 나지 않고 403에러가 나서 삽질을 하게 만든 것일까?

• 기본적으로 스프링에서는 따로 예외 처리를 하지 않았다면 예외 발생 시 500 에러가 발생한다. 그런데 스프링 시큐리티를 적용하면 메소드에서 예외가 발생했을 때 403 에러가 발생한다. 심지어 존재하지 않는 URL로 접속하여 404 Not Found가 발생해야 하는 상황에서도 403 Forbidden이 발생한다.

403 에러가 발생하는 원인

우선 이 현상의 원인을 파악하기 위해선 스프링부트에서 에러가 발생했을 때 나타나는 Whitelabel Error Page가 어떻게 나타나는지 알아야한다.

스프링 공식 블로그에 따르면 스프링부트에서는 에러가 발생하면 /error라는 URI로 매핑을 시도한다. 실제로 해당 URI로 이동하면 아래와 같은 페이지가 나타난다.

따로 에러가 발생하여 자동으로 나타난 것이 아니라 강제로 이동했기 때문에 status가 999로 나타났지만 굉장히 익숙한 Whitelabel Error Page가 나타난다.

• Whitelabel Error Page 자체는 403에러와 관련이 없지만 에러가 발생하면 /error로 매핑을 시도한다는 것이 핵심이다.

• 일반적으로 permitAll()을 통해 모든 사용자의 접근을 허용할 URI에는 권한 검증이 필요하지 않은 URI만 추가한다. 그리고 위에서 언급했듯이 스프링부트 프로젝트에서는 에러 발생 시 /error로 매핑한다. 그런데 /error는 모두에게 허용된 URI에 포함되지 않는다.

• 그래서 결과적으로 에러 페이지에도 인증 절차가 요구되어 403에러가 발생하는 것이다.

해결 방법

일단 이 문제는 anyRequest().authenticated()로 인해 /error도 인증이 필요한 것으로 간주되어 발생한 것이기 때문에 모두에게 허용할 URI 목록에 /error를 추가하면 해결할 수 있다.

    .requestMatchers("/error").permitAll() // 에러 페이지 요청 허가

• 요구사항에 맞게 API 명세서, 테이블 명세서, ERD 명세서, 인프라 설계서 작성

API 명세서 (링크)

• 각 셀을 클릭하면 Request Header, Authorization Token, Query Parameters, Path Parameters, Response, Response Body를 확인할 수 있습니다.

테이블 명세서 (링크)

ERD 명세서 (링크)

인프라 설계서(링크)

문제 링크

풀이

정말 간단하게 문자열을 내림차순으로 정렬하면 끝나는 문제이다. C++ 에서는 algorithm 라이브러리의 sort() 함수를 쓰면 됐었지만 java는 익숙치 않아 조금 헤맸던 것 같다.

import java.util.*;

class Solution {
    public String solution(String s) {
        String answer = "";

        char[] chars = s.toCharArray();
        Arrays.sort(chars);

        for(int i=chars.length - 1; i>=0; i--)
            answer += String.valueOf(chars[i]);

        return answer;
    }
}

위의 코드를 보면 sort를 진행하고, 반복문을 다시 돌려 내림차순으로 문자열을 정렬한다. 비효율적인 방법이라고 생각해 Arrays.sort(chars, Collections.reverseOrder()); 를 사용하려 했으나 char[]에서 char는 클래스 타입이 아닌 원시 타입이라 Collentions.reversOrder()를 사용하지 못한다.

그래서 생각해 낸 코드가 위의 코드. 그러나 여러 블로그들을 돌아 다니며 코드를 찾아 본 결과 아래와 같은 코드를 발견했다.

  char[] c = s.toCharArray();
  Arrays.sort(c);
  String str = new String(c);
  String answer = new StringBuilder(str).reverse().toString();

결론

원시 타입의 문자열을 처음부터 내림차순으로 정렬하긴 힘들지만, StringBuilder를 사용하여 문자열을 뒤집으면 반복문을 사용하지 않아도 된다! 위의 코드를 적용하여 조금 더 깔끔하게 문제를 풀 수 있는 것으로 보인다.

• 지난 시간에 이어 낙관적 락, 데드 락 실습을 진행해보았다.
• DB 복제 지연, 메모리 릭, 캐시 압력(Cache Pressure), 설정 버전 관리(Configuration Versioning)에 대한 이론적인 부분들을 수강하였다.

낙관적 락 실습

낙관적 락의 동작방식

• 낙관적 락(Optimistic Lock)은 트랜잭션 간의 충돌을 최소화하고 성능을 향상시키기 위해 사용되는 동시성 제어 메커니즘이다.

• 비관적 락이 데이터베이스 레벨에서 락을 걸어 다른 트랜잭션의 접근을 차단하는 방식이라면, 낙관적 락은 데이터베이스 락을 사용하지 않고, 대신 데이터가 변경되었는지 확인하여 충돌을 처리하는 방식이다.

• 버전 관리:

  • 낙관적 락에서는 보통 version이라는 필드를 엔티티에 추가한다. 이 필드는 해당 엔티티의 수정 횟수를 추적하는 역할을 한다.
  • 트랜잭션이 엔티티를 읽을 때, 현재의 버전 번호가 함께 읽혀온다.
  • 트랜잭션이 엔티티를 수정하고 저장하려고 할 때, 현재 데이터베이스에 저장된 버전 번호와 트랜잭션이 처음 읽어온 버전 번호를 비교한다.

• 데이터 충돌 검출:

  • 트랜잭션이 데이터를 저장할 때, 데이터베이스에 저장된 버전 번호가 트랜잭션이 처음 읽어온 버전 번호와 동일하다면, 데이터가 수정되지 않았다고 간주하고 업데이트를 수행한다. 이때 버전 번호는 증가한다.
  • 반면, 버전 번호가 다르면, 다른 트랜잭션이 데이터를 수정한 것으로 간주하고, 현재 트랜잭션을 롤백하거나 재시도하도록 한다.

실습

• Product.java

  import jakarta.persistence.*;
  import lombok.Data;
  

@Data @Entity public class Product { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id;

private String name;
private Double price;

@Version
private Integer version;  // 버전 필드를 통해 낙관적 락을 구현

}

- ProductRepository.java

```java
import org.springframework.data.jpa.repository.JpaRepository;

public interface ProductRepository extends JpaRepository<Product, Long> {
}

• ProductService.java

import lombok.RequiredArgsConstructor;
import org.springframework.orm.ObjectOptimisticLockingFailureException;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
@RequiredArgsConstructor
public class ProductService {

    private final ProductRepository productRepository;

    @Transactional
    public void updateProductPrice(Long productId, Double newPrice) {
        try {
            // 기존 데이터를 읽어옵니다.
            Product product = productRepository.findById(productId)
                    .orElseThrow(() -> new RuntimeException("Product not found"));

            // 가격을 수정합니다.
            product.setPrice(newPrice);

            // 저장 시 버전 충돌이 발생하면 예외가 발생합니다.
            productRepository.save(product);
        } catch (ObjectOptimisticLockingFailureException e) {
            // 낙관적 락 예외 처리
            System.err.println("낙관적 락 충돌이 발생했습니다. 다른 트랜잭션이 먼저 데이터를 수정했습니다.");
            throw e;
        }
    }
}

• ProductServiceTest.java

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.orm.ObjectOptimisticLockingFailureException;

import static org.junit.jupiter.api.Assertions.assertThrows;

@SpringBootTest
public class ProductServiceTest {
    @Autowired
    private ProductService productService;

    @Autowired
    private ProductRepository productRepository;

    @Test
    public void testOptimisticLocking() throws InterruptedException {
        // 초기 데이터 설정
        Product product = new Product();
        product.setName("Product 1");
        product.setPrice(100.0);
        productRepository.save(product);

        // 첫 번째 트랜잭션: 상품 가격을 200.0으로 업데이트
        Thread thread1 = new Thread(() -> {
            productService.updateProductPrice(product.getId(), 200.0);
        });

        // 두 번째 트랜잭션: 상품 가격을 300.0으로 업데이트
        Thread thread2 = new Thread(() -> {
            assertThrows(ObjectOptimisticLockingFailureException.class, () -> {
                productService.updateProductPrice(product.getId(), 300.0);
            });
        });

        // 두 스레드를 동시에 실행
        thread1.start();
        thread2.start();

        // 두 스레드가 종료될 때까지 대기
        thread1.join();
        thread2.join();
    }
}

실행 결과

• @Version 어노테이션을 통해 아래와 같이 version 컬럼이 생성된 것을 확인할 수 있다.

데드 락

• 데이터베이스 환경에서 데드락은 두 개 이상의 트랜잭션이 서로가 점유하고 있는 자원을 기다리면서 영원히 대기 상태에 빠지는 상황을 의미한다.
• 이 상황이 발생하면 해당 트랜잭션들은 더 이상 진행될 수 없고, 시스템 성능에 큰 영향을 미칠 수 있다.

예시

• 트랜잭션 A는 테이블 X의 일부 행을 잠금(Lock)하고, 이후 테이블 Y의 행을 잠금하려고 한다.
• B는 테이블 Y의 일부 행을 잠금하고, 이후 테이블 X의 행을 잠금하려고 한다.
• 이 경우, 트랜잭션 A와 트랜잭션 B는 서로 상대방이 보유한 잠금을 기다리면서 영원히 대기하게 되며, 이로 인해 데드락이 발생한다.

DB 복제 지연

복제 지연이란?

• 데이터가 쓰기 DB에서 읽기 DB로 복제되는 과정에서 발생하는 시간 지연을 의미

• 복제 지연으로 인해, 읽기 DB에서 최신 상태의 데이터를 읽지 못하고 이전 상태의 데이터를 읽게 되는 문제가 발생할 수 있음

• 시스템에서는 일반적으로 다음과 같은 방식으로 데이터베이스를 운영한다

  • 쓰기 DB: 모든 쓰기 작업(데이터 삽입, 업데이트, 삭제 등)을 처리하는 데이터베이스입니다. 보통 마스터(master) 데이터베이스라고도 한다.
  • 읽기 DB: 읽기 작업만 처리하는 데이터베이스로, 보통 슬레이브(slave) 데이터베이스 또는 리플리카(replica)라고 한다. 이 데이터베이스는 쓰기 DB에서 복제(replication)된 데이터를 사용한다.

문제 발생 예시

• 쓰기와 읽기 DB가 분리된 시스템에서는 쓰기 작업이 일어난 후, 그 변경 내용이 읽기 DB로 복제되기까지 시간이 걸린다. 이 지연으로 인해 다음과 같은 상황이 발생할 수 있다.

  1. 쓰기 작업: 애플리케이션이 쓰기 DB에 새로운 데이터를 저장한다.
  2. 지연: 이 데이터는 복제 지연 때문에 즉시 읽기 DB에 반영되지 않는다.
  3. 읽기 작업: 쓰기 작업 직후에 애플리케이션이 읽기 DB에서 데이터를 조회하려고 한다.
  4. 이전 데이터 조회: 이 시점에서 읽기 DB는 아직 새로운 데이터를 반영하지 않았기 때문에, 이전 데이터를 반환할 수 있다.

해결 방법

• 지연 적용 알고리즘 (Lag Compensating Logic)
  • 쓰기 후 즉시 읽기를 시도하는 경우, 잠시 지연을 두고 읽기를 재시도하는 방법

• 쓰기 DB로의 직접 읽기 (Read-after-Write)

  • 중요한 데이터에 대해 쓰기 직후 즉시 읽어야 하는 경우, 해당 읽기 작업을 쓰기 DB에서 직접 수행하도록 하는 방법

• 읽기 DB와 쓰기 DB 간의 복제 지연 최소화

  • 복제 지연을 최소화하도록 데이터베이스 설정을 조정할 수 있다. 예를 들어, MySQL의 경우 복제 지연을 줄이기 위해 semi-synchronous replication을 사용하거나, 다른 복제 설정을 최적화할 수 있다.

• CQRS 패턴

  • Command Query Responsibility Segregation (CQRS) 패턴을 적용하여, 쓰기 작업과 읽기 작업을 명확히 분리하고, 읽기 작업에 대해 일관성을 보장하는 별도의 메커니즘을 적용할 수 있다.
  • 예를 들어, 쓰기 DB의 변경이 읽기 DB에 완전히 반영된 후에야 읽기 작업을 허용하는 방식을 도입할 수 있다.

• 캐시 사용

  • 캐시 시스템을 도입하여, 쓰기 작업 후 바로 캐시를 갱신하고, 그 이후의 읽기 작업은 캐시에서 제공하는 방식을 사용한다. 캐시는 일관성을 보장하기 위해 일정 시간 동안(예: 1초) 쓰기 DB의 데이터를 캐시하는 방법을 사용할 수 있다.

메모리 릭

메모리 릭이란?

• 메모리 릭(Memory Leak)은 프로세스가 더 이상 필요하지 않은 메모리를 할당한 후 이를 해제하지 않음으로써, 해당 메모리가 지속적으로 점유된 상태로 남아있는 현상을 말한다.

• Spring에서의 예시를 들어 보면, @Autowired 주입된 객체의 잘못된 관리, 스프링 빈의 라이프사이클 관리 문제, ThreadLocal의 잘못된 사용, 이벤트 리스너의 잘못된 관리 등이 있다.

• 이러한 메모리 릭은 메모리 사용량을 지속적으로 증가시켜, 결국에는 시스템의 메모리를 고갈시켜 성능 저하 또는 애플리케이션의 충돌을 유발할 수 있다.

• 메모리를 점유하는 객체의 경우 반드시 제거(해제)하여주도록 하자!

캐시 압력(Cache Pressure)

캐시 압력이란?

• 캐시 압력은 캐시 메모리가 부족해지면서 발생하는 문제를 말한다. 캐시가 가득 차서 더 이상 새로운 데이터를 저장할 수 없고, 이로 인해 기존 데이터를 삭제해야 하는 상황이 발생할 수 있다.
• 캐시 압력이 증가하면, 캐시 항목을 삭제하거나 새 데이터를 캐시에 저장하는 동안 대기 상태가 발생할 수 있다.

해결 방법

1. 캐시 제한 설정:
   • TTL(Time-To-Live): 캐시 항목에 TTL을 설정하여 일정 시간 후에 자동으로 만료되도록 설정할 수 있다. 이를 통해 오래된 캐시 데이터를 자동으로 제거하고, 새로운 항목을 저장할 공간을 확보할 수 있다.
   • 최대 캐시 크기 설정: 사용자별 페이징 데이터에 대해 캐시의 최대 크기를 설정하여, 용량이 초과되면 오래된 데이터를 자동으로 제거하도록 할 수 있다.
2. 페이징 전략 최적화:
   • 부분적 캐싱: 모든 페이지를 캐싱하기보다는 자주 요청되는 특정 페이지만을 캐싱하여, 캐시 공간을 효율적으로 사용할 수 있다.
   • 데이터베이스 인덱스 최적화: 캐시를 사용하는 대신, 데이터베이스 인덱스를 최적화하여 페이징 성능을 향상시킬 수 있다. 이렇게 하면 캐시 의존도를 줄이고, 데이터베이스에서 더 빠르게 결과를 가져올 수 있다.
3. 분산 캐시 사용:
   • Redis와 같은 분산 캐시 시스템을 사용하여, 여러 서버에 캐시 데이터를 분산시킬 수 있다. 이를 통해 한 서버의 메모리 용량 한계를 극복하고, 캐시 성능을 높일 수 있다.
4. 캐시 우회 전략:
   • 특정 조건에서 캐시를 우회하고 직접 데이터베이스에서 데이터를 가져오는 전략을 사용할 수 있다. 예를 들어, 페이징 요청이 매우 세분화된 경우 캐시를 우회하도록 설정할 수 있다.

설정 버전 관리 (Configuration Versioning)

설정 버전 관리란?

• 애플리케이션의 설정 데이터를 시간이나 버전별로 관리하는 방법을 의미한다. 최신 설정 데이터를 항상 사용할 수 있도록 각 설정에 버전(또는 날짜)을 부여하고, 이를 기반으로 최신 설정을 조회하고 적용하는 방식이다.

설정 버전 관리의 장점

• 빠른 롤백
  • 설정 버전 관리를 통해 이전 버전의 설정 데이터를 보관하면, 장애가 발생했을 때 문제가 있는 최신 설정을 신속하게 이전 버전으로 롤백할 수 있다. 이는 서비스의 가동 중단 시간을 최소화하고, 문제를 빠르게 해결하는 데 큰 도움이 된다.
• 변경 이력 추적
  • 각 설정이 버전별로 관리되기 때문에, 어떤 설정이 언제 변경되었는지 쉽게 추적할 수 있다. 이는 문제의 원인을 분석할 때 유용하며, 특정 설정 변경이 문제를 유발했는지 확인할 수 있다.
• 테스트와 배포 용이성
  • 새로운 설정을 적용하기 전에 테스트 환경에서 해당 설정을 미리 적용해보고, 문제가 없다고 판단되면 실제 운영 환경에 적용할 수 있다. 이를 통해 설정 변경으로 인한 장애 발생 가능성을 줄일 수 있다.
• 신속한 복구
  • 장애 발생 시 최신 설정을 빠르게 적용하거나, 문제가 된 설정을 즉시 변경할 수 있다. 또한, 설정의 버전 관리 덕분에 복구 작업이 체계적으로 이루어질 수 있다.
• 일관된 설정 관리
  • 설정 데이터를 체계적으로 관리함으로써, 장애 발생 시에도 일관된 설정을 유지할 수 있다. 이로 인해 설정 오류로 인한 장애를 예방할 수 있다.
• 가시성 향상
  • 설정 변경 사항이 명확하게 기록되고 관리되므로, 모든 팀원이 설정 상태를 명확히 파악할 수 있다. 이는 장애 대응을 위한 의사소통과 협업을 개선한다.

설정 버전 관리의 단점

• 복잡성 증가: 여러 버전의 설정을 관리하는 것이 복잡성을 초래할 수 있다. 특히 버전 수가 많아질수록 관리가 어려워질 수 있다.
• 저장 공간 부담: 여러 버전의 설정 데이터를 저장하는 데 필요한 저장 공간이 늘어나며, 시간이 지남에 따라 상당한 용량을 차지할 수 있다.
• 인적 오류 가능성: 잘못된 버전을 관리하거나 롤백할 때 실수가 발생할 수 있어 복구 과정을 복잡하게 만들 수 있다.

예시

• 설정 엔티티 생성

    @Entity
    public class CoreSetting {
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        private Long id;

        @Column(columnDefinition = "jsonb")
        private String configData;

        private LocalDateTime version;

        @CreationTimestamp
        private LocalDateTime createdAt;

        // Getters and Setters

• 데이터 저장 예시

    CoreSetting coreSetting = new CoreSetting();
    coreSetting.setSettings("{\"theme\": \"dark\", \"notifications\": \"enabled\"}");
    coreSetting.setVersion(LocalDateTime.now());
    coreSettingRepository.save(coreSetting);

• 리포지토리 예시

    public interface CoreSettingRepository extends JpaRepository<CoreSetting, Long> {

        @Query(value = "SELECT * FROM CoreSetting ORDER BY version DESC LIMIT 1", nativeQuery = true)
        Optional<CoreSetting> findLatestCoreSetting();
    }

• 사용

    Optional<CoreSetting> latestCoreSetting = coreSettingRepository.findLatestCoreSetting();
    latestCoreSetting.ifPresent(setting -> {
        // 최신 설정 데이터 사용
    });

• 어제에 이어 장애 분석 및 진단, 장애 복구, 후속 조치 및 사후평가 개선, 예방 조치 등 장애 대응에 대한 이론들을 수강하였다.
• DB Lock의 개념에 대해 수강하고 비관적 락 실습을 진행하였다. 오늘은 이 부분을 중심으로 TIL을 작성해보려 한다.

DB Lock

DB Lock이란?

• DB 락(Database Lock)은 데이터베이스에서 여러 트랜잭션이 동시에 같은 데이터에 접근할 때, 데이터의 무결성(일관성)을 보장하기 위해 사용되는 메커니즘이다.
• 쉽게 말해, 한 트랜잭션이 특정 데이터에 대해 작업을 하고 있을 때 다른 트랜잭션이 그 데이터에 접근하지 못하도록 잠그는 것이다.
• 이로써 데이터의 일관성을 유지하고, 동시에 발생할 수 있는 충돌을 방지할 수 있다.

DB Lock의 필요성

• 데이터베이스는 여러 사용자나 시스템이 동시에 데이터를 읽고 쓰는 환경에서 운영된다. 이러한 환경에서 문제가 발생할 수 있는 대표적인 사례는 다음과 같다.
  • Dirty Read (더티 리드): 한 트랜잭션이 데이터를 수정 중일 때 다른 트랜잭션이 그 데이터를 읽는 상황. 만약 첫 번째 트랜잭션이 롤백된다면, 두 번째 트랜잭션은 잘못된 데이터를 읽은 것이 된다.
  • Non-repeatable Read (반복 불가능한 읽기): 한 트랜잭션이 데이터를 읽은 후, 다른 트랜잭션이 그 데이터를 수정하고 커밋하여 첫 번째 트랜잭션이 동일한 데이터를 다시 읽을 때 값이 달라지는 상황
  • Lost Update (업데이트 손실): 두 개의 트랜잭션이 동시에 같은 데이터를 수정하려고 할 때, 한 트랜잭션의 수정 내용이 다른 트랜잭션에 의해 덮어쓰여져 사라지는 상황

• DB 락을 통해 데이터에 대한 접근을 제어하면, 위와 같은 상황에서 발생할 수 있는 데이터 무결성 문제를 예방할 수 있다!

DB 락의 종류

• 공유 락 (Shared Lock, S Lock)

  • 공유 락은 데이터베이스에서 데이터를 읽을 때 사용된다. 여러 트랜잭션이 동시에 같은 데이터를 읽을 수 있지만, 공유 락이 걸린 동안에는 데이터를 수정할 수 없다.

• 배타 락 (Exclusive Lock, X Lock)

  • 배타 락은 데이터를 수정할 때 사용된다. 배타 락이 걸린 데이터는 다른 트랜잭션이 읽거나 수정할 수 없다. 한 트랜잭션이 배타 락을 획득하면 다른 모든 트랜잭션은 해당 데이터에 접근할 수 없다.

• 비관적 락 (Pessimistic Locking)

  • 비관적 락은 데이터를 읽을 때부터 락을 걸어 다른 트랜잭션이 접근하지 못하도록 하는 방식이다. 데이터의 충돌 가능성이 높을 때 유용하다.

• 낙관적 락 (Optimistic Locking)

  • 낙관적 락은 데이터를 수정하기 전까지 락을 걸지 않고, 수정 시점에만 충돌을 확인하는 방식이다. 주로 데이터의 버전 번호를 사용하여 동시성 문제를 해결한다.

• 명명된 락 (Named Lock)

  • 명명된 락은 데이터베이스에서 특정 이름으로 락을 설정하여, 동시에 하나의 프로세스만 특정 리소스에 접근하도록 하는 방식이다. 주로 특정 리소스나 작업에 대한 접근을 직관적으로 제어하기 위해 사용된다.

• 분산 락 (Distributed Lock)

  • 분산 락은 여러 시스템이나 인스턴스에서 동시에 동일한 자원에 접근할 때, 자원의 일관성을 유지하기 위해 사용되는 락이다. Redis와 같은 분산 시스템을 사용하여 구현된다.

비관적 락 실습

• start.spring.io 에서 프로젝트를 생성합니다. 디펜던시는 아래와 같이 구성한다.

• sql 로깅을 위해 아래와 같이 application.propertise를 구성한다.

spring.application.name=locking

spring.jpa.properties.hibernate.format_sql=true
spring.jpa.properties.hibernate.use_sql_comment=true

logging.level.org.hibernate.SQL=debug
logging.level.org.hibernate.orm.jdbc.bind=TRACE

• 비관적 락의 동작 방식

  • 락의 개념: 비관적 락은 데이터에 대한 접근을 제어하기 위해 사용된다. 데이터베이스에서 특정 행(row)이나 테이블에 대해 락을 걸어, 다른 트랜잭션이 동시에 동일한 데이터에 접근하거나 수정하지 못하도록 한다.
  • 락의 종류:
    • PESSIMISTIC_READ: 읽기 락(Shared Lock)을 설정하여 다른 트랜잭션이 해당 데이터를 읽을 수는 있지만, 수정은 할 수 없도록 한다.
    • PESSIMISTIC_WRITE: 쓰기 락(Exclusive Lock)을 설정하여 다른 트랜잭션이 해당 데이터를 읽거나 수정하지 못하도록 한다.
  • DB 레벨에서의 락 동작:
    • 락 설정: 비관적 락을 사용하면 SQL 쿼리나 트랜잭션이 데이터베이스에 접근할 때 락이 설정된다. 예를 들어, PESSIMISTIC_WRITE 락을 설정하면, 해당 데이터에 대한 모든 읽기 및 쓰기 작업이 락이 해제될 때까지 대기하게 된다.
    • 락 해제: 락은 일반적으로 트랜잭션이 종료되거나 커밋될 때 해제된다. 트랜잭션이 커밋되면 락이 해제되어 다른 트랜잭션이 해당 데이터에 접근할 수 있게 된다. 트랜잭션이 롤백되는 경우에도 락이 해제된다.

• 비관적 락은 주로 데이터베이스 레벨에서 동작하며, 데이터의 무결성을 보장하는 데 매우 유용하다.

• 그러나 성능에 영향을 미칠 수 있으므로, 데이터 충돌 가능성이 높은 환경에서 신중하게 사용해야 한다.

• 스프링 부트와 같은 애플리케이션에서 비관적 락을 설정하면, 데이터베이스가 이 락을 처리하고 관리하게 된다.

• 실습

  • Item.java

      import jakarta.persistence.Entity;
      import jakarta.persistence.GeneratedValue;
      import jakarta.persistence.GenerationType;
      import jakarta.persistence.Id;
      import lombok.Data;
    
      @Data
      @Entity
      public class Item {
          @Id
          @GeneratedValue(strategy = GenerationType.IDENTITY)
          private Long id;
    
          private String name;
          private Integer quantity;
      }

  • ItemRepository.java

      import jakarta.persistence.LockModeType;
      import org.springframework.data.jpa.repository.JpaRepository;
      import org.springframework.data.jpa.repository.Lock;
      import org.springframework.data.jpa.repository.Query;
    
      public interface ItemRepository extends JpaRepository<Item, Long> {
          @Lock(LockModeType.PESSIMISTIC_WRITE)  // 비관적 락 적용
          @Query("select i from Item i where i.id = :id")
          Item findByIdWithLock(Long id);
      }
    

  • ItemService.java

      import lombok.RequiredArgsConstructor;
      import org.springframework.stereotype.Service;
      import org.springframework.transaction.annotation.Transactional;
    
      @Service
      @RequiredArgsConstructor
      public class ItemService {
    
          private final ItemRepository itemRepository;
    
          @Transactional
          public void updateItemQuantity(Long itemId, Integer newQuantity) {
              // 비관적 락을 사용하여 데이터를 조회합니다.
              Item item = itemRepository.findByIdWithLock(itemId);
    
              // 재고 수량을 수정합니다.
              item.setQuantity(newQuantity);
    
              // 수정된 데이터를 저장합니다.
              itemRepository.save(item);
          }
    
          @Transactional
          public Item findItemById(Long itemId) {
              // 비관적 락 없이 데이터를 조회합니다.
              return itemRepository.findById(itemId).orElse(null);
          }
      }
    

  • ItemServiceTest.java

      import org.junit.jupiter.api.Test;
      import org.slf4j.Logger;
      import org.slf4j.LoggerFactory;
      import org.springframework.beans.factory.annotation.Autowired;
      import org.springframework.boot.test.context.SpringBootTest;
    
      @SpringBootTest
      public class ItemServiceTest {
    
          private static final Logger logger = LoggerFactory.getLogger(ItemServiceTest.class);
    
          @Autowired
          private ItemService itemService;
    
          @Autowired
          private ItemRepository itemRepository;
    
          @Test
          public void testPessimisticLocking() throws InterruptedException {
              // 초기 데이터 설정
              logger.info("초기 아이템 데이터를 설정합니다.");
              Item item = new Item();
              item.setName("Item 1");
              item.setQuantity(10);
              itemRepository.save(item);
    
              // 첫 번째 트랜잭션: 아이템 수량을 20으로 업데이트
              Thread thread1 = new Thread(() -> {
                  logger.info("스레드 1: 아이템 수량 업데이트를 시도합니다.");
                  itemService.updateItemQuantity(item.getId(), 20);
                  logger.info("스레드 1: 아이템 수량 업데이트 완료.");
              });
    
              // 두 번째 트랜잭션: 아이템 수량을 30으로 업데이트
              Thread thread2 = new Thread(() -> {
                  logger.info("스레드 2: 아이템 수량 업데이트를 시도합니다.");
                  itemService.updateItemQuantity(item.getId(), 30);
                  logger.info("스레드 2: 아이템 수량 업데이트 완료.");
              });
    
              // 두 스레드를 동시에 실행
              thread2.start();
              thread1.start();
    
              // 두 스레드가 종료될 때까지 대기
              thread1.join();
              thread2.join();
    
              // 최종 결과를 확인합니다.
              Item updatedItem = itemService.findItemById(item.getId());
              logger.info("최종 아이템 수량: {}", updatedItem.getQuantity());
          }
      }

    • 결과
  • SQL문을 잘 살펴 보면 마지막에 for update가 있는 것을 확인할 수 있다. Locking이 잘 되었다는 것을 의미한다.

• 시큐어 코딩 내용을 수강하며 SQL Injection과 그 외의 각종 보안 문제에 대해 학습했다.

• 장애 대응 강의를 수강하며 모니터링, 장애 분석 및 진단에 관하여 학습하였다.

SQL Injection

• 예전 CS공부를 할 때 부터 많이 학습했던 부분이다. SQL Injection이란 공격자가 웹 애플리케이션의 데이터베이스를 조작하거나 민감한 정보를 탈취하는 공격이다. 이 취약점은 애플리케이션이 사용자 입력을 제대로 검증하지 않을 때 발생한다.

SQL Injection의 위험성

• 데이터 탈취: 공격자가 데이터베이스에서 민감한 정보를 탈취할 수 있다.
• 데이터 변조: 데이터베이스의 데이터를 변경하거나 삭제할 수 있다.
• 권한 상승: 공격자가 데이터베이스 관리자 권한을 얻을 수 있다.
• 전체 시스템 장악: 심각한 경우 서버 전체를 장악할 수 있다.

SQL injection 공격 예시

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class SqlInjectionExample {
    public static void main(String[] args) {
        String username = "admin'; --";
        String password = "password";
        String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

        try (Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/testdb", "root", "password");
             Statement stmt = conn.createStatement();
             ResultSet rs = stmt.executeQuery(query)) {

            if (rs.next()) {
                System.out.println("User authenticated");
            } else {
                System.out.println("Authentication failed");
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

1. 공격자는 username 필드에 admin'; --를 입력한다.
2. SQL 쿼리는 SELECT * FROM users WHERE username = 'admin'; --' AND password = 'password'로 변경된다.
3. --는 SQL 주석 처리 기호로, 이후의 코드는 무시된다.
4. 결과적으로 쿼리는 SELECT * FROM users WHERE username = 'admin';가 되어, 공격자가 비밀번호를 입력하지 않아도 인증이 된다.

SQL Injection 방어 기법

• Prepared Statements (준비된 문): SQL 쿼리를 미리 컴파일하여 파라미터화된 쿼리를 사용한다.

• Stored Procedures (저장 프로시저): 데이터베이스에서 미리 정의된 저장 프로시저를 호출하여 실행한다.

• ORM (객체 관계 매핑): Hibernate 같은 ORM 프레임워크를 사용하여 데이터베이스 접근을 추상화한다.

  • 예시

    • Hibernate와 같은 ORM 프레임워크를 사용할 경우, 내부적으로 Prepared Statement를 사용하여 SQL Injection 공격을 방지한다. Spring Data JPA를 사용하는 경우에도 이에 해당함!

      import org.hibernate.Session;
      import org.hibernate.SessionFactory;
      import org.hibernate.cfg.Configuration;
      
      import java.util.List;
      
      public class HibernateExample {
        public static void main(String[] args) {
            Configuration cfg = new Configuration().configure();
            SessionFactory sessionFactory = cfg.buildSessionFactory();
            Session session = sessionFactory.openSession();
      
            String username = "admin"; // 사용자 입력으로부터 받은 값
            String password = "password"; // 사용자 입력으로부터 받은 값
      
            // HQL (Hibernate Query Language) 쿼리
            String hql = "FROM User WHERE username = :username AND password = :password";
      
            List<User> users = session.createQuery(hql)
                                      .setParameter("username", username)
                                      .setParameter("password", password)
                                      .list();
      
            if (!users.isEmpty()) {
                System.out.println("User authenticated");
            } else {
                System.out.println("Authentication failed");
            }
      
            session.close();
            sessionFactory.close();
        }
      }

• 입력 검증 및 인코딩: 사용자 입력을 철저히 검증하고 인코딩하여 SQL 쿼리에 직접 포함시키지 않는다.

• 최소 권한 원칙: 데이터베이스 사용자에게 최소한의 권한만 부여한다.

그 외 보안 문제들

Open Redirect

• Open Redirect는 공격자가 웹 애플리케이션의 리디렉션 기능을 악용하여 사용자를 악성 사이트로 유도하는 공격

Directory Traversal

• Directory Traversal은 공격자가 웹 애플리케이션의 파일 시스템에서 허용되지 않은 파일이나 디렉토리에 접근할 수 있도록 하는 공격

Clickjacking

• Clickjacking은 공격자가 웹 페이지의 투명한 프레임을 사용하여 사용자가 클릭하도록 유도하는 공격이다. 이를 통해 공격자는 사용자가 알지 못하는 사이에 악성 동작을 수행할 수 있다.

Sensitive Data Exposure

• Sensitive Data Exposure는 애플리케이션이 민감한 데이터를 충분히 보호하지 않아 공격자가 이를 탈취하는 공격이다.
• 민감한 데이터가 안전하게 저장되거나 전송되지 않을 때 발생한다. 예를 들어, 비밀번호가 평문으로 저장되거나, 신용카드 정보가 암호화되지 않은 채로 전송되는 경우가 있다.
• 이와 같이 비밀번호나 신용카드 정보와 같은 정보를 암호화하지 않고 평문으로 저장할 경우 정보통신망법 위반!
• 따라서 HTTPS(HyperText Transfer Protocol Secure) 사용 또한 필수

Insecure Deserialization

• Insecure Deserialization은 공격자가 악의적으로 조작된 객체를 애플리케이션에 전달하여 실행시키는 공격이다.
• 이를 통해 공격자는 시스템 내에서 임의의 코드를 실행하거나 데이터를 조작할 수 있다.
• 애플리케이션이 직렬화된 데이터를 역직렬화할 때, 해당 데이터가 신뢰할 수 있는지 검증하지 않으면 공격자가 악의적으로 조작된 직렬화 데이터를 주입할 수 있다.
• 이를 통해 공격자는 애플리케이션에서 임의의 코드를 실행하거나 데이터를 조작할 수 있다.

Insufficient Logging & Monitoring

• Insufficient Logging & Monitoring은 애플리케이션이 적절한 로그를 기록하지 않거나, 이상 행동을 감시하지 않아 공격을 조기에 발견하지 못하는 경우이다.

CVE, CVSS

• CVE (Common Vulnerabilities and Exposures)는 특정 소프트웨어 및 하드웨어의 취약점을 고유하게 식별하기 위해 사용되는 표준화된 명명 시스템이다. CVSS 점수는 0에서 10까지의 범위로, 낮은 점수는 덜 심각한 취약점을, 높은 점수는 매우 심각한 취약점을 나타낸다.

장애 식별

❓ 그렇다면 어떻게 고객보다 먼저 장애를 파악하고 조치를 취할 수 있을까?

모니터링

• 이전에 모니터링 실습을 진행했던 것 처럼 Prometheus, Grafana 등의 툴을 통해 시스템의 성능 상태, 장애를 모니터링하고 초기에 이를 진단할 수 있다. (이전 포스팅 👉 (클릭))

• 모니터링 기술을 크게 세 가지로 정리해보자.

시스템 모니터링

• 리소스 사용량 추적: CPU, 메모리, 디스크 I/O, 네트워크 대역폭 등의 리소스 사용량을 실시간으로 모니터링한다. 이는 시스템의 성능 병목을 조기에 식별하는 데 중요하다.

• 서버 및 애플리케이션 상태: 서버의 가용성, 응답 시간, 오류 로그 등을 모니터링하여 서버 상태와 애플리케이션의 작동 여부를 점검한다.

• 장애 예측: 머신러닝 기반의 예측 분석을 통해 리소스 사용 패턴을 학습하고, 이상 패턴을 사전에 감지하여 장애를 예방할 수 있다.

애플리케이션 모니터링

• 로그 모니터링: 애플리케이션 로그를 실시간으로 수집 및 분석하여 오류나 예외를 조기에 탐지한다. 중앙 집중형 로그 관리 시스템을 통해 모든 로그를 통합하고 분석하는 것이 효과적이다.

• 성능 모니터링: 애플리케이션의 응답 시간, 처리량(throughput), 오류율 등을 측정하여 성능 문제를 조기에 식별한다. APM(Application Performance Monitoring) 도구를 활용하여 성능 병목을 탐지할 수 있다.

• 서비스 헬스 체크: 서비스의 상태를 주기적으로 점검하는 헬스 체크를 구현하여, 서비스의 정상 동작 여부를 확인하고 장애 발생 시 자동으로 알림을 받을 수 있다.

사용자 경험 모니터링

• 엔드-투-엔드 모니터링: 사용자가 서비스를 사용하는 전체 경로를 모니터링하여, 실제 사용자 경험을 기반으로 장애를 식별한다. 사용자 지연, 실패한 요청 등의 데이터를 수집한다. (ex. 셀레니움)

• 사용자 피드백 수집: 고객 지원 채널을 통해 사용자 피드백을 수집하고, 이를 분석하여 잠재적인 문제를 조기에 식별한다.

• 리얼 유저 모니터링 (RUM): 실제 사용자의 웹 브라우저에서 데이터를 수집하여 페이지 로드 시간, 응답시간 등을 모니터링하고 사용자 경험을 개선한다. (ex. 구글 애널리틱스)

모니터링 고려사항

• 지속적인 모니터링 및 개선: 모니터링 시스템은 정기적으로 점검하고 조정하여 최신 상태를 유지해야 한다.

• 중앙 집중식 로그 관리: 로그는 한 곳에 모아 분석하여 시스템의 전반적인 상태를 명확하게 파악할 수 있어야 한다.

• 협업과 공유: 모니터링 데이터를 팀 간에 공유하여 보다 효과적인 장애 대응이 가능하도록 한다.

• 테스트 및 시뮬레이션: 장애 시나리오를 테스트하고 모니터링 시스템이 정확하게 작동하는지 검증한다.

장애 분석 및 진단

1. 초기 대응

• 장애 보고 및 인지
  • 장애 보고 체계 확립: 누군가가 계속해서 모니터링을 하기에는 실 서비스에서는 많은 인프라가 동작하고 있다. 자동 알림 시스템을 통해 장애 발생을 즉시 인지할 수 있도록 설정한다. 이전 포스팅에서 실습을 진행했던 슬랙을 통한 그라파나 Alert 설정 등이 있다.
  • 장애 상황 인지: 장애 발생 시, 즉시 관련 팀에게 통보하여 초동 조치를 취할 수 있도록 한다.
• 초기 평가
  • 장애의 심각도 평가: 장애의 영향을 평가하여 우선순위를 정한다. 서비스 중단, 성능 저하, 데이터 손상 등의 영향을 고려한다.
  • 초기 대응 전략 수립: 장애 상황에 맞는 초기 대응 계획을 수립하고, 관련 리소스를 할당한다.
• 장애 원인 분석
  • 문제 재현: 장애 상황을 재현하여 근본 원인을 명확히 파악한다. 이를 통해 동일한 상황에서 재발 방지를 위한 구체적인 조치를 설계할 수 있다.
  • 장애 패턴 인식: 장애 로그와 메트릭을 기반으로 과거 유사한 장애 패턴을 분석하여 패턴에 따른 원인을 찾아낸다.

2. 로그 및 메트릭 분석

👉 가장 먼저 분석해야 할 사항은 로그 및 메트릭!

• 로그 분석
  • 로그 수집: 중앙 집중식 로그 관리 시스템에서 로그 데이터를 수집하고 분석한다.
  • 오류 및 예외 분석: 로그를 통해 애플리케이션에서 발생한 오류와 예외를 추적하여 장애의 원인을 파악한다.
  • 로그 패턴 분석: 패턴 인식을 통해 과거의 유사한 장애 사례를 파악하고 대응책을 도출한다.
• 메트릭 분석
  • 실시간 메트릭 모니터링: CPU 사용률, 메모리 사용량, 네트워크 트래픽 등 실시간 메트릭을 모니터링하여 비정상적인 활동을 탐지한다.
  • 메트릭 데이터 비교: 정상 상태와 장애 상태의 메트릭을 비교하여 이상 현상을 식별한다.
  • 임계값 분석: 설정된 임계값을 초과하는 메트릭을 확인하여 장애의 징후를 발견한다.

3. 시스템 및 네트워크 분석

• 시스템 분석
  • 프로세스 상태 점검: 시스템에서 실행 중인 프로세스를 점검하여 비정상적으로 작동 중인 프로세스를 식별한다.
  • 리소스 사용 추적: 시스템 리소스(CPU, 메모리, 디스크 I/O)의 과도한 사용을 추적하여 장애의 원인을 분석한다.
  • 스레드 덤프 분석: JVM 스레드 덤프를 분석하여 교착 상태(데드락) 및 스레드 고갈 문제를 진단한다.
• 네트워크 분석
  • 네트워크 트래픽 모니터링: 네트워크 트래픽을 분석하여 패킷 손실, 지연, 대역폭 초과 등의 문제를 식별한다.
  • 네트워크 토폴로지 점검: 네트워크 구조를 점검하여 구성상의 문제를 진단한다.
  • 연결 상태 분석: 외부 시스템 및 API와의 연결 상태를 점검하여 네트워크 장애를 진단한다.

4. 데이터베이스 분석

• 쿼리 성능 분석
  • 슬로우 쿼리 로그 분석: 성능이 저하된 쿼리를 식별하고, 인덱스 최적화 및 쿼리 재작성으로 해결한다.
  • 데이터베이스 락 분석: 락 대기 및 데드락 상황을 식별하고 해결책을 찾는다.
  • 커넥션 풀 상태 점검: 데이터베이스 커넥션 풀의 상태를 점검하여 연결 문제를 진단한다.
• 데이터 일관성 점검
  • 데이터 무결성 확인: 데이터베이스의 무결성을 점검하여 데이터 손상 여부를 확인한다.
  • 데이터 복구 절차 실행: 손상된 데이터의 복구 절차를 실행하여 데이터베이스의 정상 상태를 복구한다.

결론

가장 좋은 방법은 장애가 일어나지 않도록 하는 것❗

• 설계 단계에서 협업자와 충분한 대화를 나눌 것

• 프로젝트에서 무언가 이상한 로직을 발견했다면( ex) 무한 루프 가능성이 있는 함수 코드 등 ) 해당 사항을 인지하고 그냥 놔둔것 같은 느낌(이것도 못봤을까??)이 들더라도 해당 영역 작업자와 반드시 논의해볼 것

• 프로젝트가 배포되더라도 지속적인 모니터링 및 보안에 힘쓸 것

모니터링 시스템 및 시큐어 코딩 관련 강의들을 수강하며 여러 가지를 배웠다.

모니터링 시스템이 무엇인지 이론적으로 간단하게 학습했고, Spring Boot Actutor, Prometheus, Grafana, loki 실습을 진행하였으며 CORS, CSRF에 대해 학습을 진행하였다.

이번 TIL 에서는 그 중 Prometheus, Grafana 실습, CORS, CSRF를 학습하며 있었던 내용들을 중심적으로 작성해보려 한다.

Prometheus

Prometheus란?

• 오픈소스 시스템 모니터링 및 경고 도구

• SoundCloud에서 시작되어 현재는 Cloud Native Computing Foundation(CNCF)에서 호스팅하고 있다.

• Prometheus는 시계열 데이터베이스를 사용하여 메트릭 데이터를 수집하고, 쿼리 및 시각화를 통해 시스템 상태를 모니터링하고 경고를 설정할 수 있다.

주요 구성 요소

• Prometheus 서버:

  • 메트릭 데이터를 수집하고 저장하는 핵심 컴포넌트이다. 각 타겟으로부터 데이터를 주기적으로 스크랩(scrape)하여 시계열 데이터베이스에 저장한다.
  • 시계열 데이터베이스(Time Series Database, TSDB)는 시간에 따라 변화하는 데이터를 효율적으로 저장하고 조회할 수 있도록 최적화된 데이터베이스이다.

• Exporters:

  • Prometheus는 기본적으로 애플리케이션에서 메트릭 데이터를 수집한다.
  • Exporter는 특정 애플리케이션이나 시스템의 메트릭 데이터를 Prometheus가 이해할 수 있는 형식으로 변환해주는 도구이다.

• Pushgateway:

  • 짧은 수명의 작업(job)에서 메트릭을 수집하여 Prometheus 서버에 푸시(push)할 수 있다.
  • 일반적으로 지속적으로 실행되지 않는 작업에서 사용된다. 예를 들어 배치 작업, 스크립트 실행, 크론 작업 등이 있다.

• Alertmanager:

  • Prometheus 서버에서 발생하는 경고(alert)를 처리하고, 이메일, PagerDuty, Slack 등 다양한 방법으로 알림을 보낼 수 있다.

• Grafana:

  • Prometheus 데이터를 시각화하기 위해 자주 사용되는 대시보드 도구이다.
  • Grafana를 사용하면 Prometheus에서 수집한 메트릭 데이터를 대시보드 형태로 시각화할 수 있다.

실습

• Prometheus 를 보다 쉽게 설치하기 위해서 Docker 를 사용한다. 이후 Grafana에서도 동일하게 Docker를 사용할 예정이다.

• 먼저 스프링 프로젝트 부터 생성한다. 아래와 같이 디펜던시를 구성한다.

  

• application.properties

    spring.application.name=sample
  
    server.port=8080
  
    #모든 엔드포인트 노출 설정
    management.endpoints.web.exposure.include=* 
  
    #헬스 체크 엔드포인트 상세 정보 표시 설정
    management.endpoint.health.show-details=always # 이 설정은 /actuator/health 엔드포인트에서 헬스 체크 정보를 항상 상세히 보여주도록 설정합니다. 기본적으로, 헬스 체크 엔드포인트는 요약된 상태 정보만 제공하며, 상세 정보는 노출되지 않습니다.
  
    management.endpoint.prometheus.enabled=true

• http://localhost:8080/actuator/prometheus 에 접속하여 프로메테우스 매트릭스를 확인할 수 있다.

  

• Prometheus 설정 파일 생성

  • Prometheus가 모니터링할 타겟과 기타 설정을 정의하는 설정 파일(prometheus.yml)을 생성한다.

  • host.docker.internal은 Docker에서 제공하는 특수한 DNS 이름으로, Docker 컨테이너가 호스트 머신(즉, Docker를 실행하는 컴퓨터)의 네트워크 서비스에 접근할 수 있도록 한다. 이를 통해 컨테이너 내부에서 호스트 머신의 네트워크 주소를 참조할 수 있다.

      global:
        scrape_interval: 15s
    
      scrape_configs:
        - job_name: 'spring-boot'
          metrics_path: '/actuator/prometheus'
          static_configs:
            - targets: ['host.docker.internal:8080']

• Prometheus 실행

  • Docker 명령어를 사용해 Prometheus컨테이너를 실행한다.

  • -v 옵션의 앞부분은 방금전 생성한 prometheus.yml의 경로를 포함하여 작성한다.

    docker run -d --name=prometheus -p 9090:9090 -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

• localhost:9090 에 접속해보자.프로메테우스 서버에 접속할 수 있습니다.

  

• 상단 메뉴에서 Status > Targets에 접속하여 스프링 애플리케이션의 매트릭스를 수집하고 있는것을 확인 할 수 있다 (나오지 않는다면 스프링 애플리케이션을 Run하고 있는지 확인한다.)

Grafana

Grafana란?

• 오픈소스 데이터 시각화 및 모니터링 도구

• 다양한 데이터 소스를 지원하여 데이터를 시각화하고 분석할 수 있도록 돕는다.

• Grafana는 대시보드를 생성하고, 데이터를 그래프나 차트 형태로 표현하며 알림 기능을 제공하여 모니터링을 강화할 수 있다.

그라파나 주요기능

• 대시보드 생성:
  • Grafana는 사용자가 데이터를 시각화할 수 있는 대시보드를 생성할 수 있도록 한다. 여러 가지 그래프, 차트, 게이지 등을 사용하여 데이터를 시각적으로 표현할 수 있다.

• 다양한 데이터 소스 지원:
  • Prometheus, InfluxDB, Graphite, Elasticsearch, MySQL, PostgreSQL 등 다양한 데이터 소스를 지원한다. 이를 통해 여러 시스템과 애플리케이션의 데이터를 통합하여 시각화할 수 있다.

• 알림 기능:

  • 조건을 설정하여 조건이 충족되면 이메일, Slack, PagerDuty 등 다양한 채널을 통해 알림을 보낼 수 있다. 이를 통해 시스템 상태를 실시간으로 모니터링하고 문제가 발생했을 때 즉시 대응할 수 있다.

• 플러그인 지원:

  • Grafana는 플러그인 아키텍처를 지원하여, 다양한 플러그인을 통해 기능을 확장할 수 있다. 예를 들어, 새로운 데이터 소스나 시각화 유형을 추가할 수 있다.

• 사용자 관리:

  • 사용자를 관리하고, 대시보드와 데이터 소스에 대한 접근 권한을 설정할 수 있다. 이를 통해 팀 내에서 협업을 강화하고 데이터 보안을 유지할 수 있다.

실습

• 이번 실습에서는 Docker를 사용하여 그라파나 컨테이너를 실행시키고, 그라파나에서 Slack으로 Alert를 보내도록 구현해볼 것이다.

슬랙 앱 생성

• 먼저 슬랙에 가입해서 워크스페이스를 생성한다.
• https://api.slack.com/apps 에 접속해서 Create an App을 클릭한다.

• 팝업이 뜨면 From scratch 를 클릭한다.

• 앱이름을 입력하고 생성한 워크스페이스를 선택한다.

• OAuth & Permissions 메뉴에 접속한다.

• 스크롤 하여 Scopes 항목으로 간 후 Bot Token Scopes에 “chat:write”를 추가한다.

• 그후 스크롤을 올라와서 Install to Workspace 를 클릭하고 허용을 클릭한다.

• Incoming Webhooks 메뉴에 접속한다. Activate Incoming Webhooks 를 활성화 한 후, 하단에 Add New Webhook to Workspace를 클릭한다. 다음 화면에서 전달 받고 싶은 슬랙 채널을 선택한다. 그리고 생성된 Webhook URL을 복사해둔다.

• 슬랙 앱에서 해당 채널에 가서 생성한 App을 “@”를 사용하여 추가해준다.

그라파나 Alert 설정

• 그라파나에서 사이드메뉴에 Alerting > Contact points 에 접속하여 Add contact point 버튼을 클릭한다.

• Name 을 입력한 후, Integration 을 Slack을 선택한다. 그후 Webhook URL에 아까 앱에서 복사한 URL을 입력한다. 테스트 버튼을 클릭하면 테스트 메시지가 슬랙 채널로 오는 것을 확인할 수 있다.

• 그라파나 사이드 메뉴에서 Alerting > Notification policies 로 들어간 후 Default policy의 edit 버튼을 클릭한다. 이후 나온 Edit창에서 Default contact point 를 이전에 생성한 contact point로 선택한다.

• Alerting > Alert rules 를 클릭하여 “New alert rule”을 클릭한다.

• 알림 이름을 입력한다. Define query and alert condition 에서 matric을 UP을 선택하고 Label filter 에서 Job , spring-boot 를 선택한다.

  Expression 의 Threshold에서 IS BLOW를 선택 숫자는 1을 입력한다. 이를 통해 만약 애플리케이션이 정지되면 알람이 발송되게 된다.

• 스크롤 하여 내려가면 Set evaluation behavior 섹션을 볼 수 있다.

  Folder 및 Evaluation group을 선택또는 새로 생성한다.

  pending period, Evaluation internal 은 빠른 확인을 위해 1m으로 설정한다.

• 좀더 스크롤해 내려가면 Confifure labels and notifications 메뉴가 있다. 해당 메뉴의 contact point 을 이전에 설정한 slack으로 설정한다.

그라파나 Alert 설정 확인

• Alert rules에 생성한 Alert이 노출된다. 상태는 Normal인 것을 확인할 수 있다.

• 스프링 애플리케이션을 정지 시키면 Normal 이었던 상태가 Pending > Firing으로 변경된다.

  그후 잠시 기다려면 슬랙 채널로 Firing 알람이 오는것을 확인할 수 있다.

• 다시 스프링 애플리케이션을 실행한후 기다리면 슬랙 채널로 Resolved 알람이 오는것을 확인할수 있다.

  (해당 알람은 도착하는데 시간이 걸린다!)

CORS (Cross-Origin Resource Sharing)

CORS란?

• 한 출처(도메인, 프로토콜, 포트)에서 실행 중인 웹 애플리케이션이 다른 출처의 리소스에 접근할 수 있도록 브라우저에서 제공하는 보안 기능

• 웹 애플리케이션은 기본적으로 동일 출처 정책(Same-Origin Policy)에 따라 동작하며, 이는 보안상의 이유로 다른 출처의 리소스 접근을 제한

• CORS는 이러한 제한을 완화하여 특정 조건 하에 다른 출처의 리소스 접근을 허용

동일 출처 정책(Same-Origin Policy)

• 동일 출처 정책은 보안 메커니즘으로, 웹 브라우저가 스크립트가 로드된 출처(origin)와 동일한 출처의 리소스만 접근할 수 있도록 제한

• 출처의 구성 요소: 출처는 스키마(프로토콜), 호스트(도메인), 포트의 조합으로 정의

  • 예: http://example.com:80와 http://example.com:8080은 포트가 다르므로 동일 출처가 아님.

CORS의 필요성

• API 호출: SPA(Single Page Application)와 같이 클라이언트 중심의 웹 애플리케이션은 종종 다른 도메인에서 호스팅되는 API를 호출해야 한다.
• 리소스 공유: 여러 도메인 간의 이미지, 스타일시트, 스크립트, 폰트 등의 리소스를 공유할 필요가 있다.

CORS의 동작 원리

• Preflight 란?

  • Preflight 요청은 CORS (Cross-Origin Resource Sharing) 요청의 일종으로, 브라우저가 실제 요청을 보내기 전에 서버에 요청할 권한이 있는지 확인하는 과정

  • 이는 보안상의 이유로, 특정 조건을 만족하는 HTTP 요청이 서버에 전송되기 전에 실행

    • HTTP 메서드가 단순 요청이 아닐 때 (GET, HEAD, POST 외의 메서드, 예: PUT, DELETE).
    • 특정 헤더를 사용할 때: 커스텀 헤더 또는 특정 표준 헤더를 사용할 때.
    • 특정 Content-Type을 사용할 때: application/x-www-form-urlencoded, multipart/form-data, text/plain이 아닌 Content-Type을 사용할 때.

  • 동작 방식은 다음과 같다.

    1. 브라우저가 Preflight 요청을 보냄:

       • OPTIONS 메서드를 사용하여 서버에 사전 요청을 보냄
       • 이 요청에는 실제 요청의 메서드와 헤더 정보가 포함됨

    2. 서버가 Preflight 요청에 응답:

       • 서버는 요청된 메서드와 헤더를 허용할지 여부를 결정하여 응답
       • 응답 헤더에는 Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 포함됨

    3. 브라우저가 응답을 확인:

       • 브라우저는 서버의 응답을 확인하고, 요청이 허용되면 실제 요청을 보냄
       • 요청이 허용되지 않으면, 브라우저는 실제 요청을 차단함

• Simple Request (단순 요청)

  • 간단한 HTTP 요청으로, Preflight 요청 없이 바로 서버에 전달
    • HTTP 메서드가 GET, POST, HEAD 중 하나.
    • 커스텀 헤더가 없고, Content-Type이 application/x-www-form-urlencoded, multipart/form-data, text/plain 중 하나

• Preflight Request (사전 요청)

  • 단순 요청 조건을 충족하지 않는 요청은 서버의 CORS 정책을 확인하기 위해 브라우저가 먼저 OPTIONS 메서드를 사용하여 Preflight 요청을 보낸다.
  • 서버가 Preflight 요청에 적절히 응답하면 실제 요청이 진행된다.

CORS 설정 시 주의사항

• 보안 고려사항:

  • 신뢰할 수 없는 출처를 허용하지 않도록 주의.

  • allowedOrigins에 와일드카드(*)를 사용하면 모든 출처에서의 요청을 허용하므로 주의가 필요.

  • 민감한 정보를 보호하기 위해 Access-Control-Allow-Credentials를 신중하게 설정.

• 성능 고려사항:

  • Preflight 요청이 빈번하면 성능 저하가 발생할 수 있으므로, Access-Control-Max-Age를 설정하여 Preflight 요청을 캐싱.
  • 불필요한 Preflight 요청을 최소화하기 위해 단순 요청 조건을 충족하도록 API 설계를 검토.

CORS 해결하기

• 백앤드 애플리케이션에서 CORS 설정을 해준다.

• 전역설정

    import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    import org.springframework.web.servlet.config.annotation.CorsRegistry;
    import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;
  
    @Configuration
    public class WebConfig {
  
        @Bean
        public WebMvcConfigurer corsConfigurer() {
            return new WebMvcConfigurer() {
                @Override
                public void addCorsMappings(CorsRegistry registry) {
                    registry.addMapping("/**")
                            .allowedOrigins("http://localhost:3000")  // 허용할 출처
                            .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                            .allowedHeaders("*")
                            .allowCredentials(true)
                            .maxAge(3600);  // Preflight 요청 캐시 시간
                }
            };
        }
    }

• 컨트롤러 레벨 설정

    import org.springframework.web.bind.annotation.CrossOrigin;
    import org.springframework.web.bind.annotation.GetMapping;
    import org.springframework.web.bind.annotation.RestController;
  
    @RestController
    public class MyController {
  
        @CrossOrigin(origins = "http://localhost:3000")
        @GetMapping("/api/data")
        public String getData() {
            return "Data from server";
        }
    }

CSRF (Cross-Site Request Forgery)

CSRF란?

• 웹 애플리케이션의 취약점을 이용해 사용자가 의도하지 않은 요청을 보내도록 하는 공격 기법

• 공격자는 사용자가 인증된 상태를 악용하여 사용자가 원하지 않는 행동을 수행하게 만든다.

• 예를 들어, 사용자가 로그인된 상태에서 악의적인 웹사이트를 방문하면, 그 웹사이트가 사용자의 권한을 이용해 은행 계좌에서 돈을 송금하도록 할 수 있다.

CSRF 상황

1. 사용자가 로그인: 사용자가 웹 애플리케이션에 로그인

2. 세션 유지: 로그인 후 세션 쿠키가 브라우저에 저장

3. 악성 웹사이트 방문: 사용자가 다른 웹사이트를 방문. 이 웹사이트는 CSRF 공격 코드를 포함

4. 악의적인 요청 전송: 악성 웹사이트는 사용자의 세션 쿠키를 이용해 원본 웹 애플리케이션으로 요청

5. 서버 처리: 서버는 요청을 정상적인 사용자의 요청으로 인식하고 처리

공격예시

• 공격자 웹페이지 코드

    <!DOCTYPE html>
    <html>
    <body>
      <h1>Free Gift</h1>
      <img src="http://bank.com/transfer?amount=1000&to=attacker" style="display:none;" />
    </body>
    </html>

  • 이 예시에서 사용자가 이 페이지를 방문하면, 이미지 태그를 통해 http://bank.com/transfer?amount=1000&to=attacker 요청이 자동으로 실행된다. 사용자가 이미 bank.com에 로그인되어 있다면, 이 요청은 인증된 상태로 처리된다.

방지방법

• Referer 헤더 검증

  • 서버는 요청의 Referer 헤더를 확인하여 요청이 신뢰할 수 있는 출처에서 온 것인지 확인할 수 있다. 그러나, Referer 헤더는 사용자가 조작할 수 있고, 일부 브라우저에서는 이 헤더를 포함하지 않을 수 있다.

• CSRF 토큰 사용

  • 가장 일반적인 방지 방법은 CSRF 토큰을 사용하는 것. 서버는 각 요청에 대해 고유한 토큰을 생성하고, 이를 폼에 포함시킨다. 서버는 요청이 들어올 때 이 토큰을 검증한다.

• form 대신 API사용

  • API를 통해 JSON데이터로 통신한다면 해당 이슈를 피할 수 있다.

CSRF 토큰 실습

• start.spring.io 에 접속하여 프로젝트를 생성한다. 디펜던시는 아래와 같이 구성한다.

• SampleContorller.java

    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.GetMapping;
    import org.springframework.web.bind.annotation.PostMapping;
    import org.springframework.web.bind.annotation.RequestParam;
  
    @Controller
    public class SampleContorller {
  
        @GetMapping("/")
        public String showForm() {
            return "form";
        }
  
        @PostMapping("/submit")
        public String  handleFormSubmit(@RequestParam("name") String name, @RequestParam("_csrf") String csrfToken) {
            // CSRF 토큰 로그 출력
            System.out.println("Received CSRF token: " + csrfToken);
            System.out.println("Received name: " + name);
            return "result";
        }
    }
  

• SampleSecurityConfig.java

    import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    import org.springframework.security.config.annotation.web.builders.HttpSecurity;
    import org.springframework.security.web.SecurityFilterChain;
    import org.springframework.security.web.csrf.CookieCsrfTokenRepository;
  
    @Configuration
    public class SampleSecurityConfig {
  
        @Bean
        public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
            http
                    .authorizeHttpRequests(authorize -> authorize
                            .anyRequest().permitAll()
                    )
                    .csrf(csrf -> csrf
                            .csrfTokenRepository(CookieCsrfTokenRepository.withHttpOnlyFalse())
                    );
  
            return http.build();
        }
    }
  

• resources/templates/form.html

    <!DOCTYPE html>
    <html xmlns:th="http://www.thymeleaf.org">
    <head>
        <title>CSRF Example</title>
    </head>
    <body>
    <form th:action="@{/submit}" method="post">
        <label for="name">Name:</label>
        <input type="text" id="name" name="name"/>
        <button type="submit">Submit</button>
    </form>
    </body>
    </html>

• resources/templates/result.html

    <!DOCTYPE html>
    <html xmlns:th="http://www.thymeleaf.org">
    <head>
        <title>Result</title>
    </head>
    <body>
    <h1>Form submitted successfully!</h1>
    <a th:href="@{/}">Go back to form</a>
    </body>
    </html>

• 애플리케이션을 살행시킨 후, http://localhost:8080에 접속한다. 크롬 검사 탭을 클릭하여 Elements 탭을 확인한다. 폼 안에 _csrf가 있는것을 확인할 수 있다.

• 폼의 값을 입력하고 제출하면 애플리케이션 로그에 CSRF 값이 노출 되는것을 볼 수 있다.

• 만약 폼dml _csrf 값을 임의로 수정 한 후 제출하면, 403 페이지로 이동하는 것을 볼 수 있다.

마무리

CORS, CSRF에 대해 공부하다 궁금한점이 생겼다.

❓ CORS의 Origin 설정을 프론트 서버로 한정할 경우 CSRF 공격에 대한 방어(CSRF 토큰 사용 등)를 할 필요가 없는가?

튜터님과 ChatGPT로부터 얻은 답변을 통해 아래와 같이 결론내릴 수 있었다.

• CORS는 보안 기능, CSRF 토큰은 일회용 키!

• 현업에서는 CORS 보안과 CSRF 토큰 사용 둘 다 적용함

• 만약 공격자가 프론트 화면(폼)에서만 변조하여 사용할 경우, 프론트 서버 도메인에서도 요청을 변조하여 보낼 수 있다.

• 또는 사용자가 의도치 않게 악성 사이트에서 HTTP 요청을 전송하게 되면, 그 요청은 동일한 Origin에서 발생한 것처럼 서버에 전달되게 할 수 있다.

• CSRF 토큰 사용 시 공격자는 사용자가 해당 사이트에 인증된 상태라는 점을 이용하더라도, 유효한 CSRF 토큰을 생성할 수 없기 때문에 공격이 방어됨

따라서 CORS 보안, CSRF 토큰 사용 두 가지 방법의 통합을 통해 더 뛰어난 보안성을 갖출 수 있을 것이다.

• 로그를 찍기 위해 @Slf4j 어노테이션을 사용하지 않고 import문을 이용해 로깅을 구현하다 제목과 같은 오류가 발생했다.

import jakarta.servlet.http.HttpServletResponse;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.util.logging.Logger;

@RestController
public class SampleController {

    private static final Logger logger = (Logger) LoggerFactory.getLogger(SampleController.class);

    @GetMapping("/")
    public String hello(HttpServletResponse response) throws IOException {
        logger.info("403 Forbidden");
        response.sendError(HttpServletResponse.SC_FORBIDDEN, "Access Denied");
        return null;

    }
}

에러 발생 원인 및 해결

• 로깅 시 Slf4j에서 import를 해야하는데 LoggerFactory는 제대로 가져왔지만 Logger 객체가 java.util.logging에서 가져온 객체인것을 확인할 수 있다.

• import java.util.logging.Logger;를 import org.slf4j.Logger;로 변경한다.

• 이후 Logger 선언문도 아래와 같이 수정한다.

  • 수정 전

    private static final Logger logger = (Logger) LoggerFactory.getLogger(SampleController.class);

  • 수정 후

    private static final Logger logger = LoggerFactory.getLogger(SampleController.class);