지금 현재 프로젝트는 MSA로 되어 있기 때문에 모놀로식 프로젝트때 사용했던 스프링 시큐리티 방식을 사용하지 못한다.만약에 사용을 하려면 스프링 시큐리티를 각 도메인마다 사용을 해야하는데 그렇게 되면 예상치 못한 이슈가 발생할지도 모르기때문에 도메인마다 시큐리티 사용하는것을 하지 않았다.그러다 보니 권한 체킹하는것이 쉽지가 않았다. 모노로식에서는 어노테이션 하나만 넣으면 되는것이사용하지 못하기 때문이었다.그렇다면 이것을 어떻게 해결하면 좋을까?해결할 수 있는 방안은 총 4가지로 필터, 인터셉터, AOP, 각 각 서비스마다 사용하는 방법이었다.그중 내가 선택한것은 AOP방식이었다. 일단 필터가 동작하는 부분은 서블릿 필터이전에 동작을 한다. 그렇다는건 컨트롤러가 들어오기전에 그것을 체킹해야된다는 뜻인데사실..
인덱스 - btree 왼쪽 작은거 오른쪽 큰거삽입,삭제 → 수정위치찾아서 추가삭제 → 정렬언제 리벨런싱되는지..Mysql은 기본적으로MySQL(InnoDB)은 기본적으로 B+Tree 인덱스를 사용하며,삽입·수정·삭제 시 트리 구조의 균형과 정렬 상태를 유지합니다.삽입 시노드에 여유 공간이 있으면 정렬된 상태로 추가되지만,노드가 가득 찬 경우 split(분할)이 발생하고 재 정렬이 이루어질 수 있습니다.삭제 시 키가 사라지면 노드 간 병합(merge)이나 키 차용(borrow)과정이 발생해, 구조적 재 정렬과 균형 유지가 수행 됩니다언제?노드가 가득 찼을 때 새로운 데이터를 삽입하면 오버플로우(Overflow)가 발생.트리의 높이를 최소로 유지하기 위해 노드를 두 개로 나눔.과정:중간 키를 선택해 상위 노..
동시성이라는건 무엇일까?여러 쓰레드가 동시에 접근해서 발생하는 문제라고 한다.이렇게까지는 알고는 있는데 내가 하고 있는 테스트가 과연 동시성이 맞는걸까?간단한 코드를 작성하였다.@Testpublic void testConcurrency() throws InterruptedException { UUID stockId = UUID.randomUUID(); Stock stock = new Stock(stockId, 1000); StockRepository mockStockRepository = Mockito.mock(StockRepository.class); Mockito.when(mockStockRepository.findByIdAndDeleteByIsNull(stockId)).then..
레이어드 아키텍처로 개발하고 있었는데 문득 궁금증이 생겼다. 과연 이게 맞는것일까?나같은 경우는 Page객체를 도메인객체에 두고 사용을 하고 있었고,Pageable객체를 프리젠테이션 계층에서 두고 넘겨주고 있었다. 왜냐하면 마땅히 방안이 생각나는게 아니었기 때문에 나는 그냥 사용하기로 했다. 오늘 팀원분들과 코드 리뷰하면서 이렇게 개발하면 될거 같아 소개 하려고 한다.일단 원래 방식의 문제가 Pagable이라던지 Page가 외부에서 가져온 라이브러리라 인프라스트럭처에서 사용하는것이 맞는걸로 알고 있다.근데 몇몇의 라이브러리는 편의성을 위해 프리젠테이션 혹은 어플리케이션측에 사용하는걸로 알고 있다.대표적인 예시가 ResponseEntity인데 얘도 어찌보면 외부에서 가져온것이기때문에 인프라에 있어야 하지만..
1차때는 모노로식으로 개발을 해서 설계가 없이 들어갔었는데 이번에는 MSA을 하기로 했다.전 직장에서도 MSA로 개발했지만 개인적으로 이게 맞는 방법인지에 대해서 의구심이 계속 들었다.그러다 레이어 4계층이라는 걸 알게 되었다.근데 이게 생각보다 쉽지 않았다. 처음부터 잘될리가 없지만, 프리젠테이션이며, 어플리케이션이며 하나같이 이해가 안가는거 투성이었다.이게 DDD라는 건가? 도메인 주도라는게 도대체 뭘까?개인적으로 요런것들이 프로젝트 전반에 걸쳐서 가장 중요한 작업이라고 생각이 들었다.그래서 튜터님에게 계속 질문을 했던걸로 기억한다. 아래는 튜터님이 주신 그림이다.중요한 점은 고수준을 얼마나 보호할 수 있는가를 생각해봐야 한다고 하셨다.그럼 여기서의 고수준은 어떤걸까? 바로 도메인이다. 그림으로 보면..
레코드는 자바14부터 등장하였다.레코드의 장점은 불변함을 가진다는 것이다.그러니까 데이터가 변경이 되지 않는 다는 뜻이 된다.사용법은 간단하다.요런식으로 ()안에 클래스에 데이터를 넣어주면 된다.이렇게 되면 new CreateClientRequest(name...); 이랑 똑같이 동작을 하게 된다.어떻게 보면 저것만 사용하니까 생성자를 추가적으로 사용해야 하는 클래스보다 깔끔하다는 느낌이 든다.그렇다면 생성자를 또 만들고 싶다면 어떻게 해야 할까?이것도 클래스와 똑같이 생성자를 만들면 된다.하지만 주의해야 할점이 있다.애초에 위 데이터들은 불변값이다. 따라서 this.name = name이런식으로 데이터를 바꾸는것은 불가능하다.어떻게 해결할 수 있을까?this()로 데이터를 입력을 받아줘야 한다. thi..
오늘 패키지 구조를 팀원들과 정했다.팀원중 한분이 아프셔서 오늘 불참해서 매우 슬프지만ㅜㅜ 암튼 우리는 패키지 구조를 정했다.튜터님이 몇일전에 글을 올려주셨는데 DDD관련 글이었다.그 글을 보고 어떻게 구성하면 좋을지 고민을 해보았습니다.1차때 패키지 구조를 논의하지 않아서 리펙토링을 하는것이 어려웠다.그래서 이 구조를 선택하게 되었다.하지만 생각보다 쉽지 않는 구조에 튜터님을 계속해서 방문해서 그 해답을 듣게 되었다.우리가 결정한 아키텍처는 4 레이어 아키텍처로상위패키지├── application├── domain├── infrastructure└── presentation크게 이렇게 결정하였다.간단히 설명하면 application은 무조건 domain이랑 소통을 해야 한다는 점이다.그리고 외부에서 받..
2차 프로젝트가 시작이 되었다.이번에는 나는 팀장이 아니라 팀원으로 시작하였다.근데 왜 내가 테크 리더....뭐지... 왜 감투를 쓰게 된거지저번 프로젝트는 배민이었다면 이번에는 쿠팡이다. 다만 다른점은 쿠팡은 물류창고가 있지만이 프로젝트는 허브가 물류창고 개념은 아니라고 하셨다.오늘 실업급여때문에 고용센터를 갔다오는 바람에 12시에 입실을 하였다.도착하니 팀원들이 API명세서를 작성하고 있었다.근데 나는 API명세서 보다 기획 흐름을 먼저 알아야 된다고 생각했고플로우 차트 부터 그리자고 하였다.그 결과 요런식으로 작성하게 되었다.플로우 차트를 그리고 보니 저녁이 벌써 9시가 넘었다. 분명 기획을 읽었는데 너무 허점이 많았고.. 힘들었다.하지만 너무 재밌게 해결했던거 같다.그리고 이번에는 chat gpt..
프로듀서..@Bean public ProducerFactory producerFactory() { Map configProps = new HashMap(); // 중간 구현 return new DefaultKafkaProducerFactory(configProps); } // 동적으로 만들고 @Bean public KafkaTemplate kafkaTemplate(ProducerFactory producerFactory) { return new KafkaTemplate(producerFactory); } // 구체화 시키고 @Bean public KafkaTemplate demoCreateEventKafkaTempla..
음 사가가 뭘까..saga: 서비스들이 이벤트로 협력해서 트랜잭션을 완성하는 방식Saga 패턴은 분산 시스템에서 트랜잭션을 처리하는 방법 중 하나로, 데이터베이스의 일관성을 보장하기 위해 여러 서비스 간의 복잡한 트랜잭션을 관리합니다. 이를 통해 마이크로서비스 환경에서 발생할 수 있는 트랜잭션 처리 문제를 해결할 수 있습니다.요렇다고 한다.그러면 주요 특징은 어떤것이 있을까분산 트랜잭션 관리:전통적인 분산 트랜잭션에서는 한 번에 모든 작업을 완료해야 하기 때문에, 여러 서비스가 참여할 때 데이터의 일관성을 유지하기가 어렵습니다.Saga 패턴은 각 서비스에서 로컬 트랜잭션을 처리하고, 각 로컬 트랜잭션의 성공이나 실패에 따라 후속 작업을 정의합니다. 즉, 트랜잭션을 여러 단계로 나누어 관리합니다.그니까 사..
Saga 패턴은 ACID 대신 BASE 원칙을 따르는 대표적인 기법 BASE는 Basically Available, Soft state, Eventual consistency의 약자야. 하나씩 간단하게 볼게!Basically Available(기본적인 가용성)시스템이 항상 완전한 일관성을 보장하지 않더라도, 항상 응답은 가능한 상태를 유지해. 일부 데이터가 최신이 아니더라도 서비스는 계속 동작하는 거지.Soft state(유연한 상태)데이터의 상태가 즉시 일관적이지 않아도 괜찮음. 각 서비스가 독립적으로 데이터를 관리하니까, 시스템 전체의 상태가 시간이 지나면서 변할 수 있어.Eventual consistency(최종적인 일관성)즉시 일관성을 포기하는 대신, 일정 시간이 지나면 결국 데이터가 일관된 상태..
카프카는 어떤것일까 내가 알기로는 카프카는 대규모 트래픽 환경에서 사용한다고 한다.생각해야 할것이 진짜 카프카가 대규모 트래픽 환경에서 좋은걸까? 좋다면 왜 좋은지 알고 있어야 한다고 생각한다.사가패턴이며, 이벤트 소싱이며 이런거 보다 진짜 중요한건 카프카가 왜 필요한지 여부에 대해 공부를 해야 한다고 생각한다.모든 기술이 그렇듯 다 탄생 배경이 있다. 그렇다는건 어긋난 방식으로 사용한다면 오히려 성능이 떨어질 수 도 있다는 뜻이 된다.이 글에서 어떻게 사용하는지에 대해는 자세하게 다루지 않을 수 도 있다. 이것도 보다 중요한건 왜 쓰고 언제 쓰는지가 훨씬더 중요하다 생각한다. 이제 본격적으로 시작해보자.카프카의 탄생 배경대규모 데이터 처리 필요성: 대규모 분산 시스템에서의 로그 처리와 실시간 데이터 스..
