우분투에 MongoDB 설치하는 방법

소개

MongoDB는 가장 인기 있는 오픈 소스 NoSQL 데이터베이스 중 하나로, 유연한 데이터 구조, 높은 확장성, 빠른 성능을 요구하는 애플리케이션에서 널리 사용됩니다. JSON과 유사한 객체를 사용하여 문서 지향 형식으로 데이터를 저장하므로 현대적인 웹, 모바일, 분석 작업에 이상적입니다. 개발자들은 동적 스키마, 자동 샤딩, 수평 확장과 고가용성을 지원하는 내장 복제 기능 덕분에 MongoDB를 선호합니다. Ubuntu의 안정성과 보안을 결합하면 MongoDB는 신뢰할 수 있고 효율적인 데이터베이스 기반 애플리케이션을 실행하기 위한 강력한 기반을 제공합니다.

이 기사에서는 Ubuntu 24.04 LTS에서 MongoDB 8.2를 설치, 구성 및 유지 관리하는 방법을 설명합니다. 서버 준비와 보안 기능 활성화부터 성능 최적화, 복제 및 백업 설정, 일반적인 문제 해결에 이르기까지 모든 필수 단계를 다룹니다. 이 가이드를 따르면 적절하게 보안이 설정되고 모니터링되며 장기 사용을 위해 최적화된 프로덕션용 MongoDB 배포 환경을 갖추게 됩니다. 개발, 테스트 또는 완전한 프로덕션 환경을 위해 MongoDB를 설정하든, 이 가이드는 효과적으로 운영할 수 있는 자세한 지침과 운영 모범 사례를 제공합니다.

전제 조건

이 튜토리얼을 따라하려면 다음이 필요합니다:

• Ubuntu 24.04 LTS를 실행하는 서버. 이 서버에는 관리자 권한을 가진 비루트 사용자가 있어야 하며 UFW(간단한 방화벽)가 설치되어 구성되어야 합니다. 이를 설정하려면 Ubuntu 초기 서버 설정 가이드를 참조하십시오.

공식 저장소에서 MongoDB 설치하기

Ubuntu 24.04에는 기본 패키지 저장소에 MongoDB 버전이 포함되어 있지만, 보통은 오래된 버전입니다. 운영 환경에서는 항상 공식 MongoDB 저장소에서 직접 MongoDB를 설치하는 것이 좋습니다. 이렇게 하면 최신 안정 버전(작성 시점 기준 8.2)과 적시에 제공되는 보안 및 유지 관리 업데이트를 받을 수 있습니다.

MongoDB 저장소를 시스템의 APT 소스에 추가하고, 패키지를 검증하는 데 사용되는 GPG 키를 가져온 다음, 데이터베이스를 설치합시다.

1. MongoDB GPG 키를 가져옵니다

APT는 패키지의 진위 여부를 확인하기 위해 GPG 키를 사용합니다. 이것이 없으면 시스템이 MongoDB 저장소를 신뢰하지 않습니다.

MongoDB 8.0용 공개 키를 가져오려면 다음 명령어를 실행하세요:

curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc | sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

이것이 하는 일은 다음과 같습니다:

• curl -fsSL 은 MongoDB 공식 서버에서 GPG 키를 조용히 가져옵니다.
• `--dearmor`는 키를 ASCII-armor 형식에서 APT와 호환되는 바이너리 키링 형식으로 변환합니다.
• 출력은 신뢰할 수 있는 키의 표준 위치인 /usr/share/keyrings/mongodb-server-8.0.gpg에 저장됩니다.

명령이 오류 없이 완료되면 키가 성공적으로 추가된 것입니다.

2. MongoDB 저장소 추가

다음으로, Ubuntu 24.04(“Noble”)용 MongoDB 공식 패키지 소스를 가리키는 새 저장소 목록 파일을 만듭니다.

echo "deb [ arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg ] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.2 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-8.2.list

이 명령어의 각 부분은 명확한 목적을 가지고 있습니다:

• deb는 APT에 이것이 바이너리 패키지 저장소임을 알려줍니다(소스 코드를 위한 deb-src와는 반대).
• `arch=amd64,arm64`는 MongoDB에서 지원하는 64비트 Intel/AMD 및 ARM 아키텍처로 제한합니다.
• signed-by=...는 APT가 다운로드를 확인할 때 위에서 추가한 특정 MongoDB 키를 사용하도록 보장합니다.
• https://repo.mongodb.org/apt/ubuntu 는 MongoDB 공식 APT 저장소의 기본 URL입니다.
• noble/mongodb-org/8.2는 우분투 릴리스 코드명(noble=Ubuntu 24.04)과 MongoDB 버전(8.2)을 모두 지정합니다.
• multiverse는 서드파티 소프트웨어를 위한 우분투 컴포넌트 섹션입니다.

3. 패키지 인덱스 업데이트

새 저장소를 추가한 후에는 APT가 새 소스를 인식하도록 시스템의 로컬 사용 가능한 패키지 목록을 새로 고쳐야 합니다:

sudo apt update

APT는 최신 패키지 목록을 다운로드하고 GPG 키를 사용하여 이를 검증합니다. 저장소 목록에서 MongoDB가 표시되면 구성이 올바른 것입니다.

4. MongoDB 설치

이제 MongoDB와 관련 도구들을 설치하세요:

sudo apt install -y mongodb-org

-y 플래그는 설치 확인 메시지를 자동으로 승인합니다.

이 명령은 다음을 포함한 관련 패키지 세트를 설치합니다:

• mongodb-org-server: 데이터베이스 저장 및 작업을 담당하는 MongoDB 서버 데몬(mongod).
• mongodb-org-mongos: 분산 배포에서 사용되는 샤딩 라우터입니다.
• mongodb-org-shell: MongoDB에 연결하는 데 사용되는 대화형 명령줄 클라이언트(mongosh).
• mongodb-org-tools: 백업 및 복원 유틸리티(mongodump, mongorestore, bsondump 등).

설치가 완료되면 실행 파일은 /usr/bin/ 아래에 위치하고, 설정 파일은 /etc/mongod.conf에 위치합니다.

5. 설치 확인

MongoDB 8.2가 성공적으로 설치되었는지 확인하려면 버전을 확인하면 됩니다:

mongod --version

다음과 유사한 출력이 표시될 것입니다:

db version v8.2.3
Build Info: {
    "version": "8.2.3",
    "gitVersion": "36f41c9c30a2f13f834d033ba03c3463c891fb01",
    "openSSLVersion": "OpenSSL 3.0.13 30 Jan 2024",
    "modules": [],
    "allocator": "tcmalloc-google",
    "environment": {
        "distmod": "ubuntu2404",
        "distarch": "x86_64",
        "target_arch": "x86_64"
    }
}

이 메시지가 보인다면 MongoDB가 올바르게 설치되었으며 서비스로 시작할 준비가 된 것입니다.

MongoDB 서비스 시작 및 관리

Ubuntu에 MongoDB를 설치하면 패키지에 systemd 서비스 유닛인 mongod.service가 자동으로 포함됩니다. 이 통합 덕분에 MongoDB는 Nginx, PostgreSQL 또는 다른 주요 데몬과 마찬가지로 Ubuntu의 표준 서비스 관리 명령어를 사용하여 깔끔하게 시작, 중지 및 재시작할 수 있습니다.

MongoDB 서비스를 시작하세요

기본적으로 MongoDB는 설치 후 자동으로 시작되지 않습니다. 수동으로 실행하려면 다음 명령어를 사용하세요:

sudo systemctl start mongod

명령이 오류 없이 실행되면 서비스가 이제 활성화됩니다. 다음 명령으로 확인할 수 있습니다:

sudo systemctl status mongod

예시 출력:

● mongod.service - MongoDB Database Server
     Loaded: loaded (/usr/lib/systemd/system/mongod.service; disabled; preset: enabled)
     Active: active (running) since Tue 2026-01-06 07:08:28 UTC; 5s ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 12462 (mongod)
     Memory: 195.4M (peak: 277.1M)
        CPU: 739ms
     CGroup: /system.slice/mongod.service
             └─12462 /usr/bin/mongod --config /etc/mongod.conf

라인 “Active: active (running)”은 데이터베이스가 실행 중이며 정상적으로 작동하고 있음을 확인해 줍니다.

대신 “failed” 또는 “inactive”가 표시되면, 문제를 해결하기 위해 MongoDB 로그 확인 섹션으로 건너뛰세요.

부팅 시 MongoDB 자동 시작 설정

대부분의 생산 시스템에서는 재부팅 후 데이터베이스가 자동으로 시작되어야 합니다. MongoDB가 부팅 시 실행되도록 하려면 다음을 실행하세요:

sudo systemctl enable mongod

이 명령은 /etc/systemd/system/multi-user.target.wants/에 심볼릭 링크를 생성하며, 시스템이 멀티유저 모드(서버의 일반 운영 모드)로 진입할 때마다 systemd가 서비스를 자동으로 시작하도록 지시합니다.

변경 사항을 다음으로 확인할 수 있습니다:

systemctl is-enabled mongod

예상 출력:

enabled

자동 시작을 비활성화하려면(유지보수나 테스트를 위해) 다음을 사용하세요:

sudo systemctl disable mongod

MongoDB 작업 확인

MongoDB가 실행 중이면 제대로 응답하는지 확인하는 것이 좋습니다.

다음 명령어를 실행하여 데이터베이스에 연결하고 연결 상태를 확인하세요:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

이 명령:

• 임시 셸 세션을 엽니다 (mongosh는 이전 mongo 클라이언트를 대체하는 새로운 MongoDB 셸입니다).
• 로컬 인스턴스에 대해 connectionStatus 명령을 직접 실행합니다.
• 쉘에 머물지 않고도 연결 결과를 표시합니다.

예시 출력:

{
  authInfo: { authenticatedUsers: [], authenticatedUserRoles: [] },
  uuid: UUID('be686f2a-9cb3-41c1-aad2-8849367de4e5'),
  ok: 1
}

"ok": 1 값은 서버가 정상적으로 작동하고 있으며 포트 27017에서 연결을 받고 있음을 확인합니다.

MongoDB 서비스 라이프사이클 관리

MongoDB가 실행 중인지 확인한 후에는 일상적인 운영에서 안전하게 관리하는 방법을 아는 것이 도움이 됩니다.

여기 주요 명령어들이 있습니다:

sudo systemctl stop mongod

sudo systemctl start mongod

sudo systemctl restart mongod

