보초개발

String, StringBuilder, StringBuffer 성능 비교

유당불내증이 있는 개발자 — Thu, 20 Mar 2025 19:29:35 +0900

JSCODE 자바스터디 2주차 공부 중 실습

String, StringBuilder, StringBuffer

지난번정리

https://bocho-developer.tistory.com/16

String은 불변클래스로 문자열 연산 시 기존 문자열을 수정하는 것이 아니라 새로운 인스턴스를 생성하여 힙 영역에 저장된다.

이런 작업이 반복 수행되면서 메모리를 많이 사용하게 되고 응답 속도에도 많은 영향을 끼치게 된다.

StringBuilder는 동기화 되어있지 않아 싱글스레드 환경에서 사용

StringBuffer는 메소드 내부에 synchronized 키워드 설정이 되어있어 멀티스레드 환경에서 안전하다.

성능 테스트

private static void stringTest() {
        long startTime = System.currentTimeMillis();
        long startMemory = getMemoryUsage();

        String str = "";
        for (int i = 0; i < 100000; i++) {
            str += "abcd";
            str += "efgh";
            str += "ijkl";
            str += "mnop";
        }

        long endTime = System.currentTimeMillis();
        long endMemory = getMemoryUsage();


        System.out.println("string 연산 실행 시간: " + (endTime - startTime) + "ms");
        System.out.println("메모리 사용: " + ((endMemory - startMemory) / (1024.0 * 1024.0)) + " MB");
        System.out.println();
    }
    
    private static void stringBufferTest() {
        long startTime = System.currentTimeMillis();
        long startMemory = getMemoryUsage();

        StringBuffer stringBuffer = new StringBuffer("");
        for (int i = 0; i < 100000; i++) {
            stringBuffer.append("abcd");
            stringBuffer.append("efgh");
            stringBuffer.append("ijkl");
            stringBuffer.append("mnop");
        }

        long endTime = System.currentTimeMillis();
        long endMemory = getMemoryUsage();


        System.out.println("stringBuffer 실행 시간: " + (endTime - startTime) + "ms");
        System.out.println("메모리 사용: " + ((endMemory - startMemory) / (1024.0 * 1024.0)) + " MB");
        System.out.println();
    }

    private static void stringBuilderTest() {
        long startTime = System.currentTimeMillis();
        long startMemory = getMemoryUsage();

        StringBuilder stringBuilder = new StringBuilder();
        for (int i = 0; i < 100000; i++) {
            stringBuilder.append("abcd");
            stringBuilder.append("efgh");
            stringBuilder.append("ijkl");
            stringBuilder.append("mnop");
        }

        long endTime = System.currentTimeMillis();
        long endMemory = getMemoryUsage();


        System.out.println("stringBuilder 실행 시간: " + (endTime - startTime) + "ms");
        System.out.println("메모리 사용: " + ((endMemory - startMemory) / (1024.0 * 1024.0)) + " MB");
    }

    private static long getMemoryUsage() {
        Runtime runtime = Runtime.getRuntime();
        return runtime.totalMemory() - runtime.freeMemory();
    }

세가지 메서드다 테스트 방식은 비슷하다.

성능을 측정하기 위해 10만번의 루프를 돌며 각각 소요시간과 메모리 사용량을 측정

테스트 결과

String 연산 시 약 14초가 소요되었고 메모리 사용량도 String 연산과 StringBuilder 와 Buffer에 비하면 차이가 크다.

생각했던 거보다 꽤나 큰 차이를 보인다.

그러나 StringBuilder와 StringBuffer는 실행시간과 메모리 사용량이에서 큰 차이가 보이지는 않았다.

자바 성능 튜닝 이야기 - 조영호 참고

StringBuffer는 클래스의 static으로 선언한 문자열을 변경하거나, singleton으로 선언된 클래스에 선언된 문자열일 경우에 사용해야한다.

StringBuilder의 경우 메서드 내에 변수를 선언했다면 해당 변수는 메서드 내에서만 살아있으므로 StringBuilder를 사용하면 된다.

중고차를 알아보다 작성하는 조회 성능 개선기 (Redis 캐싱)

유당불내증이 있는 개발자 — Fri, 14 Feb 2025 03:46:45 +0900

중고차의 늪

