DB Replication에 관해 왜 필요한지 그리고 어떤 개념인지 정리해보았습니다.왜 복제가 필요한가애플리케이션에서 단일 데이터베이스 서버에 모든 요청이 몰리는 구조는 부담이 많이 됩니다.예컨대 사용자 수가 급격히 증가해 읽기 요청이 폭발적으로 늘어난다면 한 서버만으로는처리 용량, 응답 지연, 가용성 측면에서 한계가 나타납니다. 또한 만약 그 서버에 장애가 발생하면 서비스 전체가 중단되는 단일 실패 지점이 되기도 합니다.이런 문제를 해결하기 위해 데이터 복제가 사용됩니다. 하나의 원본 DB 인스턴스에서 발생한 변경사항을 다른 DB 인스턴스로 복사해서 반영하는것입니다.이렇게 함으로써 장애가 발생해도 복제본이 대체 역할을 하여 고가용성을 확보하고읽기 트래픽을 복제본에 분산시켜 읽기 성능을 향상시켜줍니다. ..

HTTP의 변천과정이 있다는 것을 한번쯤 들어보셨을 것 같습니다.저도 찾아보기 전까진 HTTP/3이 나왔는지 몰랐었습니다.오늘은 웹이 꾸준히 발전해오면서 그 중심에 있는 HTTP 프로토콜에 대해 HTTP/1.1에서 HTTP/3까지 각 버전의 개선 배경과 기술적 진화 과정을 정리해보겠습니다. 1. HTTP/0.9 ~ HTTP/1.0 제일 처음 등장한 HTTP/0.9는 매우 단순한 프로토콜이었습니다.요청 메서드는 GET만 존재했습니다.응답은 HTML 문서 하나만 전송할 수 있었습니다.이후 등장한 HTTP/1.0은 본격적으로 웹의 형태를 갖추기 시작했습니다. 핵심 개선점요청/응답에 버전 정보를 포함했습니다.헤더 필드가 추가되어 Content-Type, User-Agent 등을 설정할 수 있었습니다.상태 코..

백엔드 시스템에서 성능을 높이기 위한 가장 핵심적인 기술 중 하나가 바로 캐싱 입니다.데이터베이스에 직접 접근하는 비용은 비싸고 느리기 때문에자주 조회되는 데이터를 메모리 기반 저장소(Redis, Memcached 등) 에 저장해 빠르게 응답할 수 있도록 하는 전략이 필요합니다. 저도 진행중인 프로젝트에 nginx를 사용해 캐싱을 도입해보려 합니다.그래서 이번 기회에 캐싱 전략에는 어떤 것들이있고 어떤 상황에 어떤 전략을 적용하면 좋은지 정리해보았습니다. Cache-Aside (Lazy Loading)Cache-Aside는 가장 널리 사용되는 캐싱 전략으로 캐시가 DB와 독립적으로 존재하며 애플리케이션이 캐시와 DB를 직접 제어합니다.동작 방식애플리케이션이 캐시에서 데이터를 먼저 조회캐시에 없으면(Cac..

지난 글에서 HTTP 요청/응답에 대해 알아보았고 HTTP 세션을 설명하며 문득 든 생각들이 있었다.세션이 만료되면 사용자 입장에서는 어떻게 되는 걸까?세션을 너무 오래 유지하면 왜 문제가 될까?서버가 여러 대일 때, 세션을 어떻게 공유해야 할까?이번 글에서는 이 세 가지 질문을 중심으로내가 공부하고 이해한 내용을 정리해봤다.  1.  세션이 만료되면 사용자에게 어떤 경험이 될까?세션은 일반적으로 사용자가 일정 시간 동안 아무 요청도 하지 않으면 자동으로 만료된다.Spring Boot 기본 세션 유효 시간은 30분이다.내가 겪은 문제사용자가 로그인하고 사이트를 켜둔 채 30분 넘게 아무 행동을 하지 않으면,다시 페이지를 이동할 때 로그인이 풀려버리는 현상이 발생했다.사용자 입장에서는 갑자기 로그인이 해제..

처음 백엔드 공부를 시작했을 때는 HTTP를 그냥 “요청 보내고 응답 받는 프로토콜” 정도로 이해했다.URL에 GET, POST가 붙는다는 건 알았지만,왜 때로는 요청이 실패하고, 어떤 구조로 데이터가 전달되며,세션이 왜 필요한지를 깊게 고민해 본 적은 없었다. 하지만 프로젝트를 하면서 클라이언트와 백엔드 사이의 흐름이 막히거나 꼬일 때마다“이건 결국 HTTP 구조를 제대로 이해하지 못해서 생긴 문제다”라는 걸 자주 느꼈다. 그래서 이번엔 단순 개념 암기가 아닌,“왜 이런 구조를 가졌을까?”,“실제 프로젝트에서 발생하는 HTTP 문제를 어떻게 대처할 것인가?” 를 중심으로 HTTP를 다시 들여다봤다.  HTTP는 상태를 기억하지 못한다HTTP는 stateless, 즉 상태를 기억하지 못하는 프로토콜이다...