전체 글

6월 27일 생존일지다. 일기를 자주 써야겠다는 다짐같은 것은 한적이 없다. 그렇기에 5. 30 생존일지를 쓰고 또 언제 쓸까 싶었지만 지금 쓰게 되었다. 뭐 부터 말해야할까 지금 나의 상태는 음.. 아무것도 아니다. 조용하게 보내고 있다.  철학적인 어쩌고..철학적인 생각들을 조금 한다. 철학에도 관심이 있었고, 책을 많이 읽었으며, 혼자 걷거나 뛰거나 혼자 멍때리면서 생각을 자주한다. 또 중2병같은 생각같기도해서 조금 부끄럽기도 하면서.. 음.. 그냥 내가 왜 태어났는지, 내가 궁극적으로 이루고싶은 목표 등등.. 음 생각보다 나의 가치관에서 많은 변화가 일어난 것 같다. 꽤나 의미있는 생존일지가 될 것 같기도하고. 일단 내 궁극적인 목표는 항상 결과를 중시했었다. 인정을 바래왔고 보상을 바래왔다. 현..

2024년 5월 30일 고통스러웠던 2023년을 떠나보내고 2024년의 새출발을 기원하며 다짐하고 또 다짐했던 나의 예전 모습이 떠오른다. 벌써 6월이 다 되가고 2024년도의 50퍼센트가 지나간다. 그 동안 나는 어떤 것을 이루었고 어떤 것을 했냐고? 정말 뭔가 많이 했다. 정말 많이했다. 하나하나 회고해봐야겠다. 취업 활동취업 활동을 좀 열심히 했다. 채용시장이 막히고 어떻고 신입 채용이 어떻고라는 말은 항상 들었다. 그러나 나는 딱히 신경쓰지 않았다. 나름 자신이 있었기 때문이다. 근데 이렇게까지 빨리 이룰 것이라고는 생각하지 못했다. 1월 15일 그니까 2024년도가 되고 15일 뒤 나는 취업에 성공했다. 물론 2023년 11월부터 구직 활동을 했지만.. 내 인생 두 번째 면접을 봤고 합격을 했다..

내부 단편화란 할당한 용량보다 메모리를 적게 사용하여 메모리가 남게 되는 것을 말한다. 리눅스에서 메모리 페이징으로 메모리를 관리하기 때문에 어느정도는 발생할 수 밖에 없다. redis는 in memory data store로, 캐시로도 많이 쓰이기 때문에 메모리 관리가 중요하다. 여러 지표중에서 Fragmentation Ratio에 대해서 알아보자   redis-cli에서 INFO 명령어로  Fragmentation Ratio를 확인할 수 있다.redis> INFO "# Server redis_version:7.0.5redis_git_sha1:00000000 redis_git_dirty:0redis_build_id:383256aa4e712b9dredis_mode:standalone os:Linux 5...

Redis는 데이터를 영구적으로 저장하는 AOF/RDB 방식의 DB 백업 용도로 사용되고 있으며, 주로 인메모리 캐시다보니 캐시 저장 용도로 많이 사용되고 있다. 레디스는 시스템 성능을 높이는데 많은 역할을 하는 좋은 솔루션이다. 그렇지만, 레디스는 메모리 측면에서 제대로 관리하지 않게 된다면 이는 곧 장애로 이어지기도 한다. Swap레디스는 메모리에 데이터를 저장한다. 그렇기에 물리 메모리(RAM) 용량보다 더 많은 데이터를 사용하게 된다면 메모리 부족으로 swap 발생하여 Redis의 성능 저하를 일으킬 수 있다. 위의 그림처럼 데이터를 물리 메모리의 용량보다 더 많이 사용하게 된다면 swap이 발생한다. 운영체제에서 swap space의 주요 기능은 물리메모리의 양이 가득차고 더 많은 메모리의 양이..

자바로 프로젝트를 진행할 때, 보통 에러 처리의 일관성과 가독성, 로깅, 디버깅, 예외 처리 유연성을 위해서 CustomException 클래스를 정의하여 자주 사용한다. 그러나 여러 이점들이 있음에도, 자바에서는 Exception의 처리 비용이 매우 비싸다는 문제가 있다. 이번 글에서는 JVM이 Exception을 처리하는 순서와 생성 비용이 비싼 이유, 마지막으로 비용 절감 방법에 대해서 알아보도록 하겠다. JVM Exception 처리 순서이 글을 참고해보면, Exception이 발생하면 다음과 같이 JVM에서 Exception을 수행한다. 예외 발생: 예외가 발생하면 JVM은 예외 객체를 생성하고, 예외를 발생시킨 메서드의 호출 스택을 추적한다.예외 객체 전파: JVM은 해당 예외를 발생시킨 메서..

