"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."
저는 작은 개발팀을 리드하고 있는 개발자입니다. 이미 상당히 많은 시간을 코드 작성보다는 기타 업무에 시간을 쏟고 있어서 "내가 개발자라고 당당히 이야기해도 되나?"하는 생각이 들 때도 있지만, 여전히 많은 부분 개발자의 정체성을 유지하고 노력 중인 개발자입니다.
개발을 하다 보면 데브옵스DevOps에 대해서 자주 접하게 됩니다. 최근에는 데브섹옵스DevSecOs나 SRESite Reliability Engineering에 대해서도 심심찮게 접하고 있습니다.
사이트 신뢰성 엔지니어링이란, 조직이 시스템이나 서비스 및 제품에서 적절한 수준의 안정성을 지속적으로 달성하도록 지원하는 엔지니어링 분야입니다. Google의 Ben Treynor Sloss란 분이 2003년에 만든 용어라고 합니다.
작은 회사에서 개발팀의 리더 역할을 하다 보니 자연스럽게 서비스/인프라 운영 전반을 함께 고민하는 입장에 놓이게 됩니다. 부족한 인력과 두루뭉술한 업무 경계 때문에 필요한 것들은 분야 불문 계속 학습해 나갈 수밖에 없습니다. 저에겐 SRE도 그런 영역 중에 하나인 것 같습니다. 비록 미세먼지 수준으로 개념을 잡고 있어서 책의 전체적인 내용에 대해서 깊이 있는 리뷰를 할 자신은 없지만, 본인이 겪은 실제 에피소드와 책의 내용 일부를 소개해 보고자 합니다.
사건의 재구성
당시 작성했던 자료를 제시하여 더 구체적으로 설명할 수 없는 점이 아쉽지만, 간단히 겪었던 상황을 설명해 보겠습니다.
2호 개발자로 회사에 입사했습니다. 개발 업무 외에도 형상 관리, CI/CD, 개발/시험 환경의 격리 구축, 인프라 운영/모니터링, 채용 업무 등 서비스 개발 프로세스 전반에 걸쳐 부족한 것들을 찾아서 일하던 시절이었습니다. 그중에 시험 데이터 생성을 위한 DB 마이그레이션 업무도 있었습니다.
시험 데이터 생성은 프로덕션 환경의 데이터로부터 마이그레이션 했었습니다. 이 작업에는 몇 가지 요구/제약 사항이 존재했습니다.
- 개발/시험 환경에서의 테스트 결과는 신뢰 가능해야 함
- 담당자의 개인 정보만 이관해야 하며, 반드시 필요한 항목만 이관해야 함
- 마이그레이션 중 발생 가능한 DB 제약 조건 등의 충돌을 해결할 수 있어야 함
- 점심시간 중에 이관 작업을 완료할 수 있을 정도로 빨라야 함
처음엔 이런 일들을 잘 처리해 줄 수 있는 오픈소스를 찾았으나 요구사항을 만족하는 적합한 도구를 찾을 수 없었습니다. 결국 마이그레이션 스크립트를 직접 작성하기에 이르렀고, 아래와 같은 흐름으로 스크립트를 작성했습니다.
- 개발/시험 환경의 DB를 초기화 (계정 및 DB 전체를 삭제 ㄷㄷㄷ)
- 프로덕션 환경의 계정, 권한, DB 스키마, SP 등 내용을 분석하여 DDL, DCL 스크립트 작성
- DDL, DCL을 개발/시험 환경에서 수행
- 프로덕션의 데이터 중 필요한 데이터만 선별하여 개발/시험 환경으로 복사
작성한 마이그레이션 스크립트는 잘 동작했습니다. 그 일이 생기기 전까지는 말이죠.
마지막 마이그레이션 시점으로부터 1년의 시간이 흘러 마이그레이션 방법에 일부 변경 사항이 생겼습니다. 조직이 성장하면서 정보 보안을 담당하는 직원이 합류했고, 보안 담당자의 피드백을 통해서 한창 부족한 지점을 보완해 나가는 과정이었습니다. 변경 지점을 통제하기 위해서 마이그레이션 스크립트용 설정 파일 구조에도 변경이 발생했습니다. 변경 내용에 대해서 테스트를 수행했고, 잠시 후 장애 모니터링 서비스로부터 장애 발생이 보고되기 시작했습니다.
전에 잘 사용했던 도구이다 보니 뻔히 테스트를 수행하고 있으면서도 내가 잘 못했다는 생각을 하지 못했습니다. 장애 대응 채널에 서비스 변경 사항이 있었는지 문의했지만, 특이 사항이 없었습니다. 그제서야 뭔가 잘못되고 있음을 느끼고 급하게 스크립트 실행을 중지했습니다. 그리고 프로덕션 환경에 몇몇 테이블 데이터가 삭제되었음을 확인했습니다.
홀로 어둡고 조용한 밤길을 지나다 고양이 한 마리가 울음소리를 내며 빠르게 내 앞을 스쳐 지나갈 때의 그 느낌. 온몸이 경직되고 머릿속이 텅 비어 버리는 느낌. 저는 DB 장애를 발생시켰습니다.
즉시 장애 대응 채널에 장애 내용의 개요를 전파하고 서비스 긴급 점검을 걸었습니다. 떨리는 손가락으로 떠듬떠듬 로그를 확인하여 어떤 내용이 삭제되었는지를 파악했는데, 다행히 100% 복원 가능한 데이터 임을 확인했습니다. DB 백업은 하루에 한 번 전체 백업, 1시간에 한 번씩 증분 백업을 진행하고 있었습니다.
DB 복원 방법에 대해서 알고 있었지만, 평소 충분히 훈련되어 있지 않았기 때문에 검색과 확인을 반복하며 복원 작업을 하느라 시간이 꽤 오래 소요됐습니다. 약 2시간 30분 후 DB 복원이 무사히 진행된 것을 확인한 후 다시 서비스를 재개할 수 있었습니다. 하루 중 가장 높은 트래픽을 그리던 시간이었지만, 나의 실수로 낙타 등과 같은 그래프를 그려야 했던 날입니다.
장애 회고 및 조치
큰 힘에는 큰 책임이 따른다.
장애 회고 과정에서 가장 먼저 떠올랐던 문구입니다. 당시 저에겐 너무 큰 권한이 주어졌었습니다.
- 프로덕션 DB의 슈퍼 유저에 준하는 권한을 부여받음
- 프로덕션 DB에서는 읽기만 하면 되지만 읽기 전용으로 연결하지 않음
- 개발용 장비에서 프로덕션 DB에 대한 접근이 허용됨
- 운영과 개발 직무가 적절히 분리되지 않음
- 리뷰 과정이 생략됨
장애 회고를 통해서 도출했던 문제를 해결하기 위해서 권한의 축소와 권한의 적절한 분배를 시작했습니다. DBA를 채용하여 DB 운영 업무를 개발자로부터 분리하였고, 개발자와 DB 연결을 필요로 하는 소프트웨어 컴포넌트에는 각각의 계정과 계정에 필요로 하는 적절한 권한을 부여했습니다. 네트워크 접근 통제를 더 강화하여 운영 업무를 위해 인가된 사용자만 인가된 환경에서 접근할 수 있도록 했습니다. DB 운영 업무는 DBA 등 인가자가 수행하며 모니터링됩니다. 또한, 사전 계획과 리뷰를 통해서 안전하게 수행할 수 있는 업무 프로세스도 만들어 운영하기 시작했습니다.
지금 생각하면 당연히 이렇게 해야 했던 일들이 바쁘고 부족하다는 핑계로 쌓아왔던 기술 부채였고 이자까지 차곡차곡 쌓아서 상환할 수밖에 없었던 경험이었습니다.
사람은 반드시 실수를 합니다.
현재 많은 기술적 의사 결정을 함에 있어서 이를 전제로 판단하고 있습니다. 실수를 해도 이를 바로잡아줄 수 있는 업무 프로세스. 실수를 해도 이를 수용할 수 있는 시스템. 실수한 사람에게 책임을 묻지 않는 문화를 만들기 위한 고민을 계속하고 있습니다.
그날 늦은 시간까지 여전히 위축된 모습으로 장애 수습과 정리를 하고 있던 나를 위로해 주었던 동료와 상사 분들이 함께 고민해 주고 있기에 가능한 일입니다.
최소 권한 설계
SRE를 위한 시스템 설계와 구축 5장에서 최소 권한 설계를 설명합니다.
최소 권한 원칙은 사용자가 원하는 작업을 수행하기 위해 사람 또는 시스템으로부터 최소한의 접근 권한만 부여받는 것을 말한다. 이 제약은 개발 수명 주기의 시작 시점, 즉 새로운 기능에 설계 단계에서추가할 때 가장 효과적이다. 필요 이상의 권한을 부여하면 실수, 버그 또는 유출의 가능성이 커질 뿐이며 운영 중인 시스템에서 보안과 신뢰성 위험을 줄이거나 최소화하기가 훨씬 더 어려워진다.
위험의 종류로 접근 권한을 분류해보고 최소 권한을 강제하는 권장 사례들을 살펴본다. 그리고 현실 환경에서 이런 사례들을 도입할 때 고려해야할 절충 설정 분산에 대한 사례로 설명한다. 인증authentication과 승인authorization에 대한 정책 프레임워크를 살펴본 후에는 계정 탈취의 위험과 긴급 대응 엔지니어의 실수로 발생할 수 있는 위험 들을 완화하는 고급 인증 제어 기법을 설명한다. 그리고 최소 권한을 설계하다 보면 절충과 긴장이 발생할 수 있다는 점을 확실히 하면서 결론을 맺는다. 이상적인 환경이라면 시스템을 사용하는 사람은 그 의도가 분명해야 하며 에러 없이 원하는 작업을 완벽하게 안전한 방법으로 실행해야 한다. 안타깝게도 현실은 그렇지 않다. 엔지니어가 실수를 할 수도 있고, 엔지니어의 계정이 탈취당할 수 있으며 심지어 악의적인 공격자로 변하기도 한다. 따라서 시스템에 최소 권한을 설계하는 것이 중요하다. 즉, 시스템은 사용자가 수행하고자 하는 작업에 필요한 데이터와 서비스에 대한 접근을 제한해야 한다.
5장 서두에 최소 권한 원칙을 함축적으로 설명하는 내용입니다. 제가 이런 사실을 이해하고 있었더라면, 혹은 이런 환경이었다면, 앞서 소개한 문제를 겪지 않았을 지도 모르겠습니다. 이런 말도 나옵니다.
희망은 전략이 아니다.
막연히 실수하지 않고 잘 사용해 주기를 바라는 것은 비현실적입니다. 최소 권한 설계 원칙을 이해하고 실천하여 안전하게 통제 가능한 시스템을 설계해야 합니다.
개발자분들에게 이 책을 추천합니다.
일하다 보면 복잡한 스펙과 빡빡한 일정 때문에 보안, 가용성, 성능, 안정성 등에는 관심을 두지 못하고 개발만 하게 되는 경우가 있습니다. 그러다 보면 자연스럽게 여러 기술 부채를 지게 됩니다.
제가 겪은 상황처럼 이런 기술 부채는 단순히 코드의 개선점 수준이 아니라 장애 발생, 개인 정보 유출, 지나치게 많은 운영 비용 등 비즈니스에 위해를 가하는 치명적인 문제로 발현되기도 합니다.
보안, 안정성 등의 주제는 개발을 한참 진행하고 나서 개선하기가 만만치 않습니다. 개발 초기부터 목표와 설계에 포함하고 개발 업무 프로세스 전반에 걸쳐 반드시 필요한 프로세스로 내재화할 필요가 있습니다.
이 책은 개발자에게 이런 일들이 왜 중요한지에 대한 깊이 있는 통찰을 제공합니다. 서비스 설계 단계부터 개발, 배포, 운영, 장애 대응, 후속 조치와 이에 필요한 조직 문화에 이르기까지 우리가 실제로 고민하게 될 주제들을 폭넓게 이야기 하고있습니다.
이 책을 읽고 한 단계 더 좋은 개발자로 성장하는데 필요한 고민들을 해볼 수 있으면 좋겠습니다.
