Lob!

생각을 정리하는 의식적인 연습을 위해 지난번 글부터 하나를 작성하는 데 1시간만 투자해보고 있습니다. 아직 세밀한 디테일을 챙기거나 충분한 부연 설명을 덧붙이는 것은 어렵게 느껴지지만 기존의 생각을 빠르게 정리하는 데에는 큰 도움이 된다고 느껴 당분간은 이 방식을 유지해보고자 합니다. Optimistic LockingOptimistic Locking(낙관적 잠금, 또는 Optimistic Concurrency Control)은 비관적 잠금(Pessimistic Locking)과 달리 잠금을 사용하지 않는 동시성 제어 방법으로 트랜잭션 간의 충돌이 자주 발생하지 않을 것이라는 가정하에 고안되었습니다. 이 기법이 적용된 대표적인 예로는 NoSQL인 MongoDB의 WiredTiger 스토리지 엔진이 있습..

Cache StampedeCache Stampede(또는 Thundering Herd)는 읽기 요청이 몰리는 특정 Resource(또는 Reosurce Collection)을 Cache에 저장하고 Look Aside 전략을 사용하고 있는 상황에서 Cache Server에서 어떠한 사유로 인해 Cache Miss가 발생하였을 때 SSoT(Single Source Of Truth, 여기서는 DBMS, Upstream API 등을 의미)로 다량의 요청이 동시에 몰려 심한 경우 일정 시간 장애도 발생시키는 위험한 상황을 의미합니다. 여기서 어떠한 사유란 다른 글에서 자주 언급하는 Cache의 TTL 만료를 대표적인 예로 들 수 있으나, 잘못된 만료 정책 설정, Global Cache Server를 사용하는 경우..

이 글의 결론만 알고 싶다면?최근 RESTful API라고 부르는 결과물들은 엄밀히 따지자면 대부분 RESTful한 API가 아닙니다.RESTful API라는 키워드를 만족하는데 매몰되기보다는 표준 HTTP API 요소를 활용해 API를 적절히 표현하고 확장하는 아이디어를 이해하는 것이 중요합니다.RESTful API가 적절하지 않은 시점과 상황을 고려하는 유연한 사고가 필요하다고 생각합니다.   이 글을 쓰게 된 배경2024년 1월 말 게으른 개발자 컨퍼런스에서 “소비자 관점의 API 설계 패턴, 사례 훑어보기” 라는 주제로 발표하며 맥락상 내용에서 제외했거나 시간 관계상 언급하지 못했던 부분을 글로 남겨보고자 합니다. 하단 참고 링크에서 발표 자료를 확인하실 수 있습니다. RESTful 설계 원칙에 ..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글이며, Look-Aside, Write-Back 패턴 등 Cache Strategy에 대한 내용들은 “Redis : Cache Strategy Pattern” 에서 다루었기 때문에 제외하였습니다. 잘못된 내용이 있을 수 있습니다. 이런 부분은 댓글을 통해 피드백 부탁드립니다.   Cache가 필요한 이유?서비스에서 자주 조회되는 데이터에 대해서 매번 접근하고 조합한 뒤 모델을 만들어 응답하는 것은 생각보다 많은 리소스를 사용하게 합니다. (Disk I/O, Join, Calculate, Sort 등..) 데이터 정규화 수준이 높거나 볼륨이 크고 서비스가 구현된 방식이 동기식이라고 가정한다면, 1개의 Request 당 최소한 1개의 Threa..

