코딩대장경

쓰레드는 프로세스 내부에 존재며 프로세스의 Stack 영역에 해당한다. 1. 메모리 (Memory) 쓰레드는 프로세스 내에서 동일한 메모리 공간을 공유합니다. 이로 인해 데이터 공유 및 효율적인 통신이 가능합니다. 2. 병렬성 (Concurrency) 쓰레드는 동시에 실행될 수 있으므로 다중 쓰레드 프로그래밍을 통해 병렬 처리를 구현할 수 있습니다. 이를 통해 시스템의 성능을 향상시킬 수 있습니다. 3. 작업 분할 (Task Division) 여러 쓰레드를 사용하면 작업을 분할하고 병렬로 처리할 수 있습니다. 이를 통해 복잡한 작업을 각각의 쓰레드에 할당하여 빠르게 실행할 수 있습니다. 4. Context Switching 다중 쓰레드 프로그램에서는 쓰레드 간의 전환이 발생할 때 Context Switc..

통상적으로 작성해둔 Validation은 Controller딴에서 ReqeustDto로 역직렬화 할 때 Spring Boot가 자동으로 해준다. 하지만 나는 RequestDto뿐만 아니라 ResposneDto나 내부적으로 사용하는 Class에서도 사용할 수 있게끔 하고 싶었다. Validator를 사용해서 생성자 호출시에 유효성 검사를 하게끔 했다. Exception Advice에서 처리 하던 BindException과 형태가 달라서 문제가 생겼다. 기존의 방식과 똑같이 Exception을 만들기 위한 코드도 함께 첨부한다. BindException 잘못된 변수명과 그 이유에 대한 Message를 함께 출력하는 코드다. 아래 코드는 디버깅을 통해 변수명과 메세지를 찾은 뒤 맵핑시켰다. 관련 포스팅 @Ex..

저번에 포스팅한 Gitlab runner에 이어서 .gitlab-ci.yml 파일 작성하는 법에 대해 알아보겠다. 이전에 작성한 Circle CI에서는 nginx를 docker를 통해서 띄웠다. 이 방식은 불필요하게 프로젝트마다 nginx가 설치되고 nginx 이미지가 동일하기때문에 자칫 잘못하면 nginx가 한번에 다운될 수 도 있다. 이번에는 nginx를 컨테이너 외부에 설치했다. 이전 포스팅에서는 gitlab-runner를 java 버전별로 설치했는데 서버 성능 이슈때문에 병렬로 pipeline을 실행하지 못하게 하나의 runner만 등록하게 변경했다. 현재 runner에는 모든 java버전이 설치되어 있다. .gitlab-ci.yml docker login시 ~/.docker/config.json..

회사에서 쓰던 Repository가 Github에서 Gitlab으로 이전했다.. 그래서 이참에 Gitlab Runner를 적용해보려고 한다. 결과부터 말해보자면 Gitlab Runner가 Circle CI보다 만족스러웠다. Gitlab은 Linux User까지 관리해줘야해서 조금 귀찮았지만 Gitlab내에서 Repository와 CICD 상황을 모두 확인 할 수 있는 점이 편했다. 무엇보다 View가 친절하고 깔끔하다.. Github도 이번에 Runner를 도입했던데 나중에 기회가 된다면 써볼예정이다. Info gitlab-runner : runner를 등록할 agent runner : gitlab-runner에 등록된 runner cpu : 2core memory : 2G disk : 32G 1-1. ..

이 포스팅은 nginx를 불필요하게 프로젝트마다 설치한다. 개선된 deploy.sh 는 이곳에 있다. 이전 포스팅 에서 말한 제로타임배포를 구현하기 위해 가장 유명한 Blue-Green전략을 사용하기로 했다. 개념은 나보다 잘 설명할 사람이 많으니 직접 찾아보시길.. 이번 프로젝트?는 가능한 많은 사람이 간편하게 사용하는 것을 목표로 만들었다. Repository가 바뀔때 마다 설정해야하는 값들이나 변경가능성이 있는 변수들 모두 쪼개서 환경변수로 관리했다. config.yml을 작성하는 것 보다 각종 파일들을 동적으로 만들거나 target port 관리 nignx설정 등에 시간을 많이 들였다. 현재 방식은 nginx를 불필요하게 프로젝트마다 설치한다. 개선된 deploy.sh 는 이곳에 있다. 파일 구성..

