시스템 엔지니어와 RTO(재해복구목표) 마인드

HYEONG HWAN, MUN/ 7월 5, 2020/ 미분류/ 4 comments

진행 중이던 프로젝트가 잘 마무리 되었고, 여유가 생겨서 글을 작성해본다.

회사에서 여러가지 업무를 하고 있는데, 그 중 하나가 인프라 관리이다.
내가 구성한 인프라는 기본적으로, 외부 공격을 차단하고, 부하를 측정해서 자동으로 서버가 추가되고(auto scaling), 주기적인 패치와, 주기적인 교체가 이루어지게 설정되어있다.
한번 제대로 구성한 다음, 별로 신경 쓰지 않는다. (물론 메신저에 notification이 오게 설정해 두었다.)

웹서비스는 고객에게 uptime 을 보장해주어야 한다. 따라서 이러한 인프라 관리자도 항상 uptime 을 감시하고, 대응할 준비가 되어 있어야 한다.

예전에, 어느 회사의 장애감지에 완전 무감각한 시스템을 본적이 있었는데, 충격이 잊혀지지가 않더라. 장애가 발생하고, 고객이 “사이트가 안떠요”라고 전화를 하면 그때부터 알고 처리하더라.
서버도 IDC에서 코로케이션을 받고 있어서, 직접 OP실과 통화를 해야했고, 장애 처리도 빨라야 10분, 늦으면 30분 정도 걸리더라. (나는 이러한 처리에 충격을 받아서, 클라우드 이전을 가이드하고 직접 이전하고 구성해 주었음)
한마디 물어보았는데 대답이 더 충격이었다. “이런 처리 방식 문제있지 않나요?” 라고 했는데 “장애 발생한지 몰랐는데 어떻게 처리하느냐“라고 당당히 답변하더라. (“몰랐으니 난 책임없다” 라는 마인드를 고수하더라)

인프라를 적절히 구성하는 방법은 이 글에서는 다루지 않겠고, RTO에 대해서만 다루도록 하겠다.

RTO : Recovery Time Objective 의 약자이며 장애복구 시간목표를 뜻한다.
일어날 수 있는 위험(Disaster)에 대해 평가하고, 다운 비용, 복구 비용을 염두해두고 있어야한다.
주로 장애라고 부르는 것들은, 예측하지 못한 위험들이며, 이것들을 처리하려면 빠른 상황 이해력과, RTO 전략, 복구 능력이 필요하다.

가끔 장애 발생시 장애 원인 디버깅을 하고, 수정하고 살리려는 사람이 있는데, 나는 그렇게 하지 말라고 한다.
시스템 운영자는 반드시 빠른 복구를 최우선 해야 한다. 어떻게 해서든 빨리 복구하세요.

 

* 예시 :
Q) 사이트의 포털 광고로 인해 가입자가 폭증해서 다운되었을 경우 어떻게 해야할까?
A) 물론 사람마다 스타일이 다르겠지만, 내가 RTO 전략을 짠다면, 우선 광고비가 나가는 비싼트래픽들이고, 유효한 트래픽들이므로, 당장 튜닝이나 캐시정책을 하기보다는 서버나 DB 성능을 최대치로 끌어올려서 살려내보겠다.

Q) 사이트에 악성글 도배가 되고 있다. 어떻게 처리해야 할까?
A) 우선 IP 를 차단해야겠지만, 요즘은 이런 단순한 것들은 잘 피해한다. 글작성 잠시 안되어도 큰 비용손실이 없으니, 우선 해당 기능을 막고, 도배 request 를 분석해서, 웹방화벽에 등록한다.
추후, 전문 방어툴(어차피 이것들도 시그니쳐 분석해서 막는 프로그램이다)을 도입한다.

Q) 사이트가 갑자기 안떠요! (실제 사례)
A) 2018년 11월 22일에 일어난 실제 사례이다. 아마존 내부 DNS 가 불능 상태가 되어 시스템 장애가 있었었다.
여러 큰 기업보다 1시간 10분 정도 재해 복구를 빨리 하였다.

