Chapter 13. 다중성 확보, 시스템 안정화 (강의33 ~ 35)

강의33. 다중성 확보

100%가동률에 약간 못 미치지만 100%를 목표로 해야 한다. SPOF(Single Point of Failure)단일 장애점을 제거하는 것이 중요하다.

다중성 확보 - AP서버

AP서버에서의 확장성을 생각하는 방식과 마찬가지로 서버 여러 대를 늘어놓는 게 기본이 된다. 1, 2대 정도 정지하더라도 충분히 처리할 수 있도록 처리능력을 확보해두는 것이다. 서버는 다양한 이유로 멈추는데, 이에 대한 대응으로 로드밸런서로 페일오버(장애극복), 페일백(정상복귀)하여 고장 난 서버를 자동적으로 분리하고, 서버가 복구되면 원상태로 복귀시키는 작업을 수행한다. 로드밸런서는 서버에 대해 주기적으로 헬스체크를 하며, AP서버나 DB서버가 살아있는지 여부를 판정하고 있다.

다중성 확보 - DB서버

DB서버도 마찬가지로 여러 대 나열해서 1, 2대 정도 정지하더라도 충분한 처리능력이 있도록 하는 것이 중요하다. 또한 Master의 다중화도 수행한다. ‘하테나’에서는 MySQL의 멀티 마스터를 사용하고 있다. 쌍방으로 replication, 즉 서로가 서로의 슬레이브가 되는 상태로 하고, 쓰기작업이 있으면, 같이 복사하는 형태로 둔다. 하지만 전달하는데 밀리 초 단위로 차이로 보면 데이터가 일치하지 않는 상태가 항상 존재한다. 엔터프라이즈의 경우에는 동기적으로 처리함으로써 대처한다. 반대편에 정확히 다 쓰인 이후에 클라이언트에 결과를 반환하도록 할 수 있다.

 

(추가공부) 오라클에서는 다중화를 위한 오라클 RAC(real application cluster)가 있다.

RAC란 여러 인스턴스에서 하나의 DB로 연결할 수 있도록 하고, 하나에서 문제가 발생한 경우 다른 인스턴스로 연결시켜준다. 캐시를 이용해서 데이터의 정합성이 유지되도록 해준다.

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

‘하테나’에서는 이미지 파일과 같은 미디어 파일을 저장하기 위한 분산 스토리지 서버로 MogileFS를 사용한다. 대량의 파일을 보존할 수 있는 확장성과 일부 서버가 다운되더라도 정체 장애가 되지 않도록 다중성을 확보할 수 있다. 여기에는 여러가지 방법이 있다. 메타데이터와 파일데이터를 각각 관리해주는 방식. 1대당 용량을 너무 높이게 되면 그 안에 저장된 파일수가 너무 많아져서 읽기나 쓰기 I/O 성능이 병목이 되어 100% 용량을 다 사용할 수 없게 되는 경우도 발생하고 있다. 이 부분에 대한 밸런스에도 주의를 기울일 필요가 있다.

강의34. 시스템 안정화

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

안정성과 자원효율 간에는 상반관계가 있다. 또한 안정성과 속도도 그렇다.

빠듯할 정도로 메모리를 튜닝해서 8GB중 7.5GB를 사용하도록 설정해두고 있다고 하자. 이 때 갑자기 처리해야 할 데이터가 늘어나거나 애플리케이션에 버그가 있거나 메모리 누수가 발생해서 소비 메모리가 갑자기 늘어나면 곧바로 스왑을 사용하기 시작해서 성능이 저하되면서 서비스 장애가 일어난다.

또는 CPU를 한계에 다다를 정도로 사용하게 되면 서버 대수를 줄일 수 있어서 비용면에서는 유리하지만, 장애가 발생하면 전체적으로 처리능력이 부족해져서 요청을 다 처리하지 못하고 막혀서 장애가 되는 경우가 종종 발생한다. 그에 대한 대책으로 CPU든 메모리든 7할정도만 사용하는 등 어느 정도 여유를 가질 수 있게 설계를 해야 한다. 앞에서 말한 것처럼 1, 2대 정도는 고장나도 정상적으로 돌아갈 수 있어야한다.

