[Log] Log 중앙화

로그 서버를 따로 두는 이유는 시스템 운영, 성능, 보안, 그리고 유지 관리 측면에서 여러 가지 이점을 얻기 위함입니다. 특히 분산 시스템이나 대규모 애플리케이션 환경에서 로그를 중앙화하는 것은 필수적인 전략으로 여겨집니다. 아래에 주요 이유와 그에 따른 장점을 자세히 설명드리겠습니다.

---

1. 중앙화된 로그 관리

• 이유: 여러 서버나 애플리케이션에서 발생하는 로그를 각 시스템에 개별적으로 저장하면 관리가 어려워집니다. 로그 서버를 따로 두면 모든 로그를 한 곳에 모아 분석하고 모니터링할 수 있습니다.
• 장점:
  
  • 로그 검색과 분석이 쉬워짐 (예: ELK 스택의 Kibana로 시각화).
  • 문제 발생 시 단일 지점에서 전체 시스템 로그 확인 가능.
  • 예: Log 서버에 로그 데이터를 저장하고 확인.

---

2. 성능 최적화

• 이유: 애플리케이션 서버가 로그를 직접 기록하면 디스크 I/O, CPU, 메모리 등의 리소스를 소모합니다. 로그 서버를 분리하면 애플리케이션 서버의 부하를 줄일 수 있습니다.
• 장점:
  
  • 애플리케이션 서버는 핵심 비즈니스 로직에 집중 가능.
  • 로그 쓰기 작업이 병목 지점이 되지 않음.
  • 예: 애플리케이션 로그를 수집해 로그 서버의 HBase로 전달하면 애플리케이션 자체는 로그 처리 부담 없음.

---

3. 보안 강화

• 이유: 로그에는 민감한 정보(사용자 데이터, 요청 IP 등)가 포함될 수 있습니다. 애플리케이션 서버에 로그를 두면 해킹 시 로그 데이터도 노출될 위험이 큽니다.
• 장점:
  
  • 로그 서버를 별도로 보호하고 접근 제어 가능 (예: 방화벽, VPN).
  • 로그 데이터 암호화 및 백업 용이.
  • 예: HBase와 ZooKeeper를 별도 서버에 두고 인증 설정으로 접근 제한.

---

4. 확장성과 고가용성

• 이유: 분산 시스템에서는 서버 수가 증가하며 로그 양도 급격히 늘어납니다. 로그 서버를 따로 두면 로그 처리 시스템을 독립적으로 확장할 수 있습니다.
• 장점:
  
  • 로그 서버를 클러스터로 구성해 고가용성(HA) 확보 (예: ZooKeeper 앙상블).
  • 대규모 트래픽에도 안정적 로그 처리 가능.
  • 예: Kafka를 로그 스트리밍 서버로 사용해 여러 애플리케이션 로그를 수집.

---

5. 장애 분석 및 복구

• 이유: 애플리케이션 서버가 다운되면 로컬 로그에 접근하기 어려울 수 있습니다. 별도의 로그 서버는 애플리케이션 장애와 독립적으로 로그를 보존합니다.
• 장점:
  
  • 장애 원인 분석 시 최신 로그 즉시 확인.
  • 로그 백업으로 데이터 손실 방지.
  • 예: 로그 서버에 저장된 로그 데이터로 장애 시점 추적.

---

6. 실시간 모니터링 및 알림

• 이유: 중앙화된 로그 서버는 실시간 로그 처리 및 알림 시스템과 통합하기 용이합니다.
• 장점:
  
  • 오류 로그 발생 시 즉시 알림 (예: ELK + 슬랙 연동).
  • 실시간 대시보드 제공 (예: Pinpoint Web, Kibana).
  • 예: Pinpoint Web이 Collector와 HBase에서 데이터를 가져와 실시간 UI 제공.

---

7. 법적/감사 요구사항

• 이유: 일부 산업(금융, 의료 등)에서는 로그를 장기 보관하고 감사 추적을 해야 할 법적 요구사항이 있습니다.
• 장점:
  
  • 별도 로그 서버에서 로그를 체계적으로 보관 및 관리.
  • 규제 준수 용이.

 

log 서버에 다른 백엔드 서버 로그 저장 실습

1) Log 서버

- rsyslog 설치

apt install rsyslog

 

- 환경 설정

vi /etc/rsyslog.conf

------------------------------------------

# provides UDP syslog reception 주석 해제
module(load="imudp") 
input(type="imudp" port="514") 

# provides TCP syslog reception 주석 해제
module(load="imtcp") 
input(type="imtcp" port="514")

 

- rsyslog 재시작

systemctl restart rsyslog

 

- 514 포트 확인

netstat -anlp | grep :514

 

- log 저장할 파일 생성 및 권한 설정

touch  /var/log/spring-application.log

chmod 777 /var/log/spring-application.log

 

- facility와 Log 저장 파일 경로 설정 추가

vi /etc/rsyslog.d/50-default.conf

------------------------------------------
# 마지막 줄에 추가
user.*    /var/log/spring-application.log

• user facility에서 발생한 로그를 /var/log/spring-application.log 파일에 기록하도록 추가

 

- 재시작

systemctl restart rsyslog

 

- 로그 확인

tail -f /var/log/spring-application.log

 

2) 백엔드 서버(Spring)

- logback 설정파일(xml) 생성 및 애플리케이션 로그를 원격 Syslog 서버로 전송하도록 구성

<configuration>
    <property name="SYSLOG_HOST" value="[LogServer IP]"/>
    <property name="SYSLOG_PORT" value="[LogServer rsyslog PORT]"/>
    <appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
        <syslogHost>${SYSLOG_HOST}</syslogHost>
        <port>${SYSLOG_PORT}</port>
        <facility>USER</facility>
        <suffixPattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %m%n</suffixPattern>
    </appender>
</configuration>

• SYSLOG_HOST: 로그를 전송할 Syslog 서버의 IP 주소 (예: 192.168.1.100).
• SYSLOG_PORT: Syslog 서버가 수신하는 포트 번호 (예: 514, rsyslog의 기본 포트).
• name="SYSLOG": 이 Appender의 이름, 로거에서 참조 시 사용.
• class="ch.qos.logback.classic.net.SyslogAppender": Syslog 프로토콜을 통해 로그를 전송하는 Logback의 클래스.
• facility="USER": Syslog 메시지의 출처를 USER로 설정 (Syslog 표준 필드, 애플리케이션 로그 의미).
• suffixPattern: 로그 메시지의 출력 형식:
  
  • %d{yyyy-MM-dd HH:mm:ss}: 날짜와 시간 (예: 2025-02-21 12:34:56).
  • [%thread]: 스레드 이름.
  • %-5level: 로그 레벨 (INFO, ERROR 등, 5자리로 정렬).
  • %logger{36}: 로거 이름 (최대 36자).
  • %m: 로그 메시지.
  • %n: 줄 바꿈.

위의 설정을 통해 여러 백엔드 서버의 로그를 하나의 로그 서버에 저장할 수 있습니다.