인프라 기초지식 11. 인프라 운영 part.1

장애대응 

하드웨어는 언젠가 반드시 고장이 난다는 생각 때문에 가능한 서비스를 멈추지 않도록 하는 방향으로 진화했다. 예를 들어 서비스를 가동한 채로 이중화된 부품 중 고장난 부품을 교환할 수 있는 '핫스왑' 기술이나 이상을 감지하면 자동으로 보정하는 'ECC 기능' 은 하드웨어의 가용성을 높여주는 기술의 한 예다. 그 밖에도 하이엔드 서버에서는 업체가 실시간으로 감시하고 있다가 경고를 감지하면 자동으로 업체의 유지보수팀이 달려가 수리해주는 서비스도 제공된다.

또한 소프트웨어는 사람이 만드는 것이므로 아무래도 버그가 섞여 있기 마련이다.

실제 환경에 적용하기 전에 충분히 테스트하긴 하지만, 아무래도 테스트를 하지 못한 조작이나 혹은 악의적인 접근으로 시스템에 이상이 발생할 수도 있다.

인프라 엔지니어 입장에서는 명확히 시스템이 멈추는 등 눈에 보이는 시스템 장애는 알 수 있지만, 버그에 의한 사소한 오류는 알 수 없을 때가 많다. 결국 일반 사용자로부터의 문의나 개발자 자신이 장치한 감시 시스템에 의해 오류를 발견하는 예가 대부분이다.

인프라 엔지니어에게 감시 솔류션은 장애 감지를 위해 특히 중요한 도구다. 장애를 빠르고 확실하게 감지하기 위해서는 감시 솔루션 없이는 불가능하다. 감시 솔루션을 신중하게 선택하고 모든 보유 기기에서 일어날 수 있는 온갖 장애 패턴을 모두 확실히 감지할 수 있도록 엄격하게 설정하다.

병목을 해결한다.

일반적으로 IT 시스템에서는 병목이 한 군데만 있어도 시스템 전체의 응답( 응답 속도 ) 에 악영향을 미친다, 시스템의 병목을 제거하는 과정에서 중요한 것은 국소적인 문제에 사로잡히지 말고 시스템 전체의 관점에서 병목을 검토하는 것이다.

부분적으로 문제를 해결했다고 해도, 다른 곳에 병목이 일어나는 부분이 있으면 시스템 전체의 응답은 개선되지 않는다. 예를 들어 웹 서버 부족 문제와 데이터 베이스 서버의 메모루 부족 문제가 동시에 일어났을 때, 아무리 데이터베이스 서버의 메모리를 증설하더라도 웹 서버 부족이 해결되지 않는 한 시스템 전체의 응답 속도는 개선되지 않는다.

특히 접속이 급증하는 IT시스템일 때는 병목 대책을 계획적으로 세울 필요가 있다. 접속수가 급증하는 IT시스템에서 아무런 대응을 하지 않으면, 거의 모든 하드웨어자원이 동시에 고갈되는 상황이 일어난다. 일단 그런 상황이 되면 땜질식 대응은 거의 불가능하고, 오랫동안 시스템을 멈추고 전체적으로 시스템을 확장한 다음 서비스를 재개해야 한다. 그렇게 되지 않기 위해서도 앞으로 접속 수가 급증할 것 같다고 판단되면 단계적으로 실생할 시스템 확장 계확을 세우면서, 그 뒤에서 계속 병목 해소 작업을 병행할 필요가 있다.

시스템에서 병목이 일어나기 쉬운 부분은 여러 갈래에 걸친다. 흔히 병목이 발생하는 부분은 다음과 같다.

- 코어 스위치의 수용량

- L2스위치의 수용량

- 웹서버의 메모리 부족

- 데이터베이스 서버의 CPU와 메모리 부족

- 데이터베이스 서버의 디스크 I/O

네트워크 장비의 병목을 해결한다.

자주 일어날 수 있는 네트워크 장비의 병목 조사 방법과 해결 방법을 설명한다.

