라이프

AWS 서비스를 이번에 좀 정리하면서 분명 종료를 했는데 안없어진 리소스들이 좀 있더라구요. 거기서 돈이 새고 있던겁니다. 근데 종료를 했으면 그냥 없어져야하는거 아닌가? 왜 안없어지지?클라우드 민주화의 그늘, '잊혀진 리소스'클라우드의 가장 큰 장점은 누구나 몇 번의 클릭이나 API 호출만으로 강력한 인프라를 즉시 구축할 수 있다는 '민첩성'에 있습니다. 하지만 이 민첩성은 역설적으로 '관리의 부재'라는 부작용을 낳습니다. 테스트를 위해 생성했다가 삭제를 잊은 EBS 볼륨, 인스턴스는 종료되었지만 여전히 요금이 부과되는 탄력적 IP(EIP), 그리고 주인을 잃은 채 떠도는 수많은 스냅샷들. 우리는 이러한 자원을 '좀비 자원(Zombie Assets)' 혹은 '유령 자원'이라 부릅니다. 이들은 대시보드 ..

첫 회사에서 겪었던 것 가장 기억에 남는것이 Jenkins 서버가 단일 서버였고, 사내 직원이 10명도 되지도 않던 상황에 고가용성을 챙기기 위하여 t3.xlarge 서버를 두개 올렸던것이 기억에 남아 글을 작성 합니다.가용성은 결코 공짜가 아니다현대 인프라 엔지니어링의 궁극적인 지향점은 '절대 죽지 않는 시스템'입니다. 우리는 서비스의 연속성을 보장하기 위해 다중 가용 영역(Multi-AZ)을 구성하고, 리전 간 복제(Inter-Region Replication)를 구축하며, 스택의 모든 레이어에 이중화를 적용합니다. "우리 서비스는 99.99%의 가용성을 보장합니다"라는 문구는 엔지니어에게는 자부심의 상징이며, 비즈니스 측면에서는 강력한 고객 신뢰의 자산이 됩니다. 하지만 FinOps의 관점에서 바라..

비용에 관련된 주제가 자꾸 늘어나는데, 이건 필수적인 요소라서 좀 많이 다루고 싶다는 생각을 했습니다. 비용과 프로젝트의 연결고리 이게 절대로 갈라놓을 수 없는 주제거든요. 옛날 개발팀과 같이 인프라에 대한 설계 할때도 알았으면 얼마나 좋았을까를 생각해보면서 글 작성해보려고 합니다. "비용이 늘었는데, 우리 서비스는 건강한가요?"클라우드 인프라를 운영하며 가장 곤혹스러운 순간은 재무팀이나 경영진으로부터 "이번 달 클라우드 비용이 지난달보다 $20\%$ 늘었는데, 왜 그런가요?"라는 질문을 받을 때입니다. 엔지니어는 "사용자가 늘어서 인스턴스를 증설했습니다"라고 답할 수 있지만, 이는 절반의 대답에 불과합니다. 비즈니스 관점에서는 비용의 절대적인 액수보다, 그 비용이 '수익 창출에 얼마나 효율적으로 기여했..

Jenkins 서버를 설치하면서 이 서버는 스펙이 변하지 않을 거라며 예약 인스턴스를 걸었던 것이 생각이 나네요. 선입금 하고 더 싸게 쓰는 방향이죠. 근데 그때는 왜 제대로 분석하지 않고 예약 인스턴스를 먼저 걸어서 서버를 놀게 두었을까요 하는 생각을 하며 글 적어봤습니다.온디맨드(On-Demand)를 넘어선 극강의 비용 효율성클라우드 비용 최적화의 여정에서 RI(Reserved Instances)나 SP(Savings Plans)가 안정적인 '적금'과 같다면, 스팟 인스턴스(Spot Instance)는 시장의 변동성을 활용하여 수익을 극대화하는 '공격적인 투자'와 같습니다. 클라우드 서비스 제공자(CSP)가 남는 유휴 자원을 수요에 따라 유동적으로 제공하는 스팟 인스턴스는 온디맨드 대비 최대 90%라..

이건 공부할때 알았던 건 입니다. 이게 의외로 네트워크 비용이 무시 못할 정도라는걸 알았거든요. 근데 책이나 Docs 문서에서는 대부분 그걸 꽁꽁 숨겨둡니다. 마치 잘 사용 안하는 구독 서비스 같은 느낌이더라구요. 그래서 그거 관련해서 글 써봅니다.청구서 속에 숨겨진 '네트워크'라는 복병클라우드 인프라를 운영하면서 가장 예측하기 힘든 비용 항목은 무엇일까요? 컴퓨팅 자원은 인스턴스 개수를 세면 되고, 스토리지는 사용량을 확인하면 됩니다. 하지만 네트워크 비용, 특히 Data Transfer Out(DTO)은 눈에 보이지 않는 공기처럼 흐르다가 월말 청구서에서 가장 날카로운 비수로 돌아옵니다. 많은 조직이 컴퓨팅 자원의 라이트사이징(Rightsizing)에는 심혈을 기울이지만, 데이터가 네트워크의 경계를 ..

로그가 지금 참 중요한 상황들이죠. 왜냐면 여러 시스템이 엮여있는 상황이기도 하고 이 문제를 파악하려면 로그와 모니터링 아니면 파악이 불가능 할 정도로 세분화 되어 있으니까요. 그래서 로그에 관련해서 비용은 어떻게 관리 해야하나 하고 생각이 들어 글 써봅니다.모든 것을 보려다 모든 것을 잃는 시대모던 마이크로서비스 아키텍처(MSA)에서 관측성(Observability)은 시스템의 건강 상태를 파악하기 위한 필수 인프라입니다. 시스템이 파편화되고 복잡해질수록 엔지니어는 더 상세한 로그(Logs), 더 촘촘한 메트릭(Metrics), 그리고 요청의 흐름을 추적하는 트레이싱(Tracing) 데이터를 요구합니다. 하지만 아이러니하게도 시스템의 투명성을 높이기 위해 도입한 모니터링 도구들이 때로는 실제 서비스를 ..

콜드 스토리지, 핫 스토리지 같은 말들이 왜 있는지 생각해보다가 S3 를 비용을 우습게 생각하는 경우들이 많은거 같더라구요. 그래서 이런 저런 커뮤니티 찾아보니 다들 비슷하더군요. 그래서 글 한번 적어봅니다."S3는 저렴하다"라는 착각이 만든 비용의 늪클라우드 인프라를 운영하며 가장 관리하기 까다로운 영역 중 하나가 바로 스토리지입니다. 컴퓨팅 자원(EC2 등)은 사용하지 않을 때 끄거나 사양을 낮추는 방식으로 즉각적인 비용 절감이 가능하지만, 스토리지는 한 번 생성되면 데이터가 삭제되기 전까지 비용이 계속 누적되는 '축적의 영역'이기 때문입니다. 일반적으로 $1GB$당 몇십 원 수준인 S3의 단가는 저렴해 보입니다. 이로 인해 로그 데이터, 백업 파일, 이미지 리소스를 무분별하게 쌓아두는 경향이 생깁니..

자동화란 말은 너무 많이 듣는거 같습니다. 근데 안할순 없어요. 본인이 서버 200개 운영 한다고 할 때 배포 한다고 하면 엔터 1회를 200번 하는거니까요. 인프라 비용하고도 큰 연관이 있죠. 50개씩 네명이 하는 것 보다는 200개를 한 사람이 하는게 더 싸니까요.왜 '분석'만으로는 비용을 통제할 수 없는가?클라우드 FinOps의 첫 번째 단계는 대개 '가시성 확보'입니다. 하지만 대시보드를 통해 비용 유출을 확인하는 시점은 이미 자원이 소비된 이후입니다. 비판적인 엔지니어링 관점에서 볼 때, 사후 분석은 문제의 원인을 파악할 수는 있지만 지출 자체를 막지는 못합니다. 특히 현대의 동적인 인프라 환경에서는 짧은 시간 동안 대규모의 리소스가 생성되었다 사라지기를 반복합니다. 이때 발생하는 '비용 스파이..

K8s 쓰면서 비용 분배는 어떻게 해야할까.. 생각이 들 정도로 큰 서비스 입니다. 작은 기업이 운영하기엔 만만치 않은 놈이에요. 그래서 한번 이걸 가지고 비용 관련해서 글 한번 작성해봅니다.클라우드 네이티브가 가져온 '비용의 블랙박스'인프라 아키텍처가 가상 머신(VM) 단위에서 컨테이너와 오케스트레이션(Kubernetes) 단위로 진화하면서, 엔지니어는 전례 없는 유연성과 확장성을 얻었습니다. 하지만 이 유연함 뒤에는 '비용 추적의 복잡성'이라는 거대한 그림자가 숨어 있습니다. 과거 CapEx 중심의 인프라에서는 특정 서버의 비용을 해당 팀에 매핑하기가 수월했습니다. 그러나 수백 개의 파드(Pod)가 공유 노드 위에서 초 단위로 생성되고 사라지는 쿠버네티스 환경에서는 "이번 달 클라우드 비용 1억 원 ..

지금은 DB 운영은 따로 안하는 파트인데요. 옛날에는 많은 파트를 맡으면서 이것저것 생각 많이 했습니다. 근데 이 DB를 불러오는게 참 오래걸려요. 근데 호출하는 걸 빨리할라고 인덱싱 DB(MongoDB) 이런거 쓰는거 보고 신기 하다 싶어서 글 적어봅니다.데이터의 바다에서 길을 잃지 않는 법인프라를 설계하고 대규모 시스템을 운영하며 우리가 가장 빈번하게 마주하는 성능 병목 현상의 중심에는 항상 데이터베이스(DB)가 있습니다. 아무리 뛰어난 성능의 서버와 고속 네트워크를 갖추고 있더라도, 단 하나의 쿼리가 수백만 건의 데이터를 전수 조사(Full Table Scan)하기 시작하면 시스템 전체는 순식간에 마비됩니다.우리는 흔히 "조회가 느리면 인덱스를 걸면 된다"라고 말합니다. 하지만 인덱스는 공짜가 아닙..