공대키메라

이번 글에서는 Log4j2 공식 문서를 읽어보려고 한다. 사실 해당 글을 위해서 LMAX Disruptor에 대해서 필자가 논문부터 User Guide까지 다 읽고왔다. 그래서 Log4j2 공식문서는 못읽고 LMAX Disruptor만 읽게 되어서... 시간이 많이 걸리게 되었다. 고로, 해당 문서를 읽으면서 Disruptor관련해서 내용이 나오면 다음 키메라가 정리한 글을 쭈욱 읽어보면 도움이 될 것이다. [Java] LMAX Disruptor 공식문서 읽기 1 : 1. Overview ~ 2.6 Pipelines and Graphs [Java] LMAX Disruptor 공식문서 읽기 2 : 3. Design of the LMAX Disruptor ~ 6. Conclusion [Java] LMAX D..

이번 글에서는 지난 글들에 이어서 실제 LMAX Disruptor 코드를 보려고 한다. 사실 지난 글에서 블로그를 읽어보고 코드도 같이 분석하려고 했는데 (지난글 여기 클릭!) 블로그를 읽는게 너무... 길어서 코드 분석은 별도로 빼게 되었다. 그럼 다시 시작해.... 보자고!목표1. LMAX Disruptor의 코드를 이해한다.1. 지난 내용을 통한 구조 리마인드 자! LMAX Disruptor에서 구조를 3개로 나눠서 효율성을 높혔다고 한다. 저장공간, 생산자 그리고 소비자! 하지만 이 그림은 오래도니 버전을 기준으로 그린 것이고, 필자는 가장 최근 버전인 4.0.0 을 들여보려고 한다. 초기 버전과의 비교를 통해서도 이해하면 좋을 듯 하다. 2. 코드 들여다보기 - overview해당 maven ..

지난 글에서는 LMAX Disruptor에 관한 논문 하나를 천천히 읽어보며 부족한 부분을 채웠다.(지난 글 여기 클릭!) 이번 글에서는 실제로 Disruptor 코드를 보고, 이를 어떻게 적용했을 때 정말 빠른지 Apache JMeter 로 보려고 한다. 지난 글에서 참고로 언급을 했지만, 실제 Disruptor 개발자 분 께서 블로그로 이에 대해 설명해주는 글이 있는데, 전반적으로 해당 글의 흐름대로 코드도 다 들여다보려고 한다. (disseecting the disruptor writing to the ring buffer)안타깝게도 해당 글은 좀 오래되어서 현 버전과 안맞을 수 있다. 고로, 글을 다 읽어보고 현재와 다른점을 짚어볼 필요가 있다.그럼에도! 큰 흐름은 변하지 않았으리라 판단한다. ..

이번에는 지난 시간에 이어 다 읽지 못한 LMAX Disruptor Technical Paper를 3장부터 이어서 읽어보려고 한다.(지난 내용 여기 클릭) 초록, 개요와 기존 메모리 구조에서 오는 문제점을 해결해야 한다는게 이전 글에서의 핵심 요약이라면 이번에는 이를 해결하는 내용이 나오지 않을까 생각한다.목표1. LMAX Disruptor가 어느 점에서 효율적인지 이해한다.1. 3) Design of the LMAX Disruptor위에서 설명한 문제들을 해결하기 위해, 큐에서 혼재되어 있던 것으로 보이는 관심사들을 엄격하게 분리하는 방식을 통해 하나의 설계가 도출되었습니다. 이 접근 방식은 쓰기 접근에 대해 모든 데이터가 오직 하나의 스레드에 의해서만 소유되도록 보장함으로써 쓰기 경합을 제거하는 데..

사실 필자는 해당 내용에 대해서는 그다지 관심이 없었다. 최근 가장 큰 관심사는 Netty를 확장해서 프레임워크를 구축하는 것인데, Log4J에 대한 공식문서를 읽고 정리할 까 고민했다. Log4j를 가져다가 사용하는게 괜찮은지 보다가 성능이며 동시성 문제며 이러한 여러가지 performance 분석에 대해서 보니.. 가져다가 쓰는것이 많은 부분에서 장점이라고 느껴졌다. 다만, LMAX에서 Discruptor라는걸 만들었는데, 이것을 활용해서 Apache Log4j 2의 성능을 극적으로 올렸다고 했다. 내가 꼳힌 부분은 Discruptor가 도대체 뭔지 글을 좀 진득~하게 읽어보고 싶었고 요약을 좀 하고 싶었기에 해당 글을 적는다. 물론 AI에게 물어보면서 모르는 부분들을 채우고 그림도 한번 도식화하면서..

