SKAI Worldwide Tech Blog

[이슈분석]AgensSQL 보안 기능 심층 분석: 암호화, 감사, 관리 요소를 중심으로

SKAI Worldwide | 스카이월드와이드 — Tue, 20 May 2025 10:40:03 +0900

서론

지난 포스팅에서 SK텔레콤 유심 해킹 사태를 통해 데이터베이스 수준 암호화의 중요성과 AgensSQL TDE의 적용 방안에 대해 살펴보았습니다. 이번 글에서는 AgensSQL의 다양한 보안 기능들을 더 깊이 살펴보고, 암호화, 감사, 데이터 관리 측면에서 엔터프라이즈급 보안을 구현하는 방법을 알아보겠습니다.

기업 데이터베이스 보안은 단순히 암호화만으로는 완벽하게 구현할 수 없습니다. 진정한 데이터 보안은 암호화, 접근 제어, 감사, 데이터 관리 등 여러 계층의 보안 요소가 유기적으로 결합되어야 합니다. AgensSQL은 PostgreSQL을 기반으로 이러한 엔터프라이즈급 보안 기능을 제공하여 데이터 보호의 전체 라이프사이클을 지원합니다.

1. AgensSQL의 암호화 기능

1.1 Transparent Data Encryption (TDE)

TDE는 데이터베이스 수준의 암호화를 제공하는 핵심 기술입니다. 이전 글에서 살펴본 바와 같이, TDE는 사용자 데이터를 투명하게 암호화하여 저장합니다.

주요 특징:

데이터 파일, WAL, 임시 파일의 포괄적 암호화
애플리케이션 코드 수정 없이 적용 가능
AES-128/256 기반 강력한 암호화 알고리즘 사용
외부 키 관리 시스템과의 통합 지원

TDE 고급 설정:

# 고급 암호화 방식으로 초기화
initdb -D /path/to/data --data-encryption --file-encryption-method=AES256

설정 결과

데이터 디렉토리 '/path/to/data'에 데이터베이스를 생성합니다.
데이터베이스 클러스터는 AES-256 암호화로 초기화됩니다.
암호화 키는 /path/to/data/pg_encryption/ 디렉토리에 생성됩니다.
초기화 완료! 다음 명령으로 서버를 시작할 수 있습니다:
  pg_ctl -D /path/to/data -l logfile start

1.2 AgensCrypto

AgensCrypto는 AgensSQL이 제공하는 강력한 확장 모듈로, 컬럼 수준의 세밀한 암호화와 다양한 암호화 함수를 제공합니다.

주요 기능:

다양한 암호화 알고리즘 지원 (AES, 3DES, ARIA 등)
컬럼 수준의 세밀한 암호화 옵션
해시 함수 (SHA-256, SHA-512 등)
암호화 키 관리 인터페이스

암호화 예시:

-- AgensCrypto 확장 모듈 설치
CREATE EXTENSION agenscrypto;

-- AES-256으로 컬럼 암호화
SELECT agenscrypto.encrypt_aes256('민감한 개인정보', '암호화키', 'cbc');

암호화 결과：

encrypt_aes256                            
---------------------------------------------------------------------
 \xd7e921c83267af8d89ef28d3b272d4f82dca931732b8c6d1be3347dbc4d7012a

이 암호화된 바이너리 데이터는 적절한 키 없이는 해독할 수 없습니다.

이를 복호화하려면:

-- 암호화된 데이터 복호화
SELECT agenscrypto.decrypt_aes256(
  '\xd7e921c83267af8d89ef28d3b272d4f82dca931732b8c6d1be3347dbc4d7012a', 
  '암호화키', 
  'cbc'
);

복호화 결과:

decrypt_aes256   
--------------------
 민감한 개인정보

AgensCrypto는 민감 데이터를 포함하는 특정 컬럼만 암호화하고자 할 때 특히 유용합니다.

TDE가 전체 데이터베이스를 암호화하는 반면, AgensCrypto는 특정 데이터에 대해 더 세밀한 제어를 제공합니다.

1.3 암호화 키 관리 전략

암호화의 핵심은 키 관리입니다.

AgensSQL은 다양한 키 관리 옵션을 제공합니다:

외부 키 관리 시스템 통합:

AWS KMS, Azure Key Vault, Google Cloud KMS 지원
Hardware Security Module (HSM) 연동
키 로테이션 자동화 지원

예시: AWS KMS와의 통합 결과

AWS KMS를 통한 키 관리 설정 후, 데이터베이스는 마스터 키를 통해 데이터 암호화 키를 보호합니다.

키 로테이션을 실행하면 다음과 같은 로그가 생성됩니다:

2025-05-21 14:30:22 UTC [12345]: 키 로테이션 시작
2025-05-21 14:30:23 UTC [12345]: 키 파일 백업 생성 - key.bin.20250521
2025-05-21 14:30:25 UTC [12345]: 새 마스터 키로 암호화 완료
2025-05-21 14:30:26 UTC [12345]: 키 로테이션 성공

이러한 키 관리 프로세스는 주기적으로 실행되어 키 탈취 위험을 최소화합니다.

2. 감사 및 로깅 기능

데이터베이스 보안에서 감사 기능은 보안 사고를 감지하고, 규제 준수를 입증하는 데 필수적입니다.

'AgensSQL은 강력한 감사 기능을 제공합니다.'

2.1 AgensSQL Audit Log

AgensSQL의 감사 기능은 데이터베이스 활동에 대한 상세한 기록을 제공합니다.

주요 기능:

SQL 쿼리 로깅
사용자 활동 추적
권한 변경 감사
객체 접근 모니터링
시스템 변경 사항 추적

설정 예시:

-- pgAudit 확장 모듈 설치
CREATE EXTENSION pgaudit;

-- 감사 로깅 수준 설정
ALTER SYSTEM SET pgaudit.log = 'read,write,ddl';

생성되는 감사 로그 예시:

2025-05-21 15:12:43.218 UTC [1234]: [3-1] user=admin,db=finance,app=psql,client=192.168.1.100 LOG: AUDIT: SESSION,1,1,DDL,CREATE TABLE,,,CREATE TABLE sensitive_data (id int, credit_card text),postgres,finance,,,,,,,
2025-05-21 15:13:01.452 UTC [1234]: [4-1] user=admin,db=finance,app=psql,client=192.168.1.100 LOG: AUDIT: SESSION,2,1,WRITE,INSERT,,,INSERT INTO sensitive_data VALUES (1, '1234-5678-9012-3456'),postgres,finance,,,,,,,
2025-05-21 15:14:22.631 UTC [1235]: [2-1] user=analyst,db=finance,app=psql,client=192.168.1.101 LOG: AUDIT: SESSION,3,1,READ,SELECT,,,SELECT * FROM sensitive_data,postgres,finance,,,,,,,

이러한 로그는 누가, 언제, 어떤 데이터에 접근했는지 추적할 수 있게 해주며, 보안 감사와 규제 준수에 필수적입니다.

2.2 고급 감사 기능과 실시간 모니터링

AgensSQL은 고급 감사 및 실시간 모니터링 기능을 제공합니다.

이상 접근 탐지 결과:

username  |     client_ip     | access_count |      first_access      |       last_access       
----------+-------------------+--------------+------------------------+------------------------
suspicious| 203.0.113.100     |    478       | 2025-05-21 09:15:32+00 | 2025-05-21 09:17:45+00
analyst   | 198.51.100.27     |    156       | 2025-05-21 10:22:17+00 | 2025-05-21 10:22:25+00

위 결과는 비정상적인 접근 패턴(짧은 시간 내 다수 접근)을 보여줍니다.

'suspicious' 사용자는 2분 13초 동안 478회 접근했으며, 'analyst' 사용자는 8초 동안 156회 접근했습니다. 이는 자동화된 공격이나 데이터 추출 시도를 나타낼 수 있습니다.

이러한 이상 징후가 감지되면 자동 알림을 통해 보안팀에 통보됩니다:

제목: [긴급] 데이터베이스 이상 접근 패턴 탐지됨
시간: 2025-05-21 09:18:01
사용자: suspicious
IP: 203.0.113.100
접근 횟수: 478회 (2분 13초 내)
대상 테이블: credentials, payment_info
조치: 해당 계정 자동 잠금됨

2.3 감사 데이터 분석 및 보고

감사 데이터 분석을 통해 생성된 일별 접근 통계 보고서는 다음과 같습니다.

일별 접근 통계:

access_date  | username |  action_type  | access_count 
---------------+----------+---------------+--------------
 2025-05-21    | admin    | SELECT        |    124
 2025-05-21    | admin    | INSERT        |     37
 2025-05-21    | admin    | UPDATE        |     15
 2025-05-21    | analyst  | SELECT        |    258
 2025-05-21    | support  | SELECT        |     92
 2025-05-20    | admin    | SELECT        |    118

이 통계를 통해 사용자별, 작업 유형별 접근 패턴을 분석할 수 있으며, 보안 정책 개선에 활용할 수 있습니다.

3. 데이터 관리 및 보안 기능

3.1 Data Redaction

Data Redaction은 민감한 데이터의 노출을 최소화하는 기술입니다. 사용자 권한에 따라 동일한 데이터에 대해 서로 다른 뷰를 제공합니다.

주요 기능:

데이터 마스킹: 민감 데이터 일부를 '*'와 같은 문자로 대체
데이터 익명화: 개인 식별 정보를 완전히 제거
가명화: 실제 데이터를 가명으로 대체하되 필요시 복원 가능

데이터 마스킹 구현 결과:

(관리자(DBA) 계정으로 조회 시)

customer_id |  customer_name  |  credit_card        |     phone      
------------+-----------------+---------------------+----------------
          1 | John Smith      | 1111-2222-3333-4444 | 010-1234-5678
          2 | Sarah Johnson   | 5555-6666-7777-8888 | 010-9876-5432

(일반 직원 계정으로 동일한 테이블 조회 시)

customer_id |  customer_name  |  credit_card        |     phone      
------------+-----------------+---------------------+----------------
          1 | John Smith      | 1111-XXXX-XXXX-4444 | 010-XXXX-5678
          2 | Sarah Johnson   | 5555-XXXX-XXXX-8888 | 010-XXXX-5432

이처럼 Data Redaction을 통해 같은 데이터베이스, 같은 테이블에 대해서도 사용자 권한에 따라 선택적으로 데이터를 마스킹하여 보여줄 수 있습니다.

3.2 Row-Level Security (RLS)

Row-Level Security는 테이블의 행 단위로 접근 제어를 적용하는 강력한 보안 기능입니다.

RLS 구현 결과:

(RLS 정책 적용 전 - 관리자 접근)

customer_id | customer_name | region  | sales_rep | account_balance
------------+--------------+---------+-----------+----------------
          1 | ABC Corp     | East    | alice     |       10250.75
          2 | XYZ Inc      | West    | bob       |       25340.50
          3 | Acme Ltd     | Central | alice     |        5120.25
          4 | Beta Corp    | East    | bob       |       15600.00

(영업담당자 'alice'로 접근 시)

customer_id | customer_name | region  | sales_rep | account_balance
------------+--------------+---------+-----------+----------------
          1 | ABC Corp     | East    | alice     |       10250.75
          3 | Acme Ltd     | Central | alice     |        5120.25

(영업담당자 'bob'으로 접근 시)

customer_id | customer_name | region  | sales_rep | account_balance
------------+--------------+---------+-----------+----------------
          2 | XYZ Inc      | West    | bob       |       25340.50
          4 | Beta Corp    | East    | bob       |       15600.00

RLS를 통해 각 영업 담당자는 자신이 담당하는 고객 데이터만 볼 수 있으며, 이는 DBMS 수준에서 자동으로 필터링됩니다.

이러한 보안 정책은 애플리케이션 로직과 독립적으로 작동하여 보안 일관성을 보장합니다.

3.3 데이터 분류 및 접근 제어

데이터 분류 체계를 구현하면, 관리자는 다음과 같은 대시보드를 통해 현재 데이터베이스의 민감도 수준을 한눈에 파악할 수 있습니다:

데이터 분류 대시보:

객체       |     컬럼명     | 민감도 수준  |   데이터 처리 요구사항   | 접근 권한 역할
------------------+---------------+-------------+-------------------------+----------------
customer_data     | customer_name | INTERNAL    | 기본 접근 제한           | data_internal
customer_data     | email         | INTERNAL    | 기본 접근 제한           | data_internal
customer_data     | credit_card   | RESTRICTED  | 암호화 및 마스킹 필수     | data_restricted
usim_auth.creds   | imsi_encrypted| RESTRICTED  | 암호화 필수              | data_restricted
payment_info      | card_number   | RESTRICTED  | 암호화 및 마스킹 필수     | data_restricted
payment_info      | cvv           | RESTRICTED  | 암호화 필수              | data_restricted

이러한 데이터 분류를 통해 조직은 데이터 자산의 중요도를 체계적으로 관리하고, 각 데이터 유형에 적합한 보안 조치를 취할 수 있습니다.

4. 통합 보안 아키텍처 구축

지금까지 살펴본 AgensSQL의 다양한 보안 기능을 통합하여 종합적인 보안 아키텍처를 구축할 수 있습니다.

4.1 다중 방어 계층 설계

보안 계층:

네트워크 보안: SSL/TLS, 클라이언트 인증서
사용자 인증: LDAP/Active Directory 통합, 다중 인증
접근 제어: 역할 기반 접근 제어, Row-Level Security
암호화: TDE, AgensCrypto를 통한 컬럼 암호화
데이터 관리: 데이터 분류, 마스킹, 익명화
감사 및 모니터링: 상세 로깅, 실시간 이상 탐지

4.2 보안 운영 관리

보안 정책 적용 상태를 모니터링한 결과 대시보드 예는 다음과 같습니다:

보안 정책 준수 상태:

테이블         | RLS 적용 | 감사 로깅 | 암호화 상태 | TDE 보호
------------------------+----------+-----------+------------+---------
public.customer_data    |   YES    |    YES    |  PARTIAL   |   YES
usim_auth.credentials   |   YES    |    YES    |  COMPLETE  |   YES
finance.payment_info    |   YES    |    YES    |  COMPLETE  |   YES
hr.employee_data        |   YES    |    YES    |  PARTIAL   |   YES
public.product_catalog  |    NO    |    YES    |    NONE    |   YES

이 대시보드는 각 테이블의 보안 설정 상태를 보여주며, 관리자는 이를 통해 보안 정책 준수 여부를 쉽게 확인할 수 있습니다.

자동화된 보안 점검 결과는 다음과 같습니다:

점검 항목        |  상태  |              세부 내용               
-----------------------+--------+--------------------------------------
TDE_ENABLED            |  PASS  | Transparent Data Encryption 활성화됨
UNUSED_ACCOUNTS        |  WARN  | 90일 이상 미사용 계정: 3개
UNENCRYPTED_SENSITIVE  |  FAIL  | 암호화 필요 민감 컬럼 중 미암호화: 2개
RLS_POLICIES           |  PASS  | 모든 민감 테이블에 RLS 정책 적용됨
LOGGING_CONFIGURATION  |  PASS  | 감사 로깅 적절히 설정됨
PASSWORD_POLICY        |  PASS  | 강력한 비밀번호 정책 적용됨

이러한 자동화된 점검을 통해 보안 위험 요소를 사전에 발견하고 조치할 수 있습니다.

5. 모범 사례 및 권장 사항

5.1 보안 설계 원칙

최소 권한 원칙: 사용자와 애플리케이션에 필요한 최소한의 권한만 부여
심층 방어: 여러 보안 계층을 통해 방어 강화
데이터 분류: 중요도에 따라 데이터 분류 및 보호 수준 결정
암호화 전략: 저장 데이터와 전송 데이터 모두 암호화
감사 및 모니터링: 지속적인 감사와 모니터링으로 이상 징후 포착

5.2 보안 구현 체크리스트

기본 보안	SSL/TLS 연결 강제 설정 강력한 인증 및 비밀번호 정책 적용 pg_hba.conf 파일 설정 최적화 불필요한 확장 모듈 및 기능 비활성화
암호화	TDE 활성화 및 설정 외부 키 관리 시스템 연동 민감 컬럼 AgensCrypto로 추가 암호화 정기적인 키 로테이션 자동화
접근 제어:	역할 기반 접근 제어 설정 Row-Level Security 적용 민감 테이블에 대한 접근 로깅 과도한 권한을 가진 계정 관리
감사 및 모니터링:	상세 로깅 설정 실시간 이상 탐지 알림 설정 정기적인 감사 보고서 생성 보안 정책 준수 검증

5.3 실제 구현 전략

단계적 접근	평가: 현재 데이터베이스의 보안 상태 평가 설계: 보안 요구사항에 맞는 아키텍처 설계 구현: 우선순위에 따라 단계적 구현 테스트: 보안 기능 테스트 및 영향 평가 모니터링: 지속적인 모니터링 및 개선
성능 고려	암호화 및 감사 로깅으로 인한 성능 영향 측정 워크로드에 따른 리소스 할당 최적화 성능 중요 영역에 대한 선택적 보안 조치 적용

결론

AgensSQL은 PostgreSQL의 강력한 기능을 기반으로 엔터프라이즈급 보안 기능을 제공합니다.

TDE, AgensCrypto, 감사 로깅, Data Redaction 등의 기능을 통해 다층적인 보안 아키텍처를 구축할 수 있습니다.

이러한 보안 기능들은 단순히 법적 규제 준수를 위한 것이 아닌, 조직의 데이터 자산을 실질적으로 보호하기 위한 필수 요소입니다.

SK텔레콤 유심 해킹 사태와 같은 사고는 데이터베이스 레벨에서의 암호화와 보안의 중요성을 다시 한번 일깨워줍니다.

조직의 데이터 보안 전략을 수립할 때는 단일 보안 기술에 의존하기보다는 AgensSQL이 제공하는 다양한 보안 기능을 조합하여 포괄적인 보안 체계를 구축하는 것이 중요합니다.

즉, 암호화, 접근 제어, 감사, 데이터 관리의 유기적인 결합을 통해 진정한 데이터 보안을 실현할 수 있을 것입니다.

[이슈분석]SK텔레콤 해킹 사태로 보는 데이터베이스 수준 암호화의 중요성

SKAI Worldwide | 스카이월드와이드 — Fri, 9 May 2025 13:54:07 +0900

USIM 데이터 암호화의 중요성(ChatGPT 생성 이미지)

사태 개요

SKT 부사장은 "네트워크 쪽은 암호화돼 있지 않은 부분이 많다"며 "데이터 인증을 할 때는 암호화를 하지만, 데이터로 저장된 상태에서는 암호화를 하지 않고 있다"고 2025년 4월 30일 국회 청문회에서 밝히며, SK텔레콤이 유심(USIM) 정보를 암호화하지 않은 상태로 관리했던 사실이 확인되었습니다. 따라서, 민감 정보들이 암호화가 되어있지 않은채 외부에 노출된 상황입니다.

개인정보의 데이터베이스 수준 암호화가 중요한 이유

휴대전화 가입자 정보 등 개인정보는 서비스 이용자의 디지털 신원증명 역할을 하는 민감한 정보입니다. 이러한 정보가 암호화되지 않은 상태로 저장되면 다음과 같은 위험이 발생할 수 있습니다:

개인 식별 정보 노출: 사용자를 특정할 수 있는 정보로, 개인정보 유출로 이어질 수 있습니다.
통신 도청 및 복제 위험: 인증키가 유출되면 통신 도청이나 유심 복제 등의 2차 피해가 발생할 수 있습니다.
법적 책임 발생: 개인정보 보호법 제29조는 개인정보처리자에게 분실, 도난, 유출, 위조, 변조, 훼손 등을 방지하기 위한 기술적, 관리적, 물리적 조치를 취할 것을 명시하고 있습니다. 물론, 개인정보 보호법 상 개인정보에 해당하는지 여부에 대해서는 다툼의 여지가 있지만, 광의적인 의미에서의 개인정보에는 포함된다는 여러 전문가의 의견이 있습니다.

AgensSQL의 TDE(Transparent Data Encryption)를 통한 해결책

AgensSQL은 Transparent Data Encryption(TDE) 기능을 통해 데이터베이스 수준에서 강력한 암호화 솔루션을 제공합니다. TDE는 사용자 데이터를 투명하게 암호화하여 저장함으로써, 데이터 파일이 유출되더라도 내용을 확인할 수 없게 만듭니다.

AgensSQL TDE의 주요 특징

포괄적인 암호화 범위: TDE는 테이블, 시퀀스, 인덱스, TOAST 테이블, 시스템 카탈로그를 포함한 데이터 파일과 WAL(Write-Ahead Log), 그리고 다양한 임시 파일을 암호화합니다.
강력한 암호화 알고리즘: TDE는 데이터 파일에 AES-128-XTS, WAL에 AES-128-CTR, 임시 파일에 AES-128-XTS 또는 AES-128-CBC 암호화 알고리즘을 사용합니다.
사용자 투명성: 암호화는 사용자에게 투명하게 이루어지므로 애플리케이션 코드 변경이나 클라이언트 드라이버 업데이트가 필요 없습니다.
백업 및 복제 보호: TDE를 사용하면 기본 백업이 자동으로 암호화되며, WAL 파일이나 스트리밍 복제를 통해 가져온 데이터도 암호화됩니다.

암호화된 데이터의 안전한 저장 방식

AgensSQL의 TDE는 데이터를 암호화된 상태로 디스크에 저장합니다. 예를 들어, 'abc', '123' 값을 가진 테이블 데이터가 암호화되면, 일반 텍스트 검색으로는 해당 데이터를 찾을 수 없으며, 파일을 직접 들여다봐도 암호화된 데이터만 볼 수 있습니다.