데이터베이스에 저장된 레코드중 거대한 문서 내용들에 대한 키워드를 인덱싱하기 위해서는 전문 검색 인덱스를 사용한다. 예를 들어서 TEXT와 같은 형의 데이터를 검색하기 위해서는 InnoDB나 MyISAM에서 제공하는 B-Tree 인덱스를 사용할 수 없다. 이러한 데이터를 검색하는 것을 Full Text Search 인덱스라고 하는데, 전문 검색 인덱스는 일반화된 기능의 명칭이지 전문 검색 알고리즘의 이름을 지칭하는 것은 아니다. 전문 검색 인덱스에는 문서의 키워드를 인덱싱하는 기법에 따라 구분자(Stopword)와 n-gram을 나누어 생각해볼 수 있다. 이외의 알고리즘은 그다지 알려지지도 않고 특히나 MySQL에서는 사용할 수 있는 것이 없다. 인덱스 알고리즘 키워드의 분석 및 인덱스 구축에는 여러가..

Kafka의 리밸런싱 븡식은 적극적 리밸런싱과 협력적 리밸런싱이 나뉘며 각각 4가지의 파티션 할당 종류가 존재한다. 범위(Range) 파티션 할당 전략 - 적극적 리밸런싱 라운드 로빈(RoundRobin) 파티션 할당 전략 - 적극적 리밸런싱 스티키(Sticky) 파티션 할당 전략 - 적극적 리밸런싱 협력적 스티키(CooperativeSticky) 파티션 할당 전략 - 협력적 리밸런싱 하나씩 알아보도록 하자 범위(Range) 파티션 할당 전략 범위 파티션 할당 전략은 카프카 v2.4 버전 이전에 기본으로 설정된 적극적 리밸런싱 방식의 파티션 할당 전략이다. 범위 파티션 할당 전략은 다음과 같은 프로세스를 거친다. 구독중인 파티션과 컨슈머를 순서대로 나열한다. 이후 각 컨슈머가 받아야할 파티션의 수를 결정..

카프카 컨슈머는 토픽의 각 파티션에서 메시지를 처리하는 역할을 한다. 그런데, 특정 컨슈머가 문제를 겪게 되면 그 컨슈머가 처리하던 파티션의 소유관은 다른 컨슈머로 넘어가게 된다. 이런 과정을 리밸런싱이라고 부르며 주로 아래와 같은 상황에서 발생한다. 컨슈머 그룹에 새로운 컨슈머가 추가 될 때 (+) 기존 컨슈머가 그룹에서 나가게 될 때 (-) 구독하는 토픽에 새로운 파티션이 생길 때 컨슈머가 구독하는 토픽이 변경될 때 리밸런싱이 가장 많이 일어나는 일반적인 상황은 애플리케이션 배포 상황이다. 기존 애플리케이션이 종료 후에 애플리케이션이 실행되면서, 기존 컨슈머가 삭제되고 새로운 컨슈머가 생성되기 때문이다. 이 과정에서 리밸런싱은 최소 두번 이상 발생한다. 리밸런싱은 아래와 같은 문제점을 동반한다. do..

JPA는 트랜잭션 기반으로 사용된다. 그래서 JPA를 사용하면 우리는 자주 @Transactional어노테이션을 사용하는 것을 알 수 있다. 그리고 조회의 경우에는 readOnly=true옵션도 함께 주게된다. 오늘은 JPA와 @Transactional에 대해서 몇 가지 궁금한 점에 대해 기록해보겠다. readOnly = true를 설정하는 이유 우리는 조회용 서비스 메서드를 작성할 때 @Transactional(readOnly = true) 이렇게 서비스 위에 어노테이션을 달아주게 된다. 이 어노테이션을 달아주게 된다면 이점이 무엇이 있을까? 가독성? 물론 가독성에 대한 장점도 있겠지만 다른 이유도 존재한다. 변경 감지 JPA의 영속성 컨텍스트가 수행하는 변경 감지(Dirty Checking)와 관련이..