sudo systemctl reload mongod

sudo systemctl disable mongod

sudo systemctl status mongod

서비스(restart)를 재시작하는 것은 /etc/mongod.conf를 편집한 후에 특히 중요합니다. 이렇게 해야 변경한 설정이 적용됩니다.

MongoDB 로그 확인

MongoDB가 시작되지 않거나 예상치 못하게 작동하면, 첫 번째 문제 해결 단계로 로그를 확인해야 합니다.

MongoDB 로그는 다음 위치에 있습니다:

/var/log/mongodb/mongod.log

마지막 20줄을 보려면 다음을 사용하세요:

sudo tail -n 20 /var/log/mongodb/mongod.log

일반적인 로그 메시지에는 다음이 포함됩니다:

• "포트 27017에서 연결 대기 중": MongoDB가 성공적으로 시작되었고 준비가 완료되었습니다.
• "데이터 디렉토리 /var/lib/mongodb를 찾을 수 없습니다": 데이터 경로가 존재하는지 확인하고 올바른 권한이 설정되어 있는지 확인하세요.
• "주소 이미 사용 중": 다른 프로세스가 이미 포트 27017을 사용하고 있습니다.
• "권한 거부됨": MongoDB 사용자(mongodb)가 데이터 및 로그 디렉토리의 소유자임을 확인하세요.

systemd가 관리하는 서비스별 로그를 확인하려면 journalctl을 사용할 수도 있습니다:

sudo journalctl -u mongod --since "5 minutes ago"

시스템 시작 시 MongoDB 테스트

특히 애플리케이션을 배포하기 전에 MongoDB가 재부팅 후 자동으로 시작되는지 확인하는 것이 좋습니다.

재부팅하려면 다음을 실행하세요:

sudo reboot

서버가 재시작된 후, 다시 로그인하여 서비스를 확인하세요:

sudo systemctl status mongod

만약 “active (running)” 라고 표시되면, 구성 설정이 올바르고 지속적임을 의미합니다.

MongoDB 구성 설정 이해

MongoDB를 설치하면, 그 동작은 /etc/mongod.conf에 위치한 단일 구성 파일에 의해 제어됩니다.

이 파일은 MongoDB가 어떻게 실행되는지를 정의합니다: 데이터 저장 위치에서부터 활동 로그 기록 방식, 수신할 IP 주소, 활성화된 보안 메커니즘까지 모두 포함됩니다. 이 파일을 이해하는 것은 매우 중요하며, 특히 프로덕션 환경에서 MongoDB를 운영할 계획이라면 필수적입니다. 이 파일의 설정은 해당 명령줄 옵션과 동일하지만, 구성 파일을 사용하면 서버 관리가 더 간단해지며, 특히 대규모 또는 자동화된 배포에서는 더욱 유용합니다.

구성 파일 개요

MongoDB의 구성 파일은 들여쓰기에 민감한 YAML 구문을 사용합니다. 즉, 편집할 때 탭이 아닌 공백을 사용해야 하며, 공백 하나가 잘못되어도 구성에 문제가 발생할 수 있습니다.

다음 명령어로 파일의 현재 내용을 확인할 수 있습니다:

sudo cat /etc/mongod.conf

기본 파일은 대략 다음과 같이 생겼습니다:

# mongod.conf

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

이걸 부분별로 나눠서 살펴보자.

storage 섹션

이 섹션에서는 MongoDB가 데이터를 어디에 저장하는지와 데이터 내구성을 보장하는 저널링을 어떻게 관리하는지를 정의합니다.

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

• dbPath: 이것은 MongoDB가 데이터베이스, 컬렉션 및 인덱스를 저장하는 디렉터리입니다. 기본적으로 /var/lib/mongodb를 가리킵니다. 이 경로를 변경하는 경우, 해당 디렉터리가 존재하고 mongodb 사용자가 소유하고 있는지 확인하세요:

  sudo mkdir -p /data/mongodb
  
  sudo chown -R mongodb:mongodb /data/mongodb

• journal.enabled: true로 설정하면 MongoDB는 충돌이나 예기치 않은 종료 시 복구를 돕는 저널 파일을 유지합니다. 저널링은 데이터를 데이터 파일에 커밋하기 전에 별도의 로그에 변경 사항을 기록하여 손상을 방지합니다. 운영 시스템에서는 항상 이 기능을 활성화 상태로 유지하세요.

systemLog 섹션

이는 MongoDB가 로그를 어떻게 어디에 기록하는지를 제어합니다.

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

• destination: 로그가 기록될 위치를 지정합니다. 기본값 file은 로그를 파일에 작성하며, MongoDB 로그를 시스템 로그와 통합하려면 syslog로 변경할 수 있습니다.
• logAppend: true일 때 MongoDB는 재시작 시 기존 파일을 덮어쓰는 대신 새로운 로그 항목을 기존 파일에 추가합니다.
• path: 로그 파일의 절대 경로.

다음과 같이 로그를 직접 확인할 수 있습니다:

sudo tail -f /var/log/mongodb/mongod.log

로그가 너무 커지면 logrotate와 같은 도구로 로그 순환을 활성화하거나 시스템 로그가 자동으로 순환되도록 설정하는 것을 고려하세요.

net 섹션

이 섹션에서는 MongoDB가 들어오는 네트워크 연결을 수신하는 방식을 정의합니다.

net:
  port: 27017
  bindIp: 127.0.0.1

• port: 기본 MongoDB 포트는 27017입니다. 동일한 호스트에서 여러 데이터베이스 서비스를 실행하는 경우 이 포트를 변경할 수 있습니다.
• bindIp: 이것은 MongoDB가 어떤 네트워크 인터페이스에서 수신할지 제어합니다.

기본적으로 127.0.0.1 (로컬 루프백 주소)로 제한되어 있어, 로컬 연결만 허용됩니다. 이는 원격 접근을 명시적으로 허용할 때까지 차단하는 중요한 보안 기본 설정입니다.

다른 기기(예: 웹 서버나 원격 애플리케이션)에서 연결할 계획이라면, 다음과 같이 수정할 수 있습니다:

bindIp: 127.0.0.1,192.168.1.100

또는 모든 인터페이스에서 수신하려면(운영 환경에서는 주의해서 사용):

bindIp: 0.0.0.0

보안 섹션

MongoDB는 기본적으로 인증이 비활성화된 상태로 설치됩니다. 데이터베이스에 연결할 수 있는 누구나 데이터를 읽거나 수정할 수 있습니다. 테스트할 때는 괜찮지만, 실제 시스템에는 보안 위협이 됩니다. 사용자 기반 인증을 활성화하려면 다음 섹션을 추가하십시오:

security:
  authorization: enabled

이 기능이 활성화되면 MongoDB는 작업을 수행하기 전에 사용자가 사용자 이름과 비밀번호로 인증하도록 요구합니다.

이 섹션의 기타 선택적 설정에는 다음이 포함됩니다:

• keyFile: 클러스터 노드 간 인증을 위해 레플리카 세트에서 사용됩니다.
• javascriptEnabled: 서버 측 자바스크립트 실행을 활성화하거나 비활성화합니다(필요하지 않는 한 비활성화 상태로 유지하는 것이 권장됩니다).

processManagement 섹션

이 섹션은 MongoDB가 프로세스 관리 및 런타임 정보를 처리하는 방식을 제어합니다.

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

이 정보는 주로 참고용이며, MongoDB가 타임스탬프 변환을 위해 시간대 데이터에 접근할 수 있도록 보장합니다. 고급 배포 환경에서는 MongoDB를 systemd 없이 수동으로 시작하는 경우, 여기에서 포킹(forking)을 활성화하여 백그라운드 작업을 수행할 수도 있습니다.

복제 및 샤딩 섹션 (선택 사항)

새로운 설치에서는 이러한 섹션을 볼 수 없지만, 다중 노드나 분산 설정에서는 사용됩니다.

레플리카 세트를 활성화하는 예시:

replication:
  replSetName: "rs0"

이는 MongoDB가 rs0라는 이름의 레플리카 세트의 일부로 시작하도록 지시합니다. 그런 다음 MongoDB 셸 내에서 초기화하고 멤버를 추가할 수 있습니다.

샤딩의 경우:

sharding:
  clusterRole: "shardsvr"

이는 샤딩된 클러스터에서 노드의 역할을 정의합니다.

setParameter 섹션

이 선택적 섹션에서는 MongoDB의 동작을 세밀하게 조정하는 런타임 매개변수를 재정의할 수 있습니다.

예시 :

setParameter:
  enableLocalhostAuthBypass: false

이를 false로 설정하면 로컬호스트 연결조차도 인증이 필요하게 됩니다. 다른 매개변수들은 쿼리 시간 초과, 커서 동작 또는 진단 로깅을 제어할 수 있습니다.

변경 사항 만들기 및 적용

/etc/mongod.conf를 수정할 때마다 변경 사항이 적용되도록 MongoDB를 재시작해야 합니다:

sudo systemctl restart mongod

그런 다음 서비스가 실행 중인지 확인합니다:

sudo systemctl status mongod

MongoDB가 다시 시작되지 않으면 구문 오류(YAML 들여쓰기 실수가 흔함)를 확인하거나 로그를 검토하세요:

sudo tail -n 20 /var/log/mongodb/mongod.log

예시: 안전하고 프로덕션 준비가 된 구성

다음은 Ubuntu 24.04용으로 깔끔하고 운영 환경에 적합한 mongod.conf 예시입니다:

# mongod.conf — Example production configuration

storage:
  dbPath: /data/mongodb
  journal:
    enabled: true
  engine: wiredTiger

systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.10

security:
  authorization: enabled
  javascriptEnabled: false

processManagement:
  timeZoneInfo: /usr/share/zoneinfo

replication:
  replSetName: "rs0"

setParameter:
  enableLocalhostAuthBypass: false

이 구성:

• 인증을 가능하게 합니다
• WiredTiger(기본 스토리지 엔진)를 사용합니다
• 특정 신뢰할 수 있는 인터페이스에만 연결됨
• 인스턴스를 복제 세트 초기화를 위해 준비합니다
• 모든 작업을 전용 로그 파일에 기록합니다

MongoDB 보안

MongoDB의 유연성은 강력하지만, 동시에 보안이 취약한 설정은 데이터 노출로 쉽게 이어질 수 있습니다. MongoDB 초기에는 많은 서버가 인증 없이 인터넷에 노출되어 있었고, 공격자는 단순히 포트 27017에 연결하는 것만으로 데이터베이스를 조회, 수정, 심지어 삭제할 수 있었습니다.

오늘날, MongoDB는 더 안전한 기본 설정과 함께 제공되지만, 인증, 네트워크 제한 및 암호화를 적용하는 것은 여전히 사용자에게 달려 있습니다.

인증 활성화

기본적으로 MongoDB는 인증이 비활성화된 상태로 시작됩니다. 이는 데이터베이스에 연결할 수 있는 누구나 제한 없이 관리 명령을 실행하거나 컬렉션을 삭제하거나 데이터를 수정할 수 있다는 것을 의미합니다. 이를 방지하기 위해 MongoDB는 명시적으로 활성화해야 하는 역할 기반 접근 제어(RBAC) 시스템을 사용합니다.

1. MongoDB 구성 파일을 엽니다:

   sudo nano /etc/mongod.conf

2. security 섹션을 찾거나, 존재하지 않는 경우 새로 만드세요:

   security:
     authorization: enabled

3. 저장하고 종료하기 (Ctrl+O 누른 후 Ctrl+X 누르기).

4. 변경 사항을 적용하려면 MongoDB를 재시작하세요:

   sudo systemctl restart mongod

MongoDB는 새로 배포된 환경에서 첫 번째 관리 사용자를 생성할 수 있도록 임시 로컬호스트 인증 우회를 제공합니다. 관리자가 존재하거나 특정 보안 설정(예: keyFile 또는 clusterAuthMode)이 활성화되면 이 우회는 자동으로 비활성화됩니다.

즉, 완전 실행이 시작되기 전에 안전하게 첫 번째 관리자 사용자를 만들 수 있다는 뜻입니다.

첫 번째 관리자 사용자 생성

관리자 사용자는 MongoDB 인증 시스템의 기반입니다. 이 사용자는 다른 사용자를 생성하고, 역할을 정의하며, 특정 데이터베이스에 대한 접근 권한을 부여할 수 있는 권한을 가지고 있습니다.

이 계정을 만들려면:

1. 로컬 MongoDB 셸을 시작하세요:

   mongosh

2. admin 데이터베이스로 전환하세요. 이 데이터베이스에는 사용자 자격 증명과 역할 정의가 저장되어 있습니다:

   use admin

3. 다음 명령어를 사용하여 사용자를 생성하세요:

   db.createUser({
     user: "admin",
     pwd: "StrongPasswordHere",
     roles: [
       { role: "userAdminAnyDatabase", db: "admin" },
       "readWriteAnyDatabase"
     ]
   })

   이것을 나눠서 살펴봅시다:

   • userAdminAnyDatabase는 이 사용자가 모든 데이터베이스에서 사용자를 생성, 수정 및 삭제할 수 있도록 허용합니다.
   • readWriteAnyDatabase는 전역적으로 읽기 및 쓰기 권한을 제공합니다. (원하면 더 엄격한 관리자 전용 사용자에 대해서는 생략할 수 있습니다.)

   이 명령은 MongoDB의 admin 데이터베이스 내 system.users 컬렉션에 새 문서를 작성합니다. 이후 사용자를 나열하여 이를 확인할 수 있습니다:

   show users

4. 셸 종료:

   exit

5. 관리자 사용자로 다시 연결하여 인증이 이제 적용되었는지 확인합니다:

   mongosh -u admin -p --authenticationDatabase admin

인증이 완료되면 다음과 같은 관리 명령어를 실행할 수 있습니다:

show dbs

MongoDB가 비밀번호를 요구하고 인증 후에만 접근을 허용한다면, RBAC가 정상적으로 작동하는 것입니다.

애플리케이션용 역할 기반 사용자 생성

운영 환경에서는 애플리케이션이 관리자 계정을 절대 사용해서는 안 됩니다. 대신, 각 애플리케이션마다 필요한 권한만 가진 전용 사용자를 생성해야 합니다.

예를 들어, 특정 데이터베이스의 데이터를 관리하는 웹 애플리케이션용 사용자를 생성하려면:

use myappdb
db.createUser({
  user: "appuser",
  pwd: "AppPassword123",
  roles: [ { role: "readWrite", db: "myappdb" } ]
})

• readWrite 권한은 애플리케이션이 이 데이터베이스에서만 모든 표준 CRUD 작업(삽입, 조회, 업데이트, 삭제)을 수행할 수 있도록 허용합니다.
• 다른 사용자를 생성하거나 시스템 컬렉션을 수정하거나 다른 데이터베이스에 접근할 수 없습니다.

다음 명령어로 데이터베이스의 모든 사용자를 나열할 수 있습니다:

show users

네트워크 접근 제한

인증이 활성화되어 있어도 MongoDB를 공개 인터넷에 노출하는 것은 위험합니다. 자동 스캐너는 정기적으로 열려 있는 포트(특히 기본 MongoDB 포트인 27017)를 찾고, 브루트포스 공격을 시도하거나 잘못 구성된 인스턴스를 악용합니다.

기본적으로 MongoDB는 로컬 인터페이스인 127.0.0.1에서만 수신합니다. 애플리케이션과 MongoDB 서버가 동일한 호스트에 있다면 아무것도 변경할 필요가 없습니다. 그러나 애플리케이션이 원격으로 연결하는 경우에는 특정 IP 주소를 명시적으로 허용 목록에 추가해야 합니다.

1. 구성 파일을 편집하세요:

   sudo nano /etc/mongod.conf

2. net 섹션을 찾아 업데이트하세요:

   net:
     port: 27017
     bindIp: 127.0.0.1,192.168.10.50

   신뢰할 수 있는 애플리케이션 서버의 IP 주소로 192.168.10.50를 교체하세요. 이렇게 하면 MongoDB가 로컬호스트와 해당 특정 원격 호스트에서만 연결을 허용하도록 설정됩니다.

3. 변경 사항을 적용하려면 서비스를 다시 시작하세요:

   sudo systemctl restart mongod

4. 활성 바인딩을 확인하십시오:

   sudo ss -tulpn | grep mongod

MongoDB가 127.0.0.1:27017과 지정한 IP 모두에서 수신 중인지 확인해야 합니다.

우분투 방화벽(UFW) 설정하기

MongoDB가 특정 인터페이스에서만 수신하더라도 운영 체제 수준에서 네트워크 보안을 강화하는 것이 최선의 방법입니다.

우분투의 UFW는 들어오는 연결과 나가는 연결을 쉽게 제어할 수 있는 방법을 제공합니다.

1. UFW가 설치되어 있고 활성 상태인지 확인하세요:

   sudo ufw status

   비활성으로 표시되면 활성화하세요:

   sudo ufw enable

2. 신뢰할 수 있는 IP에서만 MongoDB 연결을 허용하세요. 예를 들어, 애플리케이션 서버의 IP가 192.168.10.50인 경우:

   sudo ufw allow from 192.168.10.50 to any port 27017

3. 규칙이 추가되었는지 확인하세요:

   sudo ufw status numbered

   지정된 소스에서 포트 27017을 허용하는 항목을 확인해야 합니다.

4. 선택적으로, MongoDB에 대한 다른 모든 트래픽을 명시적으로 차단합니다:

   sudo ufw deny 27017/tcp

MongoDB 설정에서 bindIp와 선택적인 UFW 규칙의 이 조합은 다른 프로세스가 데이터베이스를 노출하려 해도 알려진 시스템만 데이터베이스에 접근할 수 있도록 보장합니다.

TLS/SSL 암호화 활성화

지금까지는 신뢰할 수 있는 사용자와 IP만 MongoDB에 접근할 수 있도록 하셨습니다. 다음 단계는 전송 중인 데이터를 보호하는 것입니다.

클라이언트가 MongoDB에 연결할 때, 모든 데이터(인증 자격 증명과 쿼리를 포함하여)는 기본적으로 평문으로 전송됩니다. TLS는 이 데이터를 암호화하여 도청이나 변조를 방지합니다.

인증서 생성 또는 획득

운영 환경에서는 신뢰할 수 있는 인증 기관(CA)의 인증서를 사용하세요. 테스트 또는 내부 배포용으로는 자체 서명 인증서를 생성할 수 있습니다:

sudo mkdir -p /etc/ssl/mongodb

sudo openssl req -newkey rsa:4096 -new -x509 -days 365 -nodes -out /etc/ssl/mongodb/mongodb.crt -keyout /etc/ssl/mongodb/mongodb.key -subj "/CN=$(hostname)"

이렇게 생성됩니다:

• mongodb.crt: 공개 인증서
• mongodb.key: 개인 키

MongoDB에서 요구하는 하나의 PEM 파일로 결합하세요:

sudo cat /etc/ssl/mongodb/mongodb.key /etc/ssl/mongodb/mongodb.crt | sudo tee /etc/ssl/mongodb/mongodb.pem

sudo chmod 600 /etc/ssl/mongodb/mongodb.pem

sudo chown mongodb:mongodb /etc/ssl/mongodb/mongodb.pem

이 권한은 mongodb 사용자만 키 파일에 접근할 수 있도록 보장합니다.

구성 파일 업데이트

/etc/mongod.conf 파일을 편집하고 net 섹션을 찾으세요. 그 아래에 새로운 tls 블록을 추가하세요:

net:
  port: 27017
  bindIp: 127.0.0.1,192.168.10.50
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb/mongodb.pem

• mode: requireTLS는 MongoDB가 암호화되지 않은 연결을 거부한다는 의미입니다.
• certificateKeyFile는 결합된 PEM 파일 경로를 지정합니다.

변경 사항을 적용하려면 MongoDB를 재시작하세요:

sudo systemctl restart mongod

TLS를 사용하여 연결

mongosh에 연결할 때 이제 --tls 옵션을 지정해야 합니다:

mongosh --tls --host 192.168.10.50 -u admin -p --authenticationDatabase admin

연결이 성공하고 프롬프트가 나타나면, TLS 설정이 제대로 작동하고 있는 것입니다.

OpenSSL을 사용하여 연결을 검사함으로써 암호화를 확인할 수 있습니다:

openssl s_client -connect 192.168.10.50:27017

출력에는 예를 들어 인증서 체인과 암호화 세부 정보가 표시되어야 합니다.

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

이로써 귀하의 MongoDB 서버가 이제 트래픽을 종단 간 암호화하고 있음을 확인할 수 있습니다.

보안 상태 검증

모든 설정이 완료되면 설치 상태를 다시 한 번 확인하는 것이 좋습니다.