최근 중고차에 관심이가 벤츠 인증 중고차 사이트를 자주 들락날락했다.

문제는 사이트에서 차량 조회하면 약 2초 이상 소요되어 이쁜 자동차들을 빠르게 구경하지 못해 고통받았다.

답답해서 사이트를 금방 탈주하게 되었고 개선이 필요해 보였다.

그에 비해 엔카는 86.55ms로 아주 훌륭한 조회 성능을 보여준다.

덕분에 엔카에 한번 접속하면 2시간은 순삭이다. 최적의 조회 성능으로 헤어나지 못하게 만든다.

이처럼 조회 성능은 매우중요하다. 2초 아니 1초만 소요되도 느리다고 생각해 사용자에게 좋지 않은 경험을 만들어준다.

조회 성능 개선 고민

지난 프로젝트에서 100만건의 상품데이터를 관리하며 발생되는 문제 중 상품 검색 조회 같은 경우 Elasticsearch를 적용하여 성능 개선하였고 단건 조회에서의 문제를 찾아봤다.

다행히 PK기반의 단건 조회는 인덱스 설정으로 RDB에서도 100~200ms의 Elasticsearch만큼 빠르지 않지만 양호한 조회 성능을 보여줬다.

이미 Elasticsearch를 사용 중이라 단건 조회도 함께 처리할 수 있지 않을까 생각했지만 모든 조회를 Elasticsearch로 통합하는 것이 맞을까 고민했다.

양호한 조회 성능 나오는 단건 조회에서 RDB와 Elasticserach간의 실시간 데이터 동기화 문제, 추가적인 운영 부담을 안고 사용할래? 묻는다면 오버엔지니어링일 수 있다 생각한다.

그래도 인기상품 같은 경우 사용자의 조회가 많아 성능 문제가 생길거라 생각했고 얼마나 차이가 있을지 트래픽이 몰리는 상황을 만들어 테스트를 진행했다.

Log 작업

상품조회 수치를 집계하기 위해 Logstash 설정 후 상품 단건 조회 시 로그를 저장했다.

캐싱 스케줄러 로직 구현

 @Transactional
  public void refreshPopularProductsCache() {
    TimeRange timeRangeForCache = schedulerUtil.getTimeRangeForCache();

    List<LogDetails> logDetailsList = getLogsInTimeRange(timeRangeForCache);

    Map<String, Integer> productIdAndViewCount = calculateProductViewCounts(logDetailsList);

    saveCacheProduct(productIdAndViewCount);
  }

1. 현재 시간부터 1시간 전 TimeRange 설정한다.

2. Logstash에서 TimeRange 시간대에 맞는 로그 조회

3. 조회된 로그 값에서 상품 아이디, 조회 수 계산

4. 인기 상품 Redis 캐싱

상품 단건 조회 캐시 적용

  public ProductDetails findById(String productPublicId) {
    log.info("publicId = {}", productPublicId);

    ProductDetails cachedProduct = productOperations.get("getProduct:" + productPublicId);
    if (cachedProduct != null) {
      return cachedProduct;
    }

    return productRepository.findByProductAndCurrentPrice(productPublicId)
        .orElseThrow(() -> new ProductException(
            ErrorCode.PRODUCT_NOT_FOUND));
  }

1. 캐시에서 데이터 확인 후 있으면 반환

2. 없으면 DB 조회

Look Aside 전략과는 비슷하지만 조금 다르다.

캐시에 데이터가 없다면 DB에서 조회 후 캐시 데이터를 저장 하지 않는다.

EXPLAIN 발표

유당불내증이 있는 개발자 — Sat, 1 Feb 2025 17:57:49 +0900

스파르타 단기심화반에서 전체 발표 할 수 있는 기회가 생겼다.

인생은 도전이고 드디어 때가 왔다.. 기회 생기면 다 해보자라는 마음으로 사는중이라 내심 좋았다.

나는 EXPLAIN에 대해서 준비하며 전 회사에서 겪었던 성능 개선 과정에 대해 문제점들을 있다 생각했고 발표를 통해 공유하고 싶었다.
EXPLAIN 키워드를 알고 있다면 문제해결 방법에서 느낌이 아닌 데이터로 판단하는 개발을 할 수 있을 거라 생각한다.
그래서 많은 내용보다는 발표를 보는 사람들이 이 키워드에 대해서 인식할 수 있다면 반은 성공이다.. 라는 마음으로 발표 자료를 준비했다

