서버/인프라를 지탱하는 기술 1장

다중화의 기본

• 장애가 발생해도 예비 운용 장비로 계속 동작하는 것

다중화의 본질

• 어떤 장애가 발생할 수 있는지 정의
• 장애를 대비해 예비 장비를 준비
• 장애 발생시 교체한다

라우터 장애 대응

• 예비 장비를 하나 더 둔다
• 설정은 현재 운용 장비와 동일하게 해둔다
• 보통 사용하지 않고 장애 발생시 연결한다
• 사용하지 않아서 cold standby

웹서버 장애 대응

• 웹사이트 경우 꺼둘 수 없다
• 항상 켜둬야 한다
• Hot standby

장애극복

• VIP (virtual IP Address) 인계

VIP

• 자신의 IP 주소와 별개로 IP를 둔다
• 자신의 IP주소를 변경하는게 아니라 VIP를 인계한다

장애검출

• health check로 장애 검출 해야 한다
  • ICMP
    • 가볍게 echo로 확인
    • 웹서비스가 다운된 경우 모른다
  • 포트 감시
    • TCP로 접속해서 확인해본다
    • 웹서비스 다운은 감지할 수 있다
    • 에러 반환하는지 확인할 수 없다
  • 서비스 감시
    • http 요청을 보낸다 (healthcheck api)
    • 서버 부하 주의

웹서버의 헬스체크

• HTTP 요청을 보내서 응답이 있는지 확인한다

라우터의 헬스체크

• 인터넷에 접속 가능한지 확인해본다
• 라우터가 패킷을 전송가능한지 확인해볼 수 있다
• = 웹서버가 인터넷과 통신 가능한지

IP주소를 인계하는 원리

• LAN에서 MAC 주소를 사용해서 통신한다
• MAC 주소를 얻기 위해 ARP 프로토콜을 이용한다
• ARP: IP주소 지정해서 MAC 주소를 조회하기 위한 프로토콜 (IP주소 지정한다는게 뭐지)
• 한번 얻은 MAC주소는 ARP 테이블에 캐싱
• gratuitous ARP로 내 IP와 MAC 주소를 알려준다 (갱신할 수 있다)

서버를 효과적으로 활용하자

• 예비 운용장비를 대기시켜두는 건 낭비이다
• 로드 밸런스로 여러 대의 서버에 분산시키자

웹 서버의 다중화 (DNS)

DNS 라운드로빈

• DNS로 하나의 서비스에 여러 대의 서버로 분산시킬 수 있다
• xxx.com으로 접근시 x.x.x.1, x.x.x.2 서로 다른 ip 반환

단점

• 서버 수만큼 글로벌 주소가 필요
  • a, b, c서버가 있으면 x.x.x.1, x.x.x.2, x.x.x.3이 필요
• 균등하게 분산되는 건 아님
  • 프록시 서버에 ip변환이 캐싱된다
• 서버가 다운 되더라도 검출하지 못한다
  • 죽은 걸 확인하지 못하고 부하 분산한다

DNS 라운드 로빈의 다중화 구성 예

• 웹 서버가 죽으면 VIP를 정상인 서버로 인계한다 (사진 참고)

웹 서버의 다중화 (IPVS)

DNS 라운드 로빈과 로드 밸런서의 차이

• DNS는 웹서버마다 다른 글로벌 주소를 할당해야 한다
• 로드밸런서는 하나의 IP주소 요청을 복수의 서버로 분산 가능
  • 로드밸런서는 클라와 서버 사이의 중계역할을 한다
  • 클라이언트 - 로드밸런서 - 서버
  • 마치 자신이 웹서버인 것처럼 작동한다
• 헬스체크가 성공한 서버를 성공한다
  • DNS처럼 죽은 서버에 부하 분산하지 않는다
• 로드밸런서는 비싸다… 불안감이 도입장벽

IPVS

• 리눅스는 라우터로 이용 가능하다
• IPVS라는 부하 분산 기능을 제공하는 모듈이 있다

로드밸런서의 종류와 IPVS의 기능

• L4 스위치 (일반적) IPVS
• L7 스위치

스케줄링 알고리즘

• 어떻게 부하를 분산할 것인가?
  • RR: 균등하게 분산
  • WRR (weighted): 가중치로 분산 비율
  • IC (least connection): 접속수가 가장 적은 서버 (보통 이걸로 한다)
    • 멘토님: 트레픽이 많을 경우 새로 띄운 서버에 요청이 엄청 많이 올 수 있다… → 그럼 죽음… → 또 살림…… (슬픈경험담) :cry:
    • 이럴 경우 RR이 좋을 수 있다
  • WLC (weighted): lc + 가중치
  • SED (shortest expected delay): 가장 응답속도가 빠른 서버, 속도 측정 아님, 접속수가 가장 적은 서버 (healthcheck가 가장 빠른거)
  • NQ (never queue): sed와 동일하지만 active 접속수가 0인 서버 최우선 선택 (SED와 비슷하지않나?)