지난 글에서는 공부할 프로젝트에 대해 학습하고, 어느 기능을 추가할 것인지 고민했고 이를 위해 데코레이터 패턴과 책임 연쇄 패턴에 대해 알아보았다. (궁금하면 여기 클릭!) 이번 시간에는 요금 기능과 알림 기능을 추가하려고 하는데...! 생각해보니 지난 글에서 알림 기능은 내가 고민했는데 말만 하고 넘어가버리고 말았다. 요금 기능을 직접 구현하기 전에, 알림 기능을 위한 디자인패턴을 알아보고, 실제 코드를 확장할 것이다. 사실 객체지향을 연습하기 위해서는 코드를 직접 작성하고 학습해야 하는데, 일일히 이것을 복붙하고 설명하는것이 애매하다고 생각했다. 그래서 과감히 전부 제거했고, 해당 작업들에 대한 코드와 히스토리는 다음 Git Branch에서 다 확인할 수 있다(코드 보고싶으면 여기 클릭!) 목표1...

지난 시간에는 객체지향 연습을 위한 프로젝트를 구성하기 위한 전단계로 여러 개념을 학습했다.(이전 내용이 궁금하면 여기 클릭!) 이번 글에서는 지난 시간에 이어 학습용 프로젝트 구성을 이어서 진행할 예정이다. 시작하기에 앞서서 나의 생각을 좀 적어보도록 하겠다. 해당 프로젝트는 JPA나 부가적인 기술들은 전혀 고려하지 않았다. 다만 초기 학습을 위해서는 순수하게 Domain 주도로 개발을 진행하는 것이 맞다고 생각을 했다. 현실에서 실제 개발을 한다고 하면, 솔직히 기술 스펙이 바뀌지는 않을것이다. 이미 잘 돌아가고 있는 프로젝트에 한국에서 누가 이걸 새롭게 다 하고 싶은 경우가 있는지 반문을 해보았다. 이미 서비스중인 기술을 큰 리소스를 들이면서 새로운 기술을 적용하는것은 좋을 수 있지만, 그에 ..

Program to an interface, not an implementation. => 구현이 아닌 인터페이스에 맞춰 프로그래밍하라.출처 : GoF(Gang of Four)의 《디자인 패턴 (Design Patterns: Elements of Reusable Object-Oriented Software)》 객체지향 관련 글은 2025년 9월 이후로 작성하지 않고 있었는데 정말 오랜만에 작성한다. (지난 글이 궁금하면 여기 클릭!) 그동안 Netty를 중심으로 학습이 진행되었고, AWS 자격증 취득을 목표로 하다보니 사실 흥미를 느끼지 못했다. 하지만 OOP에 준수한 코드를 작성하고, 이를 Netty에 모듈로 붙여서 작동하는 코드롤 만들 예정이다. 해당 코드의 작업들은 oop-ddd-test-pro..

지난 글에서 SOLID와 디자인 패턴에 대해 알아보았다. (여기 클릭!) Java 섹션이지만, 가장 먼저 트랜잭션 스크립트에 대해 알아보고 Spring 공식문서에서 소개하는 각각의 Stereotype Annocation인 @Controller, @Service, @Repository를 알아보고 DDD와 OOP를 어떻게 섞어야 하는지를 알가볼 것이다. 한국에서 자바 개발자는 대부분 스프링 쓰자나? 해당 내용도 자바/스프링 개발자를 위한 실용주의 프로그래밍 을 많이 참고했으니 꼭! 구매를 바란다. 그럼... 후비고...!!! 유노윤호가 말했지... 우리에게 가장 해로운 해충은 대충이다. 대충 하지 말고 제대로 해보겠다 ㅠㅠ... 1. 액티브 레코드(Active Record) vs 트랜잭션 스크립트(Tr..

지난 시간에는 행위로 코드를 설계하는 것에 대해 알아보았다. (여기 클릭) 이번 시간에는 단순 행위 설계에서 더 나아가 SOILD 에 대해 다시 알아보고, Interface를 활용해서 어떻게 객체지향스러운 코드를 작성할 수 있는지 알아보고자 한다. 이번에도 최대한 공식 영어 명칭에 대해서 분석하고 보려고 한다. 흐름은 실용주의 프로그래밍 책을 따라갈 것이다. 1. SOLID 분석아오.... solid 정말 많이 들어봤다. 그런데 사실 직접 뜻에 대해서 분석은 안햇던 것 같다. 단순히 암기를 한거지? 으으음...!!! 그래서 필자는 현재 다시 이를 훑어보려고 한다. Single Responsibility Principle단일 책임의 원칙은 하나의 모듈이 하나, 그리고 오직 하나의 액터에 책임이 있어야..