Somaz의 IT 공부 일지

Chaos Mesh 실전 가이드: 가설 수립부터 PodChaos·NetworkChaos 실험과 복구 검증까지

Overview단일 장애점과 영향 범위 글에서 서버를 여러 대 두어도 같은 의존성을 공유하면 함께 멈춘다고 정리했다. 그 판단은 구성도를 읽고 내린 것이다. 정말 함께 멈추는지, 대체 응답(Fallback)을 넣으면 정말 버티는지는 장애를 넣어 봐야 안다. 이 글은 그런 주장을 가설로 바꾸고 Chaos Mesh의 PodChaos와 NetworkChaos로 시험한 기록이다. 설치 절차는 결과에 영향을 준 값만 다루고, 가설별 측정 결과를 중심으로 정리한다. 가장 먼저 볼 것은 Chaos Mesh가 주입에 성공했다고 보고했는데 실제 트래픽에는 아무 영향이 없던 경우다. 이어서 pod-kill과 프로세스 크래시의 차이, readiness 설계가 부분 장애를 전면 장애로 키우는 조건, 지연이 장애로 바뀌는 지점..

GitLab CLI(glab)로 터미널에서 GitLab 다루기 — 설치부터 Self-Hosted 인증, CI/CD, MR 관리까지

Overview평소 GitLab을 사용하다 보면 파이프라인 상태 확인, 실패한 잡 재시도, MR 리뷰 등을 위해 매번 웹 UI로 들어가야 하는 번거로움이 있다. GitHub의 gh CLI처럼 GitLab도 공식 CLI인 glab 을 제공하는데, 이를 활용하면 터미널을 벗어나지 않고 대부분의 작업을 처리할 수 있다. 특히 사내 Self-Hosted GitLab 환경에서 Kubernetes 인프라 레포지토리를 운영하다 보면 CI 파이프라인 모니터링과 manual job 트리거를 자주 하게 되는데, 매번 브라우저를 열기보다 터미널에서 한 줄로 처리하는 게 훨씬 효율적이다. 이번 글에서는 glab 설치, Self-Hosted GitLab 인증, 그리고 실제 자주 쓰는 명령어들을 정리해두려 한다. 1. ..

Istio Ambient Mesh 완벽 가이드: 사이드카 없는 ztunnel·Waypoint 아키텍처부터 무중단 L4·L7 서비스 메시 구축까지

Overview쿠버네티스 환경에서 마이크로서비스 간 보안 통신(mTLS), 트래픽 라우팅, 관측성을 제공하는 사실상의 표준(de-facto standard) 솔루션으로 Istio가 널리 사용되어 왔다. 하지만 기존 Istio는 모든 애플리케이션 파드마다 Envoy 프록시를 보조 컨테이너로 삽입하는 사이드카(Sidecar) 아키텍처를 고수해 왔다. 이 방식은 대규모 클러스터에서 극심한 메모리 및 CPU 오버헤드를 유발하고, 프록시 설정이나 버전 업그레이드 시마다 대상 애플리케이션 파드를 강제로 재시작해야 하는 무거운 운영 부담을 안겨주었다. 이러한 사이드카 패턴의 구조적 한계를 근본적으로 해결하기 위해 정식 프로덕션 지원(GA) 단계에 도달한 혁신적 아키텍처가 바로 Istio Ambient Mesh이다. ..

단일 장애점과 영향 범위: 이중화해도 함께 멈추는 구성과 격리 경계 설계

Overview서버를 두 대로 늘리면 단일 장애점(SPOF)이 해결되었다고 생각하기 쉽다. 하지만 두 서버가 동일한 데이터베이스와 설정을 공유하고 같은 배포를 받는다면, 장애가 발생했을 때 두 대는 한 묶음으로 동시에 멈춘다. 단순히 서버 대수를 늘린다고 해서 공통 원인으로 인한 동시 장애 위험까지 사라지지는 않는다. 이 글에서는 이중화(Redundancy)의 규모를 단순한 서버 대수가 아니라 '공통 실패 단위(Unit of Failure)'를 기준으로 산정하는 법을 정리하고, 자원을 여분으로 두는 이중화와 장애 확산을 가두는 격리 경계(Blast Radius 제한)의 차이를 짚어본다. 나아가 결함이 있는 배포가 어떻게 격리 경계를 뚫고 전역 장애로 번지는지 분석한 뒤, 실제 사내 포털 무상태화 작업과 ..

Overview지난 SaltStack 완벽 가이드 (Part 1)에서는 고성능 ZeroMQ 메시징 버스를 기반으로 한 Master-Minion 아키텍처, 안전한 암호화 키 교환, 동적 타겟팅을 통한 대규모 원격 실행 기법, 그리고 Grains와 Pillar를 활용한 시스템 데이터 분리 원칙을 살펴보았다. 단일 명령을 수천 대의 노드에 밀리초 단위로 브로드캐스팅하는 원격 실행(Execution Module)이 Salt의 뛰어난 속도를 보여주었다면, 인프라의 기대 상태(Desired State)를 지속적으로 유지하고 장애에 즉각 반응하는 오케스트레이션 능력은 SaltStack의 핵심 가치인 State와 Reactor 시스템에서 완성된다. 기존의 절차적 스크립트나 단순 플레이북 기반 자동화는 특정 작업이 실패..

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장은 포스트모텀에 시간과 노력이 든다는 점을 인정하고, 그래서 쓸 때를 신중하게..