pending 메시지큐를 사용하지 않고 어떻게 알림을 구현하면 될까?우리 인프라에서 사용할 수 있는 인프라는 EC2 하나, MySQL 하나다.이걸로만 푸시알림을 무리 없이 구현할 수 있는걸까? 의심이 계속 들었지만 언제까지 고민만 할 수 없기에자신감을 갖고 끝까지 이 문제를 풀어보기로 결심했다. 푸시 알림은 서비스에서 필수불가결한 기능이다. 메시지 큐를 언젠간 도입할 수 있겠지만 유저 수가 40명 대인 현재의 서비스에서는 기존에 갖고 있는 인프라를 최대한 활용하는 방식으로 구현해보고 싶었다. 시작은 가벼웠으나..처음에는 "유저가 게시글에 댓글을 달면 알림을 준다"는 요구사항을 가볍게 흐름으로 나눠봤다. 1. 유저가 사연(게시글)에 댓글을 작성한다.2. 알림 기록을 저장하는 테이블인 Notificati..

이 글은 openjdk와 spring-boot wiki의 내용을 참고하여 작성한 글입니다. 새 프로젝트를 시작할 때 가장 먼저 부딪히는 건 코드가 아니라 선택이다. 자바는 몇 버전을 쓸지, 스프링 부트는 어디에 맞출지, 폴더는 어떻게 나눌지. 늘 하던 대로 최신 버전 골라놓고 넘어가도 되지만, 그렇게 정한 결정은 나중에 "이거 왜 이렇게 했더라?"라는 질문에 답을 못 한다.그래서 이번엔 개발 방향과 그 이유를 담은 설계서를 먼저 썼다. 아래는 그 문서를 정리한 내용이다. 1. 자바 버전자바 버전을 고려할 때, 실제 자바 개발자들이 작성하는 문서인 openjdk 문서를 참조하자. 이전 LTS 버전과의 변경점과 최신 버전의 java 변경 사항을 구체적으로 확인할 수 있다. LTS만 본다버전을 고를 때 전체..

일요일 저녁 6시 28분, 메일 한 통이 왔다. 예전이었다면 이런 문제는 늘 이렇게 시작됐다. 프론트 개발자가 "로그인이 안 되는데요?"라고 말한다. 나는 로컬에 서버를 다시 켠다. 재현되지 않는다. 그럼 내가 할 수 있는 말은 두 가지뿐이었다. "한 번만 다시 해보시겠어요?" 아니면 "로그아웃했다가 다시 로그인해보세요."운이 좋으면 그렇게 넘어갔다. 원인은 끝내 모른 채로.이번엔 달랐다. EC2에서 클라우드 와치로 로그를 보내고 로그 그룹을 만들어 로그를 기록하도록 했기 때문이다.메일을 받고 CloudWatch를 열었을 때, 운영 서버의 스택 트레이스가 그대로 남아 있었다. 나는 "다시 해보시겠어요?" 대신"혹시 이 시간에 뉴진스 검색하시고 401 받으셨죠?"라고 물을 수 있었다.그리고 그 대화 끝..

B-Tree와 Hash 데이터 구조를 이해하면 이러한 데이터 구조를 인덱스에 사용하는 다양한 스토리지 엔진에서 다양한 쿼리의 성능을 예측하는 데 도움이 될 수 있습니다.B-Tree 인덱스 특성B-Tree 인덱스는 =, >, >=, SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';위 문장에서는 조건을 만족하는 행만 고려합니다.‘Patrick' ‘Pat’ 다음 SELECT문장들은 인덱스를 사용하지 않습니다.SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';SELECT * FROM tbl_name WHERE key_col L..

에러예외Checked ExceptionUnchecked Exception에러(Error)Error는 애플리케이션이 정상적으로 복구하기 어려운, 주로 JVM 레벨의 심각한 문제를 나타낸다.Exception과 형제 관계이지 부모-자식 관계가 아니라는 점이 중요하다.문법적으로는 Error도 잡을 수 있다(catch (Error e)). 하지만 catch 하지 않는게 관례이다. 이유는 발생 시점에서 이미 JVM이나 시스템이 비정상 상태이기 때문에, 잡아서 복구할 수 없거나 오히려 문제를 숨기는 결과를 만든다. 그래서 Error는 모두 unchecked다. 컴파일러가 처리를 강제하지 않는다.주요 하위 클래스로는 StackOverflowError(메모리 한계), OutOfMemoryError(힙 영역 공간 부족) ..

