왜 인프라 관리 자동화가 필요한가?

CodingDaddy·2022년 3월 24일
0

SRE

목록 보기
4/4

“서비스가 안 되요”

어느 토요일 오전 , 기분좋게 운전을 하며 커피를 사러 가고 있었던 필자에게 한 통의 전화가 왔다. 다급한 목소리로 고객이 전화를 하니 곧바로 모든 마음의 안정과 원래 목적지에서 U턴을 해야했다. 보통 고객들은 ‘서비스가 안 된다’고 말을 하지 ‘Front단에는 오류가 없는데 API 서버와 통신이 느려진것 같이 오류가 발생해요’ 라고 자세하게 불평을 하지 않는다. 커피 메뉴나 햄버거를 개인취향에 맞게 그 어려운 주문을 할 때와는 전혀 딴 사람이다.

그렇다면 그 간단한 ‘서비스가 안 되요’라는 메뉴를 파악하기 위한 것은 모두 운영자의 몫이다. 집으로 돌아가는 시간동안 하늘이 도와서 신호등이 홍해를 가르듯 1초의 오차없이 나를 맞이해 주기를 바랬다. 물론 그 동안에도 고객들은 서로 오류 전파를 하며 불만이 높아지고 있었을 것이다. 집에 도착 후 숨이 가쁘게 노트북을 향해 달라가서 부팅을 했고, 다행히 여유로운 원격접속 프로그램의 사용자수에 포함이 되어 어렵게 사내망을 접속하여 관련 API 서버들의 CPU, 메모리 확인을 한 후 각 서버의 로그를 열어서 문제를 파악해야 했다. 물론 상황전파를 위해 메신저를 통한 보고와 질문에 대한 응답을 해야 하면서도 마음의 안정과 최고의 집중력을 발휘해야 했다. 원인은 간단했다. heap 메모리 부족. QA 버전 소스 배포의 설정이 PRD 버전까지 적용이 되었던 것이다. 이렇게 거의 1시간이 소모되었다.

그러나 문제해결을 위해 기술이 아닌 '행운' 이라는 것이 필요했다는 것이 씁쓸하다. 심야작업이 아닌 것의 행운 + 도로 상황의 행운 + 원격접속 제한의 여유의 행운 + 관련 운영자들의 PC접근성의 행운 …

네이버도 소 한번 잃고 외양간 제대로 고쳤답니다.

2016년 경주에서 대형 지진이 일어났을 때 네이버 검색량의 폭주로 네이버 시스템이 마비가 된 사건이 발생했다. 국내 최고의 검색엔진 네이버인 만큼 그들 나름대로 대응 체계가 있었을 것이다. [참고1]

365일, 24시간 언제나 서비스가 정상적으로 무중단 제공되어야 하는 시스템인 만큼 서비스의 규모가 커질수록 시스템의 신뢰성을 보장하는 일이 점점 어려워진 이유가 있었다고 한다.

첫 번째, 시스템의 규모가 한 단계씩 커질 때마다 새로운 방법론이 필요하다.
조직이든 시스템이든 규모가 커질수록 복잡도가 높아지고 관리가 어려워져 점점 관리의 효율이 떨어진다. 시스템의 규모에 따른 적정한 엔지니어를 수급하기도 어렵고 운영비용도 기하급수로 발생할 것이다. 숙련된 상태로 만들기에도 시간의 문제가 발생한다.

두 번째, 예측이 불가능한 일들이 일어난다.
지진과 같은 재난이나 각종 사회, 경제, 문화적으로 우리나라 사람들의 관심이 집중될 만한 이슈가 발생하면 네이버 검색으로 유입되는 요청량이 순간적으로 몇 배씩 폭증한다. 이런 사건 사고는 대부분 사전에 예측이 불가능하기 때문에 검색 시스템 입장에서는 미리 준비하거나 대응하기가 매우 어렵다.

필자도 코로나 폭증시대의 갑작스러운 사용자의 증가로 인해 ‘Max’에 대한 준비부족으로 고생한 적이 있다. 평온한 시대의 ‘Average’를 위해 운영이 되던 시스템에 갑작스러운 ‘변화’로 한 동안 원인 분석과 일회성 해결방법으로 위기를 모면해야 했다.

간단한 원인과 복잡한 미로

언제나 원인은 간단하다. 네이버의 경우에는 수만 대의 서버 중에서 단 8대를 차지하는 작은 서비스에서 가용량 문제가 있었는데, 이 작은 문제가 순식간에 전체 통합검색의 장애로 이어졌다고 한다. 증상 완화와 원인 파악, 영향도 분석까지 총 1시간에 가까운 시간이 소요 되었고 재발 방지책까지 포함한 사후 분석이 완료되는 데 총 48시간이나 걸렸다고 한다.

“네이버 이니까 1시간 걸렸을 것이다” 라고 감히 말할 수 있다.

필자의 경험으로는 소스 배포시 파일을 FileZila를 통한 FTP 전송을 하고 각 서버마다 접속하여 환경을 확인 후 각각 재실행을 명령하기와 정상적인 소스반영을 확증하기 위한 로그 확인까지 해야 했던 원시적인 경험을 얼마전까지 하고 있었다. 각각 사람이 발생시킬 수 있는 Human Error의 접점이 너무나도 많았고, 각 서버마다 다양한 ‘작은 원인’들이 발생했었다. 지금은 소스 자동배포 서비스를 사용하여 운영자의 접점을 최소화하여 소스 이외의 오류는 발생하지 않도록 준비가 되었다.

60초 vs 60분

앞서 소개한 필자가 경험한 서비스 장애처리 등을 예측 할 수 있는 범위내에서 자동화를 준비할 수만 있다면 아래와 같은 장점을 얻을 수 있다.

