본문 바로가기

분류 전체보기120

서버는 살아있는데 서비스가 느릴 때 확인 순서 7단계: 운영 장애를 빠르게 진단하는 실무 가이드 서버는 살아있는데 서비스가 느릴 때 확인 순서 7단계운영 중인 서버가 다운되지는 않았는데, 사용자만 느리다고 말할 때가 있다.헬스체크는 통과하고, 프로세스도 살아 있고, 에러 로그도 조용하다.이런 상황에서 가장 위험한 대응은 감으로 추측하며 여기저기 설정을 바꾸는 것이다.성능 문제는 반드시 순서가 있고, 그 순서를 지키지 않으면 원인을 놓치기 쉽다.이 글에서는 실제 운영 환경에서 사용하는 방식 그대로,“서버는 살아있는데 서비스가 느릴 때” 확인해야 할 7단계 진단 순서를 정리한다.1단계. 정말 ‘느린’ 것이 맞는지부터 확인한다첫 단계는 기술이 아니라 현상 정의다.느리다는 말은 상황에 따라 의미가 다르다.모든 요청이 느린가?특정 API만 느린가?특정 시간대에만 느린가?이 단계에서 반드시 확인해야 할 것은 .. 2026. 1. 8.
DB튜닝, 데이터베이스성능, SQL튜닝, 실행계획, 인덱스설계, 백엔드개발, 서버성능개선, 장애예방, 실무DB, PostgreSQL DB 튜닝 방법 총정리: 실무에서 바로 쓰는 데이터베이스 성능 개선 가이드데이터베이스 튜닝은 흔히 “어렵다”, “나중에 전문가가 하는 영역”이라고 생각하기 쉽습니다. 하지만 실무에서 발생하는 대부분의 성능 문제는 복잡한 알고리즘이 아니라 기본적인 튜닝 원칙 미적용에서 시작됩니다.이 글에서는 특정 DB 제품에 종속되지 않고, Oracle, PostgreSQL, MySQL 모두에 공통으로 적용되는 DB 튜닝 사고방식을 실제 운영 환경 기준으로 정리합니다. 1. DB 튜닝은 어디서 시작해야 할까?DB 튜닝은 무작정 인덱스를 추가하거나 메모리를 늘리는 작업이 아닙니다. 반드시 다음 순서로 접근해야 합니다.① 느린 구간이 어디인지 확인② SQL 자체 문제인지, 인덱스 문제인지 판단③ 실행계획을 통해 실제 동작 방.. 2025. 12. 28.
오라클 SQL을 PostgreSQL로 바꾸는 규칙 20가지: NVL·DECODE·ROWNUM·MERGE까지 한 번에 서론: “문법만 바꾸면 되겠지”가 가장 위험한 착각오라클에서 PostgreSQL로 DB를 옮길 때, 가장 먼저 마주치는 벽은 SQL이다.겉으로는 비슷해 보여도 함수, NULL 처리, 페이징, UPSERT, 날짜/타임존까지작은 차이가 쌓이면 결과가 달라지고, 그게 운영 장애로 이어진다.이 글은 실무에서 가장 많이 부딪히는 변환 포인트를 규칙 20가지로 정리했다.NVL/DECODE/ROWNUM/MERGE 같은 대표 케이스는 물론,GROUP BY, 문자열/날짜 함수, outer join 구문까지 한 번에 정리한다.목표는 단순하다.“오라클 쿼리를 보고, PostgreSQL로 즉시 치환할 수 있는 수준”이다. 규칙 1) NVL → COALESCE오라클의 NVL(a, b)는 NULL이면 b로 치환한다.Postgre.. 2025. 12. 21.
오라클 DB를 PostgreSQL로 마이그레이션하는 절차: 무중단 전환까지 실무 체크리스트 서론: 오라클 → PostgreSQL 전환은 “DB 교체”가 아니라 “시스템 이식”이다오라클을 PostgreSQL로 바꾸는 작업은 단순히 데이터 덤프를 떠서 넣는 수준이 아니다.스키마, SQL, 트랜잭션, 인덱스, 배치, 운영 도구까지 모두 영향을 받는다.특히 운영 시스템이라면 “언제 어떻게 끊김 없이 바꿀 것인지”가 핵심이다.이 글에서는 실무에서 가장 많이 쓰는 방식으로사전 분석 → 변환 → 이관 → 검증 → 전환(컷오버) → 안정화 절차를 정리한다.※ 대규모 시스템 기준으로 작성했으며, 소규모 시스템도 이 체크리스트를 축약해 적용하면 된다. 1) 마이그레이션 방식 3가지 중 무엇을 택할까?먼저 전환 목표(RTO/RPO)와 서비스 중단 허용 시간을 확정해야 한다.그에 따라 방식이 갈린다.방식 A. 오프.. 2025. 12. 20.
장애를 재현하는 법: 의도적으로 장애를 만들어 원인 추적하기 (실무 트러블슈팅 가이드) 서론: 장애는 ‘운’이 아니라 ‘재현 가능한 사건’이다운영을 해본 사람이라면 이런 말을 한 번쯤 들어봤을 것이다.“어제 분명히 장애가 있었는데, 지금은 괜찮네요.”이 말이 의미하는 바는 단순하다.장애를 재현하지 못하면, 원인도 해결도 없다.실무에서 진짜 문제는 장애 그 자체가 아니라,왜 발생했는지를 끝까지 추적하지 못하는 것이다.이 글에서는 실제 운영 환경에서 사용하는 방식 그대로,의도적으로 장애를 만들어 원인을 추적하는 방법을 단계별로 정리한다.1. 왜 장애는 재현해야 하는가?장애 대응이 실패하는 가장 흔한 이유는 다음 중 하나다.로그가 남아 있지 않다지표를 보지 않았다“추정”으로 원인을 결론지었다재현 없는 분석은 추측에 불과하다.재현 가능한 장애만이 검증 가능한 해결책을 만든다.그래서 숙련된 운영자일.. 2025. 12. 17.
Nginx 무중단 배포 완전 가이드: Blue-Green·Canary·graceful reload로 서비스 끊김 없이 배포하기 서론: 왜 무중단 배포가 필수가 되었을까?운영 중인 서비스를 한 번이라도 내려본 경험이 있다면, "점검 시간입니다"라는 공지가 얼마나 큰 리스크인지 잘 알고 있을 것이다.사용자는 더 이상 기다려주지 않는다. 특히 API 서버, 인증 서버, 결제 시스템에서는 단 몇 초의 중단도 장애로 이어진다.이 글에서는 Nginx를 활용해 서비스 중단 없이 배포하는 실전 전략을 정리한다.Blue-Green, Canary, 그리고 반드시 알아야 할 graceful reload까지 운영 환경에서 바로 적용 가능한 구성만 다룬다. 1. 무중단 배포의 핵심 원리무중단 배포의 본질은 단순하다.“기존 요청은 끝까지 처리하고, 새 요청만 새로운 버전으로 보낸다”이를 위해 필요한 조건은 다음 세 가지다.로드밸런싱 또는 리버스 프록시 .. 2025. 12. 15.

티스토리툴바