나는 단순히 제로타임배포를 하고 싶었을 뿐인데 어쩌다보니 circleci의 self-hosted runner를 설치하게 되었다... 자체서버를 사용하는 젠킨스를 이용해서 구현하려 했으나 circle ci라는 좋은 cicd툴이 있으니 써보라는 말을 많이 들었고 도전해보게 되었다. runner는 젠킨스와 같이 서버에 직접 설치할 수 있다. gitlab또한 runner가 존재하지만 빌드 속도면에성 circle ci가 우세하다는 의견이 많아서 circleci를 채택하게 되었다. (아마 캐싱능력이 더 뛰어나지 않을까 예상해본다.) 처음에는 linux용 runner를 설치하려다가 알 수 없는 오류로 실패했다.. 이 과정은 굉장히 복잡하고 어려워서 그냥 docker를 이용한 runner를 설치하기로 했다. docke..

Compile 은 해당 라이브러리가 의존하고 있는 모든 모듈를 불러오고 Implement는 최소한의 모듈만 불러온다. Implement가 성능상 유리한것이 확실한 만큼 거의 모든 Gradle 설정에 Implement가 사용되고 있다. 다만, 궁금한 점은 결국 Implement 사용시 라이브러리를 구성하는 모든 모듈를 불러오지는 않는다는 건데 애초에 라이브러리가 효율적으로 의존성을 구성한게 아니라는 건지 불러오지 않아도 되는 모듈이 왜 존재하는지 이해가 잘 가지 않아서 찾아봤다. 문제 상황은 다음과 같다. 모듈 A - 모듈 B를 의존하는 라이브러리 X 가 있고 모듈 A - 모듈 C를 의존하는 라이브러리 Y 가 있을때, complie을 사용하면 모듈 A를 중복해서 2번 빌드하게 되고 implement를 사용..

Request에서 String을 받아 Enum으로 변환하는 작업을 해야한다. 받아온 String이 Enum에 속한 값인지 판단하는 Validation Annotation을 생성하고자 한다. 물론 애초에 convertor를 통해 Request에서 직접 Enum타입을 받는 방법도 있다. 다만, 후자의 경우에는 convertor도 구현하고 Enum Validator도 구현해야하기에 비용이 적게드는 첫 번 째 방법을 선택했다. 어노테이션을 만든다는 것은 생각 보다 어렵지 않았다. 무엇보다 Enum Validator는 이미 코드가 많기 때문에 구현에 어려움은 없었는데 문제는 List로 된 Enum은 구글링으로 찾기 어려웠기에 직접 구현했다. Valid에 사용되는 어노테이션은 예시가 많기 때문에 구현에 어려움은 없..

기존 이름은 'Join시 n+1 문제 Map으로 해결' 이었으나 생각해보니 n+1 문제가 아니라 그냥 최적화 문제이므로 수정했다. 회사에서 사용중인 DB는 외래키가 존재하지 않고 양이 워낙 많아(테이블만 280개..) JPA를 활용한 batch_fetch_size의 기능을 쓰기 어렵다. 따라서 이를 자료구조로 해결하고자 방향을 잡고 생각해보니 Map을 활용하면 꽤나 효율적으로 작업을 할 수 있을 것 같았다. 부모 spot 테이블과 자식 spotImg, spotTheme 테이블을 예로 들어 설명해보겠다. 일단 spot에서 필요한 데이터만 가지고 온다. (자세한 쿼리는 보안상 생략) List spotListByCondition = spotRepository.getSpotListByCondition(spotI..

추가... 작업중 이 게시글이 완전히 잘못되었다고 깨달았다. @DynamicUpdate와 ON DUPLICATE KEY UPDATE 는 서로 완전히 상관없다. 만약 중복시 update하는 기능을 사용하고 싶다면 update 로직을 따로 작성해서 select 후 insert나 update를 하거나 native query를 이용해서 업데이트 시키면된다. 전자의 경우 만약 업데이트된 데이터가 없다면 @DynamicUpdate로 인해 쿼리를 날리지 않을것이다. 회사에서 일하던 중 'INSERT ... ON DUPLICATE KEY UPDATE ...' 라는 sql문을 발견했다. PK나 unique key를 기준으로 해당 값이 이미 존재하면 row를 새로 생성하지 않고 업데이트하겠다는 의미다. 더티체킹 이라는 키..