레디스를 깊게 다룬 책 한 권을 같이 읽는 스터디를 열었다. 매주 한 챕터를 읽고 모여서 토론하는 구조이다. 하나는 사람들이 아직도 CS에 목말라 있다는 것. 다른 하나는 그 목마름의 깊이가 사람마다 너무 다르다는 것. 이 글은 그 두 발견과, 두 번째가 남긴 숙제에 대한 기록이다.1. 기능이 아니라 "왜 생겼나"부터 시작했다스터디를 설계할 때 규칙을 하나 정했다. 기술을 기능 목록으로 외우지 않는다. 대신 그 기술이 답하려던 문제부터 따라간다. 한 문장으로는 이렇다.A라는 한계를 해결하기 위해 B가 고안되었다.레디스는 이 접근에 딱 맞는 소재다. 학계나 표준위원회가 아니라 한 서비스의 부하 곡선에서 나왔기 때문이다. 실시간 웹 로그 분석 서비스를 만들던 개발자가 있었다. 방문자의 클릭을 지금 이 순간 ..

학습 앱을 만들고 있다. 매일 3문제를 푸는 포맷이다. 하지만 운영하다 보니 "정말 이 포맷이 유저에게 가치를 주고 있나?"라는 의심이 들기 시작했다.이 글은 서비스 포맷을 근본에서부터 다시 뜯어본 고민의 기록이다. 어포던스, 초두효과, 반복 피로, 트레이드오프 만족감 — 네 가지 렌즈로 서비스를 비춰봤다.1. 어포던스, UI가 아니라 서비스 메카닉에 줄 수 있을까처음 "어포던스를 적용하자"고 했을 때, 나는 자연스럽게 UI 요소를 떠올렸다. 스와이프 인디케이터, 잠금 아이콘, 스트릭 경고색 같은 것들. 하지만 진짜 필요한 건 "매일 3문제"라는 메카닉 자체에 어포던스를 녹이는 것이었다.버튼에 그림자를 넣어서 "누르는 것"을 암시하듯, "오늘 3문제를 푸는 것"이 설명 없이도 당연하게 느껴지는 구조를 만..

프론트엔드에서 검색창 자동완성이나 resize 이벤트 처리에 debounce를 쓰는 건 익숙합니다. 그런데 서버에서도 디바운스가 필요한 순간이 있습니다. 관리자가 데이터를 연속으로 여러 번 수정할 때, 매번 무거운 후처리를 실행하면 DB에 불필요한 부하가 걸리기 때문입니다.이 글에서는 Redis + Spring Scheduler를 활용해 서버 사이드 디바운스를 구현한 경험을 공유합니다.문제 상황이커머스 운영에서 상품 정보가 변경되면 이미 예약된 알림 메시지도 함께 업데이트해야 하는 요구사항이 있었습니다.상품명 변경 — 예약 메시지에 포함된 상품명을 갱신상품 매핑 변경 — 다른 상품으로 교체 시 메시지 재생성메시지 템플릿 변경 — 발송 양식 자체가 바뀌면 전체 재생성문제는 관리자가 상품 정보를 여러 번 연..

[트랜잭션]트랜잭션은 커밋되거나 롤백될 수 있는 하나의 원자적인 작업단위이다. 하나의 트랜잭션이 아래와 같이 여러 변경을 하는 경우, 커밋될 때 모든 변경이 성공하거나 트랜잭션이 롤백될 때 모든 변경이 취소된다.START TRANSACTION;UPDATE account SET balance = balance - 10000 WHERE id = 1;UPDATE account SET balance = balance + 10000 WHERE id = 2;COMMIT; 위 예시는 계좌 이체를 구현하는 트랜잭션이다. 하나라도 실패하면 전체가 롤백되어야 하므로, 트랜잭션으로 묶어야 데이터 정합성을 유지할 수 있다.[트랜잭션의 ACID]트랜잭션은 총 네가지 속성을 가진다. [Atomic-원자성] 트랜잭션 내의 작업은 ..

멀티스레드 환경에서 동시성은 여러 작업을 병렬로 처리하면서, 애플리케이션의 성능을 향상시킬 수 있습니다.하지만 동시에 여러 스레드가 동시에 같은 데이터, 자원을 조작하게 되면, 예상하지 못한 문제들이 발생합니다. 문제 상황자바 코드를 예시로 문제 상황을 이해해 보겠습니다.public class Counter { private int count = 0; public void increment() { count++; } public int getCount() { return count; }} Counter 클래스는 count라는 필드를 가지고, 해당 필드는 increment를 통해 증가시킬 수 있습니다. 멀티 스레드 환경에서 아래와 같이 incremen..

