Browsing Tag

보안

NCP

[NCP] VM의 재부팅, 원인이 무엇일까?

안녕하세요. ManVSCloud 김수현입니다.

오늘은 서버 운영 중 미연에 방지 하지 못한 여러가지 장애 상황으로 인해 VM이 재부팅되어 일시적으로 서비스 중단이 발생하는 경우를 최소화 할 수 있는 방법에 대해 생각해보는 포스팅을 준비했습니다.


장애가 발생하는 이유는 무엇일까?

우선 장애가 발생할 경우 어떠한 원인들이 존재할까요?
IT 전공자부터 비전공자까지 다양한 인원들을 대상으로 설문조사를 진행해보았습니다.

여러분들은 어떻게 생각하시나요?
우선 “다양한 원인이 있을 것으로 보인다.”가 가장 정답에 가깝습니다.

장애라는 것은 단편적으로 보고 판단하기 어렵습니다.
다각도로 접근하여 원인 분석을 할 필요가 있고 가장 중요한 것은 이러한 장애로부터 예방하는 것입니다.

또한 재부팅이 되지 않는다고 하여도 서버가 정상적이지 않은 장애 상태라고 볼 수 있는 경우는 어떤 것들이 있을까요?

AWS의 Status Checks를 참고해보면 아래와 같은 예시가 존재합니다.

  • 네트워크 연결 끊김
  • 시스템 전원 중단
  • 물리적 호스트의 소프트웨어 문제
  • 네트워크 연결성에 영향을 주는 물리적 호스트의 하드웨어 문제
  • 시스템 상태 확인 실패
  • 잘못된 네트워킹 또는 스타트업 구성
  • 메모리가 모두 사용됨
  • 파일 시스템 손상
  • 호환되지 않는 커널

네이버 클라우드에서도 역시 크게 다르지 않습니다.
위의 다양한 원인으로 장애가 발생하게 됩니다.

제 경험상 저 역시 데이터 센터에서 MSP 업무를 하며 다수의 문의를 받아 보았지만 이러한 다양한 원인에 대해 모르시거나 잘 되던 서버가 갑자기 안되는 것을 보니 서버가 있는 곳(데이터 센터)에 문제가 생겼구나라고 인지하시는 분들이 생각보다 많았습니다.

사용하는 서버의 VM 재부팅 현상 자체를 네이버 클라우드 측의 장애로 생각하는 경우도 존재하여 네이버 클라우드 측에 문의하는 경우도 꽤 많을 것이라 생각됩니다.

아래는 위 설문조사의 결과입니다.

4번이 아닌 1,2,3번을 선택하신 분들도 어느정도 존재했습니다.
IT 업계에서 다양한 경험해보신 분들은 여러가지 케이스가 존재하는 것을 알고 계시지만 경험이 부족하거나 비전공자 또는 사업을 운영하시는 사장님들은 이러한 세부적인 사항까지 모르실 수 있다고 생각합니다.

이제 위의 여러가지 장애 예시를 알게되었고 알 수 없는 이유로 재부팅이 될 수도 있는 점을 알게되었으니 왜 재부팅이 되는지와 이러한 장애들로부터 어떻게 대비할 수 있을까?에 대해 알아보도록 하겠습니다.


이중화와 FailOver

먼저 HA(High Availability)에 대해 많이 들어보셨을 것입니다.

시스템 및 서비스 장애 발생 시 서비스 전이를 통해 장애 타임을 최소화할 수 있는 고가용성 서비스인데 대표적으로 시스템 Hang이 발생하거나 Shutdown, reboot, OS 디스크 등 장애가 발생할 경우 FailOver가 작동하게 됩니다.
(FailOver는 장애 대비 기능으로 Active 서버에서 시스템 장애 발생 시 미리 준비된 Standby 서버 자동 전환하여 서비스 중단을 최소화할 수 있도록하는 장애 조치 기능입니다.)

네이버 클라우드의 VM 재부팅 역시 이러한 FailOver가 진행되고 있습니다.
다양한 불특정 이슈로부터 서비스가 유지되도록 자연스러운 현상이 일어나는 것이죠.

만약 이러한 VM 재부팅/HA 동작이 일어나지 않는다면 어떤 문제가 발생할까요?
운영자가 서버가 중단된 사실을 인지하고 장애를 복구하기 전까지 서비스가 멈춰있는 상태가 유지될 것입니다. 이러한 문제로 인해 다운 타임이 길어지거나 빈번한 다운이 발생하게 된다면 다방면으로 사업에 크리티컬한 피해를 입게될 것입니다.

이제 VM이 재부팅/HA 동작이 되는 현상에 대해 어느정도 이해를 하셨을 것이라 봅니다.