이렇게 홍보사진도 만들어주셔서 너무 감사하다.. (많은 사람들이 집중했으면 좋겠어서 사진으로 어그로를 끌어봤다...)

발표 자료 및 영상

발표자료는 노션으로 준비했다.

내용을 정리하며 편리했지만 이번에 발표해보니 PPT로 준비하는게 집중하기 더 좋을거 같다.

https://dorian-hub-840.notion.site/EXPLAIN-18ff3adef064804aacb2f86350a5bf3d

EXPLAIN (쿼리 실행 계획) | Notion

발표영상 00:20 ~ 12:50

dorian-hub-840.notion.site

발표 영상을 다시 보니 아쉬움이 많이 남는다.
그동안 살면서 더 긴장되고 많은 일들을 있었다고 생각하며 준비도 여러 번 했지만 막상 발표하니 많이 떨렸다.
영상을 보니 목소리 톤이 루즈해지는 느낌이 들어 전달력이 떨어지는 거 같다. 어려운 내용은 아니라 생각했지만 전달하려는 바가 잘 됐을까

다음번에 기회가 생긴다면 더 잘 준비해서 다시 발표해 보고 싶다.

상품 재고 관리 - 비관적 락 vs 분산 락 적용 사례

유당불내증이 있는 개발자 — Fri, 31 Jan 2025 02:30:20 +0900

재고 차감 동시성 문제

문제 상황

주문-상품 서비스간 2PC 방식 구현 중 동일 상품에 대한 동시 주문 발생 시 재고 수량 데이터 불일치 문제 발견

JMeter 테스트 상품 재고 100개, 200번의 동시 요청

테스트 요청 수 - 200건
성공 응답 수 - 200건
오류율 - 0%
평균 처리 시간 - 167.8/sec

모든 요청을 성공으로 응답했으나 데이터베이스의 실제 데이터와 불일치가 발생

재고 차감 이력 테이블 : 200건 기록
실제 상품 재고: 79개 (21개 차감)

해결 방안 고민

❓분산락 적용 안한 이유

분산락은 전체 프로세스에 락을 걸어 동시성을 제어
상품 재고 차감은 DB에 단일 리소스 업데이트 하는 과정으로 전체 프로세스에 락을 걸 필요X
여러 DB서버가 존재하는게 아니고 현재 단일 DB서버 사용중
지금 같은 상황에서 분산락을 적용한다면 오버스팩이라고 생각

❓낙관적 락 적용 안한 이유

롤백 재시도 로직 구현하기 번거롭고 작성한 로직에서 추가적인 문제 발생할 수 있다
인기상품 구매로 동시요청이 많아질 경우 계속 충돌 발생하면서 부하발생

비관적락 적용

JMeter 테스트 상품 재고 100개, 200번의 동시 요청

테스트 요청 수 - 200건
성공 응답 수 - 100건
오류율 - 50%
평균 처리 시간 - 143.9/sec

요청 결과와 데이터베이스의 정합성 보장

재고 차감 이력 테이블 - 100건 기록
실제 상품 재고 - 0개 (초기 100개에서 모두 차감)
실패한 요청 - 100건 (재고 부족으로 인한 에러)

재고 롤백 스케줄러 분산락 적용

문제 상황

여러 인스턴스 환경에서 상품 재고 롤백 스케줄러 실행 시 중복 증가 문제 발생

[서버 A]
1. 조회: 재고 차감 이력 테이블(stock_decrease_history)에서 재고 차감 후 커밋되지 않은 이력 조회
2. 처리: 상품 재고 테이블(top_size_stock) 재고 증가 

[서버 B]
1. 조회: 재고차감 이력 테이블(stock_decrease_history)에서 서버 A와 같은 중복 데이터 조회
2. 처리: 상품 재고 테이블(top_size_stock) 재고 증가 (이미 처리된 건에 대해서도 재고 증가 발생)

해결방안

❓비관적 락 적용 안한 이유

두 테이블 간의 데이터 정합성 문제 (재고 차감 이력 테이블, 상품 재고테이블)
비관적 락 은 해당 테이블(상품 재고) 특정 로우에만 락을 걸어 순차적인 재고 증가 문제는 해결 가능
하지만 재고 차감 이력 테이블(stock_decrease_history)에서 중복 데이터가 먼저 조회문제는 비관적락과 상관 X
두 테이블 간 조회 및 처리에 대한 작업을 비관적락으로는 해결 불가

