벼락치기 개발공부

제가 서비스를 운영하면서 직접 겪은 . . .primary 1대 + standby 3대 구성부터 upstream 변경, 그리고 장애 시 promote까지단순 이론 말고 실제 삽질하면서 경험한 내용을 정리해서 작성해보았습니다! 1️⃣ 4노드 HA 구성목표 구조기존 프로젝트에서는 primary 와 standby 로 구성된 ha 상태의 DB 서비스를 운영하고 있었습니다.이해를 돕기 위해 각각의 DB 01, 02, 03, 04 같이 순번을 붙혀 설명하겠습니다.db01 (primary) └─ db02 (standby) 그러던 중 DB 서버의 OS 업그래이드를 하게 되었습니다.In-place 업그레이드를 진행하면 라이브러리나 DB extension 이 깨질 수 있기 때문에DB를 먼저 Standby 로 복제를 떠서..

repo 설정파일 생성sudo vi /etc/yum.repos.d/centos8.repo 내용 입력[baseos]name=CentOS 8 BaseOSbaseurl=http://vault.centos.org/8.5.2111/BaseOS/x86_64/os/enabled=1gpgcheck=0[appstream]name=CentOS 8 AppStreambaseurl=http://vault.centos.org/8.5.2111/AppStream/x86_64/os/enabled=1gpgcheck=0 캐시 초기화sudo yum clean allsudo yum makecache

1. 문제 요약 (Summary)운영 환경에서 /usr/lib64 디렉토리를 변경한 이후, 다음과 같은 연쇄 장애가 발생했다.시스템 부팅 실패 (/sbin/init, /bin/sh 실행 불가)rescue 복구 이후 로그인 실패패키지 복구 시도 중 dnf DNS 오류 발생추가로 파일시스템이 read-only 상태로 전환이 장애는 단순 디렉토리 변경이 아니라,리눅스 런타임(동적 라이브러리), 인증(PAM), 네트워크(DNS), 파일시스템 계층까지 영향을 준 복합 장애였다. 2. 장애 흐름 (End-to-End Flow)/usr/lib64 변경 → 동적 라이브러리 로딩 실패 → init/systemd 실행 실패 → 부팅 중단rescue 모드에서 lib64 복구 → 부팅 가능 상태 복구로그인 실패 → PAM /..

운영 환경에서 대규모 마이그레이션 작업을 진행하던 중 예상하지 못한 상황을 경험했습니다. 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에 버금가는 강력한..