개발놀이터

이번 포스팅에선 Spring의 @Transactional를 깊이있게 파헤쳐보고 정리해보도록 하겠습니다. 코드는 깃허브를 참고해주시면 감사하겠습니다. 코드는 웬만하면 적지 않을 예정입니다. 제 블로그 포스팅은 기본적으로 코드를 되도록 적지 않는데 그 이유는 코드가 많아지면 설명해야할게 많아지고 그럼 가독성이 떨어진다고 생각하기 때문입니다. 또한, 저도 공부하면서 포스팅을 수백개 봤지만 사실 코드를 잘 안봅니다... 그리고 깃허브를 들어가서 실제 코드를 보면 아시겠지만 변수명과 함수명이 실제 스프링 프로젝트와 다른 부분이 있습니다. 그 이유는 실제 스프링 프로젝트는 훨씬 더 복잡한 계층 구조와 다양한 팩토리 클래스를 가지고 있습니다. 그래서 제 프로젝트는 최대한 가볍게 만들기 위해서 변수명을 조정했습니다...

이번 포스팅에선 Spring AOP를 깊이있게 파헤쳐보고 정리해보도록 하겠습니다. 코드는 깃허브를 참고해주시면 감사하겠습니다. 코드는 웬만하면 적지 않을 예정입니다. 제 블로그 포스팅은 기본적으로 코드를 되도록 적지 않는데 그 이유는 코드가 많아지면 설명해야할게 많아지고 그럼 가독성이 떨어진다고 생각하기 때문입니다. 또한, 저도 공부하면서 포스팅을 수백개 봤지만 사실 코드를 잘 안봅니다... 그리고 깃허브를 들어가서 실제 코드를 보면 아시겠지만 변수명과 함수명이 실제 스프링 프로젝트와 다른 부분이 있습니다. 그 이유는 실제 스프링 프로젝트는 훨씬 더 복잡한 계층 구조와 다양한 팩토리 클래스를 가지고 있습니다. 그래서 제 프로젝트는 최대한 가볍게 만들기 위해서 변수명을 조정했습니다. 사실 코드는 별로 중..

이번 포스팅에선 @Configuration, @Bean을 깊이있게 파헤쳐보고 정리해보도록 하겠습니다. 코드는 깃허브를 참고해주시면 감사하겠습니다. 코드는 웬만하면 적지 않을 예정입니다. 제 블로그 포스팅은 기본적으로 코드를 되도록 적지 않는데 그 이유는 코드가 많아지면 설명해야할게 많아지고 그럼 가독성이 떨어진다고 생각하기 때문입니다. 또한, 저도 공부하면서 포스팅을 수백개 봤지만 사실 코드를 잘 안봅니다... 그리고 깃허브를 들어가서 실제 코드를 보면 아시겠지만 변수명과 함수명이 실제 스프링 프로젝트와 다른 부분이 있습니다. 그 이유는 실제 스프링 프로젝트는 훨씬 더 복잡한 계층 구조와 다양한 팩토리 클래스를 가지고 있습니다. 그래서 제 프로젝트는 최대한 가볍게 만들기 위해서 변수명을 조정했습니다. ..

이번 포스팅에선 Spring Bean LifeCycle을 깊이있게 파헤쳐보고 정리해보도록 하겠습니다. 코드는 깃허브를 참고해주시면 감사하겠습니다. 코드는 웬만하면 적지 않을 예정입니다. 제 블로그 포스팅은 기본적으로 코드를 되도록 적지 않는데 그 이유는 코드가 많아지면 설명해야할게 많아지고 그럼 가독성이 떨어진다고 생각하기 때문입니다. 또한, 저도 공부하면서 포스팅을 수백개 봤지만 사실 코드를 잘 안봅니다... 그리고 깃허브를 들어가서 실제 코드를 보면 아시겠지만 변수명과 함수명이 실제 스프링 프로젝트와 다른 부분이 있습니다. 그 이유는 실제 스프링 프로젝트는 훨씬 더 복잡한 계층 구조와 다양한 팩토리 클래스를 가지고 있습니다. 그래서 제 프로젝트는 최대한 가볍게 만들기 위해서 변수명을 조정했습니다. ..

이번 포스팅에선 Spring MVC를 깊이있게 파헤쳐보고 정리해보도록 하겠습니다. 코드는 깃허브를 참고해주시면 감사하겠습니다. 코드는 웬만하면 적지 않을 예정입니다. 제 블로그 포스팅은 기본적으로 코드를 되도록 적지 않는데 그 이유는 코드가 많아지면 설명해야할게 많아지고 그럼 가독성이 떨어진다고 생각하기 때문입니다. 또한, 저도 공부하면서 포스팅을 수백개 봤지만 사실 코드를 잘 안봅니다... 그리고 깃허브를 들어가서 실제 코드를 보면 아시겠지만 변수명과 함수명이 실제 스프링 프로젝트와 다른 부분이 있습니다. 그 이유는 실제 스프링 프로젝트는 훨씬 더 복잡한 계층 구조와 다양한 팩토리 클래스를 가지고 있습니다. 그래서 제 프로젝트는 최대한 가볍게 만들기 위해서 변수명을 조정했습니다. 사실 코드는 별로 중..

