hojak99 의 블로그

새벽 3시30분인데 지금 매우 화난다. 졸리니까 우선 간단히 쓰겠다. 코틀린을 기반으로 개발하고 있다. DB 테이블에서는 json 타입의 필드에 단순히 [123, 321, 133] 와 같은 값을 넣고있다. 그리고 entity 에서는 해당 필드를 Set 으로 타입을 정의해놓았다. 그리고 converter 를 직접 만들어서 json 을 잘 변환하도록 entity 클래스에 해당 필드에다가 converter 를 지정해주었다. 해당 필드의 이름이 numbers 라고 했을 때 querydsl 을 이용해 조건을 다음과 같이 걸어주었다. numbers.contains("311") 근데 자꾸 hql 을 보니 해당 numbers 필드를 가지고 조인을 해버린다. 어이가 없다. 해당 필드는 조인할 수 없는데 hql 에서 as..

mysql 이 어떻게 돌아가고 어떤 구조로 돼 있는지 공부해야지 해야지 하다가 이제서야 공부하고 글을 작성해 보려고 한다. 다른 블로그에도 지금 작성하는 내용과 같거나, 비슷한 내용이 작성 돼 있는 곳이 많기 때문에 살짝 의식의 흐름대로 작성한다. 이 글은 [REAL MySQL] 이라는 책을 기반으로 작성한다. MySQL 의 전체 구조 우선 책에도 나와있지만, 간단히 MySQL 전체적인 구조를 한 번 보는게 좋을 것 같다. 우선 앞으로 설명할 것들은 MySQL 을 크게 구분할 수 있는 [MySQL 엔진], [스토리지 엔진] 부분이다. ### MySQL 엔진 접속 및 쿼리 요청 처리하는 커넥션 핸들러, SQL 파서, 전처러리기, 쿼리 최적화를 위한 옵티마이저로 이루어져 있다. 또, InnoDB 의 버퍼 풀..

jpa 에서는 테이블 별로 엔티티 클래스를 생성해서 개발을 하고 로직으로 구현하면 됐었으나, mybatis 에서는 어떻게 개발을 해야 좋은 구조가 될 지 고민을 하고 있다. 우선 mybatis 로 jpa 처럼 구현을 하자니 mybatis 의 장점, 특징들을 못 살리는 것 같아서 애매하고, 도메인이 복잡해서 여러 테이블을 조인해서 사용하는데, 조인해선 나오는 필드들로 매핑 클래스를 생성하니 다른 곳에서 사용하기 애매하다,, 그래서 쪼금 다르게 매핑 클래스를 만드니 중복되는 필드들이 우후죽순으로 생겨나 버리고 관리하기 힘들어지는 것 같다. 또 그렇다고 그냥 불필요하게 조인되는 매핑 클래스를 이용해버리면 단일 책임 원칙을 위배되고 처음에 말했던 것처럼 불필요한 조인을 해버리니,,,,, 어떻게 해야 좋은 구조로..

DB 를 잘 모르거나 지식이 없는 채로 서비스를 개발할 때 누군가 이 글을 보고 이렇게 하면 안되는구나! 라고 생각했으면 하고 글을 작성해본다. 문제 상황 동시에 회원가입 요청이 들어왔을 때 중복되는 ID 값을 갖게 돼 2명의 사용자의 데이터가 하나의 ID 를 갖게 되는 상황이 발생했다. 그리고 다른 테이블에서는 해당 키를 외래키로 사용을 하는데 A 란 사용자로 인해 생긴 데이터인지, B 라는 사용자로 인해 생긴 데이터인지 판단할 수 없게 되었다. 결국 해당 데이터들은 모두 제거하게 되었다. 그렇다면 왜 이런 상황이 발생했을까? 원인 서버에서는 해당 ID 값을 직접 생성하고 있었다. 가장 마지막 ID 값을 가져와 + 1 을 하여 값을 넣어줬고, 아마 요청이 동시에 일어나거나, 트래픽이 많지 않기 때문에 ..

해당 내용은 Real MySQL 책을 인용하였습니다. MySQL 서버를 세팅할 때 구글링을 해서 셋팅해서 사용하고 그랬었는데 서버 셋팅 시 어느 정도 지식이 있어야 함을 느꼈다. 서버 설정 MySQL 서버는 단 하나의 설정 파일만 사용한다. 리눅스/유닉스 계열에서는 my.cnf, 윈도우 계열에서는 my.ini 파일을 사용한다. 이 파일의 이름을 변경할 수 없으니 참고해야 한다. 또 중요한 점은 이 설정 파일들이 여러 디렉토리에 존재할 수 있다. MySQL 서버에서는 지정된 디렉토리를 순차적으로 탐색하면서 처음 발견된 설정 파일을 사용한다. (물론 지정된 디렉토리를 다르게 설정할 수도 있다) 리눅스 서버에서 MySQL 서버를 셋팅했다고 가정하고 얘기를 하도록 하겠다. 만약 여러 개의 설정 파일들이 있고, ..

