개발과 서버 관리를 하다 보면, 장애가 발생하곤 합니다. 사실 아무리 잘 준비하고 관리를 한다고 해도 장애는 늘상 발생할 수 있습니다. 고객사로부터 장애 발생시 종단 간 테스트를 충분히 잘 해두었다면 장애가 발생하지 않아야 하는게 아니냐고 하시는 경우도 종종 있습니다. 그렇지만 End to End Test를 모든 경우에 해당되게 설계하는 것도 어렵고 대규모 서버 환경에서 이를 수행하는 건 더 어려운 일입니다.

장애는 늘 발생할 수 있습니다. 서버 관리 책임자로써 어플리케이션 문제부터 하드웨어 장애까지… 사실 장애는 늘 발생할 수 있다는 전제하에 어떻게 막을지보다는 어떻게 잘 극복할지가 관건입니다.

하드웨어 장애인 경우를 생각해보면, 문제가 된 서버를 빠르게 교체하고 동일한 작업을 수행할 수 있도록 준비해야 합니다. 하드웨어 장애시 스토리지 복사를 하는데만도 몇시간씩 걸리기 마련입니다. 스토리지 복사 후에도 어플리케이션 가동을 위해 Full Scan 등의 작업이 추가되면 복구되는 시간은 더 길어질 수 밖에 없습니다. 어플리케이션 재실행 등을 위해 클러스터 내 다른 노드들의 영향이 최소화하게 하는 부분도 함께 고려해야 합니다.

장애가 발생하고 복구할 때, 장애 동안 우회할 수 있는 장애 극복 상황도 고려를 해야 합니다. 직렬로 처리할 때 발생하는 시간을 줄이기 위해 병렬로 처리한다면 쓰레드를 얼마나 띄어야 하는지 머신 성능은 어떤걸 주안점을 가지고 선택해야 할지 고민해야 합니다.

한 고객사의 경우 특정 업무 수행시 디비 서버가 다운되는 일이 있습니다. 디버깅 과정에서 해당 작업이 정상적인 프로세스를 통한 작업이고, 서버 자원에 무리가 가지 않는 데이타 업데이트였음에도 데이타베이스 서버가 다운되는걸 발견하였습니다. 고객사에서는 답답함을 호소하고, 이런 장애로 인해 고객사 비즈니스에 마이너스가 되는걸 생각한다면, 정말 속이 상합니다.

실제 문제는 SQL 이슈였습니다. SQL의 Max allowed packet size가 초과되면서 데이타베이스가 다운되는 문제였습니다. 이런식의 디버깅 작업을 통해 서비스가 보다 안정화될 수 있을 것입니다.

어제도 고객사와 만나 대책 회의를 하면서 몇가지 운영 부분에 있어서 조치할 수 있는 부분과 시스템 업데이트 그리고 서버 장비 증설 등에 대해 논의를 하였습니다.

이 경우는 그나마 다행인게, 하드웨어 장애가 아니라서 서버 관리자가 문제를 인지 후 빠른 조치가 가능하지만, 이런 어플리케이션 단의 문제로 인해 서비스가 중지되지 않게 하기 위해서 고민이 많은 요즘입니다.

일단 별도의 테스트 인스턴스를 띄어 앞으로 Bulk Update시 미리 End to End 테스트를 하기로 하였습니다. 이렇게 하면 실제 서비스 서버에 적용하기전 사전에 문제 여부를 확인해볼 수 있습니다.

두번째로 시스템 업데이트와 Clean DB 작업 등을 통해 히스토리 파악이 안된 예전 데이타로부터 올 수 있는 장애와 오류를 없애기 위한 작업을 진행하기로 하였습니다.

그 외에 안정적인 서비스를 위해 Server의 Resource 밸런스를 잡기 위해 데이타베이스 서버를 분리하기로 하였습니다.

틈틈히 서비스 장애를 최소화하고 복구 및 디버깅 작업의 간소화 작업에 대해 고민을 해볼 계획입니다. 또한 일단 장애가 발생하면 평상시 보이지 않았던 추가적인 문제들이 나타나기 때문에 이에 대한 대응을 어떻게 하면 좋을지도 고민해볼 문제인거 같습니다.

0 Comments

Cancel