분산락 적용

분산락 획득
트랜잭션 시작
rollback 메서드 실행 (커밋되지 않은 이력 조회 후 재고 증가)
트랜잭션 종료
분산락 해제

먼저 락을 획득한 하나의 서버만 전체 프로세스 실행
다음 서버가 락 획득 후 프로세스 실행으로 불필요한 중복 데이터 조회 및 처리 방지

처음과 같이 중복 실행되지 않고 하나의 인스턴스에서만 롤백스케줄러를 실행하는것을 확인할 수 있다.

RDB vs Elasticsearch 검색 성능 비교

유당불내증이 있는 개발자 — Fri, 10 Jan 2025 00:28:54 +0900

상품 조회 시 트래픽 증가로 성능 저하문제가 발생했다.

상품데이터는 100만건, 상품 검색 조회 시 JPA QueryDsl을 사용하여 검색 조회를 하였고 소요시간은 꽤나 걸렸다.

1. RDB 상품 검색 목록 조회 평균 응답시간

RDB 정상 범위 데이터 4건의 평균 소요 시간
- 2897 + 2639 + 2663 + 2624 = 10823
평균 소요 시간
- 10,823 ÷ 4건
- 약 2.7초

1.1 Full-Text Index 적용

Full-Text Index를 적용하고 기존 Like 문을 변경했다.

WHERE  	 P.NAME LIKE '%니트%'

WHERE  MATCH(P.NAME) AGAINST ('니트');

EXPLAIN ANALYZE를 실행해보니 예상대로 Full-text index가 성공적으로 적용되어 소요시간이 줄어든것을 확인

그러나 조회되는 rows=0

무슨 문제일까 알아보니

기본적으로 MySQL은 3글자 미만의 단어는 인덱싱하지 않아서 한글의 경우 2바이트 문자이므로 이 설정의 영향을 받을 수 있다.

검색조건을 니트 -> 알파카 3글자로 변경하니 잘 반환된다.

사용자가 한글을 무조건 3글자 이상 검색하지는 않을것이다. 다른 방법을 적용해보자

2. 엘라스틱서치 적용

2.1 데이터 동기화 방법 고민

동기 처리

1. 하나의 트랜잭션안에서 DB와 엘라스틱 저장해서 실시간으로 데이터 저장

동기 처리 고민

1. 브랜드에서 상품 등록 시 얼마나 트래픽이 발생할까?

2. 실시간으로 처리가 필요한가?

3. 엘라스틱서치 동기화 장애로 인해 상품노출이 누락된어 보여지지 않고 있다면? 차라리 동기식으로 처리하여 등록 시 오류가 있다는걸 알면 좋지 않을까 -> 빠르게 문의가능

비동기 처리

1. logstash 사용하여 주기적으로 엘라스틱서치에 데이터 동기화

2. DB저장 후 이벤트 발행

비동기 처리 고민

1. 브랜드에서 대량의 상품을 한번에 등록하는 경우가 많다.

2. 또 이미지와 상세설명 등 데이터가 크다.

3. 등록 즉시 검색될 필요는 있으나 약간의 지연은 큰 문제가 아닐 수 있다?

4. 대부분 logstash 사용하여 주기적으로 DB와 엘라스틱서치 데이터 동기화를 하는것으로 보인다.

결론

보편적으로 많이 사용하는 Logstash 파이프라인 방식으로 데이터 동기화 진행

상품검색시 조회되는 쿼리 데이터를 엘라스틱서치 index로 설정

동기화 문제 해결

Logstash와 MySQL이 서로 다른 도커 컨테이너에서 실행 되어 Logstash가 MySQL 주소 찾지 못하는 문제
- 하나의 docker-compose.yml에서 실행으로 해결
RDB와 엘라스틱서치 중복 데이터 제거
- Logstash 파이프라인에서 document_id => "%{product_id}" 추가하여 해결
sql_last_value를 활용한 데이터 변경 추적
- Logstash 파이프라인의 sql_last_value값을 created_at, updated_at과 비교하여 생성, 수정된 데이터 변경 감지