1. MongoDB가 허용된 IP에만 바인딩되었는지 확인하세요:

   sudo ss -tulpn | grep mongod

   연결은 127.0.0.1 및 신뢰할 수 있는 IP로만 제한해야 합니다.

2. 인증이 적용되었는지 확인하세요. 자격 증명 없이 연결을 시도해 보세요:

   mongosh

   인증 오류가 발생할 것입니다.

3. TLS가 필수인지 확인하세요. --tls 없이 연결을 시도합니다:

   mongosh --host 192.168.10.50 -u admin -p --authenticationDatabase admin

   연결이 TLS 요구 사항에 대한 메시지와 함께 실패하면 암호화가 올바르게 적용된 것입니다.

4. MongoDB의 내부 보안 매개변수를 검토하십시오:

   mongosh -u admin -p --authenticationDatabase admin --eval "db.runCommand({ getParameter: 1, tlsMode: 1 })"

   만약 tlsMode가 "requireTLS"를 반환하면, 암호화가 활성화된 것이 확인됩니다.

인증, 접근 제어, 네트워크 제한 및 TLS가 모두 설정되었으므로, 이제 MongoDB 인스턴스가 가장 흔한 공격 벡터에 대해 강화되었습니다.

운영 모범 사례

MongoDB를 설치하고 보안을 설정한 후 다음으로 중요한 우선순위는 이를 효과적으로 유지 관리하는 것입니다. 가장 신중하게 구성된 데이터베이스라도 정기적인 유지 관리가 없으면 신뢰성을 잃을 수 있습니다. 백업, 모니터링, 시스템 업데이트와 같은 일상적인 운영 작업은 MongoDB가 시간이 지나도 성능이 우수하고 안정적이며 복구 가능하도록 보장합니다.

MongoDB 데이터 백업

잘 계획된 백업 전략은 모든 운영 데이터베이스에 있어 기본입니다. 백업을 통해 하드웨어 오류, 소프트웨어 버그 또는 실수로 인한 삭제에서 빠르게 복구할 수 있습니다. MongoDB는 각각 다른 시나리오에 적합한 논리적 및 물리적 백업을 모두 지원합니다.

mongodump을 사용한 논리적 백업

논리적 백업은 mongodump 유틸리티를 사용하여 데이터베이스 내용을 BSON 형식으로 캡처합니다. 이 방법은 이동 가능하고, 사람이 읽을 수 있으며, 자동화하기 쉽습니다.

모든 데이터베이스의 전체 백업을 만들려면 다음을 실행하세요:

mongodump --out /backups/mongodb/$(date +%F)

이 명령은 /backups/mongodb/ 아래에 현재 날짜로 된 디렉토리를 생성하고 모든 BSON 덤프를 그 안에 저장합니다.

인증이 활성화된 경우, 자격 증명이 포함된 URI 연결 문자열을 사용하세요:

mongodump --uri="mongodb://admin:YourPassword@localhost:27017/admin" --out /backups/mongodb/$(date +%F)

특정 데이터베이스를 백업할 수도 있습니다:

mongodump --db=myappdb --out /backups/mongodb/$(date +%F)

논리 백업에서 복원하려면 mongorestore를 사용하십시오:

mongorestore /backups/mongodb/2026-01-05/

또는 단일 데이터베이스를 복원합니다:

mongorestore --db=myappdb /backups/mongodb/2026-01-05/myappdb

논리적 백업은 유연하고 스크립트 작성이 쉽지만, 매우 큰 데이터셋의 경우 완료하는 데 시간이 더 걸릴 수 있습니다.

물리적 백업(파일 시스템 스냅샷)

물리적 백업은 스토리지 볼륨에서 직접 데이터베이스 파일을 캡처합니다. 이 방법은 대규모 데이터베이스에 대해 더 빠르고 공간 효율적이지만, 손상을 피하기 위해 일관된 스냅샷이 필요합니다.

저널링(기본적으로 활성화됨)을 사용하는 경우 MongoDB가 실행 중일 때도 볼륨 스냅샷을 찍을 수 있습니다. WiredTiger는 저널링이 활성화되어 있는 한 MongoDB가 실행 중일 때도 충돌 일관성 스냅샷을 지원합니다. 전체 애플리케이션 일관성 스냅샷의 경우 MongoDB를 중지하는 것이 권장되지만 필수는 아닙니다.

sudo systemctl stop mongod

클라우드 제공업체나 스토리지 시스템을 사용하여 스냅샷을 찍고 서비스를 재시작하세요:

sudo systemctl start mongod

가능할 때마다 스냅샷을 오프사이트나 다른 지역에 저장하세요. 이렇게 하면 데이터 센터 장애나 실수로 인한 로컬 삭제로부터 보호할 수 있습니다.

MongoDB 상태 모니터링

모니터링은 문제가 사용자에게 영향을 미치기 전에 예방하는 데 매우 중요합니다. MongoDB는 내장 명령어 도구를 제공하며 외부 모니터링 시스템도 지원합니다.

내장 도구 사용

mongostat 도구는 초당 작업 수, 메모리 사용량, 활성 연결과 같은 실시간 데이터베이스 지표를 표시합니다. 다음과 같이 실행하세요:

mongostat --uri "mongodb://admin@localhost:27017/?authSource=admin"

이것은 삽입, 쿼리, 업데이트 및 삭제를 실시간으로 보여주는 테이블을 생성합니다. 각 열은 더티 메모리 페이지 비율이나 활성 연결 수와 같은 핵심 성과 지표를 나타냅니다.

mongotop 유틸리티는 MongoDB가 컬렉션별로 읽기 및 쓰기에 얼마나 많은 시간을 소비하는지에 중점을 둡니다. 2초마다 실행하려면 다음을 사용하세요:

mongotop 2

이는 많은 I/O가 발생하는 컬렉션을 식별하는 데 유용합니다.

외부 모니터링 도구 사용

지속적인 가시성과 알림을 위해 MongoDB를 다음과 같은 외부 시스템과 통합할 수 있습니다:

• MongoDB Atlas 모니터링, 자체 호스팅 클러스터에도 사용 가능.
• Prometheus와 Grafana를 사용하여 시계열 대시보드를 위해 MongoDB Exporter를 사용합니다.
• Percona 모니터링 및 관리(PMM), 완전한 오픈 소스 모니터링 스위트입니다.
• Netdata, Zabbix, 또는 Datadog과 같은 일반 시스템 도구.

모니터링해야 할 중요한 지표에는 다음이 포함됩니다:

• 메모리 사용량 및 캐시 적중률
• 디스크 입출력 지연 시간 및 처리량
• 연결 수 및 대기열 길이
• 작업 지연 시간(삽입, 업데이트, 조회 시간)
• 레플리카 지연(레플리카 세트를 실행하는 경우)

디스크 공간 및 저장소 증가 관리

MongoDB 데이터베이스는 문서와 인덱스가 증가함에 따라 동적으로 확장됩니다. 디스크 사용량을 관리하지 않으면 데이터베이스가 공간 부족으로 인해 잠기거나 충돌할 수 있습니다.

디스크 사용량 확인

다음 명령어로 현재 파일 시스템 사용량을 확인하세요:

df -h /var/lib/mongodb

이는 MongoDB 데이터 디렉토리의 사용 가능 공간과 사용 중인 공간을 표시합니다.

MongoDB 자체를 통해 메모리와 캐시 사용량도 확인할 수 있습니다:

mongosh --eval "db.serverStatus().wiredTiger.cache"

캐시에 현재 있는 바이트 값은 WiredTiger 스토리지 엔진이 사용하고 있는 RAM 양을 나타냅니다.

디스크 사용량 알림 설정

적극적으로 관리하려면 디스크 사용량이 85%를 초과할 때 알림을 보내거나 모니터링을 수행하도록 알림 또는 체크를 설정하세요. 예를 들어, 간단한 스크립트를 주기적으로 실행되도록 예약할 수 있습니다:

df -h | awk '$5 > 85 {print $0}'

이를 자동화를 위해 systemd 타이머나 모니터링 도구에 통합할 수 있습니다.

오래된 데이터 및 로그 관리

크거나 사용되지 않은 컬렉션과 로그 파일은 시간이 지나면서 상당한 공간을 차지할 수 있습니다. 로그를 관리하려면 /etc/logrotate.d/mongodb에서 회전을 구성하거나(이 섹션 뒤에서 설명) 수동으로 정리하세요:

sudo journalctl --vacuum-time=7d