$ hexdump -C 16416 | grep abc
$
$ hexdump -C 16416 | tail -5
00001fc0 c8 0f 1d c8 9a 63 3d dc 7d 4e 68 98 b8 f2 5e 0a |.....c=.}Nh...^.|
00001fd0 9a eb 20 1d 59 ad be 94 6e fd d5 6e ed 0a 72 8c |.. .Y...n..n..r.|
00001fe0 7b 14 7f de 5b 63 e3 84 ba 6c e7 b0 a3 86 aa b9 |{...[c...l......|
00001ff0 fe 4f 07 50 06 b7 ef 6a cd f9 84 96 b2 4b 25 12 |.O.P...j.....K%.|
00002000

데이터 암호화 키 보안

AgensSQL TDE는 데이터 암호화 키를 안전하게 보호하기 위한 여러 메커니즘을 제공합니다. 기본적으로 암호화 키는 데이터 디렉토리 내 pg_encryption/key.bin 파일에 저장되지만, 이 키를 추가로 보호하기 위한 방법을 제공합니다:

패스프레이즈 사용(예시):

export PGDATAKEYWRAPCMD='openssl enc -e -aes-128-cbc -pbkdf2 -out "%p"'
export PGDATAKEYUNWRAPCMD='openssl enc -d -aes-128-cbc -pbkdf2 -in "%p"'

클라우드 키 관리 서비스 연동(예시):

# AWS KMS 예시
export PGDATAKEYWRAPCMD='aws kms encrypt --key-id alias/tde-master --plaintext fileb:///dev/stdin --output text --query CiphertextBlob | base64 -d > "%p"'

export PGDATAKEYUNWRAPCMD='aws kms decrypt --ciphertext-blob fileb://"%p" --output text --query Plaintext | base64 -d'

Application Level과 DBMS Level에서의 보안 및 암호화 적용 방안

Application Level 암호화(Agenscrypto)

애플리케이션 레벨에서는 pgcrypto 확장 모듈을 활용하여 컬럼 단위 암호화를 구현할 수 있습니다:

구현 방안:

민감 데이터(IMSI, Ki 등)를 저장하기 전 애플리케이션에서 암호화
AES-256과 같은 강력한 암호화 알고리즘 사용
안전한 키 관리 시스템 구축(HSM 활용 가능)
암호화된 필드에 대한 검색이 필요한 경우 토큰화 또는 검색 가능 암호화 기법 적용

-- 확장 모듈 설치
CREATE EXTENSION pgcrypto;

-- 암호화된 데이터 저장 예시
INSERT INTO usim_data (subscriber_id, imsi_encrypted, ki_encrypted)
VALUES (
  '고객ID',
  pgp_sym_encrypt('123456789012345', '암호화키', 'cipher-algo=aes256'),
  pgp_sym_encrypt('a1b2c3d4e5f6g7h8', '암호화키', 'cipher-algo=aes256')
);

-- 복호화 예시
SELECT 
  subscriber_id,
  pgp_sym_decrypt(imsi_encrypted, '암호화키') AS imsi,
  pgp_sym_decrypt(ki_encrypted, '암호화키') AS ki
FROM usim_data
WHERE subscriber_id = '고객ID';

장점	데이터베이스 관리자도 암호화된 데이터에 접근할 수 없음 애플리케이션에서 세밀한 암호화 정책 적용 가능 데이터베이스 종류에 상관없이 일관된 암호화 구현 가능
단점	애플리케이션 코드 수정 필요 성능 오버헤드 발생 가능 키 관리의 복잡성 증가 검색과 인덱싱에 제약 발생

DBMS Level 암호화 (AgensSQL TDE)

DBMS 레벨에서는 TDE를 활성화하여 전체 데이터베이스를 투명하게 암호화합니다:

구현 방안:

initdb 명령어를 통해 TDE 활성화
환경 변수를 통한 키 랩핑/언랩핑 명령 설정
postgresql.conf 파일에서 암호화 키 관련 파라미터 설정

# TDE 활성화 및 키 관리 설정
initdb -D /path/to/data --data-encryption \
  --key-wrap-command='openssl enc -e -aes-256-cbc -pbkdf2 -iter 10000 -salt -out "%p"' \
  --key-unwrap-command='openssl enc -d -aes-256-cbc -pbkdf2 -iter 10000 -salt -in "%p"'

# postgresql.conf에 키 언랩 명령 설정 확인
grep data_encryption_key_unwrap_command /path/to/data/postgresql.conf

장점

애플리케이션 코드 수정 불필요
사용자에게 투명한 암호화 제공
데이터베이스 백업 및 WAL 파일도 자동 암호화
쿼리 성능에 미치는 영향 최소화

단점

데이터베이스 관리자가 암호화된 데이터에 접근 가능
데이터베이스 자체가 침해되면 보호 효과 약화
특정 메타데이터는 암호화되지 않음

SKT 사례에 적용할 경우 이점

SK텔레콤과 같은 대규모 통신사가 AgensSQL TDE와 애플리케이션 레벨 암호화를 결합한 다층 보안 아키텍처를 구현했다면 다음과 같은 효과를 기대할 수 있었을 것입니다:

데이터 유출 위험 최소화: 외부 공격자가 서버에 침투하더라도 데이터베이스 파일은 암호화되어 있어 유의미한 정보를 추출할 수 없었을 것입니다.
다층적 보안: 애플리케이션 레벨과 DBMS 레벨 암호화를 동시에 적용함으로써 단일 계층의 취약점을 보완하는 심층 방어 전략을 구현할 수 있었을 것입니다.
규제 준수: 개인정보 보호법 제29조의 안전성 확보조치 요구사항을 충족하여 법적 책임을 줄이고 정보주체의 권리를 보호할 수 있었을 것입니다.
키 관리 강화: 외부 키 관리 서비스(AWS KMS 등)와의 통합을 통해 암호화 키를 안전하게 관리하고 주기적인 키 로테이션을 자동화할 수 있었을 것입니다.
감사 및 모니터링: 비정상적인 데이터 접근 패턴을 실시간으로 모니터링하고 대응함으로써 내부자 위협과 외부 공격을 조기에 탐지할 수 있었을 것입니다.
비즈니스 연속성: 강력한 암호화와 재해 복구 계획을 통해 서비스 중단과 데이터 손실 위험을 최소화할 수 있었을 것입니다.

AgensSQL TDE는 데이터베이스 수준의 암호화를 애플리케이션 변경 없이 구현할 수 있는 효과적인 솔루션으로, 특히 기존 대규모 시스템의 보안 강화에 적합합니다.

결론

USIM 정보와 같은 민감한 개인정보는 법적 의무 여부를 떠나 기본적인 보안 엔지니어링 원칙에 따라 반드시 암호화되어야 합니다. AgensSQL의 TDE는 애플리케이션 변경 없이 데이터베이스 수준에서 강력한 암호화를 제공하여 이러한 요구사항을 충족시킬 수 있는 효과적인 솔루션입니다.

통신사와 같이 대규모 개인정보를 처리하는 기업은 Application Level과 DBMS Level의 암호화를 적절히 조합하여 다층적 보안 체계를 구축하는 것이 중요합니다. 이를 통해 내부자 위협과 외부 해킹 모두에 효과적으로 대응할 수 있습니다.

출처:

AgensSQL - TDE 메뉴얼 및 기술자료
Agenscrypto 메뉴얼
SKT, 유심 정보 '암호화' 미비…'유심 해킹 피해 귀책사유' 될까 (뉴스핌, 2025.05.08)
https://www.newspim.com/news/view/20250507000964

최신 AI 모델의 환각 현상은 왜 심해졌을까?

SKAI Worldwide | 스카이월드와이드 — Thu, 8 May 2025 12:32:21 +0900

더 똑똑해졌는데 더 환각을 일으키는 AI, 왜 그럴까요?

안녕하세요, 여러분! 오늘은 최근 AI 세계에서 재미있는(?) 현상에 대해 이야기해볼게요. 더 똑똑해진 AI가 오히려 더 많은 '환각'을 일으키는 현상에 대해서요. 네, 맞아요. 더 발전했는데 더 틀린 답을 내놓는다니 이상하죠? 함께 알아봅시다!

AI의 '환각'이 뭐예요?

AI의 '환각'이란 AI가 존재하지 않는 정보를 마치 진짜인 것처럼 자신감 있게 말하는 현상이에요. 마치 술에 취한 친구가 없는 일을 있었다고 우기는 것처럼요!

ChatGPT가 그린 AI의 환각 이미지

대표적인 사례:

1. 존재하지 않는 법원 판례를 인용하기

2. 실제로 발표된 적 없는 논문을 언급하기

3. 일어나지 않은 역사적 사건을 사실처럼 설명하기

최신 AI가 더 많은 환각을 일으키는 이유는?

1. "너무 빨리 달리다 보니 신발끈이 풀렸어요“

오픈AI의 최신 모델인 'o3'는 이전 모델보다 성능이 좋아졌지만, 환각 비율은 16%에서 33%로 두 배나 늘었어요! 'o4 미니'는 무려 48%에 달한다고 해요. 마치 더 빨리 달리려다 오히려 넘어지는 상황이 된 거죠.

왜 이런 일이 생길까요? AI 회사들이 지금 '안정성 추구'보다는 '혁신적 실험'에 집중하고 있기 때문이에요. 경쟁이 치열한 시장에서 "우리 AI가 더 똑똑해요!"라고 자랑하기 위해 서두르다 보니 생긴 현상인 셈이죠.

2. "좋은 선생님과 좋은 교과서가 부족해요“

AI는 학습 데이터의 질과 완전성에 크게 의존해요. 마치 학생이 부실한 교과서로 공부하면 시험에서 틀린 답을 쓰는 것과 같죠!

예를 들어볼까요? 의사가 되려는 AI에게 암세포 사진만 보여주고 정상 조직 사진은 보여주지 않으면, 그 AI는 나중에 정상 조직도 암으로 오판할 수 있어요. 특히 법률이나 의료 같은 전문 분야는 양질의 학습 자료가 부족해서 더 많은 환각이 발생한답니다.

3. "너무 복잡해서 통제하기 어려워요“

최신 AI 모델들은 매개변수(파라미터)가 1조 개가 넘어요! 이게 얼마나 많은 숫자인지 감이 오시나요? 1조 원이 있다면 하루에 1억 원씩 써도 약 27년이 걸릴 정도예요. 그만큼 AI 내부는 복잡하고, 이 복잡성 때문에 AI가 왜 특정 답변을 내놓는지 개발자들도 완벽히 이해하기 어려운 상황이랍니다.

실제 사례: "저는 없는 판례를 인용했다가 벌금 물었어요"

미국 와이오밍주 연방법원에서의 AI 가짜 판례 사건(ChatGPT 생성 이미지)

2025년 2월, 미국 와이오밍주 연방법원에서는 AI가 생성한 가짜 판례를 인용한 변호사 2명에게 5000달러(약 720만 원)의 벌금을 부과했어요. 이들은 "의도하지 않은 실수"라고 해명했지만, 소속 로펌에서 해고되었죠.

미국에서는 최근 2년 동안 최소 9건의 소송에서 비슷한 일이 있었다고 해요. 법정에서 "이 판례를 참고하세요"라고 했는데, 알고 보니 그 판례가 AI가 지어낸 가짜였던 거죠. 전문가가 아니면 진짜와 가짜를 구분하기 어려울 정도로 그럴듯하게 만들어내니 정말 곤란한 상황이에요!

환각 문제, 어떻게 해결할 수 있을까요?

1. 웹 검색 기능으로 사실 확인하기

AI가 답변을 할 때 웹에서 신뢰할 만한 정보를 찾아 확인하는 방식이 주목받고 있어요. 마치 학생이 시험 보기 전에 교과서를 한 번 더 확인하는 것과 같죠!

챗GPT의 책임자 닉 털리도 "챗GPT가 사실에 기반한 최신 정보를 사용자에게 제공하려면 검색 기능은 필수"라고 강조했어요. 하지만 자체 검색 기술로 80%의 질문을 처리할 수 있으려면 수년이 걸릴 거라고 예상한답니다.

2. 지식 그래프와 온톨로지로 AI에게 '지도' 제공하기

AI 환각 문제를 해결할 수 있는 강력한 도구로 그래프 데이터베이스, 지식 그래프, 온톨로지가 주목받고 있어요!

이게 뭐냐고요? 쉽게 설명해 드릴게요.

지식 그래프는 개념들 사이의 관계를 '지도'처럼 연결해주는 구조예요. 예를 들면 "대한민국-수도-서울"처럼 정보와 정보 사이의 관계를 명확하게 정의해줍니다.

이런 지식 그래프를 AI에게 제공하면 환각 현상을 크게 줄일 수 있어요!

실제로 구글은 '지식 그래프'를 활용해 검색 결과의 정확도를 높이고 있고, 의료 분야에서는 'SNOMED CT'라는 온톨로지를 통해 의학 용어의 관계를 정의해 AI의 정확도를 높이고 있답니다.

그래프 데이터베이스의 장점은:

복잡한 관계를 명확하게 표현할 수 있어 AI가 정보의 맥락을 더 잘 이해할 수 있고, 새로운 지식이 추가되더라도 유연하게 확장이 가능해요

특히 법률, 의료 같은 전문 분야에서 정확한 정보 관계를 정의할 수 있어요

예를 들어, 법률 분야에서는 "판례A-근거법령-민법 제750조"와 같은 관계를 지식 그래프로 구축하면 AI가 가짜 판례를 만들어낼 가능성이 크게 줄어들 거예요!

3. 더 좋은 학습 데이터 확보하기

특히 법률, 의료 같은 전문 분야에서는 양질의 데이터 확보가 중요해요. 각국의 판례, 의학 논문 등 신뢰할 수 있는 자료를 더 많이 학습시켜야 할 필요가 있죠.

4. AI의 사고 과정 들여다보기

AI가 어떻게 추론하는지 역으로 연구하는 작업이 필요해요. 마치 학생이 문제를 풀 때 과정을 보는 것처럼, AI의 '사고 과정'을 분석하면 왜 환각이 발생하는지 알아낼 수 있을 거예요.

우리는 어떻게 대처해야 할까요?

당분간은 AI가 제공하는 정보, 특히 전문적인 분야의 정보는 반드시 다른 출처를 통해 확인하는 습관이 필요해요. AI는 정말 유용한 도구지만, 모든 것을 알고 있는 '전지전능한 존재'는 아니니까요!

소설 쓰기나 아이디어 발상 같은 창의적인 작업에는 AI의 환각도 때로는 도움이 될 수 있지만, 법률 문서 작성이나 의료 정보 검색처럼 정확성이 생명인 분야에서는 AI의 답변을 100% 신뢰하지 말고 반드시 전문가의 확인을 받는 것이 좋겠죠?

여러분도 AI를 사용하실 때 "이게 진짜일까?" 하는 의심의 눈을 잊지 마세요! 건강한 의심은 AI 시대를 현명하게 살아가는 데 필수적인 능력이 될 테니까요.

지식 그래프와 온톨로지 같은 기술이 발전할수록 AI의 환각도 점점 줄어들 거예요. 그때까지 우리 모두 현명한 AI 사용자가 되어봐요!

[1부] AI 전환에 온톨로지(ontology)가 필요한 이유

SKAI Worldwide | 스카이월드와이드 — Tue, 29 Apr 2025 13:54:54 +0900

1부 : AI전환에 온톨로지(ontology)가 필요한 이유

2부 : 온톨로지와 그래프 기술: SKAI의 AI 시대 혁신 솔루션
- 온톨로지와 그래프 기술의 기본 개념과 SKAI의 접근 방식 소개

3부 : 객체 중심의 사고 체계 구현
– 온톨로지가 어떻게 인간의 사고방식을 데이터 모델로 변환하는지, 실제 적용 사례를 이용하여 설명

4부 : 직관적인 데이터 해석과 탐색
– 그래프 시각화를 통한 데이터 탐색의 이점과 SKAI의 솔루션 소개

5부 : OGDB(Object Graph Database) 구현으로 확장성 확보
- SKAI만의 차별화된 기술인 OGDB 개념과 GenAI 시대에서의 의미 설명

AI 시대, 왜 온톨로지가 필요할까요?

요즘 기업들이 인공지능(AI)을 도입한다는 이야기를 자주 듣게 됩니다. 그런데 AI 도입과 함께 "온톨로지(Ontology)"와 "지식그래프(Knowledge Graph)"라는 생소한 단어들도 많이 등장하고 있습니다.

이것들이 무엇이고 왜 AI 전환 시대에 중요한지 궁금하시죠? 오늘은 이 개념들에 대해 쉽게 알아보려고 합니다.

온톨로지란? 세상을 정리하는 분류 체계입니다.

온톨로지라는 단어가 어렵게 느껴지시나요? 쉽게 말하면 '세상의 모든 것을 체계적으로 정리하는 방법'이라고 생각하시면 됩니다.

마트에 가본 적 있으시죠? 마트에서는 상품들이 체계적으로 정리되어 있습니다. 과일 코너, 육류 코너, 생활용품 코너 등으로요. 그런데 재미있는 사실은 같은 상품이라도 마트마다 분류 방식이 조금씩 다르다는 거예요.

온톨로지는 이런 다양한 분류 방식을 하나로 통합하는 '지도'라고 생각하시면 됩니다. AI가 다양한 정보를 올바르게 이해하려면 이 '지도'가 꼭 필요합니다.

지식그래프: 온톨로지를 시각화한 연결망

온톨로지와 밀접하게 관련된 개념이 바로 '지식그래프'입니다. 지식그래프는 온톨로지를 구현 하는 기술로서 실제 데이터와 개념들을 연결한 거대한 네트워크라고 생각하시면 됩니다.

데이터-관계-구성원리로 구성된 지식그래프

가족관계를 생각해보세요. "할머니-아버지-나"의 관계, "이모-사촌" 관계처럼 사람들은 서로 다양한 관계로 연결되어 있죠. 지식그래프는 이런 연결 관계를 컴퓨터가 이해할 수 있게 그려놓은 것입니다.

아들-아버지 간의 관계

다음과 같이 사물, 인물, 장소 등의 정보 간의 관계를 시각화한 것이 바로 지식그래프를 활용한 대표적인 예입니다. AI는 이런 지식그래프를 통해 "이 작품은 어떤 작가가 어디에서 만든거지?와 같은 질문에 답할 수 있게 됩니다.

모나리자와 작가, 그리고 장소 등 다양한 정보 간의 관계를 표현한 지식그래프

다양한 분류 체계를 통합해 AI가 더 똑똑해집니다

생각해보세요. 여러분이 "오늘 저녁에 샐러드용 채소 추천해줘"라고 AI에게 물어봤다면, AI는 토마토를 추천 목록에 포함시켜야 할까요? 또 "파스타용 과일 소스 추천해줘"라고 물어본다면, 토마토를 추천해야 할까요?

온톨로지와 지식그래프가 없다면 AI는 혼란스러울 겁니다. 하지만 이 두 가지가 있다면, AI는 토마토가 식물학적으로는 '과일'이지만 요리에서는 '채소'로도 사용된다는 것을 알게 됩니다. 그래서 두 질문 모두에 토마토를 적절하게 고려할 수 있게 되는 거죠.

이처럼 온톨로지와 지식그래프는 AI가 세상의 다양한 관점과 맥락을 이해하도록 도와줍니다. 단어나 개념이 여러 의미를 가질 수 있고, 상황에 따라 다르게 해석될 수 있다는 것을 AI에게 알려주는 거예요.

의료 정보도 통합해서 더 정확한 진단을 돕습니다

병원에 가보신 적 있으시죠? 같은 질병도 병원마다, 부서마다 다른 이름으로 부르는 경우가 많습니다.

예를 들어, 심장 질환의 일종인 '심근경색'은 의사들이 진료할 때는 이 이름을 쓰지만, 의무기록 시스템에는 영어 약자 'MI'로, 보험청구 시스템에는 'I21.9'라는 코드로 입력되기도 합니다. 환자 입장에서는 그냥 "심장마비"라고 부르고요.

온톨로지와 지식그래프는 이 모든 다른 표현들이 사실은 '같은 질병'을 가리킨다는 것을 AI에게 알려줍니다. 이렇게 하면 의료 AI 시스템은 어떤 용어를 사용하든 같은 질병으로 인식하고, 더 정확한 진단을 지원할 수 있습니다.

AI전환(AIX) 시대에는 개인정보도 더 안전하게 보호해야 합니다.

기업이 AI전환(AIX)하면서 많은 데이터를 다루게 되는데, 이 과정에서 개인정보 유출 같은 보안 문제가 발생할 수 있습니다. 온톨로지는 이런 위험을 줄이는 데도 도움이 됩니다.

가령, 우리의 개인정보에는 어떤 것들이 있을까요? 주민등록번호, 전화번호, 주소, 생년월일, 이메일 등이 있죠. 온톨로지는 이런 정보들이 '개인식별정보'라는 범주에 속한다고 AI에게 알려줍니다. 그러면 AI는 이런 정보들을 자동으로 인식하고 특별히 보호하는 조치를 취할 수 있게 됩니다.

또한 "평일 저녁 시간에 갑자기 해외에서 거액이 결제되는" 패턴이 '사기 의심 행위'라고 온톨로지에 정의해두면, AI는 이런 상황을 즉시 감지하고 알림을 보낼 수 있습니다. 이런 방식으로 온톨로지는 AI 전환 과정에서 발생할 수 있는 보안 위험을 줄이는 데 기여합니다.

xAI: AI 경험을 향상시키는 지식그래프의 역할

최근에는 xAI(Experience AI)라는 개념이 주목받고 있습니다. XAI는 사용자가 AI와 상호작용하는 경험의 질을 의미하는데, 온톨로지와 지식그래프는 이 경험을 크게 향상시킵니다.

자율주행 자동차를 예로 들어볼까요? 자율주행 시스템이 갑자기 급제동을 했다면, 우리는 왜 그랬는지 알고 싶을 겁니다. 지식그래프를 활용한 xAI는 "전방에 횡단보도가 있고, 어린이가 달려나올 가능성이 있어 안전을 위해 속도를 줄였습니다"와 같이 사용자가 이해할 수 있는 설명을 제공할 수 있습니다.

xAI의 핵심은 AI의 판단을 사람이 이해할 수 있게 만드는 것입니다. 온톨로지와 지식그래프는 AI의 의사결정 과정을 명확한 개념과 관계로 표현함으로써, 사용자가 AI를 더 신뢰하고 효과적으로 활용할 수 있게 돕습니다.

대화형 AI도 온톨로지로 더 지능적으로 만들 수 있습니다

대화형 AI 비서나 고객 서비스 챗봇을 생각해보세요. 이런 AI가 정확한 답변을 하려면 사용자의 질문 맥락을 제대로 이해해야 합니다.

예를 들어, 제조 공장에서 "최근 제품 불량률이 왜 높아졌을까요?"라고 AI에게 물어본다고 생각해보세요. 온톨로지와 지식그래프가 없는 AI는 단순히 '불량'이라는 단어와 관련된 정보만 찾을 수 있습니다.

하지만 온톨로지와 지식그래프가 있는 AI는 불량과 연관된 '원자재 변경', '기계 점검 일정', '작업자 교대 패턴', '계절적 요인', '온도 변화' 같은 관련 요소들을 자동으로 찾아낼 수 있습니다. 이렇게 더 폭넓은 정보를 바탕으로 AI는 더 정확하고 유용한 답변을 제공할 수 있게 됩니다.

정리: AI 전환 시대의 필수 요소, 온톨로지와 지식그래프

온톨로지와 지식그래프는 어려운 기술 용어가 아니라, 기업과 조직이 AI 시대로 성공적으로 전환하기 위한 필수 요소입니다. 이들은 AI가 우리 세상을 더 정확하게 이해하도록 돕는 '지능형 지도'의 역할을 합니다.

기업들이 AI 전환을 추진할 때 가장 어려운 과제 중 하나는 기존의 다양한 시스템과 데이터를 어떻게 AI가 이해할 수 있는 형태로 변환할 것인가 하는 문제입니다. 온톨로지와 지식그래프는 이 문제의 해결책이 될 수 있습니다.

SKAI의 지식그래프 온톨로지 솔루션은 기업들이 AI 전환 과정에서 겪는 여러 어려움을 해결하는 데 초점을 맞추고 있습니다. 이는 단순히 새로운 기술을 도입하는 것이 아니라, 기업의 소중한 지식과 경험을 체계화하고 AI가 활용할 수 있게 만드는 혁신적인 방법입니다.

AI 시대에는 데이터의 양보다 데이터를 얼마나 잘 이해하고 연결하는지가 더 중요해지고 있습니다. 온톨로지와 지식그래프는 바로 이 '연결과 이해'의 핵심 열쇠가 되어, 기업의 AI 전환을 성공으로 이끌 것입니다.

[기술 보고서]팔란티어 AIP 분석 보고서

SKAI Worldwide | 스카이월드와이드 — Fri, 25 Apr 2025 13:22:25 +0900

1. 개요

1.1. 분석 목적 및 배경

팔란티어(Palantir Technologies)는 빅데이터 분석 및 인공지능 솔루션을 제공하는 글로벌 기업으로, 최근 AIP(Artificial Intelligence Platform)를 통해 AI 시장에서의 입지를 강화하고 있습니다.

본 글에서는 팔란티어의 AIP 솔루션을 중심으로 기술적 특성, 핵심 기능, 주요 모듈 및 차별화 요소를 분석합니다.

1.2. 주요 분석 대상 및 범위

팔란티어 AIP의 핵심 기술 및 아키텍처
주요 기능 및 모듈별 기술적 특징
기존 팔란티어 제품(Foundry, Gotham)과의 연계성
AIP의 시장 경쟁력 및 차별점
향후 발전 방향 및 전략적 시사점

2. 시장 및 환경 분석

2.1. 글로벌 엔터프라이즈 AI 플랫폼 시장 동향

엔터프라이즈 AI 플랫폼 시장은 2024년 기준 약 950억 달러 규모로 추정되며, 연평균 35% 이상의 성장세이며, 주요 시장 동향으로는:

생성형 AI 중심 재편: ChatGPT 등장 이후 기업용 생성형 AI 솔루션 수요 급증
산업 특화 AI 확산: 금융, 의료, 제조 등 산업별 맞춤형 AI 솔루션 증가
데이터-AI 통합 가속화: 데이터 파이프라인과 AI 개발 환경의 통합 추세
하이브리드/멀티클라우드 확장: 다양한 환경에서 일관된 AI 운영 요구 증가
AI 거버넌스 중요성 부각: 규제 강화와 함께 책임 있는 AI 운영 체계 필요성 증대

3. 팔란티어 AIP 솔루션 기술 아키텍처

3.1. AIP 개요 및 핵심 특징

팔란티어 AIP(Artificial Intelligence Platform)는 2023년 5월에 공식 출시된 엔터프라이즈급 AI 플랫폼으로, 기업의 기존 데이터 자산과 현대적인 AI 기술을 통합하는 환경을 제공합니다.

팔란티어 공식 자료에 따르면, AIP는 기업 데이터 인프라와 대형 언어 모델(LLM) 간의 안전한 연결을 통해 실제 비즈니스 가치를 창출하는 데 중점을 두고 있습니다.

팔란티어 AIP: "엔터프라이즈 데이터와 AI의 안전한 통합"

3.1.1. AIP의 주요 특징

특징	발표된 내용
온톨로지 기반 데이터 모델링	팔란티어의 기존 온톨로지 시스템을 활용하여 비정형 및 정형 기업 데이터를 AI 모델에서 활용 가능한 형태로 표현
AI 모델 통합	OpenAI, Anthropic 등 주요 LLM 제공업체와의 공식 통합 지원 발표
기업 보안 및 거버넌스	엔터프라이즈급 보안 및 거버넌스 프레임워크를 통한 AI 사용 감독 및 제어
비즈니스 애플리케이션 생성	Boot라는 로우코드 환경을 통한 AI 기반 애플리케이션 개발 지원

3.1.2. AIP 구성 요소

AI Assistant: 팔란티어의 지식 그래프와 통합된 자연어 인터페이스
Knowledge Graph: 기업 데이터 자산을 의미론적으로 연결하는 구조
Boot: 로우코드/노코드 개발 환경으로 비즈니스 사용자가 AI 기반 애플리케이션을 구축할 수 있게 지원
보안 및 거버넌스 프레임워크: 정부 및 규제 산업에 맞춘 보안 통제 시스템

3.2. 기술 아키텍처 및 구성 요소

3.2.1. 계층별 아키텍처

계층	발표된 기능
데이터 통합 계층	기존 데이터 소스 연결 ETL 및 데이터 변환 온톨로지 모델링
AI 모델 통합 계층	주요 상용 AI 모델 지원 LLM 관리 및 버전 제어 모델 성능 모니터링
애플리케이션 개발 계층	Boot 로우코드 환경 AI 기능 템플릿 비즈니스 로직 구현
보안 및 거버넌스 계층	접근 제어 감사 로깅 규정 준수 관리

3.2.2. 배포 옵션

팔란티어는 AIP에 대해 다음과 같은 배포 옵션을 제공합니다.

배포 모델	발표된 내용
클라우드	AWS, Azure, GCP 환경에서 지원
온프레미스	고객 데이터센터 내 배포 옵션 제공
하이브리드	클라우드와 온프레미스 환경 동시 지원

3.3. 기존 제품과의 연계성

AIP는 기본 솔루션은 Foundry 및 Gotham 플랫폼과 통합 됩니다.

3.3.1. Foundry와의 통합

Foundry의 데이터 모델과 온톨로지 활용
Foundry 워크플로우 내 AI 기능 통합
공통 보안 및 사용자 관리 체계

3.3.2. Gotham과의 통합

Gotham의 그래프 기반 분석과 AIP의 AI 기능 결합
네트워크 분석 및 패턴 탐지 기능 강화
정부 및 국방 분야 특화 기능 지원

3.3.3. 현재 진행 중인 통합 현황

기본 데이터 통합 및 공통 인증 체계 구현 완료
주요 LLM 제공업체와의 통합 지속 확장 중
산업별 특화 템플릿 및 워크플로우 개발 진행 중

4. AIP 핵심 기술 모듈 분석

4.1. 온톨로지 기반 데이터 모델링

팔란티어 AIP는 기업의 데이터를 온톨로지 기반으로 모델링하는 기술을 핵심으로 활용하며, Foundry와 Gotham에서 입증된 온톨로지 시스템을 기반으로 합니다.

구성요소	발표된 기능
온톨로지 모델러	비즈니스 개념 간 관계 정의 데이터 객체 및 속성 매핑 산업별 표준 온톨로지 템플릿 제공
지식 그래프	기업 데이터 간 관계 시각화 데이터 출처 및 계보 추적 연결된 데이터 쿼리 및 탐색

팔란티어는 AIP의 온톨로지 시스템이 다음과 같은 이점을 제공한다고 합니다.

AI 모델이 기업의 도메인 특화 데이터를 이해할 수 있는 기반 제공
다양한 데이터 소스를 일관된 모델로 통합
규제 준수 및 감사를 위한 데이터 계보 추적

4.2. LLM 통합 및 RAG 아키텍처

구성요소	발표된 기능
LLM 통합	OpenAI(GPT-4), Anthropic(Claude) 등 주요 LLM 지원 API 기반 모델 통합 프롬프트 관리 및 최적화
RAG (Retrieval-Augmented Generation)	기업 데이터 기반 컨텍스트 제공 벡터 데이터베이스 활용 실시간 관련 정보 검색

AIP는 다음과 같은 방식으로 RAG 아키텍처를 구현 및 제공합니다.

기업 문서 및 데이터를 벡터 형태로 인덱싱
사용자 질의에 관련된 정보를 기업 데이터에서 검색
검색된 정보를 기반으로 LLM 응답 생성
출처 및 근거 정보 제공

4.3. AI 애플리케이션 개발 환경 (Boot)

Boot는 팔란티어가 공식적으로 발표한 AIP의 Low-Code AI 애플리케이션 개발 환경입니다.

구성요소	발표된 기능
앱 빌더	드래그-앤-드롭 인터페이스 사전 구축된 컴포넌트 라이브러리 데이터 시각화 도구
AI 통합 도구	AI 기능 블록 라이브러리 LLM 응답 표시 및 관리 AI 워크플로우 구성
비즈니스 로직	조건부 규칙 설정 워크플로우 자동화 사용자 액션 정의

팔란티어는 Boot 환경의 주요 특장점으로 다음 사항을 강조하고 있습니다.

비기술자도 AI 기반 애플리케이션 개발 가능
기업 특화 AI 솔루션 신속 개발
엔터프라이즈 환경과의 보안 통합

4.4. 보안 및 규정 준수 기능

팔란티어 AIP는 엔터프라이즈급 보안 및 규정 준수 기능 제공합니다.

구성요소	발표된 기능
접근 제어	세분화된 사용자 권한 관리 역할 기반 접근 제어(RBAC) 다중 인증(MFA) 지원
데이터 보안	데이터 암호화(저장 및 전송 중) 민감 정보 보호 데이터 분류 및 마스킹
AI 사용 거버넌스	AI 활동 감사 로깅 모델 사용 모니터링 프롬프트 및 결과 추적
규정 준수	GDPR, HIPAA, FedRAMP 등 규제 대응 감사 증거 자동 수집 규정 준수 보고서 생성

팔란티어는 AIP가 특히 정부, 금융, 헬스케어 등 규제가 엄격한 산업에 최적화된 보안 기능을 갖추고 있다고 강조하고 있습니다.

4.5. 기술적 한계 및 제약

현재까지 파악된 AIP의 기술적 한계는 다음과 같습니다.

통합 복잡성: 레거시 시스템과의 통합 시 상당한 초기 설정 작업 필요
구현 리소스: 전체 기능 활용을 위해 전문 기술 인력 요구
확장성 과제: 대규모 데이터 환경에서 성능 최적화 필요
클라우드 네이티브 통합: 일부 클라우드 네이티브 서비스와의 통합에 제한적 지원

5. AIP 보안 및 거버넌스 프레임워크

5.1. 보안 아키텍처

보안 계층	확인된 기능
ID 및 접근 제어	세분화된 접근 제어 정책 기존 기업 ID 시스템 통합(SSO) 역할 기반 권한 관리 사용자 활동 추적
데이터 보안	전송 중 및 저장 데이터 암호화 데이터 분류 및 보호 정책 개인정보 보호 자동화 조직 간 데이터 경계 관리
AI 컨텐츠 보안	프롬프트 검증 및 필터링 출력 내용 검토 메커니즘 민감 정보 탐지 및 제거 악의적 입력 방지
인프라 보안	보안 경계 설정 침입 탐지/방지 로그 관리 및 모니터링 취약점 관리

AIP 보안 아키텍처는 정부 및 국방 프로젝트에서 입증된 기존 보안 기술 기반으로 2023년 FedRAMP 인증 획득하였다고 합니다.

5.2. 규정 준수 프레임워크

규제 영역	공식 확인된 지원
글로벌 보안 표준	ISO 27001/27017/27018 SOC 2 Type II NIST 800-53 NIST 사이버보안 프레임워크
산업별 규제	금융: PCI DSS, SOX 의료: HIPAA 정부: FedRAMP, IL4 에너지: NERC CIP
개인정보 보호	GDPR(유럽) CCPA(캘리포니아) PIPEDA(캐나다)
AI 관련 규제	AI 위험 관리 프레임워크(NIST) 책임 있는 AI 원칙 준수 설명 가능한 AI 지침 지원

AIP의 규정 준수 기능은 다음과 같은 방식으로 구현되고 있습니다.

자동화된 규정 준수 증거 수집 및 문서화
규제 요구 사항에 맞춘 감사 로깅
규제 변화에 따른 정기적인 업데이트

5.3. AI 거버넌스 기능

거버넌스 영역	확인된 기능
AI 활동 감사	프롬프트 및 응답 로깅 사용자 상호작용 추적 AI 사용 통계 및 분석 이상 사용 패턴 탐지
책임 있는 AI	편향성 탐지 및 모니터링 공정성 평가 도구 윤리적 AI 사용 가이드라인 인간 검토 워크플로우
AI 제어 체계	모델 승인 및 배포 관리 사용 정책 적용 접근 제어 및 한도 설정 중앙 집중식 AI 관리
AI 투명성	의사결정 설명 기능 데이터 출처 추적 신뢰도 점수 제공 사용된 모델 정보 표시

팔란티어는 특히 규제 산업 및 정부 기관을 위한 AI 거버넌스 기능 강조하며, 기존 Foundry 및 Gotham 플랫폼에서 입증된 거버넌스 체계를 AIP에 통합 했음을 강조하고 있습니다.

5.4. 보안 및 거버넌스 역량

Gartner 보고서: 팔란티어는 엔터프라이즈 AI 거버넌스 영역에서 선도적 위치로 평가 (2023)
FedRAMP 인증: 팔란티어는 미국 정부 고위험 데이터 처리 인증 획득
금융 산업 사례: 주요 금융 기관들이 규제 준수 역량을 주요 채택 이유로 언급
외부 보안 감사: 독립적인 보안 감사에서 데이터 보호 체계의 견고성 확인

6. AIP 도입 및 구현 전략

6.1. 도입 성공 요소

성공 요소	중요성
경영진 지원	성공적 구현 사례의 90% 이상에서 경영진의 적극적 지원과 전략적 정렬이 결정적 요소로 확인됨
데이터 준비도	데이터 품질 및 접근성이 구현 시간과 초기 가치 실현에 직접적 영향을 미치는 것으로 확인됨
명확한 사용 사례	구체적이고 측정 가능한 비즈니스 목표가 있는 프로젝트의 성공률이 2.5배 높은 것으로 확인됨
전문 인력 확보	적절한 기술 역량과 교육이 구현 지연의 주요 위험 요소 감소에 필수적임이 확인됨

6.2. 기술적 도전과제

도전과제	영향도	해결 방안
데이터 통합 복잡성	레거시 시스템 및 사일로화된 데이터 환경에서 통합에 상당한 시간 소요	팔란티어는 단계적 통합 접근법 및 사전 구축된 커넥터를 권장
AI 모델 성능 최적화	대규모 데이터셋에서 응답 시간 및 정확도 최적화 과제 존재	도메인별 튜닝 및 하이브리드 추론 모델 활용 권장
보안 구성 복잡성	세분화된 보안 요구사항 충족을 위한 복잡한 설정 필요	산업별 보안 템플릿 및 단계적 구현 접근법 제공
조직 변화 관리	AI 도입에 따른 워크플로우 및 역할 변화 관리 과제	사용자 참여 및 교육 프로그램을 통한 점진적 변화 관리 권장

7. AIP 기술 로드맵 및 발전 방향

7.1. 개발 로드맵

기간	발표된 개발 계획
단기 (2023-2024)	추가 LLM 통합 확대 산업별 특화 템플릿 출시 Boot 환경 기능 강화 AI 거버넌스 도구 개선
중기 (2024-2025)	크로스모달 AI 기능 확장 에지 컴퓨팅 지원 강화 확장된 온톨로지 기능 AI 자동화 워크플로우
장기 방향성	완전 자율 AI 시스템 개발 고급 추론 및 의사결정 지원 더 깊은 도메인 특화 기능 차세대 AI 안전성

7.2. 기술 투자 영역

투자 영역	확인된 활동
생성형 AI	주요 LLM 제공 업체와의 전략적 파트너십 특화된 생성형 AI 애플리케이션 개발 RAG 아키텍처 고도화 연구
도메인 특화 AI	금융, 의료, 방위 산업별 AI 모델 개발 산업별 온톨로지 및 지식 그래프 확장 규제 준수 특화 기능
AI 안전성	책임 있는 AI 사용을 위한 기술 개발 설명 가능한 AI 및 편향성 탐지 도구 보안 및 개인정보 보호 기술
분산 AI 인프라	에지-클라우드 연계 기술 분산 학습 및 추론 아키텍처 저지연 AI 배포 기술

7.3. 기술 진화 방향

영역	기술 동향
AI 자율성 향상	점진적으로 더 많은 자율 의사결정 기능 추가 인간 감독 하의 AI 자동화 확대 복잡한 워크플로우 자가 최적화
다중 모델 협업	단일 모델에서 모델 체인 및 앙상블로 진화 특화 모델과 범용 모델의 효과적 조합 작업별 최적 모델 자동 선택
하이브리드 아키텍처	클라우드-에지 하이브리드 배포 확대 온프레미스 강점과 클라우드 유연성 결합 멀티클라우드 환경 지원 강화
AI 거버넌스 고도화	글로벌 규제 변화에 대응하는 거버넌스 기능 강화 산업별 규제 특화 컴플라이언스 도구 자동화된 위험 관리 및 완화

7.4. 시장 및 기술 트렌드 반영

트렌드	대응 방향
생성형 AI 확산	주요 생성형 AI 모델 통합 엔터프라이즈 컨텍스트에서 안전한 활용 RAG 아키텍처를 통한 기업 데이터 활용
AI 규제 강화	규제 대응 기능 선제적 개발 설명 가능성 및 투명성 기술 강화 산업별 컴플라이언스 지원
데이터 주권 중요성	지역별 데이터 현지화 지원 데이터 상주 옵션 강화 국가별 규정 준수 프레임워크
수직적 AI 통합	산업별 특화 솔루션 개발 도메인 특화 온톨로지 및 모델 특정 산업 워크플로우 최적화

7.5. 기술적 과제

기술적 과제	영향도
모델 복잡성 관리	다양한 AI 모델의 상호운용성 및 버전 관리 복잡성 증가
계산 자원 최적화	고급 AI 기능을 위한 컴퓨팅 요구사항 증가와 비용 관리 과제
기술 역량 격차	고급 AI 플랫폼 활용을 위한 전문 인력 확보 및 교육 과제
기술 부채 관리	빠르게 발전하는 AI 기술과 기존 시스템 통합 시 기술 부채 발생

이러한 과제에 대응하기 위해 다음과 같은 전략 계획 수립하고 있다고 합니다.

점진적 모델 통합 및 자동화된 관리 도구 개발
컴퓨팅 최적화 및 분산 처리 기술 개선
파트너 네트워크 확대 및 고객 교육 프로그램 강화
모듈식 아키텍처 및 마이그레이션 도구 개발

8. 경쟁 분석 및 시장 포지셔닝

8.1. 시장 내 위치 및 주요 경쟁사

현재까지 파악된 엔터프라이즈 AI 플랫폼 시장에서 팔란티어 AIP의 경쟁사는 다음과 같습니다.

주요 경쟁사	주요 제품	시장 초점
Microsoft	Azure OpenAI Service, Copilot	클라우드 중심, 생산성 통합
AWS	Amazon Bedrock, SageMaker	클라우드 인프라, 개발자 중심
Google Cloud	Vertex AI	기술 혁신, AI 연구 기반
IBM	watsonx	산업 특화 솔루션, 하이브리드 클라우드
Leading Enterprise AI Software Provider \| C3 AI	C3 AI Suite	산업 특화 AI, IoT 통합
Databricks	Databricks AI	데이터 레이크하우스, 분석 기반

8.2. 차별화 요소

영역	차별화 요소
데이터 통합	레거시 시스템 통합 역량 이기종 데이터 소스 연결 엔터프라이즈 규모 대응
보안 및 규정 준수	규제 산업 최적화 아키텍처 세분화된 접근 통제 FedRAMP 인증
도메인 특화	산업별 온톨로지 모델 전문화된 사용 사례 지원 금융/방위 산업 전문성
배포 유연성	온프레미스 지원 하이브리드 클라우드 옵션 멀티클라우드 지원

8.3. 제한 사항

영역	제한 사항
비용 구조	상대적으로 높은 구현 및 유지보수 비용 중소기업 접근성 제한
구현 복잡성	상당한 초기 설정 및 구성 필요 전문 기술 인력 요구
개발자 생태계	제한적인 개발자 커뮤니티 오픈소스 통합 부족
클라우드 네이티브 통합	일부 클라우드 서비스와의 제한적 통합 서버리스 환경 지원 부족

8.4. 시장 포지셔닝 및 타겟 세그먼트

시장 세그먼트	포지셔닝 전략
대기업/엔터프라이즈	기업 전체를 위한 End2End AI 통합 플랫폼으로 포지셔닝
정부/공공 부문	고도의 보안 및 규정 준수 요구사항에 최적화된 AI 솔루션으로 포지셔닝
금융 서비스	규제 준수 및 리스크 관리에 특화된 AI 플랫폼으로 포지셔닝
방위 산업	국가 안보 및 정보 분석을 위한 신뢰할 수 있는 AI 솔루션으로 포지셔닝
의료/헬스케어	환자 데이터 보호 및 임상 의사결정 지원을 위한 규제 준수 플랫폼으로 포지셔닝

팔란티어는 2023년 Q2 실적 발표에서 AIP가 특히 다음과 같은 산업에서 채택되고 있다고 발표하였습니다.

정부 및 공공 부문 (미국, 영국, 기타 나토 동맹국)
금융 서비스 (주요 글로벌 은행, 자산 관리 회사)
의료 (병원 시스템, 제약 회사)
방위 산업 (주요 방위 계약업체)

8.5. 객관적인 시장 동향 및 전망

팔란티어 AIP를 포함한 엔터프라이즈 AI 플랫폼 시장의 동향은 다음과 같습니다.

시장 동향	내용
시장 성장	엔터프라이즈 AI 플랫폼 시장은 2023-2028년 동안 연평균 35-40% 성장 전망 (Gartner, IDC)
경쟁 심화	클라우드 업체들의 AI 서비스 강화와 특화 기업들의 시장 진입으로 경쟁 심화
통합 추세	독립 AI 도구들보다 통합 플랫폼 접근법 선호도 증가
규제 환경 변화	AI 규제 강화 추세로 규정 준수 및 거버넌스 기능 중요성 증대

8.6. 경쟁 제품 비교 분석

기능 영역	팔란티어 AIP	Microsoft Azure AI	AWS AI	IBM watsonx
데이터 통합	강점: 온프레미스 및 레거시 시스템 약점: 클라우드 네이티브 통합	강점: Microsoft 생태계 약점: 비-MS 환경	강점: AWS 서비스 약점: 온프레미스	강점: 하이브리드 환경 약점: 구현 복잡성
모델 지원	제한적 자체 모델, 주요 타사 통합	강력한 OpenAI 파트너십, 자체 모델	다양한 자체 모델, 개방형 통합	자체 모델 포트폴리오, 오픈소스 통합
개발 도구	Boot (로우코드), 제한적 개발자 도구	종합적 개발자 도구, Copilot	강력한 개발자 중심 도구, SageMaker	하이브리드 접근법, 산업 특화
보안 및 규정 준수	매우 강력, 정부/금융 특화	강력, 클라우드 중심	강력, AWS 생태계 중심	매우 강력, 규제 산업 경험
배포 옵션	온프레미스, 클라우드, 하이브리드	주로 Azure 중심	AWS 중심	하이브리드, 멀티클라우드
가격 구조	엔터프라이즈 수준 라이선스, 높은 TCO	사용량 기반, 중간~높음	사용량 기반, 유연함	혼합 모델, 중간~높음

#. 참고자료

번호	내용 요약	출처
1	AIP 소개 및 기술 구조	Palantir 공식 블로그 및 제품 페이지
2	온톨로지 기반 데이터 모델링	Palantir Foundry Whitepaper (Ontology 기능 포함)
3	RAG 및 LLM 통합 기능	Palantir 발표자료 (AIP Launch Event 2023.05)
4	Boot (Low-code 개발환경) 기능 설명	Palantir AIP Event 데모 영상
5	FedRAMP 인증 확보	FedRAMP Marketplace - Palantir Entry
6	글로벌 AI 플랫폼 시장 규모	Gartner AI Forecast 2024
7	AIP 보안 및 컴플라이언스 대응	Palantir AIP 보안 브리핑 자료
8	엔터프라이즈 AI 경쟁사 비교	IDC, Gartner, Forrester 자료 종합
9	산업별 AIP 활용 사례	Palantir IR 자료 및 Earnings Call Q2 2023
10	AI 규제 대응 및 AI 거버넌스 체계	NIST AI Risk Management Framework (RMF) 1.0

보고서 내용 중 수정이 필요하거나 업데이트가 필요한 사항은 피드백 주시면 검토 후 반영하도록 하겠습니다.

AgensSQL의 빠른 성능과 PostGIS 기능으로 스마트 도로 데이터 혁신! 한국도로공사의 성공 사례

SKAI Worldwide | 스카이월드와이드 — Thu, 31 Oct 2024 14:16:09 +0900

"AgensSQL의 빠른 성능과 PostGIS 기능으로 스마트 도로 데이터 혁신! 한국도로공사의 성공 사례"

한국도로공사와 해당 프로젝트를 소개해 주세요.

“안녕하십니까. 한국도로공사는 1969년에 설립되어 대한민국의 고속도로 건설 및 운영을 담당하는 대표적인 공공기관입니다. 안전하고 편리한 교통 환경을 위해 노력해왔으며, 현재는 2030 비전인 ‘안전하고 편리한 미래교통 플랫폼 기업’을 목표로, 도로 정보 전반에 대한 디지털화와 플랫폼화를 중점적으로 추진하고 있습니다.

이번 프로젝트를 통해, 설계부터 시공, 유지관리까지의 과정에서 데이터를 기반으로 한 효율적인 도로 관리를 목표로 하고 있습니다. 이 플랫폼의 목적은 도로대장의 데이터를 표준화하고, 다양한 도로 관련 정보를 통합 관리하여 실시간으로 정보를 활용할 수 있는 빅데이터 기반의 스마트 도로 운영 체계를 구축하는 것입니다. 한국도로공사는 이러한 디지털 전환이 정부 정책 변화에 신속히 대응하고, 도로 정보의 생애주기 관리를 더욱 효율적으로 하기 위해 필요하다고 판단하였으며, 이번 프로젝트는 고속도로 디지털화라는 핵심 사업의 일환으로 추진되고 있습니다."

AgensSQL(아젠스SQL)을 도입하게 된 계기는 무엇인가요?

“이번 데이터 기반 스마트 도로통합플랫폼 구축은 방대한 도로 데이터를 빠르고 정밀하게 분석하며, 실시간으로 활용할 수 있는 성능이 필요했습니다. PostgreSQL(포스트그레SQL) 기반의 국산 상용 DBMS인 AgensSQL(아젠스SQL)은 테스트를 통해 글로벌 DBMS와 비교해도 더 빠른 성능 속도를 발휘하는 것으로 알고 있습니다.

특히 실시간 데이터 분석에 적합하면서도 PostGIS라는 PostgreSQL의 확장(Extension) 기능을 통해 도로 정보의 위치 기반 분석과 시각화가 가능해졌습니다. 때문에 도로 유지관리와 교통량 분석 등 중요한 역할을 수행할 수 있었습니다. 그리고 PostgreSQL의 높은 확장성 덕분에 프로젝트 진행 중 필요한 기능을 손쉽게 추가하거나 최적화할 수 있어 변화하는 요구사항에 유연하게 대응할 수 있었습니다. 이러한 기능들은 기존 DBMS 제품에서 경험하기 어려웠던 부분이었고, 이러한 이유로 AgensSQL을 도입하게 되었습니다.”

적용 이후 달라진 효과가 있으셨나요?

“도로와 관련된 방대한 데이터를 실시간으로 처리하는 데 있어서 기존 DBMS 제품에 비해 더 빠르고 안정적이었습니다. 특히 도로 대장 관리, 교통량 분석, 도로 유지 관리와 같은 다양한 작업에서 처리 시간을 크게 단축할 수 있었습니다. PostgreSQL 확장 기능인 PostGIS를 활용해 공간 데이터를 분석하여 도로와 관련된 위치 정보를 더욱 정확하게 파악하여 유지보수 작업을 잘 관리할 수 있었습니다. 마지막으로 시스템 확장성 면에서도 지속적으로 최신 기술을 업데이트할 수 있어, 향후 플랫폼 업그레이드에서도 유연하게 대응할 수 있을 것으로 기대하고 있습니다.”

공공기관에서 AgensSQL을 도입해야 하는 이유는 무엇이라고 생각하시나요?

“AgensSQL은 PostgreSQL 기반의 확장성과 성능 측면에서 뛰어나고 국내 DBMS 제품이라 믿음이 갔습니다. 무엇보다도 도로 관련 대규모 데이터를 빠르고 안정적으로 처리할 수 있다는 점은 공공기관 입장에서 큰 매력이었습니다.

PostgreSQL의 강점을 그대로 계승하면서도, AgensSQL은 한국 고객들의 니즈에 맞춘 빠른 기술 지원과 프로젝트에 최적화된 성능을 제공하였습니다. 특히 대규모 데이터 분석과 실시간 처리에 필요한 성능 향상과 기술적 안정성을 강화했기 때문에, 데이터 기반 프로젝트에서도 안정적이고 효율적인 운영이 가능하였던 것 같습니다. 또한, PostGIS 확장을 통해 공간 데이터를 정밀하게 다룰 수 있는 기능 또한 큰 장점이며, PostgreSQL의 글로벌 커뮤니티와 최신 기술 업데이트 덕분에 시스템의 확장성과 안정성까지 보장됩니다.

결론적으로, AgensSQL은 PostgreSQL의 검증된 오픈소스 기반에 국내 시장에 맞춘 기능과 신속한 기술 지원을 더한 솔루션으로, 성능, 유연성, 기술적 지원을 고루 갖춘 데이터 프로젝트에 적합한 DBMS 제품이라고 생각합니다.”

[웨비나 후기] 10/16 오픈소스 DBMS 도입 전, 필수 체크포인트

SKAI Worldwide | 스카이월드와이드 — Fri, 25 Oct 2024 08:08:23 +0900

[웨비나 후기] 10/16 오픈소스 DBMS 도입 전, 필수 체크포인트

안녕하세요, 새로운 웨비나 소식을 가지고 온 비트나인입니다.

지난 4개월간 총 6회차에 걸쳐 PostgreSQL 기술 웨비나를 뜨거운 관심과 응원덕분에 잘 마무리 할 수 있었습니다.

매회차마다 다양한 후기 의견들을 반영하여 높은 만족도를 드리며 잘 마무리할 수 있었는데요, 웨비나 주제에 대한 다양한 의견들 중 가장 관심이 높았던 주제는 ‘오픈소소 DB 동향이나 도입’ 이었습니다.

이러한 의견들을 반영하여, 이번 웨비나 주제는 ‘오픈소스 DB 도입 전, 필수 체크포인트'에 대한 이야기로 구성하여 오랜 경험이 많은 DB 전문가가 알려주는 전문적인 내용을 중심으로 내용을 진행하였습니다.

관심이 높은 주제인 만큼, 오픈소스 소프트웨어나 DB에 관심이 많으신 분들이 사전 등록에 많이 참여해 주셨고, 덕분에 지난 기술 웨비나와는 다르게 더 다양한 직군과 기업에서 참석해 주셨습니다.

웨비나의 주요 내용은 오픈소스 업계 동향을 글로벌과 국내로 나누어 소프트웨어와 데이터베이스 시장 현황을 설명하는 것으로 시작되었습니다. 수많은 오픈소스 DBMS 중 다양한 성능의 데이터베이스가 존재하지만, 그 중에서도 PostgreSQL이 왜 비즈니스에 적합한 DB로 떠오르고 있는지에 대한 상세한 기능 설명이 이어졌습니다.

다음으로 DB 도입 시 고려사항에 대한 세션으로 넘어갔습니다. 오픈소스 DBMS 도입 전 체크리스트와 기업 규모 및 환경에 따른 DBMS 유형 관리에 대해 설명하며, 자체 유지보수가 쉽지 않은 경우에는 DBMS 전문 업체와 함께하는 유지보수를 추천했습니다. 특히 최근에 비트나인에서 진행한 한국철도공사 사례를 통해, 대량의 열차 운행 데이터들을 빠르게 파악해야 하는 대형 프로젝트였던 만큼 도입 및 유지비용에도 많은 고민이 있었습니다. 이러한 상황을 분석하여, 대표적인 오픈소스 DBMS PostgreSQL 기반 상용 DB인 AgensSQL을 성공적으로 교체하여 고객사가 고민하던 빠른 대용량 데이터 처리와 도입이후에도 안전한 유지보수, 가격 문제를 잘 해결할 수 있었습니다.

모든 발표가 끝난 후, 마지막 세션으로 웨비나 사전 질문에 대한 질의응답 시간을 가졌습니다. 많은 질문 중 오픈소스 DBMS에 대한 유지보수 지원이나 기존 시스템과의 마이그레이션 관련 문의가 많았고, 발표자의 전문적이고 상세한 답변으로 웨비나를 마무리할 수 있었습니다.

웨비나에 뜨거운 관심을 보여주신 모든 참석자분들께 진심으로 감사드리며, 저희 비트나인은 앞으로도 유익하고 알찬 정보를 바탕으로 더 나은 웨비나를 준비하겠습니다. 감사합니다!

10/16 오픈소스 DBMS 도입 전, 필수 체크포인트 다시보기

AgensSQL의 우수한 성능과 최적화된 PostGIS 기능을 통한 농업 데이터 관리 효율성 증대

SKAI Worldwide | 스카이월드와이드 — Tue, 8 Oct 2024 10:57:54 +0900

AgensSQL의 우수한 성능과 최적화된 PostGIS 기능을 통한 농업 데이터 관리 효율성 증대

농림축산식품부와 해당 프로젝트를 소개해 주세요.

"농림축산식품부는 농업, 임업, 축산업, 식품산업과 관련된 정책을 총괄합니다. 농업의 생산성을 높이고, 농가의 소득을 증대시키며, 안전하고 지속 가능한 식량 공급을 보장하는 것을 목표로 합니다. 주요 업무에는 농업 기술 개발, 농촌 개발, 식품 안전 관리, 축산물의 생산 및 유통 관리 등이 있습니다. 이번 프로젝트는 차세대 농업농촌 통합정보시스템 구축을 목표로 하고 있습니다. 기존 농업 보조금 지원 시스템이 2005년 개통된 이후, 여러 차례 제도 변경과 사업 확대로 인해 시스템이 노후화되었고, 데이터 관리의 한계가 드러났습니다.

농림축산식품부는 이러한 문제를 해결하고, 새로운 디지털 환경에 맞춰 안정적이고 효율적인 시스템을 구축하기 위해 이번 프로젝트를 추진하게 되었습니다. 예산은 약 552억 원 규모로, 향후 2026년까지 장기적으로 진행될 예정입니다. 특히 부정수급을 방지하고, 데이터를 더 정확하고 실시간으로 관리하는 것을 목표로 하고 있습니다."

AgensSQL을 도입하게 된 계기를 말씀해 주세요.

"이번 프로젝트에서 AgensSQL을 선택한 이유는 무엇보다도 국산 기업의 DBMS이면서 빠른 성능과 해당 프로젝트에 적합한 기능 때문입니다. 우선 성능적인 측면에서 AgensSQL이 글로벌 A사의 제품보다도 데이터 처리 속도가 더 빠르게 나온 것으로 알고 있고, 오픈소스 기반이라 최신 기술 업데이트가 꾸준히 이루어지고 있어 시스템 안정성과 확장성 면에서 매우 만족스러웠습니다. 또한, PostGIS라는 확장 기능을 통해 농업에 관련된 공간 데이터를 효과적으로 관리하고 처리할 수 있었는데, 이는 농업 지리 정보를 관리하는 데 큰 도움이 될 거로 생각했습니다. 이러한 이유로 이번 차세대 농업농촌 통합정보시스템 프로젝트에서 AgensSQL을 도입하게 되었습니다."

적용 이후 달라진 효과가 있으셨나요?

"AgensSQL을 도입한 후 첫 번째로 확인된 효과는 데이터 처리 속도의 향상이었습니다. 기존 시스템은 대규모 데이터(농업인, 농지, 보조금 등)를 처리하는 데 있어 병목 현상이 자주 발생했지만, AgensSQL을 사용한 이후로는 이러한 데이터를 빠르게 관리하고 처리할 수 있게 되었습니다. 특히, 농업 데이터 분석 능력이 크게 개선되어, 농업 보조금 집행 및 농업 생산성 분석 등의 작업이 훨씬 효율적으로 이루어졌습니다.
두 번째로는, AgensSQL이 최신 기술을 빠르게 적용할 수 있어 향후 시스템 확장과 업그레이드에 유연하게 대응할 수 있었고 마지막으로, AgensSQL을 개발한 비트나인에는 PostgreSQL 전문 인력이 많아, 문제 발생 시 국내에서 빠르고 효율적인 기술 지원이 제공되는 점도 큰 장점이었습니다."

AgensSQL을 추천하는 이유는 무엇인가요?

"AgensSQL을 써야하는 이유는 여러 가지가 있는데 가장 먼저 성능의 우수성이 뛰어납니다. 특히 대용량 데이터를 빠르고 안정적으로 처리할 수 있는 기능을 제공하며, 저희뿐만 아니라 다른 공공기관들과 대기업에서도 이미 입증한 사례들이 있었습니다. 두번째는 비용 측면에서 매우 경쟁력이 있다고 생각합니다. 오픈소스 기반이기 때문에 초기 구축비용뿐 아니라 운영비용도 크게 절감할 수 있었습니다. 세번째는 국내산 DBMS라서 우수한 DB기술 인력들의 빠른 현장지원이 만족스러웠고, 365일 동안 24시간 언제든 중단없이 기술지원을 받을 수 있었습니다. 네번째로 빠른 업데이트와 기술 지원이 이루어져 최신 기술을 쉽게 도입할 수 있었고 마지막으로, 사용 편의성도 매우 우수해 기존 시스템과의 연동이 용이하며, 운영자나 개발자가 쉽게 관리할 수 있는 점도 큰 장점입니다.
이러한 이유로 AgensSQL은 탁월한 선택이었고, 앞으로 여러 분야의 프로젝트에서 탁월한 선택이 될 것이라 생각합니다."

[웨비나] ️10/16(수) 오후 2시,"오픈소스DBMS 도입을 위한 성공적인 전략"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Tue, 8 Oct 2024 09:07:56 +0900

[웨비나] ️10/16(수) 오후 2시,

"오픈소스DBMS 도입을 위한 성공적인 전략"에 초대합니다.

[행사초청] ️10/28(월) 세종에서 진행하는 공공 IT 담당자를 위한 오픈소스 DB 설명회에 초청합니다.

SKAI Worldwide | 스카이월드와이드 — Mon, 7 Oct 2024 19:00:13 +0900

대전/세종

지역 세미나 행사

[행사초청] ️10/28(월) 세종에서 진행하는 공공 IT 담당자를 위한

오픈소스 DB 설명회에 초청합니다.

[행사초청] ️10/8(화) IT 담당자를 위한 오픈소스 DB설명회에 초청합니다.

SKAI Worldwide | 스카이월드와이드 — Mon, 7 Oct 2024 18:57:28 +0900

[행사초청] ️10/8(화) IT 담당자를 위한 오픈소스 DB설명회에 초청합니다.

한국인삼공사, AgensSQL 도입으로 비용 효율과 성능을 잡은 마케팅 시스템 고도화 전략

SKAI Worldwide | 스카이월드와이드 — Fri, 27 Sep 2024 09:22:08 +0900

한국인삼공사, AgensSQL 도입으로 비용 효율과 성능을 잡은 마케팅 시스템 고도화 전략

한국인삼공사와 해당 프로젝트를 소개해주세요.

"안녕하세요. 한국인삼공사(KGC, Korea Ginseng Corporation)는 대한민국의 대표적인 건강기능식품 기업으로, 정관장이라는 브랜드로도 잘 알려져 있습니다.주로 인삼을 기반으로 한 다양한 제품을 생산하고 있으며, 건강기능식품 시장에서 국내외적으로 높은 인지도를 가지고 있습니다.

이번 ‘KGC 차세대 영업마케팅 시스템 구축 사업’은 최신 IT 기술과 트렌드를 반영하여, 기존의 영업 및 마케팅 관리 시스템을 보다 효율적으로 개선하고자 시작한 프로젝트입니다. 고객 중심의 경영환경을 예측하고, 유연한 사업 확장을 위해 정보 시스템을 고도화하는 것이 핵심 목표입니다. 이를 통해 고객과 내부 사용자 모두에게 더 큰 가치를 제공하고, 마케팅과 영업 관리에서 혁신적인 변화를 이루고자 했습니다."

AgensSQL(아젠스SQL)을 도입하게 된 계기를 말씀해주세요.

KGC는 차세대 영업마케팅 시스템 구축을 통해 기존 시스템의 한계를 극복하고자 했습니다. 특히, 예측기반 경영환경과 유연한 사업 확장을 위해 고도화된 정보화 시스템이 필요했습니다. 이 과정에서 중요한 요소는 성능과 안정성이었고, 동시에 비용 효율성도 큰 과제였습니다.

AgensSQL은 국내의 DBMS로써 오픈소스 PostgreSQL 기반으로 비용의 효율성과 기업 내부 IT 예산을 절감하는 데 적합하였습니다. 비용이 저렴하다고 성능이 떨어질 거란 우려가 있을 수 있는데, 실제로는 빠른 속도와 안정적인 퍼포먼스를 보여 주었습니다. 특히, 다양한 업무 프로세스와 대규모 데이터 처리에서도 안정적으로 작동하여, 트래픽이 급증하는 특수기에도 빠르게 대응할 수 있다는 점에서 신뢰할 수 있었습니다."

적용 이후 달라진 효과가 있으셨나요?

"AgensSQL 도입을 통해 KGC는 고객 관리와 마케팅 측면에서 매우 중요한 변화를 경험했습니다. 가장 큰 변화는 고객 데이터 통합과 포인트 시스템 고도화입니다.기존에는 여러 채널에서 고객 데이터를 각각 관리하다 보니 중복된 정보와 일관되지 않은 데이터 관리 문제가 있었습니다. 하지만 새롭게 구축된 통합 시스템은 모든 채널의 데이터를 하나로 연결해 중복 데이터를 제거하고 고객 생애주기와 행동 정보를 보다 세부적으로 분석할 수 있게 해줬습니다.

이로 인해 고객 맞춤형 마케팅 캠페인을 보다 효과적으로 실행할 수 있게 되었고, 고객 경험의 질이 크게 향상되었습니다. 또한, 실시간 통합 메시지 발송 시스템이 도입되면서 광고성 메시지와 정보성 메시지가 적시에 전달되어 고객 피로도를 줄이면서도 고객과의 소통 효율성을 극대화할 수 있었습니다."

AgensSQL(아젠스SQL)을 써야하는 이유는 무엇인가요?

"KGC의 마케팅 시스템 고도화 사업에서 AgensSQL을 사용하는 것은 비용 효율성과 성능 측면에서 매우 만족스러웠습니다. 오픈소스 기반의 DBMS는 상용 DBMS와 달리 비용을 저렴하게 책정하여 전체 프로젝트 비용을 절감할 수 있으며, 유연성과 확장성이 뛰어나 대규모 마케팅 데이터를 빠르게 처리하고 분석이 가능하였습니다. 특히, 국내 DBMS이기 때문에 설치 이후에도 지속적인 기술 지원 덕분에 최신 기능을 손쉽게 도입할 수 있고, 시스템 고도화 과정에서 발생하는 다양한 요구사항에 맞게 유연하게 대응할 수 있었습니다.

이러한 PostgreSQL기반의 AgensSQL의 강점은 이번 마케팅 시스템뿐만 아니라 다른 산업군에서도 효과적으로 적용될 수 있다고 생각합니다.다양한 비즈니스 환경에서 비용 절감 및 높은 확장성을 갖춘 시스템 구축이 가능하므로, 여러 기업들이 디지털 전환과 데이터 중심 경영을 강화하는 데 있어 큰 도움이 될 것이라 생각합니다. 감사합니다."

AgensSQL 도입으로 철도 운영의 효율성과 비용 절감을 실현한 한국철도공사

SKAI Worldwide | 스카이월드와이드 — Tue, 24 Sep 2024 13:08:36 +0900

AgensSQL 도입으로 철도 운영의 효율성과 비용 절감을 실현한 한국철도공사

한국철도공사와 해당 프로젝트를 소개해주세요.

“안녕하세요. 한국철도공사는 대한민국의 주요 철도 운영을 담당하는 공공기관입니다.국민들이 안전하고 효율적인 철도 서비스를 제공하는 것을 목표로 철도 운영의 모든 측면에서 최고의 서비스를 제공하기 위해 노력하고 있습니다.진행 중인 '철도운영정보시스템(IRIS, XROIS) 고도화 사업'은 철도 운영의 효율성을 높이기 위해 추진하는 중요한 프로젝트입니다.

이번 사업은 운영 관리 시스템을 최신 IT기술로 고도화하여, 철도 운영을 더욱 효율적으로 만들기 위함입니다. 따라서 다양한 분야에서 시스템을 개선합니다. 특히, 수송계획시스템과 열차 운행 관리, 차량 운용 관리 등 철도 운영에 필요한 다양한 시스템을 업그레이드 할 예정입니다.”

AgensSQL(아젠스SQL)을 도입하게 된 계기를 말씀해주세요.

“철도 운영 정보 시스템에서 DBMS는 철도 운행과 관련된 모든 데이터를 효율적으로 관리하고 처리하는 데 핵심적인 역할을 합니다. 따라서 시스템 고도화를 위해서는 빠르고 안정적인 DBMS가 필수적이죠.이를 위해 M00 DB, E00 DB, 그리고 AgensSQL을 성능 평가 대상으로 선정하여 테스트를 진행했습니다.그 결과, AgensSQL이 123/1000초로 가장 빠른 성능을 기록했습니다.

<한국철도공사 - 철도운영시스템 고도화 사업 DBMS 성능평가 결과>

또한, AgensSQL을 제공하는 비트나인의 전문 엔지니어들이 이전 프로젝트에서도 뛰어난 성과를 보여주었기 때문에, 이번 프로젝트에서도 신뢰를 가지고 맡길 수 있었습니다.

이 같은 이유로 AgensSQL을 최종적으로 선택하게 되었습니다.”

적용 이후 달라진 효과가 있으셨나요?

“예전엔 비용 대비 속도적인 면에서 제약이 많았어요.처음에는 상용 DBMS를 사용하는 것이 더 안전할지 고민도 있었지만, 실제 도입 후 결과는 기대 이상이었습니다. AgensSQL은 성능적인 측면에서 철도 운행 데이터를 처리하는 데 있어 빠른 속도와 안정성을 보여주었어요.특히, 실시간 열차 운행 정보와 수송계획 데이터 처리에서 느려짐 없이 원활하게 운영되고 있습니다. 이로 인해 시스템 전반의 반응 시간이 크게 줄어들었고, 데이터 처리 속도가 크게 향상되었습니다. 그리고 오픈소스 기반이다 보니 비용도 절반 이상으로 줄일 수 있다는 큰 장점이 있었습니다.”

AgensSQL을 써야하는 이유는 무엇인가요?

“과거에는 상용 DBMS를 사용했는데 시간이 지남에 따라 시스템의 노후화와 더불어 성능 저하 문제를 겪었습니다.특히 열차 운행 실적 데이터, 수송 대안 시뮬레이션 등 대규모 데이터를 실시간으로 처리해야 하는 상황에서 병목 현상이 발생하곤 했죠. 이로 인해 긴급 상황에서의 대응 속도가 느려지거나 계획 수립에 차질을 빚는 경우도 있었습니다.AgensSQL은 기존 시스템에 비해 데이터 처리 속도가 빨라, 데이터 분석과 실시간 처리가 원활해졌습니다. 또한,AgensSQL을 제공하는 비트나인은 뛰어난 기술 인력을 보유하여 문제 발생했을 때 오셨던 기술자 분들이 잘 대응해주셔서 안심하고 믿고 맡길 수 있었습니다. 마지막으로 기존 사용했던 DBMS는 성능 문제뿐만 아니라 비용적인 부담도 있었습니다. 특히, 유지보수와 확장에 많은 비용이 들었는데, AgensSQL로 전환하면서 이 부분이 크게 개선되었습니다. 좋은 DBMS를 만들어주셔서 감사하며, 빠른 현장 지원 등 서비스도 최적의 선택이었다고 생각됩니다.”

️9/4(수) 오후 2시, 6회차 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Wed, 14 Aug 2024 16:45:24 +0900

️9/4(수) 오후 2시, 6회차 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

" PostgreSQL로 대용량 데이터 살펴보기 "

[웨비나 후기] 8/7 글로벌 PostgreSQL 컨트리뷰터가 설명하는 최적화된 백업 및 복구 방법

SKAI Worldwide | 스카이월드와이드 — Mon, 12 Aug 2024 18:07:16 +0900

안녕하세요, 비트나인입니다!

지난 8월 7일, 5회차 PG 기술 웨비나에서는 글로벌 PostgreSQL 컨트리뷰터의

백업 및 복구 방법에 대한 심도 깊은 강연이 진행되었습니다.

데이터베이스 업무에서 백업 및 복구는 핵심적인 분야로,

이 과정이 때로는 복잡하고 도전적일 수 있지만,

데이터베이스를 안정적으로 개발하고 관리하기 위해 반드시 숙지해야 하는 주제입니다.

이번 웨비나에는 백업 및 복구 업무를 담당하고 있는

현업 전문가들이 많이 참여하여 실무에서 유용한 정보를 얻고자 했으며,

PostgreSQL에 대한 높은 관심을 보이는 도입 예정자들도 많이 참석했습니다.

백업 및 복구는 데이터 손실을 방지하고, 시스템의 신뢰성을 유지하기

위한 필수적인 과정이므로, 이러한 실무 경험이 풍부한

글로벌 PostgreSQL 컨트리뷰터의

전문적인 조언과 인사이트는 참석자들에게 큰 도움이 되었습니다.

발표의 주요 내용은 백업 및 복구의 필요성과

어떻게 발견할 수 있는지를 시작하여 데이터베이스 백업과 복구의 기본적인 방법에 대해 설명하고,

각 상황에 따라 어떻게 세부적으로 대응해야 하는지에 대한 실질적인 지침을 제공하였습니다.

특히, 주제의 중요성과 난이도를 고려하여, 세션 중간에 실시간 데모 화면을 활용하여 참가자들이

보다 쉽게 이해할 수 있도록 내용을 구성하였습니다.

이번 웨비나는 영어로 진행되었으며, 영어 자막도 제공하여 참석자들이

보다 편리하게 내용을 따라갈 수 있도록 준비하였는데요.

실시간 웨비나에서 놓친 부분이나 추가적으로 확인하고 싶은 내용이 있을 경우,

웨비나 후 설문을 완료하신 분들께는 웨비나 자료를 제공하여

다시 한 번 유익한 내용을 복습하고 확인할 수 있도록 지원하고 있습니다.

기술 웨비나 참석자분들의 희망주제를 참고하여

빅데이터 처리에 대한 문의가 많았었는데요.

그래서 다음 6회차 웨비나는 ‘PostgreSQL와 대용량 데이터’ 주제로

9월 4일에 진행될 예정입니다.

대용량 데이터의 저장 및 처리를 위한

DBMS의 구성과 개념, 그리고 PostgreSQL 기반의

대용량 DBMS(DW) 솔루션을 소개하는 자리로 마련될 것입니다.

대용량 데이터 처리 시 해결해야 하는 다양한 문제와

전문적인 해결책에 대해 다룰 예정이니, 많은 관심과 참여를 부탁드립니다.

더욱 유익한 정보를 제공하기 위해

언제나 참가자분들의 피드백에 귀기울이며 더 나은 웨비나 콘텐츠를 준비하겠습니다.

감사합니다!

#5 글로벌 PostgreSQL 컨트리뷰터가 설명하는 백업 및 복구 방법 다시보기

[웨비나 후기] 7/24 HA 구성 및 Replication 구성 방법

SKAI Worldwide | 스카이월드와이드 — Thu, 1 Aug 2024 12:45:12 +0900

안녕하세요, 웨비나 소식으로 다시 돌아온 비트나인입니다!

지난 7월 24일에 진행했던 4회차 웨비나 소식을 전해드립니다.

이번 웨비나는 두 명의 연사자가 각 세션을 준비하여 두 가지 컨텐츠로 구성했습니다.

첫 번째 세션에서는 PostgreSQL 환경의

HA(High Availability: 고가용성) 구성 요소에 대해 심층적으로 다루었고,

두 번째 세션에서는 데이터 저장의 필수 요소인 Replication에 대해 소개하는 시간을 가졌습니다.

지난 2회차 웨비나에서 소개했던 HA 관련 내용에 대한

참석자분들의 뜨거운 질문들을 반영하여,

이번 웨비나에서는 HA 구성 요소를 더욱 깊이 있게 다루게 되었습니다.

이는 참가자분들이 포스트그레SQL 환경에서 고가용성을

어떻게 구현할 수 있는지에 대한 구체적인 이해를 돕기 위해서였습니다.

특히, 다양한 HA 솔루션과 그 구성 방법에 대해 상세히 설명하고,

실무에서 겪을 수 있는 문제들과 그 해결 방법을 함께 논의했습니다.

두 번째 세션에서는 데이터 저장의 필수 요소인 Replication에

대해 다루었습니다. Replication은 데이터베이스의 가용성과 안정성을 높이는

중요한 기술로, 이를 통해 데이터 유실을 방지하고 시스템의 복구 시간을 최소화할 수 있습니다.

이번 세션에서는 Replication의 기본 개념부터 다양한 구성 방법,

그리고 실무에서의 활용 사례까지 폭넓게 다루었습니다.

회차가 거듭될수록 더욱 심화된 내용으로 구성되다 보니,

현재 Postgres를 사용 중인 참석자의 비율이 전 회차 대비 높아졌습니다.

이는 포스트그레스를를 사용하는 실무자들이 현실적으로 겪는 다양한 문제점과 그 해결 방법에

대한 자료가 온라인에서는 한계가 있기 때문에,

이런 기술 웨비나를 통해 다양한 방법과 가이드를 제공받는 것이 중요하기 때문입니다.

웨비나 후에는 전문 개발자들과의 질의응답 시간을 통해 실무에서의

고민을 직접 해결할 수 있는 기회를 제공하여, 참석자분들께 큰 도움이 되었습니다.

웨비나를 진행하면서 참가자분들의 질문이

실시간으로 올라오면 저희가 답변을 드리고 있는데요,

그 중 가장 인상 깊었던 질문들은 다음과 같습니다.

HA 구성 시 권장하는 LB(Load Balancing)는 무엇이 있는지,

Replication 기능에서 Primary/Standby로 구성되었을 때

인스턴스가 다운되더라도 정상적으로 동작하는지, 정상적 동작이 불가하다면

어떤 조치를 해야 하는지 등 현실적인 고민들이었습니다.

이러한 질문들은 웨비나를 진행하는 저희에게도 소중한 피드백이 되어,

더 나은 웨비나 컨텐츠를 준비하는 데 큰 힘과 도움이 됩니다.

뜨거운 성원에 힘입어, 다음 5회차 웨비나는 글로벌 PG 컨트리뷰터가 진행하는

PostgreSQL 환경에서의 백업 및 복구에 대한 웨비나가 예정되어 있습니다.

DB를 운영하면서 가장 많이 부딪히는 하드웨어 고장, 데이터 유실, 보안 문제에

대해 경력이 많은 전문가가 현실적이고 효율적인 방법을

소개할 예정이오니 많은 관심과 참여 부탁드립니다.

감사합니다.

#4 HA 구성 및 Replication 구성 방법 다시보기

️8/7(수) 오후 2시, 5회차 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Thu, 25 Jul 2024 14:35:46 +0900

️8/7(수) 오후 2시, 5회차 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

"글로벌 PostgreSQL 컨트리뷰터가 설명하는 최적화된 백업 및 복구 방법"

[웨비나 후기] 7/10 지속 가능한 데이터베이스 PostgreSQL, Failover와 Failback의 모든 것

SKAI Worldwide | 스카이월드와이드 — Thu, 25 Jul 2024 11:12:02 +0900

안녕하세요, 새로운 주제를 가지고 돌아온 비트나인 웨비나 후기입니다.

지난 7월 10일, 저희는 세 번째 기술 웨비나를 진행했습니다.

이번 웨비나는 ‘PostgreSQL의 Failover와 Failback의 모든 것’을 주제로 하였으며,

많은 관심과 호응 속에 성공적으로 마무리되었습니다.

비록 다소 복잡할 수 있는 주제였지만,

세부적인 기술 설명과 실시간 데모를 통해 참가자들에게 큰 도움이 되었습니다.

이번 웨비나는 ‘Preface, Patroni, Failover와 Failback 설명과

타 DB와의 이중화 비교’를 통해 PostgreSQL의 유연성과 구성 가능성, 다양한 백엔드 지원

등에 대해 알아보는 시간을 가졌습니다.

특히, 실시간 데모 세션은 참석자들에게 매우 유익한 시간이었습니다.

실제 Failover와 Failback의 동작을 시연하면서 참석자들이 이론을

보다 쉽게 이해할 수 있도록 도왔고,

실무에서의 적용 가능성을 직접 체험할 수 있는 기회를 제공했습니다.

이번 주제는 입문자들에게는 다소 생소하거나 어려울 수 있지만,

Failover와 Failback에 대한 높은 관심을 가지고 있던 참석자들에게는

매우 유익하다는 피드백을 많이 받았습니다.

참가자들 중 상당수가 실무에서 이와 같은 기능들을 자주 사용해야 하기 때문에,

실질적인 도움이 되었다는 긍정적인 반응을 보내주셨습니다.

또한, 웨비나 발표 후에는 사전에 준비한 질문과 답변들을 통해 참가자들의 궁금증을 해소하고,

현장에서 실시간으로 질문을 받아 소통하는 시간을 가졌습니다.

이번 웨비나의 재참석률은 62%에 달했으며,

이는 첫 회부터 지속적으로 관심을 가져주신 덕분이라고 생각합니다.

재참석률이 이렇게 높은 것은 참석자들이 저희 웨비나에 대해

지속적으로 관심을 갖고 있다는 것을 보여주는 좋은 지표입니다.

이러한 뜨거운 관심에 힘입어, 다음 웨비나에서는 ‘PostgreSQL의 고가용성(HA) 구성 요소와 복제(Replication) 구성 방법’에 대해 심화된 내용을 준비할 예정입니다.

지난 2회차 웨비나에서 받았던 피드백을 반영하여 더욱 깊이 있는 내용을 제공하고자 합니다.

다음 주제에 대해서도 많은 기대와 관심을 부탁드리며, 여러분의 적극적인 참여를 기다립니다.

다음 웨비나에서도 더욱 유익하고 알찬 내용으로 찾아뵙겠습니다.

많은 관심과 참여 부탁드립니다!

#3 지속가능한 데이터베이스 PostgreSQL, Failover와 Failback의 모든 것 다시보기

DBA를 위한 PostgreSQL 17 시스템 카탈로그 업데이트

SKAI Worldwide | 스카이월드와이드 — Mon, 22 Jul 2024 13:00:40 +0900

작성자: 권기순 수석_DB R&D센터-Core OSS R&D팀

PostgreSQL(포스트그레SQL) 17 beta Release를 통해 우리는 아래 주된 기능들이 강화되었다는 것을 확인할 수 있다.

VACUUM 성능 강화
인덱스 알고리즘 강화를 통한 쿼리 최적화
Logical Replication 기능 강화
JSON

이러한 업데이트 과정에서, 데이터베이스의 메타데이터를 저장하고 관리하는 데 사용되는 시스템 카탈로그(pg_catalog)도 일부 업데이트 되었다.

이 글에서는 PG 17의 업데이트된 시스템 카탈로그에 대해 알아보고, PG16과 비교했을때 어떤 변화가 있는지, DBA입장에서 활용할 수 있는 것들이 무엇이 있는지 알아보도록 한다.

What is System Catalog(pg_catalog)?

그 전에 우리는 시스템 카탈로그가 무엇인지 좀 더 자세히 알고 넘어가보도록 하자.

Postgres 17 문서에는 pg_catalog에 대하여 다음과 같이 설명하고 있다.

The system catalogs are the place where a relational database management system stores schema metadata, such as information about tables and columns, and internal bookkeeping information.

시스템 카탈로그는 관계형 데이터베이스 관리 시스템이 표 및 열에 대한 정보, 내부 부기 정보 등 스키마 메타데이터를 저장하는 곳이다.

결론부터 말하자면, 시스템 카탈로그는 데이터베이스 내부 정보를 여러 형태로 저장되는 곳이며, 다양한 DBMS 태스크를 관리하고 수행하는 데 활용 되지만, 일반적으로 사용자가 직접 조작하는 것은 바람직하지 않다는 것이 핵심 내용이다.

시스템 카탈로그의 특징

PostgreSQL의 시스템 카탈로그는 일반 테이블로 구성되어 있다.
직접 시스템 카탈로그를 변경(테이블을 삭제, 생성, 열 추가, 값 삽입/수정 등)하는 작업을 한다면, 시스템을 엉망으로 만들 수 있기 때문에 일반적으로 사용자가 직접 시스템 카탈로그를 변경해서는 안된다.
직접 시스템 카탈로그를 변경하는 대신 SQL 명령어를 사용해야 한다. 예를 들어 CREATE DATABASE 명령어는 pg_database 카탈로그에 행을 삽입하고 실제 디스크에 데이터베이스를 생성한다. 일부 특수한 경우에는 시스템 카탈로그를 직접 조작해야 할 수 있지만, 점점 더 많은 작업들이 SQL 명령어로 제공되면서 이러한 필요성은 점점 감소하고 있다.

시스템 카탈로그의 활용

PostgreSQL 서버에서 쿼리 최적화, 액세스 제어 및 개체 확인에 사용 가능하다.
사용자(application 사용자 또는 특정 tool)가 메타데이터를 조회하여 데이터베이스의 구조를 이해할 수 있다.
유지관리 및 관리: 인덱싱, 권한 및 스키마 변경과 같은 데이터베이스 유지관리 작업에 필요한 정보를 제공한다.

최적화/튜닝: 데이터가 저장되고 액세스되는 방식에 대한 통찰력을 제공하여 성능 튜닝을 돕는다.
보안 감사: 역할과 권한을 검토하여 적절한 액세스 제어를 보장한다.

pg_catalog changes in PG 17

이제 본격적으로, PG 17에서는 어떤 카탈로그들이 어떻게 변화되었는지 알아보도록 하자.

1. Optimizer 영역

pg_stats

PostgreSQL 6.x부터 pg_statistic이라는 시스템 카탈로그로 시작한 pg_stats는 테이블 및 인덱스의 통계 정보(데이터 분포, 유니크 값 개수, 상관관계 등)를 저장하는 시스템 카탈로그이다. pg_stats는 PostgreSQL의 쿼리 옵티마이저가 쿼리 계획을 수립할 때 사용된다.

PG17 업데이트로 pg_stats에 범위 유형(range-type) 히스토그램 정보를 보고하기 위한 칼럼들이 새로 추가되었다.

칼럼	자료형	설명
range_length_histogram	anyarray	범위 유형 열의 비어 있지 않은 범위 값과 비어 있지 않은 범위 값의 길이를 나타내는 히스토그램. (범위 유형이 아닌 경우 Null) 범위 경계의 포함 여부에 관계없이 subtype_diffrange 함수를 사용하여 계산된다.
range_empty_frac	real	값이 빈 범위인 열 항목의 비율(범위가 아닌 유형의 경우 Null)
range_bounds_histogram	anyarray	비어 있지 않은 범위 값과 널이 아닌 범위 값의 하한과 상한을 나타내는 히스토그램(범위가 아닌 유형의 경우 Null) 이 두 히스토그램은 범위들의 단일 배열로 표현되며, 그 범위들의 하한은 하한의 히스토그램을 나타내고, 상한은 상한의 히스토그램을 나타낸다.

아래 예제를 통해 새로 추가된 칼럼을 활용해 볼 수 있다.

postgres=# -- 테이블 생성
postgres=# CREATE TABLE test(r int4range);
CREATE TABLE
postgres=# -- 1부터 10,000까지의 숫자를 생성하고, 각 숫자에 대해 int4range 타입의 랜덤 범위 값을 생성하여 test 테이블에 삽입
postgres=# INSERT INTO test
postgres-# SELECT int4range((random()*10)::integer,(10+random()*10)::integer)
postgres-# FROM generate_series(1,10000);
INSERT 0 10000
postgres=# SET default_statistics_target = 10; -- 통계 정보 수집 대상 수를 10으로 설정
SET
postgres=# -- test 테이블에 대한 통계 정보를 수집
postgres=# ANALYZE test;
ANALYZE
postgres=# -- pg_stats 시스템 카탈로그에서 test 테이블의 통계 정보를 조회
postgres=# SELECT range_length_histogram, range_empty_frac, range_bounds_histogram FROM pg_stats WHERE tablename = 'test' \gx
-[ RECORD 1 ]----------+------------------------------------------------------------------------------------------------------
range_length_histogram | {1,5,6,8,9,10,11,12,14,15,20}
range_empty_frac | 0.0026666666
range_bounds_histogram | {"[0,10)","[1,11)","[2,12)","[3,13)","[4,14)","[5,15)","[6,16)","[7,17)","[8,18)","[9,19)","[10,20)"}

2. Migration 영역

pg_stat_bgwriter

PostgreSQL은 데이터 무결성을 유지하기 위해 모든 데이터 변경 사항을 먼저 WAL(Write-Ahead Log)에 기록한다. background writer 프로세스는 이 WAL 레코드를 주기적으로 실제 데이터 파일에 기록하는 역할을 하며, 이를 통해 데이터베이스 시스템의 안정성과 성능을 향상시킬 수 있다.

PostgreSQL 8.3부터 도입된 pg_stat_bgwriter 뷰는 background writer 프로세스의 활동을 모니터링하여 background writer 프로세스의 다양한 활동 데이터를 확인 할 수 있게 되었고, 데이터베이스 성능과 안정성을 이해하는데 도움을 주기 시작하였다. 예를 들어, background writer 프로세스가 지연되거나 과도한 I/O 활동을 하는 경우 pg_stat_bgwriter를 통해 성능 문제의 원인을 파악할 수 있다.

이번 PG 17의 업데이트를 통해 pg_stat_bgwriter의 buffers_backend 칼럼과 buffers_backend_fsync 칼럼은 pg_stat_io의 특정 칼럼들과 유사하게 중복되어 제거되었다.

PG16의 pg_catalog.pg_stat_io뷰를 보면 다음과 같은 칼럼이 있다.

칼럼	자료형	설명
buffers_backend	bigint	op_bytes에 지정된 각각의 크기인 쓰기 연산 횟수.
fsyncs	bigint	fsync 호출 수. 이것들은 컨텍스트 노멀에서만 추적된다.

그리고 PG16의 pg_stat_bgwriter 뷰를 살표보면 아래와 같은 칼럼들을 확인할 수 있다.

칼럼	자료형	설명
buffers_backend	bigint	백엔드(세션) 프로세스가 직접 기록한 총 버퍼 수.
buffers_backend_fsync	bigint	백엔드(세션) 프로세스가 직접 fsync 작업을 한 회수 (일반적으로 백엔드(세션) 프로세스가 공유 버퍼를 디스크로 내려 쓰더라도, 이 동기화 작업은 writer 프로세스가 담당한다. 즉 writer 프로세스의 fsync 작업 부하량을 파악하는데 도움이 된다.)

위 두개의 표를 통해 각뷰의 특정 칼럼들이 서로 유사성을 가지고 있다는 것을 확인할 수 있다.

또한 PG 17 업데이트를 통해 아래 예제와 같이 buffers_backend 칼럼과 buffers_backend_fsync 칼럼 등이 제거된 모습을 확인할 수 있다.

postgres=# SELECT * FROM pg_stat_bgwriter\gx
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed | 124 -- pg_stat_checkpointer 관련 칼럼으로 이동.
checkpoints_req | 10 -- pg_stat_checkpointer 관련 칼럼으로 이동.
checkpoint_write_time | 3370 -- pg_stat_checkpointer 관련 칼럼으로 이동.
checkpoint_sync_time | 14 -- pg_stat_checkpointer 관련 칼럼으로 이동.
buffers_checkpoint | 75 -- pg_stat_checkpointer 관련 칼럼으로 이동.
buffers_clean | 0
maxwritten_clean | 0
buffers_backend | 9 -- pg_catalog.pg_stat_io에 존재하여 제거.
buffers_backend_fsync | 0 -- pg_catalog.pg_stat_io에 존재하여 제거.
buffers_alloc | 2935
stats_reset | 2024-07-12 16:55:11.046794+09

pg_stat_slru

이전에는 SLRU(Simple Least Recently Used) 관련 정보를 확인하기 위해 로그 파일 분석이나 내부 함수 호출 등 복잡한 방법을 사용해야 했다. 이로 인해 SLRU 캐시 상태를 실시간으로 모니터링하고 문제를 진단하기 어려웠다.

또한 SLRU 캐시 상태에 대한 가시성 부족으로 인해 SLRU 캐시 크기, 교체 정책 등 SLRU 관련 매개변수에 대한 튜닝이 어려웠다. 그래서 DBA는 SLRU 캐시 상태를 쉽게 확인하고 모니터링할 수 있는 기능을 요구했고, PostgreSQL 13에서 pg_stat_slru 뷰를 도입했다. 이를 통해 SLRU 캐시 상태에 대한 가시성을 크게 향상시키고, SLRU 튜닝을 용이하게 만들었다.

이번 PG17 업데이트에는 SLRU 버퍼 크기를 구성하기 위해 몇 개의 GUC를 추가하는 향후 패치에 적용될 이름과 일치시킬 목적으로 pg_stat_slru 뷰의 SLRU 칼럼 이름이 변경되었다. 또한 이 변경과 관련하여 pg_stat_reset_slru() 함수의 입력값도 변경된 칼럼 이름을 사용해야 한다. 이번 변경은 PG17 이전버전과 하위호환성 문제를 야기시킬 수 있으니 DBA입장에서는 이 점을 특히 주의해야 한다.

PG 16과 PG 17의 pg_stat_slru.name을 비교해 보면 아래와 같다.

PG 16	PG 17
postgres=# SELECT name FROM pg_stat_slru; name ----------------- CommitTs MultiXactMember MultiXactOffset Notify Serial Subtrans Xact other (8 rows)	postgres=# SELECT name FROM pg_stat_slru; name ------------------ commit_timestamp multixact_member multixact_offset notify serializable subtransaction transaction other (8 rows)

pg_attribute

pg_attribute 테이블은 PostgreSQL의 핵심 시스템 카탈로그 테이블로, 데이터베이스 객체의 열 정보를 제공하고 있다. 이번 PG17 업데이트에서는 pg_attribute.attstattarget 및 pg_statistic_ext.stxstattarget칼럼의 기본 통계 대상을 NULL로 나타내도록 변경되었다.

먼저 pg_attribute.attstattarget 및 pg_statistic_ext.stxstattarget 칼럼에 대해 아래 표로 간략히 알아보자.

pg_attribute.attstattarget

pg_statistic_ext.stxstattarget

* ANALYZE를 통해 이 칼럼에 대한 축적된 통계의 세부 수준을 제어한다.
* 0 값은 통계를 수집하지 않아야 함을 나타낸다.
* null 값은 시스템 기본 통계 대상을 사용하라는 의미이다.
* 양의 값은 정확히 무엇을 의미하는지는 데이터 유형에 따라 다르다.
* 스칼라 데이터 유형의 경우 수집할 "가장 일반적인 값"의 목표 개수와 생성할 히스토그램 바이너리들의 목표 개수이다.

* 이 통계 오브젝트에 대해 ANALYZE 별로 누적된 통계의 세부 수준을 제어한다.
* 0 값은 통계를 수집하지 않아야 함을 나타낸다.
* null 값은 참조되는 열의 통계 대상 중 최대 값을 사용하거나 시스템 기본 통계 대상을 사용하도록 지시한다.
* 양수 값은 수집할 "가장 일반적인 값"의 목표 개수를 결정한다.

이전에는 이 두 칼럼의 기본값이 -1이었는데, 이는 통계 수집을 하지 않는다는 의미였다. 하지만 -1이라는 값은 0값과 혼란을 줄 수 있기 때문에, 이를 -1에서 NULL로 변경하여 기본적으로 통계 수집을 하지 않는다는 것을 명확히 하였다.

PG 16의 pg_attribute.attstattarget 및 pg_attribute.stxstattarget 칼럼을 보면 attnotnull항목이 true로 설정되어 있어 NULL 설정이 불가능 했지만, PG 17의 칼럼을 보면 false로 설정되어 NULL 값의 설정이 가능하다는것을 확인할 수 있다.

PG 16	PG 17
postgres=# select attname,attnotnull from pg_catalog.pg_attribute where attname = 'attstattarget' or attname='stxstattarget'; attname \| attnotnull ---------------+------------ attstattarget \| t stxstattarget \| t (2 rows)	postgres=# select attname,attnotnull from pg_catalog.pg_attribute where attname = 'attstattarget' or attname='stxstattarget'; attname \| attnotnull ---------------+------------ attstattarget \| f stxstattarget \| f (2 rows)

아래 예제를 통해 pg_attribute.attstattarget 및 pg_statistic_ext.stxstattarget 칼럼이 어떻게 변화되었는지 확인해볼 수 있다.

postgres=# -- test 테이블 생성
postgres=# CREATE TABLE test (
postgres(# id SERIAL PRIMARY KEY,
postgres(# col1 INT,
postgres(# col2 VARCHAR(50)
postgres(# );
CREATE TABLE
postgres=#
postgres=# -- 데이터 입력
postgres=# INSERT INTO test (col1, col2) VALUES
postgres-# (1, 'apple'),
postgres-# (2, 'banana'),
postgres-# (3, 'cherry'),
postgres-# (4, 'date'),
postgres-# (5, 'elderberry');
INSERT 0 5
postgres=# -- attstattarget 확인 : default 값이 NULL
postgres=# SELECT attname, attstattarget
postgres-# FROM pg_attribute
postgres-# WHERE attrelid = 'test'::regclass AND attnum > 0;
attname | attstattarget
---------+---------------
id | -1 -- PG 17 이전에는 -1로 표기되어 있었다.
col1 | -1 -- PG 17 이전에는 -1로 표기되어 있었다.
col2 | -1 -- PG 17 이전에는 -1로 표기되어 있었다.
(3 rows)
postgres=# -- STATISTICS 값 변경 후 확인
postgres=# ALTER TABLE test ALTER COLUMN col1 SET STATISTICS 50;
ALTER TABLE
postgres=# SELECT attname, attstattarget FROM pg_attribute WHERE attrelid = 'test'::regclass AND attnum > 0;
attname | attstattarget
---------+---------------
id |
col1 | 50
col2 |
(3 rows)
postgres=# -- statistics 생성
postgres=# create statistics mystat1 on col1,col2 from test;
CREATE STATISTICS
postgres=# -- pg_catalog.pg_statistic_ext 확인 : stxstattarget이 NULL임을 확인할 수 있다.
postgres=# select * from pg_catalog.pg_statistic_ext;
oid | stxrelid | stxname | stxnamespace | stxowner | stxkeys | stxstattarget | stxkind | stxexprs
-------+----------+---------+--------------+----------+---------+---------------+---------+----------
16427 | 16420 | mystat1 | 2200 | 10 | 2 3 | -1 | {d,f,m} |
(1 row)

pg_stat_progress_vacuum

PostgreSQL 9.6이전 버전에서는 PostgreSQL 데이터베이스의 Garbage Collector 역할을 하고 있는 VACUUM 작업의 진행 상황을 추정하거나 로그 파일을 확인해야 했다. 이러한 불편함을 해결하기 위해 PostgreSQL 9.6에서 pg_stat_progress_vacuum 뷰가 처음 도입되어 VACUUM 작업의 진행 상황, 처리된 튜플 수, 남은 작업량 등을 실시간으로 모니터링할 수 있게 되었다.

이번 PG17 업데이트로 pg_stat_progress_vacuum의 max_dead_tuples 칼럼의 이름을 max_dead_tuple_bytes로 변경했고, num_dead_tuples 칼럼의 이름을 num_dead_tuple_ids로 변경헀으며, dead_tuple_bytes 칼럼을 재추가 하였다. 그리고 또한 indexes_total과 indexes_processed 칼럼이 추가되었다.

기존의 max_dead_tuples와 num_dead_tuples 칼럼은 데이터베이스 내에서 사용되지 않는 튜플의 수를 나타낸다. 그러나 실제로 DBA입장에서 관심을 가지는 것은 사용되지 않는 튜플들이 차지하는 디스크 공간의 크기였다. 그래서 max_dead_tuples을 제거하고 max_dead_tuple_bytes 칼럼을 추가하였고, num_dead_tuples을 제거하고 dead_tuple_bytes 칼럼을 추가하여 더 정확한 정보를 제공하게 되었다. 다만, 기존에 삭제된 num_dead_tuples의 경우, 여전히 사용자에게 의미 있는 정보를 제공하기 때문에, num_dead_item_ids라는 이름으로 재추가 하여 데드 튜플 수에 대한 칼럼으로 사용할 수 있게 되었다.

또한 indexes_total과 indexes_processed칼럼이 추가되어 vacuum 작업 중 처리되는 인덱스에 대한 모니터링도 가능하게 되었다.

PG 17의 pg_catalog.pg_stat_progress_vacuum를 보면 PG16의 max_dead_tuples와 num_dead_tuples가 제거되고 max_dead_tuple_bytes, dead_tuple_bytes, num_dead_item_ids가 각각 추가된 것을 확인할 수 있다.

칼럼	자료형	설명
max_dead_tuple_bytes	bigint	maintenance_work_mem을 기반으로 index vacuum cycle을 수행하기 전에 저장할 수 있는 데드 튜플 데이터의 양.
dead_tuple_bytes	bigint	마지막 index vacuum cycle 이후 수집된 데드 튜플 데이터의 양.
num_dead_item_ids	bigint	마지막 index vacuum cycle 이후 수집된 데드 항목 식별자 수.
indexes_total	bigint	vacuum작업이 정리되었거나 정리될 인덱스의 총 개수. vacuuming indexes 단계 또는 cleaning up indexes 단계가 시작되면 확인 가능하다.
indexes_processed	bigint	처리된 인덱스 수. vacuuming indexes 작업 또는 cleaning up indexes작업 때에만 진행된다.

3. Monitoring 영역

pg_stat_checkpointer

기존에는 체크포인트에 대한 발생 시기, 소요 시간, 주기 등을 쉽게 파악하기 어려웠고, 체크포인트 관련 성능 문제를 진단하기 위해서는 로그 파일을 수동으로 확인해야 했다. 또한 체크포인트 과다 발생이나 과도한 I/O 문제, 체크포인트 지연, 중단 등의 문제를 해결하기 위한 최적화가 필요했으나 문제의 원인을 신속하게 파악하기가 어려웠다.

PG17 업데이트에서는 pg_stat_checkpointer 뷰가 새롭게 추가되었다. pg_stat_checkpointer는 체크포인터 프로세스의 활동을 모니터링하는 데 사용된다. DBA는 체크포인터 프로세스를 통해 WAL(Write-Ahead Log) 관리, 버퍼 관리, 체크포인트 수행, 데이터베이스 복구 지원등이 가능해졌다. 이를 통해 데이터베이스의 일관성과 안정성을 유지하는 것이 수월해졌다.

PG 16에는 pg_catalog.pg_stat_checkpointer 정보가 없지만,

postgres=# \d pg_catalog.pg_stat_checkpointer;
Did not find any relation named "pg_catalog.pg_stat_checkpointer".

PG 17에서 pg_catalog.pg_stat_checkpointer 관한 내용 확인이 가능하다.

칼럼	자료형	설명
num_timed	bigint	수행된 예약된 체크포인트 수
num_requested	bigint	수행된 요청된 체크포인트 수
restartpoints_timed	bigint	시간 초과 또는 수행 시도 실패로 인해 예약된 재시작 지점 수
restartpoints_req	bigint	요청된 재시작 지점 수
restartpoints_done	bigint	수행된 재시작 지점 수
write_time	double precision	파일이 디스크에 기록되는 체크포인트 및 재시작포인트 처리 부분에서 소요된 총 시간(milliseconds)
sync_time	double precision	파일이 디스크에 동기화되는 체크포인트 및 재시작포인트 처리 부분에서 소요된 총 시간(milliseconds)
buffers_written	bigint	체크포인트 및 재시작포인트 동안 작성된 버퍼 수
stats_reset	timestamp with time zone	이 통계가 마지막으로 재설정된 시간

아래 예시를 통해 pg_stat_checkpointer 사용법을 알아보자.

postgres=# -- checkpoint 확인
postgres=# SELECT * FROM pg_stat_checkpointer;
num_timed | num_requested | restartpoints_timed | restartpoints_req | restartpoints_done | write_time | sync_time | buffers_written | stats_reset
-----------+---------------+---------------------+-------------------+--------------------+------------+-----------+-----------------+-------------------------------
76 | 7 | 0 | 0 | 0 | 49447 | 51 | 533 | 2024-07-16 16:31:50.167073+09
(1 row)
postgres=# -- checkpoint 생성
postgres=# CHECKPOINT;
CHECKPOINT
postgres=# SELECT * FROM pg_stat_checkpointer;
num_timed | num_requested | restartpoints_timed | restartpoints_req | restartpoints_done | write_time | sync_time | buffers_written | stats_reset
-----------+---------------+---------------------+-------------------+--------------------+------------+-----------+-----------------+-------------------------------
77 | 8 | 0 | 0 | 0 | 49448 | 52 | 533 | 2024-07-16 16:31:50.167073+09
(1 row)
postgres=# -- checkpoint 리셋
postgres=# SELECT pg_stat_reset_shared('checkpointer');
pg_stat_reset_shared
----------------------

(1 row)
postgres=# -- 리셋된 checkpoint 확인
postgres=# SELECT * FROM pg_stat_checkpointer;
num_timed | num_requested | restartpoints_timed | restartpoints_req | restartpoints_done | write_time | sync_time | buffers_written | stats_reset
-----------+---------------+---------------------+-------------------+--------------------+------------+-----------+-----------------+-------------------------------
0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 2024-07-17 17:44:07.178496+09
(1 row)

pg_wait_events

그동안 DBA는 데이터베이스 성능 저하의 원인을 찾기 위해 어떤 리소스에서 대기 상태가 발생하는지 파악해야 했고, 성능 문제의 근본 원인을 찾아내기 위한 대기 이벤트 정보가 필요했다. 이러한 정보가 없으면 문제 해결에 더 많은 시간이 소요되었다.

PG17에서는 대기 이벤트 유형을 확인 할 수 있는 시스템 뷰인 pg_wait_events가 추가되어 데이터베이스의 성능 병목 지점을 신속하게 파악하고, 효과적인 튜닝 및 최적화를 수행할 수 있게 되었다. 또한 이 뷰는 pg_stat_activity에서 보고된 대기 이벤트에 대한 설명을 추가하는 데 유용하기도 하다.

PG 16에는 pg_catalog.pg_wait_events 정보가 없지만,

postgres=# \d pg_catalog.pg_wait_events;
Did not find any relation named "pg_catalog.pg_wait_events".

PG 17에서 pg_catalog.pg_wait_events가 새롭게 추가된 것을 확인 할 수 있다.

칼럼	자료형	설명
type	text	이벤트 유형.
name	text	이벤트 이름.
description	text	이벤트에 대한 설명.

아래 예시를 통해 pg_wait_events를 확인해보자.

postgres=# -- pg_wait_events 확인
postgres=# SELECT * FROM pg_wait_events LIMIT 3;
type | name | description
----------+-------------------+-----------------------------------------------------
Activity | ArchiverMain | Waiting in main loop of archiver process
Activity | AutovacuumMain | Waiting in main loop of autovacuum launcher process
Activity | BgwriterHibernate | Waiting in background writer process, hibernating
(3 rows)
postgres=# -- pg_wait_events와 pg_stat_activity를 join
postgres=# SELECT psa.pid, psa.application_name, psa.wait_event,
postgres-# we.description
postgres-# FROM pg_stat_activity psa
postgres-# JOIN pg_wait_events we
postgres-# ON (psa.wait_event_type = we.type AND
postgres(# psa.wait_event = we.name);
pid | application_name | wait_event | description
-------+------------------+---------------------+--------------------------------------------------------------
92708 | | AutovacuumMain | Waiting in main loop of autovacuum launcher process
92705 | | BgwriterHibernate | Waiting in background writer process, hibernating
92704 | | CheckpointerMain | Waiting in main loop of checkpointer process
92709 | | LogicalLauncherMain | Waiting in main loop of logical replication launcher process
92707 | | WalWriterMain | Waiting in main loop of WAL writer process
92711 | psql | ClientRead | Waiting to read data from the client
(6 rows)

4. Logical Replication 영역

pg_stat_subscription

기존에는 구독 복제의 상태, 지연 시간, 처리 지연 등의 정보를 확인하기 위한 상세한 정보를 찾기 힘들 뿐만 아니라 이를 통한 복제 성능 최적화 및 복제 시스템 관리가 매우 어려웠다.

그리하여 pg_stat_subscription뷰가 PostgreSQL 10부터 도입되어 복제 구독(replication subscription)에 대한 다양한 정보를 통해 DBA가 복제 관련 문제를 진단하고 해결할 수 있게 되었다.

PG 17에서는 논리적 복제 작업자 유형을 쉽게 확인하기 위한 worker_type칼럼이 추가되었다. 기존의 leader_pid 및 reid와 같은 다른 칼럼을 논리적 복제 작업자 유형을 유추 할 수 있었지만 worker_type칼럼을 통해 보다 직관적이고 명확하게 논리적 복제 작업자 유형을 파악할 수 있다.

아래 내용처럼 PG16대비 worker_type 칼럼이 PG17에 새롭게 추가된 것을 확인 할 수 있다.

칼럼	자료형	설명
worker_type	text	구독 작업자(subscription worker) 프로세스의 유형. 가능한 유형은 apply, parallel apply, table synchronization.

worker_type칼럼의 유형에 대해 좀 더 자세히 살펴보면 다음과 같다.

worker_type 칼럼 유형	설명
apply	복제 프로세스가 대상 데이터베이스에 변경 사항을 적용하는 작업을 수행하고 있음을 나타낸다. 즉, 논리적 복제 프로세스가 원본 데이터베이스에서 수신한 변경 사항을 대상 데이터베이스에 순차적으로 적용하고 있는 상태이다.
parallel apply	복제 프로세스가 변경 사항을 병렬로 적용하는 작업을 수행하고 있음을 나타낸다.
table synchronization	복제 프로세스가 초기 데이터 동기화 작업을 수행하고 있음을 나타낸다. 새로운 구독이 생성되거나 구독이 재동기화될 때 이 작업이 수행된다. 테이블의 전체 데이터를 대상 데이터베이스로 복사하는 작업이다.

결론

PostgreSQL 17에서의 시스템 카탈로그(pg_catalog) 개선은 새로운 카탈로그 객체와 열의 추가, 기존 객체의 확장 및 개선 등을 통해 데이터베이스 내부 구조와 메타데이터에 대한 가시성과 접근성이 향상되었다. 이를 통해 보다 효율적인 모니터링, 문제 해결, 튜닝 등이 가능해지면서 DBA와 개발자에게 많은 이점을 제공하게 되었다.

시스템 카탈로그의 지속적인 발전은 PostgreSQL의 확장성과 유연성을 높일 것으로 기대된다. 새로운 기능 및 확장 모듈 개발 시 관련 메타데이터의 노출과 관리가 용이해질 것이며, 카탈로그 정보에 대한 향상된 API 제공 등을 통해 외부 도구와의 통합성도 향상될 것이다.

참고 문헌

PostgreSQL에서 Lock 문제를 찾고 해결하는 방법

SKAI Worldwide | 스카이월드와이드 — Fri, 12 Jul 2024 10:47:44 +0900

작성자: 서준섭 과장_DB 기술센터-DB Tech팀

PostgreSQL에서 Lock 문제를 찾고 해결하는 방법

PostgreSQL은 고급 오픈소스 관계형 데이터베이스 관리 시스템으로, 데이터 무결성과 일관성을 관리하기 위해 Lock에 의존하는 동시성 제어 메커니즘을 제공합니다. Lock은 트랜잭션의 무결성을 유지하는데 필수적이지만, 제대로 관리되지 않으면 장시간 대기와 같은 문제를 야기할 수 있습니다. 이러한 Lock 문제를 식별하고 해결하는 방법을 이해하는 것은 데이터베이스 성능과 신뢰성에 매우 중요합니다. 이 게시물에서는 PostgreSQL에서 Lock 문제를 찾는 방법, Lock을 해제하는 것이 중요한 이유, 그리고 효과적으로 Lock을 해제하는 방법에 대해 설명하겠습니다.

PostgreSQL Lock 이해하기

Lock 문제를 다루기 전에 PostgreSQL에서 사용하는 Lock의 종류를 이해하는 것이 중요합니다:

Row-level Lock: 행(row) 단위로 걸리는 Lock입니다. 트랜잭션이 특정 행을 업데이트 삭제, 또는 특정 방식으로 접근할 때 사용됩니다. Row lock에는 waiting lock이 사용되는데, A라는 테이블에 A라는 세션이 업데이트를 시동했는데, A 업데이트가 끝나기 전까지 B를 업데이트해도 B가 대기를 하게 되는 경우입니다. B는 대기 상태(sleep)로 들어가기 때문에 CPU를 사용하지 않습니다.
Table-level Lock: 테이블 전체에 걸리는 lock입니다. 테이블의 구조를 변경하는 ‘ALTER TABLE’ 명령을 실행할 때 해당 테이블 전체에 잠금이 걸립니다.
No-Waiting Lock: Lock을 요청했을 때 리소스가 이미 잠겨있다면 대기하지 않고 즉시 실패하는 lock입니다. No-waiting lock에는 Spin Lock과 LW Lock (Lightweight Lock)과 같은 PostgreSQL에서 자주 사용되는 두 가지 메커니즘이 있습니다.
Spin Lock은 짧은 시간 동안 반복적으로 확인하는 메커니즘으로 고성능 환경에서 유용하지만, 장시간 lock이 지속되면 CPU를 낭비할 수 있습니다.
Lightweight Lock: LW lock은 Spin lock과 대기 상태를 결합하여 CPU 자원을 더 효율적으로 사용합니다. 스핀 락 부분이 긴 시간 동안 지속될 경우 Spin Lock과 같이 CPU 자원을 낭비할 수 있습니다.

Lock 문제 식별하기

PostgreSQL에서 Lock 문제는 slow query 또는 차단된 트랜잭션 등으로 인해 나타날 수 있습니다. 이러한 문제를 식별하려면 여러 PostgreSQL 시스템 뷰와 도구를 사용해야 합니다.

1. pg_stat_activity: 현재 활성 쿼리와 그 상태에 대한 정보를 제공합니다. Lock을 기다리고 있는 쿼리를 식별하는 데 유용합니다.

결과:

여기서 waiting이 t인 경우, 해당 쿼리가 Lock을 기다리고 있다는 의미입니다.

2. pg_locks: 활성 트랜잭션이 보유한 Lock을 보여줍니다. 어떤 트랜잭션이 Lock을 보유하고 있고 어떤 트랜잭션이 Lock을 기다리고 있는지 식별하는 데 도움이 됩니다.

결과:

여기서 granted가 f인 경우, 해당 트랜잭션이 Lock을 기다리고 있다는 의미입니다.

3. pg_blocking_pids: 지정된 세션을 차단하고 있는 세션의 프로세스 ID를 반환합니다.

결과:

이는 트랜잭션 12346이 트랜잭션 12345에 의해 막히고 있음을 나타냅니다.

4. pg_stat_activity와 pg_locks 조합: 이 뷰를 조합하면 Lock와 그 영향에 대한 종합적인 뷰를 제공합니다.

결과:

Lock 해제가 중요한 이유

Lock 해제가 중요한 이유는 다음과 같습니다:

성능: Lock은 트랜잭션을 대기하게 만들어 쿼리 실행 시간을 늦추고 데이터베이스 성능을 저하시킬 수 있습니다.
CPU 자원 활용: waiting lock과 같이 큐에서 대기하게 되는 lock은 해제될 때까지 순서를 기다리는 동안 Sleep 상태에 빠지기 때문에 서버 자원을 소비하지는 않습니다. 단 Spin Lock, LW Lock과 같은 메모리와 CPU를 점유하는 락은 너무 오랫동안 지속적으로 lock을 유지하다보면 메모리와 CPU 사용량을 증가시킬 수 있습니다. 최악의 경우 시스템이 멈추거나 시스템 전반에 부정적인 영향을 미칠 수 있습니다.
사용자 경험: 데이터베이스에 의존하는 애플리케이션의 경우 Lock 문제는 응답 시간을 느리게 하여 사용자의 편의성을 해칠 수 있습니다.

Lock 해제하는 방법

Lock 문제를 식별한 후에는 이를 해제할 수 있습니다. 다음은 Lock을 해제하는 몇 가지 방법을 소개합니다:

1. 차단된 트랜잭션 종료: Lock을 보유한 트랜잭션을 식별하고 종료합니다. 이는 pg_terminate_backend 함수를 사용하여 수행할 수 있습니다.

결과:

차단된 트랜잭션이 성공적으로 종료되었음을 나타냅니다.

2. Lock 시간 제한 설정: Lock을 기다리는 시간이 너무 오래 걸리는 트랜잭션을 자동으로 종료하도록 Lock 시간 제한을 구성합니다. 이는 lock_timeout 파라미터를 사용하여 설정할 수 있습니다.

이 설정은 트랜잭션이 Lock을 5초 이상 기다리면 자동으로 종료됩니다.

3. 쿼리 최적화: Lock을 최소화하도록 SQL 쿼리를 최적화합니다. 여기에는 인덱싱, 쿼리 재작성, 트랜잭션을 가능한 한 짧게 유지합니다.

Lock 문제를 방지하기 위한 팁

Lock 문제가 발생하지 않도록 하기 위해 다음의 팁을 고려하십시오:

짧은 트랜잭션: 트랜잭션을 가능한 한 짧게 유지하여 장시간 동안 Lock을 보유할 가능성을 줄입니다.
인덱싱: 적절한 인덱싱을 통해 테이블 스캔의 필요성을 줄이고 필요한 Lock 수를 줄입니다.
쿼리 최적화: 쿼리를 최적화하여 효율적으로 실행되고 과도한 Lock을 요구하지 않도록 합니다.
정기 모니터링: 앞서 논의한 뷰와 도구를 사용하여 데이터베이스 Lock 문제를 정기적으로 모니터링합니다.
배치 처리: 대량 업데이트나 삽입이 필요한 경우 이러한 작업을 배치로 수행하여 데이터베이스에 미치는 영향을 줄입니다.

예시와 결과를 통한 설명

위에서 언급한 쿼리와 함께 구체적인 결과를 예시로 제시하면 Lock 문제를 더 명확하게 이해할 수 있습니다. 다음은 다양한 상황에서의 예제와 결과입니다.

1. 현재 활성 트랜잭션 확인

활성 트랜잭션을 확인하는 쿼리를 실행합니다:

결과:

2. 현재 대기 중인 Lock 확인

Lock을 기다리고 있는 트랜잭션을 확인하는 쿼리를 실행합니다:

예상 결과:

3. 차단된 트랜잭션 종료

차단된 트랜잭션을 종료하는 쿼리를 실행합니다:

예상 결과:

markdown

이 결과는 차단된 트랜잭션이 성공적으로 종료되었음을 나타냅니다.

결론

본 아티클에서는 PostgreSQL의 Lock 문제를 식별하고 해결하는 방법에 대해 심도 있게 설명했습니다. 다양한 시스템 뷰와 도구를 사용하여 Lock 문제를 모니터링하고, 적절한 방법을 통해 Lock을 해제하며 Lock 문제를 예방하는 것이 중요합니다. 이러한 접근 방식을 통해 PostgreSQL 데이터베이스의 성능과 신뢰성을 유지하고 개선할 수 있습니다.

[웨비나 후기] 7/4 급부상하는 PostgreSQL 꿀팁과 프로페셔널 서비스

SKAI Worldwide | 스카이월드와이드 — Thu, 11 Jul 2024 17:14:04 +0900

안녕하세요!

지난 7월 4일, '급부상하는 PostgreSQL 꿀팁과 프로페셔널 서비스' 웨비나에 참석한 후기를 여러분과 나누고자 합니다.

이번 웨비나는 IT 업계의 다양한 전문가들이 모이는

테크 전문 웨비나 플랫폼인 토크아이티에서 진행되었습니다.

주제는 'PostgreSQL의 숙명, PG 운영 시 주의사항과 AI를 위한 pgvector 소개'였으며,

마지막으로 전문적이고 체계적인

PostgreSQL 기술지원 서비스인 비트나인의 'PGTS(PostgreSQL Technical Services)'에

대한 설명으로 마무리되었습니다.

특히 많은 관심을 받은 주제는 'PG를 NoSQL DB로 사용하기'와 '트러블 슈팅 가이드'였습니다.

PG 기반의 DB를 운영하거나 개발할 때 발생하는 다양한 문제와 해결책, 그리고 기존 PG 구조를 기반으로 NoSQL DB를 활용할 때 얻을 수 있는 인사이트에 대해 깊이 있는 논의가 이루어졌습니다.

또한, PGTS 서비스에도 뜨거운 관심을 받았는데요.

오픈소스 PostgreSQL 커뮤니티 버전부터 모든 PG 기반의 상용 DB 제품까지 대상으로 기술지원을 하고 있으며, 테크포털 기반으로 글로벌 24x365 무중단 실시간 대응 및 체계적인 장애지원 서비스에 대해 많은 문의가 있었습니다.

이번 웨비나 피드백을 통해 참가자 대부분이 온라인 교육과 웨비나를 통해 필요한 정보를 얻는다고 답변하였습니다.

장소에 구애받지 않고 실시간 소통을 하며 세부적인 궁금증을 해결할 수 있는 공간이기 때문이라고 생각됩니다.

앞으로도 더욱 다양한 웨비나를 통해 알차고 유익한 교육 내용으로 찾아뵙겠습니다.

지속적인 성원에 감사드리며, 곧 다시 뵙기를 기대합니다.

감사합니다.

[토크아이티 웨비나 다시보기]

️7/24(수) 오후 2시, 네번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Thu, 11 Jul 2024 14:47:58 +0900

️7/24(수) 오후 2시, 네번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

PostgreSQL 컨트리뷰터가 설명하는 pgPool의 문제점과 해결방안

SKAI Worldwide | 스카이월드와이드 — Wed, 10 Jul 2024 19:25:42 +0900

작성자: Umar 팀장 ㅣDB R&D센터 l Core OSS R&D TEAM LEADER

PostgreSQL 컨트리뷰터가 설명하는 pgPool의 문제점과 해결방안

PgPool은 PostgreSQL 환경에서 다양한 이점을 제공하는 강력한 미들웨어 솔루션입니다. 특히 고수요 시장에서 PgPool의 활용도가 높습니다. 다운타임으로 인한 재정적 및 평판 손실이 큰 기술 분야에서는 고가용성을 유지하는 것이 매우 중요합니다. 전자상거래 대기업인 쿠팡이나 소셜 플랫폼인 카카오톡과 같은 기업은 수많은 동시 사용자를 보유하고 있습니다. 또한 핀테크 회사인 토스는 계좌 잔액 조회, 거래 내역 등 다량의 읽기 쿼리를 처리합니다. 검색 엔진 및 콘텐츠 플랫폼과 같은 인기 애플리케이션 역시 높은 볼륨의 반복 쿼리를 처리합니다.

PgPool은 다양한 상황에서 유용하게 활용될 수 있습니다. PostgreSQL은 특정 수준을 넘어서는 동시 세션 처리에 한계가 있습니다. PgPool을 통해 connection pooling을 구현하면 데이터베이스 연결을 개설하고 종료하는 데 따르는 오버헤드를 최소화할 수 있습니다. 이는 높은 동시성을 가진 애플리케이션에 매우 중요하며, 빠른 응답 시간과 효율적인 자원 사용을 보장합니다. PgPool은 connection pooling 기능을 제공합니다. 들어오는 클라이언트 요청에 대해 재사용 가능한 데이터베이스 연결을 유지하고 관리합니다.

PgPool은 읽기 전용 쿼리를 여러 standby 노드에 분산시켜, 기본 노드의 과부하를 줄이고 읽기 확장성을 향상시킵니다. 이러한 부하 분산을 통해 기본 노드가 쓰기 작업에 집중할 수 있게 되어 전체 시스템의 성능과 신뢰성이 높아집니다. PgPool은 스트리밍 복제로 구성된 여러 스탠바이 노드에 읽기 전용 쿼리를 분산시킵니다. 이를 통해 PostgreSQL 복제본의 읽기 확장성을 활용하여 읽기 쿼리가 클러스터 전체에 균형있게 분배될 수 있습니다. 쓰기 작업은 여전히 기본 노드에서 이루어져 ACID (Atomicity, Consistency, Isolation, Durability) 속성을 유지합니다. 예를 들어, 은행 앱은 대량의 읽기 작업을 복제본으로 라우팅하여, 기본 노드의 성능에 영향을 주지 않으면서도 거래 내역에 빠르게 접근할 수 있습니다. 이는 특히 은행의 피크 시간대에 매우 중요합니다.

스트리밍 플랫폼이나 티켓팅 서비스와 같은 온라인 서비스는 라이브 이벤트나 티켓 판매 중에 다운타임을 허용할 수 없습니다. PgPool의 고가용성 기능은 이러한 서비스가 노드 장애에도 중단되지 않도록 보장합니다. PgPool의 자동 장애 조치 메커니즘은 기본 노드 장애 시 신속하게 standby 노드로 전환하여, 최종 사용자에게 서비스 연속성을 유지합니다. PgPool은 기본 노드의 상태를 지속적으로 모니터링하고, 장애를 감지하면 자동으로 standby 노드를 기본 노드로 승격하고 연결을 재라우팅합니다.

PgPool은 빠른 쿼리 응답이 필요한 경우에도 매우 유용합니다. 예를 들어, 주요 스포츠 이벤트나 인기 있는 드라마 방영 시기와 같은 피크 시간대에 콘텐츠 플랫폼은 PgPool을 통해 캐시된 쿼리를 빠르게 제공할 수 있습니다. 이를 통해 로드 시간을 줄이고 매끄러운 사용자 경험을 보장할 수 있습니다. PgPool은 데이터베이스 부하를 줄이고 반복된 쿼리에 대한 응답 시간을 단축하여 사용자 경험을 향상시킵니다. PgPool은 이러한 쿼리의 결과를 캐시하며, 이후 동일한 쿼리는 데이터베이스를 다시 조회하지 않고 캐시에서 제공됩니다.

PgPool은 높은 동시성, 읽기 확장성 및 성능 최적화와 같은 PostgreSQL 환경의 까다로운 요구사항을 해결하여 상당한 이점을 제공합니다. 그러나 PgPool을 배포할 때는 기술적 전문 지식과 전략적 계획이 필요한 다양한 문제에 직면하게 됩니다.

PgPool을 구성하려면 수많은 파라미터를 설정해야 합니다. 최적의 성능을 위해서는 이러한 구성에 익숙해지고 파라미터를 적절히 조정하는 것이 중요합니다. Num_init_children, max_pool, health_check_period와 같은 파라미터를 신중하게 조정해야 합니다. 현재 IT 업계에서는 빠른 배포 주기와 지속적인 통합 관행이 일반적이므로, 빠르고 효율적인 PgPool 설정이 요구됩니다. 잘못된 구성으로 인해 성능이 최적화되지 않거나 심지어 다운타임이 발생할 수 있는데, 이는 핀테크 및 이커머스와 같이 리스크가 높은 환경에서는 용납될 수 없습니다.

PgPool의 고가용성 구성이 중요합니다. PgPool이 single point of failure가 되면 전체 데이터베이스 시스템이 취약해질 수 있습니다. 따라서 적절한 고가용성 설정이 필요합니다. 특히 통신, 금융, 전자상거래와 같이 다운타임이 재정 및 평판에 큰 영향을 미칠 수 있는 분야에서는 고가용성이 매우 중요합니다. 이러한 비즈니스 환경에서는 PgPool의 안정성과 가용성이 핵심적인 요소라고 할 수 있습니다.

PgPool은 중개 계층으로 작동하므로 지연 시간과 처리 오버헤드를 유발할 수 있습니다. 이러한 추가 오버헤드는 성능에 부정적인 영향을 미쳐, connection pooling과 로드 밸런싱의 이점을 상쇄시킬 수 있습니다. 이를 개선하기 위해서는 지속적인 성능 모니터링과 PgPool 설정 최적화가 필요합니다. PgPool의 구성 및 튜닝을 통해 지연 시간과 오버헤드를 최소화하여, 전체적인 데이터베이스 시스템의 성능을 향상시킬 수 있습니다. 이를 통해 connection pooling과 로드 밸런싱의 장점을 효과적으로 활용할 수 있습니다

PgPool에는 포괄적인 기본 제공 모니터링 및 디버깅 도구가 부족합니다. 이로 인해 문제를 신속하게 진단하고 해결하기 어려워, 서비스 안정성에 영향을 줄 수 있습니다.

PgPool의 failover 메커니즘은 전용 관리 도구에 비해 기본적인 수준에 머물러 있습니다. 금융 및 통신 등의 산업에서는 신속하고 안정적인 장애 조치가 서비스 연속성 유지에 필수적입니다. 지연되거나 수동으로 이루어지는 장애 조치는 상당한 다운타임과 데이터 불일치를 초래할 수 있습니다. 역동적이고 빠르게 변화하는 IT 환경에서는 신뢰할 수 있는 failover 기능이 부족할 경우, 중요한 운영 중에 예기치 않은 문제가 발생할 수 있습니다.

PgPool의 문제점을 해결하기 위해서는 성능, 가용성, 보안을 저해하지 않으면서도 PgPool의 장점을 완전히 활용할 수 있도록 숙련된 인력과 적절한 도구를 통한 신중한 계획이 필요합니다. 이러한 문제들을 이해하고 해결함으로써, 기술 기업들은 PgPool을 효과적으로 활용할 수 있게 되며, 역동적이고 경쟁적인 시장의 요구사항을 충족하는 고성능, 확장 가능하고 신뢰할 수 있는 데이터베이스 시스템을 유지할 수 있을 것입니다.

PostgreSQL에서의 오라클 사용자를 위한 가이드

SKAI Worldwide | 스카이월드와이드 — Tue, 9 Jul 2024 13:52:27 +0900

작성자: 임상욱 상무- Digital Biz센터

PostgreSQL에서의 오라클 사용자를 위한 가이드

1. PostgreSQL 과 Oracle의 태생적 차이

PostgreSQL과 Oracle DBMS는 각각의 태생적 배경과 철학에 따라 다른 방향으로 발전해왔습니다. PostgreSQL은 커뮤니티 중심의 오픈 소스 프로젝트로 유연성과 확장성이 뛰어나며, Oracle은 상업용 데이터베이스로서 고가용성과 보안을 중시하는 방향으로 발전했습니다. 이러한 차이는 두 DBMS의 기능과 사용 사례에 영향을 미치며, 사용자가 선택하는 기준이 되기도 합니다.

1.1 PostgreSQL의 태생

1.1.1.역사와 배경

PostgreSQL은 1986년 캘리포니아 대학교 버클리에서 시작된 POSTGRES 프로젝트에서 기원했습니다.

원래의 목적은 기존의 Ingres 데이터베이스 시스템을 개선하는 것이었으며, 1996년에 SQL을 지원하게 되면서 PostgreSQL로 이름이 변경되었습니다.

그 태생적인 배경은 유연성과 확장성, 높은 표준 준수 및 안정성을 강조하는 설계 철학을 반영하고 있습니다.

오픈 소스 커뮤니티에 의해 개발되었으며, 현재도 글로벌 커뮤니티 중심으로 발전하고 있습니다.

이러한 오픈소스 특성 덕분에 PostgreSQL은 다양한 데이터베이스 애플리케이션에서 널리 사용되고 있습니다.

1.1.2.철학과 설계 원칙

PostgreSQL은 BSD 라이선스로 시작하여 그를 계승한 독자적인 PostgreSQL License 를 만들어 사용하고 있습니다. 이는 누구나 자유롭게 소스 코드를 수정하고 배포할 수 있다는 것을 의미하며, 오픈 소스 철학을 따르기에 아래와 같은 특징이 있습니다.

확장성: 사용자 정의 데이터 타입, 함수, 연산자 등을 지원하여 확장이 용이합니다.
표준 준수: SQL 표준에 대한 높은 준수율을 자랑합니다.
ACID 준수: 트랜잭션의 원자성, 일관성, 격리성, 지속성을 철저히 준수합니다.
커뮤니티 중심 개발: 다수의 개발자와 사용자에 의해 지속적으로 기능이 추가되고 개선됩니다.

PostgreSQL은 개발자 성향을 가진 사용자들을 대상으로 하기에 다양한 확장성을 지원합니다.

기본적으로 데이터 타입, 연산자들의 확장을 지원하고 또한 엔진부분에서 일부 사용자가 개입을 할수 있도록 Hook 메커니즘을 지원합니다. 아래는 PostgreSQL이 지원하는 Hook의 종류들입니다. 이런 Hook 및 다양한 확장 메커니즘을 통하여 다양한 Extension들이 존재하며 이련 Extension들과 함께 아래 그림과 같은 PostgreSQL Ecosystem을 이루고 있습니다.

General Hooks
Security Hooks
Function Manager Hooks
Planner Hooks
Executor Hooks
PL/pgsql Hooks

[PostgreSQL이 지원하는 확장 Hook]

[PostgreSQL Ecosystem]

표준준수는 확장성과 함께 이야기 될 수 있습니다.

오픈 소스 철학을 바탕으로 다양한 확장을 제공하기 위하여 DBMS Core 자체는 철저한 표준을 준수 하여야 합니다. 철저한 원칙 준수를 통하여 이를 확장 하였을시 이상 동작에 대한 위험성을 줄일 수 있습니다. PostgreSQL은 이런 SQL 과 같은 질의 표준 외에도 다음 장에서 설명할 데이터 처리에 대한 원칙도 철저히 준수하고 있습니다.

1.1.3.주요 특징

PostgreSQL은 Vacuum 기반의 MVCC(다중 버전 동시성 제어)를 통한 높은 동시성 처리를 지원하고, JSON 및 JSONB 타입을 통한 NoSQL 기능을 제공합니다. 또한, JSONB는 빠른 검색을 위해 INDEX를 지원하며, 관련된 다양한 함수와 연산자를 제공합니다.(->, ->>, #>>, jsonb_set, jsonb_each)

현재 PostgreSQL은 GIS 데이터 처리를 위한 PostGIS Extension과 AI 처리를 위한 Vector DB 확장을 제공하는 pgVector extension이 오픈 소스 커뮤니티에서 개발되고 있습니다.

1.2 Oracle의 태생

1.2.1. 역사

Oracle Corporation은 1977년 래리 엘리슨(Larry Ellison), 밥 마이너(Bob Miner), 에드 오츠(Ed Oates)에 의해 설립되었으며 설립 당시 회사의 이름은 Software Development Laboratories(SDL) 였습니다.

이 회사는 미국 중앙정보국(CIA)의 데이터베이스 프로젝트를 위해 설립되었으며, 이 프로젝트의 코드명이 “Oracle”로 시작되었습니다.

초기 개발을 위해 설립자들은 관계형 데이터베이스의 가능성을 보고 IBM의 논문을 기반으로 한 관계형 데이터베이스 시스템을 개발하기로 하였고 이 논문은 에드거 F. 커드(Edgar F. Codd)의 관계형 모델에 대한 개념을 설명하고 있었습니다.

초기 버전은 IBM의 SQL 언어를 구현했으며, 상업적 목적으로 발매되었습니다.

1.2.2. 제품의 발전과 상용화

1979년, Oracle은 Oracle Version 2를 출시했습니다. 이는 세계 최초의 상용 SQL 기반 관계형 데이터베이스 관리 시스템이었습니다. 재미있게도, Version 1은 내부적으로 존재했지만 공식적으로 출시되지는 않았습니다.

1983년, Oracle은 Version 3를 출시했습니다. 이는 C 언어로 다시 작성되었고, 주요 운영 체제에서 사용할 수 있도록 설계되었습니다. 이 버전은 트랜잭션 처리와 다중 사용자 환경을 지원하는 기능을 포함하고 있었습니다.

1.2.3. 글로벌 확장과 기능 강화

Oracle은 계속해서 새로운 기능과 성능 개선을 포함한 버전을 출시했습니다. 특히 Oracle Version 4에서는 읽기 일관성을 제공했고, Version 5에서는 분산 쿼리를 지원했습니다. 1986년, Oracle은 주식 상장을 통해 자본을 확보하고 글로벌 시장으로의 확장을 가속화했습니다.

1992년에 출시된 Oracle 7은 성능과 관리 기능을 크게 향상시켰으며, 저장 프로시저와 트리거, PL/SQL 등 고급 기능을 도입했습니다. 이 버전은 기업 환경에서 널리 채택되어 Oracle을 주요 상용 DBMS로 자리매김하게 했습니다.

1.2.4. 21세기와 클라우드 컴퓨팅

2001년에 출시된 Oracle 9i는 인터넷 애플리케이션을 위한 기능을 강화했으며, Real Application Clusters(RAC)를 도입하여 고가용성과 확장성을 제공했습니다. 이 버전부터 Oracle은 “i”를 통해 “Internet”을 강조했습니다.

2013년에 출시된 Oracle 12c는 “c”가 클라우드를 의미하며, 멀티 테넌트 아키텍처를 도입하여 클라우드 환경에서의 효율성을 극대화했습니다. 이는 하나의 데이터베이스 인스턴스 내에서 여러 데이터베이스를 호스팅할 수 있는 기능을 제공하여 클라우드 서비스 제공자와 대규모 데이터 센터에서 유용했습니다.

Oracle은 지속적으로 새로운 기능과 보안 개선을 도입하고 있으며, 최근 버전에서는 인공지능(AI)과 머신러닝(ML) 기능을 데이터베이스에 통합하는 데 주력하고 있습니다. Oracle Autonomous Database는 자율 운영 기능을 통해 관리 작업을 자동화하고, 성능과 보안을 최적화합니다.

1.2.5 Oracle DBMS의 철학과 설계 원칙

Oracle은 상업용 소프트웨어로서 안정성과 성능을 최우선으로 여깁니다. 이는 대기업과 금융기관 등에서 요구하는 성능과 신뢰성을 충족시키기 위해 설계되었습니다. 그 결과, Oracle은 다양한 산업 분야에서 상업적으로 큰 성공을 거두었습니다.

Oracle은 RAC(Real Application Clusters)와 같은 고가용성 기능을 통해 대규모 트랜잭션을 처리할 수 있도록 설계되었습니다. 이를 통해 사용자들은 중단 없이 안정적으로 시스템을 운영할 수 있습니다.

Oracle은 데이터 보안에 중점을 두어 다양한 보안 기능을 제공합니다. 이는 금융, 의료 등 민감한 데이터를 다루는 산업에서 특히 중요하며, Oracle의 보안 기능은 이러한 요구를 완벽히 충족시킵니다.

Oracle은 ERP, CRM 등 다양한 기업 솔루션과의 통합을 고려하여 개발되었습니다. 이를 통해 기업은 하나의 통합된 시스템에서 모든 데이터를 관리할 수 있어 효율성을 극대화할 수 있습니다.

Oracle은 또한 지속적인 기술 혁신을 통해 클라우드 기반 솔루션을 제공하며, 기업들이 더욱 유연하고 비용 효율적으로 데이터 관리를 할 수 있도록 지원하고 있습니다. 이를 통해 Oracle은 미래의 IT 환경 변화에도 능동적으로 대응하며, 고객들에게 최상의 서비스를 제공하고 있습니다.

2. PostgreSQL에서 데이터 핸들링

2.1 형(Type) 캐스팅에 대한 원칙

PostgreSQL은 개발된 언어인 C 언어와 유사한 원칙을 가지고 있습니다.

C 언어는 Low Level 언어로서, 철저한 표준과 원칙을 준수하여 이를 사용하는 사용자에게 이상 동작을 하지 않도록 유도합니다.

그중 형 캐스팅은 원래의 데이터 타입을 다른 데이터 타입으로 사용하였을때 명시적 혹은 암시적으로 내부에서 일어 나게 됩니다.

다음은 두 DBMS에서 타입 변환의 원칙입니다.

Oracle:

숫자와 문자열 간의 연산 및 비교에서 암시적 타입 변환을 허용합니다.
문자열을 날짜로 암시적으로 변환할 수 있습니다.

PostgreSQL:

숫자와 문자열 간의 연산 및 비교에서 암시적 타입 변환을 허용하지 않으며, 명시적 타입 변환을 요구합니다.
문자열을 날짜로 암시적으로 변환하지 않으며, 명시적 타입 변환을 요구합니다.

그밖의 예시는 아래와 같습니다.

예) 날짜와 숫자간의 연산

SELECT '2024/07/08'::date +1

결과]

2024-07-09

예) 날짜형 문자와 숫자간의 연산

SELECT '2024/07/08' + 1

결과]

ERROR: invalid input syntax for type integer: "2024/07/08"

LINE 1: SELECT '2024/07/08' + 1

SQL state: 22P02

Character: 8

예) 실수형 문자와 숫자간의 비교

SELECT '1.23' = 1;

결과]

ERROR: invalid input syntax for type integer: "1.23"

LINE 1: SELECT '1.23' = 1;

SQL state: 22P02

Character: 8

예)숫자와 Boolean 의 비교

SELECT 1 = true;

결과]