몇몇 오픈소스로 만들어 장애대응 자동화를 테스트 해 본 결과, 장애가 발생한 API서버에 설치된 모니터링 agent가 장애를 감지하는 10초 이후에 놀랍게도 장애발생 전파부터 장애처리, 처리전파까지 60초내에 해결이 되었다. 프로세스를 강제로 죽이는 간단한 장애발생 조건이었지만 동일한 테스트 작업을 새벽3시에 운영자에게 일으켰다면 처리 소요시간은 알 수가 없다. 최소한 60초내에 운영자가 일어나서 전화기 넘어 화가난 고객의 목소리를 알아 듣기까지 60초 이상이 걸릴 것이다. 그리고 토요일에 일어난 그 사건 또한 빠른 대처를 했지만 60분이 소요가 되었다.

60초와 60분, 둘 중 무엇을 택할 것인가?

물론 고객이 이 사실을 알기 전까지만 선택이라는 것을 할 수 있다.

설상가상 vs 클릭

한정된 인력과 시간으로 많은 인프라를 관리하느라 바쁜 인프라 담당자에게 대규모 변화가 있는 소스배포를 검증하기 위해 임시로 단기간에 사용할 신규 도메인 생성, 네트워크 설정, 서버 인스턴스, 소스 복사, 기타 등등을 요청을 한다는 것은 당연한 일이지만, 인프라 담당자의 업무 부담이나 부재로, 혹은 인프라팀의 스케쥴 때문에 제때 요청하지 못 할 수도 있다.

또한 제대로 작업이 되었는지 검증하고 미흡한 결과물일 경우 재요청을 하기 위해 오고가는 이메일로 요청하는 부서의 담당자 또한 인프라가 준비 되기까지는 스케쥴이 중단이 된다.

AWS와 같은 클라우드 환경이라 하더라도 기존 운영중인 서비스에 관련된 모든 인프라를 모두 복사해서 다른 리전이나 다른 계정에 설치하여 오류없이 단기간에 운영할 수 있도록 수작업을 한다는 것은 요청자나 수행자 모두 큰 부담을 갖을 수 밖에 없는 것이 현실이다. 게다가 인프라 담당자의 오랜 부재나 이직으로 history를 알던 사람이 사라지면, 그 때는 재앙과도 같다.

이럴 때 기존 운영 인프라를 코드[참고 2]로 관리하고 있다가 클릭 한번으로 자동으로 프로비저닝을 할 수 있는 기술[참고3]을 도입을 한다면 위의 문제가 조직에 주는 부담을 해결 할 수 있다.

새로운 인프라 구성과 프로비저닝을 테라폼의 기술로 구현하고, 구성 관리는 Ansible로 하고, 각 작업의 소스 파일을 git과 같은 히스토리 관리 툴로 운영을 한다면 운영자의 부재, 조직의 변화에도 서비스의 확장과 일관성을 확보할 수 있다. 물론 이것은 특정 클라우드사에 기술이 종속되지 않기 위한 오픈소스와 독립적인 서비스를 이용하는 방법이고, 클라우드사마다 각각 오픈소스의 개념을 서비스로 제공하고도 있다.

우아한 장애대응

대규모 인프라를 운영하는 우아한 형제들의 장애를 대비하는 모습을 처절하게 보이기까지 하다. [참고4] 그러나 그들에게는 우아하고 이름 꽤나 유명한 개발자들이 즐비하다.

‘우아한형재들’과 같이 일부러 잘 운영되고 있는 현재 인프라에 여러가지 스트레스를 주어서 인프라의 단점과 약점을 찾아내고 장애발생 이전에 미리 해결 하기위해 SRE[참고5]를 도입하는 기업들이 늘어나고 있다.

장애대처에 대한 이슈로 고객의 관심이 뜨거웠을 때, 연구소에서 빠른 장애대처를 위해 매뉴얼을 작성 했었다. 어제 입사한 사람이 읽고서도 처리할 수 있을 만큼의 수준으로 정보를 담고자 했다. 그러나 그것은 너무나 어려웠다. 장애가 매뉴얼 대로만 일어나 주기를 기도해야 하는 수준이었다. 그런데 우리 조직에는 이런 장애대처 매뉴얼도 없는 시스템들도 있을 것이다. 그리고 개발자들의 자리이동도 점점 많아지는 조직이 되어가고 있다.

닫는 글

인프라 관리의 자동화를 스터디 하기위해 여러 정보를 찾으면서 느낀 것은 장애 대처와 단순 운영에 인력을 소모하지 않고, 신속하고 유연한 인프라 조성과 대규모 인프라를 운영 할 수 있는 능력을 갖춘다는 것은 기업의 꽃이 아니라 생존의 열쇠가 되어 가고 있는 것을 느낀다. 그리고 단순히 인프라 자동화 관련 기술자체 뿐만 아니라 DevOps, SRE 등을 구현할 수 있는 유기적인 조직의 구성과 문화가 있어야만 제대로 정착할 수 있다는 것을 선행 기업들이 보여주고 있다.

참고 자료:

[참고1] https://d2.naver.com/helloworld/2047663

[참고2] https://www.redhat.com/ko/topics/automation/what-is-infrastructure-as-code-iac

[참고3]https://www.redhat.com/ko/topics/automation/whats-it-automation ,Terraform: https://www.ibm.com/kr-ko/cloud/learn/terraform

[참고4] https://techblog.woowahan.com/6557/ , https://techblog.woowahan.com/4886/

[참고5] https://sre.google/sre-book/introduction/

profile
Creative - DevOps in Korea

0개의 댓글