똑똑한 최적화가 놀랍게도 역효과가난 사례와 그 최종 해결을 공유.처음 작성한 슬로우 쿼리SELECT id FROM posts WHERE channel_id = '9tne5g44z...'AND deleted_at = 0AND created_at 실행계획 분석 결과는 다음과 같다: 이 쿼리는 그들의 환경에서 실행하는 데 몇 분이나 걸렸는데, USE INDEX(idx_posts_channel_id_delete_at_create_at)을 사용하면 1초도 안걸려 실행됐다고한다. 위의 EXPLAIN 출력을 보면, 옵티마이저가 idx_posts_created_at 인덱스를 선택하고 있는 걸 알 수 있는데, 사실 idx_posts_channel_id_deleted_at_created_at를 선택하는게 명확히 더..

Hibernate가 제공하는 SoftDelete@SoftDelete 는 하이버네이트 6.4 버전부터 도입된 애노테이션입니다.https://docs.hibernate.org/orm/6.5/javadocs/org/hibernate/annotations/SoftDelete.html SoftDelete (Hibernate Javadocs)(Optional) Conversion to apply to determine the appropriate value to store in the database. The "domain representation" can be: true Indicates that the row is considered deleted false Indicates that the row is co..

문제 상황특정 유저가 댓글을 단 모든 게시글 중 게시글이 삭제되지 않으면서 댓글도 삭제처리 되지 않은 모든 게시글을 쿼리하는 API 가 존재한다. 현재는 posts를 먼저 조회하기 위해 straight_join을 걸고 left join을 하고 있다.또한, WHERE c.user_id = 827493558402544824 AND c.is_deleted = false를 하고 있어서 쿼리가 inner_join으로 바뀌어서 처리되고 있다. 이를 조금 더 명확하게 inner_join을 의도를 담아 직접 쓰는 방향으로 수정도 필요하다. 4 먼저, 위 쿼리를 이너조인으로 변경하고 straight_join 힌트를 제거해주었다.straight_join 키워드는 post 보다 comment 가 더 많이 달릴거라는 예측..

현재 프로젝트에 남은 인덱스는 두 개이지만, DB 테이블에 남아있는 인덱스는 실험하면서 걸어둔 인덱스가 모두 남아있었다. 아래 쿼리는 현재 댓글 작성이 열려 있어서 댓글 작성이 진행되고 있는 게시글의 최신순 10건 조회 쿼리다.이 쿼리는 지금 인덱스를 잘 타고 있을까? 항상 주요 지표인 select_type, type, Extra를 잘 살펴보자. select_type은 SIMPLE type은 ref Extra에 Using where 해당 쿼리의 실행계획은 MySQL 서버에서 체크 조건(Using where)을 확인해주고 있긴 하지만 아주 효율적인 것을 알 수 있다. 어어? 현재 인덱스 추가를 해 두지 않은 인덱스를 선택하고 있다. 내가 걸어놓은 Posts 테이블의 인덱스는 idx_is_comple..

버퍼 풀(Buffer Pool)버퍼 풀은 주 메모리(RAM) 안에 있는 영역으로, InnoDB가 접근되는 테이블 데이터와 인덱스 데이터를 캐시(저장)하는 곳이다. 버퍼 풀 덕분에 자주 쓰는 데이터는 메모리에서 바로 접근할 수 있어 처리 속도가 빨라진다. 전용 서버에서는 보통 물리 메모리의 최대 80%까지 버퍼 풀에 할당하는 경우도 많다.대량 읽기(read)를 효율적으로 처리하기 위해, 버퍼 풀은 페이지(page) 단위로 나뉘며, 한 페이지에는 여러 행(row)이 들어갈 수 있다. 캐시 관리를 효율적으로 하기 위해 버퍼 풀은 페이지들의 연결 리스트(linked list)로 구현되어 있고, 거의 사용되지 않는 데이터는 LRU(Least Recently Used) 알고리즘의 변형으로 캐시에서 밀려나게 된다.버..