일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- Spring Batch
- HTTP
- 스프링부트
- AOP
- 우테코
- MSA
- CircuitBreaker
- REDIS
- 프리코스
- yml
- 백준
- 레벨2
- 코드리뷰
- 서블릿
- 스프링 부트
- 우아한테크코스
- 자바
- AWS
- 의존성
- Level2
- 우아한세미나
- JPA
- 프로그래머스
- 트랜잭션
- 세션
- mock
- 미션
- JUnit5
- Docker
- Paging
- Today
- Total
목록전체 글 (155)
늘
클래스 변수와 인스턴스 변수의 일반적인 차이클래스 변수와 인스턴스 변수의 차이점이라면 많은 블로그들에서 설명해주고 있습니다.대표적으로 아래와 같죠.클래스 변수와 인스턴스 변수의 초기화 차이그렇다면 초기화하지않고 선언만 해주었을때 아래의 코드의 결과는 무엇이 나올까요? public class VariableTest { static int a; public static void main(String[] args) { System.out.println(a); }}결과는 0이 나옵니다. 만약 String 객체로 바꾼다면 null이 나오게 됩니다.그렇다면 인스턴스 변수로 바꾸면 어떻게 나올까요?네 초기화가 되어있지 않아서 컴파일에서 에러가 나옵니다.그렇다면 클래스 변수는 초기화를 하지..
게이트웨이를 운영하던중 첫 적립 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..
spring batch 5는 이전 버전과 많이 변경되었다. 기본적인 스프링배치부터 스프링 배치 5.0은 어떻게 달라졌는지 직접 실무에 적용해보면서 느꼈던 경험을 적어본다. Architecture 공식문서에 나온 아키텍처이다. Application, Core, and Infrastructure 로 구성되어있다. Application: 애플리케이션에는 Spring Batch를 사용하여 개발자가 작성한 모든 배치 작업과 사용자 정의 코드가 포함되어 있다. Batch Core: 배치 작업을 시작하고 제어하는 데 필요한 핵심 런타임 클래스가 포함되어 있습니다. JobLauncher, Job, and Step이 포함되어있다. Batch Infrastructure: 애플리케이션과 코어는 모두 공통 인프라 위에 구축..
스터디를 하면서 실무에 적용하기 좋은 챕터라고 생각되어 따로 정리해둡니다. 유연하고 재사용 가능한 퍼블릭 인터페이스를 만들기 위한 원칙과 기법을 살펴보는 것이 주제이다. 우선 협력과 메시지에 대해 알아보자. 협력 관계를 설명하는 전통적인 메타포는 클라이언트-서버 모델이다. 협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다. 그리고 객체는 클라이언트와 서버의 역할을 동시에 수행한다. 협력의 관점에서 객체는 두 가지 종류의 메시지 집합으로 구성된다. 하나는 객체가 수신하는 메시지의 집합이고 다른 하나는 외부의 객체에게 전송하는 메시지의 집합이다. 협력에 적합한 객체를 설계하기 위해서는 외부에 전 송하는 메시지의 집합도 함께 고려하는 것이 바람직하다. 용어정리 메시지는 객체들이 협력하기 위해 사..
RPC 원격 프로시저 호출(Remote Procedure Call)은 네트워크의 세부 사항을 이해하지 않고도 한 프로그램이 네트워크의 다른 컴퓨터에 있는 프로그램에 서비스를 요청하는 데 사용할 수 있는 소프트웨어 통신 프로토콜이다. RPC는 클라이언트 - 서버 모델이다. 요청하는 프로그램은 클라이언트이고, 서비스를 제공하는 프로그램은 서버이다. 로컬 프로시저 호출과 마찬가지로 RPC는 원격 프로시저의 결과가 반환될 때까지 요청 프로그램을 일시 중지해야 하는 동기 작업이다. 그러나 동일한 주소 공간을 공유하는 경량 프로세스 또는 스레드를 사용하면 여러 RPC를 동시에 수행할 수 있다.(+ grpc를 사용하면 비동기식으로 사용할 수 있다.) API를 설명하는 데 사용되는 사양 언어인 IDL(인터페이스 정의 ..
본 게시글은 지속적으로 학습하면서 업데이트할 예정입니다. 동작원리 컨테이너 빌드(nginx, payment, batch …) 사용자가 docker push hub.example.com/nginx 와 같이 docker hub에 저장해둔다.(사내, docker.com 등) 이후, 쿠버네티스 명령어를 통해 저장해둔 컨테이너가 실행하도록 한다.(yaml or kubectl 명령어로 실행 가능) 명령어를 실행하면, 마스터 노드(Control-plane)에 요청이 간다. 마스터 노드는 API서버가 있어서 쿠버네티스관련 요청을 받는다. 스케줄러에게 어떤 워커 노드에 nginx를 실행하면 좋을지 물어보면, 스케줄러가 워커 노드의 상태를 보고 적절한 노드를 응답해준다.(REST API서버에게) API서버는 할당받은 워커..
일반적으로 분산 시스템에서 메시지를 주고받는 방법으로는 크게 2가지가 있다. API를 통한 통신 즉각적인 요청과 응답을 주고받는다. 간단한 개발 메시지 큐를 통한 통신 비동기, 배치 처리와 함께 적용하기 좋다. 일반적으로 publisher가 데이터를 큐에 넣으면 consumer가 큐에서 데이터를 꺼내서 데이터를 가공한다. 복잡한 개발 분산 시스템에서는 모든 데이터가 네트워크를 타면서 이동하므로 지연, 유실 등의 문제가 발생할 수 있다. 따라서 아래의 3가지 방식을 통해 데이터 전달을 보장하는 방법이 있다. 1. At most once producer가 최대 한 번만 송신하고 consumer가 최대 한 번만 수신한다. 간단한 구현 & 개발이지만 데이터 유실 가능성이 높다. 대용량 메세지 전송할 때 편하다...