Sean kim의 생활 이야기

여정의 시작

IT 분야에서 시스템 엔지니어로 시작한 내 첫 프로젝트는 PostgreSQL이 메인 DB인 은행 시스템이었다. 이 프로젝트에서 맺은 인연을 통해 PostgreSQL 엔지니어로 일하게 되었고, 지금까지 약 6년간 이 분야에서 일하고 있습니다. SSG의 PostgreSQL 담당 엔지니어였던 것이 인연이 되어 그 이후로 계속해서 이커머스 분야에서 DBA로 경험을 쌓고 있습니다.

전문가로서의 보람

PostgreSQL 엔지니어로서 가장 큰 보람은 다양한 고객과 개발자들이 필요로 하는 부분을 대화를 통해 풀어내고, 이를 운영에 성공적으로 적용했을 때입니다. 또한 처음 보는 시스템에서 문제를 진단하고 해결해 나가는 과정도 엔지니어로서 큰 성취감을 줍니다.

한국에서는 아직 PostgreSQL에 대해 깊이 이해하는 전문가가 많지 않기 때문에, 내가 가진 지식이 더욱 가치 있게 활용되고 있으며, 특히 쿼리 분석, 데이터베이스 파라미터 최적화, generic/custom plan 활용, 파티셔닝 같은 경험이 업무에서 큰 도움이 되고 있습니다.

PostgreSQL의 장단점

장점

1. 뛰어난 확장성: 복잡한 데이터 타입, 사용자 정의 함수를 통해 다양한 요구사항을 충족시킬 수 있다.
2. 풍부한 확장 기능(Extension): pg_prewarm, vector, PostGIS 같은 다양한 확장 모듈을 통해 특화된 기능을 쉽게 추가할 수 있다. 인공지능, 지리정보, 성능 최적화 등 다양한 분야의 요구사항을 충족시킬 수 있다.
3. 활발한 오픈소스 커뮤니티: 지속적인 개선과 버그 수정이 이루어지며, 사용자가 직접 버그 리포팅(oracle_fdw 등)을 통해 기여할 수 있다.
4. 비용 효율성: 상용 데이터베이스에 비해 라이센스 비용 없이 엔터프라이즈급 기능을 제공한다. 특히 오라클과 비교했을 때 비용 차이는 막대하다. 최근 경험에 따르면 8코어 오라클 시스템 구축에 몇억 원의 비용이 들고, 유지보수 비용만 해도 매년 초기 도입 비용의 22%에 달한다. PostgreSQL은 이러한 비용 부담 없이 고성능 데이터베이스 환경을 구축할 수 있다.

단점

1. 프로세스 기반 아키텍처: 각 연결마다 별도의 프로세스를 생성하기 때문에 커넥션 풀 사용이 필수적이다. 이는 메모리 사용량 증가로 이어질 수 있다.
2. 상대적으로 복잡한 설정: 많은 튜닝 파라미터와 옵션이 있어 초기 설정과 최적화에 전문 지식이 요구된다.
3. 리소스 관리의 어려움: 워크로드 분산과 리소스 격리가 상용 DB보다 세밀하게 제어하기 어려울 수 있다.

클라우드와 PostgreSQL

최근에는 AWS Aurora PostgreSQL과 같은 관리형 서비스를 중심으로 업무가 이루어지고 있다. 전통적인 설치형 방식에서 클라우드 네이티브 환경으로 전환되면서 운영 방식도 많이 달라졌지만, 기본적인 PostgreSQL 지식은 여전히 중요한 자산이 되고 있습니다.

마무리

한국에서도 PostgreSQL 사용이 점차 증가하고 있는 추세이며 클라우드 환경의 확산, 오픈소스에 대한 인식 변화, 비용 효율성 등이 주요 요인으로 작용하고 있습니다. 이에 따라 PostgreSQL 전문가에 대한 수요도 함께 높아지고 있다고 생각합니다. 매 10월마다  나오는 메이저 버전 릴리즈 마다 계속해서 신기능이 릴리즈되며 말 그대로 업그레이드 되는 PostgreSQL의 꾸준함이 최대 장점이라고 생각 합니다. PostgreSQL 10 버전부터 접해 보았는데, 현재 17버전까지 릴리즈 되었으며, 이후의 6년이 어떨지 너무 기대되는 오픈소스 DBMS 입니다.

Orphaned 파일이란 무엇인가?

PostgreSQL의 내부 구조에서, 데이터베이스 객체(테이블, 인덱스 등)는 파일 시스템의 파일로 저장됩니다. 'Orphaned 파일'은 시스템 카탈로그에서는 참조되지 않지만 디스크에는 여전히 존재하는 파일을 의미합니다. 이런 파일들은 다양한 데이터베이스 작업 중에 생성될 수 있습니다.

