들어가며
검색 시스템을 구축하여 사용자에게 제공하기 시작하면, 이미 “멈출 수 없는 시스템”이 됩니다. 사용자가 일상적으로 검색에 의존하게 되면, 검색을 사용할 수 없는 시간은 업무 정체로 직결됩니다.
이 글에서는 Fess를 안정적으로 운영하기 위한 모니터링, 백업, 장애 대응에 대해 실전 플레이북으로 해설합니다.
대상 독자
Fess를 운영 환경에서 관리하는 관리자
검색 시스템의 안정 가동을 보장하고 싶은 분
시스템 운영에 대한 기본 지식이 있는 분
운영의 전체상
Fess의 안정 운영은 다음 세 가지 축으로 구성됩니다.
모니터링: 문제를 조기에 발견한다
백업: 데이터를 보전한다
장애 대응: 문제 발생 시 신속하게 복구한다
모니터링
헬스 체크
Fess는 REST API를 통해 헬스 체크 엔드포인트를 제공합니다.
GET http://localhost:8080/api/v1/health
정상 시 HTTP 200이 반환됩니다. 외부 모니터링 도구(Nagios, Zabbix, Datadog 등)에서 이 엔드포인트를 정기적으로 호출하여 Fess의 가동 상태를 모니터링할 수 있습니다.
시스템 정보 확인
관리 화면의 [시스템 정보]에서 다음 정보를 확인할 수 있습니다.
크롤 정보
마지막 크롤 실행 결과(처리 문서 수, 오류 수 등)를 확인할 수 있습니다. 크롤이 정상적으로 완료되었는지 확인하는 데 사용합니다.
시스템 정보
Fess와 OpenSearch의 버전, JVM 메모리 사용량, 인덱스의 문서 수 등을 확인할 수 있습니다.
모니터링해야 할 지표
크롤 완료 알림
Fess에는 오류 로그나 검색 엔진 장애 감지 시 알림을 보내는 기능이 있습니다. Slack이나 Google Chat의 Webhook을 설정하면 이상 발생을 즉시 파악할 수 있습니다.
백업
백업 대상
Fess 환경의 백업 대상은 다음 두 가지로 크게 나뉩니다.
1. 설정 데이터
크롤 설정, 사용자 정보, 사전 데이터 등 관리 화면에서 설정한 정보입니다. Fess 관리 화면의 [시스템 정보] > [백업]에서 설정 데이터의 백업을 가져올 수 있습니다.
2. 인덱스 데이터
크롤로 수집한 문서의 인덱스입니다. OpenSearch의 스냅샷 기능을 사용하여 백업합니다.
백업 전략
| 대상 | 빈도 | 보존 기간 | 방법 |
|---|---|---|---|
| 설정 데이터 | 일별 | 30세대 | Fess 백업 기능 |
| 인덱스 | 일별 | 7세대 | OpenSearch 스냅샷 |
| Docker 구성 | 변경 시 | Git 관리 | compose.yaml 버전 관리 |
설정 데이터 백업 자동화
Fess의 관리 API를 사용하여 설정 데이터의 백업을 자동화할 수 있습니다. 스케줄러의 작업으로 설정하거나 외부 cron 작업으로 실행합니다.
복원 절차
장애 발생 시의 복원 절차를 사전에 확인해 두는 것이 중요합니다.
Fess 정지
설정 데이터 복원(관리 화면 또는 API)
필요에 따라 OpenSearch 스냅샷에서 복원
Fess 기동
동작 확인
복원 절차는 정기적으로 리허설을 실시하여 절차의 정확성과 소요 시간을 파악해 둡시다.
장애 대응
자주 발생하는 장애와 대처법
Fess가 기동되지 않는 경우
로그 파일(logs/fess.log) 확인
JVM 메모리 부족:
-Xmx파라미터 조정포트 충돌: 8080 포트가 다른 프로세스에서 사용되고 있지 않은지 확인
OpenSearch 연결 실패: OpenSearch가 기동되어 있는지 확인
크롤이 실패하는 경우
작업 로그([시스템 정보] > [작업 로그]) 확인
네트워크 연결: 크롤 대상에 대한 연결 확인
인증 오류: 인증 정보(비밀번호, 토큰)의 유효 기간 확인
장애 URL 확인: [시스템 정보] > [장애 URL]에서 상세 확인
검색이 느린 경우
OpenSearch의 클러스터 상태 확인(yellow/red인 경우 대응 필요)
인덱스 크기 확인(비대화되지 않았는지)
JVM 힙 확인(가비지 컬렉션이 빈번하게 발생하고 있지 않은지)
동시 크롤 중인 경우, 크롤 완료 후 개선되는지 확인
검색 결과가 오래된 경우
크롤 스케줄 확인(정상적으로 실행되고 있는지)
크롤 설정의 최대 접근 수가 부족하지 않은지
대상 사이트가 크롤을 차단하고 있지 않은지(robots.txt)
장애 URL 관리
크롤 시 접근할 수 없었던 URL은 “장애 URL”로 기록됩니다. 관리 화면의 [시스템 정보] > [장애 URL]에서 확인할 수 있습니다.
장애 URL이 많은 경우 다음을 확인합니다.
대상 서버가 정지되어 있지 않은지
네트워크 경로에 문제가 없는지
인증 정보가 유효한지
크롤 간격이 너무 짧아 대상 서버에 부하를 주고 있지 않은지
로그 관리
Fess의 로그 파일은 다음 위치에 출력됩니다.
Fess 로그:
logs/fess.log(애플리케이션 로그)크롤 정보: 관리 화면의 [시스템 정보] > [크롤 정보]
작업 로그: 관리 화면의 [시스템 정보] > [작업 로그]
검색 로그: 관리 화면의 [시스템 정보] > [검색 로그]
로그 파일이 비대화되지 않도록 로그 로테이션 설정을 확인해 둡시다.
운영 체크리스트
일상적인 운영에서 확인해야 할 항목을 체크리스트로 정리합니다.
일별 체크
크롤이 정상적으로 완료되었는가
헬스 체크가 정상인가
디스크 사용률이 임계값 이하인가
주별 체크
검색 로그의 제로 히트율(제8회 참조)
실패 URL 확인 및 대응
백업이 정상적으로 취득되고 있는가
월별 체크
인덱스 크기 추이
JVM 메모리 사용량 트렌드
사전 업데이트(제9회 참조)
보안 패치 확인
정리
이 글에서는 Fess의 안정 운영을 위한 모니터링, 백업, 장애 대응에 대해 해설했습니다.
Health API와 관리 화면을 활용한 모니터링
설정 데이터와 인덱스 데이터의 백업 전략
자주 발생하는 장애 패턴과 대처법
일별, 주별, 월별 운영 체크리스트
“검색이 되는 것은 당연하다”를 유지하기 위해 예방적인 운영 체제를 갖춥시다.
다음 회에서는 검색 API를 사용하여 기존 시스템과 연계하는 패턴을 다룹니다.