모종닷컴

멀티 모듈 프로젝트를 구성하다보니 그레이들에 대해 참 모르고 있던 부분들이 많았다는 걸 깨닳았네요.. Gradle 관련 공부를 어떤 방식으로 진행할 지 아직 정하지 못했기 때문에 간단하게 공식 문서상에서 소개하는 Gradle에 대해 알아보도록 하겠습니다. Gradle 이란? Gradle은 거의 모든 유형의 소프트웨어를 빌드 할 수 있음 만큼 충분히 유연하게 설계된 오픈 소스 빌드 자동화 도구입니다. Gradle 주요 특징 고성능 : Gradle은 입력 또는 산출물이 변경되어 실행해야 하는 작업만 실행함으로써 불필요한 작업을 방지합니다. 또한 빌드 캐시를 사용하여 이전 실행 또는 공유 빌드 캐시가 있는 다른 시스템에서도 작업 산출물을 재사용할 수 있습니다. 또한 현재까지도 팀에서 Gradle의 성능을 개선..

잘못된 모듈 설계 19년도에 만들고 있던 개인프로젝트를 멀티모듈프로젝트를 진행했었다. 대충 기억을 되짚어보면 아마 front-end, admin-api, pay-api, common 뭐 이런식으로 모듈을 구성하였던 것 같다. 그리고 이런식으로 구성한 모듈이 우아한형제들 블로그에 올라온 글에서 실패한 설계의 예로 쓰이고 있음을 알게되었다. 그 때 개인프로젝트를 예시로 좀 들어보면 이렇다. A,B,C,D,E 모듈이 있다. C에 API가 하나가 작성되었고 이 API를 D, E 서버가 사용해야 한다고 가정해보자. API의 응답 및 요청 DTO들이 생겼다. 이걸 D, E 서버에 모두 넣어야 할까? 그럼 중복으로 코드를 작성하고 관리하기 힘들테니 common에 작성을 해놓는다. 자연스럽게 A, B도 common을 ..

3계층 구조 Presentation Layer : 사용자 중점 계층 (front-end) Business Layer : 비즈니스 로직 계층, presentation layer의 요구를 받아 처리하는 곳 (back-end) Data Layer : 데이터베이스에 접근하여 데이터를 읽거나 쓰는 작업등의 역할 Mock Layer란? Mock Layer라는 개념이 존재하는 것은 아니고 제가 임의로 편하게 부르기 위해서 지어봤습니다. 위의 3계층 구조에서 Business Layer에 속하게 됩니다. 테스트 코드를 짜다보면 mockito 라는 테스트 프레임워크에 대하여 한번쯤은 들어보셨을 겁니다. 어떤 특정 요청에 대하여 개발자가 지정한 결과를 내려주는 방식인데 이러한 것을 실행 환경에서도 사용하기를 원했습니다. 한..

아주 예전부터 Quartz에 대한 글을 써야지 생각만 하고 어느새 잊어버렸는데요. 이번 회사 동료가 Quartz 적용을 한 발표를 하는데 너무 오래전에 본 내용이라 기억이 하나도 안나네요.. 그래서 기억좀 되살릴겸 Quartz 정리를 좀 해보았습니다. Quartz Job Scheduling 란? Quartz는 작은 독립형 애플리케이션부터 거대한 e-commerce 시스템에 이르기까지 거의 모든 Java 애플리케이션 내에 통합될 수 있는 풍부한 기능을 갖춘 오픈 소스 작업 스케줄링 라이브러리입니다. Quartz는 수십, 수백, 심지어 수만 개의 작업을 실행하기 위한 단순하거나 복잡한 일정을 만드는 데 사용될 수 있습니다. Quartz Scheduler에는 JTA 트랜잭션 및 클러스터링 지원과 같은 많은 엔..

이전 글 : https://monny.tistory.com/223 VIEW 알고리즘 이해하기 - MERGE 편 뷰 테이블이 있는데 되게 느려져서 좀 찾아보다가 알게된 부분들이 있어 글로 정리하려고 합니다. 알고리즘 MySQL에서 뷰를 처리할 때 알고리즘의 종류는 아래와 같다. MERGE : MERGE를 사용하면 뷰 monny.tistory.com 이전 글에서 MERGE에 대해서 알아보았습니다. 오늘은 TEMPTABLE 전략에 대해 알아보려고 하는데 TEMPTABLE 전략은 아래 글의 Materialize와 같습니다. 옵티마이저의 파생 테이블 관련 전략 옵티마이저는 파생 테이블 참조를 두 가지 전략을 이용하여 다룹니다. Merge (병합) : 외부 쿼리에 파생 테이블을 병합. Materialize (구체화..

