성장을 꾸준히 기록하는 공간

블로그는 오랜만이다. 그동안 노느라 멈춘건 결단코 아니다. 5월에는 AWS SAA 땄다. 정보처리기사 합격 결과도 6월에 나왔다. 프로젝트를 여러 개 동시에 진행하면서 너무 정신이 없었다. 프로젝트 진행하면서 생긴 문제 해결이나 고민한 내용부터 공부한 내용까지 블로그에 글쓸거는 넘쳐서 쌓이고 있는데... 정작 퇴고할 시간이 없었다. 공모전이나 대회 참여도 꾸준히 하고 있고, CTF 문제풀이 서비스도 3월부터 진행해서 5월에 출시 배포했다. 게임은 아직 준비중인데 자꾸 재밌는 기능들이 떠올라서 여전히 컨텐츠 추가중이다. 부트캠프? 인턴? 그런거 안합니다.네 못했어요 24년 2월 소프트웨어 마에스트로 2차 코딩테스트 탈락24년 5월 BoB 최종면접 탈락24년 12월 우아한테크코스 프리코스 탈락25년 1..

부제 - 은탄환은 없다 알다시피, SQL문에서 LIKE 쿼리의 성능은 처참하다.%keyword% 형태의 문자열의 경우는 인덱스를 활용할 수 도 없어서 Full Table Scan을 해야한다. 당연히 결과값 데이터가 많을수록 성능이 더 떨어진다.아직 결과 수가 많지 않아서 LIKE 연산으로 괜찮지만 충분히 개선의 여지가 남아있다. 복잡한 텍스트 검색시 사용되는 ElasticSearch는 현재 서비스 성격상 맞지 않으며, 우리는 운영비 제로를 목표로 t2.micro를 쥐어짜내고 있는 상황이다. MySQL에서 Full-text Search라는 기능을 제공한다.Full-text Index를 사용해서 텍스트 기반 검색에 대해 더 빠르게 검색할 수 있다. Full-text Search 개요데이터베이스나 검색 시스템..

CTF 문제풀이를 위한 'Hack Playgrond' 서비스의 핵심 기술을 설계하던 중, 사용자가 문제 컨테이너에 접속해서 Flag를 찾을 수 있도록 동적으로 Kubernetes 상에서 Pod 리소스를 관리하고 있었다. 리소스 최적화를 통해 운영비용을 획기적으로 절감하는게 1차적인 목표였기에 이를 위해서 사용자가 이용을 끝낸 컨테이너를 삭제하는 Pod Garbage Collection을 직접 구현하고 있었다. 어떻게 사용자가 이용을 끝냈는지 판단할 수 있는지 고민하던 중, 마침 2024년 쿠버에 네이티브 수준의 사이드카 컨테이너를 프로젝트에 추가했다는 사실을 알게 되어서 프로젝트에 적용 가능한지 확인차 공부해본 내용을 소개하고자 한다. 참고로 결국 기술 구현 자체는 Java 라이브러리에서 아직 Nativ..

OOM 아닌 경우에 직접 힙 덤프 뜨는건 처음인거 같다. 겉핥기식을 넘어서 그래도 덤프 분석을 좀 진득하게 해볼 수 있었다. Heap 메모리는 JVM 내에서 임의로 생성된 객체들이 동적으로 할당되는 공간을 말한다.Heap의 덤프 파일은 운영중인 애플리케이션의 Heap 영역을 snapshot으로 기록한 파일을 일컫는다. GC Logs만 놓고 분석할때는 Eden 영역이 작은지 계속 꽉 차는 일이 잦았다.짧은 수명주기를 가지는 객체가 대부분이어서 GC시 비효율적인 메모리 사용이 생기는 것으로 보인다. ZGC같은 경우는 과도한 CPU 사용이나 TPS 저하문제를 바로잡기 위한 튜닝이 중요하다.Heap 영역을 넉넉하게 잡을수록 GC 주기가 길어진다. 반대로, 작으면 자주 GC를 돌려야해서 TPS가 저하하게 된다. ..

ReactiveKafkaSpring 환경에서 Kafka 사용이 편해졌다. 마치 WebMVC에서 Request 패턴처럼 사용하고, Partition을 나눠서 병렬 처리로 동시성 문제를 해결할 수 있다. Streaming 플랫폼의 본질Producer → stream 형태로 publish, subscribe → Consumer Reactive의 본질은 대상을 Async하게 다루는거고, 이를 Stream 형태(Flux)로 비동기 처리한다. ReactiveKafka 사용시 생기는 메시지 소비의 지연 현상을 알아보자ReactiveKafkaConsumerTemplate 자체가 Lazy하게 동작한다.Kafka 클라이언트 설계상, receive()가 호출되기 전까지 내부적으로 KafkaReceiver가 구동하지 않는다...