IPVS 사용하기

• keepalived
• 설정파일 내용에 따라 IPVS 가상 서버를 구축한다

L4스위치와 L7스위치

• L4
  • TCP헤더 등의 프로토콜 헤더의 내용으로 분산시킬 곳 결정
  • 클라이언트가 리얼서버와 통신
• L7
  • 애플리케이션 계층의 내부까지 분석해서 분산시킬 곳을 결정
  • TCP 세션을 전개
  • 클라이언트 ↔ 로드밸런서, 로드밸런서 ↔ 리얼서버
  • 두 가지 TCP 세션을 전개
  • (하나도 이해 안 됨 TCP 세션이 뭐지?)
  • 3way, 4way handshake
• 결론
  • 성능을 추구하면 L4
  • 우연한 설정을 하고자 하면 L7

L4스위치의 NAT 구성과 DSR 구성

• NAT 구성으로 이용할 수도 있지만 더 좋은 성능을 위해 DSR 구성을 취할 수 있다
• NAT (Network Address Translation)
  • 클라이언트 패킷의 수신지 주소를 변경해서 리얼로 전송
  • 응답 패킷을 받아서 ip 주소를 되돌린다
• DSR (Direct Server Return)
  • ip주소를 변경하지 않고 수신 패킷 그대로 리얼로 전송
  • 높은 트래픽인 경우 DSR 권장
  • 다만 리얼 서버가 글로벌 주소를 처리할 수 있어야 한다
    • DSR로 변경해서는 부하분산은 할 수 없다
    • 루프백 인터페이스에 가상서버 IP를 할당
  • 멘토님 의견: 10년 전 이야기라 ip가 풍족할 때이다

동일 서브넷인 서버를 부하분산할 경우 주의사항

• 동일 서브넷에서 NAT을 사용할 수 없다
• 메일 패킷 예시 (이해못함)
  • NAT 구성은 목적지 ip를 변경함
  • 하지만 변경된 경우
  • “수신측인 192.168.0.1은 동일 서브넷인 IP 주소이므로 로드밸런서로 되돌아가지 않고 웹 서버로 직접 송신된다”
  • “NAT에 의해 변경된 IP 주소를 원래대로 되돌릴 수가 없으므로 정상적으로 통신할 수 없게된다”
  • → DSR 구성으로 하면 좋다

라우터 및 로드밸런서의 다중화

다중화란

• 웹 서버의 다중화는 이제 가능
• 로드밸런서가 고장나면 서비스가 모두 정지해버린다

다중화 프로토콜 VRRP

• VRRP
  • HSRP 프로토콜 기반
  • 벤더에 의존하지 않는 다중화 프로토콜
• keepalive로도 VRRP 이용 가능

VRRP의 구조

• VRRP의 마스터 노드는 VRRP패킷을 멀티캐스팅 주소로 보낸다
• VRRP패킷: Advertisement라고 함 (광고한다는의미)
• 백업 노드가 VRRP 패킷을 수신하지 못하면 마스터 노드가 다운된 것으로 판단
• 백업 노드는 수신 후 다시 마스터 노드로 송신을 한다

가상 라우터 ID

• 모든 VRRP 패킷이 동일한 주소로 보낸다
• VRRP에는 가상 라우터 ID가 존재
• 가상 라우터 ID로 VRRP끼리 구분 가능하다

우선순위

• 백업 노드가 2개 이상일 때 어떤 백업 노드가 마스터 노드가 될 것인가
• VRRP는 우선순위가 있다
• VRRP가 수신을 안 하면 송신을 시작한다
• 자신보다 높은 우선순위를 만나면 마스터 승격을 포기한다 (ㅋㅋ)

선점형 모드

• 자신이 우선순위가 높으면 마스터 뺏음
• 선점형 off: 자신의 우선순위가 높더라도 뺏지 않음

가상 MAC 주소

• VPPR 장애 극복시 IP주소 뿐만 아니라 MAC주소도 함께 인계
  • IP만 인계할 경우
    • ARP 테이블을 변경해줘야 한다
    • gratuitous ARP로 변경
    • ARP가 도달하지 않을 수 있다
    • 그럴 경우 캐시 갱신 전까지 통신 중단된다
  • MAC주소도 함께 인계해야 한다

keepalived의 구조상 문제

• MAC주소를 이용하지 않도록 구현되어 있다
• 마스터로 승격된 직후에는 통신이 안 될 수 있다
• grap_master_delay로 일정 시간 기다린다
• 이후 gratuitous ARP 송신되도록 조정가능