Blog
//
Blog
About Me
//
📚

Projects

# of Posts
10
1 more property
Search

간단한 쇼핑몰 개발 기능목록

•
회원기능
•
상품기능
•
주문기능
•
기타 요구사항

도메인 모델과 데이터베이스 설계

•
회원:주문 = 1:N
•
주문:상품 = N:N이 되므로 중간테이블인 주문상품으로
•
상품:카테고리 = N:N(실제운영에서는 N:N을 지양해야함)
[Boot+JPA] 요구사항 분석 및 설계

H2 데이터베이스 설치

H2 인메모리 데이터베이스를 로컬환경에 설치하여 사용하고자 한다. 과거 MacOS 설치 내용과 동일하므로 해당 내용을 그대로 사용한다.
최초 데이터베이스를 생성하기 위해서는 JDBC URL을 다음처럼 입력한다.
이처럼 연결하고 나면 지정한 URL 경로에 다음과 같이 xx.mv.db와 같은 데이터베이스 파일이 생성되게 된다.
생성 이후부터는 로컬호스트로 접근이 가능하다.
[Boot+JPA] JPA, DB 설정

프로젝트 생성

프로젝트는 JDK 8(1.8) 버전을 사용하고자 하지만 spring.io에서는 더이상 과거 버전들의 셋업을 제공하지 않는 문제점이 있다. 따라서 원하는 group, artifact 명을 작성하고 우선 17버전으로 생성한 이후 프로젝트 내부에서 build.gradle을 통해 다운 그레이드를 하고자 한다.
과거 버전의 프로젝트 셋업이 된 스켈레톤 백업본이 없어서 아래처럼 진행하게 되었다.

기본 라이브러리 추가

프로젝트 생성 단계에서 원하는 라이브러리를 프로젝트에 추가 할 수 있다. 생성 이후에 build.gradle에 직접 추가해도 되지만 우선적으로 자주 사용되는 Spring Web, JPA, Lombok과 H2 Database를 선택하여 추가했다.

build.gradle에서 다운그레이드

다음과 같이 위 build.gradle을 수정한다.
[Boot+JPA] 프로젝트 환경 설정

레디스 분산 락이란?

레디스(Redis) 분산 락은 여러 컴퓨터 또는 프로세스 간에 자원의 동시 접근을 제어하기 위한 메커니즘입니다. 분산 시스템에서 여러 노드가 동일한 자원에 접근하려 할 때, 일관성과 순서를 유지하면서 동시성 문제를 해결하는 데 쓰입니다.

레디스 분산 락의 필요성

•
동시성 관리: 복수의 인스턴스가 동일한 데이터를 동시에 수정하려 할 때, 데이터 불일치를 방지합니다.
•
일관성 유지: 분산 시스템 내에서 데이터의 일관성을 유지하며, 작업의 순서를 보장합니다.
•
데드락 방지: 데드락을 감지하고 해결하는 메커니즘을 제공합니다.

레디스 분산 락의 작동 원리 ( Redisson )

1.
락 회득: Redisson은 Lua 스크핍트를 사용하여 락을 획득합니다. 이 스크립트는 락키가 존재하지 않는 경우에만 락 키를 생성하고, 이 키에 대한 유효 시간 (TTL)을 설정합니다. 이로 인해 서버나 애플리케이션에 문제가 발생하여 락을 해제하지 못하는 경우에도 설정된 유효 시간 이후에 자동으로 락이 해제됩니다.
2.
레디스 키의 유효기간: 락을 회득 시 레디스 키에 유효기간을 설정하여 락 획득자가 특정 시간 안에 작업을 완료하지 못하면 락이 자동으로 해제되도록 합니다. 이를 통해 데드락을 방지합니다.
3.
락 재진입: Redisson은 동일한 락을 여러번 회득 할 수 있는 재진입 가능한 락을 지원합니다. Lua 스크립트는 락을 요청하는 쓰레드나 인스턴스가 이미 락을 보유하고 있는지를 확인하고 만약 락을 가지고 있다면 락 획득 요청을 허용하여 재진입을 가능하게 합니다.
[Spring][258] 레디스 분산락을 이용한 동시성 문제 대응

Kafka를 시도하는 이유

1.
현재 진행 중인 프로젝트의 서비스는 대용량 트래픽을 받는 서비스입니다.
2.
확장성이 중요한 경우
3.
탄력성과 고가용성이 중요한 경우
즉 저희 서비스의 확장성과 안정성, 서버 과부하 방지, 동시성 문제를 성능 저하하는 락없이 해결하기 위해 카프카를 시도하였습니다.

KafKa의 동작 흐름

