장애가 났을 때 ‘서버가 느립니다’는 알지만 ‘왜 느린지’는 모르는 상황, 익숙하실 겁니다. 전통적 모니터링은 알고 있는 문제만 잡지만, 옵저버빌리티는 예상치 못한 문제도 사후에 파고들 수 있게 해줍니다. 그 토대가 로그, 메트릭, 트레이스라는 세 기둥입니다.운영 문제: 데이터는 많은데 답이 없다세 신호를 각각 따로 수집하면, 메트릭에서 지연 급증을 봐도 어느 요청 때문인지 추적할 수 없습니다. 옵저버빌리티의 진짜 가치는 세 신호를...
트래픽이 평소의 10배로 치솟는 이벤트 날, 시스템은 버텨야 하지만 평소에는 그만한 자원을 놀릴 수 없습니다. 오토스케일링은 이 모순을 해결하는 핵심 기술이지만, 잘못 설정하면 너무 늦게 늘어 장애가 나거나 너무 민감하게 출렁여 비용이 새어 나갑니다.운영 문제: 고정 용량의 딜레마피크에 맞춰 자원을 고정하면 평소엔 80%가 유휴이고, 평균에 맞추면 피크에 무너집니다. 정적 용량 계획으로는 비용과 안정성 중 하나를 반드시 포기해야 합니다. 오토스케일링은 수요에 따라 용량을...
콘솔에서 클릭으로 만든 인프라는 누가 무엇을 바꿨는지 기록이 없고, 같은 환경을 다시 만들 수도 없습니다. IaC(Infrastructure as Code)는 인프라를 선언적 코드로 정의해 버전 관리, 리뷰, 재현을 가능하게 만듭니다. 이 글은 테라폼류 도구로 운영할 때의 실전 패턴을 다룹니다.운영 문제: 드리프트와 눈송이 서버코드로 만든 인프라도 누군가 콘솔에서 손대면 코드와 실제 상태가 어긋나는 ‘드리프트’가 생깁니다. 또 환경마다 미묘하게 다른...
새벽 3시, 휴대폰이 울립니다. 결제 성공률이 급락했다는 알림입니다. 잠에서 덜 깬 채로 노트북을 여는 그 순간이, 사실 한 조직의 운영 성숙도를 가장 정직하게 드러냅니다. 이 글은 여러 장애를 겪으며 배운 것들을 회고합니다.운영 문제: 영웅에 의존하는 대응의 한계초기에는 시스템을 가장 잘 아는 한 사람이 모든 장애를 해결했습니다. 빠르지만 위험한 구조였습니다. 그 사람이 휴가를 가면 복구가 멈췄고, 지식은 그의 머릿속에만 있었습니다. 좋은 온콜은 영웅이 아니라 누구나 따라갈...
컨테이너는 빠르고 가볍지만, 그 가벼움이 곧 보안 책임의 분산을 뜻합니다. 베이스 이미지의 오래된 라이브러리, 과도한 권한, 노출된 시크릿 등 빈틈은 여러 단계에 흩어져 있습니다. 보안은 한 곳을 막는 게 아니라 빌드부터 런타임까지 층층이 막는 다층 방어(defense in depth)여야 합니다.운영 문제: 공격면은 이미지에서 시작된다많은 사고가 이미지 단계에서 시작됩니다. 거대한 베이스 이미지에는 수백 개의 패키지가 들어 있고, 그중 하나의 알려진 취약점(CVE)이 침투...
e-wikidversity