사이드 프로젝트 백엔드 설계를 어떻게 할지 고민 중 박용권님의 우아한 모노리스 세미나를 듣고 멀티 모듈로 변경하였다. 나한테는 개인적으로 도움이 된 부분이 많아서 좋았던 것 같다. 현재 마이크로서비스에서 멀티모듈로 구조를 바꿔가는 중이라 따로 사이드이펙트가 생기거나 그러지는 않은 상황인데 멀티 모듈로 개발하면서 생긴 고민이나 내가 생각 했을 때 문제점? 을 블로그에 작성하려고 한다. 이번 달 최고 잘한 일은 귀찮더라도 세미나를 간 것이 아닐까 싶다. 멀티 모듈로 구성하면서 참고한 깃허브 저장소이다. 세미나를 해주신 박용권님의 깃허브 저장소이다. https://github.com/arawn/building-modular-monoliths-using-spring arawn/building-modular-mo..

운이 좋게 "우아한 모노리스" 라는 세미나를 듣게 되었다. https://www.facebook.com/woowahanTech/photos/a.1925530564354206/2487165348190722/?type=3&theater 우아한Tech [마감] 2020년 우아한Tech의 첫 세미나 1월 우아한테크세미나 우아한형제들 박용권님의 "우아한모노리스" 세미나 소식을 전합니다.🙇‍♀️🙇 하단 내용을 확인하시고 링크를 통해 신청해주세요. 😉 제목 : 우아한모노리스 일시 : 1월 23일 목요일 오후 7시 30분 장소 : 우아한형제들 작은집 7층 교육장 http://naver.me/Gx536FCe... www.facebook.com 간단하게 얘기하자면 박용권이라는 분은 기존 모놀리틱 서비스에서 마이크로서비스로..

현재 다니고 있는 회사에서 제공하는 서비스는 전형적인 모놀리틱 시스템이다. 같은 회사 동료와 MSA 로 새롭게 서비스를 구축하자라는 공통된 의견을 가졌다. 그 이유는 기존 서비스 구조는 어딘가를 수정하려면 그와 함께 봐야하는 코드가 많고 비즈니스 로직이 너무 촘촘하게 결합 돼 있었기 때문이다. 여기 한군데 건들면 모든 코드가 영향을 받는다. 우선적으로 DB 구조도 뭔가 분석하거나 쌓인 데이터를 통해 인사이트를 얻을 수 있는 그런 좋은 구조가 아니였고 불필요한 컬럼 및 테이블이 쌓여있었다. 현재는 다른 개발자 분들께 현재 서비스에서 나중에는 이런 식으로 서비스를 나누고 DB 는 이렇게 나눴으면 좋을 것 같다. 라는 것까지 이야기가 됐다. 그러나 현실적으로 보았을 때 3년도 채 되지 않은 스타트업에서 기존 ..

> 해당 글은 엔터프라이즈 자바 마이크로 서비스 를 보고 작성합니다. 언젠간 모놀리틱 서비스에서 마이크로서비스로 마이그레션 할 일이 있을 것이라 생각을 하며,,,, 모놀리틱 서비스에서 마이크로서비스로 마이그레이션 할 때 여러가지 패턴이 존재한다. - 빅뱅 패턴 (Big Bang) - 스트랭글러 패턴 (Strangler) - 하이브리드 패턴 (Hybrid) 빅뱅 패턴 빅뱅 패턴은 쉽게 말해 기존 모놀리틱 서비스에서 한 번에 바로 마이크로서비스로 변환하는 패턴을 말한다. 급격하게 변하기 때문에 사이드이펙트가 크고 비즈니스에 큰 타격이 갈 가능성이 존재한다. 예를 들면 마이크로서비스로 한 번에 변환했는데 어느 부분에서 갑자기 서비스가 먹통이 돼 CS 폭주 등,, 근데 시스템이 먹통인 상태에서 오류를 고치는데는..

이번에 사이드프로젝트를 진행하면서 카카오 로그인을 붙여야 했다. Spring boot 를 이용하여 카카오 로그인을 연동해야 했기에 카카오에서 제공하는 REST API 를 이용하였다. https://developers.kakao.com/docs/restapi/user-management Kakao Developers_ 더 나은 세상을 꿈꾸고 그것을 현실로 만드는 이를 위하여 카카오에서 앱 개발 플랫폼 서비스를 시작합니다. developers.kakao.com 우선 처음으로 access token 과 refresh token 을 관리하는 것을 구현해보기 때문에 처음에 Spring Security 를 이용하여 어떻게 구현할 것인지, access token 과 refresh token 을 어떻게 관리하고 갱신할..