하지만 VM이 재부팅되는 동안 일시적인 서비스 중지나 재부팅 후에 서비스 정상 작동 불가로 이어질 경우 이러한 장애로부터 또는 이를 미연에 방지하기 위해 어떤 점검과 준비를 할 수 있을지 대표적인 다섯가지 예를 알아보도록 하겠습니다.


장애를 어떻게 대비할 수 있을까?

1. 모니터링

가장 첫번째! 장애를 인지하는 것부터가 우선입니다.
장애가 발생했는데도 장애를 인지하지 못하여 장애 타임이 길어지는 일은 없어야할 것입니다.

모니터링을 이용하여 장애 또는 장애에 대한 대비를 할 수 있도록 모니터링 설정을 해야합니다. 대표적으로 디스크, CPU, Memory 사용률에 대한 모니터링을 하여 부하 발생 시 원인 파악 및 조치를 하여 장애 대비를 할 수 있고 프로세스, 서버 DOWN 시 장애 발생 시 빠른 대처가 가능해야합니다.

네이버 클라우드에서는 이러한 모니터링을 할 수 있도록 Cloud Insight(Monitoring) 서비스를 지원합니다. (Cloud Insight(Monitoring) – Configuration – Event Rule)

모니터링 설정 방법을 이곳에서 다루기에는 전체적인 포스팅이 너무 길어져버릴 수 잇으니 추가적인 포스팅을 하도록 하겠습니다.

2. 고가용성 아키텍처

두번째는 고가용성 아키텍처를 구성하는 것입니다.
높은 가용성과 장애 시 복구 시간의 최소화하기 위해 고가용성 아키텍처를 적극 권장합니다.

웹 서버의 경우 하나의 고사양의 서버 하나만 사용하기 보다 사양을 나누어 2개 또는 4개로 나누는 것이 좋고 리전 역시 나누는 것이 좋습니다. 거기에 오토스케일링까지 이용한다면 좋겠죠. 위 아키텍처 이미지들은 웹 서버의 대표적인 일부 예시이며 상황에 따라 더욱 다양하게 사용이 가능합니다.

첫번째 이미지와 같이 단일로 사용하는 것은 정말… 권장드리지 않습니다.
(물론 세션에 대한 문제를 당장 처리할 수 없다면 어쩔 수 없지만요?)

단일 서버로 서버 다운의 걱정과 특정 시간에 부하가 있어 고민을 하시던 고객님이 있었습니다. 위와 같은 다양한 아키텍처를 소개해드리고 방안에 대해 설명을 해드리고 작업을 해드린 경험이 있었습니다.

서버 하나가 다운되더라도 다른 리전의 서버가 운영되며 다운 및 자원 부하 시 오토스케일링으로 추가적인 서버 확보가 가능하도록 해주어 고객님께서 장애 및 특정 시간에 Scale Out , 특정 시간 이후 Scale In이 되어 비용 효율적으로 서비스를 원활하게 사용할 수 있게 되었다고 매우 만족하셨습니다.

추가로 DB 서버는 Cloud DB for MySQL를 사용하시는 경우 “고가용성 지원”을 사용하는 것이 좋고 일반 서버에 설치하여 사용하는 경우 이중화 작업을 진행할 수 있습니다.

3. 백업

세번째로 백업을 진행하는 것입니다.
네이버 클라우드에서는 자동 백업을 신청받아 진행하게 됩니다.

이게 조금 네이버 클라우드를 사용하며 아쉬운 부분 중에 하나인데…
이미지 및 스냅샷 생성을 자동화하여 주기적으로 백업하는 방법이 지금 당장 서비스로 만들어진 게 없습니다.

그렇기때문에 네이버 클라우드에 Backup 서비스 신청서를 작성하여 신청하거나 다른 방법을 찾아보아야합니다.
(요즘 이 부분으로 불편함을 겪고 있는 사용자들이 많아 이에 대한 방안 찾기 위해 개발을 배우고 있습니다.)

4. 최적화 및 보안 작업

네번째로 최적화 및 보안 작업입니다!
대부분 최적화가 되지않아 장애로 이어지는 경우를 너무나도 많이 보았습니다.

기술지원 업무를 하다보니 이런 케이스를 많이 보게됩니다.
이미 정해진 리소스 자원으로 감당하기 힘든 것들이 내부에서 작동되고 있어 서버가 “죽여줘~!”라며 소리치는 경우가 아주 드물죠.

서버 내 사용하는 소프트웨어들의 설정값 및 개발 소스 및 DB 쿼리 최적화 이 잘 되어있어야합니다.
(특히 최근에 저도 DB 쿼리가 처리되지 않아 서비스에 영향받으시는 고객님들을 자주 보는 것 같네요.)
또한 용량 문제로 장애가 발생하는 경우도 존재합니다.
Log 파일이 용량을 전부 사용하여 서비스 운영에 지장이 생기는 경우죠.
Log 파일을 Logrotate를 이용하여 관리할 필요도 있으며 그 외에 보안적인 측면도 신경써야할 것입니다.