ERROR: operator does not exist: integer = boolean

LINE 1: SELECT 1 = true;

HINT: No operator matches the given name and argument types. You might need to add explicit type casts.

SQL state: 42883

Character: 10

2.2 Schema명에 대한 대소문자 처리

PostgreSQL은 Schema명에 대해 소문자로 처리하며, Oracle은 대문자를 우선하여 처리합니다.

Oracle:

PostgreSQL:

Schema명에 대해 특정하여 저장의 원한다면 따옴표로 묶어서 처리 해야 합니다.

예)

CREATE TABLE "TestTable" ("Column1" VARCHAR(20));

INSERT INTO "TestTable" ("Column1") VALUES ('Hello');

SELECT * FROM "TestTable" WHERE "Column1" = 'Hello';

3. 오라클 사용자가 PostgreSQL 사용시 주의점

Oracle DBMS 사용자가 PostgreSQL을 사용할 때 주의해야 할 점은 여러 가지가 있습니다. 이 두 데이터베이스 시스템은 많은 기능과 개념을 공유하지만, 세부적인 동작 방식과 기능 구현에서 차이가 있습니다. 주요 주의점을 아래와 같이 정리할 수 있습니다.

3.1 데이터 타입 관리

Oracle은 다양한 자동 형변환을 지원하지만, PostgreSQL은 엄격한 형변환 규칙을 따릅니다. PostgreSQL에서는 명시적 형변환을 더 자주 사용해야 합니다.

3.2. Null 처리와 ‘’(Empty String) 처리

Oracle은 빈 문자열(’’)은 Null로 취급됩니다. 즉, 빈 문자열을 삽입하면 Null이 삽입되고, 빈 문자열을 비교하면 Null과 동일하게 취급됩니다.
예를 들어, 빈 문자열을 삽입하려고 하면 그 값은 Null로 저장됩니다. '' IS NULL은 참(True)입니다.

PostgreSQL은 빈 문자열(’’)과 Null은 별개의 값으로 취급됩니다. 빈 문자열을 삽입하면 빈 문자열이 저장되고, 빈 문자열을 비교할 때는 실제로 빈 문자열과 비교됩니다.
빈 문자열은 빈 문자열로 저장되고, Null은 Null로 저장됩니다.’’' IS NULL은 거짓(False)입니다.

3.3. 함수와 패키지

Oracle의 패키지는 PostgreSQL에서는 기본적으로 제공되지 않습니다. PostgreSQL에서 비슷한 기능을 구현하려면 스키마와 여러 함수로 구성해야 합니다.
예시:

Oracle 패키지 예제:
CREATE OR REPLACE PACKAGE my_package AS
PROCEDURE my_procedure;
END my_package;

PostgreSQL에서는 개별 함수로 구현:
CREATE FUNCTION my_function() RETURNS void AS $$
BEGIN
-- 함수 본문
END;
$$ LANGUAGE plpgsql;

3.4. 시스템 뷰와 메타데이터

Oracle의 데이터 사전 뷰(ALL_TABLES, USER_TABLES, DBA_TABLES 등)와 PostgreSQL의 시스템 카탈로그(pg_tables, information_schema.tables 등) 간에 차이가 있습니다.
예시:

Oracle:
SELECT * FROM ALL_TABLES;

PostgreSQL:
SELECT * FROM pg_tables WHERE schemaname = 'public';

3.5. 데이터베이스 링크

Oracle의 DB 링크는 PostgreSQL에서 FDW(Foreign Data Wrapper)로 대체할 수 있습니다.
예시:

Oracle DB 링크:
CREATE DATABASE LINK my_link CONNECT TO remote_user IDENTIFIED BY password USING 'remote_db';

PostgreSQL FDW:
CREATE EXTENSION postgres_fdw;
CREATE SERVER foreign_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'remote_host', dbname 'remote_db');
CREATE USER MAPPING FOR local_user SERVER foreign_server OPTIONS (user 'remote_user', password 'password');
IMPORT FOREIGN SCHEMA public FROM SERVER foreign_server INTO local_schema;

4. 결론

이렇게 오라클과 PostgreSQL은 태생의 차이로 PostgreSQL은 표준과 원칙을 준수하며 확장위주로 발전하였으며 오라클은 상업용 용도로 편의성과 시장의 확장(Internet/Cloud/Grid)을 중심으로 발정 하였습니다.

Oracle 및 포스트그레SQL의 사용자들은 타 DBMS를 사용할 때 이런 특징을 이해하고 사용한다면 한단계 더 발전된 DBMS 사용자가 될것입니다.

[행사스케치] 7/4 비트나인 찐 파트너스데이 2024

SKAI Worldwide | 스카이월드와이드 — Mon, 8 Jul 2024 13:00:06 +0900

안녕하세요, 여러분! 작년에 이어 올해 하반기에 실시한

비트나인 찐 파트너스데이 2024 후기 소식을 전달드립니다.

지난 7월 4일, 비트나인 오피스에서 열린 비트나인 찐 파트너스데이 후기를 전해드리려고 해요. 작년에 이어 올해도 많은 파트너사분들이 참석해 주셔서 정말 감사한 시간이었어요. 이번 행사는 비트나인의 기술과 활용 가이드를 소개하고, 파트너사분들의 궁금증을 해결하는 소통의 장이었습니다.

행사 시작: 인사말과 제품 소개

행사는 비트나인의 강철순 대표님이 따뜻한 인사말로 시작됐습니다.

그 후, 비트나인의 대표 제품 및 서비스에 대한 소개가 이어졌는데요,

특히 AgensSQL과 PGTS(PostgreSQL Tech-support Service)에 대한 설명이 있었습니다.

PGTS는 실시간으로 기술 이슈를 대응할 수 있는 비트나인의 기술 대응 시스템입니다.

덕분에 저희 제품을 사용하는 데 있어 어떤 문제가 생기더라도

신속하게 해결할 수 있다는 점을 강조했죠

기술 세션: 깊이 있는 기술 공유

첫 번째 기술 세션에서는 ‘PG 최적화 마이그레이션 고려사항’과

‘테크 포털 가이드’에 대해 발표했습니다.

PG 기반 DB를 통해 마이그레이션을 진행할 때 고려해야 할 사항들,

그리고 비트나인 제품을 사용할 때 발생할 수 있는 다양한 기술 이슈를

실시간으로 대응하는 방법에 대해 자세히 설명했어요.

특히 비트나인의 테크 포털사이트를 통해 이런 이슈들을

어떻게 해결할 수 있는지 시연도 보여드렸습니다.

파트너 세션: 하이퍼엑셀의 발표

마지막 세션에서는 하이퍼엑셀의 홍성민 수석님이 자사의 AI 기반

반도체 기술에 대해 발표해 주셨어요.

AI 기술이 접목된 반도체의 발전 히스토리와 주요 기술,

그리고 시장에서의 활용 방안에 대해 자세히 알아볼 수 있는 시간이었습니다.

이를 통해 각 파트너사들은 자신들의 업무에 적용할 수 있는 유익한 정보를 얻고,

앞으로 비즈니스 파트너십을 어떻게 발전시킬지에 대해 고민해 볼 수 있었어요.

이벤트와 네트워킹: 즐거운 마무리

긴 발표 세션이 끝난 후에는, 참가자분들을 위해 재미있는 이벤트를 준비했어요.

추첨을 통해 많은 파트너사분들께 5만원 상당의 스타벅스 기프티콘과 차량용 청소기를 증정했습니다.

또한 시원한 맥주와 피자, 치킨, 다과 등 맛있는 음식들을 준비해 두었어요.

라운지에서 자유롭게 앉아 맛있는 다과와 함께 기술 및 비즈니스에 대한 이야기를

나누며 친교를 쌓는 시간을 가졌습니다.

이번 행사는 파트너사분들과 직접 소통하며 현업에서

겪는 고민과 대처사항에 대해 진솔하게 얘기 나눌 수 있었던 소중한 시간이었어요.

비트나인의 현재 기술 현황을 공유하면서

앞으로 어떤 방향으로 나아가야 할지 함께 고민해 볼 수 있는 좋은 기회였습니다.

다음 파트너스데이에는 더욱 발전된 기술과 다양한 파트너사들과의

교류를 통해 비즈니스 협업을 이어나갈 수 있도록 준비하겠습니다.

더욱 멋진 모습으로 다시 찾아뵙겠습니다.

감사합니다.

[후기] 7/2 스타트업을 위한 PostgreSQL DB운영 원데이 클래스

SKAI Worldwide | 스카이월드와이드 — Fri, 5 Jul 2024 14:43:58 +0900

안녕하세요! 스타트업 기업을 대상으로 한

포스트그레SQL DB운영 원데이 클래스 후기를 전해드립니다.

지난 7월 2일, 비트나인 사무실에서 오프라인으로

다양한 산업에 종사하시는 분들을 대상으로

포스트그레SQL DB운영에 관한 원데이 클래스를 진행했습니다.

첫 실시임에도 불구하고 많은 분들의 관심과 참석 덕분에

성공적으로 마칠 수 있었습니다.

비트나인 오피스 4층 입구 전경

클래스 내용은 아래와 같이 3가지로 항목으로 구성으로 진행하였습니다.

1. 포스트그레SQL 고가용성 및 재해복구 :

고가용성(HA), 재해복구(DR)을 중심의 재해복구 방법 및 도입 고려사항.

2. 포스트그레SQL 백업 복구 방안 :

백업 복구에 대한 타입설명과 장애/재해 발생 후 상황에 따라 세부적인 대처방안.

3. 포스트그레SQL 모니터링 방안 :

장애 / 재해를 사전에 예방하기 위한 모니터링 시 사전 고려사항과 세부 조치 방법.

많은분들이 DB를 운영하면서 겪게되는 주요한 사항들을 중심으로

주제로 교육을 진행하였더니

클래스 이후 적극적인 Q&A와 다음 클래스에 대한

많은 관심과 의견들을 남겨주셨는데,

그 중 가장 기억에 남았던 의견은

"실습 기반 혹은 시연 포함 교육"과 "심화 교육 요청"이었습니다.

이런 소중한 피드백을 참고하여, 7월 1일부터 14일까지 온사이트 DB교육 이벤트에

교육 커리큘럼을 3가지 코스(기초운영, 심화운영, 마이그레이션)로 구성하여

참가자들을 모집하고 있으니 뜨거운 관심과 참여 부탁드리겠습니다.

앞으로도 더욱 알차고 유익한 교육 프로그램을 제공할 수 있도록 노력하겠습니다.

다음번 클래스에서도 많은 관심과 참여를 부탁드리며, 지속적인 성원에 감사드립니다.

곧 다시 뵙기를 기대합니다.

감사합니다.

[웨비나 후기] 6/26 #2 실전 코드로 알아보는 How to use pgPool

SKAI Worldwide | 스카이월드와이드 — Tue, 2 Jul 2024 17:21:33 +0900

2주 만에 돌아온 비트나인 웨비나 후기입니다.

지난 6/26 2회차 웨비나를 진행했는데요, 처음 웨비나 보다는 조금 더 안정화 운영 모습을 보여드릴 수 있었던 것 같아 다행입니다.

갈수록 더 나아지는 모습 보여드리겠습니다.

이번에는 웨비나를 시작하면서 지난 설문조사에서 받은 피드백 반영사항을 공유드렸습니다.

바로 아래 내용인데요,

그렇다보니 2회차에도 많은 분들이 설문조사에 참여해 주시고 다양한 의견 주신 것 같아 감사했습니다.

특히 기억에 남는 분은 “어떤 주제라도 좋으니 앞으로 계속 PostgreSQL 기술 관련 세션을 진행해 달라!” 고 하셨습니다.

여러분들이 만들어가는 웨비나라는 생각으로 남겨주신 의견, 소중하게 여기고 반영하고 있으니 앞으로도 많은 관심 부탁드립니다.

금번 웨비나는 실전 코드를 활용한 pgPool을 주제로 발표가 진행되었는데요,

아무래도 개발 쪽 영역이다 보니 조금 어려웠다는 의견이 있었던 것 같습니다.

자주 참여해 주시는 분들을 분석하여 난이도 조절와 주제선정에 신경 써 볼 예정입니다.

그럼 저희는 7월 10일에 있을 3회차 웨비나를 잘 준비하여 다시 돌아오겠습니다.

감사합니다!

#2 실전 코드로 알아보는 How to use pgPool 웨비나 다시보기

PostgreSQL에서의 AI 구현 - pgvector 활용

SKAI Worldwide | 스카이월드와이드 — Tue, 2 Jul 2024 16:23:21 +0900

작성자: 김정한 이사 ㅣDB R&D센터 l Tech Biz. 팀

개요

본 아티클에서는 벡터 데이터베이스를 논의하며, 기본 개념을 넘어 벡터의 주요 연산부터 시작합니다. 특히, 벡터 데이터베이스는 쿼리를 통해 가장 유사한 결과를 비교하고 식별하는 기반이 되는 벡터 유사도를 다룹니다. 필요한 경우에만 수학적 표현과 기하적 표현을 사용하며, 실제 파이썬 코딩 예시를 함께 제공할 예정입니다.

다음 연재에 벡터 임베딩(데이터의 특정 Feature를 포착하는 데이터의 수치적 표현)과 인덱싱 알고리즘, Semantic Search(기본적으로 텍스트의 의미나 이미지에 포함된 개체 등 유사성을 기준으로 검색하는 것)에 대하여 알아보도록 하겠습니다. 이어서 벡터 Indexing 기법들을 알아보고 OSS(Open Source Software) 벡터 데이터베이스들과 PostgreSQL pgvector의 장단점 소개 및 비교 테스트, 마지막으로 벡터 데이터베이스(pgvector)의 LLM과 RAG 응용에 대한 부분을 차례로 다룰 예정입니다.

Vector 연산

벡터 데이터베이스에 저장되는 벡터는 선형대수(Linear Algebra)에서 데이터의 개수나 형태에 따라 크게 스칼라(scalar), 벡터(vector), 행렬(matrix), 텐서(tensor)로 나뉘는 유형중 하나로 스칼라는 숫자 하나로 이루어진 데이터입니다. 벡터는 여러 숫자로 이루어진 데이터 레코드(data record로 array와 같은)이며, 행렬은 이러한 벡터, 데이터 레코드가 여러개인 데이터 집합이라고 볼 수 있습니다. 텐서는 같은 크기의 행렬이 여러 개 있는 것이라고 생각하면 되겠습니다.

Vector 내적/외적

그럼 먼저 벡터의 연산에 대하여 주요한 몇 가지를 알아보도록 하겠습니다. 벡터를 가지고 연산하는 방법은 여러 가지가 있지만 데이터 분석, ML/DL 및 AI와 관련되어서는 벡터의 각 성분을 곱한 후 그 결과를 모두 더하는 내적(Dot Product)과 두 벡터의 성분을 활용하여 새로운 벡터를 생성하는 외적(Cross Product)이 주된 연산법이 있습니다. 파이썬을 사용하여 임의의 두 벡터(array)를 계산해보겠습니다.

* Dot Product는 Inner Product 라고 표현되기도 함.

<Python Vector 연산> * Numpy : 다차원 배열을 쉽게 처리하고 효율적으로 사용할 수 있도록 지원하는 파이썬의 패키지

import numpy as np #Numpy Library

# 3차원 벡터 생성
v1 = np.array([5, 6, 1])
v2 = np.array([6, -1, 2])

# 벡터내적 dot Product
dot_product = np.dot(v1, v2)
print("dotprod.:", dot_product)

# 벡터외적 cross Product
cross_product = np.cross(v1, v2)
print("crossprod.:", cross_product)

결과

dotprod.: 26
crossprod.: [13 -4 -41]

이러한 벡터의 내적(Dot Product)연산은 데이터 분석에서 사용되는 가중합(weighted sum)에서 사용됩니다. 예를 들어 만약 데이터 벡터가 =[ 1,⋯, ] 이고 가중치 벡터가 =[ 1,⋯, ] 이면 데이터 벡터의 가중합을 수식으로 표현하면 다음과 같습니다:

다음으로는 가중평균(weighted average)에 대해 알아보겠습니다. 벡터로 표현된 개의 데이터의 단순 평균은 아래와 같은 수식으로 나타낼 수 있습니다:

이러한 내적연산은 정규화/비정규화 데이터셋에 모두 적합합니다. 추후에 다룰 인덱싱을 위한 유사도(similarity) 측정에도 사용됩니다.

유사도

유사도란 두 벡터가 닮은 정도를 정량적으로 나타낸 값입니다. 두 벡터가 비슷한 경우에는 유사도가 크고 비슷하지 않은 경우에는 유사도가 작아집니다. 유사도 측정에는 내적(Dot Product)이외에도

코사인 유사도(cosine similarity)
유클리드 거리(Euclidean Distance) or L2 Distance
맨해튼 거리(Manhattan Distance) or L1 Distance
해밍 거리(Hamming Distance)
자카드 거리(Jaccard Distance)
피어슨 유사도(Pearson Similarity)

등이 있으며, 벡터 데이터베이스에서 사용자의 쿼리를 받으면 인덱스 벡터를 쿼리 벡터와 비교하여 가장 가까운(유사한) 벡터를 결정하기 위하여 위와 같은 유사도 측정법들이 사용됩니다. 개념적으로 이해하는것이 중요합니다. 아래 이미지는 앞으로 다룰 오픈소스 데이터베이스 PostgreSQL의 벡터 익스텐션인 pgvector의 Github에 주요 기능 중 지원되는 유사도 측정법을 보여줍니다. 위에 나열한 측정법들과 매칭되는 것들도 보입니다.

pgvector에서는 용어를 L1 과 L2를 사용하였는데, Manhattan distance와 Euclidean distance와 같은 의미이며, Manhattan distance는 두 점의 좌표 차이의 절대값의 합이고, Euclidean distance는 두 점 사이의 직선 거리를 말합니다.

그럼, 대표적인 유사도 몇 가지를 알아보도록 하겠습니다. 우리가 직관적으로 생각하는 두 지점간의 직선 거리라는 개념과 유사한 유클리드 거리(Euclidean Distance)부터 알아보도록 하겠습니다.

유클리드 거리(Euclidean Distance)

두 점인 a, b간의 벡터인 Norm의 정의와 벡터의 차의 정의에서 유클리드 거리는 다음과 같은 식을 구할 수 있습니다.

* Norm : 놈(norm)은 쉽게 말해 두 점 사이의 거리를 일반화한 개념으로 ||a|| 로 표현함.(이 외에도 여러가지 Norm이 있음)

* aT : 벡터의 전치(Transpose) 연산을 위하여 열과 행을 바꾸는것.

복잡한 수학식보다는 파이썬 numpy에 선형대수모듈 linalg.norm() 함수로 임의의 두 벡터(array)간 거리를 간단히 계산해보겠습니다.

# using linalg.norm()
import numpy as np

# numpy arrays
point1 = np.array((2, -1, 3))
point2 = np.array((1, 2, 1))

# linalg.norm()을 사용하여 유클리드거리 계산
dist = np.linalg.norm(point1 - point2)

# printing Euclidean distance
print(dist)

결과

3.7416573867739413

다음은 많이 사용되는 코사인 유사도(cosine similarity)를 설명합니다.

코사인 유사도(cosine similarity)

벡터는 크기와 방향을 가지는데, 두 벡터의 방향이 유사할수록 그들이 비슷하다고 간주하며, 이를 측정하기 위해 두 벡터 사이의 각의 코사인값을 사용합니다.

유클리드 거리와 마찬가지로 두 벡터 x,y간의 코사인 유사도를 수학식으로 표현해보면 다음과 같습니다.

여기서 Norm ||x||와 ||y||는 위의 유클리드 거리에서도 논한바와 같이 벡터 x와 y의 크기(길이)입니다. 코사인 유사도의 범위는 -1에서 1까지이며, 1은 동일한 방향(0°), 0은 직교(90°), 그리고 -1은 반대 방향(180°)을 나타냅니다.

여기서 재미있는 점은 단어를 가지고 feature 벡터화 하여 코사인 유사도를 측정할 때는 음수가 나올수 없어 90도일때가 가장 단어간의 관계성이 없습니다. 예를 들어 “happy” 라는 단어를 예로 들자면 비슷한 의미의 “love”같은 단어는 코사인 유사도 1에 가까운 값이 나오고 “monitor” 같은 단어는 관계성이 없으므로 0에 가까운 값이 나온다는 것입니다. 이처럼 코사인 유사도는 자연어처리(NLP)의 텍스트 분석, 추천 시스템, K-Means 클러스터링 알고리즘에도 사용되며 pgvector에서도 사용되는 범용적인 유사도입니다.

뒤에서 임베딩을 다루기 전이지만, 자연어처리(NLP) 모델 Word2Vec에서, 예시로 “Queen”과 “King” 두 단어를 벡터화하면 다음과 같이 수치적으로 표현될 것입니다. 이 벡터들은 2차원 평면에서 아래에 나열된 수치와 같이 유사도가 높고(방향이 유사하게) 표현됩니다.

Queen = [1.5, -0.4, 7.2, 19.6, 3.1, ..., 20.2]
King = [1.5, -0.4, 7.2, 19.5, 3.2, ..., 20.8]

이를 통해 벡터 기반 표현은 수치적 연산이 가능해지며, 센세이션을 일으킨 아래 예제와 같이 단어간 연산이 가능해집니다.

"king − man + woman ≈ queen"

"King"과 "man"의 차이(feature vector)가 "왕족"이라는 것을 나타내며, 이는 "queen"에서 "woman"을 뺀 것이라는 것을 수학적으로 유추할 수 있습니다.

파이썬 코드를 통해 보겠습니다. 앞에 사용한 것과 같이 Python Numpy 의 Norm과 내적(Dot Product)으로 계산할 수도 있지만, 파이썬 M/L Open-source Library Scikit-Learn 1.5 에서 “cosine_similarity( )”함수를 제공하고 있으므로 이를 간편하게 사용해 보겠습니다.

<Python 코사인 유사도>

# using Scikit-learn(sklearn) cosine_similarity()
from sklearn.metrics.pairwise import cosine_similarity

Queen = [[1.5, -0.4, 7.2, 19.6, 3.1, 20.2]]
King = [[1.5, -0.4, 7.2, 19.5, 3.2, 20.8]]

# printing cosine_similarity
print(cosine_similarity(Queen, King))

결과

[[0.99985641]]

스케일변화의 측면에서는 유클리드 거리는 데이터간에 스케일변화가 크지 않을때, 코사인은 스케일차이가 클때 주로 활용된다고 볼 수 있다.

해밍 거리(Hamming Distance)

해밍 거리(Hamming Distance)는 위키백과에 정의를 보면 “블록 부호 이론에서, 해밍 거리(Hamming距離, 영어: Hamming distance)는 곱집합 위에 정의되는 거리 함수이다”라고 되어 있고 “대략, 같은 길이의 두 문자열에서, 같은 위치에서 서로 다른 기호들이 몇 개인지를 센다.” 설명만으로는 조금 복잡하기 때문에 예제를 통한 간단히 계산법을 보면서 개념적인 설명을 하겠습니다.

예제)

'1011101'과 '1001001'사이의 해밍 거리는 2이다. (1011101, 1001001)

'2143896'과 '2233796'사이의 해밍 거리는 3이다. (2143896, 2233796)

"toned"와 "roses"사이의 해밍 거리는 3이다. (toned, roses)

첫번째 예제에서 보이듯 두 집합(2진벡터)내의 XOR 연산을 통한 합산 값이 거리가 되는것을 볼 수 있습니다.

대부분의 벡터는 부동 소수점(Float)으로 표현되다 보니 해밍 거리는 두 텍스트 간의 어법의 차이, 단어의 철자의 차이 또는 임의의 두 이진 벡터 간의 차이와 같은 것을 측정하거나 sparse 벡터간의 차이를 측정하는 데 좋습니다.

* sparse 벡터 : 밀집 벡터와 대비되는 개념으로 ‘희소 벡터(sparse vector)’가 있다. 희소 벡터는 분석 대상인 모든 단어가 가진 모든 속성을 차원으로 설정하여, 대부분의 요소 값이 0인 벡터를 의미한다.

해밍거리는 NLP에 TF-IDF(Term Frequency-Inverse Document Frequency), 협업 필터링(collaborative filtering) 등 추천시스템 데이터 분석에도 사용되고 있습니다.

자카드 거리(Jaccard Distance)

자카드 거리(Jaccard Distance)는 Jaccard coefficient라고도 하며 먼저 자카드 유사도를 계산하고 1에서 자카드 유사도 값을 뺀 값으로 측정됩니다. 두 집합 A, B에 대하여 아래와 같은 수식으로 표현됩니다만, 그림과 함께 아주 간단한 계산으로 쉽게 설명 하겠습니다.

아래 그림과 같이 두 집합간에 합집합 = 12, 교집합 = 3 일경우, 자카드 유사도 = 3/12 (0.25), 즉 자카드 거리는 1-0.25 = 0.75 입니다.

당연한 얘기이지만 두 집합 사이의 교집합이 클수록 유사도가 높습니다.

여기까지 pgvector에서 지원되는 주요유사도에 대하여 이해를 가져 보았습니다.

벡터 데이터베이스는 이미지, 텍스트, 오디오, 센서 데이터와 같은 비정형 / 반정형 데이터를 데이터 객체의 속성에 따라 고차원 벡터 공간에 임베딩하고, 각 벡터 간의 관계를 정의하며 특정 알고리즘(Hashing, Quantization, Graph 등)에 따라 인덱싱하는 방식입니다. 이 과정에서 유사도 측정은 주어진 쿼리에 대해 벡터 데이터베이스가 가장 관련성이 높은(유사한) 결과를 비교하고 식별하는 기초가 됩니다. 따라서 유사도에 대한 이해는 반드시 필요합니다. 본 기고문에서 다루지 않은 유사도나 더 깊은 영역에 관심이 있는 독자들에게는 추가적으로 파헤쳐 보시기를 권장드립니다.

이어서 다음 연재에는 벡터 임베딩에 관해 알아보며 KNN, ANN 검색 알고리즘, 관계형 DBMS의 B-Tree 와 같은 벡터 Indexing으로 Hashing, Product Quantization, Graph 기반한 기법들에 대해 알아보도록 하겠습니다.

PostgreSQL, pg_rewind(Failback)

SKAI Worldwide | 스카이월드와이드 — Tue, 2 Jul 2024 15:33:19 +0900

작성자: 서준섭 과장 ㅣDB R&D센터 l DB Tech 팀

1.pg_rewind 소개

1.1. pg_rewind란?

PostgreSQL 공식 문서에서 pg_rewind는 다음과 같이 소개하고 있습니다.

PostgreSQL 데이터 디렉터리를 자신으로부터 파생된 또 다른 데이터 디렉터리에게 맞춰 동기화합니다.

pg_rewind는 클러스터의 또 다른 복사본에 맞춰 PostgreSQL 클러스터를 동기화 해주는 도구입니다. 이는 클러스터의 타임라인이 분기된 경우에도 적용할 수 있습니다. 일반적인 시나리오는 장애 복구 후 이전의 마스터 서버를 새로운 마스터 서버의 스탠바이로 되돌려주는 것입니다.

pg_rewind를 사용하면 대상 데이터 디렉터리가 원본 데이터 디렉터리의 베이스 백업본과 유사하게 만들어집니다. 다른 백업 방법과 다른 점은, pg_rewind는 변경된 블록만 복사하기 때문에 전체 파일을 복사할 필요가 없다는 것입니다. 또한, 대상 데이터 디렉터리에 없는 릴레이션 파일, 환경 설정 파일, WAL 파일 등은 그대로 복사됩니다. 데이터베이스가 크고 변경 사항이 크지 않는 경우, pg_rewind를 이용한 이 되감기 작업이 다른 구축 방법보다 빠릅니다.

pg_rewind는 source 클러스터와 target 클러스터 간의 타임라인 이력을 조사하여 분기 지점(replication 중단 시점)을 찾아냅니다. 그리고 타겟 클러스터의 pg_wal 디렉터리에서 분기된 시점으로 되돌릴 수 있는 전체 WAL 파일을 찾아냅니다. 이 분기 지점은 source/target 클러스터 또는 두 클러스터 간의 공통된 이전 타임라인에서 찾을 수 있습니다.

전형적인 장애 복구 시나리오에서 target 클러스터는 분기된 지 오래되지 않은 경우가 많습니다. 이 경우에는 문제가 없지만, target 클러스터가 분기된 이후에도 오랜 기간 운영되었다면, source 클러스터 측에서 오래된 WAL 파일이 없을 수 있습니다. 이런 경우에는 직접 해당 WAL 아카이브 파일을 pg_wal 디렉터리로 복사하거나, pg_rewind의 -c 옵션을 사용하여 복사할 수도 있습니다. pg_rewind 명령은 페일오버 용도로만 사용되는 것이 아니라, 대기 서버가 운영 서버로 전환되었다가 다시 대기 서버로 바뀌는 경우에도 사용될 수 있습니다.

pg_rewind 수행 후, 타겟 서버는 데이터의 일관성을 유지하기 위해 WAL 재반영 작업이 필요합니다. 서버가 시작되면 아카이브 복구 모드로 진입하고, 원본 데이터베이스 서버의 마지막 체크포인트 이후에 소스 서버에서 생성된 모든 WAL을 재생합니다. 문제는 필요한 WAL 파일이 없는 경우입니다. 이 상황에서는 pg_rewind 명령으로 이 파일들을 복사할 수 없습니다. 이런 경우, target 서버가 실행될 때 target 데이터 디렉터리 내에 recovery.signal 파일을 만들고, postgresql.conf 파일에서 복구에 필요한 적절한 restore_command 설정을 할 수 있습니다. 이를 통해 target 서버가 필요한 WAL 파일을 복구할 수 있습니다.

pg_rewind를 수행하기 위해서는 target 서버의 postgresql.conf 에서 다음과 같은 요구사항이 충족되어야 합니다:

1. wal_log_hints 옵션이 활성화되어 있어야 합니다.

2. initdb로 클러스터를 초기화할 때 체크섬(checksum)이 활성화되어 있어야 합니다.

또한 full_page_writes 값은 on으로 활성화되어 있어야 합니다. 이 옵션들은 모두 기본값으로 비활성화되어 있습니다. 이러한 설정이 완료되어야 pg_rewind를 성공적으로 수행할 수 있습니다.

[postgres@204b0624983f ~]$ $PGHOME/pg_rewind --help
pg_rewind resynchronizes a PostgreSQL cluster with another copy of the cluster.

Usage:
  pg_rewind [OPTION]...

Options:
  -c, --restore-target-wal use restore_command in target configuration to
                                 retrieve WAL files from archives
  -D, --target-pgdata=DIRECTORY existing data directory to modify
      --source-pgdata=DIRECTORY source data directory to synchronize with
      --source-server=CONNSTR source server to synchronize with
  -n, --dry-run stop before modifying anything
  -N, --no-sync do not wait for changes to be written
                                 safely to disk
  -P, --progress write progress messages
  -R, --write-recovery-conf write configuration for replication
                                 (requires --source-server)
      --config-file=FILENAME use specified main server configuration
                                 file when running target cluster
      --debug write a lot of debug messages
      --no-ensure-shutdown do not automatically fix unclean shutdown
  -V, --version output version information, then exit
  -?, --help show this help, then exit

Report bugs to <pgsql-bugs@lists.postgresql.org>.
PostgreSQL home page: <https://www.postgresql.org/>

1.2 wal_log_hints 파라미터의 역할

wal_log_hints 옵션을 on으로 설정하면 PostgreSQL의 Write-Ahead Logging (WAL) 메커니즘에 변화가 발생합니다. 이 옵션이 활성화되면, 데이터베이스는 힌트 비트(hint bits)를 업데이트할 때마다 WAL에 해당 로그를 기록하게 됩니다. 힌트 비트는 데이터베이스 인덱스 및 기타 메타데이터의 정합성을 유지하는 데 사용됩니다. 이 옵션이 중요한 이유는 다음과 같습니다:

hint bits란?
PostgreSQL의 MVCC 메커니즘은 많은 유용한 기능을 제공하지만 구현 과정에서 몇 가지 혼란스러운 부작용이 발생할 수 있습니다. 그 중 하나는 힌트 비트(hint bits) 처리와 관련된 것입니다.

MVCC는 힌트 비트를 사용하여 데이터의 가시성과 정합성을 관리합니다. 힌트 비트는 커밋되거나 중단된 트랜잭션에 의해 튜플이 생성 및/또는 삭제된 것을 표시하는 데 사용됩니다. 이러한 힌트 비트가 설정되지 않은 튜플의 가시성을 결정하려면 pg_clog 및 pg_subtrans를 참조해야 하므로 비용이 많이 드는 검사 작업이 필요합니다. 반면에 튜플에 비트가 설정된 경우, 해당 상태가 알려져 있어 현재 스냅샷에서 쉽게 계산할 수 있습니다.

문제는 이러한 힌트 비트 처리 과정에서 데이터베이스 테이블에 많은 쓰기 작업이 발생할 수 있다는 점입니다. 즉, 사용자가 데이터베이스 테이블을 단순히 읽기만 하는 경우에도, 힌트 비트 관리를 위한 쓰기 작업이 필요할 수 있습니다. 이는 MVCC 메커니즘의 부작용으로, 데이터베이스 성능에 부정적인 영향을 미칠 수 있습니다.

wal_log_hints 설정으로 인한 변화

WAL 기록 증가:

힌트 비트(hint bits)는 MVCC(Multi-Version Concurrency Control) 구현의 일환으로 사용되며, 레코드의 상태를 추적하는데 사용됩니다.
힌트 비트 업데이트는 주로 커밋된 트랜잭션을 표시하거나 오래된 트랜잭션의 상태를 표시하는 데 사용됩니다.
wal_log_hints를 on으로 설정하면, 이러한 힌트 비트 변경 사항이 WAL에 기록됩니다.
결과적으로 WAL 로그의 크기가 증가할 수 있습니다.

디스크 I/O 증가:

WAL 로그의 크기 증가로 인해 디스크 I/O가 증가할 수 있습니다.
이는 시스템의 성능에 영향을 미칠 수 있으며, 특히 많은 업데이트가 발생하는 워크로드에서 두드러질 수 있습니다.

데이터 무결성 향상:

wal_log_hints가 on으로 설정되면, 클러스터의 데이터를 다른 노드로 이동하거나 복구하는 과정에서 데이터 무결성을 유지하는 데 도움이 됩니다.
이는 주로 고가용성 환경에서 중요한 고려 사항입니다.

pg_rewind 시 wal_log_hints가 필요한 이유

pg_rewind는 PostgreSQL 클러스터를 특정 시점으로 되돌리기 위해 사용되는 도구입니다. 주로 장애 복구 상황이나 스탠바이 서버를 프라이머리 서버로 전환한 후 원래 프라이머리 서버를 다시 동기화할 때 사용됩니다.

pg_rewind가 제대로 작동하려면 두 서버 간의 차이를 식별하고 필요한 변경 사항을 동기화해야 합니다. wal_log_hints가 필요한 이유는 다음과 같습니다:

블록 수준 차이 검출:

pg_rewind는 블록 수준에서 변경된 데이터를 식별합니다. WAL에 힌트 비트 변경 사항이 기록되지 않으면, pg_rewind는 정확한 변경 내역을 파악할 수 없습니다. 이는 데이터 일관성에 문제를 야기할 수 있습니다.

안전한 동기화:

힌트 비트의 변경 사항이 WAL에 기록되면, pg_rewind는 이러한 변경 사항을 인식하고 안전하게 동기화할 수 있습니다. 이는 클러스터의 무결성을 유지하고 데이터 손실을 방지하는 데 필수적입니다.

따라서, wal_log_hints 설정을 ‘on’으로 하는 것은 pg_rewind의 올바른 작동을 보장하고 데이터 일관성과 무결성을 유지하는 데 중요한 역할을 합니다. 이를 통해 PostgreSQL 클러스터의 안정성과 신뢰성을 높일 수 있습니다.

2. pg_rewind 목적

pg_rewind의 목적은 끊어진 Replication을 현재 운영중인 Primary DB와 Data Cluster를 동기화하고 Replication을 재연결하는 것입니다.

새롭운 Replication을 구성하는 간단한 방법으로 pg_basebackup을 고려할 수 있습니다. 그렇다면 pg_rewind가 pg_basebackup과 어떤 차이점과 장점이 있는지 살펴볼 필요가 있습니다. pg_basebackup의 경우 Data Cluster를 완전히 삭제하고 현재 운영 중인 Primary DB의 Data Cluster를 처음부터 물리적으로 복제합니다.

반면 pg_rewind는 source DB가 분기된 시점부터 target DB와의 차이점을 블록 단위로 확인하고 변경된 부분만 추가합니다. 따라서 데이터 용량이 큰 데이터베이스에서 끊어진 Replication을 재구성하는 데 소요되는 시간은 pg_rewind가 월등히 빠르다는 장점이 있습니다. 마찬가지로 pg_rewind를 수행하는 경우 pg_basebackup에 비해 빠른 속도로 failback이 가능하다는 장점이 있습니다.

3. pg_rewind 사용

과정	primary	secondary
primary 기본 설정	listen_addresses = '' archive_mode = on archive_command = 'test ! -f /archive/%f && cp %p /archive/%f' logging_collector = on log_filename = 'postgresql-%Y-%m-%d.log' wal_level = replica synchronous_commit = local wal_keep_size = 32 synchronous_standby_names = '' promote_trigger_file = '/home/agensql/data/trigger.signal' hot_standby = on
primary 기본 설정	host all all 0.0.0.0/0 trust host replication repluser 0.0.0.0/0 trust
primary 기동	ag_ctl start
repluser 생성 및 권한 부여	create user repluser with replication password '1234' login; grant all privileges on database agensdb to repluser;
Replication 초기 구성		pg_basebackup -h 192.168.54.184 -D $PGDATA -U repluser -p 5333 -v -P -R --wal-method=stream
Replication 초기 구성		ag_ctl start
recovery 모드 확인		select pg_is_in_recovery();
wal_reciever 확인	select * from pg_stat_replication;
Primary 장애 상황	ag_ctl stop
Secondary Promote		[방법 2 가지] 1. pg_ctl promote -D $PGDATA 2. vi $PGDATA/postgresql.conf promote_trigger_file = '/home/agens/data/trigger.signal' pg_ctl reload / select pg_reload_conf(); touch /home/agens/data/trigger.signal
DDL 발생		create table test(a int); insert into test select * from generate_series(1,1000);
과정		Single DB
설정 추가	vi postgresql.conf wal_log_hints = on	vi postgresql.conf wal_log_hints = on
재기동 및 설정 등록	ag_ctl start ag_ctl stop	pg_ctl reload
pg_rewind(sync)	pg_rewind --source-server='host=192.168.54.83 port=5333 user=agens dbname=postgres' --target-pgdata=$PGDATA -P -R
	rm $PGDATA/postgresql.auto.conf
설정 추가	vi postgresql.conf primary_conninfo='user=repluser password=1234 host=192.168.54.83 port=5333'
standby.signal 추가	touch $PGDATA/standby.signal
재기동	ag_ctl start
과정	new_secondary	new_primary
recovery 모드 확인	select pg_is_in_recovery();
wal_receiver 확인		select * from pg_stat_replication;

3.1. pg_rewind를 이용한 failback

과정	Primary	Standby
초기 Replication 구성		$PGHOME/pg_basebackup -h 172.18.0.2 -D $PGDATA -U repluser -p 5432 -v -P -R --wal-method=stream
		$PGHOME/pg_ctl start
	select * from pg_stat_replication;	select pg_is_in_recovery();
Primary 서버 장애	$PGHOME/pg_ctl stop
Standby 서버 Read only 확인		create table test123(id int); ERROR: cannot execute CREATE TABLE in a read-only transaction
Standby 서버 Promote		[postgres@204b0624983f ~]$ $PGHOME/pg_ctl promote waiting for server to promote.... done server promoted
과정	DB off	Single (Promote)
테이블 생성 및 데이터 삽입		CREATE TABLE user_activity_log2 ( id SERIAL PRIMARY KEY, user_id INT NOT NULL, activity_type VARCHAR(50) NOT NULL, activity_timestamp TIMESTAMP NOT NULL, activity_details TEXT );
테이블 생성 및 데이터 삽입		DO $$ DECLARE start_id INT := 1; end_id INT := 1000000; -- Adjust this to reach ~1GB data user_id INT; activity_types TEXT[] := ARRAY['login', 'logout', 'purchase', 'view', 'click']; activity_details TEXT; activity_timestamp TIMESTAMP; BEGIN FOR i IN start_id..end_id LOOP user_id := (i % 10000) + 1; -- Simulating 10,000 unique users activity_timestamp := NOW() - (random() * INTERVAL '1000 days'); activity_details := md5(random()::text); INSERT INTO user_activity_log2 (user_id, activity_type, activity_timestamp, activity_details) VALUES (user_id, activity_types[(random() * 4 + 1)::INT], activity_timestamp, activity_details); END LOOP; END $$;
wal_log_hints 설정	vi postgresql.conf wal_log_hints = on
DB 재기동	ag_ctl start ag_ctl stop
pg_rewind 수행	$PGHOME/pg_rewind --source-server='host=172.18.0.3 port=5432 user=postgres dbname=postgres' --target-pgdata=$PGDATA -P -R pg_rewind: connected to server pg_rewind: servers diverged at WAL location 0/630000A0 on timeline 2 pg_rewind: rewinding from last common checkpoint at 0/63000028 on timeline 2 pg_rewind: reading source file list pg_rewind: reading target file list pg_rewind: reading WAL in target pg_rewind: need to copy 537 MB (total source directory size is 1071 MB) 550000/550000 kB (100%) copied pg_rewind: creating backup label and updating control file pg_rewind: syncing target data directory pg_rewind: Done!
postgresql.auto.conf 삭제	rm $PGDATA/postgresql.auto.conf
복제 대상 설정	vi postgresql.conf primary_conninfo='user=repluser password=1234 host=172.18.0.3 port=5432'
DB 기동	$PGHOME/pg_ctl start
과정	new_standby	new_primary
Replication 확인	select pg_is_in_recovery();	select * from pg_stat_replication; pid \| usesysid \| usename \| application_name \| client_addr \| client_hostname \| client_port \| backend_start \| backend_xmin \| state \| sent_lsn \| write_lsn \| flush_lsn \| replay_lsn \| write_lag \| flush_lag \| replay_lag \| sync_priority \| sync_state \| reply_time -------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+--------------+-----------+------------+------------+------------+------------+ -----------+-----------+------------+---------------+------------+------------------------------- 97179 \| 24576 \| repluser \| walreceiver \| 172.18.0.2 \| \| 50820 \| 2024-06-17 05:39:39.883996+00 \| \| streaming \| 0/900633D8 \| 0/900633D8 \| 0/900633D8 \| 0/900633D8 \| \| \| \| 1 \| sync \| 2024-06-17 05:39:50.838498+00 (1 row)
wal_log_hints 설정		vi postgresql.conf wal_log_hints = on
DB 종료		$PGHOME/pg_ctl stop
구 Primary promote	$PGHOME/pg_ctl promote
과정	new_primary	DB off
pg_rewind 수행		$PGHOME/pg_rewind --source-server='host=172.18.0.2 port=5432 user=postgres dbname=postgres' --target-pgdata=$PGDATA -P -R
복제 대상 설정		vi postgresql.conf primary_conninfo='user=repluser password=1234 host=172.18.0.2 port=5432'
DB 기동		$PGHOME/pg_ctl start
Replication 확인	select * from pg_stat_replication; pid \| usesysid \| usename \| application_name \| client_addr \| client_hostname \| client_port \| backend_start \| backend_xmin \| state \| sent_lsn \| write_lsn \| flush_lsn \| repl ay_lsn \| write_lag \| flush_lag \| replay_lag \| sync_priority \| sync_state \| reply_time -------+----------+----------+------------------+-------------+-----------------+-------------+-------------------------------+--------------+-----------+------------+------------+------------+----- -------+-----------+-----------+------------+---------------+------------+------------------------------- 53519 \| 24576 \| repluser \| walreceiver \| 172.18.0.3 \| \| 57092 \| 2024-06-17 05:56:49.833254+00 \| \| streaming \| 0/91005F98 \| 0/91005F98 \| 0/91005F98 \| 0/91 005F98 \| \| \| \| 1 \| sync \| 2024-06-17 05:58:50.991647+00 (1 row)	select pg_is_in_recovery();

4. pg_rewind 마무리

결론적으로, pg_rewind는 PostgreSQL 클러스터의 장애 복구 및 스탠바이 서버 전환에 유용한 도구입니다. 변경된 블록만을 복사하여 효율적으로 데이터를 동기화하며, 타임라인 분기 후에도 적용할 수 있어 유연합니다. 이를 통해 빠른 시간 내에 클러스터를 복구하거나 스탠바이 서버로 전환할 수 있습니다.

단, pg_rewind를 성공적으로 수행하기 위해서는 타겟 서버의 postgresql.conf 파일에서 필요한 설정이 충족되어야 하며, 필요한 WAL 파일을 확보해야 합니다. 특히, 복구 모드에서 WAL 파일이 없을 경우에는 별도로 아카이브 파일을 복사하거나 restore_command 설정을 통해 복구할 수 있습니다.

따라서, pg_rewind는 신속하고 효율적인 복구 및 서버 전환을 지원하는 중요한 도구로, 적절한 설정과 파일 관리가 필수적입니다. 이러한 점들을 고려하여 pg_rewind를 활용하면 PostgreSQL 클러스터의 안정성과 가용성을 크게 향상시킬 수 있습니다.

[프로모션] PostgreSQL 사용 고객사를 위한 온사이트 DB 교육 이벤트 실시

SKAI Worldwide | 스카이월드와이드 — Mon, 1 Jul 2024 19:36:44 +0900

[프로모션] PostgreSQL 사용 고객사를 위한 온사이트 DB 교육 이벤트 실시

비트나인
agens@bitnine.net
서울시 강남구 테헤란로 516, 정헌빌딩 3,4,5층 070-4800-3517
수신거부 Unsubscribe

7/10(수) 오후 2시, 세 번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Fri, 28 Jun 2024 10:00:14 +0900

️7/10(수) 오후 2시, 세번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

PostgreSQL 글로벌 컨트리뷰터와의 기술 인터뷰_feat. 최신 PG 17버전

SKAI Worldwide | 스카이월드와이드 — Thu, 27 Jun 2024 10:00:55 +0900

PostgreSQL 글로벌 컨트리뷰터와의 기술 인터뷰

feat. 최신 PG 17버전

PostgreSQL 전문 기업 비트나인에서 특별한 시간을 준비했습니다. 비트나인 제품의 핵심 연구원과 인터뷰를 통해 PostgreSQL 이야기를 나눠보려고 합니다. 최근 릴리즈된 17 Beta 버전에 대한 전문가의 견해도 놓치지 않고 담아왔습니다.

그럼 지금부터 시작합니다.

Q. 안녕하세요, Umar Hayat 수석보님! 자기소개 부탁드립니다.

안녕하세요, 인터뷰에 초대해 주셔서 감사드립니다. 저는 Umar Hayat이고 파키스탄에서 왔습니다. 현재는 가족과 함께 서울에서 살면서 데이터베이스 전문기업 비트나인에서 일하고 있습니다.

Q. 그동안 어떤 커리어를 쌓아 오셨는지 궁금합니다.

저는 컴퓨터 사이언스 학사 학위를 취득한 후, 2011년 파키스탄 이슬라마바드의 엔지니어링 CAD 회사인 벤틀리 시스템에서부터 커리어를 시작했습니다.

그 이후 2016년에는 Enterprise DB에 입사하여 클라이언트 측 Database Driver, PgPool 및 Pgbounce와 같은 미들웨어 툴 그리고 Server 툴을 다루는 다양한 팀에서 일했습니다. EDB에서 저는 인하우스 제품을 개발뿐만 아니라 커뮤니티 프로젝트에 기여하였고, 그 중에서도 PgPool Development Group의 멤버가 되었습니다

경력을 쌓아오면서 저는 사이버 보안에 관심을 가지게 되었고, Information Security 석사 학위를 취득했습니다. 보안은 IT에서, 특히나 데이터베이스 분야에서 아주 중요한 요소라고 생각했기 때문입니다.

EDB에서 5년간 근무한 후 2021년 비트나인에 입사하게 됐습니다. 현재는 Bitnine에서 Database Engine 개발 및 HA 가용성을 담당하는 Core Group을 리딩하는 수석보입니다.

Q. 파키스탄에서 한국까지 오는 결정이 쉽지 않았을 것 같습니다. 비트나인에서 일하게된 특별한 계기가 있으신가요?

비트나인에 조인하게된 데는 여러 이유가 있습니다. 저의 커리어의 상당 부분은 데이터 베이스 관련 업무를 해왔고 데이터베이스 개발과 그와 관련된 툴, 에코시스템 등에 관심이 많았기 때문에 이 커리어를 지속적으로 성장시킬 수 있는 회사가 필요했습니다.

비트나인은 데이터베이스 전문기업으로서 글로벌 시장에서 존재감을 드러내고 있는 전도유망한 회사였고, 뿐만 아니라 비트나인이 오픈소스를 적극 지원하는 것에 많은 영감을 받았습니다. 전사적으로 PostgreSQL, Apache AGE 등 오픈소스 커뮤니티에 상당한 기여를 할 수 있도록 지원하고 있었습니다. 이에 동료들과 함께 성장할 수 있는 적합한 회사라는 생각이 들었고 과감하게 의사결정하게 되었습니다. 현재는 임직원을 소중하게 생각하는 조직문화에서 만족하면서 즐겁게 일하고 있습니다.

Q. 오픈소스 커뮤니티 이야기가 흥미롭네요. PostgreSQL Contributor를 포함하여 활동하고 계신 커뮤니티 이야기를 해주시겠어요?

저는 다양한 오픈소스 커뮤니티 활동을 즐기고 있습니다. 처음은 2018년 NpgSQL(PostgreSQL.NET Driver)에서 PostgreSQL 커뮤니티에 Contribution을 시작했고, SCRAM 인증을 위한 구현을 제공했습니다. (SCRAM: 현재 PostgreSQL 설치에서 표준 및 기본 인증 메커니즘)

이후에 PgPool Development Group과 함께 일하기 시작했고 PgPooL의 여러 메이저 및 마이너 릴리스에서 기능과 버그 수정을 하는 데 Contribution 하기 시작했습니다. 요즘에도 여유 시간이 생길 때마다 되도록 많은 PG 커뮤니티 프로젝트에 기여하려고 노력합니다.

PostgreSQL은 과거부터 현재까지 매우 강력한 오픈 소스 커뮤니티이며, 대부분의 프로젝트에서 항상 많은 일이 일어나고 있습니다. 이러한 훌륭한 커뮤니티에 일원으로 참여하게 되어 영광으로 생각합니다.

Q. 오랜 기간동안 꾸준히 커뮤니티 활동을 하신 게 대단하시네요. 그렇다면 PostgreSQL 커뮤니티의 Contributor가 되고 싶어 하시는 분들께 한마디 부탁드립니다.

PostgreSQL 커뮤니티의 Contributor가 되고 싶다면, 먼저 목적을 명확히 해야 합니다. 많은 사람들이 각기 다른 이유가 있겠지만 예를들면 ‘다른 사람들을 행복하게 함으로써 내가 행복을 느끼고 싶다’는 것처럼 간단할 수도 있습니다. 혹은 조금 더 실용적인 목적과 목표를 가질 수 있는데 예를들면 가장 좋아하는 분야에서 전문성을 쌓는 다든가 좋은 사람들과 일하고 네트워킹 하는 게 될 수 있습니다.

당신의 Contribution은 작을 수 있지만 나중에 이 제품에서 해당 기능을 사용하는 사람에게 엄청난 차이를 만들어 낼 수 있다는 걸 알아야 합니다. 물론 당신의 목적과 목표에 상관 없이 당신의 전문적인 커리어는 분명히 성장하게 될 것입니다.

Q. 좋은 마인드인 것 같습니다. 구체적인 Contribution 방법도 설명해주시겠어요?

시작을 위해서는 몇가지 단계를 거쳐야 합니다. 일부 기능을 구현하거나 문제를 해결하려면 PostgreSQL의 언어인 C 프로그래밍 지식이 있어야 하며 당연히 데이터베이스 개념과 SQL 언어를 알아야 합니다. 또한, 소스 코드와 컴파일 방법을 이해해야 합니다.

PostgreSQL 웹사이트의 Developers 섹션에서 Mailing List 링크를 사용할 수 있습니다. 링크를 활용해 활성 토론을 볼 수 있고 그들을 구독해서 이메일을 받아볼 수 있습니다. 그럼 프로젝트에서 활성 토론이 언제 발생하는지 알 수 있습니다.

활성 패치를 볼 수 있는 Commitfest 포털도 있습니다. 초보자의 경우 먼저 기존 패치를 검토해보고 다른 개발자가 패치를 검토하는 방법을 확인하는 것이 좋습니다. 환경에 익숙해지면 기존 버그를 선별하여 수정을 시도한 다음 점차 복잡한 기능 구현을 진행할 수 있습니다.

철저한 검토와 여러 번의 패치 논의를 거쳐 최종 패치까지 제안 과정을 거친 후 패치를 Commit 할 준비가 완료됩니다. 소수의 Commit 담당자가 직접 검토한 후 패치를 Git repository에 Commit 할 것입니다.

사실 코드는 PG 커뮤니티에서만 Contribution 할 수 있는 것은 아닙니다. 여러분의 블로그나 다른 채널을 사용해서 다른 사람들을 도와주거나 시스템의 인프라를 제공함으로써 기여할 수 있습니다. Advocacy 자체가 커뮤니티에 큰 기여를 합니다.

Q. 자세한 설명 감사합니다. 이번 PG 17 버전에 대해 많은 분들이 궁금해하고 계신데요, 그 이전에 그동안 PG가 발전해온 방향성에 대한 전문적인 관점을 소개해주시겠어요?

최근에 PG 17 Beta 1 버전이 출시되어 전세계 IT 담당자들이 평가를 시작했습니다. 여러 해동안 활발하게 contribution 해주신 모든 분들께 이 자리를 빌어 감사인사 드립니다.

지난 많은 릴리즈 동안, PostgreSQL은 다양한 분야에서 상당한 성능 향상을 보여줬습니다.

PostgreSQL 13은 parallelized vacuuming이나 incremental sorting 같은 향상된 기능을 도입하여 인덱싱 및 쿼리 성능을 높였고, PostgreSQL 14는 parallel sequential 스캔 및 보다 효율적인 B-tree index handling 같은 기능을 통해 성능을 더욱 최적화했습니다. 그리고 PostgreSQL 15는 partitioned tables의 쿼리 성능을 향상시키는 partition pruning과 vacuum 효율성의 개선으로 이전 버전의 주 강화 기능과 비슷한 행보를 이어나갔습니다.

PostgreSQL 16은 더 빠른 sorting 알고리즘과 병렬 쿼리를 위한 메모리 관리를 추가하는데 중점을 둔 기능 개선이 이뤄졌습니다. 각각의 릴리즈는 PostgreSQL이 더 크고 복잡한 workload를 처리할 수 있도록 기능이 강화 되었습니다.

PostgreSQL 10에서 시작된 built-in logical replication 기능은 publish-subscribe 모델을 통해 table-level 복제를 지원합니다. 이후 출시한 PostgreSQL 16까지 다른 PostgreSQL 기능과 더욱 원활하게 통합하면서 성능, conflict의 관리, 데이터 타입 지원을 강화되고 replication 측면에서의 성능 개선이 지속적으로 이뤄졌습니다.

Postgres 14, 15에도 많은 발전이 있었지만 가장 눈에 띄는 것은 16에서 소개된 양방형 replication 지원입니다. 앞으로도 PostgreSQL은 대규모 및 고가용성 환경의 요구를 충족시킬 예정입니다. 이를 위해 보다 세분화된 제어 기능, 복잡한 복제 토폴로지 지원, 성능 최적화를 통한 논리적 복제(logical replication) 개선 등을 목표로 하고 있습니다. 이러한 발전 방향은 PostgreSQL 17과 같은 향후 버전에서 더욱 구현될 것으로 기대됩니다.

천천히 그러나 꾸준히 우리는 진정한 멀티 마스터 솔루션 구현으로 나아가고 있습니다.

또한, PostgreSQL은 사용성과 개발자 기능에서 상당한 발전을 이루었습니다. PostgreSQL 13에서는 JSON path 쿼리, 인덱스 생성, 파티셔닝 기능 향상을 통해 개발자가 복잡한 데이터 구조를 좀 더 쉽게 처리하고 쿼리성능을 개선할 있도록 했습니다.

PostgreSQL 14는 여러 개의 쿼리에 대한 대기 시간을 줄여주는 쿼리 pipelining 기능, 모니터링 및 통계 기능 강화 등으로 사용성을 더욱 향상시켰습니다.

PostgreSQL 15는 MERGE 명령과 같은 SQL 호환 기능 추가, 향상된 JSON 및 SQL/JSON 지원, full-text 검색 개선으로 더 나은 검색 기능을 제공합니다.

PostgreSQL 16은 SQL/JSON constructors 및 향상된 logical replication 지원과 향상된 보안 기능 및 더 강력한 오류 보고 기능을 도입하여 개발자가 애플리케이션을 더 쉽게 구축, 유지 및 확장할 수 있도록 함으로써 이러한 추세를 이어갔습니다.

요약을 위해 몇 가지 주요 부분만 언급했지만, PostgreSQL 17까지 전체적인 그림을 보면 성능, 보안 및 사용성을 향상시키기 위한 PostgreSQL의 지속적인 노력을 엿볼 수 있습니다.

각 릴리즈는 이전 버전을 기반으로 최신 데이터베이스 애플리케이션의 요구를 충족하고 새로운 기능을 사용자에게 알립니다.

이러한 발전을 통해 세계 기업과 개발자들에게 최고의 선택이 되기 위한 PostgreSQL의 의지를 알 수 있습니다.

StackOverflow와 DB-Engine의 전년도 결과에서도 볼 수 있듯이, PostgreSQL은 현재 가장 많은 개발자에게 인기 있는 오픈소스 데이터베이스 1위가 되었습니다.

Q. PostgreSQL 17에서 어떤 점이 달라졌나요?

이번 PG 17에는 새로운 기능이 많이 추가되었으나, 핵심 기능 몇 가지만 추려 말하고자 합니다.

가장 큰 개선이 된 성능부터 설명하겠습니다.

성능 개선은 쿼리실행과 그 하위단계에서 가장 크게 드러납니다.

stream I/O 사용, 순차 스캔과 WAL 프로세스 lock의 개선, 여러 부분에서의 최적화를 통해 쿼리플래너, 옵티마이저, 실행단계의 성능을 향상시켰습니다.

두번째는 Vacuum 프로세스의 개선에 관한 것입니다. 17에서는 메모리 소비, 실행 시간이 모두 개선되었는데 Vacuum 프로세스 관련 최대 메모리 설정이 기존 1GB에서 3GB로 늘었습니다.

다음은 incremental backup support입니다. 기존에는 업데이트가 많은 WAL 파일을 만들어냈기 때문에 많은 부하가 발생했습니다. 용량에 따라 다르긴 하지만, 더 많은 용량을 백업할 수 있도록 바뀌었는데, 이제는 WAL 파일을 다시 읽어들이는 시간이 10배 단축되었습니다.

논리적 복제 측면에서는 물리적 standby서버에서도 논리적 복제를 할 수 있도록 pg_create subscriber utility를 도입, CREATE/ALTER SUBSCRIVISION을 이용하여 논리적 복제의 장애처리를 할 수 있게 되었습니다.

장애조치후 replication쪽을 새로 primary 노드로 재설정하는 번거로움이 있었기 때문에 고가용성 측면에서 이 두 기능이 많은 도움을 줄거라 생각합니다.Subscriber노드의 PK and REPLICA IDENTITY에 hash 인덱스가 지원되면서 성능도 향상되었습니다.

이전 PG16까지는 오직 B-tree 인덱스만 지원되었습니다. 하위 트랜잭션의 논리적 디코딩은 대용량 쿼리의 속도를 높이는데 이는 HA(고가용성)에서 많은 도움이 될 것으로 전망합니다.

SQL 명령어에서도 많은 개선이 이뤄졌는데, 테이블 파티션 영역에서는 테이블 구조를 변경하는 MERGE PARTITIONS, SPLIT PARTITIONS 명령어가 소개되었습니다. 명령어 형태로도 유추할 수 있듯이 여러 파티션을 병합하거나(MERGE PARTITIONS), 파티션을 여러부분 분할(SPLIT PARTITIONS)하는 명령어입니다. 하지만 현재는 약간의 제한이 있습니다. 이 명령어들은 단일 프로세스에서 작동해야 하고 부모 테이블에 ACCESS EXCLUSIVE LOCK 설정이 필요하므로, 결과적으로 부하가 많은 대형 파티션 테이블에서는 권장되지 않습니다.

pg_stat_*이름의 새로운 view들이 추가되고 기존의 view에도 새로운 정보가 추가됨으로써 데이터베이스 객체, 작동에 대한 모니터링도 개선되었습니다.

어플리케이션 개발자들에게는 RETURNING 절이 지원되는 MERGE 문은 아주 중요한데,

RETURNING 절이 추가되어 병합 작업중에도 수행된 작업된 작업에 대한 정보를 얻을 수 있게 되었습니다.

또한 개발자의 편의를 위한 여러 기능들이 도입되었는데, 이 중 SQL/JSON function의 적용범위가 크게 향상되었습니다. 이제 Postgres에서도 JSON_TABLE() 함수를 사용하여 JSON 데이터를 테이블 형식에 맞게 변환할 수 있게 되었고, subquery나 다른 SQL 작업들에서도 사용할 수 있습니다. 그리고 JSON(), JSON_SCALAR(), JSON_SERIALIZE()와 같은 json을 생성하는 함수, 그외에도 JSON_EXISTS(), JSON_QUERY(), JSON_VALUE() 와 같은 함수들이 이번 릴리즈에 포함되었습니다.

또한 Hash 인덱스를 복제 변경 적용에 활용할 수 있게 됨에 따라 성능이 향상되고, B-tree 인덱스를 넘어서는 유연성이 향상되며, 워크로드의 엄청난 수의 하위 트랜잭션에 대한 논리적 디코딩도 HA 시나리오에서 중요한 역할을 할 것입니다.

애플리케이션 개발자에게 MERGE 문과 SQL/JSON 향상은 매우 유용할 것입니다. 새로운 pg_stat_* 뷰를 추가하고 기존 뷰에 대한 정보를 추가함으로써 데이터베이스 개체 및 작업에 대한 모니터링도 향상되었습니다.

그 외에도 더 많은 기능 개선점들이 있지만 위의 내용들이 눈에 띄게 개선된 부분들이어서 뽑아보았습니다.

Q. 중요한 개선사항을 짚어 설명해 주셔서 감사합니다. 오늘 Umar Hayat님의 커리어 이야기 그리고 PG 17 Beta 버전에 대한 견해까지 들어볼 수 있는 좋은 시간이었습니다.

네, 저도 좋은 시간이었습니다. 앞으로도 PostgreSQL 관련 다양한 내용 나눌 수 있으면 좋겠습니다.

여기까지 Umar Hayat님와 함께한 인터뷰였습니다. 다음 시간에도 비트나인의 또 다른 전문 역량을 갖춘 분을 초대하여 PostgreSQL 기술 이야기를 나누는 시간을 준비 하겠습니다. 감사합니다.

PostgreSQL 성능 저하 Troubleshooting 가이드-2부-

SKAI Worldwide | 스카이월드와이드 — Wed, 26 Jun 2024 09:39:13 +0900

작성자: 서준섭 과장_DB 기술센터-DB Tech팀

PostgreSQL 트러블슈팅 가이드: Slow Query

PostgreSQL에서 slow query는 전반적인 시스템 성능에 큰 악영향을 줄 수 있습니다.

먼저 slow query는 데이터베이스 서버의 CPU와 메모리 자원을 과도하게 소모하여 다른 쿼리들의 실행을 방해할 수 있습니다. 이는 전체적인 응답 시간 지연으로 이어져, 사용성을 크게 저하시킬 수 있습니다.

또한 slow query는 데이터베이스 연결 수를 급격히 증가시켜 리소스 고갈로도 이어질 수 있습니다. 이 경우 새로운 연결 요청이 지연되거나 거부되어 전체적인 서비스 가용성이 떨어질 수 있습니다.

더불어 데이터베이스 로그 파일의 용량을 빠르게 증가시켜 디스크 공간 문제도 야기할 수 있습니다. 이는 결국 데이터베이스 백업 및 복구 작업에도 악영향을 줄 수 있습니다.

결국 slow query는 데이터베이스 서버의 리소스 고갈, 사용성 및 서비스 가용성 저하, 디스크 공간 문제 등 다양한 측면에서 시스템 성능을 크게 저하시킬 수 있습니다. 따라서 이에 대한 지속적인 모니터링과 적극적인 튜닝이 필요합니다.

본 아티클은 PostgreSQL에서 slow query를 어떻게 확인하고 해결하는지에 대해 소개하겠습니다.

Slow Query 확인 방법

1. pg_stat_activity 모니터링

지난 1부에서 소개한 pg_stat_activity 뷰를 통해 현재 실행 중인 쿼리를 실시간으로 모니터링할 수 있습니다. 이 뷰에는 각 세션의 PID, 사용자 이름, 접속된 데이터베이스 이름, 현재 실행 중인 쿼리 등의 정보가 포함되어 있습니다.

예를 들어, 다음과 같은 쿼리를 통해 현재 실행 중인 쿼리의 목록을 얻을 수 있습니다.

위 쿼리에서는 state가 ‘active’인 세션의 정보를 필터링하여 아래와 같이 보여줍니다.

특정 PID의 세션 상세 정보를 확인하려면 다음과 같이 추가 조건을 걸 수 있습니다.

이를 통해 특정 세션에서 어떤 쿼리가 실행 중인지 아래와 같이 명확하게 파악할 수 있습니다.

2. EXPLAIN 명령어 사용

쿼리의 실행 계획을 확인하기 위해 EXPLAIN 명령어를 사용합니다. 실행 계획을 통해 쿼리가 어떤 방식으로 실행되는지, 어떤 인덱스를 사용하는지, 어떤 테이블 스캔을 수행하는지 등을 알 수 있습니다.

다음과 같은 쿼리를 통해 실행 계획을 확인할 수 있습니다.

실행 계획에서 각 단계의 비용과 예상 행 수 등을 확인할 수 있습니다.

위 결과에서 볼 수 있듯이, 이 쿼리는 users 테이블에 대한 순차 스캔(Seq scan)을 수행하고, email 컬럼에 대한 필터링을 적용하고 있습니다.

또다른 예시를 통해 EXPLAIN ANALYZE로 실제 쿼리 실행 시간과 실행 계획을 동시에 확인할 수 있습니다.

결과:

Seq Scan on large_table (cost=0.00..4456.00 rows=1000 width=100) (actual time=120.235..1200.345 rows=1000 loops=1)

Filter: ((column1 = 'some_value'::text) AND (column2 ~~ '%some_pattern%'::text))

Rows Removed by Filter: 9000

Total runtime: 1201.234 ms

위 결과에서는 실제 실행 시간(actual time), 실제 반환된 행 수(actual rows) 등의 정보도 확인할 수 있고, 실행 결과와 함께 소요된 시간도 보여줍니다. 해당 예시에서는 약 1.2초가 소요된 것을 알 수 있습니다.

Slow query를 해결할 수 있는 방법은 많겠지만 하나의 예시로 index를 생성하고 쿼리를 다시 실행하여 소요된 시간을 줄이는 방법을 표현해보겠습니다.

결과:

Index Scan using large_table_column1_column2_idx on large_table (cost=0.29..8.30 rows=1 width=100) (actual time=0.029..0.041 rows=1 loops=1)

Index Cond: ((column1 = 'some_value'::text) AND (column2 ~~ '%some_pattern%'::text))

Total runtime: 0.075 ms

Large_table에 Index를 추가하여 total runtime을 줄일 수 있었습니다.

사용자는 위와 같이 쿼리의 성능 문제를 파악하고, 적절한 최적화 방법을 찾아서 slow query를 해결할 수 있습니다.

3. 쿼리 프로파일링

쿼리 프로파일링 도구를 사용하면 쿼리 실행 시간, CPU 및 메모리 사용량 등을 더욱 세밀하게 분석할 수 있습니다. 대표적인 도구로는 pg_stat_statements가 있습니다. 이는 각 쿼리의 실행 횟수, 총 실행 시간, 평균 실행 시간 등을 수집하여 성능 분석에 도움을 줍니다.

가장 오래 걸리는 쿼리, 가장 많이 실행된 쿼리, 가장 많은 CPU를 사용한 쿼리 등을 정확하게 파악할 수 있도록 지원하는 도구를 활용하여 쿼리 성능의 병목 지점을 더 정확하게 파악해보시기 바랍니다.

4. 로그 분석

PostgreSQL에서는 다양한 정보를 로그 파일에 기록합니다. 이 로그 파일에는 쿼리 실행 시간, 실행 계획, 에러 메시지 등이 포함되어 있습니다. 이를 통해 사용자는 성능 문제를 일으키는 쿼리를 쉽게 파악할 수 있습니다.

로그 파일의 위치는 postgresql.conf 파일에서 설정할 수 있습니다. 기본적으로는 데이터 디렉터리 내에 위치하지만, 필요에 따라 별도의 디렉터리를 지정할 수 있습니다.

Slow query 로그를 활성화하려면 다음과 같은 설정을 추가할 수 있습니다:

로그 파일은 데이터 디렉터리 내의 pg_log 폴더에 생성되며, 다음과 같은 형식으로 기록됩니다:

2023-06-20 10:30:45.123 UTC [123] LOG: duration: 1234.567 ms statement: SELECT * FROM users WHERE email = 'example@example.com';

위 설정에서 log_min_duration_statement는 쿼리 실행 시간이 1초 이상인 경우에만 로그에 기록하도록 합니다. 이 값은 상황에 따라 조절할 수 있습니다.

log_directory는 로그 파일이 저장될 디렉터리를 지정하며, log_filename은 로그 파일의 이름 형식을 정의합니다. 이 예시에서는 날짜와 시간 정보가 포함된 파일명을 사용하고 있습니다. 이렇게 설정된 로그 파일을 분석하면 다음과 같은 정보를 얻을 수 있습니다:

1. 쿼리 실행 시간: 로그 파일에 기록된 실행 시간을 통해 slow query를 식별할 수 있습니다.

2. 실행 계획: 로그에 포함된 실행 계획 정보를 통해 쿼리의 성능 병목 지점을 파악할 수 있습니다.

3. 에러 메시지: 로그에 기록된 에러 메시지를 통해 쿼리 실행 시 발생한 문제를 확인할 수 있습니다.

이러한 정보를 종합적으로 분석하여 사용자는 성능 문제를 일으키는 쿼리를 식별하고, 적절한 최적화 방법을 찾아 적용시킬 수 있습니다.

3부에 계속 되는 Troubleshooting 가이드

2부 아티클에서는 PostgreSQL에서 slow query가 시스템에 끼치는 악영향을 알아봤고 문제를 해결하기 위해 확인하는 방법을 알아봤습니다.

이어지는 3부 troubleshooting 가이드에서는 lock에 대해 전반적으로 알아보고자 합니다. Lock은 데이터베이스 동시성 제어를 위해 필수적으로 사용되는 기능인데, 관리가 제대로 이루어 지지 않으면 다양한 문제가 발생할 수 있습니다. 어떤 문제가 어떤 결과를 초래하는지, 그리고 이에 대한 troubleshooting 방법을 간략하게 알아보겠습니다.

PostgreSQL 17 기술 방향성

SKAI Worldwide | 스카이월드와이드 — Tue, 25 Jun 2024 15:49:35 +0900

작성자: 윤재영 수석보ㅣ DB R&D센터 - Enterprise R&D팀장

PostgreSQL 17 beta Released

2024년 5월 23일 PostgreSQL 17 beta 1이 릴리즈 되었습니다. 매년 메이저 버전을 한 개씩 올리는 PostgreSQL의 정책상 사용자에게 더 나은 경험을 제공해 주기 위해 1년간 많은 내용들을 연구하고 적용합니다. 또한 PostgreSQL이 OSS(Open Source Sofrware)이다 보니 다른 기여자들의 참여도 활발하고, 자신이 기여한 내용이 적용된다면 그만한 보람이 또 없을 것입니다.

이 글에서는 이번 PostgreSQL 17 beta에서 어떤 기능들이 집중적으로 조명되었고, 그를 통한 앞으로의 방향에 대해 예측해 보겠습니다.

1) VACUUM 성능 향상

PostgreSQL은 Oracle과 MySQL과는 달리, MVCC를 위한 VACUUM을 적용하였습니다. 보통 Data는 물리적으로 디스크에 저장되는데, 이 데이터를 갱신 시, 디스크에 있던 기존 정보를 갱신하거나 삭제하지 않아, FSM(FreeSpaceMap)에 사용 가능한 공간이 있는지 확인 후 없으면 FSM을 추가로 확보합니다. FSM에서 사용할 수 있는 공간에 UPDATE 된 데이터를 기록, UPDATE된 데이터의 저장이 완료되면 UPDATE 이전 원본 Tuple을 가리키던 포인터를 이동시켜, 어디에도 참조되지 않는 기존 Data, 즉 Dead Tuple이 발생하게 됩니다.