이번 포스팅에선 AnnotationApplicationContext를 깊이있게 파헤쳐보고 정리해보도록 하겠습니다. 코드는 깃허브를 참고해주시면 감사하겠습니다. 코드는 웬만하면 적지 않을 예정입니다. 제 블로그 포스팅은 기본적으로 코드를 되도록 적지 않는데 그 이유는 코드가 많아지면 설명해야할게 많아지고 그럼 가독성이 떨어진다고 생각하기 때문입니다. 또한, 저도 공부하면서 포스팅을 수백개 봤지만 사실 코드를 잘 안봅니다... 그리고 깃허브를 들어가서 실제 코드를 보면 아시겠지만 변수명과 함수명이 실제 스프링 프로젝트와 다른 부분이 있습니다. 그 이유는 실제 스프링 프로젝트는 훨씬 더 복잡한 계층 구조와 다양한 팩토리 클래스를 가지고 있습니다. 그래서 제 프로젝트는 최대한 가볍게 만들기 위해서 변수명을 ..

공부를 시작한지는 만으로 4년 3개월 햇수로는 5년차에 접어들면서 이것저것 많이 공부해봤는데요. 그래서 블로그 포스팅도 어느새 600개를 향해 가고있습니다. 물론 그 중에서 코딩 테스트나 영어 공부, 면접 준비를 뺀 진짜 포스팅은 500개 남짓이지만요. 처음엔 코딩하는게 재밌었습니다. 프로젝트 만드는게 재밌었거든요. 영한님 강의 들으면서 복습할겸 사이드 프로젝트로 하나 만들어보고 강의 듣고 사이드 프로젝트 만들고를 반복했습니다. 그렇게 2년정도를 공부하니 웬만한 프로젝트는 만들 수 있겠더군요. 그리고 그 때 이론이 부족한 것을 자각하고 코딩은 하지 않고 이론 공부만 매진했습니다. 특히 데이터베이스를 위주로 네트워크, 운영체제, 보안, 아키텍처, 데브옵스 가리지 않고 공부했죠. 제가 가장 이상적이라고..

기존 ver.2에서 Redis를 도입해 RDBMS의 부하를 30퍼센트 줄여 문제점을 개선하였습니다. 하지만 읽기 요청이 많아지면 Redis에 큰 무리가 가게 되고 Redis가 standalone 상태에서 다운되면 뒤에 있는 RDBMS도 다운될 가능성이 있습니다.  때문에 Redis의 고가용성을 유지하는 것이 새로운 과제가 되었고 이번 ver.6에서 Redis Sentinel을 이용해 문제를 해결하게 되었습니다.  왜 Sentinel이었나?Redis에 고가용성을 위한 옵션으로 Sentinel과 Cluster가 존재합니다. 둘 중 Sharding이 지원되는 Cluster가 상위호환이지만 Sentinel을 선택하게 되었습니다.  Sentinel을 선택한 이유는 우선 첫번째로 프로젝트에 Sharding이 필요할..

백엔드에서 가장 난이도 있기로 소문난 특정 지점에 트래픽이 몰리는 상황을 대비하여 Redis를 이용해 대기열을 만들었습니다.  https://coding-review.tistory.com/530 Redis로 대기열 구현하기이번 포스팅에선 Redis로 대기열을 구현한 것을 공유하려고 컴퓨터 앞에 앉았습니다.  이번에 주요한 기능은 WebSocket과 Redis의 Sorted Set 자료구조입니다. Sorted Set은 정렬 알고리즘의 시간 복잡도coding-review.tistory.com  제 프로젝트는 온라인 쇼핑몰인만큼 블랙프라이데이나 콜라보 이벤트를 하는 경우 트래픽이 몰리는 것을 대비하여 대기열을 만들었습니다.  이번 대기열을 이용해 애플리케이션 서버 부하와 RDBMS의 부하를 획기적으로 줄일 수..

기존 프로젝트에서 동시성 문제가 발생하였고 이를 JPA의 비관적 락으로 해결하였습니다. 하지만 비관적락이 RDBMS로 하여금 락킹 매커니즘을 관리하기위해 커넥션을 생성하고 이때문에 RDBMS에 부하가 발생한다는 문제가 발생했습니다.  해결방법으로 Redis의 라이브러리인 Redisson을 이용해 분산 락을 구현했습니다. 기존에 사용하던 Lettuce는 스핀락의 개념으로 Redis에 lock을 지속적으로 확인해야 하기 때문에 RDBMS의 부하가 그대로 Redis로 몰린다는 단점이 있었습니다. 때문에 Redisson을 사용하게 되었습니다.  wrk2로 부하 테스트를 진행하였고 docker로 컨테이너를 모니터링 하여 테스트를 진행했습니다.  특징RDBMS는 MySQL을 사용하였습니다. 스레드는 8개, 동시 커..