구독 중인 기술 블로그 RSS 피드 목록 이 블로그는 다양한 기술 소식을 RSS 피드로 구독하여 콘텐츠를 생성하고 있습니다. 토스 기술 블로그: https://toss.tech/rss.xml 카카오 기술 블로그: https://tech.kakao.com/feed/ 당근(Daangn) 미디엄 블로그: https://medium.com/f...

서론: 오늘의 문제 Terraform 도입은 첫 apply가 아니라 이후 수동 변경과 provider 진화를 통제하는 운영 체계다. 정기 drift 탐지, 정책 검사, 업그레이드와 비상 변경의 되돌림을 설계한다. 1. Drift의 종류 콘솔 수동 변경, 외부 자동화, provider 기본값 변화, 삭제된 자원은 서로 다른 대응이 필요하다. 차이를...

서론: 오늘의 문제 코드 구조 변경이 실제 인프라의 삭제와 재생성을 뜻할 필요는 없다. import, moved, removed 블록으로 코드 주소와 실제 객체의 연결을 명시적으로 이관한다. 1. 주소 변경의 위험 리소스 블록 이름이나 module 경로가 바뀌면 Terraform은 기존 주소가 사라지고 새 주소가 생겼다고 해석할 수 있다. 리팩터...

서론: 오늘의 문제 IaC 파이프라인의 핵심은 자동 apply가 아니라 사람이 검토한 계획과 실제 실행된 계획을 일치시키는 것이다. PR, 저장된 plan, 승인과 동시성 제어를 하나의 흐름으로 묶는다. 1. Speculative Plan PR에서는 예상 변경을 보여 주는 speculative plan으로 추가, 수정, 삭제와 교체를 검토한다. ...

서론: 오늘의 문제 좋은 Terraform module은 리소스를 숨기는 상자가 아니라 조직의 인프라 결정을 재사용 가능한 계약으로 표현한다. 입력, 출력, 버전과 책임 범위를 작게 유지한다. 1. 추상화의 단위 provider 리소스 한 개를 그대로 감싼 module은 가치가 작다. 네트워크가 포함된 서비스 실행 환경처럼 함께 변경되고 같은 정...

서론: 오늘의 문제 Terraform state는 캐시 파일이 아니라 선언한 주소와 실제 자원을 연결하는 운영 장부다. 저장 위치, 잠금, 접근 권한과 복구 절차를 먼저 설계해야 협업이 안전해진다. 1. State가 저장하는 것 state는 리소스 주소와 원격 객체 식별자를 연결하고 의존성 계산에 필요한 메타데이터를 보관한다. 실제 인프라를 다시...

서론: 오늘의 문제 계측 라이브러리를 설치했다고 관측성이 완성되지는 않는다. 공통 의미 규칙, 비용 예산, 품질 검사와 단계적 전환으로 팀이 신뢰하는 플랫폼을 만든다. 1. 관측 질문에서 시작하기 먼저 사용자가 실패하는 지점, 지연의 원인, 용량 한계를 어떤 질문으로 찾을지 정한다. 신호 수집량이 아니라 답할 수 있는 운영 질문의 수를 성과로 본...

서론: 오늘의 문제 애플리케이션이 관측 백엔드마다 다른 exporter를 직접 관리하면 교체와 정책 통제가 어렵다. Collector의 receiver, processor, exporter를 데이터 파이프라인으로 설계한다. 1. Agent와 Gateway 토폴로지 노드 가까이에서 수집해야 하는 파일 로그와 중앙에서 처리할 trace를 구분한다. ...

서론: 오늘의 문제 로그는 사람이 읽는 문장만이 아니라 trace와 metric을 연결하는 구조화된 사건이다. 기존 로깅 라이브러리를 유지하면서 공통 필드와 민감 정보 정책을 정한다. 1. 구조화 로그의 최소 필드 timestamp, severity, service, environment, event name을 안정된 필드로 둔다. 메시지 문구가...

서론: 오늘의 문제 메트릭은 값 하나보다 이름, 단위, 속성 집합이 만든 시계열 계약이 중요하다. counter, gauge, histogram을 올바르게 선택하고 카디널리티 예산을 운영한다. 1. 계측기 선택 누적 사건은 counter, 오르내리는 현재 상태는 gauge 계열, 분포는 histogram으로 표현한다. 같은 현상을 여러 타입으로 ...