BackEnd262 [JPA] Hibernate6 SQLFunctionTemplate not working anymore 1. 문제의 상황 이번에 SpringBoot 3로 migration 하면서 Hibernate도 6으로 변경하게 되었다. 하지만 더 이상 SQLFunctionTemplate을 사용할 수 없다는 점을 알게 되었다... 나의 프로젝트에는 많지는 않지만, 소량의 CustomFuction들이 존재하고 있던 상황이다... 다음은 기존 Hibernate5에서 커스텀하여 사용하고 있던 "match"라는 이름의 함수이다. 의존성 자체를 찾을 수 없는 상황이였으며, Hibernate의 SQLFunctionTemplate 자체가 deprecated 되었다는 점 을 알게 되었다. 따라서 이를 변경하기 위해 엄청난 삽질을 했는데.... 나처럼 삽질하지 않도록 하기 위해.... 기록을 남겨본다. 2. 해결 방법 1) 다음과 같이.. BackEnd/JPA 2024. 3. 17. 험난한 Django REST framework 경험기 저는 평상시에 서버개발에 주로 Java, Kotlin, Spring 조합을 사용하던 "Java 2명 타요"중 1명에 속하는 사람이었습니다. Java + Spring의 개발 직관성과 생산성은 정말 사랑할 수밖에 없다 생각하거든요! 그럼에도 다른 언어 진영의 서버사이드 프레임워크들이 항상 궁금했었습니다. 스프링이 편한 것을 알기 위해서는 다른 도구들이 불편한 것을 알아야 그 대비적 효과가 더 크다 생각하기 때문입니다(?) 다행히 학기 초반에 일주일 정도의 여유시간이 생겼으며, 그나마 언어는 알고 있는 Python 진형의 기술인 DRF를 공부해 보는 시간을 갖게 되었습니다....... 만..... 한 10일 정도 공부해 보고 느낀 점은... 음... 할 말이 많아지는 기술이더군요.... 따라서 제가 직접 느낀.. BackEnd/기타 2024. 3. 15. [쿠링] 헥사고날 아키텍처를 향하여 (By TDD) 이번 글을 통하여 기존의 쿠링의 계층형 아키택처를 Hexagonal Architecture로 리팩토링 해 나가려 한다. 그럼 기존에 어떠한 점이 불편했기에 이러한 선택을 하게 되었을까? 기존의 문제점부터 한번 살펴보자. 1. 기존 아키텍처의 문제점 1-1) 데이터 중심의 설계? 우선 가장 첫 문제점은 우리의 앱이 어느순간부터 데이터베이스 중심적으로 설계가 진행되고 있었다는 점이다. 사용자를 위한 애플리케이션이라면, 해당 문제를 해결할 도메인 로직이 중요한데... 정작 이점은 고려하지 못하고 구현된 아키텍처였다. 다음 글은 내가 이에 대하여 좀더 설명해 둔 글이기에, 자세한 설명은 다음 글을 읽어봐 주시길! https://blogshine.tistory.com/688 계층형 아키텍처는 왜 데이터베이스 중심.. BackEnd/쿠링 2024. 2. 2. 계층형 아키텍처는 왜 데이터베이스 중심의 설계를 유도할까? 1. 계층형 아키텍처가 어때서? 마틴 파울러의 책, PoEAA (Pattern of Enterprise Application Architecture: 엔터프라이즈 애플리케이션 아키텍처 패턴)을 보면 대표적인 3 계층을 소개하는 파트가 있다. 이름도 그 흔한, 3-tire-아키텍처, 또는 계층형 아키텍처 등 부르는 이름도 은근 다양하다. 이러한 아키텍처를 사용하던 방식을 잠시 떠올려보면... 최상단의 표현 계층이 도메인(서비스) 계층에 의존하고, 다시 도메인 계층은 영속성 계층에 의존하게 된다. 사용자 요청의 시작을 기점으로 생각해보면 이러한 흐름은 자연스럽게 데이터베이스에 의존하게 된다. 개발자가 의식하지 못한 사이에 어느덧 도메인 계층의 코드들이 영속성 계층을 기반으로 만들어지게 된다..... 이쯤 돼.. BackEnd/기타 2024. 1. 25. [쿠링] Pattern 하나로 서버 OOM발생시켜 다운시키기 (Heap Dump 보기) 1. 처음엔 문제인 줄 몰랐다... 현 쿠링은 엄청 비싼 인스턴스를 사용하지는 않고 있기 때문에 인스턴스 한대당 Memory가 512MB에 불과한 서버를 사용 중이다. (대신 값싼 거 3대로 운영 중) 심지어 메인서버는 Heroku이고, 테스트서버와 모니터링 서버는 AWS에서 기동중이다. (메인 서버 이전이 쉽지가 않다...) 평상시에는 크게 문제처럼 느껴지지 않던 부분이 시간적 여유를 갖고 보니 조금은 어색하게 느껴진 부분이 있었다. 우선 다음 모니터링 기록을 살펴보자 ▶ Heap : G1 Eden Space ▶ Heap : G1 Survivor Space G1 Eden 영역에 수시로 생성되고 있는 양이 어림잡아 170MB, 그중 Survivor로 살아남는 녀석들은 MAX 7MB. 그럼 163MB나 매.. BackEnd/쿠링 2024. 1. 18. [쿠링] Spring JDBC를 사용한 Batch Insert 구현과 고민 예전부터 시간 나면 해결하고 싶었던 문제 중 하나인 Batch(Bulk) insert에 대한 구현을 하며 이번글을 남기게 되었다. 기존에 주로 사용해 왔던 JPA의 한계로 인하여 이러한 결정을 하게 되었는데, 어떤 문제점과 고민이 있었는지 이번 글을 통하여 공유해 볼까? 한다. 고민 1 : JPA가 무엇인가? 이것부터 생각해 보기 기존에 내가 사용하던 ORM 기술인 JPA는 ORM의 대표 기술이다. 그럼 ORM은 어떤 철학을 갖고 설계된 것일까? 이를 wiki에서 검색해 보았다! ORM (Object–relational mapping) Object–relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programmin.. BackEnd/쿠링 2024. 1. 14. [Kafka] Kafka Connect on Docker 1. 문제의 상황 MSA 토이프로젝트를 진행하던 도중 Local에서만 사용하던 Kafka와 Kafka Connector를 Container로 만들어 사용해야 하는 일이 발생하였다. 따라서 모든 서비스에 Dockerfile을 만들어 커테이너화 시켜주었으며, 추가적으로 DB와 Kafka또한 컨테이너화 시켜야 했다. 우선 MSA 토이 프로젝트의 구조는 다음과 같다!! 간단한 쇼핑몰 서비스 이며, 오늘 글에서 다룰 부분은 Order-Service와 Kafka 부분이다. 그냥 Kafka 자체만 필요하면 제공되는 Docker 이미지 사용하면 끝이라 쉽지만, 그 외 Connector를 함께 사용하려 하니 준비해야 할 점이 추가적으로 있었다. 또한 DB에 저장하기 위해 최종적으로 JDBC 라이브러리 또한 필요하여 추가.. BackEnd/Kafka 2023. 12. 6. [쿠링] 사용자 인증의 시작부터 끝까지의 여정 항상 프로젝트를 진행할 때마다 한 번씩은 고민해 왔던 문제가 있다. 바로 "인증, 인가 가 과연 해당 서비스의 핵심 비즈니스 로직인가?"에 대한 고민이다. 경험이 부족했던 시점에야 당연히 이러한 생각조차 하지 못하여 논의할 내용조차 없었다 경험이 조금 있는 시점에서는 일단은 API수준에서 구현은 가능하지만 이를 어떤 방식으로 분리해야 할지 몰랐다. 이번 글에서는 이러한 나의 고민을 스스로 적어보고, 해결해나가는 과정을 기술할 것이다! (즉, 지극히 개인적인 내용.... 태클 환영) 고민 1 : Core Business란 무엇인가? 경계가 있는가? 가장 우선적으로 고민했던 부분은 Core Business라는 것 이 뚜렷한 경계가 있는 것 인가였다? 이에 대한 확인을 위해 위대하신 GPT에게 질문을 던져보았.. BackEnd/쿠링 2023. 10. 7. [쿠링] 효율적인 Log 관리를 위한 여정 - 1 1. 문제가 되는 상황 여유가 생겼을 때 쿠링이 Log를 남기고 있는 과정에 대하여 한번 고민해보고 싶었다. 오늘 글은 크게 3가지에 대한 고민으로부터 시작되었다. 1) Log의 level이 적합한가? (이번 글에서 해결할 내용) 2) Log 파일의 사이즈가 너무 커지지 않도록 나뉘어 저장되고 있는가? (이번 글 에서 해결할 내용) 3) Log의 모니터링이 편리하게 되고 있는가? (추가 글에서 다룰 예정) 일단 2가지에 대하여 답해보면, 현 쿠링은 "아니요"라고 답할 수 있을 거 같다. 크게 기준없이 설정된 log들의 level, 더 나아가 log를 보기 위해서는 직접 EC2에 접근하여 로그 파일을 살펴봐야 했다... 또한 로그가 중요하다는 생각에 무분별하게 남기는 것이 과연 좋은가? 나는 습관적으로 예.. BackEnd/쿠링 2023. 8. 27. [Linkllet] 검색 쿼리 개선하기 (by 커버링 인덱스) 우선 이번 테스트는 M1 맥북, 메모리 16G의 노트북에서 docker 환경의 MySQL에서 수행되었습니다. 전체 article 데이터 약 87만건을 기준으로 실험하였습니다. 1. 문제 되는 상황 우선 원래의 "프로그램"을 검색하는 query는 다음과 같다. select a.article_id, a.title, a.link, a.created_at from article a where a.member_id = 1 and (a.title like '%프로그램%' escape '!') order by a.created_at asc; 실행 결과는 다음과 같다. 약 2.4초가 걸렸으며, 데이터의 건수는 485건이 조회된다. 검색 쿼리의 실행계획은 다음과 같다. 몇 가지 살펴보자! type이 ALL로 되어 있는거.. BackEnd/Linkllet 2023. 8. 13. [Kafka] Multi-Service 간의 데이터 동기화 1. 문제의 상황 여러 개의 독립된 Order Service가 동작하고 있는 상황에서, 각 OrderService마다 DB를 할당하게 된다면 동기화 작업이 힘들어진다. 예를 들어 초콜릿의 재고가 초기에 10이었을 때, OrderService A에 주문이 들어와 3개가 감소하여 7개가 되었다 생각해 보자. 하지만 OrderService B에 할당된 DB에는 여전히 재고가 10개 있으며, 이는 DB 간의 데이터 동기화를 어렵게 만드는 주범이 될 것이다! 예를 들면 다음과 같은 것이다! 현재 사이드로 구현 중인 미니 프로젝트에서 UserService에서 주문 요청 -> Service Discovery를 통해 해당 서비스 찾기 -> 해당 OrderService에 주문 요청을 하게 된다. 2개의 OrderServ.. BackEnd/Kafka 2023. 8. 8. [Linkllet] 흔한 N+1 문제 해결하기 1. 문제 되는 상황 팀원 중 한 분이 폴더 목록을 조회할 때, 해당 폴더 내부에 몇 개의 링크가 저장되어 있는지 그 원소의 수 또한 함께 전달해 달라 요청해 주셨습니다. 이 카톡을 처음 봤을 때 시간이 늦은 시간이었던 지라 매우 간단하게 생각하고 다음날 바로 구현하겠다 하고 눈을 감았습니다만.... 그럴 때 있잖아요? 뭔가 실수한 거 같아서 눈은 감고 있지만 계속 생각날 때? 머릿속에 스쳐 지나가는 N+1 쿼리 문제.... 아 이거 폴더마다 count 쿼리가 날아갈 텐데... 아읔.... 일단 자야지 하면서.... 계속 어떻게 구현할지 생각하다 잠들어버렸습니다..... 다음날 눈 뜨자마자 N+1을 외치면서 눈을 뜨게 되었습니다... (진짜로.. 눈뜨자 마다 이생각부터 난...) 1 - 1) ER 다이어.. BackEnd/Linkllet 2023. 7. 21. 이전 1 2 3 4 ··· 22 다음
