벼락치기 개발공부

🚨 PostgreSQL WAL 1.8TB 폭증 + Archive Storage Full 장애 대응기

운영 환경에서 대규모 마이그레이션 작업을 진행하던 중 예상하지 못한 상황을 경험했습니다. DB 전체 스토리지는 약 7TB였고 실제 데이터는 약 5.6TB 수준이었습니다.표면적으로 보면 여유가 있는 상황이었지만, 어느 순간 WAL 사용량이 급격히 증가하여 pg_wal 영역이 1.8TB까지 커지는 상태가 발생했습니다. 확인해보니 archive storage 3TB가 이미 100% 가득 찬 상태였고,그 영향으로 WAL이 정상적으로 정리되지 못하고 계속 쌓이고 있었습니다. DB는 즉시 다운되지는 않았지만조금만 더 진행되었다면 실제 서비스 쓰기 장애로 이어질 수 있는 매우 위험한 상황이었습니다.이번 글에서는 이 상황이 왜 발생했는지, 실제로 어떤 위험이 있었는지, 그리고 어떻게 해결했는지까지 운영 경험 기반으로 ..

데이터베이스를 사용하다 보면 자연스럽게 이런 궁금증이 생깁니다.“INSERT나 UPDATE를 하면 데이터는 바로 디스크에 저장되는 걸까?” 하는 질문인데요. 실제로 대부분의 RDBMS는 이런 방식으로 동작하지 않습니다.성능과 안정성을 동시에 확보하기 위해 데이터 변경은 먼저 메모리에서 처리하고, 변경 사실은 로그에 기록한 뒤 실제 디스크 반영은 이후 시점에 수행하는 구조를 사용합니다. 이번에 이러한 구조를 가진 RDBMS 의 디스크 활용법에 대해서 알아보겠습니다! 🚀 RDBMS는 데이터를 바로 디스크에 저장하지 않는다? Oracle, MySQL(InnoDB), PostgreSQL 같은 주요 RDBMS들은구현 방식이나 내부 명칭은 조금씩 다르지만이러한 메모리 기반 처리 + 로그 기반 안정성 확보 구조를..

이전 게시글인 Kafka Outbox 패턴으로 비동기 이벤트 발행하기 에서는데이터를 Outbox 테이블에 적재하고, 이를 기반으로 Kafka 이벤트를 안전하게 발행하는 구조를 정리해봤습니다. 이번에는 그 다음 단계로,Kafka로 발행된 이벤트를 어떻게 소비하면 좋을지,그리고 대용량 주문 환경에서도 안정적으로 조회하려면 어떤 구조가 좋을지를 정리해보려고 합니다. 이번 글에서는Elasticsearch, Redis, 그리고 Idempotency Lock을 활용해서주문 처리 흐름을 한 단계 더 확장해봤습니다!.전체 흐름 먼저 살펴보기이번에 정리해본 전체 데이터 흐름은 아래와 같습니다. PostgreSQL → Outbox Table → Kafka (order.created) → Kafka Consume..

비동기 처리 방식을 공부하면서 Kafka 통신 흐름을 로그를 통해 확인하면서동작 원리를 파악하는 과정에서 깨달음을 얻어 게시글을 작성합니다!Kafka 를 처음 사용하면서 저는 Kafka 로 이벤트를 발행할 때 이게 언제, 어디서, 어떤 흐름으로 실행되는건지 헷갈렸습니다.특히 Outbox 패턴을 적용하면 Kafka 발행 로직이 Controller 와 분리되기 때문에요청이 끝났음에도 Kafka 가 동작하는 것을 알 수 있는데요 이를 기반으로 아래 내용들을 정리해보겠습니다!HTTP 요청 처리 흐름Filter / Interceptor / Service의 역할Kafka Outbox 발행이 Controller와 분리되는 이유로그로 Kafka 통신을 확인하는 방법실무에서는 Outbox를 어떻게 활용하는지 1. 전체 ..

백엔드 개발을 하다 보면 이런 말을 자주 듣는다.“이건 비동기로 처리해야 해요”“Kafka로 이벤트 흘리면 됩니다”“MQ로 분리하세요”그런데 막상 물어보면👉 왜 비동기가 필요한지,👉 동기/비동기가 실제로 뭐가 다른지,👉 MQ와 Kafka가 왜 등장했는지명확하게 설명하기는 쉽지 않다.이 글에서는 아무 배경지식 없는 상태에서도 이해할 수 있도록비동기 처리의 등장 배경부터 차근차근 설명해보겠습니다!1. 우리가 처음 만드는 시스템은 전부 “동기 처리”다대부분의 웹 서비스는 이렇게 시작한다.클라이언트 요청 → 서버 처리 → 응답 이를 동기(Synchronous) 처리라고 한다. 예시: 주문 API주문 요청 → 결제 처리 → 재고 차감 → 주문 저장 → 알림 발송 → 응답 이 구조는 이해하기 쉽고, 구현도 단..