아마존 웹서비스 내부 DNS 서버 장애

 

아무튼 인프라 관리자, 시스템 엔지니어라면 장애를 감지하고, RTO 전략을 수립하고, 빠르게 복구/구축 할 능력을 길러 두어야 한다.

 

* 같이 알아볼 이론 - RPO : Recovery Point Objective 를 뜻하며 장애 발생시 복원 가능한 시점을 뜻한다.
6시간마다 전체 백업하는 시스템에서, 5시간 사용중에 장애가 발생해서 복구해야 한다면 => 복구 가능한 시점은 5시간전의 백업시점이 되게 된다.
이것은 별로 신경쓰고 있지 않는데, S3 VersioningAWS Aurora DB를 사용하면 초단위의 복원이 가능하기 때문에, RTO는 거의 장애발생 직전 시점이 가능하다.

 


요즘에는 보안 능력도 필요하더라.

비지니스를 하다보면 B2B, B2C 등 어쩔 수 없이 개인정보를 취급하게 된다. (나의 경우에는 B2B 라서 개인정보취급위탁)
나는 개인정보를 많이 다루기 때문에, 1년에 한번씩 행정안전부에서 진행하는 “개인정보 보호교육“을 듣는데, 들을 때마다 부담이 되더라. (이것은 능력도 있어야 되고, 더 많은 노력도 있어야 한다.)
외부 해커 입장에서 돈이되는 것들은, 컨텐츠 데이터 보다는, 회원 개인정보 이다.
따라서, 이러한 돈되는 정보를 얻으려는 공격이 많다. 시스템 관리자는 이것을 감지하고 방어할 능력도 있어야한다.

뉴스에는 나오지 않았지만, 최근에도 어느 업체의 고객정보 유출, 어느 업체의 주민등록번호 보유 및 유출, 어느 업체의 전체 시스템 해킹 등도 있었다.
(쉬쉬해도 관련업계에는 소문나게 되어있다.)

이러한 일이 생겼을때 “책임의 화살은 누구에게 갈 것인가?” 를 생각해보도록 하자.

 


결론 : 장애시 빠르게 복구 할 수 있도록 준비해 둘 것. 모니터링 구축도 필요하다. (서버 모니터링 서비스/소프트웨어 리뷰 목록 : https://blog.lael.be/post/9619 글도 참고바람)

내 경험상, 서버 한대 다운되거나, 몇분 서비스 장애가 일어나도 사는데 별 지장 없지만, 개인정보 유출은 큰 문제가 발생한다. 따라서 항상 긴장하고 있을 것.

인프라관리자/시스템엔지니어/시스템관리자는 실력과 능력이 필요하며, 무엇보다 많은 노력이 필요한 업무이다.

 

4 Comments

  1. 항상 좋은 글 감사드립니다~

    1. 감사합니다. 항상 좋은일 있으시길 바랍니다!

  2. 제가 다니는 회사는 구글클라우드플랫폼 기반으로 서비스중인데 고객 사이트 중 한곳이 무슨 프로모션인지 뭔가 해서 트래픽 폭증으로 서버가 나가서 다른 사이트까지 접속이 안되는 사태가 발생을 하였습니다..;; 팀장님이 빨리 해결을하긴 했지만.. 문득 이 글이 생각나더라구요. 항상 좋은 정보 감사합니다^^

    1. 잘 해결되었다니 다행입니다.
      저도 최근에 고객사의 갑작스런 스팟 이벤트로 인해서 동접이 몰리는 상황이 발생했고, 장애도 발생했었는데 DB서버 사양을 늘려서 대처했습니다.
      조만간, 서비스 운영중 다운타임없이 사양을 늘리는 방법 및 부하 쿼리 확인방법에 대해 글을 작성해보려고 합니다.
      감사합니다.

Leave a Comment

작성하신 댓글은 관리자의 수동 승인 후 게시됩니다.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>
*
*