일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
29 | 30 | 31 |
- 리눅스
- 자바 프로젝트
- 학점
- 티스토리
- 유사코드
- 파이썬 소스
- SQL
- 프로젝트
- K6
- 백준 알고리즘
- oracle
- 알고리즘
- 문법 정리
- 오라클 디비
- resilience4j
- MongoDB
- smart cast
- jsp
- hyperledger
- dynamic query
- spring
- JVM
- auto configure
- 자바
- 오라클
- 운영체제
- c#
- 초대장
- 파이썬
- gradle
- Today
- Total
목록Programming (154)
모종닷컴
Spring에서 Redis을 사용할 때 동적인 데이터를 삽입해야 하는 경우가 있습니다. spring-data-redis 버전에 따라 살짝 다르긴 하지만 현재 사용 중인 2.2.13.RELEASE 버전을 기준으로 포스팅하도록 하겠습니다. 프로젝트 세팅 (gradle, kotlin, spring boot) 그레이들 스크립트 import org.jetbrains.kotlin.gradle.tasks.KotlinCompile plugins { id("org.springframework.boot") version "2.2.13.RELEASE" id("io.spring.dependency-management") version "1.0.15.RELEASE" kotlin("jvm") version "1.6.21" kot..
SQS Standard Queue를 사용 중인데 동일한 메시지를 각 애플리케이션이 중복 수신된 적이 있습니다. 제가 생각한 것들이 맞다면 메시지는 중복 수신되지 않을 것 같았는데 이런 이슈가 왜 발생했는지 궁금하여 좀 찾아봤습니다. 일단 생각했던 아키텍처를 그림으로 그려보면 아래와 같습니다. Queue에서 동시성 처리가 되어있다면 app1, app2, app3에서 동시에 요청하더라도 메시지1, 메시지2, 메시지3이 잘 분배가 되겠지라는 게 기본적으로 깔려있던 전제였습니다. SQS 아키텍처 이제 SQS의 실제 아키텍처를 보면 아래와 같습니다. 큐라고 생각했던 모습과는 완벽하게 다른 형태입니다. 큐에 메시지 삽입 이제 SQS에 메시지를 적재하는 과정과 메시지의 라이플 사이클에 대한 설명을 이어나가도록 하겠습..
혹시 AWS Simple Queue Service(SQS)를 활용하고 계신가요? 그리고 어떤 이유에 의해서 SQS에서 polling 해오는 부분을 임의로 중지 및 시작할 수 있도록 컨트롤하고 싶으신 적이 있으신가요? 그렇다면 이번 글이 도움이 될 수도 있을 것 같습니다. 저는 위와 같이 SQS를 임의로 중지하거나 시작하는 등의 컨트롤을 해야 하는 경우가 있었고 이 글이 저와 같은 고민을 하고 계신 분들께 도움이 될 수 있을 것 같아 이번 포스팅을 쓰게 되었습니다. 시작하기 전에 먼저 테스트 환경 및 코드를 먼저 맞춰보도록 하죠. 환경 세팅 IAM 사용자 생성 SQS를 사용할 수 있는 사용자 하나를 추가해보도록 하겠습니다. IAM 서비스에 들어가서 '액세스 관리'의 '사용자' 탭에 들어갑니다. 그러면 아래..
이전 포스팅(Circuit Breaker Pattern 그리고 이를 스프링에 적용해보기)에서 예고한 대로 Circuit Breaker의 상태 변화에 따른 이벤트 리스너 추가 및 서킷의 상태를 수동으로 변경하는 법 및 서킷브레이커를 리셋하는 방법을 쓰려고 합니다. 이벤트 리스너 추가 CircuitBreaker를 적용하고 나서 고민했던 포인트 중 하나는 서킷브레이커가 OPEN 상태가 되었을 때 개발자들도 인지를 했으면 좋겠다는 생각이었습니다. 처음에는 서킷브레이커 코드 중에서 상태를 변경하는 부분을 찾아내서 해당 부분을 커스텀하면 되지 않을까?라는 생각을 했었습니다. 서킷브레이커 코드를 조금 찾아보고 나니, 서킷에 이벤트 리스너가 있는 걸 알 수 있었습니다. 관련해서 계속 파고들어 가다 보니 CircuitB..
MySQL의 경우 flyway를 통해서 데이터 마이그레이션을 진행할 수 있는데 Mongodb의 경우는 데이터 마이그레이션을 하기 위해서는 어떤 라이브러리를 사용할 수 있을까? Mongock 페이지에서 소개하는 간단한 특징 몇 개만 짚어보자면 아래와 같다. 자바 기반 마이그레이션 도구 견고한 락 메커니즘을 이용하기 때문에 분산 환경에서 안정적으로 실행 가능하다. 코드로 마이그레이션 스크립트를 작성할 수 있다. MongoDB 마이그레이션이 가능하며 (자칭) 가장 안정적인 프로덕트 오픈 소스 정기적인 유지보수 Spring과 호환이 좋다. 노란줄만 보더라도 적합해 보이는 툴입니다. MongoDB 마이그레이션으로 가장 많은 스타를 받고 있는 mongobee의 경우 업데이트가 이제는 거의 없는 반면 Mongock은..
Circuit Breaker는 무엇이며 어떠한 상황에서 사용될까? circuit breaker는 이름에서 알 수 있듯이 회로를 차단하는 기능입니다. 주로 외부 콜에 의존하는 부분에 사용합니다. 예를 들어 A와 B 서버가 존재한다고 가정해보겠습니다. A서버에서는 B서버의 API에 의존하고 있는 형태일 때 만약 B서버에 과부하가 걸려 응답을 제시간에 못주게 되는 경우 A서버에서의 API 호출은 응답을 기다리다가 모두 실패하게 될 것입니다. 이렇게 B서버의 장애는 A서버 외에도 B서버를 사용하고 있는 모든 서버에 장애가 전파되게 됩니다. 이때 이런 생각을 해보게 됩니다. "어차피 지금 B서버의 요청은 모두 timeout이 나게 될텐데 A서버가 이 요청을 위해 리소스를 계속 낭비하고 있어야 할까?" 예를 들어 ..
담당하던 프로젝트 일정이 조금씩 딜레이 되면서 오랜만에 다시 블로그로 돌아온 것 같습니다. 이번 프로젝트 때 많은 기술적인 이슈들을 마주하였는데 지금부터 조금씩 정리하면서 올리려고 합니다. 그중에서도 오늘은 Intellij IDEA 디버깅과 관련된 간단한 팁을 먼저 공유드리려고 합니다. 멀티스레드 환경에서 디버깅하기 개발을 하다보면 동시성 관련 이슈들을 마주하게 됩니다. 동시성 문제라는 걸 자각하지만 로컬에서 재현한다는 것은 꽤나 귀찮은 부분들이 많습니다. 하지만 Intellij IDEA를 사용하시는 분들이라면 이 동시성 재현을 편하게 할 수 있습니다. 사용법은 간단합니다. 아래 사진과 같이 디버깅을 시작하기 원하는 라인에 브레이크 포인트를 걸어놓습니다. 이 상태에서 빨간색 원위에서 우클릭을 해줍니다. ..
개요 작업을 하다가 우연히 발견하게 된 것이 있습니다. MongoDB에 일괄로 저장하는 코드를 작성하고 @Transactional을 붙이면 이 작업이 트랜잭션 단위로 동작하기를 기대했는데 실제로는 전혀 동작이 되고 있지 않았기 때문입니다. 문서들을 찾아본 결과 MongoDB는 4.0 버전 이후부터 Transaction을 지원하기 시작했고, 사용하고 있는 Spring Data MongoDB는 2.1 버전 이후부터 MongoDB의 Transaction을 사용할 수 있다고 합니다. 제가 작업하는 환경은 모두 MongoDB의 Transaction을 사용할 수 있는 버전이었음에도 불구하고 동작이 되지 않았습니다. 그래서 이번 포스팅에서는 스프링 프레임워크에서 MongoDB의 Transaction을 사용하기 위한 ..
Transaction 먼저 트랜잭션이란 연속되는 연산들을 묶은 단위입니다. 이 단위에 정의된 연속된 연산들이 모두 성공해야 트랜잭션이 성공하며, 이 연산들 중 일부가 실패하면 정의된 연산들은 모두 실행되지 않았던 시점으로 다시 돌아가야 합니다. 예를 들어 A가 B에게 M원을 송금하는 것을 트랜젝션으로 정의한다면 아래와 같은 연산들이 포함될 것입니다. A가 B에게 M원을 송금한다 B의 계좌 상태가 유효한지 체크 A의 계좌에서 M원을 차감할 수 있는지 체크 A의 계좌에서 M원을 차감 B의 계좌에 M원을 더한다. 연산이 제대로 이루어졌는지 체크 트랜잭션 완료. 이러한 연산을 실행하는 중 4번 연산(=B의 계좌에 M원을 더하는 연산)에서 이 알 수 없는 오류에 실패하였을 때 A의 계좌에서 M원을 차감했던 것을 ..
MongoDB 준비 MongoDB replication 세팅을 위해서는 2개 이상의 몽고 인스턴스가 필요합니다. 문서를 보면 일반적으로는 3개의 인스턴스로 구성하는 게 가장 일반적인 설정인 것 같습니다. 테스트 편의를 위해 도커를 사용하도록 하겠습니다. 도커가 없다면 로컬에 몽고DB 인스턴스를 3개 준비해주셔도 무방 할 겁니다. version: "3.6" services: mongo-1: image: mongo:4.4 container_name: mongo-1 ports: - "30000:30000" command: mongod --replSet replset --port 30000 mongo-2: image: mongo:4.4 container_name: mongo-2 ports: - "30001:30..