이전에 PostgreSQL HA 환경에서 장애가 발생했을 때, 이중화 환경 구성 중 Primary / Primary(P,P) 상태로 전환되며 성능 이슈가 발생한 경험을 공유합니다!이번 사례는 repmgr 기반 Streaming Replication 환경에서 발생하였으며, 최종적으로 repmgr clone 을 통해 정상적으로 북구했습니다. 1️⃣ 문제 상황운영 중이던 PostgreSQL HA 환경은 아래와 같은 구조였습니다.● Primary DB- Read / Write 모두 처리 ● Standby DB- Read 전용 처리 각각 두개의 DB 는 repmgr 기반 Streaming Replication 구성으로 되어있습니다.해당 환경은 PostgreSQL HA(High Availability) 구성을 ..

안녕하세요!오늘은 데이터베이스 업계의 '오픈소스 끝판왕'이라 불리는 PostgreSQL에 대해 깊이 있게 알아보려 합니다.제가 현재 다니고 있는 회사에서도 PostgreSQL 을 사용하는 중인데 여러가지 장점들이 소개하고자 게시글을 작성하게 되었습니다!단순히 유행이라서가 아니라, 왜 수많은 기업이 기존의 Oracle을 떠나 Postgres로 향하는지 그 이유를 명확히 짚어보겠습니다.1. PostgreSQL이란 무엇인가?PostgreSQL은 전통적인 관계형 DB(RDBMS)를 기반으로 하면서, 사용자 정의 타입·함수·확장 모듈을 지원하는 객체-관계형(ORDBMS) 특성을 함께 갖고 있습니다. 30년 이상의 역사를 가진 만큼 매우 안정적이며, 오픈소스임에도 불구하고 상용 DB인 Oracle에 버금가는 강력한..

솔루션 관련 게시글들을 찾아보다가 흥미로운 방식으로 문제를 해결한 내용을 찾아서 블로그 게시글로 정리해서 올려봅니다!1. 문제업무 시스템에서는 많은 파일들이 생성되고 엑셀, PDF, 정산 리포트, 통계 자료 등 다양한 산출물들이 매일같이 만들어지고 내려지는데요. 이런 파일들의 대부분은 보안 대상으로 취급됩니다.그렇기에 많은 시스템이 특정 보안 솔루션을 통해 파일을 암호화하거나 보호하게 됩니다. 하지만 보안 정책이 변경되는 순간부터 기존 방식의 수정해야될 부분들이 많아지는데요기존에는 설치형(에이전트 기반) 보안 솔루션을 사용하고 있지만 신규 클라우드 기반 보안 솔루션이 도입되었지만,모든 사용자들에게 동일한 보안 방식을 적용시킬 수 없었고 결국 하이브리드 상황을 맞이하게 됩니다. 특정 권한 - 신규 보안 방..

안녕하세요~ 이번에는 제가 Dockerfile 을 사용할 때 노가다를 해보면서 얻은 빌드 전략과 방식에 대해서 소개해드리겠습니다!먼저 Dockerfile 이란 빌드 자동화 도구이자 CI/CD 핵심 구성 요소 역할을 합니다.프로젝트가 커지고 빌드 대상이 많이질수록 Dockerfile 구조, 빌드 방식, 캐시 전략은 성능과 유지보수에 큰 영향을 줍니다. 이 글에서는 Dockerfile 을 효율적으로 작성하는 방법, 그리고 BuildKit 기반 고속 빌드 전략과 에러 이후 재빌드가 어떻게 동작하는지 까지 제가 실제로 겪었던 고충을 해결하는 방법을 정리하였습니다 📌 1. Dockerfile 빌드 구조의 기본 개념Dockerfile은 위에서 아래로 순차적으로 실행되며, 각 명령은 레이어(layer)를 형성합니다..

JPA를 사용하다 보면 같은 조건으로 조회하는데도 반환 타입에 따라 동작 방식이 달라지는 경우가 있습니다.특히 List, 단일 엔티티 반환(Member), 그리고 Optional 는 반환 결과가 완전히 다르기 때문에 정확히 이해하고 사용하는 것이 중요합니다.이번 글에서는 반환 타입의 차이를 코드와 함께 정리해보겠습니다.✔️ 1. 테스트 코드로 살펴보는 반환 결과@Testpublic void returnType(){ Member m1 = new Member("AAA", 10); Member m2 = new Member("AAA", 20); memberRepository.save(m1); memberRepository.save(m2); List aaa = memberReposito..