개요 📝A 사에서 진행하는 x 프로젝트에서는 기존에 A 사에 구축된 시스템과 연동을 통해 데이터를 받아오는 로직이 존재했었다. 새롭게 A 사에서 수주한 y 프로젝트는 x 프로젝트가 받아오는 데이터가 필요했으나, x 프로젝트와 같이 A 사 시스템과의 연동은 보안 문제로 허용되지 않는 상황이었다. 결국 x 프로젝트에서 A 사와 연동해 가져온 데이터를 y 프로젝트 쪽 DB로 넘겨주는 방안이 필요했고, 이를 위해 메시지 브로커인 Kafka를 사용하게 되었다. 내용 📌앞에서 설명했듯이, 나는 데이터를 주고받는 중계자의 역할로서 Kafka를 활용하게 되었다. API 가 아닌 외부 브로커인 Kafka를 사용했던 이유는 데이터 송수신 간 아래와 같은 장점이 있기 때문이었다:Kafka를 사용하는 애플리케이션 인스턴스..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/bWEqsu/btsJg6iNWm2/6Ff5wxsGVtCFIRE02hU7Q0/img.png)
FCM 이란?Firebase Cloud Messaging 의 줄임말로, 메시징 기능을 클라우드 서버에서 제공해주는 구글의 서비스이다. 개요프로젝트를 하는 도중에 FCM 을 사용해 볼 수 있는 기회가 생겼다. 용도는 특정 알림 기능을 모바일 단말에 푸시로 전달하는 것이었다. 기존에 구현되어 있는 기능이었으나, 최근에 FCM Legacy API 가 만료됨에 따라 V1 으로 마이그레이션하는 작업을 하게 되었다.FCM 동작 플로우프로젝트 생성먼저 FCM 은 위에서 언급한대로 클라우드 서버에서 기능을 제공하기 때문에, 어떤 프로젝트 하위에서 푸시를 주고받을 건지 정해야 한다. 그래서 프로젝트를 생성하면 아래와 같은 페이지로 관리가 가능하다: 관리자 페이지는 프로젝트별로 생성이 되고, 프로젝트 정보는 아래 항목들..
새로운 프로세스 구현하기앞서 레디스 활용기 - 1 는 어떻게 레디스를 활용하기로 결정하게 되었는지에 대한 내용이었다면, 이번에는 그 구체적인 구현 방식을 소개해 보고자 한다.레디스의 특징구현을 하기 위해 학습해야 했던 레디스 (Redis) 의 몇몇 특징은 다음과 같다: 레디스는 key-value 형태로 데이터를 저장한다.value 는 hkey-value 형태 또는 그냥 문자열이다.key 가 문자열인 데에 반해, hkey 는 해시 값으로 인식된다.여러 명령어를 통해 key / hkey / value 를 다룰 수 있다. 몇 가지 자주 사용되는 명령어들은 아래와 같다:get {key 이름} : key-value(문자열) 인 경우에 {key 이름} 에 해당하는 value 를 반환한다.hget {key 이름} {..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/crNurM/btsHGzrVAw1/lNqrnWYJjGhlUwa1j9BAF1/img.png)
📌 개요현재 사물 또는 사람에게 부착된 IoT 기기로부터 BLE 신호 형태로 수신되어 정제된 데이터를 RDB 에 쓰고, 다시 읽어서 상태 (위치 등) 를 모니터링 할 수 있는 소프트웨어 개발 및 운영에 참여하고 있는 중이다.사업은 병원들을 위주로 전개하고 있으며, 각 클라이언트마다 서로 다른 요구사항들을 갖고 있다.약 3년 전 이 모니터링 소프트웨어를 설치하여 지금까지 개발 및 유지보수를 해주고 있는 Y 병원에서 한 달 전쯤 이슈제기를 해왔다:방문자 출입기록과 로그 데이터가 일치하지가 않습니다! 방문자 출입기록은 말 그대로 병원에 각기 다른 목적으로 방문하는 다양한 사람들의 현황을 IoT 기기 (Y 병원에서는 스마트폰 앱) 를 이용하여 파악하고 정리한 기록이다. 회사에서 개발 중인 모니터링 소프트웨어..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/bHVh02/btsHzuZKNKg/yKmHqv64xkDJV4rAEfCR01/img.png)
...which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by 위 에러가 발생해서, 확인해보니 full_group_by 옵션이 켜져 있어 group by 절에 없는 컬럼은 어느 부분에 표시해야 할 지 정하지 못해서 발생하는 문제라고 한다. full_group_by 옵션을 끄기 위해, 구글링을 해봤다. 먼저 아래 쿼리로 full_group_by 옵션이 설정되어 있는지 확인했다:쿼리: select @@sql_mode;결과 (@@sql_mode 컬럼의 값): ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DAT..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/sy61h/btsd1iTOrzY/fuKNwE9oVBkqvQ7kIhPjuK/img.png)
Introduction 새로운 프로젝트를 생성하면서 그동안의 Swagger 을 사용한 문서화 방식 대신 Spring REST docs 를 활용해보고자 했고, 이전에 사용하지 않은 플러그인을 추가했다. 개요 Gradle 로 빌드 시 발생한 에러를 자세히 읽어본 후 관련 코드를 찾아보다가 플러그인 중 ''org.asciidoctor.convert'' 가 추가된 것을 발견할 수 있었다. 해결 구글링을 하는 도중 asciidoctor 는 Spring Rest Docs 에서 사용하는 플러그인이라는 사실을 알게 되었다. Spring Rest Docs 공식 문서에서는 다음과 같이 build.gradle 파일을 작성하라고 되어 있다. plugins { (1) id "org.asciidoctor.jvm.convert" ..
![](http://i1.daumcdn.net/thumb/C148x148.fwebp.q85/?fname=https://blog.kakaocdn.net/dn/ErBDO/btr1POk7GhT/NidLvLBUmHmhE6x7aYYZzK/img.png)
Goal 캐시를 적용하여 같은 키워드 사용하여 검색 시 캐시에 저장된 쿼리문과 엔티티를 사용하도록 하여 검색 속도 개선 캐싱 적용하기 위한 준비 * 환경 - Spring Boot 3.x - Hibernate 6.x 우선 Hibernate 의 버전을 확인하고 버전에 맞는 EhCache 의존성을 build.gradle 에 추가해주었다. 출처의 첫 번째 링크를 참조해서 JCache 와 EhCache 의 의존성을 모두 추가 후 yml 파일을 설정해 1. L2 캐시를 사용하며 2. 콘솔 로그에서 L2 캐시가 적용이 올바르게 되었는지 확인하겠다고 명시했다. 아래는 build.gradle 에 추가한 dependencies 이다. implementation 'org.hibernate.orm:hibernate-jcach..
Introduction 프로젝트를 하던 중, DB 에서 테이블을 조회하는 코드가 중복이 많다는 것을 알게 되었다. 이후 중복을 없애기 위해 디자인 패턴을 적용하자고 마음을 먹고 전략 패턴을 적용해보았다. 패턴 적용 전 코드 public SearchPageGetResponse findTracksWithKeyword(Pageable pageable, String searchKey, String memberEmail) { Member member = validateMember(memberEmail); Page tracks = trackRepository .findAllByTrackTitleContainingOrAlbumAlbumTitleContainingOrArtistArtistNameContaining(ke..
- Total
- Today
- Yesterday
- spring
- 가상 서버
- DTO
- gitlab
- google cloud
- Firebase
- Java Data Types
- Jackson
- 프로그래머스
- 인증/인가
- 알고리즘
- json web token
- docker
- 실시간데이터
- DeSerialization
- 기지국 설치
- Spring Boot
- JPA
- JPQL
- 코테
- 도커
- LazyInitializationException
- 역직렬화
- 지연 로딩
- N+1
- 깃랩
- FCM
- @RequestBody
- JOIN FETCH
- ci/cd
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |