7장. 무정지를 위한 인프라 구조

7.1 안정성 및 이중화

• 안정성, 고가용성
  • 시스템 서비스가 가능한 한 멈추지 않도록 하는 것
• 안정성 및 고가용성의 목표
  • 고장, 장애에 의한 정지가 발생하지 않을 것 (하드웨어에서는 MTBF-Mean Time Between Failure, 평균 장애 지속 시간 이라고 함)
  • 고장, 장애가 발생해도 복구할 수 있을 것 (하드웨어에서는 MTTR-Mean Time To Repair, 평균 복구 시간 이라고 함)
  ⇒ 컴포넌트 이중화
  • 고장, 장애가 발생한 것을 검출할 수 있을 것 ⇒ 컴포넌트 감시
  • 고장, 장애가 발생해도 데이터가 보호될 것 ⇒ 데이터 백업
• 이중화란?
  • 하나의 기능을 병렬로 여러 개 나열해서 하나에 장애가 발생해도 다른 것을 이용해서 서비스를 계속할 수 있는 것
  • 이중화는 반드시 부하분산, 내부적 생존 감시, 마스터 결정, 페일오버의 구조를 갖추고 있음

이중화에 의한 안정성은 다양한 계층에서 실현할 수 있다.

1. H/W 컴포넌트 계층
   1. 전원, 네트워크, 하드디스크 이중화
   2. 신뢰도가 비교적 낮은 부분과 데이터 보호를 목적으로 함
2. 시스템 계층
   1. 여러 서버에서 동일한 처리를 실행하는 서버 이중화
   2. 특정 서버의 처리가 중단돼도 다른 서버에서 처리를 지속해서 사용자에게는 영향을 주지 않는 것이 목적(가장 자주 사용)
3. 물리적 위치 계층
   1. 시스템을 서로 다른 위치(데이터 센터나 클라우드)에서 운영하는 이중화
   2. 데이터 센터의 정전이나 대규모 장애가 발생한 경우에도 시스템을 유지하는 것이 목적

⇒ 인프라에서 중요한 것은 사용자에게 영향을 주지 않는 것이다. CPU에 돈을 들이는 것 보다 시스템 이중화가 더 싸고 효과적이다. 즉, 비용과 신뢰도는 상호 의존 관계에 있기 때문에 비용을 아껴서 시스템의 신뢰도를 높이는 것은 인프라 엔지니어에게 중요한 역량이다.

7.2 서버 내 이중화

• 액티브-스탠바이 구성
  • 액티브 측에서 어떤 문제가 발생하면 스탠바이 장비로 교체돼서 스탠바이가 액티브로 변경 ⇒ 페일오버(Failover)
• 리눅스 본딩(Bonding)이 이중화된 인터페이스를 감시하는 두 가지 방식
  • MII(Media Independent Interface)감시
    • 링크업(인터페이스가 가동되는 것)이 동작하면 정상이라고 판단
    • 불필요한 폴링(특정 주기로 네트워크 상태를 확인하는 것) 패킷이 전송되지 않고 폴링 위치로 지정한 IP 주소를 가진 장비에 대해서는 유지관리나 장애를 의식하지 않아도 되기 때문에 가장 선호되는 방식
    • MII 감시는 링크업 상태를 확인하는 것만으로도 충분하기 때문에, 불필요한 네트워크 확인 작업(폴링)을 줄일 수 있음
    • 인터페이스의 링크 상태를 확인하기 때문에 접속돼 있는 L2 스위치만 감시 가능
  • ARP감시
    • 특정 IP 주소로 ARP 요청을 보내서 돌아오는 응답 유무에 따라 정상적인지 확인
    • 폴링이 되는 ARP 요청이 동일 네트워크 내의 브로드캐스트이기 때문에 불필요한 트래픽이 증가(단점) → 감시 빈도를 너무 높게 설정하지 않는 것이 중요하다
    • 임의의 IP 주소에 대해 ARP 요청을 본냄(네트워크 게이트웨이)

7.3 저장소 내부 구조와 RAID

저장소 이중화의 주요 대상은 HDD고, HDD는 가동 빈도가 높아서 고장 나기 쉽기 때문에 자체 이중화를 통해 저장소를 관리해야 한다.

• RAID(Redundant Array of Independent Disk)
  • 여러 HDD를 묶어서 그룹으로 만들고 이것을 논리적인 HDD로 인식하는 기술
  • LU(Local Unit): 논리적 HDD
  • 안정성 확보: HDD에 장애가 발생해도 데이터가 손실되지 않도록 데이터 기록을 이중화(HDD는 움직이는 부분이 많아서 고장이 쉽기 때문에 기록을 이중화한다는 것은 매우 중요)
  • 성능 향상: 여러 개의 HDD를 병렬로 동시에 동작시키기 때문에 하나의 HDD를 동작시킬 대보다 I/O 처리 성능이 높아짐
  • 용량 확장: 10TB를 하나의 파일 시스템으로 취급 가능

→ RAID를 통해 이중화 작업을 하더라도 다중 장애 시에는 복구할 수 없는 경우가 있기 때문에 RAID에만 의존하는 것이 아니라 데이터 백업도 반드시 해 두어야 함

• 버스 이중화
  • DM-Multipath(버스 이중화)
    • I/O는 I/O 스케줄러나 드라이버 같은 커널내부를 통과하지만, DM-Multipath는 I/O 요청(고정 길이 블록의 집합)을 HBA에 할당해서 페일오버를 실현
    • 저장소가 지원하는 경우 액티브-스탠바이로도 사용 가능

7.4 웹 서버 이중화(소프트웨어 관점)

• Apache HTTP Server(아파치)
  • 어느 쪽이든 미리 여러개를 가동시켜 두어서 클라이언트 요청에 빠르게 대응할 수 있는 구성을 가지고 있음
  • 여러 개를 가동시켜 두면 프로세스/스레드 중 하나에 장애가 발생해도 다른 프로세스/스레드가 가동되고 있기 때문에 웹 서버의 서비스 전체가 정지되는 일은 없음
  장애가 발생하면?
  • HTTP 프로토콜의 상태 코드를 통해서 에러를 반환
  • 웹 서버에 대한 요청은 큐에 쌓이지 않고 바로 에러를 반환한다는 특징이 있다
• 서버 이중화
  • DNS를 이용해서 하나의 호스트명에 대해 복수의 IP 주소를 반환
  • (클라이언트가 URL을 입력하면 URL내에 호스트명이 포함되어 있어서 DNS를 이용해서 하나의 호스팅명에 대해 복수 IP 주소를 반환하는 것)
  • DNS 라운드 로빈(Round Robin)DNS는 질의에 대해 순서대로 IP 주소를 반환하고 이 방법은 매우 간단하게 서버를 이중화할 수 있다는 이점이 있지만 몇 가지 주의사항이 있다.
    • DNS가 서버 상태를 감시해서 파악하지 않기 때문에 서버가 정지된 경우에도 그 서버의 주소를 반환(가용성을 중요시 하는 경우 부적합)
    • DNS가 세션 상태를 파악하지 않기 때문에 다음 접속 시에 동일 서버에 접속해야 하는 경우에도 부적합(웹 서버에 동적 컨텐츠가 있어서 세션 상태를 저장하고 있어야 하는 경우 DNS 라운드 로빈 방식이 부적합)
  • 호스트명에 대해 복수의 IP 주소를 등록해 두는 것
  ⇒ 단점을 극복하기 위한 부하분산 장치: 로드밸런서
  1. 부하분산 장치가 이전에 어느 웹 서버에 요청을 할당했는지를 쿠키에 저장하고 있다
  2. 클라이언트 측에서 쿠키 사용을 허가하면 두 번째 이후 접속부터 HTTP 요청 헤더에 쿠키를 저장해서 접속한다
  3. 부하분산 장치는 이 쿠키를 읽어서 같은 서버에 요청을 할당하는 것