뷰 테이블이 있는데 되게 느려져서 좀 찾아보다가 알게된 부분들이 있어 글로 정리하려고 합니다. 알고리즘 MySQL에서 뷰를 처리할 때 알고리즘의 종류는 아래와 같다. MERGE : MERGE를 사용하면 뷰 정의와 뷰를 참조하는 명령문의 관련 부분이 병합됩니다 TEMPTABLE : TEMPTABLE을 선택하면 뷰 결과가 임시 테이블에 저장됩니다. UNDEFINED : MySQL이 사용할 알고리즘을 정합니다. 기본 알고리즘은 optimizer_switch 시스템 변수의 derived_merge 플래그 값에 결정됩니다. UNDEFINED 뷰 알고리즘은 아래와 같은 상황에 지정됩니다. CREATE VIEW 에 알고리즘을 지정하지 않았을 때 CREATE VIEW 문에 명시적으로 ALGORGERM = UNDEFI..

mongodb에 특정 기간 안에 생성된 데이터를 검색해야 할 일이 있었습니다. mongodb를 자주 다뤄보지는 않아 between 관련 쿼리를 구글에 검색해봤는데 어떤 글은 new Date를 사용하고 어떤 글에서는 ISODate를 이용해서 쿼리를 날린다고 합니다.. 이 두 개의 차이가 뭘까 하고 알아보았는데 일단 mongodb에는 항상 UTC를 기준으로 시간 데이터가 입력된다고 합니다. 따라서 한국 20시 00분의 시간을 mongo에 저장하면 11시 00분이 들어가게 되는 것이죠. 이게 사실인지 확인해보기 위해 실습을 조금 해봤습니다. Spring Boot + Mongodb 의존성 추가 implementation 'org.springframework.boot:spring-boot-starter-data-..

버퍼 풀 InnoDB 스토리지 엔진의 핵심적인 부분이다. 디스크의 데이터 파일이나 인덱스 정보를 메모리에 캐시해 두는 공간. 쓰기 작업을 지연시켜 일괄 작업으로 처리할 수 있게 해주는 버퍼 역할도 같이 한다. => 디스크 작업의 횟수를 줄일 수 있다. 버퍼 풀 사이즈 운영체제와 클라이언트 스레드가 사용할 메모리를 고려하여 설정해야 한다. 클라이언트 세션에서 테이블의 레코드를 읽고 쓸 때 버퍼로 사용하는 공간을 '레코드 버퍼'라고 하는데, 커넥션이 많고 사용하는 테이블도 많다면 레코드 버퍼 용도로 사용되는 공간이 많이 필요해질 수 있다. 하지만 레코드 버퍼 공간은 별도로 설정할 수 없으며, 전체 커넥션 수와 커넥션에서 읽고 쓰는 테이블의 개수를 가늠할 수 없으므로 정확한 메모리 공간 산정이 어렵다. 위에서..

이번 글에서는 제가 Postman에서 자주 사용하는 꿀팁 아닌 꿀팁을 공유드리고자 합니다. 일단 예시 상황을 먼저 보도록 하겠습니다. 일련의 과정들을 호출 이런 예시 상황을 들어보도록 할게요. 멤버를 등록하는 API를 호출 후, 해당 멤버의 이름을 업데이트하는 api를 호출 이어서 멤버를 삭제하는 api를 호출하는 프로세스가 필요하다고 합시다. 일단 포스트맨에 컬렉션 하나를 추가하고 컬렉션에 3개의 Request를 추가합니다. 아래에서 3개 API 스펙을 설명하도록 하겠습니다. 다만 블로그 글을 위해 엉망진창으로 만든 API라서 불편하더라도 그냥 봐주시면 감사하겠습니다ㅎㅎ... 멤버 등록 이름만 받으면 멤버 등록이 완료됩니다. 응답 메시지로는 생성된 멤버의 id를 그냥 리턴하도록 했어요 멤버 이름 수정..

깃허브에 용량이 큰 파일인 경우 블락당한다는 사실을 알고 계신가요?? 용량이 큰 파일을 왜 제한하고 있는지, 큰 파일의 기준이 어떻게 되는지, 용량이 큰 파일을 어떻게 올릴 수 있는지를 한번 알아보도록 하겠습니다. 용량이 큰 파일을 제한하는 이유 GitHub에서는 사용자의 성능과 안정성을 보장하기 위해 전체에 대하여 리포지토리 상태(= repository health)를 모니터링하고 있으며. 리포지토리 상태 체크는 크기, 커밋 빈도, 커밋 내용, 커밋 구조를 보고 있습니다. 그리고 이 상태 체크에 커밋 파일 크기가 걸리는 걸로 보입니다. 이는 리포지토리의 크기를 작게유지하기 위함도 있는 것 같습니다. 깃허브에서 설명에 따르면 리포지토리의 크기는 1GB, 5GB 미만을 권장한다고 합니다. 리포지토리가 작을..