| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 |
- 오라클 디비
- resilience4j
- SQL
- 자바
- spring
- 문법 정리
- hyperledger
- gradle
- 초대장
- 알고리즘
- jsp
- 파이썬
- dynamic query
- 파이썬 소스
- MongoDB
- K6
- 운영체제
- 백준 알고리즘
- 학점
- 프로젝트
- auto configure
- 티스토리
- 오라클
- 자바 프로젝트
- smart cast
- JVM
- 유사코드
- 리눅스
- c#
- oracle
- Today
- Total
목록목차 (238)
모종닷컴
지난 글에서 Docker 이미지를 변경한 뒤 외부 서비스와의 TLS Handshake가 실패했고, JDK 17.0.18부터 java.security의 jdk.tls.disabledAlgorithms에 TLS_RSA_*가 추가된 것이 직접적인 원인이라고 판단했습니다.운영 장애를 빠르게 복구해야 했기 때문에 -Djava.security.properties를 이용해 TLS 정책을 재정의했고, 실제로 문제도 해결되었습니다.하지만 장애가 해결된 이후에도 한 가지 의문이 계속 머릿속을 떠나지 않았습니다.정말 TLS_RSA_* 하나만이 원인이었을까?해당 외부 서비스는 정말 TLS_RSA_*밖에 사용할 수 없는 서버였을까?첫 번째 단서: Cipher Suite 재확인가장 먼저 해당 서버가 실제로 어떤 Cipher Su..
Docker 이미지를 변경했더니 TLS Handshake가 실패했다운영 환경에서 Docker Base Image를 변경한 뒤 예상하지 못한 장애를 경험했습니다.애플리케이션 코드도 변경하지 않았고, 외부 서비스도 변경되지 않았습니다.정말 Docker 이미지만 변경했을 뿐인데 특정 외부 서비스와의 HTTPS 통신이 모두 실패하기 시작했습니다.처음에는 단순히 JDK 업데이트로 인해 TLS 정책이 변경된 것이라고 생각했고 가볍게 대처하였습니다.하지만 문제를 추적하는 과정을 통해 정확한 원인을 짚고, 올바른 대처를 할 수 있었습니다.이번 글에서는 장애를 어떻게 분석했고 어떤 가설을 세우며 원인을 좁혀갔는지를 정리해보려고 합니다.장애 발생운영 환경에서는 Spring Boot의 WebClient를 사용하여 외부 기관..
macOS에서는 기본적으로 F1~F12 키가 ‘특수 기능 키(밝기, 소리, 재생 등)’로 동작하고, 실제 F1~F12 기능을 쓰려면 Fn 키(또는 Globe 키=지구모양 키)를 함께 눌러야 합니다.MacOS를 사용하다보면 "특수 기능"보다는 "기본 기능"을 많이 사용하므로, 저의 경우 F?? 키를 눌렀을 때 기본 기능키로 바꾸는게 적합한 것 같았습니다.1. 키보드 단축키 설정 들어가기"시스템 설정" -> 좌측 "키보드" 메뉴 -> "키보드 단축키"2. F? 키를 표준 기능키로 사용 활성화좌측 "기능 키" -> 기능 활성화이 기능을 활성화 한 이후에 특수 기능(예: F11(소리 줄이기))을 사용하려면 설명에 나와있듯이 "Fn" 키를 누르면 됩니다.
도커 컨테이너로 자바 애플리케이션을 실행한 후 모니터링을 하다보니 제가 알고 있던 가비지 컬렉션 동작과는 다르다는 것을 발견했습니다. 당시 Oracle Linux Server 리눅스 서버와 openjdk 21를 사용했습니다. 추가로 컨테이너 메모리를 1GB로 제한하였습니다. 이렇게 구성하였을 때 아래와 같이 GC 로그와 자바 버전을 출력해보았습니다.bash-4.4# java -Xlog:gc --version[0.002s][info][gc] Using Serialopenjdk 21 2023-09-19OpenJDK Runtime Environment (build 21+35-2513)OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)여기서 첫 번..
Docker Container에 리소스 제한 설정을 CPU(1.0), Memory(1GB)로 설정한 후 JVM 메트릭을 확인하는데 Non-heap 영역이 1GB가 넘게 할당되있는 것을 봤습니다.메모리는 일단 아래와 같이 할당되었습니다.JVM Heap : 248MiBJVM Non-Heap : 1.23GiB혹시 컨테이너 메모리 제한을 잘못설정한건지 리눅스 cgroup을 봤지만 리소스 제한은 잘 된것으로 보였습니다.컨테이너 메모리는 1GB로 설정했는데 어떻게 된 일 일까요??Compressed Class 영역JVM Non-Heap을 들여다 보니 metaspace가 -1B, Compressed Class: 1GiB가 할당되었고, 나머지 240MiB는 기타 다른 영역에 할당됬습니다.결국 이 Compressed C..
NATS 보다가 "10,000 foot view"가 나와서 뭔가 싶었는데 비행기가 10,000피트 상공에서 아래를 내려다보는 것처럼, 아주 높은 관점에서 전체적인 그림만 보는 개요(overview)를 뜻한다고 합니다. 세부적인 기술적 내용이나 구현 방법이 아닌, 어떤 문제를 해결하려고 하는지 혹은 큰 구조가 어떻게 되는지 등 "큰 그림"을 설명할 때 쓰는 말입니다! 이런 비슷한 표현들이 있나 좀 더 찾아봤습니다. 직역의미30,000 foot view / 50,000 foot view3만/5만 피트 상공에서 본 관점10,000피트보다 더 높은 곳에서 바라본다는 뜻으로, 매우 거시적인 시각으로 전체를 바라본다는 뜻입니다.Big picture큰 그림가장 흔한 표현으로 세부보단 전체 흐름을 보자는 뜻입니다.Hi..
@Componentclass Test(...) { init { eventPublihser.publishEvent(TestEvent()) }}@Serviceclass TestService { @EventListener(TestEvent::class) fun handleEvent(event: TestEvent) { log.info { "hello" } }}이슈위와 같은 코드를 작성했을 때 애플리케이션이 켜지면 “hello”가 출력되기를 기대했으나 출력이 안됨. 반면 API를 하나 만들어서 동일한 코드를 실행하면 Listener에서 감지가 된다. 원인/** Class SimpleApplicationEventMulticaster **/ @Override pub..
브로커와 컨트롤러 카프카 버전 2.8 이후부터 메타데이터 관리를 주키퍼를 사용하지 않고 자체 관리하게 되었는데 이로 인해 카프카 애플리케이션의 역할은 크게 두 가지(브로커, 컨트롤러)로 구분할 수 있다. '컨트롤러'는 클러스터 수준의 메타데이터 관리 및, 리더 선출, 브로커 추가 제거 같은 클러스터 관리 작업을 하는 역할을 하며, '브로커'는 메시지의 저장 및 전송과 관련된 작업을 담당한다. 애플리케이션을 역할을 지정할 수 있는데, 브로커나 컨트롤러 중 하나의 역할만 지정할수도 있고, 브로커 겸 컨트롤러 역할도 지정할 수 있다. Quorum based Controller KRaft 합의 알고리즘을 통해 리더로 선출된 컨트롤러는 Active Controller라고 불리며, 그 외에 컨트롤러는 Followe..
zookeeper를 이용한 카프카 메타데이터 관리 카프카 2.8 버전 이전에는 아래와 같은 메타데이터들을 관리하기 위해 zookeeper를 사용했었음. 클러스터 토폴로지 정보, 토픽 메타데이터, 컨트롤러 정보, 컨슈머 그룹 정보, ACLs 정보, 브로커 정보 등.. Zookeeper를 통해 메타데이터를 관리했을 떄 발생하는 문제들 Zookeeper 자체에 이슈가 있다기보다는 주키퍼를 활용하여 메타데이터를 관리하는 카프카의 방식에 여러 가지 문제가 있었음. 주키퍼라서 생기는 문제들. 주키퍼는 카프카와 별개의 분산 시스템 관리자는 카프카를 배포하기 위해 두 개의 개별 분산 시스템을 관리하고 배포하는 방법을 배워야 한다. SASL과 같은 설정이 카프카, 주키퍼 두 시스템에 모두 적용되어야 한다. 로컬에서 간단..
카프카 메트릭카프카 코드를 보다 보면 메트릭을 수집해서 특정 클래스에서 계속 계산하는 모습을 볼 수 있습니다. 해당 클래스들은 MBean을 상속받아 작성되어 있어서 내부 메트릭을 JMX를 통해 얻을 수 있습니다. 브로커 뿐만 아니라 KRaft 같은 메타데이터, Producer, Consumer 등의 메트릭도 모두 JMX를 이용할 수 있습니다. 다만 메트릭에 접근하기 위해서는 몇 가지 설정이 필요합니다.Java Management Extensions (JMX)는 Java 애플리케이션을 모니터링하고 관리하기 위한 기술. JMX는 MBean (Managed Bean)이라는 관리 가능한 자바 오브젝트를 사용하는데 애플리케이션은 이 MBean을 통해 다양한 정보와 작동 상태를 노출하며, 관리자 또는 모니터링 도구..