![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/J7AI4/btstxkC7s4q/e2o2KG4wklk2lJt7zvGbO0/img.png)
최근에 여러 일이 겹쳐 오랜만에 포스팅한다. 현재 담당하고 서비스의 개발은 대부분 RDB를 사용한다. 때문에 NoSQL DB를 접할 일이 많이 없었다. 이번에 이벤트성으로 개발할 일이 생겼는데, 이 개발에는 AWS DynamoDB를 사용해보자고 했다. 선택에는 별 다른 이유는 없었는데, 이벤트성 사용하고 치울 데이터를 메인 RDB에 저장할 필요가 없다고 느껴서였다. 그러나 저런 단순한 이유를 차치하더라도, AWS DynamoDB는 충분히 좋은 DB이다. 어떤 특성이 있는지 알아보자. DynamoDB란? Amazon DynamoDB는 키 값과 문서 데이터 모델을 지원하는 서버리스 NoSQL 데이터베이스 서비스의 일종입니다. 개발자는 Amazon DynamoDB를 사용하여 소규모로 시작하여 전 세계로 규모를..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cvOq31/btssf0TFU6V/MeyQkgiy3t1H2b1pvqrFck/img.png)
이전 글에서는 QueryDSL을 왜 도입하려했는지, 왜 선택했는지 다른 툴과 비교 분석을 해봤다. 이번 글은 스프링부트에 어떻게 설치하고 사용할지 작성해보려 한다. build.gradle plugins { id 'com.ewerk.gradle.plugins.querydsl' version '1.0.10' ... } dependencies { implementation "com.querydsl:querydsl-jpa:5.0.0" implementation "com.querydsl:querydsl-apt:5.0.0" ... } def querydslDir = "$buildDir/generated/querydsl" querydsl { jpa = true querydslSourcesDir = querydslDi..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cx9ylT/btsr5XW29Nt/HvRFm04OrQknpN3N86F9a0/img.png)
SI 회사에서 일할 무렵엔 항상 MyBatis만 사용했었다.(생각해보니 현재 기준으로 반년도 안지났다.) JPA를 사용하자고, 사용해보자고 자주 이야기했지만 결국 도입에 실패했던 기억이 있다. ㅠ 그런데 이직한 곳도 막 서비스가 런칭한지 얼마 안됐음에도 MyBatis를 쓰고 있었다. 하지만 여긴 JPA 도입을 권장해줘서 JPA를 사용해볼 수 있었는데, 사용하면서 마음에 들지 않는 부분들이 보이기 시작했다. 가장 큰 문제점이라 생각하는건 쿼리가 복잡해지면 JPQL이란걸 사용해야 했다. 아래는 JPQL의 예시다.public interface HistoryRepository extends JpaRepository { @Query("SELECT h FROM UserActivity h WHERE h.tim..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/bWmEKB/btsr4W4VkEE/hGgBaWkWKMraCxZt5LDM0K/img.png)
java의 poi를 이용해 엑셀파일을 핸들링할 일이 생겼다. poi는 엑셀 파일을 핸들링하기 위해 workbook이라는 객체를 생성한다. 별 생각없이 객체를 생성해서 사용하는데 IntelliJ에서 아래와 같은 알림을 던져줬다. try-with-resources으로 덮으라는데 이게 뭘까? 일단 클릭해본다. 그러면 try 구문으로 해당 라인이 변경된다. try (Workbook workbook = new XSSFWorkbook()) { Sheet sheet = workbook.createSheet(sheetName); ... catch (IOException e) { e.printStackTrace(); } try-with-resources 구문을 왜 쓸까? try-with-resources 구문은 Java..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/dHHxdB/btsrYS2ye3q/FJH2RT7ri1L5A8EYhCJJ1K/img.png)
이전 글에서 사용했던 Cosine Search는 dense vector 하나만을 이용한 방법이었다. 그래서 내가 조금 더 다양한 정보를 갖고 있을 때, 이를 전부 활용하기 어렵다는 단점이 있다. 예를 들어, 내가 알고 있는게 게시물의 제목, 내용, 작성자, 작성 시간 등 몇 가지의 정보가 있음에도 게시물의 제목만 활용할 수 있다는 것이다. 모든 내용을 한문장에 섞어서 하나의 벡터화를 할 수도 있겠지만, 이럴 경우 엄밀히 말하면 각각을 비교한 결과가 아니게 된다. 이렇게 다양한 정보를 활용하기 위해서 Elasticsearch에서는 K-NN search 기능을 제공한다. 이를 이용해 검색 기능을 Springboot로 구현해봤다. 대략적인 구현은 cosine search에서 구현한 방식을 따라가려고 한다. 그..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/LCkeo/btsrTQ4AYn6/zSO7I6Moq40u4Eo8kOSuFk/img.png)
아래는 한 서비스에서 쓰고 있는 application.yaml 파일이다. 위와 같이 길어진 이유는 서버의 종류가 엄청 많기 때문이다. 서버가 local/dev/stag/qa/prod 외에도 스케줄러가 붙어있어서 7~8개의 profile이 한 yml파일에 존재하게 됐다. 각각 서버의 profile은 아래와 같이 분리해서 application.yml 파일에 설정한다. ### ### ### local ### ### --- spring: config: activate: on-profile: local 나눠 놓을 수는 것 까지는 좋다. 그런데 관리를 제대로 하지 않았다. 그래서 모든 서버에서 공통적으로 사용하는 부분을 분리하지 않아서 yaml 파일이 엄청나게 길어지게 된 것이다. 이런 식으로 보관하면, 모든 서버..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/ps3vd/btsrEr5pgBJ/d6xKKLeKWcKfgnAMKfcmhk/img.png)
List의 element를 삭제하는데 위와 같은 에러가 발생했다. 코드를 보면 별 내용은 없다. 리스트의 첫 번째 요소를 삭제하는 코드이다. List lines = Arrays.asList(str.split("\n")); lines.remove(1); 에러가 발생하는 이유는 Arrays.asList()로 생성된 리스트는 고정 크기 리스트이기 때문이다. 고정 크기 리스트이기 때문에, remove도 안되지만 add도 안된다. 해결법은 간단하다. 가변 크기의 리스트로 변환하면 된다. ArrayList는 가변크기의 리스트니까 아래와 같이 ArrayList로 재선언해주면 정상적으로 사용가능하다. List lines = new ArrayList(Arrays.asList(str.split("\n"))); lines...
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/onulf/btsrVqXXgZm/An9KxL2Cz9XQz1OUeoqsH1/img.jpg)
문제의 발생 새로운 프로젝트를 시작하면서, 로그를 다시 붙여야할 일이 생겼다. 기존 프로젝트에 로그를 개발하면서 했던 파이프라인을 그대로 가져와서 붙여넣었는데, POST 요청에서 이상하게 동작하지 않았다. 원인을 분석하면서 생긴 일을 정리해보려고 한다. 우선 현재 시스템에서 로그를 어떻게 찍는지 간단히 정리해보고 가자. 1. Controller에서 API 요청을 받아서 서비스로직까지 처리한 후 return 2. 이 return 할 때 AOP AfterReturning을 통해 캐치 3. 이때 발생하는 return object와 요청 정보를 담고 있는 HttpServletRequest을 통해서 로그를 생성 이 과정 중 3번에서 문제가 발생했다. 사실 스프링부트에서 POST 요청의 RequestBody를 가져..
- Total
- Today
- Yesterday
- Elastic cloud
- docker
- AWS EC2
- springboot
- 람다
- lambda
- java
- GIT
- Kotlin
- openAI API
- S3
- 오블완
- EKS
- 스프링부트
- terraform
- AOP
- CloudFront
- 후쿠오카
- 티스토리챌린지
- AWS
- OpenFeign
- OpenAI
- ChatGPT
- serverless
- Spring
- cache
- MySQL
- elasticsearch
- JWT
- Log
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |