[AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드코드]스터디 4주차
·
ETC
스터디 3주차 까지는 캐시 서버 & 시크릿 & 카나리 배포 전략을 테스트했었는데 7장부터는 SMB에서 엔터프라이즈 급으로 규모가 확장되었을 때 어떤 것들을 고려해야하는지, 고도화를 위해서는 어떤 서비스를 추가해서 어떻게 운영해야하는지 실습해보도록 한다.1주차: https://canaryrelease.tistory.com/122 2주차: https://canaryrelease.tistory.com/123 3주차: https://canaryrelease.tistory.com/1247장. 규모 확장7.1 성장통: SMB 구조의 한계지금까지 Notiflex는 단일 노드풀(default-pool)에 모든 워크로드가 섞여 있고, 테넌트는 smb 하나뿐이다. 관측 스택, ArgoCD, Valkey, 앱이..
[AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드코드]스터디 3주차
·
ETC
스터디 2주차에는 지난번에 이어서 GKE 클러스터 위에서 클로드 코드를 활용해서 배포 파이프라인과 모니터링 스택을 구축한다.1주차: https://canaryrelease.tistory.com/122 2주차: https://canaryrelease.tistory.com/123 5장. 무중단 배포5.1 Rolling Update는 왜 서비스가 끊기는가Rolling Update는 파드를 하나씩 갈아끼우니 언뜻 무중단처럼 보인다. 문제는 세 가지다. Ready와 "진짜 준비됨"의 간극. readinessProbe가 통과했다고 앱이 트래픽을 완벽히 처리할 수 있는 건 아니다. 커넥션 풀 워밍업, 캐시 로딩 같은 것들이 끝나기 전에 트래픽이 꽂히면 그 요청들은 느리거나 실패한다.검증 창구가 없다. 새 버전..
AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드코드 스터디: CH03-04
·
ETC
스터디 2주차에는 지난번에 이어서 GKE 클러스터 위에서 클로드 코드를 활용해서 배포 파이프라인과 모니터링 스택을 구축한다.1주차: https://canaryrelease.tistory.com/1223장. 첫 번째 배포 파이프라인3.1 푸시 기반 배포의 한계2장까지의 배포는 kubectl apply로 내가 클러스터에 직접 밀어넣는(push) 방식이었다. 푸시 방식의 한계는 다음과 같다.누가 언제 어떤 버전을 배포했는지 기록이 없음롤백하려면 이전 매니페스트를 어딘가에서 찾아와 다시 apply해야 함누군가 kubectl edit으로 클러스터를 직접 고치면 추적이 안 됨책은 이 문제의 해법을 명령형에서 선언형으로의 사고 전환이라고 정리한다. "최종 상태는 이거다"(선언형)를 Git에 선언해두면, 클러스터가 그..
[AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드코드]스터디 1주차
·
ETC
요즘 개인 공부에 너무 소홀했던 것 같아 스터디를 시작했다. “AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드” 라는 책을 읽고 공부한 내용을 올리는 모각코 형식의 스터디이고 이번주는 챕터 1~2를 읽고 실습한 후 공부한 내용에 대해 포스팅을 진행해야 한다. CH01. AI 시대, 개발자의 인프라1.1 개발자에게 인프라가 다가온 시대"you build it, you run it" Amazon의 CTO Werner Vogels가 20년 전 인터뷰에서 언급한 '제품팀에서 개발과 운영을 같이 진행한다'라는 개념은 이제는 당연하게 다가온다. 하지만 현실에서는 "개발" 조직에서 클라우드 서비스 등의 "인프라" 영역을 제대로 같이 하는 경우는 AWS SDE 말고는 보지 못했던 것이 사실인데..