2.2 Elasticsearch 상품 검색 목록 조회 평균 응답시간

Elasticsearch 정상 범위 데이터 4건의 평균 소요 시간
- 100 + 58 + 47 + 49 = 254 ms
평균 소요 시간
- 254 ÷ 4건
- 약 0.06초 (63.5ms)

3. 검색 성능 개선 결과

RDB vs Elasticsearch

RDB: 약 2.7초 (2,705ms)
Elasticsearch: 약 0.06초 (63.5ms)
Elasticsearch가 RDB보다 약 42.6배 더 빠른 검색 속도를 보여줌

24년 회고

유당불내증이 있는 개발자 — Wed, 1 Jan 2025 02:57:10 +0900

취업 그리고 퇴사

24년 1월부터 다니던 회사를 8월말에 퇴사하였다.

입사 후 얼마 지나지 않아 선임 개발자들의 퇴사로 인해 입사 동기와 둘이서 백엔드 업무를 진행하게 되는데 그때부터 뭔가 잘못돼감을 느꼈다.

그때 당시에는 '기회다 오히려 좋아. 이참에 나의 기술적 역량을 높이며 실무에 적용해 보자' 라는 부푼 마음을 가지고 임했다.

생각했던 것보다 작은 서비스라도 신입 둘이서 운영하기에 많은 어려움이 있었고 개인의 기술 역량, 문제 해결능력의 중요성을 느꼈다.

어느정도 시간이 지났고 회사에서 원하는 더 이상의 기능개발은 없었다.

그 후 월급이 들어오지 않았고 며칠 뒤 회사 경영난으로 인해 권고사직을 권유하는 메일을 받았다.

이때 당시에는 막막함도 있었지만 '드디어 각잡고 공부할 때가 왔다. 초심으로 돌아가자' 라는 생각을 했기 때문에 마냥 아쉽지만은 않았다.

결국 두달 치 월급을 받지 못한채 개발팀 대부분의 사람들이 퇴사를 하였다. 그렇게 작은회사는 아니라고 생각했는데 이렇게 갑자기 회사가 망할 줄은 몰랐다.

퇴사하니 그때 왜 더 아득바득 공부해서 여러 가지 시도를 해보지 못했을까 하는 아쉬움이 든다.

떼인 돈 받기

퇴사 후 밀린 월급을 받기 위해 회사와의 연락, 고용노동부 방문을 하며 그렇게 두달정도를 보냈다.

생각보다 회사는 협조에 저조했고 약속했던 실업급여를 받기까지도 꽤 오랜시간이 걸렸다.

세상의 쓴맛을 느꼈다.

이바닥도 쉽지 않구나.. 스트레스도 상당했고 무언가 손에 잡히지 않았다.

좋은 인생경험이라 생각했고 하나씩 해결해가며 어느정도 마무리 되었다. (아직 못 받은 돈이 조금 있다.)

이럴때가 아니다 다시 공부를 시작하자

스파르타 코딩클럽

F-LAB 멘토링 과정을 고민하던 중 스파르타 코딩클럽 단기심화 과정을 보게 되었고 대용량 트래픽 처리, MSA 키워드에 꽂혀 과정을 진행하게 되었다. 사실 국비 심화과정이라 무료였던 점도 컸다.

국비학원 출신으로서 국비, 부트캠프를 그렇게 신뢰하지는 않는다. 교육기관에 무언가 크게 바라지 않았고 공부하는 기간중 하나의 과정이라 생각하고 임했다.

그런데 생각했던 것보다 좋다. (너무 다행이다)

3번의 프로젝트를 진행하게된다. 뛰어난 팀원들도 만났고 담당 튜터님은 그동안 만나본 개발자 중에서도 선한 인성과 비례되는 좋은 실력을 가지셨다.

두가지 충족되는 개발자들은 잘 보지 못했는데 이게 가능한거였구나 싶다. 나의 롤모델 리스트중 한분이 되었다.

모의면접을 통한 기본기, 팀원들의 트러블 슈팅, 튜터님 특강 등 혼자 공부했다면 경험해 보지 못했을 거 같다.

물론 현타를 많이 느껴 감정의 변화가 자주 생긴다. 덕분에 공부에 집중을 못 할 때도 있지만 정해진 스케줄 안에서 팀원들과 이야기 나누며 지루하지 않게 공부하고 있다.