VACUUM이 테이블에서 UPDATE 또는 DELETE로 인해 발생한 Dead Tuple을 처리할 때, VACUUM은 Index Vacuum을 처리하는 동안 테이블에서 해당 Tuple이 어디에 있었는지 기억해야 하는데, 이 원리는 기본 테이블에 데드 튜플, 데드 Row Version이 존재하고, Index가 여전히 해당 Dead Row를 가리키고 있어,인덱스로 이동하여 오래된 인덱스 항목을 제거한 다음 기본 테이블에서 데드 튜플을 실제로 완전히 제거할 수 있어야 합니다. 그러나 PostgreSQL 16버전까지는 이에 할당할 수 있는 용량이 적어(최대 1GB), 성능 측면에서 많은 애로사항이 있었습니다.

이를 해결하기 위해, ID를 저장할 때 간단한 배열을 사용하여 처리, 메모리 효율성이 높아졌습니다. 실제로 pganalyze에서 PG16과 PG17에 대한 autovacuum 기능 테스트 시, PG16은 Index vacuum이 계속 전환되면서 그만큼 IO 접근이 잦아지지만, PG16에서는 그러한 과정 없이 1회의 Scanning Heap만 발생함과 동시에 처리 시간도 빨라지는 결과를 보여주었습니다.

<PG16(상)과 PG17(하)의 autovacuum 성능 비교. pganalyze >

2) 인덱스 알고리즘 강화를 통한 쿼리 최적화

이번 PostgreSQL 17 beta에서는 B-Tree 및 BRIN 인덱스에 대한 유의미한 성능 강화가 이뤄졌습니다

B-Tree index는 이제 제약 조건이 있는 Row 실행 시 중복된 문을 제거할 수 있으며 더 이상 Row의 절이 포함된 쿼리에 대해 작업을 수행하지 않습니다. 이전 버전인 PostgreSQL 16은 한 번에 여러 값을 제어할 수 없어, 커밋 전에 B-Tree Index를 반복적으로 탐색하여 동일한 페이지를 얻어냈었으나, 이제 특정 페이지로 작업할 때 이 입력 값 배열이 고려되므로 전체 트리를 다시 탐색하지 않고도 다음 값을 얻을 수 있게 되는 이점이 생겼습니다. 여러 값이 포함된 IN 절은 각 값에 대해 인덱스 스캔 카운터가 증가하였으나, 이번 기능 개선을 통해 이 카운터가 크게 감소하는 이점을 볼 수 있게 되었습니다. 또한 BRIN 인덱스에 병렬 Index Build 사용을 지원하게 됨으로써, 여러 병렬 작업자를 사용하여 인덱스 생성 시간을 크게 단축시킬 수 있어, 대규모 데이터셋에서 효율적으로 인덱스를 생성할 수 있게 되었습니다.

<10만개의 데이터를 IN절을 통해 검색했을 때의 PG16(상)과 PG17(하)의 쿼리 플랜 비교>

3) Logical Replication

기존에는 최신 버전으로 업그레이드 할 경우, 기존의 Logical Replication Slot을 삭제하는 번거로움이 존재하였는데, 이제는 삭제할 필요 없이 바로 업그레이드를 진행할 수 있게 되었습니다. 이로 인해, 엔지니어는 이제 업그레이드에만 집중할 수 있게 되었습니다. 또한, 장애 조치를 제어할 수 있는 기능이 추가되었습니다.

Physical Replication과 Logical Replication은 사상적 차이가 존재합니다. 특히 그 중 Physical Replication은 DB의 버전이 다를 경우 Replication 자체가 이뤄지지 않는데, 이번 기능 개선을 통하여 Physical 기준으로 복제된 내용을 새로이 Logical 복제본으로 변환할 수 있는 CLI가 추가되었습니다. 엔지니어 입장에서 좀 더 쉬운 HA 제어가 가능해 졌습니다.

4) JSON 강화

기존의 PostgreSQL이 JSON을 제어할 수 없었던 것은 아닙니다. 하지만 JSON을 다루기 위해 각 행에 대한 여러 타입 캐스팅을 진행해야 했고, 그에 따른 쿼리가 번거로워짐을 감수해야만 하였습니다. 그래서 Oracle이나 MySQL의 JSON_TABLE()을 부러워했던 경우가 많았습니다.

그러나 이제 PostgreSQL에서도 JSON을 표준 PostgreSQL 테이블로 변환할 수 있는 기능과 SQL/JSON 생성자 및 쿼리 함수에 대한 지원이 추가되었습니다. 원래는 PostgreSQL 15에 릴리즈 하려 했으나, 베타 기간에 잠깐 나왔다 사라졌습니다. 이로써 JSON_TABLE() 및 JSON(), JSON_SCALAR() 및 JSON_SERIALIZE() 같은 SQL/JSON 생성자 function이나 JSON_EXISTS(), JSON_QUERY() 및 JSON_VALUE() 등의 쿼리 Function을 지원합니다. 단,

이번 beta 버전에서는 JSON_TABLE()이 중첩 열을 처리하는 기능은 없이 제공될 예정입니다.

<PostgreSQL에서 JSON_TABLE()을 사용하여 원하는 값을 도출>

5) 앞으로의 방향성은?

그 외에도 여러 가지 개선 사항이 있었습니다. MERGE를 통한 뷰 업데이트 COPY의 처리 속도 향상, 증분 백업 및 I/O 모니터링 시 소모 시간 표시 등 많은 기능들이 들어왔습니다.

1997년 PostgreSQL 6.0이 태동한 이후, 약 27년이 지났습니다. 개발자 친화적인 모토를 가지고 지속적인 기능 강화가 이루어지고 있는 이 때, 대부분의 업데이트에서 인덱스 강화, Logical Replication 강화 등이 이뤄졌으며, 최근 16 버전에서는 JSON/JSON 표준을 준수하는 정책이 도입되었습니다. 특히 금번 업데이트 중 인덱스를 개선하기 위한 적응형 기수 트리가 추가되거나, Logical Replication의 강화, JSON function 지원 등을 통해 DB 자체의 퍼포먼스를 강화하는 동시에 좀 더 고품격의 HA를 보장하고, JSON에 대한 사용자의 목마름을 해소할 수 있는 첩경을 제시함으로써, 상기 기능을 중점으로 강화하며 발전하지 않을까 하는 추측을 해봅니다.

앞으로도 PostgreSQL이 개발자 뿐만아니라 사용자에게 만족감을 줄 수 있는 긍정적인 방향으로 발전하기를 기대해 봅니다.

7/4(목) 비트나인, 토크아이티 웨비나에서 PostgreSQL 꿀팁 공개

SKAI Worldwide | 스카이월드와이드 — Tue, 25 Jun 2024 09:37:00 +0900

️7/4(목) 비트나인, 토크아이티 웨비나에서 PostgreSQL 꿀팁 공개

PostgreSQL 성능 저하 Troubleshooting 가이드-1부-

SKAI Worldwide | 스카이월드와이드 — Mon, 24 Jun 2024 08:38:21 +0900

작성자: 서준섭 과장- DB 기술센터 I DB Tech팀

PostgreSQL 트러블슈팅 가이드: OS 리소스 확인 및 세션 정보 조회

데이터베이스 성능 저하는 애플리케이션 전체의 성능에 큰 악영향을 미칩니다. 데이터베이스의 성능이 저하되면, 웹사이트 로딩 속도가 느려지거나 트랜잭션 처리 속도가 감소하여 사용자 경험이 크게 악화될 수 있습니다. 이러한 성능 저하는 갑작스럽게 발생할 수 있으며, 원인을 빠르게 찾아내고 해결하는 것이 매우 중요합니다.

성능 저하 문제를 해결하기 위해서는 체계적인 troubleshooting 프로세스가 필요합니다. 먼저 데이터베이스 서버의 전반적인 리소스 사용량을 확인하여 병목 지점을 찾아내야 합니다. CPU, 메모리, 디스크 I/O, 네트워크 사용량 등을 모니터링하여 어느 리소스가 가장 많이 사용되고 있는지 파악해야 합니다. 이후 데이터베이스 연결 상태, 실행 중인 쿼리, Lock 상태 등을 면밀히 살펴보며 문제의 원인을 분석해야 합니다. 예를 들어, 특정 쿼리가 지나치게 오래 걸리거나 여러 트랜잭션이 동시에 실행되면서 Lock 이 발생하는 경우가 있을 수 있습니다.

본 1부 가이드에서는 PostgreSQL 데이터베이스 성능 저하 문제를 해결하기 위한 초기 단계별 troubleshooting 방법을 제시하고자 합니다. 먼저 OS 리소스 사용량 확인을 한 후, 데이터베이스 연결 상태 분석 등의 핵심 단계를 차례로 살펴보겠습니다.

OS Resource 확인

OS 리소스를 확인하기 위해서는 다음과 같은 Linux 명령어를 활용하여 CPU, 메모리, 디스크 I/O 등의 시스템 리소스 사용량을 모니터링하여 병목 지점을 찾아내야 합니다.

- top: CPU, 메모리, 프로세스 등 실시간 시스템 정보 확인

- iostat: 디스크 I/O 성능 모니터링

- vmstat: 메모리, 스왑, 프로세스, CPU 등 시스템 전반의 성능 지표 확인

- sar: 과거 시스템 활동 데이터 확인

특히 DB 서버 프로세스의 PID 값을 확인하여 해당 프로세스의 리소스 사용량을 집중적으로 모니터링해야 합니다.

CPU 과점유 Process 의 PID 확인 (top 이용)

시스템 리소스 부족, 네트워크 장애, 디스크 오류 등의 이벤트들이 데이터베이스 성능 저하의 원인이 되었을 가능성이 있을 수 있습니다. 이러한 이벤트를 살펴보려면 /var/log/messages 파일을 검토하여 DB 성능 이슈가 발생한 시간대에 시스템 상황을 파악해야 합니다.

var/log/messages 파일 확인 방법:

1. 터미널에서 tail -n 100 /var/log/messages 명령어를 실행하면 최근 100개의 로그 메시지를 확인할 수 있습니다.

2. grep 명령어를 사용하여 특정 키워드가 포함된 로그를 검색할 수 있습니다. 예를 들어 grep "error" /var/log/messages를 실행하면 "error" 문자열이 포함된 로그를 확인할 수 있습니다.

3. less 명령어를 사용하면 파일 전체를 스크롤하며 확인할 수 있습니다.

이처럼 OS 리소스 사용량 확인과 시스템 로그 분석을 통해 데이터베이스 성능 저하의 근본 원인을 찾아낼 수 있습니다. 이 과정은 CPU, 메모리, 디스크 I/O 등 병목 지점을 식별하고, 관련 이벤트나 오류 로그를 확인하여 문제의 원인을 종합적으로 진단합니다.

Session 정보 조회

pg_stat_activity와 pg_stat_statements를 통해 문제가 되는 세션과 쿼리를 식별하고, max_connections 설정과 현재 세션 수를 확인하여 리소스 부족 문제를 해결하는 것이 두 번째 트러블슈팅 단계입니다.

PostgreSQL에서 pg_stat_activity와 pg_stat_statements는 각각 다른 목적으로 사용되는 시스템 카탈로그입니다. pg_stat_activity는 PostgreSQL에서 기본적으로 제공되는 카탈로그 뷰이며, pg_stat_statements는 PostgreSQL에서 설치가 필요한 extension입니다. 이 둘의 차이와 용도는 다음과 같습니다:

pg_stat_activity	pg_stat_statements
현재 데이터베이스 서버에 연결된 모든 세션 정보 제공	데이터베이스에서 실행된 모든 SQL 문의 통계 정보 제공
각 세션의 PID, 사용자 이름, 데이터베이스 이름, 클라이언트 주소, 현재 실행 중인 쿼리, 쿼리 실행 시간 등의 정보 포함	각 SQL 문의 텍스트, 실행 횟수, 총 실행 시간, CPU 사용량, 메모리 사용량, I/O 사용량 등의 정보 포함
데이터베이스 관리자는 어떤 세션이 현재 실행 중인지, 어떤 쿼리를 수행하고 있는지 확인 가능	데이터베이스 관리자는 어떤 SQL 문이 가장 많은 리소스를 사용하고 있는지 확인 가능
장시간 실행 중인 쿼리나 리소스를 과도하게 사용하는 세션 식별 유용	성능 저하의 원인이 되는 문제 쿼리를 신속하게 식별하고 최적화함
이 정보를 바탕으로 문제가 되는 세션 종료, 쿼리 최적화 등의 조치를 취할 수 있음	SQL 문의 실행 패턴을 분석하여 인덱스 생성이나 쿼리 재작성 등의 최적화 방안을 수립할 수 있음

요약하면, pg_stat_activity는 현재 실행 중인 세션 정보를, pg_stat_statements는 과거 실행된 SQL 문의 통계 정보를 제공합니다. 데이터베이스 관리자는 이 두 가지 정보를 종합적으로 활용하여 데이터베이스 성능 문제의 원인을 신속하게 진단하고 해결책을 마련할 수 있습니다.

확인한 PID 로 실행 중인 Query 확인

예를 들어, pg_stat_activity에서 장시간 실행 중인 쿼리가 있다면, 이 쿼리를 종료하는 것이 긴급 해결책이 될 수 있습니다. 리소스를 과도하게 사용하는 쿼리를 종료함 으로써 짧은 쿼리들이 데이터베이스를 사용할 기회를 얻게 됩니다. 때로는 이러한 쿼리를 종료하는 것이 내부 서버 오류가 발생하여 전체 데이터베이스를 사용할 수 없게 만드는 것보다 낫습니다.

이렇게 Session 정보를 조회하고 SQL 실행 통계를 확인하면 데이터베이스 성능 저하의 원인이 되는 문제 쿼리와 세션을 식별할 수 있게 됩니다.

또한, max_connections 설정 값과 현재 연결된 세션 수를 확인하는 것도 중요합니다.

max_connections 확인 방법 예시:

Example

select *
  from
  (select count(*) as total_used from pg_stat_activity ) q1
, (select count(*)*100/(select current_setting('max_connections')::int) as used_ratio from pg_stat_activity) q2
, (select setting::int res_for_superuser from pg_settings where name=$$superuser_reserved_connections$$ ) q3
, (select setting::int max_conn from pg_settings where name=$$max_connections$$ ) q4
;

total_used | used_ratio | res_for_superuser | max_conn
------------+------------+-------------------+----------
            6 | 6 | 3 | 100
(1개 행)

만약 max_connections 값이 부족하면 새로운 세션 연결이 거부되어 성능 저하를 일으킬 수 있습니다. 위 쿼리의 경우는 안정적일 때의 예시이지만, total_used 세션 수가 max_connections 값에 근접하거나 동일할 경우, 메모리 사용량이 과도해질 수 있습니다. 이러한 경우, max_connections 값을 늘리거나 메모리 용량을 확장해야 할 것입니다.

2부에 계속 되는 Troubleshooting 가이드

1부 아티클에서는 PostgreSQL의 성능 저하 문제를 해결하기 위한 초기 단계별 troubleshooting 방법을 소개했습니다. OS 리소스 사용량을 확인하여 병목 지점을 파악하거나, pg_stat_activity를 통해 현재 진행 중인 세션 정보 pg_stat_statements로 과거 실행된 SQL문의 통계 정보를 확인하여 문제의 원인을 진단할 수 있습니다.

다음 2부에서는 slow query가 시스템에 어떤 악영향을 줄 수 있는지에 대해 알아보고, 그 이슈를 확인하고 해결하는 방법에 대해 알아보도록 하겠습니다.

6/26(수) 오후 2시, 두 번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Thu, 20 Jun 2024 15:22:12 +0900

️6/26(수) 오후 2시, 두 번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

[웨비나 후기] 6/12 #1 PostgreSQL의 Replication 작동 원리와 활용 방안

SKAI Worldwide | 스카이월드와이드 — Tue, 18 Jun 2024 12:57:22 +0900

PostgreSQL 자료를 찾고 계신가요?

국내에서 PostgreSQL에 대한 관심도가 지속적으로 높아지고 있는 반면, PostgreSQL 콘텐츠를 구하기는 새삼 어려운 게 현실입니다.

그래서인지 비트나인이 진행하는 다양한 기술세션에서 주최 자체에 대한 감사 인사와 응원을 정말 많이 보내주십니다!

이에 힘입은 비트나인은 PostgreSQL 사용자들이 보다 많은 콘텐츠를 접하고 스터디할 수 있도록 적극적으로 지원하기로 하였습니다.

그 중 하나가 바로 웨비나인데요!

그것도 무려 2주에 한 번씩 여러분을 찾아뵙기로 하였습니다.

지난 6/12, 첫 번째 PostgreSQL 기술 웨비나를 진행했습니다.

이번 웨비나에서 주목할 만한 점은 붐비는 Q&A였습니다.

사전 등록 시 받은 질문부터가 양이 어마어마하여 질문을 고르는 데 한참을 고민했습니다.

뿐만 아니라 웨비나 현장에서도 참석자의 1/4에 해당하는 분들이 양질의 질문을 해주셨답니다.

부족한 시간 탓에 모든 질문을 실시간으로 답변드리지 못했지만, 웨비나 종료 후 Q&A를 정리한 질의답변 문서를 공유해드림으로써 조금이나마 궁금증을 해소해드렸습니다.

앞으로도 여러분이 비트나인을 통해 다양한 주제로 PG 스터디 하실 수 있게 유익한 웨비나 준비하도록 하겠습니다.

무엇보다 웨비나 이후 진행하는 설문조사는 저희가 꼼꼼하게 분석하여 웨비나에 최대한으로 반영하고 있으니 정성스럽게 의견 주시면 감사하겠습니다.

다음 2회차 기술웨비나는 6월 26일 수요일 오후 2시에 비트나인 Core R&D팀 연구원이 pgPool을 주제로 발표할 예정 입니다.

많은 관심과 참여 부탁드립니다!

웨비나 영상을 다시 보고 싶다면?

누가 Vacuum을 방해하는가?

SKAI Worldwide | 스카이월드와이드 — Mon, 17 Jun 2024 12:35:52 +0900

작성자: 이익구 이사- DB테크센터 -TSM그룹

누가 Vacuum을 방해하는가?

Postgresql 입문자라면 누구나 Vacuum이 중요하다는 것을 알고 있을 것이다.

Vacuum은 dead tuples에 의해 차지하고 있는 disk space를 정리하여 table size가 쓸데없이 커지는 것을

방지하며, 불필요한 block read를 줄이고 최신의 통계정보 갱신으로 보다 나은 실행계획을 세울수 있도록

query optimizer에 도움을 주며 wraparound가 발생하는 것을 방지하도록 해 준다.

“autovacuum=on으로 설정하면 모든게 자동으로 알아서 잘 처리해 주는거 아냐?” 라고 할 수도 있지만

실상은 그렇지 않다.

이 글에서는 autovacuum=on 운영하에서 dead tuples을 제대로 정리하지 못하는 3가지 상황에 대해

예제를 통해 살펴보도록 하겠다.

1) Long Transaction 그냥 두지 말자 !!

간단한 예제의 모니터링을 위해 vac01 table의 autovacuum 관련 parameter를 아래와 같이 수정한다.

=> alter table vac01 set (autovacuum_vacuum_scale_factor = 0.0);

=> alter table vac01 set (autovacuum_vacuum_threshold = 5);

=> alter system set log_autovacuum_min_duration to 0;

=> select pg_reload_conf();

Session #01은 vac01 table에 10건의 data를 생성하고 6건의 데이터를 갱신하여 auto vacuuming이

실행되도록 한다. (pg_stat_user_tables.n_dead_tup > autovacuum_vacuum_threshold +

autovacuum_vacuum_scale_factor * pg_class.reltuples, 6 > 5 + 0*10)

auto vacuuming이 실행되기 전에 Session #02는 Long Transaction으로 되도록 하고.

Session #03은 Long running Query가 되도록 한다.

—----------------------------------------------------------------------------------------------------------------------------------------

-. Session #01 -. Session #02 -. Session #03

=> insert into vac01

select id,

substr(md5(random()::text),1,10)

from generate_series(1, 10) id;

=> begin; => select pg_sleep(600);

insert into t01 values (1, 'long trans');

=> update vac01

set c2 = 'update' where c1 < 7;

commit;

—----------------------------------------------------------------------------------------------------------------------------------------

-. Active Session Monitoring

=> select pid, state, substr(query,1,40), backend_xid, backend_xmin from pg_stat_activity;

pid | state | substr | backend_xid | backend_xmin

-------+-------------------------+----------------------------------------------------+------------------+--------------

23782 | idle in transaction | insert into t01 values (1, 'long trans') | 7452 |

23783 | active | select pg_sleep(600); | | 7452

위와 같은 상황에서 vac01 table은 auto vacuum이 실행되어도 6개의 rows들의 xmax 값은 7454로

removable cutoff: 7452 보다 크기 때문에 auto vacuum에 의해 정리되지 않고 남아 있게 된다.

agensdb=# select lp, t_xmin, t_xmax, t_ctid from heap_page_items(get_raw_page('vac01', 0));

—--------------------------------------------------------------------------------------------------------------------------

1 | 7451 | 7454 | (0,11) 7 | 7451 | 0 | (0,7)

2 | 7451 | 7454 | (0,12) 8 | 7451 | 0 | (0,8)

3 | 7451 | 7454 | (0,13) 9 | 7451 | 0 | (0,9)

4 | 7451 | 7454 | (0,14) 10 | 7451 | 0 | (0,10)

5 | 7451 | 7454 | (0,15) 11 | 7454 | 0 | (0,11)

6 | 7451 | 7454 | (0,16) 12 | 7454 | 0 | (0,12)

13 | 7454 | 0 | (0,13)

14 | 7454 | 0 | (0,14)

15 | 7454 | 0 | (0,15)

16 | 7454 | 0 | (0,16)

LOG: automatic vacuum of table "agensdb.public.vac01": index scans: 0

pages: 0 removed, 1 remain, 1 scanned (100.00% of total)

tuples: 0 removed, 16 remain, 6 are dead but not yet removable

removable cutoff: 7452, which was 3 XIDs old when operation ended

#. removable cutoff란 간단히 말해서 현재 시점의 Database 내에서 해당 txid를 참조하는 Session은 없는
것을 보장한다는 의미이다. 즉, 7452 까지는 vacuum 대상이 된다는 것이다.

transaction 정리 후, auto vacuum에 의해 6개의 dead tuples이 정리되는 것을 볼 수 있다.

LOG: automatic vacuum of table "agensdb.public.vac01": index scans: 0

pages: 0 removed, 1 remain, 1 scanned (100.00% of total)

tuples: 6 removed, 10 remain, 0 are dead but not yet removable

removable cutoff: 7458, which was 0 XIDs old when operation ended

이와 같이 오래된 ‘idle in transaction’ 이나 active한 long query는 auto vacuum의 대상 table에 관계없이

dead tuples을 정리하지 못하게 하는 방해물인 것이다.

또한 autovacuum_naptime(default 60초) 마다 성공하지도 못하는 auto vacuum 작업을 long query가

완료될때까지 쓸데없이 반복하며 시스템 리소스만 낭비하게 되는 요인으로 작용하게 된다.

PostgreSQL은 이러한 상황을 예방할 수 있도록 ‘idle_in_transaction_session_timeout’ 과

‘statement_timeout’을 설정할 수 있다.(default는 0)

#. idle_in_transaction_session_timeout은 트랜잭선이 시작한 뒤 작업을 실행하지 않고 대기 중인 상태의
트랜잭션을 일정 시간이 지나면 자동으로 종료 해주는 parameter로 postgresql.conf 파일을 수정하는
방법과 아래와 같이 Command를 이용하는 방법이 있다. (단위는 ms)
=> alter system set idle_in_transaction_session_timeout to 300000;

#. statement_timeout parameter는 OLTP 업무의 특성을 고려하여 적정한 값을 적용하고 배치 프로그램
단위로 => set statement_timeout to 0 or 배치최대시간; 구분하여 적용할 수 있다.

2) Replication Slot을 사용할때 Standby Server의 DB 상태를 체크 하자 !!

Replication Conflict를 방지하기 위해 standby server에 hot_standby_feedback = on으로 설정하고

사용할때 standby server의 DB를 stop한 뒤에 replication slot의 상태를 조회해 보면,

=> select slot_name, slot_type, active, active_pid, xmin from pg_replication_slots;

slot_name | slot_type | active | active_pid | xmin

-------------+------------+---------+--------------+------

repl_slot01 | physical | f | | 7532

xmin 값이 7532 인 것을 알수 있고, 이 값이 auto vacuum 수행 시, removable cutoff 값이 될 것이다.

=> update vac01 set c2 = 'update06' where c1 < 7; 와 같이 6건을 update 한 다음의 xmax 값을

조회해 보면, 아래와 같이 7533 인것을 확인할 수 있다.

agensdb=# select lp, t_xmin, t_xmax, t_ctid from heap_page_items(get_raw_page('vac01', 0));

—--------------------------------------------------------------------------------------------------------------------------

1 | 7531 | 7533 | (0,11) 7 | 7531 | 0 | (0,7)

2 | 7531 | 7533 | (0,12) 8 | 7531 | 0 | (0,8)

3 | 7531 | 7533 | (0,13) 9 | 7531 | 0 | (0,9)

4 | 7531 | 7533 | (0,14) 10 | 7531 | 0 | (0,10)

5 | 7531 | 7533 | (0,15) 11 | 7533 | 0 | (0,11)

6 | 7531 | 7533 | (0,16) 12 | 7533 | 0 | (0,12)

13 | 7533 | 0 | (0,13)

14 | 7533 | 0 | (0,14)

15 | 7533 | 0 | (0,15)

16 | 7533 | 0 | (0,16)

auto vacuum의 수행 log를 보면, dead tuples을 정리하지 못한 것을 알 수 있다.

LOG: automatic vacuum of table "agensdb.public.vac01": index scans: 0

pages: 0 removed, 1 remain, 1 scanned (100.00% of total)

tuples: 0 removed, 16 remain, 6 are dead but not yet removable

removable cutoff: 7532, which was 42 XIDs old when operation ended

standby server의 DB를 start 한 후에,

=> select slot_name, slot_type, active, active_pid, xmin from pg_replication_slots;

slot_name | slot_type | active | active_pid | xmin

repl_slot01 | physical | t | 60061 | 7538

xmin 값은 7538 로 바뀌고 auto vacuum의 수행 log를 보면, dead tuples이 정리 되었다.

LOG: automatic vacuum of table "agensdb.public.vac01": index scans: 0

pages: 0 removed, 1 remain, 1 scanned (100.00% of total)

tuples: 6 removed, 10 remain, 0 are dead but not yet removable

removable cutoff: 7538, which was 0 XIDs old when operation ended

standby server의 DB를 한동안 start 할 수 없는 상황이라면, slot 삭제도 고려해 볼 수 있다.

=> select pg_drop_replication_slot('repl_slot01');

pg_drop_replication_slot

--------------------------

(1 row)

3) Distributed Transaction을 사용한다면 Transaction Hang 상황도 살펴 보자 !!

—----------------------------------------------------------------------------------------------------------------------------------------

-. Session #01 -. Session #02

=> begin;

prepare transaction 'tran01';

=> update vac01 set c2 = 'update' where c1 < 7;

=> agensdb=# select gid, prepared, owner, database, transaction AS xmin from pg_prepared_xacts;

gid | prepared | owner | database | xmin

--------+----------------------------------------------+--------+--------------+------

tran01 | 2024-06-11 12:40:39.095001+00 | agens | agensdb | 7560

(1 row)

auto vacuum의 수행 log를 보면, dead tuples을 정리하지 못한 것을 알 수 있다.

LOG: automatic vacuum of table "agensdb.public.vac01": index scans: 0

pages: 0 removed, 1 remain, 1 scanned (100.00% of total)

tuples: 0 removed, 16 remain, 6 are dead but not yet removable

removable cutoff: 7560, which was 5 XIDs old when operation ended

Hang 상황을 처리하려면, 아래와 같이 rollback을 수행한다.

agensdb=# rollback prepared 'tran01';

ROLLBACK PREPARED

agensdb=# select gid, prepared, owner, database, transaction AS xmin from pg_prepared_xacts;

gid | prepared | owner | database | xmin

-----+----------+-------+----------+------

(0 rows)

❶ Long Transaction, ❷ Replication, ❸ Distributed Transaction 사용자에 따라 PostgreSQL 운영환경은

다양할 수 있지만, 먼저 나의 운영환경을 이해하고 나에게 맞는 상황들을 고려하여 모니터링을 잘

수행하고 예방한다면 auto vacuum은 정상적으로 수행될 것이므로 vacuum에 대해 너무 걱정할 필요는

없을 것이라 생각됩니다.

#. Replication Conflict는 아래를 참조하세요.

Replication conflicts in PostgreSQL and how to deal with them | CYBERTEC PostgreSQL | Services & Support (cybertec-postgresql.com)

#. Script 참고

-. pageinspect는 debugging 목적으로 database pages의 내용을 살펴볼 수 있는 기능을 제공

CREATE EXTENSION pageinspect;

누구나 아는 DBMS 튜닝 이야기 하지만 어려운 튜닝-1편

SKAI Worldwide | 스카이월드와이드 — Fri, 14 Jun 2024 14:06:22 +0900

작성자: 윤성호 수석- DB테크센터 -DB Tech 1팀

1. PostgreSQL 넌 뜨겁구나

상용 DBMS는 대부분 DBMS에서 사용하는 메모리 부분이나 세션관련된 파라미터는 AUTO이다. 우리가 처음 수동 변속기 차량을 운전하면 어렵다고 느끼게 된다 이유는 클러치를 밟아야 하고 또 속도나 엔진의 RPM에 따른 변속을 해주어야한다. 그렇지 못하면 차량이 울컥하거나 심하면 엔진이 꺼진다. 하지만 오토변속기는 클러치나 변속 타이밍에 신경을 써야할 필요가 없기에 운전에 대한 부담이 적기에 한결 운전하기 편하고 집중 할 수 있다.

아쉽게도 오늘의 주인공은 수동이다. 하지만 수동이 단점만 있는 것인가 그렇지는 않다 수동이기에 가볍고 메모리의 효율도 좋고 최적의 설정시 좋은 성능을 발휘 한다.

급변하고 급속하게 커지고 있는 데이터 시장에서 DBMS는 더 다양하고 더 많은 데이터를 저장 할 것을 강하게 요구받고 있다. 수동이지만 날렵한 이번 주인공인 PostgreSQL의 파리미터 설정을 통해 급변하는 데이터 시장의 요구를 대응해보자. 레이싱 경기를 치루는 고성능 스포츠카 차량의 대부분은 수동임을 기억하자.

2. 어디부터 볼까

DBMS(PostgreSQL)의 설정 변수는 매우 다양하다. 서버 스펙, 네트워크 및 설정, 스토리지 서버, DBMS를 구동하기 위한 OS 환경변수, DBMS의 기초인 인스턴스 환경변수, DB부분의 환경변수 등 공개된 변수와 공개되지 않은 변수까지 더하면 약 백여가지에 이른다. 우린 이 모든 것을 한번에 보기는 불가능에 가깝다. 그래서 조금씩 알아가보기로 하며, 위의 변수들은 어렵고 지루할 수 있는 이야기들이다. 하지만 반드시 성능을 위해 알아야하는 이야기이기에 쉽게 풀어가보려 한다.

3. 메모리 부터 풀어보자

메모리는 DBMS에 매우 중요한 요소이다, 수많은 요소들이 DBMS에 많은 영향을 미치지만 메모리는 가장 큰 영향을 미치는 요소들 중에 하나이다. 이에 DBMS와 메모리는 매우 깊고 중요한 관계이다. 데이터의 다양성, 사이즈, 다양한 데이터 처리, 처리 속도에 대한 요구의 증가로 메모리 부분의 중요도는 더욱 증가하고 있다. 그래서 우리는 메모리 부문 부터 알아보기로 하자.

DBMS에서 사용되는 heap, cash, mem 라고 부르는 것에 대하여 이야기 할 것이다. 왜 같은 메모리인데 다르게 부르고 또 어떻게 사용되는지 간단하게 집고 넘어가자.

heap : DBMS 인스턴스의 다양한 활동을 지원하기 위한 필요한 정보를 주로 저장하는 데 사용되는 메모리의 한부분이다.
cash : DB에서 가장 자주 사용되는 데이터나 메타 데이터를 빠르게 접근할 수 있도록 설정되어 있는 메모리의 한 부분으로서 DB엔진이 가장 빠르게 접근 할 수 있는 주소에 배치되어진다. DB의 운영에 필요한 메타 정보, 통계정보, Explain 정보 등이 있다.
mem : 일반적인 DB가 사용하는 메모리 공간으로, 예를 들면 데이터가 상주하는 bufferpool이나 temp 공간 등이 있다.

각각의 DBMS 별로 사용되는 용어나 작동하는 방식은 각각 다를 수 있다.

4. DBMS와 메모리 그리고 스토리지, 그 둘의 끈끈함

메모리와 스토리지는 떨어 질 수 없다. 그래서 둘의 관계를 한번 간단하게 살펴보고자 한다.

요즘 DBMS들의 성능이 많이 좋아지고 평준화가 되어가고 있다. 그 이유 중 하나는 많은 사용자들이 스토리지 서버에 사용되는 저장장치를 HDD에서 SSD로 옮겨가면서 HDD의 RPM과 헤드의 물리적인 요소를 탈피함으로 물리적 한계를 극복한 논리적인 저장으로의 변화에 따른 속도의 증가로 서버용 스토리지의 성능은 눈부시게 향상 되었기 때문이다(눈물이 날 정도 이다. 오래 DB쪽에 일을 했다면 HDD 스토리지로 인한 스트레스는 아마 아시리라 생각한다).

메모리 역시 CPU의 클럭이 증가함에 따라 메모리의 클럭 역시 높아지고 있다. DDR3, 4, 5로 발전하면서 클럭이 비약적으로 높아짐에 따라 메모리 속도 역시 빨라지고 있다. 하지만 둘의 속도는 여전히 차이가 나고 있다.

메모리와 스토리지는 서로 필수 불가결한 존재이기에 둘 간의 성능 차이가 많이 난다면 여러운 환경에 직면하게 된다. 메모리는 DDR5(5600MHz)인데 스토리지 서버의 저장 장치를 HDD(아직 SSD는 가격이 비싸다)를 사용한다면 DBMS의 성능에 크나큰 장애가 될 것이다. 그 이유는, 메모리는 휘발성이라는 매우 큰 단점이 있기 때문에 비휘발성인 스토리지에 저장을 해야한다. 메모리에서 스토리지에 쓰는 시간이 오래 걸린다면 I/O wait가 많이 발생하고 commit이나 log 쓰기, 데이터 저장, temp 작업 등이 느려지기에 DB 성능의 발목을 잡는다. 또한, DBMS 작업의 대부분이 메모리에서 일어나는데 데이터를 메모리에 올리는 상황에서도 느린 스토리지로 인해 메모리에 데이터의 적재가 늦어지면 DB의 성능이 느려진다. 그로인한 DB 옵티마이저(Optimizer)의 오판을 불러오기도 한다는 것을 기억하자.

5. PostgreSQL 메모리 구조

DBMS의 메모리 구조는 상당히 복잡하다. 메모리의 구조를 알지 못한다면 튜닝의 포인트를 잡을 수가 없다. 그러니 간단하게 메모리의 구조를 집고 넘어가자. DBMS의 제품별로 메모리 구조나 용어가 서로 크게 다를 수 있다. 크게 공유 메모리를 강조하는 쪽과 비공유 메모리를 강조하는 쪽으로 나누어지는데 우리가 다룰 PostgreSQL은 비공유를 강조하는 쪽에 가깝다.

Postgresql은 크게 Local Memory와 Shared Memory로 나눌 수 있다.

Local Memory : 개별 Backend process가 개별로 할당을 받아 사용하는 비공유 메모리로, 전체 Connection의 수를 고려하여 설정해야한다. 하위로는 Maintenance_work_mem, Temp_buffer, Work_mem, Catalog_cache, Optimizer, Executer 등이 있다.

Shared Memory : 모든 process가 공유해서 사용하는 공간으로, 전체 물리 메모리와 세션수를 고려하여 설정을 해야한다. 하위로는 Sheard Buffers, WAL Buffers, CLOG buffers, Lock Space, Other Buffers가 있다.

6. PostgreSQL 메모리별 역할

Local Memory 메모리에 포함되는 메모리

Maintenance_work_mem : VACUUM, CREATE INDEX, and Restoring database dumps 작업시 사용되는 메모리로, work_mem보다 크게 설정하는 것을 권장한다.(기본 64MB)

Temp_buffer : 세션에서 사용할 수 있는 Temp buffer 메모리의 양을 설정한다. Temp buffer의 활용도는 생각보다 많다는 것을 기억하자. 세션의 작업 형태나 SQL의 업무에 따라 다르기에 적절한 양의 설정이 필요하다. Temp_buffer에 설정된 양까지 각 세션에서 사용할 수 있다.

Work_mem : 세션의 작업시 사용되는 메모리로, Sort(Order by, Distinct, Merge join), Hash 등에 사용되며 세션 작업 별로 지정된 메모리가 할당되기에 총 세션수와 총 물리 메모리를 고려해 설정해한다.

Catalog_cache : system catalog 메타 데이터를 조회할 때 사용하는 메모리로, 자주 사용되는 영역으로 별도의 메모리로 관리하는 메모리이다.

Optimizer / Executer : SQL를 실행계획을 생성하고 실행하는데 필요한 메모리영역이다.

Shared Memory 메모리에 포함되는 메모리

Shared Buffers : Disk의 I/O에 가장 크게 영향을 미치는 메모리로, Disk로부터 데이터를 메모리로, 메모리에서 Disk로, 데이터의 변경 등에 사용되는 buffer로 DB의 성능에 큰 영향을 주는 메모리이다.

WAL Buffers : 각각의 세션들에서 수행되는 트랜잭션에 변경된 데이터에 대한 변경 로그를 캐싱하는 메모리로, Disk에 쓰기 전에 WAL 데이터의 버퍼링 하는 메모리이다.

CLOG buffers : CLOG는 Commit Log로 CLOG는 CC(Concurrency Control) 메커니즘에 대한 모든 트랜잭션의 상태(예 : in_progress, committed, aborted)를 유지한다.

Lock Space : Lock와 관련된 정보를 저장하는 메모리로, DBMS에서 사용되는 모든 Lock정보를 기록합니다. 데이터의 정합성을 유지할 때 중요한 역할을 하는 것이 Lock이다.

이번에는 DBMS에서 사용되는 메모리에 대하여 간단하게 살펴 보았다.

다음 편부터 실질 적인 메모리 부분 파라미터들의 종류와 역활에 대하여

그리고 그 파라미터들의 변경을 통해 성능이 어떻게 변하는지(튜닝) 알아보도록 하자

[프로모션] PostgreSQL을 사용하는 스타트업을 위한 DB 운영 무상 교육 이벤트

SKAI Worldwide | 스카이월드와이드 — Wed, 12 Jun 2024 10:21:15 +0900

스타트업을 위한 안정적인 DBMS관리 노하우

