[대규모 서비스를 지탱하는 기술] 다중성 확보, 시스템 안정화

대규모 서비스를 지탱하는 기술

대규모 서비스를 지탱하는 기술

---

다중성 확보

다중화를 위해서 가장 중요시하는 것은 SPOF(Single Point of Failure) 즉, 단일 장애점을 제거하는 것이다.

• 한 곳에 장애가 나면 시스템이 멈춰버리는 부분을 가능한 한 없앰으로써 가동률을 높이도록 함.

 

AP 서버 다중성 확보

AP 서버에서는 확장성을 생각하는 방식과 마찬가지로 서버 여러 대를 늘어놓는 것이 기본이 된다.

• 중요한 것은 1대나 2대 정도 정지하더라도 충분히 처리할 수 있도록 처리 능력을 확보해두는 것이다.

 

서버는 다양한 요인으로 멈춘다. 이에 대한 대응으로

• 로드밸런서로 페일오버(failover, 장애극복), 페일백(failback, 정상 복귀)하여 고장 난 서버를 자동적으로 분리하고, 서버가 복구되면 원 상태로 복귀시키는 작업을 수행하고 있다.
• 페일오버는 자동으로 분리하는 것, 페일백은 정상이 되면 복귀시키는 처리를 의미한다.
• 로드밸런서는 서버에 대해 주기적으로 헬스체크를 하고 있으며, 이는 다중화에서 가장 기본적인 부분이다.

 

DB 서버 다중성 확보

DB 서버도 마찬가지로 서버를 여러 대 나열해서 1, 2대 정지하더라도 충분한 처리능력이 있도록 해주는 것이 중요하다.

마스터 다중화는 어려움. 마스터 다중화를 위해서 멀티 마스터라는 방법을 사용할 수 있음.

 

멀티 마스터

• 멀티 마스터는 쌍방으로 레플리케이션, 서로가 서로의 슬레이브가 되는 상태로 해두고 한쪽에 쓰기 작업을 하면 다른 한쪽으로 전달하고 반대쪽에 쓰더라도 다른 쪽으로 전달하는 양방향 레플리케이션 방법이다.
• 다만 MySQL은 실제로 한쪽에 쓰기작업을 하면 반대쪽으로 전달되는 흐름이기 때문에 약간의 지연이 존재.
• 엔터프라이즈에서는 이 부분에 대한 대책으로 레플리케이션을 동기적으로 처리함으로써 대처 (슬레이브까지 쓰였다는 것을 확인한 다음에 클라이언트에 결과를 반환)
• 이 경우 동기는 확실하게 담보되지만 성능면에서 큰 손실이 발생함.
• 웹 서비스에서는 동기가 맞지 않는 리스크에 대해서 어느 정도 받아들임으로써 성능을 중시하는 경우가 많음.

 

멀티 마스터

페일오버 동작

• 상호 간에 VRRP(Virtual Router Redundancy Protocol)이라는 프로토콜로 감시.
• VRRP에 의해 한쪽이 분리된 것을 알게 되면 자신이 Active 마스터로 승격한다.

 

멀티 마스터 구성

• 서버는 기본적으로 2대 있으며, Active/Standby 구성을 하고 있다.
• 기본적으로 항상 Active 쪽만 쓰기 작업을 하는 구성으로, Active 서버가 다운되면 Standby였던 쪽이 Active로 승격해서 새로운 마스터가 되고, 다운된 서버는 수작업으로 복구시켜서 다시 Standby로 되돌리던가 다시 원래의 구성으로 되돌리는 방식.
• 외부에서 어느 쪽 서버가 Active인지 판단하기 위해 Virtual IP를 사용한다.
• 실제 두 서버가 1(Active), 2(Standby)라는 주소를 가지고 있다면 새롭게 3이라는 가상 주소를 Active(1) 쪽에 할당. 이런 식으로 구성함으로써 AP 서버 입장에서는 마스터 전환이 은폐되는 효과를 얻을 수 있다.

 

스토리지 서버 다중성 확보

분산 파일 시스템

• 분산 파일 시스템을 사용함으로써 대량의 파일을 보존할 수 있는 확장성과 일부 서버가 다운되더라도 전체 장애가 되지 않도록 다중성을 확보할 수 있다.

 

시스템 안정화

---

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

시스템을 안정화시키기 위해 상반되는 부분이 몇 가지 있다.

• 안정성과 자원 효율
• 안정성과 속도

 