• 퍼시스턴스(Persistence): 세션 상태 저장을 실현하는 기능
  • 소스 IP 주소: 클라이언트 IP 주소를 기반으로 요청을 할당할 웹 서버를 결정(클라이언트 IP 끝자리가 홀수이면 웹 서버 1에 할당하는 등)
  • 쿠키: HTTP 헤더 내에 접속한 웹 서버 정보를 저장
  • URL: URL 구조 내에 접속한 웹 서버 정보를 저장
• 부하분산 장치의 할당 알고리즘
  • 라운드 로빈(Round Robin): 서버의 IP 주소에 순서대로 요청을 할당
  • 최소 연결(Least Connection): 현재 활성 세션 수보다 세션 수가 가장 적은 서버의 IP 주소에 요청을 할당
  • 응답 시간(Response Time): 서버의 CPU 사용률이나 응답 시간 등을 고려해서 가장 부하가 적은 서버의 IP 주소에 요청을 할당

장애가 발생하면?

→ 부하분산 장치는 웹 서버의 가동 상태를 탐지할 수 있다. 장애를 감지한 경우는 클라이언트 요청을 동적으로 다른 서버에 할당(페일오버)할 수 있다.

*할당 알고리즘 선택시에 고려해야 할 것은 ‘복잡한 알고리즘’을 피하는 것(복잡할 수록 데이터가 알고리즘을 통과할 때 부하가 커짐)

→ 정적 콘텐츠가 저장되는 웹 서버의 경우는 일반적으로 웹 서버 처리가 가볍고, 세션 수와 CPU 등의 리소스 소비가 비례(단순한 알고리즘, 라운드 로빈, 최소 연결 방식을 주로 사용)

7.5 AP 서버 이중화

1. 부하분산 장치 사용
2. 세션 정보 이중화

*오라클 웹로직 서버(Oracle WebLogic Server): 상용 AP 서버

1. 웹로직에는 리디렉션용 플러그인이 있어서 웹 서버에 구현
2. 세션 정보는 접속된 AP 서버를 기본으로 하고 보조 세션을 복사해둔다(복제)
3. 이 서버 정본는 쿠키에 저장돼서 클라이언트에게 반환
4. 클라이언트가 재접속할 때는 웹 서버에 구현된 리디렉션용 플러그인이 기본 서버를 판별해서 해당하는 AP 요청을 리디렉션

장애가 발생하면?

쿠키 정보를 가지고 보조 세션 정보에 접속해서 세션이 계속 유지됨

세션 정보를 복제하면 이를 위한 메모리나 네트워크 리소스 소비량이 늘어나기 대문에 주의가 필요

 

• DB연결 이중화

→ AP 서버는 3계층형 시스템의 중간에 위치하고 AP 서버에는 DB 서버에 접속 시 사용할 연결을 사전에 여러 개 생성해 두는 기능이 있음(⇒ 연결 풀링 Connection Pooling → 웹로직의 데이터 소스를 설정해서 이용)

• 원래 데이터 소스는 여러 연결을 만들어서 데이터베이스 처리를 병렬로 실행할 수 있게 하는 구조
• 애플리케이션은 연결 해제를 하지 않아서 연결 생성 및 해제 시에 걸리는 시간이나 리소스가 필요 없어서 고속으로 처리가 가능

장애가 발생하면?

• 웹로직이 감시에 두 번 실패하면 연결을 일단 끊은 후 재접속
• 연결이 모두 사용 중인 경우는 설정 최댓값까지 연결 수 늘리고 최댓값을 초과한 요구가 오면 일정 시간 대기
• 연결 풀링 설계 방침
  • 최솟값과 최댓값을 동일하게 설정
  • 방화벽 유무 확인

7.6 DB 서버 이중화

• 서버 이중화(액티브-스탠바이)
  • 액티브-스탠바이형의 클러스터(Cluster) 구성(고가용성 구성-HA(High Availability))
• 서버 이중화(액티브-액티브)

7.7 네트워크 장비 이중화

• L2 스위치 이중화
• L3 스위치 이중화
• 네트워크 토폴로지

7.8 사이트 이중화

• 사이트 간 이중화

7.9 감시

• 생존 감시
• 로그(에러) 감시
• 성능 감시

7.10 백업

• 시스템 백업
• 데이터 백업