SKAI Worldwide | 스카이월드와이드 — Mon, 3 Jun 2024 14:51:18 +0900

스타트업을 위한 안정적인 DBMS관리 노하우

오픈소스 DBMS의 성능에 대한 신뢰성이 높아지면서 오픈소스 DBMS 시장 규모는 점차 확대되고 있으며, 국내 많은 스타트업도 이러한 추세에 따라 PostgreSQL, MariaDB 등과 같은 오픈소스 DBMS를 도입하고 있습니다. 오픈소스를 사용하면 개발 리소스를 절감하고, 비용 효율을 극대화하며, 빠른 시장 변화에도 유연하게 대응할 수 있어 스타트업에게 매력적인 선택지가 됩니다.

특히 운영 안정성이 중요한 데이터베이스 시장에서도 오픈소스의 사용률이 증가하고 있습니다. 대표적으로 PostgreSQL은 글로벌 DBMS 시장에서 전체 인지도 4위를 차지하였고, 2023년 전문 개발자 대상 인기도 설문조사에서 1위를 기록했습니다.

그러나 데이터베이스는 상용 제품을 사용하는 기업도 자체적인 기술 역량만으로 운영하기 어려워 벤더사 혹은 파트너사의 기술지원을 필요로 합니다. 스타트업에서 오픈소스 DBMS를 운영하는 것은 생각보다 어려우며, 결국 심각한 장애 및 성능저하로 인한 기술지원의 필요성이 발생하게 됩니다. 스타트업에서 오픈소스 DBMS를 운영하는데 어떤 어려움이 있는지 살펴보고, 안정적인 운영을 위한 기술지원을 받기 위해 고려해야 하는 요소들을 분석해보겠습니다.

전문성 있는 DBA 채용의 어려움

스타트업은 자체 DBA 채용에 어려움을 겪습니다. 경험 많은 DBA는 고도로 숙련된 전문가로, 경쟁력 있는 연봉을 요구하지만, 스타트업은 초기 자금이 제한적이므로 높은 인건비를 감당하기 어렵습니다. 또한, DBA는 안정적인 직장을 선호하고 데이터베이스 직무의 전문성을 중시하기 때문에, 미래가 불확실하고 다양한 역할을 동시에 수행할 수도 있는 스타트업을 부담스럽게 여길 수 있습니다. 따라서 많은 스타트업은 외부 컨설팅이나 기술지원을 통해 데이터베이스 관리를 해결하게 됩니다.

보안 취약성 및 가용성 유지의 어려움

안정적인 DBMS 운영의 핵심은 데이터 보안과 고가용성입니다. 스타트업은 민감한 고객 정보와 비즈니스 데이터를 다루기 때문에 적절한 접근 제어와 권한 관리를 통해 중요한 자산을 보호해야 합니다. 빠르게 변화하는 환경에서 시스템 가용성을 유지하지 못하면 DBMS 장애나 성능 저하로 인해 서비스가 중단될 수 있습니다. 그러나 소규모 스타트업은 주로 Replication 없이 단일로 DBMS를 구성하며, 데이터베이스 전담 관리자가 부재한 경우가 많아 보안과 고가용성을 보장하기 어렵습니다. 이는 고객 이탈과 비즈니스 손실로 이어질 수 있습니다.

신속한 장애 대응 역량 부족

갑작스러운 시스템 장애로 인해 데이터베이스 트랜잭션이 중단되거나 손상될 경우, 신속하게 원인을 분석하고 해결해야 합니다. 그러나 경험이 부족한 DBMS 관리자는 장애 원인 분석과 빠른 해결이 어려워 서비스 중단을 초래할 수 있으며, 이는 고객의 불만을 야기할 수 있습니다. 특히 비즈니스와 직결된 Mission Critical한 장애가 지속되어 서비스 중단 혹은 성능 저하가 장기화된다면, 비즈니스의 다양한 측면에 영향을 미쳐 운영 효율성이 떨어지고 회사의 손실로 이어질 수 있습니다. 따라서 오픈소스 DBMS 장애 발생 시 전문가를 통한 신속한 대응이 필수적입니다.

스타트업을 위한 PostgreSQL 기술지원 서비스는?

이러한 고민을 해결하기 위해 전문 기술지원 회사를 통해 DBMS를 관리하는 것을 권고하고 있습니다. 데이터베이스 관리는 서비스와 바로 직결되므로 전문성과 체계적인 시스템이 완비된 회사를 선택하는 것이 중요합니다. 오픈소스 DBMS 중 PostgreSQL을 사용하는 스타트업이라면 대한민국 1등 기업 비트나인의 PGTS를 사용하는 것을 고려해볼 수 있습니다. PGTS는 PostgreSQL Tech-support Service의 약자로, PostgreSQL Community 버전(오픈소스)을 사용하는 고객에게 특화된 기술지원 서비스입니다.

PostgreSQL DBMS 운영의 어려움을 PGTS로 해결

스타트업에서 PostgreSQL을 운영하면서 기술지원이 필요하다면 PGTS가 가이드가 되어 솔루션을 제시해드릴 수 있습니다. 비트나인은 11년간 꾸준한 PostgreSQL 연구개발 기업으로 글로벌 전문인력인 다수의 Contributor를 보유하고 있어 다양한 범위의 기술지원이 가능합니다. 자체적으로 해결하기엔 부담스러운 업무에 가이드를 받아서 손쉽게 진행해 보세요.

성능 진단 가이드: 현재 구현되는 성능을 진단해보고 최적화하고 싶은 경우
SQL 튜닝 가이드: SQL 튜닝이 필요한데 적절한 방향 제시가 필요한 경우
마이그레이션 노하우: 신규 DB로 마이그레이션을 해야 하는 경우
버전 업그레이드 노하우: PostgreSQL 버전 업그레이드 시 버그 픽스 등 지원이 필요한 경우
DB 운영 가이드 및 교육: DB 운영 전반에 대한 가이드 혹은 교육이 필요한 경우
클라우드 전환시 DB 운영 노하우: 온프레미스에서 클라우드 전환이 필요한 경우

PGTS의 경쟁력: 스타트업 맞춤형 기술지원

테크 포털 기반 체계적인 이력관리: Tech Portal 시스템으로 고객 히스토리를 통합 관리하여 연속성 있게 대응하기 때문에 내부직원이 전담하는 만큼 안정적이고 신뢰할 수 있습니다.
비용 부담을 줄이는 가격 구성: 일반적인 Care Pack 서비스와 서비스 범위는 동일하나 가격이 합리적입니다. 비용 때문에 서비스 이용을 망설였던 스타트업에서도 충분히 가성비 있게 이용할 수 있습니다.
티켓 베이스 기술지원: 티켓 베이스로 필요할 때마다 기술지원을 요청할 수 있어서 리소스 낭비가 없고, 시간 지체 없이 원격으로 곧바로 대응이 가능하여 편리합니다.

위와 같이 PostgreSQL 전문가가 직접 기술지원하는 서비스를 통해

데이터베이스 운영에 대한 걱정을 덜고, 안정적 운영에 대한 노하우도 전수받을 수 있습니다.

스타트업에 최적화되어 있는 PGTS를 통해 오픈소스 DBMS의 강점은 살리고

리스크는 최소화할 수 있는 비트나인의 체계적인 서비스를 경험해보세요!

더욱 유익하고 다양한 PostgreSQL DB의 최신정보를 확인해보세요~!!

bitnine.net/blog

6/12(수) 오후 2시, 첫 번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

SKAI Worldwide | 스카이월드와이드 — Fri, 24 May 2024 14:17:24 +0900

️6/12(수) 오후 2시, 첫 번째 "비트나인 PostgreSQL 기술 웨비나"에 초대합니다.

오픈소스 PostgreSQL 기술지원 서비스를 받아야 하는 이유

SKAI Worldwide | 스카이월드와이드 — Tue, 14 May 2024 08:30:40 +0900

데이터베이스 기술지원 실패 사례

서울시에 위치한 소상공인과 중소기업을 지원하는 모 기관은 E사의 PostgreSQL 기반 상용 DBMS를 사용하면서 다음과 같은 문제들을 경험했습니다.

DB link 연계 불능: 모 기관에서 사용하던 Oracle과 E사가 제공한 데이터베이스와의 연계 작업에서 문제가 발생했고, 이 문제의 원인을 파악하는 데만 3개월이 걸렸습니다.
장애 조치 및 원인 분석 불가: File Lock 문제로 인해 OS가 종료되었고, DB 장애 복구(Fail-over)가 이루어지지 않았습니다. 재시작 후에도 지속적으로 장애가 발생했습니다.
JDBC 드라이버 버전 이슈: E사는 고객 환경에 적합하지 않은 JDBC 드라이버 버전을 제공했습니다. 결국 고객은 PostgreSQL 커뮤니티 버전(무료 오픈소스 버전)을 설치하여 문제를 자체적으로 해결해야 했습니다.

제대로 된 기술지원의 부재가 가장 큰 원인

이 문제들은 DBMS 제품의 문제로 발생하기도 했지만, E사의 체계적이지 않았던 기술지원 서비스가 문제를 더 크게 만들었습니다. 해당 사례에서 보였던 E사의 단점은 아래와 같이 요약할 수 있습니다.

Postgres 기술 역량 부족한 기술 파트너 배정: E사는 국내에서 자체적으로 기술지원을 제공할 수 있는 엔지니어가 없었습니다. 그래서 E사의 Postgres 제품을 교육받은 파트너사를 배정했지만, 효과적인 진전은 없었습니다. 세 차례의 파트너사 교체가 있었음에도 불구하고, 고객은 적절한 해결책을 받지 못했습니다. E사의 파트너사들은 원인을 파악과 문제를 해결하지 못했으며, 이에 따라 담당 엔지니어를 지속적으로 교체했습니다. 이러한 과정에서 제품 이슈에 대한 히스토리가 적절히 관리되지 않았고, 결국 시간을 낭비하는 결과를 초래했습니다.
장애에 대한 명확한 원인 분석 불가: E사의 파트너사들은 발생한 장애에 대한 명확한 원인을 찾지 못했습니다. 결국 고객은 PostgreSQL 커뮤니티 버전을 설치하여 직접 원인을 찾아냈다고 합니다.
기술지원 비용 M/D 기반으로 청구: 제대로된 해결책을 제공하지 않았음에도 불구하고 E사는 기술지원 비용을 M/D(Man-Day) 기반으로 모 기관에게 청구했습니다. 이는 E사의 글로벌 본점의 정책에 따른 것이라고 하는데, 국내에 있는 기관 입장에서는 기술지원 서비스 경험과 비용 청구 때문에 다른 DBMS를 고려하게 되는 계기가 되었습니다.

모 기관과 유사한 사례는 전국적으로 퍼지고 있습니다. 오픈소스 특성을 가진 PostgreSQL이 매력적이지만, 이에 대한 전문 기술지원을 받기가 어렵습니다. 결국 PostgreSQL을 기반으로 하는 상용 벤더사의 도움을 받아야 하는데, 국내에는 아직 PostgreSQL을 코어 단위로 볼 수 있는 경력을 가진 엔지니어를 보유한 기업이 많지 않습니다.

이와 같은 사례를 계기로 지난 4월 비트나인은 PGTS라는 PostgreSQL 기술지원 서비스를 공식적으로 출시했습니다. 본 서비스는 오픈소스 커뮤니티 버전부터 PostgreSQL을 기반으로 한 다른 상용 DB 제품의 코어 엔진까지 지원합니다.

PGTS는 발생한 장애에 대해 신속하게 대응하며, 명확한 원인을 분석합니다. 국내외 체계를 보유하고 있어 24시간 365일 무중단 서비스가 가능합니다. 또한, 테크 포털을 통해 모든 서비스의 이력을 관리할 수 있으며, 고객과 엔지니어가 모니터링할 수 있는 채널을 제공합니다.

PGTS 서비스의 가격도 합리적으로 서버당 n만원을 연간 기준으로 제공하고 있습니다. 가격 정책에 대해 더 자세하게 알고 싶다면 지금 바로 비트나인에 문의하시기 바랍니다.

비트나인은 국내 PostgreSQL 분야의 선두 기업입니다. 비트나인에게 문의만 주신다면 PostgreSQL 관련 문제가 발생된 곳이 언제 어디든지 달려가겠습니다.

PostgreSQL Tech-support Service의 모든 것

▶브로셔 보기

비트나인의 콘텐츠를 계속 받아보고 싶으시다면?

▶뉴스레터 구독하기

제품 및 기술문의

070-4800-3517 | agens@bitnine.net

비트나인 PGTS의 Remote와 Premium 서비스란?

SKAI Worldwide | 스카이월드와이드 — Thu, 2 May 2024 17:21:26 +0900

1년 무료 서비스 프로모션 진행 중!

PGTS의 두 가지 서비스: Remote & Premium

지난 29일, 비트나인은 PGTS 공식 론칭 포스트를 통해 자사의 포스트그레SQL 기술지원 서비스에 대한 소식을 간략하게 전달했었습니다. PGTS 서비스는 PostgreSQL Community 버전을 포함한 모든 PG 기반 상용 제품 대상으로 기술지원 서비스를 직접 제공합니다. 특히, 글로벌 24x365 지원을 위한 조직, 테크 포털의 티켓 대응 시스템, 글로벌 수준의 SLA에 의한 일관되고 예측되는 서비스 품질을 제공함으로써 무중단 기술지원 서비스를 자랑합니다.

이번 포스트에는 PGTS의 두 가지 서비스 모델에 대해 살펴보겠습니다.

PGTS는 기본적인 PG 지원을 제공하는 PGTS Remote와 모든 PG 계열 제품에 대한 PGTS Premium 서비스로 구분됩니다.

PGTS Remote 서비스는 PostgreSQL 커뮤니티 버전을 사용하는 중소기업 고객을 대상으로 24시간 365일 무중단의 차별화된 유지보수 서비스를 제공합니다. 이 서비스는 고객의 비즈니스 연속성을 보장하며, 기술적 문제에 신속하게 대응할 수 있는 지원을 제공합니다.

PGTS Premium 서비스는 원격 및 현장 지원(On-site)을 모두 포함하며, 비트나인의 전문적인 기술력을 바탕으로 한 고품질의 기술지원 서비스를 제공합니다. 이 서비스는 복잡한 기술적 요구사항에 대응하고, 고객 맞춤형 솔루션을 통해 비즈니스 가치를 극대화할 수 있도록 설계되었습니다.

각각의 서비스에 대해 더 깊게 알아보겠습니다.

(이 포스트에 포함된 내용은 비트나인 홈페이지에서 제공하는 PGTS Technical Sheet의 일부를 참조하였습니다. 보다 상세한 정보를 원하신다면, 비트나인 홈페이지에서 PGTS Technical Sheet를 확인해 주시기 바랍니다.)

PGTS Remote 서비스 개요

PGTS Remote 서비스는 PostgreSQL Community Version 9 이후 버전을 지원하며, 다음과 같은 서비스를 제공합니다.

기본적인 PG에 대한 Remote Support

Remote 응대 기본 (TS Center)
최초 설치 및 셋업, 장애 발생시 경중에 따른 현장 지원
Remote 응대를 통한 비용 절감

일반 Care Pack 시장 가격과 유사한 형태의 서비스

파트너 기반의 Care pack 서비스를 100% 대체 가능
비용은 유사하나, 시스템 기반의 실제 서비스 품질은 훨씬 탁월

Tech Portal 시스템 기반의 글로벌 서비스

Care pack에서는 불가능한, 시스템 기반의 유지보수 지원
고객별 History 관리, 24x365 서비스 제공, 체계적인 고객 지원

온건한 PG Community 버전에 가장 집중된 서비스

PostgreSQL 커뮤니티 버전에 대한 DB 유지보수 서비스 지원
다양한 3rd party 제품 연계는 별도 협의 필요

PGTS Remote 서비스 범위 및 서비스 대상

서비스 범위	서비스 대상
PG 커뮤니티 버전 한정 지원 - 타 상용 PostgreSQL 제품 지원 불가	현재 PG Community 버전 사용 및 사용 예정 고객
Professional Service 별도 구매 필요 - DB 튜닝, 마이그레이션 등 서비스는 별도 구매 필요	DB 사용에 있어 충분한 downtime 확보가 가능한 고객
	간헐적 유지보수 서비스 지원이 적합한 고객

PGTS Premium 서비스 개요

PGTS Premium 서비스는 모든 PostgreSQL 제품에 대한 탁월한 기술지원을 포함합니다. 이 서비스는 PostgreSQL 커뮤니티 버전은 물론, 상용 벤더사의 포스트그레스 기반 제품의 PG 코어 엔진 지원까지 제공합니다. 신속하고 지속적인 기술지원을 자랑하는 PGTS Premium은 대규모 고객이나 핵심 비즈니스를 운영하는 고객에게 이상적인 선택입니다.

PGTS Premium은 다음과 같은 서비스를 제공합니다.

빠른 응대, Vendor on-site 지원의 프리미엄 서비스

10분 이내 응대, 2시간 이내 현장도착(수도권)을 원칙으로 하는 서비스 제공

기술력 기반의 High Tech 서비스

Core 기술력을 기반으로 한 Contributor & Committer 서비스
Core-level support를 통한 high tech 서비스

Tech Portal 시스템 on-site 지원을 통한 차별화 서비스

고객 지원 History 관리를 통한 서비스 연속성 제공
24x365 서비스 제공을 위한 글로벌 조직 체계 완비
장애 및 긴급 호출시 온오프라인 동시 기술 지원

검증된 application 추가 제공을 통한 차별화 서비스

필요시 AHM(HA), AEM(Admin, 모니터링)등 각종 툴 제공
PG 기능 확장시 PG Extension 검증을 통한 안전성 지원(Professional Service와의 연동)

PGTS Premium 서비스 범위 및 서비스 대상

서비스 범위	서비스 대상
PG 커뮤니티와 상용 PG 제품 지원 가능 - EDB, eXperDB, Fujitsu 등 타 제품 지원 가능	PG 커뮤니티와 PG 계열 제품 등 관련된 모든 제품 사용 고객
Professional Service 활용 가능 - 연간 20시간 사용 가능 - DB 튜닝, 마이그레이션, 데이터 연동(ETL) 등의 컨설팅 서비스 - 검증된 PostgreSQL 3rd Party 제품 지원 가능	- 미션 크리티컬 업무 사용 고객 - DB 다운타임 확보가 힘들고, 즉각적 업무 재개가 필요한 고객
	타이트한 DB 유지관리 및 기술지원이 필요한 고객

PGTS Premium 서비스 범위 및 서비스 대상

PGTS Premium 서비스에서만 제공되는 Professional Service는 총 3가지로 구성되어 있으며, 연간 20시간의 기술 지원 서비스를 받으실 수 있습니다.

각 서비스에 대한 자세한 내용은 PGTS: Technical Sheet에서 보실 수 있습니다.

PostgreSQL 기술지원 서비스, 지금 바로 신청하세요!

비트나인에서는 포스트그레SQL 기술지원 서비스를 제공하고 있으며, 공식 론칭을 기념하여 2주간 한정으로 1년간 무료로 이용하실 수 있는 프로모션 이벤트를 진행 중입니다. 포스트그레SQL 사용 중 기술 지원이 필요하시거나, 개발용 서버나 중소형 시스템에서 부담 없이 테스트해보고 싶으신 분들은 이 기회를 놓치지 마시고 프로모션에 참여해 보세요!

1년 무료 프로모션 알아보기

PostgreSQL Tech-support Service의 모든 것

▶브로셔 보기

비트나인의 콘텐츠를 계속 받아보고 싶으시다면?

▶뉴스레터 구독하기

제품 및 기술문의

070-4800-3517 | agens@bitnine.net

[프로모션] 무려 1년 무상? PostgreSQL 기술지원 서비스 PGTS 공식 론칭 기념!

SKAI Worldwide | 스카이월드와이드 — Tue, 30 Apr 2024 16:29:07 +0900

[백서 프롤로그] 그래프 기술이 만드는 차원이 다른 생성형 AI

SKAI Worldwide | 스카이월드와이드 — Tue, 30 Apr 2024 08:30:27 +0900

생성 AI 모델의 한계

2023년, 생성형 AI(GenAI) 분야가 급격히 성장하고 있습니다. 이러한 AI 모델들은 대규모 언어 모델(LLM)을 기반으로 하며, 대규모 데이터셋으로 사전학습되어 있습니다. 특히, 이미지, 텍스트, 영상 등 창조적인 작업 분야에서 활용되며, 그 정확도와 효율성이 꾸준히 향상되고 있습니다.

그러나, 모델 학습 및 실행 과정에서 많은 시간과 자원이 소요되며, 편향성과 환각(hallucination) 현상과 같은 문제가 발생합니다. 환각 현상이란 생성형 AI가 실제로 존재하지 않는 정보나 콘텐츠를 생성하는 것을 의미합니다.

이러한 문제를 해결하기 위해, 최근 생성형 AI 모델은 대규모 데이터셋으로 사전학습을 하고, 프롬프트 엔지니어링(prompt engineering)과 미세조정(fine-tuning)을 수행하고 있습니다. 하지만, 학습 이후 최신 정보나 특정 주제를 반영하는 데 한계가 있으며, 환각 문제로 인해 답변의 정확성이 떨어지기도 합니다.

생성형 AI 활용의 한계

이를 극복하기 위한 접근 방식 중 하나가 검색-증강 생성(Retrieval-Augmented Generation, RAG)입니다.

이 글은 2024년 비트나인의 네 번째 월간 백서인 '그래프 기술이 만드는 차원이 다른 생성형 AI'의 도입 부분을 일부 담았습니다. 더 자세한 내용에 대해서는 링크를 눌러 확인해 주세요!

▶더 읽어보기

비트나인의 생성형 AI 솔루션, AgensSQL GenAI Edition에 대해 궁금하시다면?

▶제품 소개서 보기

비트나인의 콘텐츠를 계속 받아보고 싶으시다면?

▶뉴스레터 구독하기

제품 및 기술문의

070-4800-3517 | agens@bitnine.net

비트나인, PostgreSQL 기술지원 서비스(PGTS) 공식 론칭

SKAI Worldwide | 스카이월드와이드 — Mon, 29 Apr 2024 08:30:55 +0900

PGTS란?

비트나인은 포스트그레SQL 커뮤니티 버전부터 포스트그레스 기반인 상용 제품을 아우르는 글로벌 통합 기술지원 서비스인 ‘PGTS’를 공식적으로 론칭했습니다.

PGTS는 PostgreSQL Tech-support Service의 약어로 모든 포스트그레SQL 제품을 대상으로 기술지원을 제공하는 서비스입니다. 오픈소스 커뮤니티 버전은 물론 포스트그레SQL을 기반으로 한 다른 상용 DB 제품까지도 기술지원을 제공하고 있습니다.

PGTS, why now?

PGTS는 최근 포스트그레SQL에 대한 높은 수요와 그 요구를 직접적으로 반영한 최적의 서비스로, 고가 정책의 외산 DBMS를 탈피하려는 경향이 있는 대형 고객사는 물론이고, 자체 DBMS 유지관리가 힘든 중소형 고객사까지 광범위하게 활용될 것입니다.

비트나인은 11년간의 AgenSQL & AgensGraph의 DBMS 서비스 노하우를 바탕으로 코스닥에 상장된 한 국내유일 포스트그레SQL 코어기술 보유기업입니다. 비트나인은 자사 제품 위주로 포스트그레SQL 코어 기술지원은 제공해 왔지만, 최근 포스트그레SQL의 높은 수요로 인해 PGTS 서비스를 공식적으로 론칭했으며, 보장되는 제품 범위를 확대했습니다.

"24 x 365" 무중단 PGTS의 지원 서비스, 비결은?

비트나인의 PGTS 서비스는 세 가지 핵심 특성을 가지고 강력한 다이렉트 지원을 제공합니다:

24 x 365 무중단 서비스	PostgreSQL 코어기술 Direct 지원	Tech Portal 시스템 제공
글로벌 단위의 서비스 형태 경쟁사 대비 가장 빠르게 대응 10분 이내 빠른 응답 2시간 이내 현장도착(수도권) 보장	PostgreSQL 핵심 컨트리뷰터를 통한 기술자 Direct 지원 국내외 R&D 센터 보유 체계적인 SLA 프로세스	Tech Portal이라는 특화된 시스템 기반의 기술지원 모든 서비스 History 관리 고객별 전용 Monitoring 제공

Tech Portal 시스템 주요 화면

Tech Portal 시스템을 통해 고객별 모든 history를 바탕으로 체계적이며 통합된 신속한 24x365 논스톱 기술지원을 제공합니다.

Tech Process Tracking은 고객의 모든 프로세스를 트레킹하는 화면으로, 테크포털의 티켓 대응이력, 진단결과 등 지속적인 트레킹을 통해 연속성 있는 지원이 가능합니다. 또한, 고객은 테크 지원상황에 대해 모니터링이 가능합니다.

Customer Service History는 고객의 모든 누적된 이력을 기반으로 데이터 분석을 통한 통합된 사전/사후 지원이 가능합니다.

Real-time Support는 실시간 원격 및 출동을 동시 지원합니다. 고객의 콜이나 Live Chat 문의를 바탕으로 신속한 출동 서비스와 연계하여 실시간 원격 및 2시간 이내 출동방문을 동시 제공합니다. (이는 서비스의 버전에 따라 제공되는 내용이 상이할 수 있습니다)

다음 편 예고: PGTS Remote vs PGTS Premium의 차이

다음 PGTS 블로그 포스트에서는 PGTS Remote와 Premium이 제공하는 상세 서비스 내용과 차이에 대해 알아보겠습니다. 그리고 그 외 이 공식 론칭 글에서 다루지 못한 상세 정보에 대해 살펴보겠습니다.

PGTS 공식 론칭과 함께 선착순 프로모션 이벤트도 진행되고 있으니, 포스트그레SQL 도움을 받고 싶다거나 이벤트에 관심 있으신 분들은 언제든지 비트나인 홈페이지에 방문하시기 바랍니다!

PostgreSQL Tech-support Service의 모든 것

▶브로셔 보기

비트나인의 콘텐츠를 계속 받아보고 싶으시다면?

▶뉴스레터 구독하기

제품 및 기술문의

070-4800-3517 | agens@bitnine.net

기업에 PostgreSQL 커뮤니티 버전 기술지원이 필요한 이유

SKAI Worldwide | 스카이월드와이드 — Wed, 24 Apr 2024 13:03:52 +0900

전 세계 사용성이 계속 증가하는 PostgreSQL

2022년에 작성한 ‘기업 데이터 환경에 PostgreSQL이 최적인 이유’라는 블로그 글에서는, 수년간 눈에 띄는 성장을 이룬 오픈소스 관계형 DBMS인 포스트그레SQL을 소개하며, 기업들이 왜 이 데이터베이스를 선택해야 하는지를 탐구했습니다.

오픈소스 RDBMS 관심도 순위 (2024년 4월 기준) (출처: DB-Engines)

2년이 지난 현재, 포스트그레SQL은 여전히 글로벌 DBMS 시장에서 전체 인지도 4위를 유지하며, 2023년 전문 개발자 대상 설문조사에서는 인기도 1위를 차지하면서 전 세계적으로 사용률이 크게 증가하고 있음을 증명했습니다.

2023 스택 오버플로우 전문개발자 대상 설문조사 (출처: 스택 오버플로우)

포스트그레SQL에 대한 소개는 지난 발행글들을 통해 이미 많이 다루었습니다. 그러나 이번 글에서는 포스트그레SQL의 시장 현황과 장점을 소개하는 대신, 종종 간과되기 쉬운 기술 지원의 중요성에 초점을 맞추어 살펴보고자 합니다.

PostgreSQL에 대해 더 알고 싶다면?

[백서 프롤로그] 오픈소스 DB 전성시대, 기업들이 선택하는 데이터베이스는?

클라우드 전환에서의 오픈소스 DB, 선택 아닌 필수 오픈소스 DBMS는 최신 IT 트렌드인 클라우드 네이티브 및 빠른 기술 혁신을 위한 기반으로 각광받고 있습니다. 기능과 성능 면에서 지속적인 발

bitnine.tistory.com

기업 데이터 환경에 PostgreSQL이 최적인 이유

블로그 글을 보시기 전에 2024년 비트나인의 첫 번째 월간 백서인 '오픈소스 DB 전성시대, PostgreSQL을 선택하는 이유'를 읽어보세요! ▶ 지금 다운로드하기! 오픈소스 vs 상용, 벌어지는 인기 트렌드

bitnine.tistory.com

국내 PostgreSQL 시장의 기술 지원 현황: 커뮤니티 버전의 문제

포스트그레SQL은 강력한 기능과 개방성 덕분에 전 세계적으로 광범위하게 사용되는 데이터베이스 관리 시스템(DBMS)입니다. 비트나인의 2월호 백서에 언급된 바와 같이, 최근 국내 공공 기관들도 비용 절감을 포함한 다양한 이점을 고려하여 포스트그레SQL과 같은 오픈소스 DBMS의 도입을 적극 검토하고 있습니다. 그러나 국내에서 포스트그레SQL 기술 지원 서비스는 주로 네 가지 주요 문제에 직면하고 있습니다.

기술 지원의 부족

많은 국내 기업들이 PG 코어 기술에 대한 충분한 지원을 받지 못함으로써, 서비스의 연속성을 유지하는 데 필요한 체계를 갖추지 못하고 있습니다. 이는 고객 만족도 저하로 이어지며, 결국 포스트그레SQL의 전반적인 신뢰성에 부정적인 영향을 미치고 있습니다.

기술력의 결여

현재 국내 시장에서는 PG 커뮤니티 버전에 대한 충분한 기술 지원을 제공할 수 있는 업체가 드물어, 이는 미션 크리티컬 업무에 포스트그레SQL을 효과적으로 활용하는 데 상당한 장애로 작용하고 있습니다.

인력의 부재

PG 코어에 대한 컨트리뷰터나 확장 기능 개발자가 국내에 충분하지 않은 상황입니다. 이는 포스트그레SQL에서 발생하는 문제들이 해결되지 않고 방치되는 원인이 되고 있으며, 기술 지원 업체들이 소수의 엔지니어에게만 의존하고 있어 서비스의 안정성에 문제가 생기고 있습니다.

서비스 연속성의 어려움

체계적인 History 관리 시스템이 없어 서비스 연속성을 유지하는 데 어려움을 겪고 있습니다. 또한, SLA(Service Level Agreement)에 따른 서비스 품질 기준이 마련되어 있지 않아, 일관되고 예측 가능한 서비스 제공이 어려운 상황입니다.

커뮤니티 버전의 문제의 해결책 모색

포스트그레를 안정적으로 운영하기 위해 아래 필수 요소들을 제시합니다.

필수 기술력 확보

미션 크리티컬한 업무를 수행하기 위해서는 PG 코어 기술력 확보가 필수적입니다. 이는 장애의 원인을 정확히 분석하고, 발생할 수 있는 이슈를 효과적으로 우회하기 위한 중요한 조치입니다.

커뮤니티와의 협력

PG 커뮤니티와의 협력을 통해 기술적 역량과 인지도가 높은 컨트리뷰터 및 개발자를 확보하는 것이 중요합니다. 이를 통해 전문 엔지니어로 구성된 체계적인 기술 지원 팀과 R&D 협업을 강화하여, 현장에서 발생하는 문제와 제품 개발에 대한 요구사항을 신속하게 해결할 수 있습니다.

서비스 품질과 연속성 구축

Technical Support Portal을 통한 History 관리를 포함한 서비스 연속성과 즉시성을 보장하는 체계적인 지원 시스템의 구축이 필요합니다. 이와 함께, 글로벌 기준에 부합하는 SLA를 준수하여 고품질의 서비스를 제공해야 합니다.

그래서 PostgreSQL의 기술지원은 어디서 받나요?

국내에서 포스트그레SQL의 기술 지원 관련 문제와 해결책을 제시했음에도 불구하고, 데이터베이스 전문 벤더사가 아닌 일반 기업에서는 이러한 해결책들을 실행하기 어려운 것이 현실입니다. 따라서, 포스트그레SQL을 다루는 벤더사의 직접적인 지원이 매우 필요시 되고 있습니다.

비트나인은 포스트그레SQL 개발 역량과 경험을 갖춘 DBMS 전문 벤더사로, 일반 커뮤니티 버전을 넘어서 개선된 아젠스SQL 엔터프라이즈 버전과 숙련된 엔지니어들이 제공하는 기술 지원 서비스를 제공하고 있습니다.

특히, 비트나인은 모든 포스트그레SQL DB 제품에 대해 글로벌 전 지역 기술 지원 서비스와 벤더사의 강력한 직접 지원을 제공하는 벤더사의 강력한 Direct 지원을 제공하는 서비스를 선보일 예정입니다. 서비스의 공식 론칭과 함께 따라오는 정보도 함께 업로드될 예정이니 많은 기대와 관심 부탁드립니다!

오라클 호환성 지원하는 PostgreSQL 기반 엔터프라이즈 DBMS AgensSQL

▶제품 소개서 보기

비트나인의 콘텐츠를 계속 받아보고 싶으시다면?

▶뉴스레터 구독하기

제품 및 기술문의

070-4800-3517 | agens@bitnine.net

기업의 생성형 AI 도입을 위한 응답 품질 향상 필요성 및 방법

SKAI Worldwide | 스카이월드와이드 — Mon, 22 Apr 2024 12:30:56 +0900

기업의 생성형 AI 도입의 어려움

현재 생성형 AI는 기업의 생산성과 업무 효율성을 끌어올리는 방면에서 많은 관심을 받고 있습니다. 하지만 각 분야에서 다소 보편적인 결과를 출력하는 생성형 AI를 도입하는 것은 신뢰도 높은 인사이트를 도출하는 측면에서 어려움이 존재합니다. 이러한 어려움을 해결하고, 기업의 생성형 AI 도입에 기여하기 위해 생성형 AI의 결과 개선 방법으로 RAG 프레임워크가 대두되고 있습니다. RAG는 생성형 AI 모델의 재학습 없이, 생성형 AI의 환각 현상을 해결하거나 일반적인 답변을 개선할 수 있습니다.

AgensSQL GenAI Edition은 PostgreSQL DB 엔진 및 전문가 서비스인 AgensSQL의 Enterprise Plus 제품으로, RAG 역할을 수행하기 위해 지식그래프를 활용하여 사용자 정보를 반영하는 맞춤형 RAG 확장 프레임워크로 개발되었습니다. 그리고 LLM, Vector DB, Graph DB 등 서로 간을 연동하기 위해 오픈소스 프레임워크인 PostgreSQL를 활용합니다. 본 글에서는 AgensSQL GenAI Edition에서 활용한 지식그래프와 PostgreSQL에 대해 알아봅니다.

RAG 프레임워크에서 그래프의 역할

지식 그래프를 적용하면 질문이 복잡해지거나 학습되지 않은 정보에 대해서 환각현상을 일으키거나 일반적인 답변만을 얻을 수 있는 생성형 AI의 결과 품질이 개선됩니다. 그래프는 사람, 장소, 키워드 등의 객체를 나타내는 노드와 객체 간의 관계를 나타내는 엣지의 집합으로 이루어져 있어 정보를 유연하게 정의하는데에 의미가 있습니다. 예를 들어 온라인 쇼핑에서는 사용자의 구매 이력과 상품 간의 관련성으로 표현합니다. 지식 그래프로 사용자의 환경과 분야 등의 정보를 반영하여 생성형 AI의 결과를 두 가지 측면에서 개선할 수 있습니다.

첫 번째로, 사용자의 질문에 대해 보다 정확한 답변을 생성할 수 있습니다. 예를 들어 지식 그래프를 사용하여 상품과 구매자 간의 관계, 거래 내역, 사용자 선호도 등을 표현하고, 이를 기반으로 한 추론 과정을 통해 더 심층적이고 유용한 결과를 도출합니다.

두 번째로, 더 빠르고 정확하게 정보를 검색하고 분석합니다. 사용자 프로필, 행동 패턴, 관심사 등을 지식 그래프로 표현하여 고객 세분화를 수행하고, 이를 통해 생성형 AI가 상황에 맞는 개인화된 서비스를 제공합니다.

그래프 RAG의 데이터 준비 (이미지 출처: AWS)

실제로 AWS에서는 생성형 AI의 응답 정확도 향상을 위한 방법으로 RAG에 지식 그래프를 적용하고 있습니다. 질문 내용이 그래프 스키마에 잘 반영되어 있지 않으면 정확도가 떨어지기 때문에, 지식그래프에서 질문과 관련된 키워드의 인접 노드를 탐색하여 추가 컨텍스트를 확보함으로써 결과를 보완하도록 구성했습니다.

PostgreSQL을 사용해야 하는 이유

PostgreSQL (이미지 출처: Quest)

오픈소스를 활용하기 위한 PostgreSQL은 확장 가능성 및 표준 준수를 강조하는 객체-관계형 데이터베이스 관리 시스템입니다. RAG 방법론을 적용함에 있어 PostgreSQL는 특히 활성화된 커뮤니티로 개발 생태계 제공과 내장된 확장 기능으로 유연함을 가지고 있습니다. 이 밖에도 아래와 같은 다양한 역할과 기능을 제공합니다.

성능 및 확장성 :

- 지형 공간 지원

- 무제한 동시성과 같은 독점적인 데이터베이스 기술에서만 확인할 수 있는 다양한 성능 최적화 지원

- 여러 데이터 유형에 대해 심층적이고, 광범위한 데이터 분석 실행

동시성 지원 :

- 여러 사용자가 동시에 데이터에 액세스하여 동시성을 효율적으로 관리

다양한 언어 지원 :

- 여러 프로그래밍 언어의 호환성과 지원

- Python, JavaScript, C/C++, Ruby 등 시스템 충돌 없음

- 사용자가 능숙한 언어로 데이터베이스 작업 수행 가능

100% 오픈소스 :

- 지식, 전문성, 오픈소스 가치의 강력한 토대를 기반으로 구축

- 전 세계에서 가장 진보한 데이터베이스

- 기업에는 합리적인 가격

데이터베이스 통합 :

- 라이선스 비용 통합

- 벤더 종속 탈피

- 데이터베이스의 총 소유 비용 절감

- 애플리케이션 이식성 개선

결론

이 글에서는 RAG 역할을 하는 AgensSQL GenAI Edition에 활용되는 지식그래프와 PostgreSQL의 내용을 다뤘습니다. 각 역할은 사용자의 질문에 보다 정확한 답변하도록 돕고, 정보 접근 측면에서 유연성과 확장성을 지원하는 것입니다.

생성형 AI로 만들어진 인공지능 서비스들은 대규모 데이터의 학습으로 만들어졌기 때문에, 전문적이고 세부적인 답변을 기대하기 어렵습니다. 기업들의 생성형 AI 활용을 극대화하기 위해 관련 분야의 정보를 적용시키고, 이에 부합하는 결과를 도출해야 합니다. PostgreSQL로 사용자의 정보 및 다양한 피드백을 담고, 지식그래프로 사용자의 질문 관련 키워드들을 제공하여 보다 향상된 Gen AI 서비스를 기대합니다.

참고

1) Amazon Bedrock으로 그래프 RAG 구현하기

2) PostgreSQL

비트나인의 생성형 AI 솔루션, AgensSQL GenAI Edition에 대해 궁금하시다면?

▶제품 소개서 보기

비트나인의 콘텐츠를 계속 받아보고 싶으시다면?

▶뉴스레터 구독하기

제품 및 기술문의

070-4800-3517 | agens@bitnine.net