분류 전체보기

동시 접속자가 증가하면, DB에 전달되는 부하 또한 증가하게 됩니다. 아직 심각한 성능 저하를 경험하지는 못했지만, 사내 서비스에 사용자가 점차 늘어나는 상황에서 단일 DB 구조의 잠재적 문제를 미리 파악해 장애를 방지해야겠다고 판단했습니다. Clustering, Replication, Sharding 등 다양한 선택지 중 해당 프로젝트에 가장 적합한 Replication을 선택하게 되었습니다. 선택한 이유와 Replication을 적용하면서 확인한 성능 개선 결과를 공유하겠습니다. 😣 단일 DB의 한계단일 DB는 모든 쓰기/읽기 요청이 한 곳에 집중되어 트래픽이 증가할 경우 성능 저하를 피할 수 없고, 장애 발생 시 전체 서비스가 중단될 수밖에 없습니다.'그럼 성능을 올리면 되잖아?'라고 생각할 수 ..

여느 때처럼 사내 프로젝트를 진행하던 중, 문득 'Redis에 장애가 발생하면 캐싱된 데이터를 요청하는 API는 어떻게 될까?' 라는 생각이 스쳐 지나갔습니다. TimeOut이 발생할지, 즉시 에러를 반환할지, 다른 방식으로 처리될지 궁금해졌습니다. 궁금증을 해소하기 위해 직접 확인해보기로 했습니다. 🚫 Redis 서버에 장애 상황을 연출해보자Redis 서버에 장애 상황을 만들기 위해 직접 Redis 서버를 종료 시키고 API를 호출한 뒤 어떤 일이 발생하는지 직접 확인해봤습니다.결과는 예상대로, TimeOut이 발생했습니다. 매 요청마다 Redis 연결을 시도하고, 연결에 실패하면 설정된 TimeOut 시간만큼 기다린 후 에러를 반환했습니다. 사용자 입장에서는 몇 초간 응답 없이 기다리다 결국 데이..

얼마 전 새벽, 모니터링 시스템의 알림이 발송되어 확인해보니 운영 중인 사내 사이트에 초당 10,000건 이상의 API 요청으로 인해 서버가 다운되는 상황이 발생했습니다. 서비스는 접속이 불가능해졌고, 약 5시간 동안 서비스가 완전히 중단되었습니다. 악의적인 DDoS 공격이었지만, DDoS에 무방비하게 당한 것은 사전에 대비책을 마련하지 않았기 때문이라고 생각합니다. 동일한 상황을 방지하고자 자발적으로 처리율 제한 장치를 구축했고, 이번 글에서는 어떤 알고리즘을 선택했고, 왜 선택했는지에 대해 공유하려고 합니다. 📊 API 호출 횟수 제한 정책처리율 제한 장치를 설계하면서 가장 먼저 고민했던 부분은 임계값이었습니다. 정상 트래픽은 유지하면서, 공격 트래픽을 제한할 수 있는 임계값을 구하기 위해 Goog..

사내에서 6년간 운영해오던 사이트를 전면 리팩토링 작업 후 몇 개월간 큰 문제없이 운영되는 듯 했었는데, 데이터가 쌓이다보니 동료가 작업한 특정 페이지에서 조회 시간이 19초 이상 소요되는 것을 발견했습니다. 회사에서는 크게 문제 삼지 않았지만, 이런 문제들이 쌓이다 보면 분명 더 큰 문제로 다가올 수 있다고 생각했습니다. 그래서 직접 나서서 슬로우 쿼리 문제를 해결하기로 했습니다. 🛠️ 쿼리부터 튜닝하자인덱스 추가, 캐시 등의 작업을 하기 전 쿼리를 효율적으로 수정하기만 해도 성능이 상당히 개선될 수 있기 때문에 우선 쿼리 작업을 수행했습니다. 아래 3가지 작업을 통해 조회 시간 평균 19초에서 약 5초까지 감소시킬 수 있었습니다. 👉🏻 불필요한 Join 제거 및 서브쿼리 개선불필요한 Join을..

대부분의 애플리케이션에서 데이터 관리는 빼놓을 수 없죠 ! 그래서 오늘은 데이터베이스 Lock에 대해 알아보려고합니다. ❓Lock이란 ?Lock의 정의는 DB의 일관성과 무결성을 유지하기 위해 트랜잭션의 순차적 진행을 보장할 수 있는 직렬화 장치입니다. 즉, 트랜잭션 처리의 순차성을 보장하기 위한 방법이라고 생각하시면 됩니다. Lock의 종류는 공유 Lock(Shared Lock, Read Lock, S-Lock), 배타 Lock(Exclusive Lock, Write Lock, X-Lock)로 나뉩니다. 🔎 공유 Lock(Shared Lock, Read Lock, S-Lock)공유 Lock은 데이터 읽기 작업에 사용되는 Lock입니다. 공유 Lock은 공유 Lock끼리는 동시에 접근이 가능합니다. 하..

평소 무신사를 많이 이용하는 저는 무신사 밋업 신청 글을 보자마자 망설임 없이 '신청하기' 버튼을 눌러 버렸습니다. 감사하게도 선정되어 개발자 인생 처음으로 밋업 참여 기회를 얻게 되었습니다.이번 밋업은 무신사의 비전과 앞으로의 방향성 그리고 무신사 Engineering을 이루고 있는 각 팀의 성격과 팀의 역할을 소개하는 시간이었습니다. (발표에 너무 집중해서 메모를 못해, 기억나는 내용만 작성 하겠습니다🥲)💭 기억에 남는 발표 내용무신사의 비전과 성장요즘 경제가 좋지 않아 실적이 부진할 거라는 예상과는 달리, 무신사는 오히려 꾸준한 매출 증가세를 보이고 있다고 합니다. 저는 단순히 운이 좋아서가 아니라, 고객 경험 개선과 플랫폼 안정성을 위해 끊임없이 노력해온 수많은 직원들의 성과라고 생각합니다. ..

📚 책을 선택한 계기개발자라면 누구나 한 번쯤 대규모 시스템을 설계하고 운영해보고 싶은 로망이 있을 것입니다. 저 역시 평소 "유튜브는 어떻게 수억 명의 사용자를 처리할까 ?", "검색어 자동완성 시스템은 어떻게 관리할까 ?"와 같은 궁금증이 많았지만, 실제 업무에서는 작은 규모의 서비스만 다루다 보니 대규모 시스템을 경험할 기회가 없었습니다.마침 선우님의 추천으로 "가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 알게 되었고, 평소 사용하던 서비스들이 어떻게 설계되었는지, 수많은 사용자를 어떻게 처리하는지를 배울 수 있는 좋은 기회가 될 것 같아 선택하게 되었습니다.🧐 목차 살펴보기이 책의 목차는 아래와 같습니다. 도서 구매 전 목차를 보고 흥미로운 주제가 많아 신나했던 기억이 새록새록하네요 ..

🫢 문제 상황Spring Boot에서 Master/Slave 패턴으로 DB 구조를 구현했지만, @Transaction(readOnly = true)로 설정한 메서드가 계속 Master DB(3306)로 접근하는 문제가 발생하였습니다. Slave DB(3307)로 라우팅되어야 하지만 실제로는 읽기 전용 설정이 false로 인식되는 문제가 발생하고 있었습니다. ⚙️ 환경설정DB 설정(application.yml)spring: datasource: master: hikari: driver-class-name: com.mysql.cj.jdbc.Driver jdbc-url: jdbc:mysql://localhost:3306/bank?serverTimezone=Asia/S..