시스템의 불안정 요인

1. 기능추가, 메모리 누수

새로운 기능을 추가하면 그 기능이 예상보다 무거워서 전체적인 부하가 늘어나 서비스가 다운되는 일이 발생한다. 메모리 누수도 상당히 불안정한 요인이다.

 

2. 지뢰

특정 URL이 읽히면 아무리 시간이 지나도 응답이 오지 않아서 장애의 원인이 되는 현상을 말한다. 무한루프에 빠지거나 메모리를 비정상적으로 소비하면서 폭주해서 시스템의 불안정으로 이어지는 경우가 있다. 어디에 지뢰가 있는지 확인할 때는 기술자다운 테크닉이 필요하다.

 

3. 사용자의 액세스 패턴

예전에는 종종 인기가 많은 사이트에 링크를 걸어 두면 그 사이트 사용자가 집중적으로 접속해서 다운되는 경우가 생겼다. 이러한 액세스 변동도 흡수할 수 있도록 구성해 두는 게 중요하다. 정형적으로 Squid같은 캐시 서버를 사이에 추가해서 게스트의 경우 캐시를 반환할 수 있도록 해 두는 방법이 있다. 캐시를 사용하면 리소스를 거의 사용하지 않고 요청에 대한 응답을 반환할 수가 있으므로, 제대로 캐싱해서 게스트의 집중적인 액세스를 잘 처리할 수 있도록 해 두는 것이 효과적

 

4. 데이터 증가

당초 예상했던 데이터보다 늘어나서 이것이 전체적인 부하의 증가로 이어져서 시스템이 불안정해지는 경우가 있다. 이럴 때에는 DB설계를 변경하거나 데이터를 압축하는 등의 적절한 조치를 취하는 것이 매우 중요하다.

 

5. 외부연계 추가

광고 관련 웹 PAI나 Amazon 웹 API 등을 새롭게 추가하는 등 외부의 새로운 API를 연결하는 것을 말한다. 외부시스템이 다운되어 있을 때 덩달아서 다운되는 형태가 되기 쉬우므로, 이러한 외부 노이즈에 견딜 수 있는 시스템을 구현하는 것도 중요하다.

 

6. 메모리, HDD장애, NIC장애

메모리나 HDD, 네트워크 장애는 일상적으로 발생한다. 로드밸런서에서 적절한 항목에 대해 헬스체크를 해서 하드웨어장애로 이상이 생겼을 때 바로 문제가 발생한 서버로 요청이 전송되지 않도록 할 수 있다. 이와 관련한 시스템의 불안정 요인을 웬만큼 고려해서 설계하고 점차 개선해가는 것이 인프라 관련 업무에서 중요한 부분

 

강의35. 시스템 안정화 대책

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

실제 대책을 취하고 있는 방식은 크게 두 가지로, 버퍼의 유지와 불안정 요인의 제거다.

시스템 수용능력의 7할을 상한선으로 해서 이를 넘어서면 서버를 추가하거나 메모리를 늘리는 등 임계치를 설정하는 방식을 취하고 있다. 불안정 요인을 제거하는 것은 SQL 부하대책, 메모리 누수 줄이기, 비정상 동작 시 자율제어를 들 수 있다.

이상 동작 시의 자율제어

자동 DoS판정 ->특정 IP로부터 다수의 요청이 오면 당분간 403을 반환해서 액세스를 차단하는 등의 비정상 액세스에 대처

자동 재시작 -> 메모리 누수로 인해 스왑을 사용하기 시작하면서 부하가 증가하여 성능이 떨어질 때,  어느 정도 리소스를 지나치게 사용했다 고 판단했다면 웹 서버를 재시작 한다.

자동 쿼리제거 -> DB 서버에 어떤 쿼리가 실행되고 있는지를 파악해서 어느 정도 이상으로 시간이 경과한 쿼리를 강제적으로 KILL하는 것

자율적으로 안정화하는 방향으로 시스템을 제어하도록 한다. 하지만 이거는 잠정적인 해법이고 본질적인 해법이 아니라는 것을 염두에 두고 코드를 작성하는 것이 중요하다.