Somaz의 IT 공부 일지

Runbook 작성과 자동화: Toil을 줄이는 운영 절차 만들기

Overview운영 절차는 대개 누군가의 머릿속이나 메신저 대화 어딘가에 있다. 같은 작업을 하는 사람마다 순서가 조금씩 다르고, 장애가 나면 그 절차를 아는 사람을 먼저 찾아야 한다. 절차를 문서로 적은 것이 런북(runbook)이고, 그 문서대로 손으로 되풀이하는 일이 Google SRE가 말하는 toil이다. 이 글은 Google SRE Book과 SRE Workbook이 정의하는 toil과 그 측정 방법, 런북과 플레이북(playbook)이라는 말이 문서마다 어떻게 쓰이는지, 런북에 적을 항목, 다시 실행해도 안전한 단계를 쓰는 법, 그리고 런북을 어떤 순서로 자동화할지를 정리한다. Kubespray 업그레이드 절차 자체는 Kubernetes 클러스터 업그레이드하기 (kubespray 2026v...

OverviewMTTR은 장애 대응을 이야기할 때 가장 먼저 나오는 숫자다. 그런데 R이 무엇의 약자인지부터 팀마다 다르다. Atlassian의 인시던트 지표 문서는 R이 repair, recovery, respond, resolve 네 가지를 뜻할 수 있다고 적고, MTTR을 추적하기 전에 어떤 MTTR을 말하는지부터 맞추라고 권한다. 이 글은 그 네 가지 뜻, 측정을 시작하고 끝내는 시점, MTBF와 가용성 계산, 장애 시간을 평균으로 요약할 때 생기는 문제, DORA가 MTTR이라는 이름을 버린 경위를 정리한다. 마지막으로 장애 시작 시각을 알 수 없어 MTTR을 측정할 수 없었던 세 사례를 다룬다. 이 사례들에는 측정한 MTTR 수치가 없다. 글에 나오는 장애 시각과 장애 시간 예시는 모두 설명을..

OverviewGitHub CLI(gh)는 GitHub에서 공식적으로 제공하는 커맨드라인 도구로, 터미널에서 직접 GitHub의 다양한 기능을 사용할 수 있게 해준다. 브라우저로 GitHub에 접속하지 않고도 Pull Request 생성, Issue 관리, Repository 클론, GitHub Actions 모니터링 등 거의 모든 작업을 터미널에서 수행할 수 있다. 기존에는 git 명령어로 버전 관리만 가능했지만, gh 명령어를 함께 사용하면 GitHub 플랫폼의 기능까지 통합적으로 제어할 수 있어 DevOps 엔지니어나 개발자에게 매우 유용하다. 특히 CI/CD 파이프라인이나 자동화 스크립트에서 --json 플래그를 통해 구조화된 출력을 얻을 수 있어 활용도가 높다. 이 글에서는 Linux, macO..

Overview클라우드 네이티브 환경의 엔터프라이즈 보안은 크게 빌드 시점의 이미지 취약점 분석, 배포 시점의 어드미션 컨트롤 정책 검증, 그리고 애플리케이션이 실제로 구동되는 런타임 보호의 세 단계로 나뉜다. 많은 조직이 Harbor나 Trivy를 통한 정적 컨테이너 이미지 스캐닝과 Kyverno나 OPA/Gatekeeper를 통한 배포 매니페스트 제약 조건을 갖추고 있다. 그러나 이미 정상적으로 서명되고 검증을 통과하여 클러스터에 배포된 파드 내부에서 제로데이 취약점을 악용한 원격 코드 실행(RCE), 허가되지 않은 대화형 쉘 실행, 권한 상승, 혹은 암호화폐 채굴 프로세스가 구동되는 런타임 침해 사고는 정적 검사 도구만으로는 탐지할 수 없다. Falco는 클라우드 네이티브 컴퓨팅 재단(CNCF)의 ..

Overview포스트모텀(Postmortem)은 Google SRE Book의 정의에 따르면 인시던트와 그 영향, 완화하거나 해결하려고 취한 조치, 근본 원인, 재발을 막기 위한 후속 조치를 적은 기록이다. 장애를 고치는 일과 그 장애를 문서로 남기는 일은 다른 기술이고, 후자는 양식과 문장의 문제에 가깝다. 이 글은 그 기록을 쓰는 방법을 다룬다. 쓰는 기준과 양식, 계기와 근본 원인을 나누는 법, 5 Whys와 그 한계, 원인이 하나라는 전제의 문제, 사람을 탓하는 문장 고치기, 조치 항목 추적까지 정리한다. 마지막에는 이 블로그의 두 글을 양식에 맞춰 다시 써 본다. 언제 쓸지 미리 정하기SRE Book 15장은 포스트모텀에 시간과 노력이 든다는 점을 인정하고, 그래서 쓸 때를 신중하게..

Overview인프라의 규모가 수백 대에서 수만 대 단위로 확장될수록 서버 설정 관리와 원격 제어의 속도 및 신뢰성은 전체 서비스 안정성을 좌우하는 핵심 요소가 된다. 기존의 많은 엔지니어링 조직이 SSH 기반의 에이전트리스 도구인 Ansible을 활용해 왔으나, 대규모 동시 명령 실행 시 발생하는 SSH 연결 오버헤드와 순차 실행에 따른 지연 문제는 지속적인 운영 병목으로 지적되었다. 이러한 문제를 근본적으로 해결하기 위해 설계된 도구가 바로 고성능 비동기 메시징 버스인 ZeroMQ를 기반으로 동작하는 SaltStack(Salt)이다. SaltStack은 이벤트 기반 아키텍처(Event-Driven Architecture)를 중심으로 중앙 Master와 노드 Minion 간의 양방향 통신을 지원하여 대..

Overview클라우드 네이티브 환경의 엔터프라이즈 보안은 정적 이미지 취약점 스캐닝(Trivy, Grype)과 배포 시점의 어드미션 컨트롤(Kyverno, Gatekeeper)만으로는 완성될 수 없다. 사전에 정상 검증을 통과한 파드라 할지라도 런타임 단계에서 제로데이 취약점을 악용한 원격 코드 실행(RCE), 비인가 셸 탈취, 권한 상승(Privilege Escalation), 컨테이너 탈출(Container Escape)과 같은 실시간 침해 위협에 직면한다. 따라서 커널 레벨에서 컨테이너 내부의 모든 행위를 지속적으로 감시하고 위협 발생 즉시 무력화하는 런타임 보안 체계가 필수적이다. 기존의 대표적인 런타임 보안 도구들은 시스템 콜(System Call) 이벤트를 링 버퍼(Ring Buffer)를 ..

Overview쿠버네티스 환경에서 애플리케이션 배포와 인프라 형상을 코드로 관리하는 GitOps 파이프라인의 사실상 표준(de-facto standard) 도구로 ArgoCD가 자리잡았다. 단일 퍼블릭 클라우드를 넘어 AWS, GCP, Azure 전반에 워크로드를 분산 배치하는 멀티 클라우드 환경이 보편화되면서, 각 클라우드의 관리형 쿠버네티스 서비스에 일관된 방식으로 ArgoCD를 배포하고 외부 접근을 통제하는 아키텍처 설계가 필수적이다. 하지만 실제 운영 환경에서는 클라우드 제공업체마다 IAM 인증 체계와 인그레스(Ingress) 트래픽 라우팅 메커니즘이 근본적으로 다르다. AWS EKS는 과거 문법 오류 시 클러스터 접근이 차단되던 `aws-auth` ConfigMap을 폐기하고 AWS API 레벨..

Overview클라우드 네이티브 환경에서 쿠버네티스 워커 노드를 운영할 때 대표적으로 간과하기 쉬운 보안 사각지대는 바로 노드 레벨의 호스트 운영체제(OS)다. 대다수의 엔지니어링 팀은 Amazon Linux 2(AL2), Amazon Linux 2023(AL2023), 혹은 Ubuntu 같은 범용 리눅스 배포판을 EKS 워커 노드 AMI로 채택한다. 그러나 범용 OS는 패키지 관리자(yum, dnf, apt), 파이썬/펄 같은 스크립트 인터프리터, 수많은 유틸리티와 기본 셸(bash)을 내장하고 있어 컨테이너 구동이라는 단일 목적에 비해 공격 표면(Attack Surface)이 지나치게 넓다. 또한 엔지니어가 SSH나 SSM으로 노드에 임의로 접속해 설정을 바꾸면서 발생하는 구성 드리프트(Configu..

Overview한동안 우리 클러스터는 GitLab을 모든 앱의 OIDC Identity Provider로 써 왔다. ArgoCD는 내장 dex의 GitLab connector를, Harbor는 native OIDC 엔드포인트를, Vaultwarden은 SSO authority로 각각 GitLab을 바라보는 구조였다. 잘 굴러가긴 했지만 새 요구사항이 생길 때마다 — LDAP 연동, MFA 정책, 세션 수명, SSO 전용 관리 도구 등 — GitLab에 새 기능을 욱여넣거나 별도 인증 레이어를 또 하나 띄워야 했다. 결국 대부분의 팀이 도달하는 결론을 우리도 따랐다. GitLab 앞에 Keycloak을 중앙 IdP로 두고, Identity Brokering으로 기존 GitLab 계정을 그대로 쓰면서, 다운..