회사에서 개발하는 레거시 프로젝트의 Version Migration 작업을 준비하기 위해 Spring (boot) Version별 변경 내역을 조사하고 있는 내용입니다. 누락되거나 잘못 기술된 내용이 있을 수 있는 점 양해 부탁드립니다. Spring Boot 2.1.x Java 11 지원 (Spring Framework 5.1) Spring Boot 2.1 Release Notes · spring-projects/spring-boot Wiki 포함 의존성 변경, 삭제 등 (Junit 4.12 → Junit 5.2, Tomcat 8.5.39 → 9.x, Hibernate 5.2 → 5.3) Spring Framework 5.1 Java 8 ~ 11 CGLIB 3.2 fork(Java 9+ API로 위임) ..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. Sharding이 필요한 이유? 서비스의 특성이나 운영되어온 기간에 따라 사용자의 Data, State는 지속적으로 축적되게 됩니다. 이러한 것들이 몇 천만에서 수십 억 또는 그 이상으로 늘어난다면, Index와 같은 요소를 잘 구성되어 있더라도 결국 조회 성능의 하락이나 Data, State를 관리하는 Node에게 큰 부하를 주게 됩니다. 이는 결국 서비스의 지연 발생 빈도 수나 기간이 늘어나는 주요한 원인 중 하나가 됩니다. 이를 대비하기 위해 우리는 Performance와 Scalability 속성을 만족하는 서비스 설계를 진행하여야만 합니다. 그리고 이 속성을 지원하는 설계 방법 중 하나로는 Sharding 구조가 있습니다...

어제저녁부터 시끌시끌한 주제인 Spring4 Shell에 대해서 찾아 정리한 글입니다. 짧은 시간 동안, 얕은 이해도를 가지고 대략적인 부분만 작성하였기에 이 부분을 유의해주시고 피드백해주시면 감사드리겠습니다. 해당 문제가 발생하기 위한 조건 Java 9+ Spring Core 5.3.17 또는 5.2.19 버전 이하를 사용 Post Mapping end-point JSON / XML Converting을 사용하지 않는 API (application/x-www-form-urlencoded 사용) 즉 @ModelAttribute - ModelAttributeMethodProcessor이나 Key=Value Format의 Binding을 사용할 때 외장 Tomcat 9 사용 WebAppClassLoaderB..

회사에서 개발하는 레거시 프로젝트의 Version Migration 작업을 준비하기 위해 Java Version별 변경 내역을 조사하고 있는 내용입니다. 누락되거나 잘못 기술된 내용이 있을 수 있는 점 양해 부탁드립니다. 회사에서 맡아 진행하는 프로젝트에서 Java 17(Spring Boot는 2.6.2)을 사용하고 있기 때문에 Record나 Switch Expression, 추가된 Util 등에 만족하면서 개발을 하고 있는데요. 그렇기에 가능하다면 다른 레거시 프로젝트 또한 Java 17로 Migration 해보려고 합니다. 개인적으로 Spring Boot Version을 올리는 것이 더 까다롭지 않을까 생각하고 있습니다. Java 9 (~2018년 3월 지원 종료) 자바 모듈화(JDK 모듈 분리 기능..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. Redis Persistence Redis는 가지고 있는 데이터를 장애 발생 시 복구할 수 있도록 데이터를 영속화하는 방법을 제공합니다. Redis 데이터 영속화는 관리하는 비즈니스 데이터의 성향과 중요도에 따라 사용하거나, 하지 않을 수 있습니다. 상황을 고려하지 않고 AOF의 Always 전략 등을 사용하는 행위는 Redis의 성능 하락과 응답 지연 문제를 심화시킬 수 있기 때문에 잘 고려하여야 합니다. 영속화를 사용하는 경우 Redis Server의 서비스 중단을 방지하기 위해 Child Background Process를 사용하는 것이 필수적이며, Process fork로 인한 메모리 사용량, 발생하는 Disk I/O 빈도와..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글이며 기존에 작성했었던 CI / CD 글을 수정한 것입니다. 자동화되지 않은 개발 프로세스의 문제점 상용 서비스, 소프트웨어는 일반적으로 여러 명의 개발자가 협업을 진행하기 때문에 코드의 관리와 배포 후 발생하는 장애 대처 용도로 Git과 같은 버전 관리 도구를 사용하여 각 코드에 대한 이력과 메시지를 남기고 병합하는 과정을 거치게 됩니다. 이러한 프로세스를 계속 수행되다 보면 기존 코드(테스트, 스키마 설정 값, 충돌)와 문제가 발생할 수 있지만 이를 빨리 식별하지 못해 운영 환경에서 서비스 장애가 발생하는 경우가 있을 수 있습니다. 또한 개발, 운영팀이 수동으로 코드를 빌드하고 테스트 및 FTP 등의 프로토콜을 통한 패키지 전달 및 실행..