Orphaned 파일이 발생하는 원인

Orphaned 파일은 주로 다음과 같은 상황에서 발생합니다:

1. 트랜잭션 중단: 파일을 생성하는 트랜잭션이 완료되기 전에 중단된 경우
2. 비정상 종료: 데이터베이스가 비정상적으로 종료될 때
3. DDL 작업: 대규모 테이블 변경이나 재구성 작업 중 문제 발생 시
4. VACUUM FULL: 테이블 재구성 중 새 버전을 만든 후 이전 버전이 완전히 제거되지 않은 경우

PostgreSQL의 트랜잭션 관리 시스템은 PostgreSQL의 액세스 방법에서 설명되는 것처럼, 파일 생성과 시스템 카탈로그 업데이트를 별도의 작업으로 처리합니다. 이 때문에 파일은 생성되었지만 카탈로그 업데이트가 완료되지 않은 상태로 남을 수 있습니다.

Aurora에서 Orphaned 파일 문제의 심각성

Aurora PostgreSQL과 같은 클라우드 관리형 데이터베이스에서는 orphaned 파일 문제가 특히 중요합니다:

1. 비용 증가: Aurora는 사용된 스토리지 볼륨에 따라 비용이 청구되므로, 불필요한 orphaned 파일은 직접적인 비용 증가로 이어집니다.
2. 효율성 저하: 대량의 orphaned 파일은 백업 작업, 스냅샷 생성, 스토리지 할당 등에 부정적 영향을 미칠 수 있습니다.
3. 공간 관리 복잡성: Aurora의 스토리지 자동 확장 기능으로 인해 orphaned 파일이 자동으로 스토리지 확장을 유발할 수 있습니다.

Orphaned 파일 진단 방법

Aurora PostgreSQL에서 orphaned 파일을 식별하기 위한 주요 방법은 다음과 같습니다:

1. Aurora 스토리지 파일과 PostgreSQL 카탈로그 비교

SELECT aurora.*, pg_class.*
FROM (SELECT filename as aurora_filename,
             split_part(filename,'/',2) as aurora_dboid,
             split_part(filename,'/',3) as aurora_relfilenode,
             pg_size_pretty(allocated_bytes) as aurora_allocated,
             pg_size_pretty(used_bytes) as aurora_used
      FROM aurora_stat_file()
      WHERE split_part(filename,'/',2)::text in (SELECT oid::text
                                                FROM pg_database
                                                WHERE datname = current_database())
      AND (split_part(filename,'/',3) ~ '^[0-9]+$' or split_part(filename,'.',2) ~ '^[0-9]+$')
     ) aurora
LEFT JOIN
     (SELECT c.relfilenode as pg_class_relfilenode,
             pg_relation_filenode(c.oid) as pg_class_pg_relation_filenode,
             nspname AS pg_class_schema,
             relname as pg_class_relname,
             CASE
                WHEN c.relkind='i' then 'index'
                WHEN c.relkind='t' then 'toast'
                WHEN c.relkind='r' then 'table'
                WHEN c.relkind='v' then 'view'
                WHEN c.relkind='c' then 'composite type'
                WHEN c.relkind='S' then 'sequence'
                ELSE c.relkind::text
             END as "pg_class_type",
             pg_size_pretty(pg_relation_size(c.oid)) as pg_class_size
      FROM pg_class c
      LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
      WHERE relkind IN ('r','i','m','t')
     ) pg_class
ON split_part(aurora.aurora_relfilenode,'.',1)::int = pg_class.pg_class_pg_relation_filenode::int
WHERE pg_class.pg_class_relfilenode is NULL
ORDER BY aurora_filename;

이 쿼리는 Aurora의 물리적 스토리지 파일과 PostgreSQL의 시스템 카탈로그를 비교하여, 카탈로그에 존재하지 않는 파일(즉, orphaned 파일)을 식별합니다.

2. 할당된 공간과 실제 사용 공간 비교

SELECT pg_size_pretty(sum(allocated_bytes)), pg_size_pretty(sum(used_bytes)) 
FROM aurora_stat_file() 
WHERE filename like 'base%';

이 쿼리는 Aurora에서 할당된 총 스토리지 공간과 실제 사용 중인 공간을 비교합니다. 큰 차이가 있다면 orphaned 파일이 존재할 가능성이 높습니다.

실제 예시 결과:

 pg_size_pretty │ pg_size_pretty
────────────────┼────────────────
 18 GB          │ 9511 MB
