[Linux] OpenSSL을 사용한 자체 서명된 CA 생성 가이드

 내부 서비스에서 TLS 보안 연결을 구성할 때 외부 인증 기관(CA)을 사용하는 대신, 자체 서명된 인증서를 기반으로 사설 CA(Private CA)를 구성하는 방식이 종종 사용됩니다. 특히 비용 절감이나 내부 네트워크 전용 인증이 필요한 경우 적합한 접근법입니다. 이 문서에서는 OpenSSL을 사용하여 자체 서명된 CA를 구성하는 방법을 단계별로 안내합니다. 1. 준비 사항 루트 권한 또는 sudo 명령을 사용할 수 있는 계정 OpenSSL이 설치된 리눅스 시스템 2. 자체 서명된 CA 생성 절차 2.1 CA용 개인 키 생성 256비트 ECDSA(Elliptic Curve Digital Signature Algorithm) 기반의 키를 생성합니다. 키 생성 속도는 하드웨어 성능과 엔트로피 수준에 따라 달라질 수 있습니다. # openssl genpkey -algorithm ec -pkeyopt ec_paramgen_curve:P-256 -out ca.key 2.2 자체 서명된 CA 인증서 생성 위에서 생성한 ca.key 를 기반으로 CA 인증서를 생성합니다. 인증서는 X.509 형식이며, 유효 기간은 10년(3650일)로 설정합니다. # openssl req -key ca.key -new -x509 -days 3650 \\ -addext keyUsage=critical,keyCertSign,cRLSign \\ -subj "/CN=Example_CA" -out ca.crt /CN=Example_CA 는 CA의 Common Name입니다. 필요에 따라 적절한 명칭으로 변경하세요. 3. 보안 설정 CA 개인 키 파일의 권한을 적절히 설정하여 무단 접근을 차단합니다. # chown root:root ca.key # chmod 600 ca.key 4. 클라이언트에 인증서 등록 (선택사항) 생성한 ca.crt 파일을 시스템 전체에서 신뢰하도록 하려면, trust 명령어를 사용해 볼 수 있습니다. 이 명...

[MariaDB] Galera 클러스터 구축9: Weighted Quorum과 Split Brain 문제 완전 정복 - 이론 및 설계 원리

 Galera Cluster를 처음 도입하려는 개발자들이 가장 자주 묻는 질문이 있습니다. "왜 최소 3개의 노드가 필요한가요? 비용 절감을 위해 2개로는 안 되나요?" 이 질문의 답은 데이터베이스 클러스터링의 핵심 개념인 Weighted Quorum 과 Split Brain 문제에서 찾을 수 있습니다. 오늘은 이 두 개념을 깊이 있게 살펴보고, 안정적인 Galera Cluster 구축 방법을 알아보겠습니다. Split Brain 문제란 무엇인가? Split Brain은 다중 마스터 데이터베이스 시스템에서 발생하는 가장 심각한 문제 중 하나입니다. 이는 클러스터 내 노드들 간의 네트워크 통신이 끊어졌지만, 각 노드가 여전히 클라이언트와 연결되어 독립적으로 작동할 때 발생합니다. 실제 상황으로 이해하는 Split Brain 온라인 쇼핑몰의 재고 관리 시스템을 예로 들어보겠습니다 상황 : Server A와 Server B 간의 네트워크 연결이 끊어짐 문제 발생 : 두 서버 모두 각각의 웹 애플리케이션으로부터 주문 요청을 받음 Server A : 상품 재고를 100개에서 95개로 업데이트 (5개 판매) Server B : 같은 상품 재고를 100개에서 80개로 업데이트 (20개 판매) 각 서버는 상대방이 장애 상태라고 판단하고 독립적으로 운영을 계속합니다. 결과적으로 동일한 상품에 대해 서로 다른 재고 수량이 기록되어 데이터 정합성 에 치명적인 오류가 발생하게 됩니다. 네트워크가 복구된 후에는 어떤 데이터가 올바른지 판단하기 어려워지고, 수동으로 데이터를 정리해야 하는 상황이 발생할 수 있습니다. Weighted Quorum의 핵심 원리 Quorum의 기본 개념 Quorum(정족수)은 클러스터 내에서 유효한 결정을 내리기 위해 필요한 최소 투표 수 를 의미합니다. Galera Cluster에서는 각 노드를 하나의 투표권으로 간주하고, 현재 활성화된 노드 수에 따라 정족수를 동적으로 계산합니다. Galera는 클러스터...

[MariaDB] Galera 클러스터 구축 8: 새로운 노드 추가 및 클러스터 확장

 이번 글에서는 기존에 구성된 Galera 클러스터(3노드)에 새로운 노드( mariadb4 )를 추가하는 과정을 단계별로 설명합니다. 이 과정을 통해 클러스터의 가용성과 확장성을 높일 수 있으며, 실무 환경에서도 자주 활용되는 중요한 작업입니다. 1. 환경 정보 노드 이름 IP 주소 mariadb1 192.168.155.51 mariadb2 192.168.155.52 mariadb3 192.168.155.53 mariadb4 192.168.155.54 2. 신규 노드 초기 설정 (mariadb4) IP설정 및 hostname 설정 # hostnamectl set-hostname mariadb4 # nmcli connection modify enp1s0 ipv4.addresses 192.168.155.54/24 ipv4.gateway 192.168.155.1 ipv4.dns 8.8.8.8 autoconnect on ipv4.method manual 방화벽 설정 새로운 노드에서 Galera 클러스터 통신을 위한 포트를 열어줍니다. # firewall-cmd --add-port=3306/tcp --permanent # MySQL/MariaDB 포트 # firewall-cmd --add-port=4567/tcp --permanent # Galera 복제 트래픽 # firewall-cmd --add-port=4567/udp --permanent # Galera 복제 트래픽 (UDP) # firewall-cmd --add-port=4568/tcp --permanent # IST (Incremental State Transfer) # firewall-cmd --add-port=4444/tcp --permanent # SST (State Snapshot Transfer) # firewall-cmd --reload 호스트 파일 설정 모든 노드(기존 노드 포함)에서 새로운 노드의 호스트 정...

[MariaDB] Galera 클러스터 구축7: 전체 노드 정지 후 재시작과 부트스트랩 복구

 이번 글에서는 Galera Cluster의 모든 노드를 완전히 종료했다가 다시 시작하는 시나리오 와, 클러스터가 자동으로 복구되지 않을 때 필요한 수동 부트스트랩 복구 절차 를 설명합니다. 이 상황은 실제 운영 환경에서도 발생할 수 있기 때문에 정확한 이해와 절차 숙지가 필요합니다. 1. 정상적인 클러스터 재시작 1.1 클러스터 전체 노드 종료 테스트 환경에서는 세 개의 노드( mariadb1 , mariadb2 , mariadb3 )를 모두 종료합니다. # 각 노드에서 실행 $ sudo shutdown -h now 노드가 완전히 꺼졌는지 확인한 뒤 다음 단계로 진행합니다. 1.2 전체 노드 재시작 후 클러스터 상태 확인 모든 노드를 다시 기동한 후, 각 노드에서 MariaDB 서비스 상태와 클러스터 크기를 확인합니다. $ sudo systemctl status mariadb mysql> SHOW STATUS LIKE 'wsrep_cluster_size'; -- 예상 결과: 3 대부분의 경우 클러스터는 자동으로 복구되며, 이전과 동일한 구성으로 재합류합니다. 데이터베이스 상태도 유지되어야 합니다. mysql> SELECT * FROM products; 2. 비정상 종료 후 수동 부트스트랩 복구 2.1 비정상 종료 상황 만들기 (테스트 환경) 실제 운영 환경에서는 전원 장애, 시스템 크래시, 강제 재부팅 등으로 인해 클러스터가 비정상 종료될 수 있습니다. 테스트 환경에서 이 상황을 재현하려면 VMware, VirtualBox 같은 가상머신 환경에서 Power Off 기능을 사용하여 세 개 노드를 모두 강제로 종료할 수 있습니다. VMware vSphere Client / VMware Workstation 1. 각 VM을 선택 2. "Power" → "Power Off" (graceful shutdown이 아닌 강제 종료) 3. 모든 노드에 대해 반복 이렇게 강제 종료하면 ...