메모리나 CPU를 한계에 이를 때까지 사용하면 장애가 발생할 수 있다.

• 메모리는 7할 정도까지만 사용한다거나 CPU를 7할 정도까지만 사용하는 등 어느 정도 여유를 가질 수 있게 설계하는 것이 중요.
• 한계에 다다를 정도로 사용하지 않고 어느 정도 버퍼를 유지하고 버퍼가 부족해지면 새로운 서버를 추가하거나 구성을 약간 변경해서 전체적인 사용량을 줄이는 대책을 계속해감으로써 안정성을 확보할 수 있다.

 

시스템의 불안정 요인

기능 추가, 메모리 누수

• 애플리케이션, 서비스 레벨에서 기능을 추가하면 그 기능이 예상보다 무거워서 전체적인 부하가 늘어나 서비스가 다운되는 가능성이 있다.
• 메모리 누수의 경우, 메모리가 조금씩 누수되어 가는데, 버퍼가 너무 작으면 시간이 지남에 따라 버퍼를 다 사용해서 스왑을 사용하기 시작해서 부하가 증가하는 것을 알 수 있다.

 

사용자의 액세스 패턴

• 캐시 서버를 사이에 추가해서 게스트 사용자의 경우는 캐시를 반환할 수 있도록 해두는 방법이 존재.

 

데이터량 증가

• 예상했던 데이터량보다도 늘어나서 전체적인 부하의 증가로 이어져서 시스템이 불안정해지는 경우가 존재.
• DB 설계를 변경해서 전체적인 레코드 수의 증가를 억제해 데이터량의 규모를 적정한 수준으로 줄이는 대책이 존재. (예를 들어 별 1000개를 달면 1000개의 레코드를 추가하는 방식에서, 1000개를 추가했다는 정보를 가진 레코드를 1개만 추가하는 방식으로 변경)

 

외부연계 추가

• 외부연계를 늘리게 되면 외부 시스템이 다운되어 있을 때 덩달아서 다운되는 형태가 되기 쉬우므로, 외부시스템이 다운되거나 다운되지는 않더라도 부하가 높을 때에도 연계하고 있는 서비스가 영향을 받지 않도록 충분한 속도로 동작하거나 외부로부터 데이터를 가져올 수는 없지만 그 부분만 작동을 안 하고 다른 부분을 출력할 수 있도록 하는 등 외부 노이즈에 견딜 수 있는 시스템을 구현하는 것도 중요.

 

메모리, HDD 장애, NIC 장애

• 메모리나 HDD, 네트워크 장애는 일상적으로 발생한다.
• 하드웨어의 능력이 저하되더라도 문제가 되지 않도록 해두는 것이 중요하다.
• 예를 들어 로드밸런서에서 적절한 항목에 대해 헬스체크를 해서 하드웨어 장애로 이상이 생겼을 때 바로 문제가 발생한 서버로 요청이 전송되지 않도록 할 수 있다.

 

시스템 안정화 대책

---

적절한 버퍼 유지와 불안정 요인 제거

적절한 버퍼 유지를 위해 한계의 7할 운용을 수행.

• 시스템 수용 능력의 70%를 상한선으로 해서 이를 넘어서면 서버를 추가하거나 메모리를 늘리는 등 임계치를 설정하는 방식을 취한다.

 

불안정 요인 제거

• SQL 부하 대책, 메모리 누수 줄이기, 비정상 동작 시 자율제어 등을 들 수 있다.
• SQL 부하는 부하가 높아질 듯한 SQL을 발행하지 않도록 하는 것은 시스템을 안정화시키기 위해 매우 중요.
• 배치 SQL의 영향으로 시스템이 무거워지는 경우, 배치용 DB를 준비해두고 거기에서 처리하도록 해서 사용자가 일반적으로 사용하는 DB와는 부하를 분리시켜 두는 것이 효과적이다.

 

이상 동작 시의 자율제어

자동 DOS 판정

• 1시간에 특정 IP주소로부터 다수의 요청이 오면, 당분간 403을 반환해서 액세스를 자율적으로 차단함으로써 비정상 액세스에 대처.

 

자동 재시작

• 예를 들어 어느 정도 리소스를 지나치게 사용했다고 판단했다면 웹 서버를 재시작한다.
• 또는 가상화되어 있는 호스트에서는 가상화되어 있는 OS별로 재시작을 한다.

 

자동 쿼리 제거

• 최종 수단에 가까운 방법으로 소요시간이 긴 SQL을 KILL 하는 방법도 존재.