(1 row)

위 결과에서 볼 수 있듯이, 할당된 공간(18GB)과 실제 사용 중인 공간(9511MB ≈ 9.3GB) 사이에 약 8.7GB의 차이가 있습니다. 이는 상당한 양의 orphaned 파일이 존재하고 있음을 시사합니다.

3. 데이터베이스 크기와 실제 테이블 크기 비교

SELECT database_name, pg_size_pretty(total_DB_size_bytes) AS total_DB_file_size,
       pg_size_pretty(real_tables_size_bytes) AS real_tables_size,
       pg_size_pretty(total_db_size_bytes-real_tables_size_bytes) AS difference,
       (total_db_size_bytes-real_tables_size_bytes) AS difference_bytes
FROM (SELECT current_database() as database_name,
             pg_database_size(current_database()) AS total_DB_size_bytes,
             sum(pg_relation_size(oid)) AS real_tables_size_bytes
      FROM pg_class) s;

이 쿼리는 데이터베이스의 총 크기와 실제 테이블들의 크기를 비교합니다. 차이가 크다면 불필요한 공간이 있을 수 있으며, 이는 orphaned 파일 때문일 수 있습니다.

Orphaned 파일 관리 전략

1. 정기적인 모니터링 및 진단

위의 진단 쿼리를 정기적으로 실행하여 orphaned 파일 상태를 모니터링합니다. 이를 통해 문제가 심각해지기 전에 조기에 발견할 수 있습니다.

2. VACUUM FULL 및 CLUSTER 활용

VACUUM FULL table_name;
CLUSTER table_name USING index_name;

이러한 명령은 테이블을 완전히 재구성하고 불필요한 공간을 회수할 수 있습니다. 하지만 테이블이 클 경우 실행 시간이 길어질 수 있으므로 주의가 필요합니다.

3. AWS 지원 티켓 제출

Aurora PostgreSQL에서 대규모 orphaned 파일 문제가 발견된 경우, AWS 내부 팀에 지원 티켓을 제출하여 용량 정리를 요청해야 합니다. AWS의 관리형 서비스 특성상, 일부 저수준 스토리지 정리 작업은 사용자가 직접 수행할 수 없으며 AWS 지원팀의 도움이 필요합니다.

티켓 제출 시 다음 정보를 포함하는 것이 좋습니다:

• Aurora 클러스터 식별자
• 진단 쿼리 결과 (할당된 공간과 사용 중인 공간의 차이)
• 문제가 되는 데이터베이스 이름
• orphaned 파일로 인한 영향 (비용 증가, 성능 저하 등)

4. 자동화된 관리 스크립트 개발

주기적으로 orphaned 파일을 감지하고 필요시 AWS 지원팀에 알리는 자동화된 스크립트를 개발하여 DBA 작업을 간소화할 수 있습니다. 이 스크립트는 위의 진단 쿼리를 실행하고 결과에 따라 적절한 조치를 취할 수 있습니다.

결론

Aurora PostgreSQL에서 orphaned 파일 관리는 비용 효율성과 성능 최적화를 위해 중요한 요소입니다. 효과적인 모니터링과 관리 전략을 통해 불필요한 스토리지 비용을 절감하고 데이터베이스 성능을 유지할 수 있습니다. 위 예시에서 볼 수 있듯이, 할당된 공간과 실제 사용 공간 사이에 큰 차이(18GB vs 9.5GB)가 있을 수 있으며, 이는 상당한 비용 낭비로 이어질 수 있습니다.

Aurora의 스토리지 비용 모델을 고려할 때, orphaned 파일로 인한 추가 비용을 최소화하는 것은 특히 중요한 최적화 지점입니다. 정기적인 모니터링과 필요 시 AWS 지원팀과의 협력을 통해 orphaned 파일 문제를 효과적으로 관리할 수 있습니다.

지난 6개월간 우리 팀은 Querypie를 실무에 적용해보았습니다. 처음엔 웹 기반의 접근성과 깔끔한 UI에 반해 도입했지만, 실제 업무 환경에서 몇 가지 짜증나는 문제들과 마주쳤습니다. 이 리뷰는 Querypie 개발팀이 좀 더 핵심 기능에 집중하길 바라는 마음과, 다른 기업들이 도입 시 겪을 수 있는 문제점들을 공유하기 위해 작성했습니다.

분명한 장점들

Querypie가 매력적인 이유는 확실히 있습니다. 일단 웹 기반이라 별도 설치 없이 브라우저만으로 접속 가능한 점이 정말 편리했어요. 재택근무와 사무실을 오가며 작업할 때도 어디서든 똑같은 환경으로 DB 작업을 할 수 있었죠.