System Security Checker, App Security Checker, Web Security Checker 등을 이용한 점검 및 IPS, WAF 신청으로 보안을 강화하는 방법이 있습니다.

취약점 공격을 이용하여 공격성 접근으로 시스템 부하 및 서비스 운영 중단이 발생하는 경우도 많이 일어납니다. 특정 사용자분들은 뉴스에나 나오는 이야기겠지…라며 아무렇지 않게 생각하시다가 큰 피해를 입으신 뒤 뒤늦게 보안적인 측면을 고려하시는 분들이 많습니다.

개인적으로 보안 장비 도입이 비용적으로 선택하기 힘들다면 서버 내부에서 오픈 소스를 활용하여 보안 설정을 할 필요가 있고 백업은 무조건! 필수입니다.
(IPS, WAF, BACKUP 어디에 비용을 투자할까? 고민되시면 무조건 BACKUP을 권장합니다.)

5. 장애 대응 매뉴얼

마지막으로 장애 대응 매뉴얼을 만들고 적극적으로 활용하는 것입니다.
물론 어떠한 업무에 대해 특정 인원 한 명만 처리가 가능한 상황이라면 보안상 옳지 않으나 특정 서버 담당자가 처리할 수 없는 상황일 때 다른 인원이 정해진 장애 대응 프로세스를 이용하여 대응이 가능한 상태를 만드는 것입니다.

제가 알기로 배달의 민족이 장애에 예민하여 이러한 장애 대응 프로세스가 잘 되어있다고 들었습니다. 또한 개발 환경에서 장애를 만들고 담당자가 아닌 인원들이 장애 시 대응하는 훈련도 하고 있다고 합니다.

아래는 장애 대응에 대한 글인데 내용이 마음에 들어 추가해두었으니 한번쯤 읽어보시면 좋을 것같습니다.

지금까지 대표적인 다섯가지 예시를 알아보았습니다.
물론 위 예시를 제외하고도 더 존재합니다. 예를 들면 이벤트 전 자원 확보라던가?
이벤트, 뉴스, 광고로 인해 평소보다 많은 트래픽과 자원 사용으로 서비스 장애가 발생하는 케이스도 많이 있죠. 이를 인지하고 있음에도 불구하고 대비하지 않는다면 당연히 장애로 이어질 수 있습니다.

장애를 미연에 방지하기 위한 점검과 준비 방법 전부 다 적지는 못했습니다.
또 다른 것들이 생각나신다면 댓글로 적어주시면 감사하겠습니다.


Personal Comments

오늘은 네이버 클라우드 플랫폼 사용 시 VM이 재부팅되는 원인은 무엇이고 이를 어떻게 대비할 수 있을지 알아보았습니다.

많은 사용자들이 운영 중인 서비스가 중지된다면 당황스러울 것입니다.
네이버 클라우드 측에서도 이러한 부분으로부터 사용자들이 조금 더 유연하게 대처할 수 있도록 개선되었으면 하는 점에 대해 생각해보았습니다.

Trouble Shoot 가이드가 보강되면 좋겠지만 이러한 부분은 네이버 클라우드 측에서 모든 케이스별로 Trouble Shoot 가이드를 쓴다는 것은 쉽지 않은 일이 될 것입니다.
(실제로 너무 다양한 케이스가 많아서 그걸 모두 예측하고 가이드로 만든다는 것은 어렵다고 보며 만약 만든다고 하더라도 고객별 시스템 환경에 따라 변수가 생길 수 있을 것이라 생각합니다. )

그렇기때문에 이러한 트러블 슈팅이나 추가적인 조치 방안의 경우 파트너사를 이용하여 도움받는 것이 더 효율적이라고 생각하며 오히려 네이버 클라우드 측에서는 사용자들이 조금 더 네이버 클라우드를 편하게 사용할 수 있도록 각 서비스별 기능을 업그레이드 했으면 좋겠습니다.

대표적으로 현재 네이버 클라우드 측에서 Linux 서버 운영 시 NAS를 함께 사용할 때 가용성을 위해 오토스케일링을 설정할 경우 NAS의 접근제어로 인해 오토스케일링으로 생성된 서버의 경우 NAS의 접근제어 리스트에 자동으로 추가되지 않으므로 정상적인 부팅이 되지않아 오토스케일링을 원하는대로 사용할 수 없는 문제가 발생합니다.

여러가지 개선되었으면 하는 점이 있지만 가이드적인 부분보다 이러한 기능적인 부분에서 불가능한 요소로 인해 다양한 아키텍처로부터 제한이 생기거나 불편함을 겪는 경우가 줄도록 해야할 것입니다.

긴 글 읽어주셔서 감사합니다.