WS / WAS / DB 레이어 별 장애 포인트 및 대응 방안

업데이트:

1. 웹 서버(WS) 레이어

정의

웹 서버는 HTTP를 기반으로 동작하며, 주로 정적 리소스와 기타 부가기능을 제공합니다. 정적 리소스는 HTML, CSS, JS, 이미지 파일 등을 포함하며, 서버는 이러한 리소스를 클라이언트에 제공하는 역할을 합니다.

또한 일부 웹 서버는 서블릿, JSP, PHP, ASP와 같은 동적 리소스를 실행할 수 있는 기능도 갖추고 있습니다.

예시

  • Apache
  • Nginx



2. 웹 애플리케이션 서버(WAS) 레이어

정의

웹 애플리케이션 서버(WAS)는 웹 서버의 기능을 포함하여 동적 리소스를 실행하는 서버입니다. 프로그램 코드를 실행하여 동적으로 결과를 생성하는 역할을 하며, 예를 들어 서블릿, JSP, PHP, ASP, Spring MVC 등을 처리합니다.

또한, 동적 HTML 생성이나 HTTP API(JSON) 제공과 같은 다양한 기능을 지원합니다.

예시

  • Tomcat
  • Jetty
  • Undertow
  • JBoss



WS와 WAS의 차이

  • 웹 서버(WS): 주로 정적 리소스를 제공 (예: HTML, CSS, JS, 이미지).

  • 웹 애플리케이션 서버(WAS): 애플리케이션 로직을 실행하여 동적 리소스를 처리 (예: 서블릿, JSP, PHP).

예를 들어, 자바 환경에서는 JSP와 서블릿 같은 동적 리소스를 WAS에서 실행하고, 정적 리소스는 WS에서 제공하는 것이 일반적입니다.



웹 시스템 구성


웹 시스템은 웹 서버(WS)웹 애플리케이션 서버(WAS) 로 나누어집니다.


WS는 정적 리소스 제공을 담당하고, WAS는 애플리케이션 로직을 포함한 동적 리소스를 처리합니다.

이렇게 역할을 분리함으로써 WAS와 데이터베이스(DB) 서버의 과부하를 줄일 수 있고, 장애가 발생했을 때에도 웹 서버에서 기본 오류 페이지를 제공할 수 있습니다.

WS / WAS / DB 레이어 별 장애 포인트 조사 및 대응 방안

1. 웹 서버(WS) 레이어

장애 포인트와 대응 방안

① 과도한 트래픽으로 인한 서버 과부하

  • 로드 밸런서 구축으로 트래픽 분산
  • 오토스케일링 설정으로 자동 서버 확장
  • CDN 활용하여 정적 컨텐츠 부하 감소
  • 캐싱 전략 최적화

② 설정 오류(예: 잘못된 가상 호스트 설정)

  • 설정 파일 자동화 도구 사용(Ansible, Puppet)
  • 설정 변경은 테스트 환경에서 검증 후 적용
  • 설정 파일을 버전 관리하고 정기적인 감사 및 리뷰 진행

③ 보안 취약점(예: SSL/TLS 설정 오류)

  • 정기적인 보안 업데이트 및 패치 적용
  • SSL/TLS 설정 자동 점검 도구 사용
  • 보안 설정 가이드라인 수립 및 준수
  • 주기적인 보안 감사 및 취약점 스캔 실시

④ 디스크 공간 부족

  • 디스크 공간 모니터링 시스템 구축
  • 로그 로테이션 및 압축 정책 수립
  • 불필요한 파일 자동 저리 스크립트 구현
  • 클라우드 스토리지 연동으로 확장성 확보

⑤ 네트워크 연결 문제

  • 이중화된 네트워크 구성
  • 네트워크 모니터링 도구 도입
  • ISP 이중화 또는 백업 회선 구축
  • DNS 이중화 및 지리적 분산



2. 웹 애플리케이션 서버(WAS) 레이어

장애 포인트와 대응 방안

① 메모리 누수

  • 주기적인 힙 덤프 분석 및 메모리 프로파일링
  • 코드 리뷰와 정적 분석 도구 사용
  • 가비지 컬렉션 튜닝 및 모니터링
  • 메모리 사용량 임계치 설정 및 알림 구현

② 쓰레드 고갈

  • 쓰레드 풀 설정 최적화
  • 비동기 프로그래밍 패턴 적용(예: CompletableFuture, Reactive Programming)
  • 데드락 및 쓰레드 경합 모니터링 도구 사용
  • 장기 실행 작업은 배치 처리로 분리

③ 리소스 관리 미흡

  • 리소스 사용량 모니터링 및 로깅 강화
  • 자동 스케일링 정책 수립
  • 컨테이너 리소스 제한 설정
  • 캐싱 전략 최적화 및 분산 캐시 시스템 도입

④ 애플리케이션 코드 버그

  • 단위 테스트, 통합 테스트 강화
  • CI/CD 파이프라인 구축
  • 코드 품질 분석 도구 도입(예: SonarQube)
  • 로깅 및 모니터링 강화로 버그 조기 발견
  • 카나리 배포 또는 블루-그린 배포 전략 적용

⑤ 데이터베이스 연결 풀 고갈

  • 연결 풀 크기 최적화 및 모니터링
  • 연결 누수 탐지 및 해결
  • 데이터베이스 프록시 도입(예: PgBouncer, ProxySQL)
  • 읽기 전용 작업의 분리 및 읽기 전용 복제본 활용
  • 데이터베이스 연결 재시도 및 백오프 전략 구현



3. 데이터베이스(DB) 레이어

장애 포인트와 대응 방안

① 느린 쿼리 실행

  • 쿼리 실행 계획 분석 및 최적화
  • 주기적인 쿼리 성능 모니터링 및 튜닝
  • 파티셔닝 전략 적용
  • 캐싱 레이어 도입(예: Redis, Memcached)
  • 읽기 전용 복제본 활용하여 부하 분산

② 인덱스 부족 또는 비효율적인 인덱스

  • 쿼리 패턴 분석을 통한 적절한 인덱스 설계
  • 인덱스 사용 현황 모니터링 및 불필요한 인덱스 제거
  • 정기적인 인덱스 재구축 및 통계 갱신

③ 디스크 I/O 병목 현상

  • SSD 또는 고성능 스토리지 시스템 도입
  • RAID 구성 최적화
  • 디스크 I/O 모니터링 및 알림 설정
  • 데이터 아카이빙 및 파티셔닝으로 데이터 볼륨 관리

④ 연결 한계 도달

  • 커넥션 풀 크기 최적화
  • 데이터베이스 프록시 도입
  • 연결 관리 전략 개선
  • 읽기 전용 복제본 활용
  • 데이터베이스 클러스터링 또는 샤딩 고려

⑤ 데이터 무결성 문제

  • 제약 조건 및 트리거 설정
  • 트랜잭션 관리 및 ACID 속성 준수
  • 정기적인 데이터 검증 및 정합성 체크 스크립트 실행
  • 백업 및 복구 전략 강화
  • 데이터 변경 로깅 및 감사 체계 구축

결론

위의 대응 방안을 체계적으로 적용하면, 각 레이어의 성능과 안정성을 크게 향상시킬 수 있습니다.

참고사이트

[WEB] WS(Web Server) vs WAS(Web Application Server)

댓글남기기