UI도 깔끔하고 직관적이에요. 데이터베이스 구조를 한눈에 파악하기 좋고, 다크 모드 지원도 눈의 피로를 줄여줍니다. 특히 MySQL 환경에선 대체로 안정적으로 동작했고, 테이블 구조 시각화나 기본적인 데이터 관리 기능들이 잘 구현되어 있었습니다.

실제 사용에서 마주친 한계

하지만 실제 업무 환경, 특히 다양한 DB 엔진을 사용하는 환경에서는 꽤 실망스러운 경험을 했습니다.

가장 큰 문제는 MySQL 외 다른 DB 엔진 지원이 매우 부실하다는 점입니다. Oracle을 사용할 때는 웹 버전에서 프로시저나 패키지 같은 객체 정보가 거의 없어서 답답했습니다. "지원합니다"라고 말하기엔 너무 기본적인 기능들이 빠져있어요.

PostgreSQL도 비슷한 문제가 있었는데, 특정 information schema 조회가 안 되는 버그가 아직도 해결되지 않았습니다. 이런 문제들 때문에 결국 다른 도구를 병행해서 써야 했죠.

권한 관리도 심각한 문제였습니다. 설정해놓은 권한이 제대로 적용되지 않거나 일관되지 않게 작동해서 팀 작업 시 여러 번 당황했습니다.

그리고 가장 치명적이었던 건, 우리 회사처럼 프록시를 사용해야 하는 환경에서는 Querypie가 자랑하던 row 수 제한 기능이 전혀 작동하지 않는다는 점이었어요.

워크플로우 사용할 때도 Oracle 패키지 반영 같은 작업에서 가끔 문법 오류로 실패하는 경우가 있어서, 중요한 자동화 작업은 결국 다른 방식으로 처리하게 되었습니다.

도입 전 꼭 확인하세요

만약 여러분 회사에서 Querypie 도입을 고려하고 계시다면, 꼭 아래 사항들을 체크해보세요:

1. 프록시 기능 사용을 고려하시나요? 그렇다면 row 제한 정책이 작동하지 않는 문제를 감수할 수 있는지 생각해보세요. 대용량 데이터를 다루는 환경이라면 보안적인 문제가 될지 미리 테스트해보는 걸 권장합니다.
2. Oracle이나 PostgreSQL을 주로 사용하나요? 그렇다면 쿼리파이 WEB에서 필요한 모든 객체 정보와 뷰 조회가 제대로 되는지 꼼꼼히 확인하세요. 기본적인 기능들이 안 될 수도 있습니다.
3. 워크플로우 사용을 계획 중인가요? 특히 Oracle 패키지 변경 작업이 포함된다면, 실제 환경에서 몇 번 테스트해보세요. 예상치 못한 문법 오류로 실패할 수 있습니다.

개선을 바라며

솔직히 말하면, Querypie는 꽤 좋은 제품입니다. 다만 최근 새로운 기능 추가에만 급급한 나머지 기본적인 부분에 대한 지원이 많이 부족합니다. 보안 프로그램으로써 화려한 새 기능보다는 이미 약속한 기능들이 제대로 동작하는 게 우선이라고 생각합니다.

개발팀에게 바라는 점은:

1. Oracle, PostgreSQL 등 다른 DB 엔진 지원을 제대로 해주세요
2. 권한 관리 시스템을 근본적으로 개선해주세요
3. 프록시 환경에서도 row 제한 기능이 작동하게 해주세요
4. 기존 버그들을 새 기능보다 우선적으로 수정해주세요

결국 좋은 DB 도구란 화려한 것보다 안정적이고 신뢰할 수 있어야 한다고 생각합니다. Querypie가 기본에 충실한 도구로 발전하길 진심으로 바랍니다.

서론

최근 HP ZBook Ultra G1a 노트북의 저장 공간을 확장하기 위해 기존 SSD를 2TB 모델로 교체했습니다. 하지만 SSD 클로닝 작업 후 예상치 못한 문제에 직면했죠. 노트북이 부팅되지 않고 "Reset System"이라는 메시지가 화면 왼쪽 상단에 계속 깜빡이면서 BIOS 단계에서 무한 재부팅되는 현상이 발생했습니다. 이 문제를 해결하는 과정에서 얻은 경험을 공유하고자 합니다.

문제 분석

문제 증상 설명

