Lob!

이 글의 결론만 알고 싶다면?최근 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 등의 프로토콜을 통한 패키지 전달 및 실행..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. 복제가 필요한 이유? 우리가 제공하는 API 서비스는 일반적으로 Stateless 한 형태를 준수하여 개발하여야 합니다. 이는 State를 다른 서비스(RDBMS, Global Session Storage - Redis 등)에서 관리하게 하고, API 서비스는 필요에 의해 조회하도록 하여 Stateful로 개발하였을 때 발생하는 API 서비스 간의 상태 동기화 이슈나 확장성 저하 문제를 최소화할 수 있기 때문입니다. 이러한 구조는 트래픽 급증에 대응하는 Scale-out을 가능케 합니다. 이런 형태로 개발하게 되면 결국 다수의 API 서비스가 조회하는 State를 관리하는 서비스에는 대량의 부하가 전달되어 자연스레 해당 서비스에 장..

이 글은 특정 구현에 종속되는 내용을 제외한 이론 위주의 정리 글입니다. 장애 감지 알고리즘이 필요한 이유? 우리가 개발하는 서비스가 단일 시스템이 아닌 분산 시스템 구조를 지닌다면 특정 서비스에 장애가 발생하더라도 모든 서비스 노드에게 전파되지 않기 때문에, 사용자 요청으로 인해 식별되기 전까지 모를 수 있습니다. 장애가 발생한 서비스에 따라서 시스템에 잘못된 값을 설정하거나 중복이 발생할 수 있고 (Index Sharding Service) 사용자가 보는 캐싱된 데이터가 소실되는 경우도 발생할 수 있습니다. (Feed Cache Service 등) 물론 모든 장애가 서비스 종료, 충돌과 같은 완전 중단 상태를 의미하는 것은 아니며, 상황에 따라 부하로 인한 응답 지연, 네트워크 지연 이슈 혹은 데드락..