sudo rm -f /var/log/mongodb/*.gz

애플리케이션 데이터를 위해, 임시 또는 시간에 민감한 데이터를 저장하는 컬렉션에는 TTL(시간 제한) 인덱스 사용을 고려하세요:

db.sessionLogs.createIndex({ "createdAt": 1 }, { expireAfterSeconds: 604800 })

이 기능은 7일 이상 된 문서를 자동으로 삭제합니다.

안전한 업그레이드 수행

MongoDB를 업그레이드하려면 특히 메이저 버전 간 이동 시 신중한 계획이 필요합니다. 다음 과정은 다운타임을 최소화하고 호환성을 보장합니다.

현재 버전 확인

설치된 버전을 확인하세요:

mongod --version

업그레이드 전에 백업하세요

업그레이드하기 전에 항상 전체 백업을 만드세요:

mongodump --out /backups/mongodb/pre-upgrade-$(date +%F)

패키지 저장소 업데이트 및 업그레이드

이전에 MongoDB 패키지가 자동으로 업데이트되지 않도록 고정을 설정했다면, 고정을 해제하세요:

echo "mongodb-org install" | sudo dpkg --set-selections

그런 다음 패키지 목록을 업데이트하고 MongoDB를 업그레이드하세요:

sudo apt update

sudo apt install -y mongodb-org

MongoDB는 업그레이드 중에도 구성 파일과 데이터 파일을 보존하지만, 백업을 하면 문제가 발생했을 때 되돌릴 수 있습니다.

업그레이드 확인

업그레이드 후:

1. 서비스 상태를 확인하세요:

   sudo systemctl status mongod

2. 최근 로그에서 경고나 마이그레이션 관련 메모를 확인하세요:

   sudo tail -n 30 /var/log/mongodb/mongod.log

3. 새 버전을 확인하세요:

   mongosh --eval "db.version()"

정기 유지보수 자동화

소규모 환경에서는 수동 유지 관리가 가능하지만, 자동화는 일관성을 보장합니다. cron이나 systemd timers를 사용하여 정기적인 백업, 로그 회전, 또는 모니터링 체크를 예약할 수 있습니다.

자동 백업 예약

루트 크론탭을 편집합니다:

sudo crontab -e

다음 줄을 추가하여 매일 새벽 2시에 MongoDB 인스턴스를 백업하세요:

0 2 * * * mongodump --out /backups/mongodb/$(date +\%F)

이것은 매일 날짜가 표시된 백업 폴더를 생성합니다.

로그 회전 구성

로그 파일이 디스크 공간을 차지하는 것을 방지하려면 로그 회전 설정 파일을 만드세요:

sudo nano /etc/logrotate.d/mongodb

다음 내용을 추가하세요:

/var/log/mongodb/mongod.log {
    weekly
    rotate 5
    compress
    delaycompress
    missingok
    notifempty
    create 640 mongodb adm
    postrotate
        systemctl reload mongod > /dev/null 2>&1 || true
    endscript
}

이 설정은 5주치 로그를 보관하고, 오래된 파일은 압축하며, 로그 순환 후 MongoDB를 다시 로드합니다.

정확한 시스템 시간 유지

MongoDB의 저널링 및 복제 기능은 정확한 타임스탬프에 의존합니다. 시스템 시계가 어긋나면 충돌 후 복제 지연이나 저널 손상이 발생할 수 있습니다.

Ubuntu 24.04는 기본적으로 systemd-timesyncd를 사용하지만, 더 정확한 시간 동기화를 위해 chrony를 사용할 수도 있습니다:

sudo apt install chrony -y

sudo systemctl enable --now chrony

다음을 통해 동기화를 확인할 수 있습니다:

timedatectl status

만약 NTP synchronized가 yes로 표시된다면, 시스템 시계가 동기화된 상태입니다.

실시간으로 MongoDB 상태 확인

MongoDB는 포괄적인 런타임 진단을 위해 serverStatus 명령을 제공합니다. 셸에서 직접 쿼리할 수 있습니다:

mongosh --eval "db.serverStatus()"

이것은 다음과 같은 지표를 포함하는 상세한 JSON 객체를 반환합니다:

• 메모리 사용량
• 캐시 사용
• 연결 수
• 작업 처리량
• 복제 상태

특정 필드를 추출하여 대상별 검사를 수행할 수 있습니다. 예를 들어, 연결 통계를 확인하려면:

mongosh --eval "db.serverStatus().connections"

이를 통해 시스템이 연결 포화 상태인지 또는 자원 제약 상태인지 빠르게 파악할 수 있습니다.

고가용성 준비

단일 노드 MongoDB 배포는 개발 용도나 중요도가 낮은 애플리케이션에 적합합니다. 운영 환경에서는 레플리카 세트를 구현해야 합니다. 레플리카 세트는 중복성과 자동 장애 조치를 제공하여 한 노드가 실패하더라도 가용성을 보장합니다.

일반적인 설정에서는:

• 하나의 노드는 기본(primary) 역할을 하며, 모든 쓰기 작업과 대부분의 읽기 작업을 처리합니다.
• 하나 이상의 보조 노드가 데이터를 실시간으로 복제합니다.
• 주(primary) 노드가 오프라인이 되면, 보조 노드 중 하나가 자동으로 새 주 노드가 됩니다.

레플리카 세트는 백업 및 확장과 같은 유지 관리 작업도 간소화합니다. 백업이나 분석 쿼리를 보조 노드로 오프로드하여 기본 노드 성능에 영향을 주지 않고 처리할 수 있습니다.

귀하의 MongoDB 인스턴스가 이제 완전히 운영 가능하며 적절하게 관리됩니다.

확장 및 성능 최적화

MongoDB는 수평적으로 확장되도록 설계되어, 더 강력한 단일 기계에만 의존하지 않고 서버를 추가함으로써 용량과 성능을 향상시킬 수 있습니다. 데이터셋이 커지거나 애플리케이션이 더 많은 동시 쿼리를 처리하기 시작하면, 확장은 MongoDB가 지속적으로 안정적이고 효율적으로 작동하도록 보장합니다.

MongoDB를 확장하는 기본적인 두 가지 방법이 있습니다:

1. 레플리카 세트는 중복을 통해 신뢰성과 읽기 성능을 향상시킵니다.
2. 샤딩은 더 큰 데이터 세트와 쓰기 부하를 처리하기 위해 데이터를 여러 서버에 분산시키는 것입니다.

레플리카 세트 이해하기

레플리카 세트는 데이터의 동일한 복사본을 유지하는 MongoDB 서버 그룹입니다. 레플리카 세트는 높은 가용성을 제공하고 하드웨어 또는 네트워크 장애로부터 보호합니다. 기본(primary) 노드가 실패하면, 보조(secondary) 노드 중 하나가 자동으로 역할을 맡아 최소한의 다운타임을 보장합니다.

표준 레플리카 세트는 다음으로 구성됩니다:

• 하나의 주요 노드가 모든 쓰기 작업을 처리합니다.
• 두 개 이상의 보조 노드가 기본 노드에서 데이터를 복제합니다.
• 선택적 중재자 노드로, 선거에는 참여하지만 데이터를 저장하지 않습니다.

프로덕션 시스템에서는 MongoDB가 레플리카 세트에 최소 세 개의 멤버를 두는 것을 권장합니다.

레플리카 세트 구성

레플리카 세트를 생성하려면 최소 두 개에서 세 개의 서버(물리적 또는 가상)가 필요합니다. 각 노드에는 MongoDB가 설치되어 있고 구성되어 있어야 합니다.

1. 각 노드에서 설정 파일 /etc/mongod.conf를 열고 복제 섹션을 추가하세요:

   replication:
     replSetName: "rs0"

2. 각 서버에서 MongoDB를 재시작합니다:

   sudo systemctl restart mongod

3. 주 노드에서 MongoDB에 연결하고 레플리카 세트를 초기화합니다:

   mongosh

   그런 다음 실행하세요:

   rs.initiate({
     _id: "rs0",
     members: [
       { _id: 0, host: "mongodb1.example.com:27017" },
       { _id: 1, host: "mongodb2.example.com:27017" },
       { _id: 2, host: "mongodb3.example.com:27017" }
     ]
   })

4. 상태를 확인하세요:

   rs.status()

   출력에는 하나의 프라이머리와 두 개의 세컨더리가 표시되어야 하며, 상태는 'PRIMARY' 및 'SECONDARY'로 표시되어야 합니다.

레플리카 세트의 장점

레플리카 세트는 여러 가지 중요한 장점을 제공합니다:

• 고가용성: 자동 장애 조치(failover)는 기본 노드가 오프라인이 될 경우에도 지속적인 작동을 보장합니다.
• 데이터 중복: 각 노드는 데이터의 전체 복사본을 유지합니다.
• 읽기 확장성: 보조 노드가 읽기 작업을 처리하여 기본 노드의 부하를 줄일 수 있습니다.
• 유지 관리 유연성: 가용성에 영향을 주지 않고 보조 노드에서 백업이나 시스템 업데이트를 수행할 수 있습니다.

샤딩 이해하기

샤딩은 MongoDB의 수평 확장 전략입니다. 데이터셋이 단일 서버에 저장하거나 효율적으로 처리하기에는 너무 커질 경우, MongoDB는 이를 여러 서버에 나눠 저장되는 샤드라고 불리는 작은 조각으로 분할할 수 있습니다.

각 샤드는 데이터의 일부를 보유하며, 클러스터는 전체적으로 하나의 논리적 데이터베이스처럼 동작합니다.

샤드 클러스터의 구성 요소

일반적인 MongoDB 샤드 클러스터에는 다음이 포함됩니다:

• 샤드: 데이터를 저장하는 노드로, 종종 중복성을 위해 레플리카 세트로 배치됩니다.
• 구성 서버: 청크 분포를 포함한 메타데이터와 클러스터 구성을 저장합니다.
• Mongos 라우터: 샤딩 키를 기반으로 클라이언트 쿼리를 올바른 샤드로 라우팅합니다.

샤드 키 선택

샤드 키는 MongoDB가 데이터를 샤드 간에 어떻게 분배할지를 결정합니다. 잘못 선택된 샤드 키는 데이터 불균형(데이터 스큐라고도 함)이나 핫스팟을 초래할 수 있습니다.

좋은 샤드 키는 일반적으로 다음과 같은 특징이 있습니다:

• 고유값이 많은(높은 기본값 수)
• 데이터 접근 패턴도 균일합니다.
• 대부분의 쿼리에 샤드 키가 포함된 예측 가능한 쿼리 패턴.

데이터베이스에서 샤딩을 활성화하는 예:

sh.enableSharding("salesdb")
sh.shardCollection("salesdb.orders", { "customer_id": 1 })

이 명령은 salesdb 데이터베이스에서 샤딩을 활성화하고 customer_id 필드를 사용하여 orders 컬렉션을 샤딩합니다.

샤딩을 사용해야 할 때

다음과 같은 경우에는 샤딩을 고려해야 합니다:

• 데이터베이스가 단일 서버의 저장 용량 한도에 근접하거나 이를 초과하고 있습니다.
• 쓰기 처리량이 지속적으로 CPU 또는 디스크 I/O를 최대치로 사용하고 있습니다.
• 작업 집합이 더 이상 RAM에 맞지 않아 자주 페이지 교체가 발생합니다.
• 데이터셋에서 기하급수적인 성장을 예상합니다.

샤딩은 아키텍처의 복잡성을 더하므로, 필요할 때만 도입하는 것이 가장 좋습니다.

성능을 위한 WiredTiger 튜닝

MongoDB는 기본적으로 WiredTiger 스토리지 엔진을 사용합니다. 이 엔진은 최신 하드웨어에 최적화되어 있으며, 압축, 캐싱, 다중 스레드 입출력을 사용합니다. WiredTiger가 메모리와 디스크 입출력을 관리하는 방식을 이해하면 성능 향상에 도움이 됩니다.

메모리 사용량

WiredTiger는 일반적으로 사용 가능한 RAM의 약 50%를 캐시로 사용하며, MongoDB는 시스템 메모리에 따라 이 값을 동적으로 조정합니다.

이 설정은 구성 파일에서 조정할 수 있습니다:

storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8

이 설정은 시스템이 MongoDB와 함께 다른 메모리 집약적인 서비스를 실행할 때 유용합니다. 전용 MongoDB 서버의 경우 기본 캐시 설정을 그대로 두는 것이 일반적으로 가장 좋습니다.

다음을 실행하여 현재 캐시 사용량을 확인할 수 있습니다:

mongosh --eval "db.serverStatus().wiredTiger.cache"

압축

WiredTiger는 디스크 사용량을 줄이기 위해 데이터 및 인덱스 압축을 지원합니다. 기본적으로 성능과 공간 효율성을 균형 있게 제공하는 Snappy 압축을 사용합니다. 속도보다 디스크 절약을 우선시하는 경우, zlib(더 나은 압축을 위해) 또는 zstd(최신 환경용)로 전환할 수 있습니다.

예제 구성:

storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd

일지 작성과 내구성

저널링은 전원 손실이 발생하더라도 쓰기 작업이 내구성을 가지도록 보장합니다. commitIntervalMs 매개변수를 조정하여 저널 쓰기가 발생하는 빈도를 제어할 수 있습니다:

storage:
  journal:
    commitIntervalMs: 100

간격을 낮추면 내구성이 향상되지만 쓰기 성능이 약간 저하될 수 있습니다.

모니터링 및 스케일링 트리거

MongoDB 배포를 확장해야 할 시점을 인식하는 것이 중요합니다. CPU 부하, 메모리 사용량, I/O 대기 시간과 같은 지표를 모니터링하면 용량을 추가해야 할 시점을 판단하는 데 도움이 됩니다.

비즈니스 확장에 흔한 요인

• CPU 사용률이 지속적으로 80% 이상입니다.
• 디스크 I/O 지연 시간이 허용 기준을 초과함(예: 10ms 이상).
• RAM 사용량이 장기간 최대치에 근접함.
• 작업 집합 크기의 급속한 증가.
• 노드 간 복제 지연 증가.

이러한 지표가 나타나면 추가 세컨더리(읽기용) 또는 샤드(쓰기 중심 부하용)를 추가하는 것을 고려하세요.

수직 확장 vs 수평 확장

수직 확장은 기존 서버에 더 많은 자원(CPU, RAM, 더 빠른 디스크 등)을 추가하는 것을 포함합니다. 관리가 더 쉽지만 하드웨어 용량에 의해 제한됩니다.

수평 확장은 작업 부하를 분산시키기 위해 새로운 서버를 추가하는 것을 포함합니다. 이는 몽고DB의 강점으로, 적절하게 설계되면 거의 선형적으로 확장됩니다.

관리형 MongoDB로의 이전

시스템이 성장함에 따라 자체 호스팅 클러스터를 관리하는 것이 복잡해질 수 있습니다. 이 단계에서는 MongoDB Atlas와 같은 관리형 MongoDB 서비스로 전환하면 운영 부담을 크게 줄일 수 있습니다.

관리형 플랫폼은 자동 백업, 패치, 모니터링, 확장 및 암호화를 처리합니다. 그러나 자체 관리 환경에 비해 추가 비용이 발생할 수 있으며 유연성이 다소 떨어질 수 있습니다.

권장: 팀이 성능 병목, 클러스터 관리 복잡성 또는 관리형 플랫폼이 더 효율적으로 처리하는 규제 요구사항과 같은 지속적인 운영 문제에 직면할 때까지는 자체 호스팅을 유지하세요.

비교: 자체 호스팅 vs 관리형 MongoDB

MongoDB는 두 가지 주요 방식으로 배포될 수 있습니다:

1. 셀프 호스팅은 사용자가 직접 데이터베이스를 설치, 구성 및 유지 관리하는 방식입니다(이 가이드에서 다룹니다).
2. 관리형, 제3자 제공자가 MongoDB를 서비스로 호스팅하고 운영해주는 방식입니다.

각 접근 방식에는 고유한 장점과 단점이 있습니다. 적절한 선택은 기술 전문성, 작업 부하 특성, 규정 준수 요구 사항, 운영 우선순위에 따라 달라집니다.

이 두 가지 옵션을 자세히 살펴보겠습니다.

셀프 호스팅 MongoDB

MongoDB를 자체 호스팅할 때는 물리 서버, 가상 머신 또는 Linux-Console.net Droplet과 같은 클라우드 인스턴스 등 자신의 인프라에 직접 설치합니다. 설치부터 업그레이드, 모니터링에 이르기까지 환경의 모든 측면을 직접 제어할 수 있습니다.

셀프 호스팅의 장점

1. 완전한 제어와 유연성: 구성 설정, 파일 시스템, 네트워킹 및 성능 조정에 대한 완전한 권한을 가집니다. mongod.conf 파일을 수정하고, 저장 경로를 선택하며, 조직의 기준에 맞는 맞춤형 보안 또는 백업 정책을 적용할 수 있습니다.
2. 소규모 배포를 위한 비용 효율성: 소규모 또는 중간 규모 워크로드의 경우, 자체 호스팅이 관리형 서비스를 사용하는 것보다 비용이 저렴할 수 있습니다. 추가적인 관리 계층이 아닌 기본 컴퓨팅 및 저장소 리소스에 대해서만 비용을 지불하면 됩니다.
3. 맞춤형 보안 정책: MongoDB를 내부 VPN, 방화벽 또는 사설 네트워크와 통합하여 지역 또는 산업별 보안 요구 사항을 완전히 준수할 수 있습니다. 일부 조직은 데이터 거주지나 규제 제한으로 인해 온프레미스 배포를 요구하기 때문에 자체 호스팅이 유일한 실행 가능한 옵션이 됩니다.
4. 성능 최적화: 하드웨어를 직접 제어할 수 있으므로 I/O 스케줄러, 캐시 크기, 압축 알고리즘과 같은 시스템 매개변수를 세밀하게 조정할 수 있습니다. 또한 MongoDB를 관련 서비스와 동일한 위치에 배치하여 네트워크 지연을 최소화할 수도 있습니다.

셀프 호스팅의 어려움

• 운영 오버헤드: 업데이트 및 패치 설치부터 장애 처리 및 성능 튜닝에 이르기까지 모든 것을 관리할 책임이 있습니다. 이를 위해서는 데이터베이스 관리와 Linux 시스템 관리에 대한 전문 지식을 갖춘 전담 인력이 필요합니다.
• 확장성 복잡성: 자체 호스팅 MongoDB 클러스터를 확장한다는 것은 새로운 서버를 프로비저닝하고, 데이터를 재균형하며, 구성 설정을 업데이트하고, 복제 또는 샤딩 토폴로지를 수동으로 유지 관리하는 것을 의미합니다. 이러한 작업은 자동화 없이는 오류가 발생하기 쉽습니다.
• 백업 및 재해 복구: 스스로 백업, 복원 및 오프사이트 저장 프로세스를 설계, 테스트 및 유지해야 합니다. MongoDB의 도구(mongodump, mongorestore 및 볼륨 스냅샷)는 이를 가능하게 하지만, 이를 위해서는 체계적인 운영 계획이 필요합니다.
• 모니터링 및 경고: 자체 호스팅 MongoDB는 Prometheus, Grafana 또는 Percona PMM과 같은 도구를 사용하여 모니터링 및 경고 시스템을 설정해야 합니다. 지속적인 가시성이 없으면, 장애나 성능 병목 현상이 다운타임을 유발할 때까지 눈에 띄지 않을 수 있습니다.

요약하자면, 자체 호스팅 MongoDB는 소규모에서는 유연성, 독립성, 낮은 비용을 제공하지만, 지속적인 유지 관리 노력이 많이 필요합니다.

관리형 MongoDB 서비스

관리형 MongoDB 서비스는 데이터베이스를 대신 호스팅하며, 모든 인프라, 업데이트, 확장 및 보안 패치를 자동으로 처리합니다. 이러한 서비스는 대부분의 관리 부담을 없애면서 높은 가용성과 전 세계적인 확장성을 제공합니다.

관리형 MongoDB의 장점

1. 최소한의 운영 노력: 서비스 제공자가 데이터베이스 프로비저닝, 백업, 업그레이드 및 장애 조치를 자동으로 처리합니다. 몇 번의 클릭이나 API 호출만으로 새 클러스터를 배포할 수 있어 관리 업무 부담을 크게 줄일 수 있습니다.
2. 자동 스케일링: 관리형 서비스는 데이터셋이 커짐에 따라 컴퓨팅 및 저장소 자원을 동적으로 조정할 수 있습니다. 예를 들어, MongoDB Atlas는 다운타임 없이 자동 샤딩과 수직 스케일링을 지원합니다.
3. 내장 모니터링 및 알림: 관리형 플랫폼에는 CPU 사용량, 디스크 성능, 연결 통계 및 쿼리 지연 시간에 대한 대시보드가 포함되어 있습니다. 별도의 모니터링 도구를 배포하지 않고도 중요한 지표에 대한 알림 임계값을 설정할 수 있습니다.
4. 기본 제공 고가용성: 대부분의 관리형 서비스는 서로 다른 가용 영역에 세 개 이상의 복제 세트 노드를 포함한 클러스터를 배포합니다. 이를 통해 최소한의 설정으로 자동 장애 조치와 높은 가동 시간을 보장합니다.
5. 보안 및 규정 준수: 관리형 MongoDB 플랫폼은 내장 암호화, 역할 기반 접근 제어, 네트워크 격리(VPC 피어링), 그리고 ID 제공자와의 통합을 제공합니다. 또한 SOC 2, GDPR, HIPAA, ISO 27001과 같은 표준에 대한 인증을 받아 규정 준수 감사가 용이합니다.
6. 글로벌 분산: MongoDB Atlas와 유사한 서비스는 다중 지역 클러스터를 지원합니다. 데이터를 사용자와 지리적으로 가까운 위치에 복제할 수 있어 분산 애플리케이션의 지연 시간을 개선할 수 있습니다.

관리형 서비스의 한계

1. 대규모에서는 비용 증가: 관리형 서비스는 자동화와 편의성에 대해 추가 요금을 부과합니다. 데이터 양과 트래픽이 증가함에 따라, 특히 SSD에 저장된 대형 데이터셋의 경우, 월간 비용이 자체 호스팅 인스턴스를 운영하는 비용을 초과할 수 있습니다.
2. 제한된 맞춤 설정: 관리되는 환경에서는 저수준 구성 옵션에 대한 접근이 제한됩니다. 파일시스템 수준 설정, 캐시 조정 또는 기본 운영 체제 매개변수를 변경할 수 없습니다.
3. 벤더 종속(Vendor Lock-In): 각 제공업체는 고유한 API와 배포 구성을 가지고 있어, 나중에 서비스 간 이전이 어렵습니다.
4. 네트워크 의존성: 관리형 데이터베이스는 외부 네트워크 연결에 의존합니다. 애플리케이션이 온프레미스 환경에서 실행되는 경우, 관리형 서비스에 안전하게 연결하는 것이 지연 시간이나 VPN 터널에 대한 의존성을 발생시킬 수 있습니다.

요약하면, 관리형 MongoDB 서비스는 관리 부담을 크게 줄이고 신뢰성을 향상시키지만, 그 대신 유연성이 떨어지고 반복 비용이 더 높아집니다.

기능 비교표

적절한 배포 모델 선택

자체 호스팅 MongoDB와 관리형 MongoDB 중 어떤 것을 선택할지는 주로 조직의 우선순위, 자원, 제약 조건에 달려 있습니다. 다음 시나리오를 고려해 보세요:

• 다음과 같은 경우에는 자체 호스팅 MongoDB를 선택하세요:

  • 인프라와 데이터에 대한 완전한 제어가 필요합니다.
  • 당신의 업무량은 적당하고 예측 가능합니다.
  • 귀하는 Linux 및 MongoDB 관리에 대한 사내 전문 지식을 보유하고 있습니다.
  • 규정 준수 또는 데이터 거주 법률은 온프레미스 저장을 요구합니다.

• 다음과 같은 경우 관리형 MongoDB를 선택하세요:

  • 당신은 인프라보다는 애플리케이션 개발에 집중하는 것을 선호합니다.
  • 최소한의 설정으로 자동 확장과 높은 가용성이 필요합니다.
  • 귀하의 팀에는 전담 데이터베이스 관리자가 부족합니다.
  • 글로벌로 분산된 클러스터나 컴플라이언스 인증(SOC 2, HIPAA, GDPR)이 필요합니다.

문제 해결 및 유지 관리

가장 신중하게 구성하고 모니터링하더라도 MongoDB 배포에서는 문제가 발생할 수 있습니다. 여기에는 성능 저하, 시작 실패, 복제 지연, 디스크 공간 부족 등이 포함될 수 있습니다. 안정적인 MongoDB 환경을 유지하는 핵심은 문제를 진단하고 예방 유지보수 절차를 적용하는 체계적인 접근 방식을 갖는 것입니다.

MongoDB 서비스 상태 확인

MongoDB 문제를 해결할 때 첫 번째 단계는 데이터베이스 서비스가 제대로 실행되고 있는지 확인하는 것입니다.

다음 명령어로 현재 상태를 확인할 수 있습니다:

sudo systemctl status mongod

MongoDB가 실행 중이라면, 다음과 같은 출력이 표시될 것입니다:

Active: active (running)

Main PID: 3564 (mongod)

서비스가 비활성, 실패 또는 중지 상태이면 재시작하세요:

sudo systemctl restart mongod

재시작 후 다시 상태를 확인하세요. 즉시 실패하면 로그 파일에서 구체적인 오류를 확인하세요.

MongoDB 로그 검토

로그는 진단 정보의 가장 직접적인 소스입니다. MongoDB는 주요 이벤트, 경고 및 오류를 모두 다음 위치에 있는 주요 로그 파일에 기록합니다:

/var/log/mongodb/mongod.log

가장 최근 항목을 보려면 다음을 실행하세요:

sudo tail -n 30 /var/log/mongodb/mongod.log

MongoDB가 시작되지 않으면 일반적으로 다음 오류 중 하나가 표시됩니다:

• 권한 거부됨: /var/lib/mongodb 또는 /var/log/mongodb의 소유권이나 권한이 올바르지 않습니다. 권한을 확인하고 수정하세요:

  sudo chown -R mongodb:mongodb /var/lib/mongodb /var/log/mongodb

• 데이터 디렉터리를 찾을 수 없음: /var/lib/mongodb가 존재하고 /etc/mongod.conf에 정의된 경로와 일치하는지 확인하세요.

• 주소 이미 사용 중: 다른 프로세스가 포트 27017을 사용 중입니다. 다음 명령으로 확인하세요:

  sudo lsof -i :27017

  충돌하는 서비스를 중지하거나 재구성하십시오.

• 손상된 데이터 파일: MongoDB가 갑자기 종료된 경우 이러한 문제가 발생할 수 있습니다. 이러한 경우 재시작 시 저널이 데이터를 자동으로 복구해야 합니다. 실패하면 백업에서 복원해야 할 수도 있습니다.

sudo tail -f /var/log/mongodb/mongod.log

연결 문제 진단

연결 문제는 또 다른 빈번한 문제입니다. 클라이언트가 MongoDB에 연결할 수 없을 때는 보통 네트워크, 인증 또는 구성 문제 때문입니다.

MongoDB가 올바른 인터페이스에서 수신 대기 중인지 확인하기

실행 :

sudo ss -tulpn | grep mongod

출력은 MongoDB가 127.0.0.1에 바인딩되어 있는지(로컬 연결용)와 구성된 외부 IP를 표시해야 합니다. MongoDB가 예상된 IP에서 수신 대기하지 않는 경우 /etc/mongod.conf의 bindIp 필드를 확인하십시오.

net:
  bindIp: 127.0.0.1,192.168.10.50

편집 후 MongoDB를 재시작하세요:

sudo systemctl restart mongod

방화벽 규칙 확인

원격 연결이 실패할 경우, 방화벽이 포트 27017의 트래픽을 허용하는지 확인하세요:

sudo ufw status

그렇지 않다면, 특정 IP에서의 연결을 허용하세요:

sudo ufw allow from 192.168.10.50 to any port 27017

Telnet 또는 Ping으로 연결 테스트

클라이언트 시스템에서 포트에 접속할 수 있는지 테스트하세요:

telnet mongodb-server-ip 27017

또는

nc -vz mongodb-server-ip 27017

연결이 성공하면 문제는 인증이나 사용자 권한과 관련되어 있을 가능성이 높습니다.

인증 실패 문제 해결

인증 문제는 액세스 제어를 활성화하거나 사용자 자격 증명을 변경한 후 종종 발생합니다.

인증이 활성화되어 있는지 확인

로컬로 연결하고 확인하십시오:

mongosh --eval "db.runCommand({ getParameter: 1, authenticationMechanisms: 1 })"

출력에 "SCRAM-SHA-256"가 포함되어 있으면 인증이 활성화된 것입니다.

로그인 자격 증명 확인

관리자 계정을 사용하여 연결해 보세요:

mongosh -u admin -p --authenticationDatabase admin

만약 이것이 실패하면, 인증 없이 로컬로 연결하십시오(사용자가 없을 때 로컬호스트에서만 가능) 그리고 관리자 계정을 다시 생성하십시오:

use admin

db.createUser({
  user: "admin",
  pwd: "NewStrongPassword",
  roles: ["userAdminAnyDatabase", "readWriteAnyDatabase"]
})

데이터베이스 컨텍스트 확인

각 MongoDB 사용자는 특정 데이터베이스 내에서 정의됩니다. 잘못된 데이터베이스로 인증하면 인증이 실패합니다. 예를 들어, 사용자가 admin 데이터베이스에서 생성되었다면, 명시적으로 해당 데이터베이스에서 인증해야 합니다:

mongosh -u admin -p --authenticationDatabase admin

성능 문제 해결

성능 저하는 높은 메모리 사용, 느린 디스크 입출력, 최적화되지 않은 쿼리 또는 과도한 동시 연결로 인해 발생할 수 있습니다. MongoDB에는 이러한 문제를 식별하기 위한 여러 진단 도구가 포함되어 있습니다.

리소스 사용량 확인

Linux 명령어를 사용하여 시스템 수준 메트릭을 확인하세요:

top

vmstat 2

iostat -x 2

mongod로 인한 높은 CPU 사용량이나 10밀리초를 초과하는 디스크 지연 시간을 확인하세요.

데이터베이스 작업 모니터링

실행 :

mongostat 2

이것은 초당 삽입, 조회, 업데이트 및 삭제를 포함한 실시간 지표를 표시합니다.

특정 작업이 느리게 실행되는 경우, MongoDB 프로파일러를 사용하여 장시간 실행되는 쿼리를 확인하세요.

쿼리 프로파일링 활성화

느린 쿼리를 기록하기 위해 프로파일러를 일시적으로 활성화할 수 있습니다:

use myappdb

db.setProfilingLevel(1, { slowms: 100 })

이것은 100밀리초보다 오래 걸리는 모든 쿼리를 기록합니다.

결과를 검토하세요:

db.system.profile.find().sort({ ts: -1 }).limit(5).pretty()

인덱스 효율성 분석

비효율적인 쿼리는 종종 인덱스가 없어서 발생합니다. MongoDB가 인덱스를 올바르게 사용하고 있는지 확인하려면 쿼리 앞에 explain()을 추가하세요:

db.orders.find({ customer_id: 12345 }).explain("executionStats")

만약 executionStages.stage가 "COLLSCAN"을 보여준다면, MongoDB가 전체 컬렉션 스캔을 수행하고 있는 것입니다. 성능을 향상시키기 위해 인덱스를 생성할 수 있습니다:

db.orders.createIndex({ customer_id: 1 })

손상된 데이터베이스 복구

데이터 손상은 드물지만, 전원 손실이나 디스크 오류로 발생할 수 있습니다. MongoDB가 시작되지 않고 로그에 WiredTiger 파일에 손상이 표시된다면, 다음 단계를 따르세요:

1. MongoDB 중지:

   sudo systemctl stop mongod

2. 현재 데이터 디렉토리를 백업합니다:

   sudo cp -r /var/lib/mongodb /var/lib/mongodb-corrupt-backup

3. 수리 작업을 시도하십시오:

   sudo -u mongodb mongod --repair --config /etc/mongod.conf

4. MongoDB 재시작:

   sudo systemctl start mongod

수리가 실패하면 가장 최근 백업에서 데이터를 복원하세요.

정기 점검 작업

예방 정비는 예기치 않은 고장의 가능성을 크게 줄입니다.

로그를 정기적으로 회전하십시오

로그 회전 정책이 활성화되어 있는지 확인하세요. MongoDB는 내부 로그 회전(logRotate 명령)과 logAppend가 활성화된 경우 logrotate를 통한 외부 회전을 모두 지원합니다. 로그가 빠르게 증가하면 수동으로 실행할 수도 있습니다:

sudo logrotate -f /etc/logrotate.d/mongodb

컴팩트 컬렉션

컬렉션은 여러 번 삽입과 삭제가 이루어지면 단편화될 수 있습니다. compact는 공간을 회수할 수 있지만 블로킹 작업이므로 실제 운영 환경에서는 거의 사용하지 않는 것이 좋습니다. WiredTiger는 대부분의 단편화를 자동으로 처리하므로 일반적으로 압축(compacting)은 불필요합니다.

이 작업은 데이터베이스를 잠그므로 트래픽이 적은 시간에 수행하세요.

컬렉션 검증

주기적인 데이터 무결성 검사를 실행하세요:

db.runCommand({ validate: "collection_name" })

이는 색인과 문서가 일치하는지 확인합니다.

디스크 및 메모리 사용량 모니터링

디스크 사용량이 85%를 초과하거나 메모리 사용량이 위험 수준에 도달하면 자동 알림을 사용하여 경고하십시오. Prometheus, Percona PMM, 또는 MongoDB Atlas Monitor와 같은 모니터링 도구를 사용하면 이러한 지표를 시간 경과에 따라 추적할 수 있습니다.

시스템 업데이트 안전하게 적용하기

MongoDB나 기본 Ubuntu 시스템을 업데이트할 때는 항상 체계적인 절차를 따라야 합니다:

1. 먼저 데이터를 백업하세요.

2. 커널이나 라이브러리를 업그레이드하기 전에 MongoDB 서비스를 중지하세요:

   sudo systemctl stop mongod

3. 업데이트 적용:

   sudo apt update && sudo apt upgrade -y

4. 서비스를 다시 시작하고 제대로 실행되는지 확인하세요:

   sudo systemctl start mongod
   
   sudo systemctl status mongod

사전 예방적 유지보수를 위한 도구

여러 도구가 지속적인 유지 관리와 건강 점검을 간소화합니다:

• MongoDB Compass: 데이터를 시각적으로 탐색하고 성능 지표를 확인할 수 있는 GUI.
• Atlas CLI: MongoDB Atlas에서 클러스터, 사용자 및 백업을 관리하기 위한 도구입니다.
• Mongosh 스크립트: 맞춤 스크립트를 사용하면 연결 수와 디스크 사용량에 대한 일일 보고서를 생성하거나 건강 상태 점검을 자동화할 수 있습니다.
• Ansible 플레이북: 설치 자동화, 구성 검증, 백업 예약을 수행합니다.

재해 복구 테스트

유지보수 계획의 마지막 단계는 복구 절차 테스트입니다. 백업은 올바르게 복원될 때만 유용합니다.

분기마다 최소 한 번:

1. 가장 최근 백업을 스테이징 서버에 복원하세요.
2. 인덱스, 사용자 및 권한이 올바르게 로드되는지 확인하세요.
3. 복구 시간 목표(RTO)를 충족하는지 확인하기 위해 복원 시간을 측정하세요.
4. 비상시 어떤 관리자라도 실행할 수 있도록 과정을 문서화하세요.

장기 유지보수 체크리스트

이러한 문제 해결 및 유지 관리 방법을 따르면 성능이 우수하고 안전하며 시간이 지나도 견고한 Ubuntu에서 MongoDB 배포를 유지할 수 있습니다. 일관된 모니터링과 유지 관리는 서비스 중단이나 데이터 손실 사건에서 복구하는 것보다 훨씬 비용이 적게 듭니다.

자주 묻는 질문

1. 왜 MongoDB는 기본 Ubuntu 저장소에서 제공되지 않나요?

MongoDB는 라이선스 변경으로 인해 18.04 버전 이후 Ubuntu의 기본 저장소에서 제거되었습니다. MongoDB 서버 사이드 공개 라이선스(SSPL)는 Debian과 Ubuntu 프로젝트에서 오픈 소스로 인정되지 않습니다. 그 결과, Canonical은 더 이상 공식 저장소에서 MongoDB를 배포하지 않으며, 사용자는 대신 MongoDB 자체 APT 저장소에서 설치해야 합니다.

2. MongoDB를 완전히 제거하려면 어떻게 하나요?

MongoDB를 제거하고 관련된 모든 파일을 삭제하려면 다음 명령어를 실행하세요:

sudo systemctl stop mongod

sudo apt purge -y mongodb-org*

sudo rm -rf /var/lib/mongodb

sudo rm -rf /var/log/mongodb

sudo rm -f /etc/apt/sources.list.d/mongodb-org-*.list

sudo apt autoremove -y

이 명령은 MongoDB 서비스를 중지하고, 관련된 모든 패키지를 제거하며, 데이터 및 로그 디렉토리를 삭제하고, 저장소 항목을 정리합니다.

3. MongoDB가 실행 중인지 어떻게 확인하나요?

다음 명령어를 사용하여 MongoDB 서비스 상태를 확인할 수 있습니다:

sudo systemctl status mongod

MongoDB가 실행 중이면 “Active: active (running)”라는 문구가 표시됩니다. 또는 다음 명령어를 실행하여 연결 상태를 확인할 수도 있습니다:

mongosh --eval "db.runCommand({ connectionStatus: 1 })"

명령이 "ok": 1을 반환하면, MongoDB가 활성화되어 있고 연결을 허용하고 있는 것입니다.

4. MongoDB를 작은 VPS에서 실행할 수 있나요?

네, MongoDB는 작은 VPS에서도 실행할 수 있지만 제한이 있습니다. 기본 개발이나 테스트 작업의 경우, 2개의 CPU 코어, 2GB RAM, 10~20GB SSD 저장 공간을 갖춘 서버면 충분합니다.

하지만 실제 운영 환경에서는 MongoDB가 최소 4개의 CPU 코어, 8GB RAM, 고속 SSD 또는 NVMe 스토리지가 있는 시스템에서 가장 잘 작동합니다. 메모리가 부족한 환경에서는 과도한 스와핑을 방지하기 위해 WiredTiger 캐시 크기를 조정해야 할 수 있습니다.

5. MongoDB가 복구 작업 실행 후에 시작되지 않는 이유는 무엇인가요?

MongoDB는 수리 작업을 root로 실행한 경우 시작에 실패할 수 있습니다. 이는 /var/lib/mongodb에 있는 데이터 파일의 소유권이 root:root로 변경되기 때문입니다. mongod 서비스가 mongodb 사용자로 실행되므로, 이러한 파일을 읽거나 쓸 권한이 없습니다. 이를 해결하려면 수리 명령을 mongodb 사용자로 실행하거나, 실행 후 올바른 소유권을 복원해야 합니다:

sudo chown -R mongodb:mongodb /var/lib/mongodb

6. MongoDB가 올바른 네트워크 인터페이스에서 수신 중인지 어떻게 확인할 수 있나요?

다음을 사용하여 MongoDB의 활성 리스너를 확인할 수 있습니다:

sudo ss -tulpn | grep mongod

이것은 MongoDB가 바인딩된 IP 주소와 포트를 보여줍니다. 예상한 IP(예: 애플리케이션 서버의 IP)가 보이지 않는 경우, /etc/mongod.conf에서 bindIp 값을 확인하고 서비스를 재시작하세요.

7. MongoDB의 기본 WiredTiger 캐시 크기를 변경해야 하나요?

대부분의 경우, 아니요. WiredTiger는 시스템 RAM의 약 50%를 자동으로 사용하며, 사용 가능한 메모리에 따라 캐시 사용량을 동적으로 조절합니다. MongoDB가 다른 메모리 집약적인 애플리케이션과 서버를 공유하는 경우에만 cacheSizeGB 설정을 조정하세요. 전용 MongoDB 서버라면 일반적으로 기본 동작을 유지하는 것이 좋습니다.

8. 왜 제 MongoDB 로그가 이렇게 많이 늘어나죠?

MongoDB는 운영 데이터를 /var/log/mongodb/mongod.log 파일에 지속적으로 기록합니다. 로그 순환(log rotation) 없이 사용하면 이 파일이 매우 커질 수 있습니다. 가이드의 유지 관리 섹션에 설명된 대로 logrotate를 사용하여 로그 순환이 설정되어 있는지 확인하여, 오래된 로그가 자동으로 압축되거나 삭제되도록 하세요.

9. 복제 세트에 노드를 추가해야 할 시기는 언제인가요?

읽기 트래픽이 지속적으로 증가하거나, 노드 선출이 자주 발생하거나, 복제 지연이 발생하거나, 여러 존이나 지역에 걸쳐 더 높은 가용성이 필요할 때 복제 세트를 확장해야 합니다. 세컨더리를 추가하면 읽기 부하가 분산되고 내결함성이 향상되며, 특히 운영 환경에서 유용합니다.

10. MongoDB 서버에서 TLS가 올바르게 활성화되어 있는지 어떻게 확인할 수 있나요?

/etc/mongod.conf에서 TLS를 구성한 후, 다음을 사용하여 연결하세요:

mongosh --tls --host <server-ip> -u admin -p --authenticationDatabase admin

연결에 성공하면, 다음을 실행하세요:

openssl s_client -connect <server-ip>:27017

유효한 TLS 핸드셰이크와 Protocol: TLSv1.3와 같은 세부 정보는 암호화가 활성화되어 있음을 확인해 줍니다.

결론

MongoDB를 효과적으로 운영하는 것은 단순히 설치와 설정에 관한 것이 아니라, 시간에 따라 성능, 보안 및 안정성 사이의 균형을 유지하는 것입니다. 이제 귀하는 생산 환경의 작업을 지원하고, 수요에 따라 확장하며, 예상치 못한 장애에서 복구할 수 있는 완전한 기능을 갖춘 MongoDB 시스템을 갖추게 되었습니다.

이 가이드에 나와 있는 원칙과 모범 사례를 일상적인 모니터링부터 장기적인 용량 계획까지 적용하면 어떤 환경에서도 MongoDB를 자신 있게 운영할 수 있습니다. 직접 관리하든 MongoDB Atlas와 같은 관리형 서비스로 마이그레이션하든, MongoDB 내부 동작에 대한 이해를 통해 항상 데이터에 대한 통제권을 유지할 수 있습니다.

데이터베이스에 대해 더 알아보려면, 다음 튜토리얼을 확인하세요:

• 데이터베이스의 다양한 유형은 무엇인가요? 사용 사례와 아키텍처로 설명
• SQLite vs MySQL vs PostgreSQL: 관계형 데이터베이스 관리 시스템 비교
• 우분투에 Node.js 설치하는 방법
• MERN 스택 시작하는 방법

Linux-Console.net 커뮤니티와 함께 학습해 주셔서 감사합니다.