• 노트북 부팅 시도 시 화면 왼쪽 상단에 "Reset System" 메시지가 순간적으로 나타남
• BIOS 화면으로 진입한 후 다시 재부팅되는 과정이 무한 반복
• BIOS 설정에서는 2TB SSD가 정상적으로 인식됨
• 놀랍게도 기존 SSD로 다시 교체하여 부팅을 시도했을 때도 동일한 문제가 지속됨

의심되는 원인

문제의 원인을 추적해보니, SSD 클로닝 작업 전에 Ubuntu 듀얼부팅을 구현하기 위해 boot 영역을 수정했던 것이 주요 원인으로 추정되었습니다. 특히 기존 SSD에서도 동일한 문제가 발생한 것을 보면, 부트 영역의 변경이 BIOS 수준에서 영향을 미쳤거나 부트 설정 자체가 손상된 것으로 보입니다.

해결 방법

Windows 설치 USB 준비

1. 다른 컴퓨터에서 Windows 설치 미디어 생성 도구를 사용하여 USB 부팅 디스크 제작
2. HP ZBook Ultra G1a의 BIOS에서 부팅 순서를 USB 우선으로 변경

복구 절차

1. Windows 설치 USB로 부팅
2. 설치 화면이 나타나면 '컴퓨터 복구' 옵션 선택
3. 복구 과정에서 "복구 실패" 메시지가 표시됨
4. 놀랍게도 이후 노트북이 정상적으로 부팅됨

흥미로운 점은 시스템이 복구에 실패했다는 메시지를 표시했음에도 불구하고, 이 과정 이후로 부팅 문제가 완전히 해결되었다는 것입니다. 아마도 Windows 복구 도구가 부트 영역을 자동으로 수정하거나 BIOS와의 연결을 재설정하는 과정에서 문제가 자연스럽게 해결된 것 같습니다.

교훈과 예방책

이번 경험을 통해 몇 가지 중요한 교훈을 얻었습니다:

1. Windows 설치 USB 사전 준비: SSD 업그레이드나 시스템 변경 작업을 시작하기 전에 반드시 Windows 설치 USB를 미리 만들어두어야 합니다. 부팅 문제가 발생한 후에는 다른 컴퓨터가 없으면 USB를 만들기 어려울 수 있습니다.
2. 듀얼부팅 설정 전 백업의 중요성: 부트 영역을 수정하기 전에 반드시 시스템 이미지 백업을 생성해야 합니다.
3. SSD 클로닝 시 주의사항: 클로닝 전에 부트 영역이 수정된 경우, 단순 클로닝만으로는 부팅 문제가 발생할 수 있습니다.
4. BIOS 설정 확인: SSD 교체 후 BIOS가 새로운 하드웨어를 정상적으로 인식하는지 확인하고, 필요한 경우 부팅 설정을 재조정해야 합니다.

결론

HP ZBook Ultra G1a의 SSD 업그레이드 과정에서 발생한 "Reset System" 무한 부팅 문제는 의외로 간단한 Windows 복구 시도만으로 해결되었습니다. 비록 복구 도구가 실패 메시지를 표시했지만, 이 과정이 문제를 해결하는 데 충분했습니다. 더욱이 이 문제는 새 SSD뿐만 아니라 기존 SSD에서도 동일하게 발생했던 것으로 보아, 부트 설정 자체의 문제였음을 알 수 있습니다.

여러분도 유사한 문제를 경험하셨다면, 먼저 Windows 복구 도구를 시도해보시길 권장합니다. 또한 SSD 업그레이드나 듀얼부팅 설정 시 겪은 경험이 있으시다면 댓글로 공유해주시면 감사하겠습니다.

자신을 버린 적 있는 사람을 무람없이 다시 사랑할 수 없는 것처럼, 그녀가 삶을 다시 사랑하는 일은 그때마다 길고 복잡한 과정을 필요로 했다.

왜냐하면, 당신은 언젠가 반드시 나를 버릴 테니까.
내가 가장 약하고 도움이 필요할 때,
돌이킬 수 없이 서늘하게 등을 돌릴 테니까.
그걸 나는 투명하게 알고 있으니까.
그걸 알기 전으로 돌아갈 수 없게 되었으니까.

삶이 항상 좋은 것은 아니나, 우리는 항상 삶으로 돌아간다. 

하지만 이 책의 한 구절처럼 그것이 항상 쉬운 것은 아니다.

그럼에도 우리는 돌아간다 

DJI Pocket 3로 촬영하였습니다.

운전해서 지리산 국립공원에 가면 노고단까지 약 2시간 정도면 도착 합니다.(길은 잘 되어 있으나 약간 경사 있음)

연휴나 주말에는 주차를 위해 오래 대기해야 할 수 있으니 아침 일찍 이동하는 것이 좋습니다.