PART 1 Build a fault tolerant system

If Kakao 2019 Program 정리

• 본 포스팅은 if(kakao) dev 2019에서 발표자료를 개인의 경험과 빗대어 설명하였습니다.
• 모든 창작권은 카카오에게 있으며, 발표내용은 개인의 해석이 들어갈 수 있음을 알림니다.
• 발표자료 및 영상은 다음 링크에서 확인하실 수 있으며, 저적권을 위해서 PPT에 있는 내용을 사용하지 않습니다.
  • https://if.kakao.com/2019/program

PART 1 Build a fault tolerant system

연구실에서 서버, 네트워크, 연구실에서 사용하는 여러 오픈소스 소프트웨어와 개발 플랫폼을 운영하다 보면 가장 걱정되는 것이 장애라고 할 수 있다. 가상화 서버와 네트워크, 보안 시스템을 아무리 철저하게 설계 및 운영한다고 가정하더라고 예기치 않은 장애 발생은 나에게 큰 부담감으로 다가갈 수밖에 없다.

장애 발생은 한순간에 이루어진다. 본인이 관리하지 않는 윈도우 PC에서 외부망에 접속하던 A가 랜섬웨워에 감염된 사실을 알게 되고 연구실을 발칵 뒤집이게 되었다. 하나의 PC가 랜섬웨어에 걸린 것일 뿐이지만 사설 네트워크로 연결된 연구실에 특성상 랜섬웨어는 빠르게 퍼져나갈 것이고, 즉각적인 보고와 함께 약 70여 대의 PC에 전수조사를 진행하게 되었다. 다행히도 업데이트 및 랜섬웨어 방지 프로그램 덕분에 피해는 그렇게 크지 않게 마무리되는 듯 싶었다.

하지만 한 번에 불행은 또 다른 불행을 몰고 온다고 했던가.. 이번에는 2대의 ESXi에 문제가 발생했다. RAID 볼륨이 깨지는 것으로 시작하여 장애가 발생하기 시작하더니 이번에는 서버가 동작하지 않는 상태까지 빠르게 장애가 전파되었다. 우리는 수많은 애플리케이션 서비스를 사용하면서 살아간다. 그것은 개인의 일상에 깊숙하게 파고 들어갔고, 하나의 애플리케이션의 장애는 서비스의 신뢰를 떨어뜨리게 되는 문제를 야기시킨다.

연구실에 모든 시스템이 마비되자 하나둘씩 불만을 토로하기 시작했다. 하나의 하드웨어의 장애가 빠르게 전파되어 전체 시스템을 마비시키는 시간은 빠른 속도로 진행되었다. 물론 본인이 서버 관리를 제대로 진행하지 않고 소홀하게 관리한 책임을 회피할 수 없겠지만 서비스 장애는 큰 스트레스로 다가왔다. 다행인 점은 보조 서버가 있었다는 점, 모든 시스템은 백업본이 있었기 때문에 4시간의 복구 작업을 통해 중요 코어 애플리케이션을 복구하는 데 성공하였다.

이러한 시스템 장애를 완벽하게 막기 어렵기 때문에 우리는 항상 오류가 발생할 수 있음을 예상하고 이에 대한 대비책을 설계하고 준비해야 한다. fault tolerant system 즉 장애 허용시스템을 운영하기 위해서는 장애 차단, 이중화 시스템을 통해 동작을 지속시키고 사용자는 장애 발생했는지에 대한 여부를 알아서는 안 된다. 장애 발생 시스템은 알람을 통해 담당자에게 통보해야 하며, 이를 신속하게 해결할 수 있는 능력이 있어야 한다.

물리 서버 및 네트워크 장비를 이중화하는 방법은 가장 기본적인 방법이지만, 이러한 시스템을 전부 구축하기 위해서는 굉장한 큰 비용이 들어가는 것이 사실이다. 클라우드 시스템을 사용한다면 이러한 비용 문제를 어느 정도 막을 수 있겠지만, 본 연구실에 사용하는 애플리케이션은 클라우드 시스템을 사용할 수 없는 상황임과 동시에 금융 서비스 또한 클라우드 시스템을 사용할 수 없다. 클라우드 서비스 업체도 마찬가지이다. 사용자는 장애 발생 여부를 알 수 없지만, 실질적으로 클라우드 서비스에서 근무하는 사람은 한치에 실수가 전체 시스템에 영향을 끼칠 수 있다는 사명감을 느끼고 있어야 한다.

이러한 사고가 이루어지고 나서, 연구실에 대대적인 인프라 재설계 작업이 이루어졌다. 백본 네트워크 장비의 교체, 코어 장비별 LACP설정, 연구용, 일반, 특수 목적용 네트워크 분리, 불법 침입을 감지하기 위한 오픈소스 방화벽 설치 Docker 오케스트레이션 구축, 로그 시스템을 구축했다.

인프라스트럭처 시스템이 잘 구성이 되어 있다고 하더라도 장애의 대부분의 원인은 코드일 것이다. 비정상적인 쿼리, API 요청, 스레드 풀 처리 문제는 애플리케이션을 개발할 때 가장 잇슈가 되는 부분이다. 잘 설계된 서비스 로직, 문제 발생 시 해결 방안, 애플리케이션, 하드웨어어 시스템 문제 발생 시 해당 담당자에게 즉각 통보할 수 있는 알림 시스템이 안정적인 애플리케이션을 개발하는 데 있어서 중요할 방안일 것이다.

최근에는 MSA 개방 방법론이 대중화되면서 이러한 애플리케이션 문제가 상당히 해결될 것이라 믿고 있다. 애플리케이션 개발자와 인프라스트럭쳐 운영자 각기 다른 분야인지만 안정적인 서비스를 운영하기 위해 노력하고 있다는 사실을 알 수 있는 시간이었다.