고민보단 실천을

GitHub Actions 동시성 제어: concurrency + cancel-in-progress로 배포 경합 막기같은 환경에 배포가 동시에 돌면 마지막 커밋이 아닌 버전이 올라가거나 롤백이 뒤섞인다. concurrency로 경합을 막는 최소 설정을 정리한다.설정 예시concurrency: group: staging-${{ github.ref }} cancel-in-progress: true환경 단위로 그룹 나누기staging은 최신 커밋만 남기기(cancel-in-progress=true).prod는 순차 실행이 안전할 때가 많다(cancel-in-progress=false).그룹 키에 환경을 반드시 포함한다(섞여 취소되는 사고 방지).concurrency: group: prod-${{ gith..

Docker Compose 로컬 개발 환경 표준화: healthcheck, depends_on, 초기화 스크립트로컬 환경이 흔들리면 온보딩/디버깅 비용이 올라간다. Compose로 누가 돌려도 같은 환경을 만드는 방법을 healthcheck 중심으로 정리한다.depends_on의 오해depends_on은 시작 순서만 보장한다. DB가 준비됐는지는 healthcheck로 보장해야 한다.compose 예시services: postgres: image: postgres:16 healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d app"] interval: 3s retries: 20 api: depends_on:..

배포 전략 비교: Rolling vs Blue-Green vs Canary, 언제 무엇을 선택할까배포 전략은 예쁜 그림이 아니라 장애 반경과 롤백 속도를 결정한다.한 줄 요약Rolling: 기본값. 혼종 상태가 생겨 검증이 어렵다.Blue-Green: 스위치 기반. 롤백이 빠르지만 비용이 든다.Canary: 일부 트래픽만 새 버전. 관측/판단 체계가 필요하다.Kubernetes Deployment(rollingUpdate) 예시spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 0배포 판단 지표 예시에러율: 5xx 비율, 핵심 API 실패율지연: p95/p99, 타임아웃 비율비즈니스..

Trivy로 컨테이너 취약점 스캔 CI 만들기: 실패 기준(Severity)과 예외 운영법취약점 스캔은 '0개'가 목표가 아니라, 팀이 운영 가능한 기준을 만드는 게 목표입니다.Trivy를 CI에 붙이고, 실패 기준과 예외(allowlist) 운영을 어떻게 하면 덜 괴로운지 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)취약점 스캔은 '0개'가 목표가 아니라, 팀이 운..

Terraform 운영 실전: remote state, state lock, drift 감지로 사고 줄이기Terraform 사고의 대부분은 코드가 아니라 state 운영에서 시작합니다.remote state, state lock, drift 감지를 기본값으로 두는 운영 방법을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)Terraform 사고의 대부분은 코드가 아니라..

Supply Chain 보안 입문: SBOM과 SLSA를 '지금 팀'에 맞게 도입하는 방법요즘 보안은 코드보다 '빌드/배포 파이프라인'이 먼저 털립니다.SBOM과 SLSA를 유행어가 아니라, 팀이 운영 가능한 최소 단위로 도입하는 방법을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)API/HTTP 영역은 '작은 정책'이 전체 사용자 경험과 운영 비용을 바꿉니다. 그래서 실무에서는 구현보다도 기준(정책)과 검증 루프가 중요합니다.특히 프록시/CDN/게이트웨이가 있는 환경에서는 서버 코드만 보면 원인을 놓치기 쉽습니다. 레이어를 같이 정리해두면 같은 장애를 반복하지 않게 됩니다.실전 내용(바로 적용..

MySQL 온라인 스키마 변경: pt-online-schema-change vs gh-ost 선택 기준과 운영 함정MySQL 스키마 변경은 트래픽이 있으면 곧 장애가 될 수 있습니다.pt-osc와 gh-ost의 차이, 그리고 운영에서 터지는 함정을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)MySQL 스키마 변경은 트래픽이 있으면 곧 장애가 될 수 있습니다.pt-o..

Kubernetes Taints/Tolerations 실전: 특정 워크로드를 전용 노드에 격리하는 법특정 워크로드(배치/ML/로그)가 전체 노드를 흔들면, 결국 '격리'가 필요합니다.Taints/Tolerations로 전용 노드를 만드는 기본 패턴을 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)특정 워크로드(배치/ML/로그)가 전체 노드를 흔들면, 결국 '격리'가 필..

Kubernetes 시크릿 운영: Secret vs External Secrets(Secrets Manager) 무엇을 언제 쓰나시크릿은 저장하는 것보다 '로테이션'이 더 어렵습니다.K8s Secret과 External Secrets(Secrets Manager/Vault) 조합을 실무 기준으로 정리합니다.이 글의 목표는 '개념 정리'보다, "어떤 기준으로 결정할지"와 "어떻게 운영에서 사고를 줄일지"를 남기는 것입니다.왜 이게 어려운가(운영 관점)운영 이슈는 대부분 한 설정이 아니라 '정렬되지 않은 설정 조합'에서 나옵니다(타임아웃, 종료, 리소스, 재시도).따라서 증상 -> 원인 -> 검증 루틴을 팀 표준으로 만들면, 장애 대응 시간이 크게 줄어듭니다.실전 내용(바로 적용)시크릿은 저장하는 것보다 '..