다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌


  • 가동률을 100%로 끌어올려 시스템이 멈추지 않도록 하는 것
  • 여기서 중요한 것은 SPOF (Single Point of Failure) 단일장애점을 제거하는 것이다.

[강의33] 다중성 확보

다중성 확보 - WAS 서버

  • 중요한 것은 여러대의 서버가 있을 때 몇대의 서버가 정지하더라도 서비스가 정상적으로 처리될 수 있는 상태를 만드는 것이다.
  • 로드밸런서에서 failover를 처리할 수 있다.
    • 고장난 서버를 분리시키고 정상적인 서버로 요청을 보내는 것
    • 연결된 서버들에 대한 주기적인 헬스체크
  • failback
    • 고장난 서버를 복구하고 다시 복귀시키는 것

다중성 확보 - DB 서버

  • 마찬가지로 여러대의 DB 서버가 있을 때 몇대가 고장나더라도 요청을 정상적으로 처리할 수 있어야 한다.
  • Master도 다중화 하면 좋다 → 하지만 어렵다.
    • 책의 예시에서는 멀티 마스터를 사용하고 있다.
      • 양쪽이 서로 slave 관계이기 때문에 한쪽이 쓰기작업을 하면 다른 한쪽으로 전달 (양쪽이 서로 그렇게 작용)
    • MySQL에서는 데이터가 전달되기 까지 몇 밀리초만큼의 딜레이가 있을 수 있다.
      • 엔터프라이즈에서는 이 부분이 굉장히 중요하게 작용하기 때문에 동기적으로 replication을 수행하여 슬레이브까지 쓰여진 이후에 클라이언트에게 결과를 반환한다.
    • 동기가 맞지 않은 리스크에 대해서는 어느정도 받아드리고 더 중요시하고 싶은 성능을 향상시키는 태도가 중요하다.

멀티 마스터

  • 상호 간에 VRRP (Virtual Redundancy protocol) 로 감시하고 있으며 한쪽이 분리하면 본인을 Active 마스터로 승격시킨다.


    이미지 출처: 대용량 서비스를 지탱하는 기술

  • 2대의 Master서버가 하나는 Active 하나는 Standby로 구성되어 있다.

  • 한쪽 서버가 다운되면 다른 쪽이 Master로 승격된다. 다운된 서버가 복구되면 다시 원래 역할로 돌아온다.

  • 외부에서 Active 마스터 서버를 알고 있기 위해서 가장 IP를 부여한다.

    • 즉 2대의 서버에 부여된 IP 이외에 Active 한 서버에 부여되는 추가 가상 IP가 있는 것이다.
    • 따라서 동일한 IP 주소로 계속 요청을 보내기 때문에 마스터 서버간의 전환이 외부에서는 보이지 않는다.

다중성 확보 - 스토리지 서버

  • 분산 파일 시스템을 활용할 수 있다.
  • 큰 파일을 분할하여 저장하기도 하고, 하나의 파일을 하나로 취급하여 여러 곳에 분산하여 저장한 메타 데이터를 관리하는 형태로 분산하기도 한다.

[강의34] 시스템 안정화

시스템 안정화를 위한 상반관계

  • 시스템 안정화는 자원효율과 상반관계이다.
    • 메모리를 빠듯하게 튜닝했을 때 장애가 일어날 수 있다.
    • CPU를 한계에 다다를 정도로 사용하면 장애가 발생할 수 있다.
      • 서버의 대수를 줄일 수 있지만, 서버 중 1대가 장애가 나면 나머지 CPU에 여유공간이 없어서 처리능력이 부족해져서 요청을 처리하지 못하게 된다.
  • 시스템 안정화는 속도와 상반관계이다.
  • 안정성을 확보하기 위해 CPU와 메모리에 여유공간을 주고 사용해야한다.

시스템 불안정 요인

기능추가, 메모리 누수

  • 새로운 기능이 무거워서 부하가 일어나 서버 다운
  • 메모리 누수가 시간이 지날수록 쌓여서 스왑을 사용하며 부하가 증가

지뢰

  • 특정 url을 읽으면 응답이 오지 않아서 장애의 요인이 되는 것
  • 무한루프나 메모리 누수인 경우가 많다 → 비정상적으로 메모리를 소비하는 것
  • 애초에 지뢰를 없애는 것도 중요하지만 그것을 어렵기 때문에 밟더라도 치명적인 문제가 되지 않도록 설계하는 것이 중요하다.

사용자 액세스 패턴

  • 어떤 특정 사이트에 집중적으로 사용자 접속이 일어나서 다운되는 경우

데이터량 증가

  • 데이터 증가로 부하가 일어나는 경우

외부연계 추가

  • 외부 모듈이 다운되는 경우
  • 그렇더라도 서비스가 영향을 받지않고 충분히 동작하도록 설계하는 것이 중요

메모리, HDD 장애, NIC 장애

  • 하드웨어가 능력의 저하의 원인이 될 수 있지만 치명적인 문제가 되지 않도록 하는 것이 중요하다.
  • 헬스체크로 미리 체크하여 문제가 생긴 경우 요청을 우회하는 것이 중요하다.

[강의35] 시스템 안정화 대책

실제 안정화 대책 - 적절한 버퍼 유지와 불안정 요인 제거

  • 적잘한 버퍼 유지를 위해 7할 정도로 운용을 한다. 즉 70%를 상한선으로 정하여 넘어가는 경우 서버를 추가하거나 메모리를 추가하는 것
  • 불안정 요인을 제거하기 위해 SQL 부하대책, 메모리 누수 줄이기, 비정작 동식 자율제어 등을 한다.

SQL 부하 대책

  • 부하나 높아지는 쿼리를 날리지 않도록 하는 것이 중요하다.
  • 개발자는 본인이 보내는 쿼리를 파악하여 부하가 높은 쿼리를 발행할 경우 그 용도의 DB를 따로 준비하여 그곳으로 SQL를 날리도록 한다.

이상 동작 시 자율제어

  • 자동 DoS 판정

    • 다수의 요청이 오는 경우 에러 처리

  • 자동 재시작

    • 리소시를 지나치게 사용했다면 서버를 재시작한다.

  • 자동 쿼리제거

    • 소요시간이 긴 SQL을 Kill 하도록 함
    • 특정 시간마다 체크하여 소요시간이 긴 쿼리를 kill 한다.

  • 자율제어를 지나치게 잘 해놓으면 문제가 있어도 어플리케이션이 어느정도 잘 동작하게 된다. 이러면 문제를 알아채지 못해서 본질적인 문제가 해결되지 않을수도 있다는 것을 기억해야한다.

  • 자율제어는 잠정적인 해법이다.