일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 우테코
- 스프링 부트
- 스프링부트
- Docker
- 미션
- 프로그래머스
- 우아한테크코스
- yml
- CircuitBreaker
- MSA
- 세션
- Level2
- AOP
- JUnit5
- 레벨2
- REDIS
- 프리코스
- Paging
- 의존성
- 백준
- 코드리뷰
- JPA
- 서블릿
- AWS
- HTTP
- mock
- 자바
- 트랜잭션
- 우아한세미나
- Spring Batch
- Today
- Total
목록전체 글 (161)
늘
실무에서 정산 쿼리가 있었는데 쿼리 길이만 152줄(with절을 통해 cte 테이블을 만들고 이를 중첩 join 사용)이 되었다. 실제로 매우 느렸던 문제를 이론으로 접하고 있던 hashJoin을 적용함으로써 성능 개선했던 경험을 작성하고자 한다.상황3.5만개의 데이터를 O(n**2)으로 처리-> 12억번 조회해야한다. 실행계획을 확인하면 NestedLoop Join이 여러번 사용되었다.대량의 데이터는 NestedLoop Join(O(N*M)보다 Hash Join(O(N+M) 혹은 Sort Merge JoinO(N log N + M log M)을 사용하면 개선 여지가 있다. Hash JoinBuild Phase:조인 대상 테이블 중 작은 테이블(보통 메모리에 올릴 수 있는 쪽)을 기준으로 해시 테이블을 ..

현업에서 파이썬 서비스를 jvm환경으로 이관하면서 파이썬에서 적용되던 코드를 이관하고 있었습니다. 이때 파이썬의 int는 무한한 길이의 숫자를 사용할 수 있어서 자바의 기본적인 long, double로는 처리가 안되는 문제를 발견했습니다. 이러한 이유에 대해서 분석한 내용을 기록합니다. 자바에서는 아래의 사진처럼 긴 정수는 컴파일이 되지 않는 현상이 있습니다. 하지만 파이썬에서는 어떻게 가능할까요?파이썬이 무한한 길이의 정수가 가능한 이유Arbitrary Precision(임의의 정확도) 파이썬의 int는 C 언어의 long 타입을 기반으로 구현되어있습니다. 각 자리수를 배열에 담아서 처리하며 배열에 각 자릿수를 담을때는 2^30 진법으로 변환함으로써 수행합니다. ob_digit이라는 배열에 해당 값을 ..
ThreadPoolExecutor트래픽이 증가했을땐 처리량을 높이기 위해 스레드를 늘리고, 감소했을땐 줄이려면 어떻게 해야할까? 병렬처리를 위해선 어떻게 스레드를 설정해야할까? ThreadPoolExecutor 메서드ThreadPoolExecutor executor = new ThreadPoolExecutor( 2, // corePoolSize: 기본 스레드 수. 항상 최소 2개의 스레드는 유지됩니다. 4, // maximumPoolSize: 최대 스레드 수. 필요할 경우 스레드는 최대 4개까지 증가할 수 있습니다. 30, // keepAliveTime: corePoolSize를 초과하는 스레드가 대기할 수 있는 최대 시간(30초). TimeUnit.SECONDS, // keepA..

초기 속도초기에 docker build할때 걸리는 시간이다. 매번 배포할때마다 배포 시간이 느려서 일의 효율성에 치명적이었다. 배포 시간을 잡아먹는 가장 큰 원인은 도커 빌드할때 걸리는 시간이었고 해당 문제를 해결해야겠다고 생각했다. 개선후 속도Docker Layer도커 레이어는 파일 시스템에 변화를 주는 커맨드마다 새로운 이미지 레이어를 만듭니다.FROM베이스 이미지 설정레이어 생성 OCOPY파일/디렉터리를 컨테이너로 복사레이어 생성 ORUN명령 실행 및 결과 저장레이어 생성 ODocker Build Cache빌드 캐시가 작동하는 방식레이어가 변경되면 그 뒤에 오는 다른 모든 레이어도 영향을 받습니다. 명령이 있는 레이어가 COPY무효화되면 그 뒤에 오는 모든 레이어도 다시 실행해야 합니다.저희 서비스..

인스턴스 변수 (Instance Variable)각 객체가 독립적으로 가지는 변수, 객체의 상태 표현각 객체간 독립적이다.클래스 변수 (Class Variable)static을 사용한 정적 변수, 클래스의 상태 저장모든 객체가 클래스 변수를 공유한다.지역 변수 (Local Variable)메서드나 블록 안에서 선언되는 변수해당 블록 안에서만 사용 가능기본값이 없어서 반드시 초기화하고 사용해야 함인스턴스 변수와 클래스 변수의 초기화그렇다면 초기화하지않고 선언만 해주었을때 아래의 코드의 결과는 무엇이 나올까요? public class VariableTest { static int a; // 클래스 변수 int a; // 인스턴스 변수 public static void main(String[]..

https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.htmlredis를 사용한 분산락을 구현할때 RedLock의 한계는 이미 잘 알려진 문제입니다. 간략히 짚고 넘어가자면 Java기반 서버에서 stw가 발생할때 또는 클락 드리프트 이슈가 발생할때 락 일관성이 깨질 수 있다는 것입니다.이를 확실하게 해결하기 위해서는 주피터를 사용하라고 되어있습니다. 그렇다면 redis를 사용한 분산락은 어떻게 구현할 수 있을까요?redlock알고리즘을 사용하는 이유가 클러스터 구조에서 일관성있는 락을 유지하기 위해 존재하는데, redlock을 사용하지 않는다면 어떤 식으로 redis의 java 클라이언트인 redisson이 락을 처리하는지 확인해보겠..

게이트웨이를 운영하던중 첫 적립 api를 호출했을때 아래의 예외가 터졌다.java.util.concurrent.TimeoutException: Did not observe any item or terminal signal within 1000ms in 'contextWriteRestoringThreadLocals' (and no fallback has been configured)게이트웨이 구성은 spring cloud gateway로 구성되어있고 아래 zipkin에서 보면 response-time이 1s가 넘어가자 exception을 던지는 것으로 확인했다. 다만 gateway에서 response-timeout설정을 1s보다 길게 잡아두었는데 1000ms에서 예외가 터지는게 의아했다.원인 찾기1. 일..
limit이 걸린 쿼리는 limit이 안걸린 쿼리보다 항상 빠르다? ----- (X)모든 조회쿼리에서 limit이 걸리면 특정 개수만 조회하기에 항상 빨라질거라 생각했지만 limit을 해제하니 오히려 쿼리 속도가 더 빨라졌습니다. 어떻게 이런 일이 발생했는지 확인해보겠습니다.해결 과정에서 헛다리도 짚었는데 그 과정 또한 기록했습니다. 결론만 보고싶으신 분은 아래로 가주시면 됩니다. 가정우선 예시 테이블 구조를 설명해드리겠습니다. history테이블은 5억이상의 데이터가 적재되어있고 복합 인덱스가 걸려있습니다.CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, active_id INT NULL, event_type VARCHAR(255) ..

서킷브레이커는 회로 차단기로도 불리며 주요 목적은 시스템의 일부분에 문제가 발생했을 때, 그 문제가 전체 시스템으로 확산되는 것을 방지하는 것입니다. 가령 게이트웨이에서 라우팅하는 대상의 서버가 응답이 없거나 특정 에러를 계속 발생시킨다면 게이트웨이의 자원도 고갈됩니다. 모든 서비스에 장애가 전파되는 것이지요. 이러한 문제를 막기 위해 회로차단기(circuitBreaker)를 둠으로써 장애의 전파를 막을 수 있습니다. 서킷 브레이커는 개발자가 설정하는 값에 따라 어느 상황에서 서킷을 열지를 결정할 수 있습니다. (설정 관련 문서 를 참고해서 작성할 수 있습니다.)이러한 서킷이 열렸는지 닫혔는지 여부도 개발자가 알수 있어야한다고 생각됩니다. 따라서 서킷의 이벤트가 발생할때 슬랙으로 알림을 전송받도록 구현해..

정확히는 MySQL에서 PagingQueryProvider와 JdbcPagingItemReader을 함께 사용할때 페이징은 offset을 사용하지 않는다 입니다.문제 상황으로는 JdbcPagingItemReader를 통해 조회를 할때, SELECT 절에 별칭을 주었는데 정상적으로 읽지 못하는 문제가 발생했습니다. 해당 이슈를 해결하면서 알게된 사실을 공유하려고 합니다.JdbcPagingItemReader@Bean@StepScopepublic JdbcPagingItemReader reader() { return new JdbcPagingItemReaderBuilder() .name("reader") .pageSize(chunkSize) .fe..