켜져있어서 돌아가는 서비스 운영하기
Edit on GitHub켜져있어서 돌아가는 서비스를 관리의 영역으로
시스템 관리자라면 켜져있어서 돌아가는 서비스들을 운영한 경험이 있을거다. 많은 컨퍼런스, 밋업, 개발자 블로그, 업체의 기술 블로그들에서 배포 파이프라인을 구성하고 모니터링을 고민하고 있을 때, 쓸쓸하게 팀에 git을 어디서부터 적용해야할지 고민하고 있을 많은 시스템 운영자, 데브옵스 엔지니어, 인프라 엔지니어들과 이 경험을 나누고자 한다.
무엇부터 해야할까?
시스템 목록
관리의 관점에서 보자면 지금 회사에서 돌아가고 있는 시스템이 무엇인지 몇개인지 파악하는 것이 우선이다.
- 초안잡기 : 최초 목록을 작성할 때 아는 서비스들을 중심으로 목록을 작성하자.
- 추가하기 : 서비스에 장애가 발생했을 때 트러블 슈팅을 하다보면 처음 보는 서비스들을 발견하고 깜짝 놀랄때가 종종 있다. '안희 이 서버는 뭬야?'라고 당황할 수 있지만 하나도 관리해주지 않았는데 지금까지 죽지 않고 운영되고 있었음에 감사하며 관리 목록에 추가하도록 하자.
구성 및 관리 항목
잘 돌아가는 서비스 모두 비슷한 이유로 잘 돌아가고 있지만, 트러블이 생긴 시스템은 모두 각자의 이유로 트러블을 일으킨다. 관리자 입장에서 무엇을 관리해야할까에 대한 답은 장애를 복구할 때 어떤 정보가 필요한가에 대한 답변과 같은 맥락을 가진다.
- 시스템명 : 시스템이름
- 상세 : 용도 및 기타 설명
- 자원 : CPU, Memory, Disk 등 주요 자원. 단일 시스템으로 돌아갈지 복수 시스템으로 분산할지에 따라 최소/평균/최대 자원 등을 정의필요
- OS :
- 설정정보 :
- 네트워크 정보(hostname, ip, subnet, gateway, dns ...)
- 보안 : 계정 설정, 계정 및 그룹 등의 권한
- 프로그램
- 웹/와스/DBMS/파일서버
- 개발 소프트웨어(바이너리)
- 환경설정
- WEB
- WAS
- 연동시스템
- 데이터베이스, 웹와스SSO캐쉬
불변 시스템
왜 불변 시스템을 구성해야 할까? 가장 큰 장점은 개별 시스템의 구성을 자동화하여 복구 자동화를 이룰 수 있다는 점에 있겠지만 시스템 관리자 입장에서의 명확한 이점은 장애가 터진 시스템은 장애를 고치는 것 보다 복구 시점을 기준으로 처음부터 쌓아올리는 것이 대부분의 경우 쉽고 빠르다는 것에 있을 것이다. 전통적인 시스템 관리자 혹은 장비 관리자의 관점으로 보면 하드웨어 장애가 발생했을 때 장비를 고치는게 아니라 일단 새 장비로 교체하여 서비스를 돌아가게 만들어두고 해당 장비를 고치는 것과 비슷한 관점으로 이해를 하면 좋을 것같다. 다만, 장비는 돈을 주고 갈아끼우면 되지만(ex. 레이드 구성이 되어있는 디스크가 나갔다면? 새 디스크 넣기. L2스위치가 나감? 설정을 옮겨서 스위치 교체), 시스템 교체는 갈아끼울 서비스(서버 혹은 내부 설정 등)를 관리자가 관리영역하에서 이력관리를 꾸준히 해두어야 한다는 차이점이 있겠다. 이건 아무도 못해준다. 엔지니어를 사지 않는 이상은...
업무 총량은 불변 시스템 구성이 많을 수 있지만 장애 복구의 관점에서 중요한 것은 터진 시스템을 얼마나 빨리 살리는가로 정의되어야 한다. 이 시간은 복구 목표 시간(RPO : Recovery P??? Objective)으로 정량화할 수 있겠다. 불변 시스템의 환경을 구성하는데 별도의 자원을 소모해야하지만 장애 복구의 관점에서 정량적 시간내 복구가 가능하다는 것이 큰 장점이라고 할 수 있겠지. 사실, 장애가 터지면 막 후덜덜한다. 손도 떨리고 동료나 윗선에서는 언제 복구되냐고 뒤에 서서 지켜보고있고, 뒤에서 지켜보면 콘솔접속해서 키보드를 치는데 손이 오들오들 떨려서 살릴 시스템도 못 살린다. 끊임없이 기록하고 관리하고 자동화하자.
불변 시스템을 위한 관리 목록
불변 시스템을 구성하기 위하여 변하는 것들의 주기를 정의해두는 것이 좋다.
- 개발 소프트웨어 및 바이너리 : 매 배포시점마다
- 운영 시스템 : 시스템에 대한 변경이 필요할 때마다(ex. 웹서버를 아파치에서 nginx로 변경하였다)
- 빌드 및 배포 자원 : 배포 환경이 변할때 마다
- 로그 : 서비스를 운영하는 매 순간
- DB의 데이터 : 서비스를 운영하는 매 순간
정리해보면
- 1과 2는 줄글 형태로 관리 가능하다. 개발 문서나 회사 내부위키 등
- 3은 CI도구로 운영하는 것이 정신 건강에 좋다. 21세기에 소스나 바이너리를 2020finalsource.zip final-2.zip으로 관리할 이유는 크지 않다. CVS, SVN는 이제 주력이 아니니 묻지도따지지도 말고 GIT을 쓰자.
- 5는 서비스에 따라 초단위로 변경이 발생할 수 있다. 4는 관리의 목적이니 중요치 않지만 5의 관리의 핵심이 된다. 이건 다음 기회에...
관점에 따른 소프트퉤어 개발 및 운영 프로세스
각 역할을 가진 사람들의 전통적인 관점의 개발 프로세스와는 다른 관점에서
PM
??? 워터폴 이미지 ???
워터폴로부터 시작되는 프로세스. 경직되어 보이면서도 사일로를 조장하는 적폐의 상징으로 보이지만 결국 PM은 저기있는 업무를 다 이해하고 프로덕트를 뽑아내야한다. 프로세스가 가진 경직성을 개선하고자 다양한 개발 프로세스들이 나왔고 단위 기능 중심으로 갈지, 반복을 어떻게 가져갈지, 핵심기능을 먼저 만들지, 프로토타입을 먼저 만들지에 대한 상세 방법론을 어떻게 가져갈 것인가에 대한 워터폴에 정의된 업무 중 하지 않아도 되는 것은 없다. 지금 이 순간 개발자와 고객이 멍을 때려도 PM만은 우리가 어떤 상황에 있는지 정신줄 놓지 않는 용도로 마음에 넣어두자. 20세기에 동년배들이 개발했던 프로그램들은 한번 배포하면 끝났을수도 있지만 이제 그런 세상이 아니다. 웹/게임/앱 등 지속적인 요구사항 변경이 당연한 시대가 되었으므로 요구사항 변화 및 운영 모니터링에 대한 관점이 필요하다.
개발자
??? 배포 파이프라인 이미지 ???
인풋부터 아웃풋 사이의 소프트웨어 개발 프로세스이다. 기관에 따라 단위기능을 혼자 치고가면 PM롤을 포함해야할 수도 있지만 기획서라는 인풋에서 소프트웨어 바이너리라는 아웃풋을 끊임없이 만들어가야 하는 관점으로 볼때 워터폴 전체를 커버하기보다 소프트웨어 배포 프로세스를 중심으로 업무 프로세스를 가져간다. 요구사항, 설계에 대한 부분보다 개발 및 배포가 중심이 된다.
운영자
??? 전체 모니터링 구성 이미지 ???
시스템 운영자 관점에서 각각의 시스템이 얼마나 잘 돌아가고있는지 확인하는 것이 주요 골자가 된다. 앞단까지의 개발이 완료된 바이너리를 잘 운영할 수 있는가. 모니터링/장애 복구 관점에 운영 프로세스가 필요하게 되며 실제 노드를 중심으로 관리하게 된다.
- 서버
- 성능 모니터
- 보안 로그
- 소프트웨어
- 로그