[MariaDB] Galera 클러스터 구축6: 노드 강제 종료 시 복제와 Quorum 동작 이해

 MariaDB Galera 클러스터를 운영하다 보면 노드 장애는 피할 수 없는 상황입니다. 정상적인 종료와 갑작스러운 전원 차단, 두 상황에서 클러스터가 어떻게 반응하는지 궁금하지 않으신가요? 이전 포스팅에서는 노드를 정상적으로 종료했을 때의 복제 과정을 다뤘습니다. 이번에는 예기치 못한 노드 장애 상황 에서 Galera 클러스터가 어떻게 동작하는지, 그리고 핵심 개념인 Quorum 이 무엇인지 실제 테스트를 통해 알아보겠습니다. 실습 환경 준비 테스트를 위한 환경 구성은 다음과 같습니다: 클러스터 구성 : 3개 노드 ( mariadb1 , mariadb2 , mariadb3 ) 테스트 테이블 : inventory.products 시나리오 : 노드 강제 종료 → Quorum 상실 → 복구 과정 1단계: 클러스터 상태 점검 먼저 모든 노드가 정상적으로 클러스터에 참여하고 있는지 확인해보겠습니다. mysql> SHOW STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 좋습니다! 3개 노드가 모두 정상 상태네요. 이제 테스트용 데이터를 하나 추가해보겠습니다. mysql> INSERT INTO products VALUES (7, 'Desk Lamp', 15); Query OK, 1 row affected (0.01 sec) 다른 노드들에서도 데이터가 정상적으로 복제되었는지 확인해보세요. 모든 노드에서 동일한 데이터를 조회할 수 있을 것입니다. 2단계: 첫 번째 노드 강제 종료 테스트 이제 본격적인 테스트를 시작해보겠습니다. mariadb1 노드를 정상적인 shutdown 명령어가 아닌 강제 전원 차단 방식으로 종...

[MariaDB] Galera 클러스터 구축5: 노드 중지와 재시작 시 데이터 복제 동작 확인

  Galera Cluster의 가장 강력한 기능 중 하나는 노드가 재시작되거나 일시적으로 오프라인이 되더라도 데이터 일관성을 유지하는 동기 복제 구조 입니다. 이번 글에서는 일부 노드를 정상적으로 종료(shutdown)한 후, 재시작했을 때 데이터가 정상 복제되는지 확인하는 과정을 실습을 통해 검증해보겠습니다. 클러스터 상태 확인 먼저 현재 클러스터가 정상적으로 3개 노드로 구성되어 있는지 확인합니다. mysql> SHOW STATUS LIKE 'wsrep_cluster_size'; +--------------------+-------+ | Variable_name | Value | +--------------------+-------+ | wsrep_cluster_size | 3 | +--------------------+-------+ 클러스터 크기가 3이면 모든 노드가 정상 참여 중입니다. 테스트 데이터 준비 테스트를 위해 inventory 데이터베이스의 products 테이블에 몇 개의 데이터를 미리 삽입해둡니다. mysql> USE inventory; mysql> SELECT * FROM products; +------------+--------------+----------+ | product_id | product_name | quantity | +------------+--------------+----------+ | 1 | Notebook | 50 | | 2 | Pen | 100 | | 3 | Monitor | 30 | +------------+--------------+----------+ 여기에 새 데이터를 추가합니다: mysql> INSERT INTO products VALUES (4, 'Keyboard', 20); 모든 노드에서 SEL...

[MariaDB] Galera 클러스터 구축4: 복제 테스트 및 데이터 동기화 확인

 Galera Cluster의 가장 중요한 특징 중 하나는 각 노드 간의 실시간 데이터 복제입니다. 이번 글에서는 이를 직접 테스트해보는 과정을 소개합니다. 새롭게 구성한 예제를 기반으로 데이터베이스를 생성하고, 테이블을 만들고, 각 노드에 데이터를 삽입하여 복제가 제대로 이루어지는지 확인해보겠습니다. 테스트 시나리오 데이터베이스 이름: inventory 테이블 이름: products 테이블 구성: 제품 ID, 제품명, 수량 엔진: InnoDB (Galera는 InnoDB만 지원) Galera Cluster 노드: mariadb1, mariadb2, mariadb3 1. 데이터베이스 생성 $ mysql -u root -p Enter password: ****** -- 데이터베이스 생성 mysql> CREATE DATABASE inventory; -- 확인 mysql> SHOW DATABASES; 생성된 inventory 데이터베이스는 Galera의 복제를 통해 나머지 노드에도 자동으로 생성됩니다 . mariadb2와 mariadb3에서도 동일하게 확인합니다. 2. 테이블 생성 이제 inventory 데이터베이스에 products 테이블을 생성합니다. mysql> USE inventory; mysql> CREATE TABLE products ( product_id INT PRIMARY KEY, product_name VARCHAR(100), quantity INT ) ENGINE=InnoDB; mysql> SHOW TABLES; 각 노드에서 SHOW TABLES 를 실행하면 동일한 테이블이 존재함을 확인할 수 있습니다. 3. 데이터 삽입 및 복제 확인 세 노드 각각에서 서로 다른 데이터를 삽입해보고, 복제가 잘 되는지 확인해보겠습니다. -- mariadb1에서 실행 mysql> INSERT INTO products VALUES (1, 'Notebook',...