1.
프론트엔드에서 요청: 사용자의 액션에 의해 프론트엔드에서 백엔드로 HTTP 요청이 전송됩니다.
2.
Kafka 컨트롤러: Spring Boot 어플리케이션 내의 컨트롤러가 HTTP 요청을 받아 처리합니다.
3.
Kafka 프로듀서: 컨트롤러는 Kafka 프로듀서를 통해 메시지를 Kafka 서버의 특정 토픽으로 전송합니다.
[Spring][258] 카프카 도입으로 구조적으로 동시성 문제에 대응
[Spring][258] 소프트웨어 아키텍처 및 CI/CD 가독성 올린 구조로 수정
EC2편 참고자료
EC2 Console에서 MySQL 초기 설정 참고
RDS 연결하기 포함편 참고
EC2에 github pull때, TEST 가 충돌이 난다 제거필요, application.properties를 직접 찾아가서 생성해줘야함
TEST파일은 빌드할때 오류가 발생하나보다. 삭제한것을 다시 pull받고 돌리니 빌드가 된다. 하지만 런타임단계에서 오류가 발생하는데,
application.properties 파일 자체가 github에서 제외되었기 때문, 보안땜에 github은 안올리는데, EC2 서버컴에서 pull받으면 이것자체가 없으니 빌드하면 JDBC정보 등등을 못찾을거다.
.gitignore로 제외한것이 있다면, bootjar 빌드에 필요한것은 직접 찾아가서 생성해줘야한다.
우분투 방화벽 ufw 설정 및 허용, EC2 배포시 8080을 혹시나 막았는지 확인할것
ufw 활성화하기
[Spring][AWS EC2]58 EC2로 배포해보기

문제 상황

Kafka 서버로 프로듀서가 데이터를 전송하는 것은 성공하였으나 Kafka 리스너가 Kafka 서버에서 데이터를 읽지 못하는 상황이 발생했습니다. 이 문제는 @KafkaListener 애노테이션을 사용하여 Kafka 메시지를 수신하는 Spring Boot 어플리케이션에서 나타났습니다.

문제 분석

문제의 핵심 원인은 Kafka 리스너에서 containerFactory 설정을 누락한 것이었습니다. containerFactory는 Kafka 리스너가 사용할 ConsumerFactory와 관련 설정을 정의하는 데 사용됩니다. 이 설정을 제대로 지정하지 않으면, Spring Boot는 기본적으로 로컬 환경에 맞게 구성된 containerFactory를 사용하게 됩니다. 이 경우, Kafka 리스너는 실제 Kafka 서버가 아닌 로컬 서버에서 데이터를 읽으려 시도하게 되며, 결과적으로 데이터를 제대로 수신하지 못하게 됩니다.

문제 해결 과정

1.
원인 파악
에러 로그와 설정을 분석하였더니 컨슈머가 카프카 서버를 로컬 서버로 인식한다는 점을 발견했습니다. 이를 통해 문제가 containerFactory 설정과 관련이 있다는 것을 파악했습니다.
[Spring][258] 트러블 슈팅 : Kafka 리스너(컨슈머)가 Kafka 서버에서 데이터를 읽지 못하는 문제 발생 및 해결
Wire Frame 작성
•
프로젝트 프론트 엔드 기초 디자인
DB 설계
•
ERD(Entity Relationship Diagram) 작성
API 명세서 작성
•
기능별 기초 CRUD API 명세서 작성
프로젝트 기초 구조 생성
•
작업 분배 전 main 브랜치의 기초 구조 생성
프로젝트 MVP 기능별 분업 시작
•
MVP 기능별 작업구간 분배
[Spring][258] 초기 기획 과정 - 3
MySQL DB의 데이터와 Elasticsearch 데이터는 동기화로 일관성을 유지해야 한다.
기존 MVP 기능으로 도서의 정보를 변경하는 부분들이 있습니다. 특히 Elasticsearch와 연결된 도서 목록에서 사용자는 도서 대출, 도서 대출 예약을 진행 할 수 있습니다.
사용자가 도서 대출을 진행하면 도서의 대출 가능 여부를 알 수 있는 Status 컬럼은 POSSIBLE에서 IMPOSSIBLE로 변경됩니다. 해당 기능은 HTML의 Ajax HTTP 요청을 통해 MySQL DB에 있는 대상 book_id의 도서의 상태를 즉시 변경하지만, Elasticsearch는 MySQL의 DB를 Logstash로 가져와서 인덱싱하기 때문에 이 과정에서 새로 목록을 불러와야 할 필요성이 있습니다.
Logstash의 데이터 변경 추적 설정 필요성
기존 Logstash를 통해 MySQL의 DB를 전달하여 색인하는 부분입니다. 709만개의 도서 데이터를 한번에 읽어오는 과정에서 JVM의 메모리 부족 현상이 발생하여 200만개씩 메모리에 로드하고 Elasticsearch로 전달하도록 구성되어있습니다.
하지만 이 부분에서 설정의 문제점이 있습니다.
•
최초 실행 1회 이후로 데이터를 전달하고 해당 소스는 종료됨
•
MySQL DB의 변경사항이 생기면 수동으로 해당 파일을 다시 실행시켜 주어야 업데이트가 됨
•
다시 한번 200만개씩 총 709만개를 돌면서 업데이트가 아닌 모든 정보를 덮어쓰는 형태
최초의 전체 709만개 도서 데이터 전달은 기본적으로 실행되어야 하는데 지속적으로 어떤 도서의 정보 업데이트에 대한 별도 동기화 처리가 필요했습니다.
Logstash의 tracking_column을 이용한 변경 추적
공식 문서에 따라서 tracking_column을 통해서 특정 컬럼의 값이 변경되는 것을 추적할 수 있고, Elasticsearch에 변동된 행만을 업데이트 할 수 있는 방안이 있었습니다.
[Spring][258] MySQL→Logstash→Elasticsearch 의 동기화 처리에서 발생하는 문제
Load more
　｜　Main Page　｜　Category　｜　 Tags　｜　About Me　｜　Contact　｜　Portfolio