서비스를 유지보수하게 되면, 수정된 내용을 고객에게 제공하기 위해 배포라는 과정이 필요하다. 일반적으로 배포 과정은 반복 작업이다. 수정된 소스가 메인 브런치에 머지된 후1. 수정된 소스를 기반으로 빌드한다.2. 빌드된 산출물을 반영할 서버 또는 s3에 전송한다. 3. 기존  서비스를 중단하고, 산출물을 교체한다.4. 배포 중 또는 후 문제가 발생하면 산출물을 다시 되돌린다. 우리는 이러한 반복 작업을 줄이고, 우리의 새로운 버전 애플리케이션이 안정적으로 패치하기 위해 자동화된 CI/CD 파이프라인을 구축하고, 다양한 전략을 사용하여 배포한다. 다양한 배포 전략에 대해 알아보고자 한다. 롤링 배포배포 그룹의 애플리케이션을 순차적으로 트래픽을 차단한 뒤, 새버전으로 재기동한다.[배포 과정]새 버전으로 교체..

.백엔드 개발을 하다보면 주기적으로 또는 특정 시간대에 동작해야하는 기능을 만들어야할 때가 있습니다. 이러한 경우 Spring에서는 기본적으로 Spring Schduler를 내장하고 있습니다. Spring Schduler 를 사용하면 원하는 기능을 간단하게 만들 수 있지만 서버가 분산환경이거나, 복잡한 로직일 경우 적합하지 않습니다. 오늘은 이러한 경우에 사용할 수 있는 Spring quartz에 대해 알아보겠습니다.쿼츠 구성요소[전체 동작 흐름]1. SchedulerFactory가 Scheduler를 생성하고, SchdulerRepository에 등록2. QuartzScheduler가 시작되면, ThreadExecutor를 통해 QuartzSchdulerThread를 생성3. 생성된 QuartzSchd..

상태수락됨콘텍스트현재 서비스는 2개의 리눅스 서버로 구성되어 있다.레디스는 1번 서버에 standalone 형태로 구성되어 있다.1번 서버가 내려가는 경우, 서비스에 장애로 이루어질 수 있어서 failover 구성을 해야한다.redis에서 failover를 구성하기 위한 방법은 Sentinel과 Clustering이 있다. 결정[의사 결정 과정 ] 1. 고가용성이 목표인가 : 고가용성이 목표이다.2. 샤딩(Scale-out)이 필요한가 : 필요 없다.3. 서버 자원이 여유로운가 : 클러스터링을 구성하기에는 메모리가 부족하다. [레디스 구성] - 쿼럼은 2로 설정 [FailOver 과정 예상]1. Master 서버 다운2. B서버 2개의 센티널이 쿼럼 2로 마스터 서버 장애 식별3. B서버 Slave가 M..

스프링 캐시 추상화스프링 프레임워크는 캐시 추상화를 지원합니다.이를 활용하여, 캐시 구현 기술에 종속되지 않게 추상화된 캐시 서비스를 구현할 수 있습니다. 캐시 관련 설정1. EnableCaching 추가@EnableCaching @Configuration public class CacheConfig { ...}캐시 매니저 빈 추가추상화된 캐싱 서비스는 org.springframework.cache.Cache및 org.springframework.cache.CacheManager인터페이스에 의해 구체화됩니다. 스프링에서 제공하는 캐시매니저는 다음과 같습니다. ConcurrentMapCacheManager (빈을 등록하지 않으면 기본적으로 사용)SimpleCacheManager : 사용할 캐시를 ..

저는 5인 이하의 소규모 SI 회사에서 개발 및 유지보수 업무를 하고 있습니다.소규모 SI에서 일을 하게되면 다양한 장애상황을 직면합니다.일반적으로 이러한 환경에서, 조언을 얻거나 해결책을 제시받기 어렵기 때문에 저의 경험을 공유하고자 합니다. 예산이 한정되어있는데 트래픽이 계속 증가한다면문제상황클라이언트가 사이트 개발 및 유지보수 요청을 한다.기획 당시에는 소규모 인원만 사용하게 될 것이고, 사용량(트래픽)이 그렇게 많지 않다고 이야기한다.별다른 수익화 모델 없이, 기존의 구두로 이루어지는 일을 전산화하는 요구사항이다.따라서 서버 운영 비용을 한달에 10~20만원 선에서 해결해야한다.초기에는 이러한 구성에도, 트래픽이 많지않아 문제 없이 서버 운영이 가능했다.그러나 이런 평화로운 나날도 잠시, 클라이어..