오래 앉아있지만 다 습득하진 못한거 같아 아쉬움은 크다.

끝으로

2024년은 다사다난한 해였다.

퇴사를 하고 공부를 하니 다시 개발에 재미를 느끼고 있는 중이다. 나는 아니라 생각했지만 환경에 영향을 많이 받는 사람이라 느꼈고 뭔가 진거 같아서 아쉽다.

25년은 개발 오타쿠로 살아가 보려한다. 좋은 개발자로 성장할 수 있기를

try-with-resources

유당불내증이 있는 개발자 — Wed, 25 Dec 2024 02:20:41 +0900

try-finally 문제점

package exam;

public class TryFinally {
    public static void main(String[] args) throws Exception {
        TestResource testResource = new TestResource();
        try {
            testResource.firstMethod();
        } finally {
            testResource.close();
        }
    }


    static class TestResource implements AutoCloseable {
        public void firstMethod() {
            System.out.println("firstMethod() 실행 ");
            throw new RuntimeException("첫번째 에러 발생");
        }

        @Override
        public void close() throws Exception {
            System.out.println("close() 실행 ");
            throw new RuntimeException("두번째 에러 발생");
        }
    }
}

1. 첫번째 메서드에서 에러가 발생했고 close()메서드를 실행된다.

2.만약 finally 에서 에러가 발생한다면 첫번째 메서드의 에러는 두번째 에러에 가려지게 된다.

3.처음 오류가 발생 근원지를 찾을 수 없다.

/Users/dongpillson/Library/Java/JavaVirtualMachines/corretto-17.0.9/Contents/Home/bin/java -javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=50215:/Applications/IntelliJ IDEA.app/Contents/bin -Dfile.encoding=UTF-8 -classpath /Users/dongpillson/study/TIL/out/production/TIL exam.TryFinally
firstMethod() 실행 
close() 실행 
Exception in thread "main" java.lang.RuntimeException: 두번째 에러 발생
	at exam.TryFinally$TestResource.close(TryFinally.java:23)
	at exam.TryFinally.main(TryFinally.java:9)

Process finished with exit code 1

try-with-resources 적용

package exam;

public class TryWithResources {
    public static void main(String[] args) throws Exception {
        try (TestResource testResource = new TestResource();) {
            testResource.firstMethod();
        }
    }


    static class TestResource implements AutoCloseable {
        public void firstMethod() {
            System.out.println("firstMethod() 실행 ");
            throw new RuntimeException("첫번째 에러 발생");
        }

        @Override
        public void close() throws Exception {
            System.out.println("close() 실행 ");
            throw new RuntimeException("두번째 에러 발생");
        }
    }
}

두개의 에러가 발생하는것을 확인할 수 있다.

Kafka, Redis를 활용한 이벤트 중복 처리 방지

유당불내증이 있는 개발자 — Thu, 19 Dec 2024 00:31:45 +0900

2차 팀프로젝트 회고

주문 서비스와 배송 서비스 간 Kafka 사용

네트워크 지연, 시스템 장애 등으로 인한 메시지 중복 전송이나 순서 보장 문제가 발생할 수 있는 문제에 대한 고민

구성

- 메시지 큐: Kafka
- 중복 처리 방지: Redis
- 이벤트 타입: OrderCreateEvent (주문 생성 이벤트)

1. 이벤트 중복 처리 방지