- 각 포트의 물리 인터페이스의 속도가 트래픽을 감당하는가??

조사방법

1Gbps 인터페이스라면 실제 IN/OUT 트래픽이 각각 1Gbps 미만인가?

대책

서버를 분산해서 트래픽을 분산하거나 인터페이스를 더 빠른 것으로 바꾼다 ( 1Gbps -> 10Gbps 등)

- 네트워크 장비의 전송 능력에 한계는 없는가?

조사방법

패킷 드롭이 발생하지 않는가? 전송 능력 부족을 보이는 로그가 남아 있는가?

대책

가능하면 네트워크 장비를 상위 기종으로 교체하거나 캐시 메모리 추가 등을 시행한다

서버 장비의 병목을 해결

다음으로 자주 일어날 수 있는 서버 장비 병목의 조사 방법과 해결 방법을 설명한다

-프론트엔트 서버의 응답이 저하되었는가?

조사 방법

각 서버의 응답 시간을 정기적으로 가져와 극단적인 저하가 일어났는지 살펴본다. 혹은 사용자로부터 응답 속도에 관한 질문이 들어 왔는지 살펴본다.

대책

우선, 프론트 엔드 서버 문제인지 아니면 데이터 베이스 등의 백엔드 서버 문제인지 파악한다.

백 엔드 서버에서 CPU, 메모리, 네트워크, 디스크I/O의 실시간 이용 상황을 보고, 어느 하드웨어 자원이 과도하게 사용되면 백 엔드 서버 문제로 의심한다. 그렇지 않으면 프론트 엔드 서버 문제를 의심해, 마찬가지로 CPU, 메모리, 네트워크, 디스크I/O의 실시간 이용 상황을 보고 어느 하드웨어가 과도하게 사용되면 프론트 엔드 서버로 의심한다.

하드웨어 리소스를 많이 사용하는 서버를 파악하면 다음은 원인을 분석한다. 하드웨어 리소스가 정말 부족한 것인지, 애플리케이션의 문제인지, 그렇지 않으면 하드웨어 고장인지 판단한다. 하드웨어 리소스가 부족한 때는 다음 수단을 이용해서 증설한다

- CPU : CPU의 소켓 수( 물리 개수 ), 혹은 코어 수를 늘린다. CPU 수를 늘릴 수 없을 때는 속도가 빠른 CPU로 교체하거나 서버 자체를 상위 기종으로 교체하거나 서버수를 늘려 부하를 분산한다.

- 메모리 : 메모리 설치 용량을 늘린다.

- 네트워크 : 복수의 네트워크 인터페이스를 묶어 네트워크 대역을 늘려준다. 단, 네트워크 인터페이스를 한계까지 사용하는 서버는 네트워크뿐만 아니라 다른 하드웨어 리소스도 어느 정도 사용하고 있을 것이다. 그런 때는 서버 수를 늘려서 부하를 분산하는 편이 좋을 수도 있다.

- 디스크 I/O : 더 빠른 스토리지를 도입하거나 하드 디스크를 SSD와 엔터프라이즈 플래시 메모리 같은 고속 디스크로 교체하는 방법이 있다. 그렇게 디스크 I/O 부하가 높을 때는 하드웨어적인 대응으 곤란해지므로 여러대의 서버로 부하가 분산되게 프로그램을 수정하는 등 근본적인 대처가 필요해 진다.

디스크 I/O값이 클 때 의심해야 할 것

디스크 I/O값이 크다고 디스크가 병목이라고 단정하기 전에, 일단 하드웨어 고장 가능성도 의심해보자. 흔이 있는 사례로는 하드디스크에 불량 섹터가 있어서 그 부분을 회피하고자 평소보다 디스크 성능이 떨어지는 예가 있다. 또한 하드디스크가 고장이나서 핫스페어 디스크가 활성화되면서 RAID 재구성을 위해 일시적으로 디스크 I/O 부하가 올라갈 수도 있고, 혹은 RAID 컨트롤러의 고장으로 평상시와 다른 처리가 실행되고 있을 수도 있다.