@KafkaListener(
            topics = "${spring.kafka.consumer.topic.order.create}", // OrderCreateEvent
            groupId = "${spring.kafka.consumer.group-id}", // group-delivery
            containerFactory = "orderCreateEventListener"
    )
    public void consumeOrderCreateEvent(DomainEventEnvelop<OrderCreateEvent> eventEnvelop) {
        OrderCreateEvent orderCreateEvent = eventEnvelop.getEvent();
        Long orderId = orderCreateEvent.getOrderId();
        LocalDateTime createdAt = eventEnvelop.getCreatedAt();
        String eventKey = EVENT_KEY_PREFIX + orderId;

        // 현재 이벤트가 기존 이벤트보다 과거이거나 같은 시간이면 무시
        String existingEventTimestamp = redisTemplate.opsForValue().get(eventKey);
        if (existingEventTimestamp != null) {
            LocalDateTime existingCreatedAt = LocalDateTime.parse(existingEventTimestamp);
            if (!createdAt.isAfter(existingCreatedAt)) {
                log.warn("과거 이벤트 발생 [orderId: {}, currentEventTimestamp: {}, existingEventTimestamp: {}" , orderId, createdAt, existingCreatedAt);
                return;
            }
        }

Redis를 활용하여 주문아이디와 이벤트의 타임스탬프 정보를 저장하였고 동일한 주문 아이디에 대해 이전 이벤트보다 과거의 이벤트가 들어오면 무시

2. 이벤트 정보 저장

redisTemplate.opsForValue().set(eventKey, createdAt.toString(), Duration.ofDays(1));

이벤트 정보를 Redis에 1일간 보관, TTL설정을 어떻게 하면 좋을지 판단이 안되었다.

3. 배송 생성

try {
    deliveryService.createDelivery(DeliveryCreateRequestDto.from(orderCreateEvent));
} catch (Exception e) {
    log.error("Failed to process OrderCreateEvent - orderId: {}, error: {}",
            orderCreateEvent.getOrderId(), e.getMessage(), e);
    throw new RuntimeException(e);
}

유효한 이벤트에 대해 배송 생성 하며 예외 발생 시 로그 기록

데이터베이스 기반 중복 처리 방법

따로 이벤트 발생되는 로그를 테이블에 저장 후 값을 읽어와도 될 거같다.

DB 부하 증가, 이벤트 처리 지연 시간 증가의 문제가 있다는것을 예상은 하지만 트래픽이 얼만큼 발생되느냐에 따라 다를거같다. 또 아직 그만큼의 트래픽은 경험해보지 못해서 이번에 비교 성능테스트를 하지못한 점은 아쉽다.

이벤트 발생 정보를 레디스로 저장 후 휘발 시킬것인가? 로그까지 저장할 것인가에 대한 고민은 해결되지 않았다.

Ch.2 대규모 AI 시스템 설계 프로젝트 S.A

유당불내증이 있는 개발자 — Mon, 9 Dec 2024 11:26:34 +0900

API 명세서

https://www.notion.so/teamsparta/API-4919a95833be44d2bf9228a1c9b5e1b9

API 명세서 | Notion

Basic Response 구조

teamsparta.notion.site

Auth(회원) API

주문 API

상품 API

배송 API

배송 경로 API

배송 담당자 API

허브 API

허브 경로 API

업체 API

SNS, AI API

테이블 명세서

https://www.notion.so/teamsparta/DB-2f6f5a7373bf4fd0bed1e5f573d04f1e

DB 설계 | Notion

테이블 명세

teamsparta.notion.site

ERD

인프라 설계서

OSIV (Open Session In View)

유당불내증이 있는 개발자 — Sun, 1 Dec 2024 01:12:49 +0900

OSIV (Open Session In View)

영속성 컨텍스트를 HTTP 요청 시작부터 응답까지 유지하는 기능

여기서 View라는 개념이 어떤건지 궁금했다.

REST API 등 View가 없는 서비스에서도 이 용어를 그대로 사용한다고 한다
View라기보다는 클라이언트에 대한 응답이 완료되는 시점을 의미
HTTP 응답이 끝날 때까지 영속성 컨텍스트를 유지하는 개념으로 확장

OSIV의 View는 역사적인 용어이며 현재는 클라이언트에 대한 응답 완료 시점으로 이해하면 된다고 한다.

spring.jpa.open-in-view=?

JPA를 사용하면 yml에서 위의 값을 true,false로 설정할 수 있다. 기본 설정값은 true이다.

spring.jpa.open-in-view=true

이 설정이 true 라면 http 요청 시작부터 끝까지 DB커넥션을 가져와 영속성 컨텍스트를 유지한다. (영속성 컨텍스트는 기본적으로 커넥션을 유지)
트랜잭션 범위가 아닌 곳에서도 사용할 수 있다는 것인데 예를들면 controller단에서의 엔티티 조회시 Lazy loading으로 조회가 가능하다.
커넥션을 오래 가지고 있게되어 성능에 문제가 발생할 수 있다.

spring.jpa.open-in-view=false

@Transactional 이 붙은 service 쪽에서만 영속성 컨텍스트를 유지한다.
만약 다른곳에서 사용하고 싶다면 DTO 클래스를 만들어 반환하여 구성
오래 DB커넥션을 가지고 있지않아 대용량 트래픽 상황에서 커넥션 관리에 용이하다.

테스트

spring.jpa.open-in-view=true 설정했다.

별문제없이 Lazy Loading이 동작한다.

다음은 spring.jpa.open-in-view=false

LazyInitializationException이 발생한다!

물론 service단에서도 @Transactional을 붙이지 않으면 LazyInitializationException이 발생한다.

정리

Service를 제외하고는 엔티티를 직접적으로 사용하지 않게 코드를 작성해왔다 했다.

그렇지만 spring.jpa.open-in-view=true 기본설정값으로 인해 @Transactional 없는곳에서 동작했던 부분에 대해 직접 오류를 겪어보지 못했던거 같다.

앞으로도 Service쪽이 아닌 View 즉, 다른곳에서는 엔티티를 직접 호출하지 않을 것 같지만 Lazy Loading 관련해 동작원리에 대해 다시 되짚어보게 되는 시간이었다.

또 DB 커넥션을 HTTP 요청 시점부터 계속 잡고 응답 시에 반환하는 것은 대규모 트래픽에서 커넥션 풀 문제가 발생할 수 있다는 점을 이번에 새로 알게되었고 트래픽 상황에 고려해 설정값을 false로 두어야겠다.

참고 :Claud, ChatGPT

https://ykh6242.tistory.com/entry/JPA-OSIVOpen-Session-In-View%EC%99%80-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94

JPA - OSIV(Open Session In View) 정리

OSIV(Open Session In View) OSIV(Open Session In View)는 영속성 컨텍스트를 뷰까지 열어두는 기능이다. 영속성 컨텍스트가 유지되면 엔티티도 영속 상태로 유지된다. 뷰까지 영속성 컨텍스트가 살아있다면

ykh6242.tistory.com

보초개발

String, StringBuilder, StringBuffer 성능 비교

성능 테스트

테스트 결과

중고차를 알아보다 작성하는 조회 성능 개선기 (Redis 캐싱)

중고차의 늪

조회 성능 개선 고민

인기 상품 조회 성능 테스트

Log 작업

캐싱 스케줄러 로직 구현

상품 단건 조회 캐시 적용

인기상품 캐싱 후 부하테스트

인기 상품 캐싱 전 후 비교

EXPLAIN 발표

발표 자료 및 영상

상품 재고 관리 - 비관적 락 vs 분산 락 적용 사례

재고 차감 동시성 문제

문제 상황

해결 방안 고민

❓분산락 적용 안한 이유

❓낙관적 락 적용 안한 이유

재고 롤백 스케줄러 분산락 적용

문제 상황

해결방안

❓비관적 락 적용 안한 이유

분산락 적용

RDB vs Elasticsearch 검색 성능 비교

1. RDB 상품 검색 목록 조회 평균 응답시간

1.1 Full-Text Index 적용

2. 엘라스틱서치 적용

2.1 데이터 동기화 방법 고민

동기 처리

비동기 처리

결론

동기화 문제 해결

2.2 Elasticsearch 상품 검색 목록 조회 평균 응답시간

3. 검색 성능 개선 결과

RDB vs Elasticsearch

24년 회고

취업 그리고 퇴사

떼인 돈 받기

스파르타 코딩클럽

끝으로

try-with-resources

try-finally 문제점

try-with-resources 적용

Kafka, Redis를 활용한 이벤트 중복 처리 방지

구성

- 메시지 큐: Kafka- 중복 처리 방지: Redis- 이벤트 타입: OrderCreateEvent (주문 생성 이벤트)

1. 이벤트 중복 처리 방지

2. 이벤트 정보 저장

3. 배송 생성

데이터베이스 기반 중복 처리 방법

Ch.2 대규모 AI 시스템 설계 프로젝트 S.A

API 명세서

테이블 명세서

ERD

인프라 설계서

OSIV (Open Session In View)

OSIV (Open Session In View)

spring.jpa.open-in-view=?

spring.jpa.open-in-view=true

spring.jpa.open-in-view=false

테스트

정리

- 메시지 큐: Kafka
- 중복 처리 방지: Redis
- 이벤트 타입: OrderCreateEvent (주문 생성 이벤트)