imguno imguno

Terraform 004 임박!Overview Terraform 자격증 준비하시는 분들 계신가요? 저는 최근 IaC에 관심이 생겨 Terraform을 공부하고 있었는데, 찾아보니 Terraform Associate (003) 시험이 2026년 1월 7일까지만 운영되고, 바로 다음날부터는 Terraform Associate (004) 시험으로 넘어간다고 하네요. 사실 003이나 004 어느 것을 취득해도 큰 차이는 없지만 그래도 최신 시험을 보는 게 Terraform에서 추구하는 방향을 이해하는 데 더 도움이 될 것 같아서 004 시험을 준비하려고 합니다! 공식 사이트: HashiCorp Certified: Terraform Associatehttps://developer.hashicorp.com/ce..

jQuery에 React를 넣어보자!OverviewjQuery로 만든 SPA(single page application)는 시간이 지날수록 유지보수가 힘들어집니다.DOM을 직접 제어하다 보니 사이드이펙트가 자주 발생하고 신규 개발자가 구조를 파악하기도 어렵습니다.프론트엔드 전체가 하나의 거대한 프로그램처럼 동작하다 보니 성능 문제도 점점 두드러졌습니다.“이제 슬슬 넘어갈 때가 됐구나.”React 도입을 희망했지만 문제는 한 번에 갈아엎을 수 없다는 것이었습니다.수년간 쌓아온 프론트엔드를 소수 인원으로 전환하는 건 리스크가 너무 컸습니다.그래서 선택한 방법은 “점진적 포팅”.검색을 해보면 대부분 React 안에서 jQuery 함수를 호출하는 예시는 쉽게 찾을 수 있습니다.하지만 저희가 필요했던 건 그 반대..

AWS i3 괴담..Overview최근 운영 중이던 AWS i3 인스턴스가 은퇴(retirement) 대상이 되면서 예상치 못한 이슈를 겪었습니다.기존 서비스가 i3 인스턴스의 휘발성(Instance Store) 디스크를 데이터 저장소로 사용하고 있었던 것입니다!추측하기론 인프라 구축 당시 i3의 빠른 Instance Store SSD 성능을 극대화하기 위해 선택된 설계로 보입니다. AWS에서는 인스턴스 종료/재시작 시 휘발성 디스크의 데이터가 보존되지 않는다고 명확히 안내하고 있지만, 실제로 이벤트가 오기 전까지는 그 리스크를 체감하기 어려웠습니다. 이번 경험을 통해 배운 점을 공유하고자 합니다.인스턴스가 종료될 때 데이터 보존Docs: 인스턴스가 종료되면 인스턴스 스토어 볼륨이 자동으로 삭제되고 데이..

Custom Prometheus로 가벼운 모니터링 환경 만들기Overview운영 과정에서 모니터링은 필수입니다.장애를 "감지"하고 "예상"하며 "대응"하기 위함입니다.기존에도 모니터링 환경은 있었습니다. 하지만 실시간으로만 확인이 가능했을 뿐, 과거 기록은 남지 않았습니다.즉, 순간적인 장애는 잡아낼 수 있었지만, “이 시간대에 왜 자꾸 느려지는가?” 같은 패턴 분석이나 사전 대응은 불가능했습니다.그래서 과거를 기록할 수 있는 새로운 모니터링 환경이 필요했습니다.다만, 운영 서버에 무겁게 모듈을 추가 설치하는 방식은 피하고 싶었습니다.서비스가 우선이었기 때문에, 불필요한 사이드 이펙트는 최대한 배제해야 했습니다.문제 상황기존 모니터링: 실시간 확인만 가능, 과거 기록 없음장애는 잡을 수 있지만 패턴 분석..

TABLE SWAP 시 ALTER 대신 RENAME 을 사용하자OverviewETL 파이프라인에서는 새로운 데이터를 운영 테이블에 반영할 때, Zero-downtime(무중단)으로 테이블을 교체하는 전략이 필요합니다. 이를 위해 흔히 테이블 스왑(Table Swap) 방식을 사용합니다. 예를 들어, 기존 운영 테이블이 foo라면foo → foo_old (백업 보존)foo_new → foo (새로운 테이블로 교체) 이렇게 이름을 교체하면 서비스는 중단 없이 새로운 데이터를 사용할 수 있고 동시에 foo_old로 이용해 빠른 롤백도 가능합니다. 테이블 이름 교체 방식MySQL에서 테이블 이름을 교체할 수 있는 방법은 두 가지입니다.-- ALTER 사용ALTER TABLE ... RENAME TO-- RENA..

공간인덱스를 안 타네? Optimizer가 의도한대로 동작했습니다.OverviewAPI 성능 로그를 보다가, 특정 테이블에서 ST_Intersects 쿼리만 유독 느린 걸 발견했습니다.A 테이블 (약 1.2만 rows) → 인덱스 사용B 테이블 (약 56만 rows) → 인덱스 사용R 테이블 (약 8.3만 rows) → 인덱스 무시 + 풀스캔 발생 🤔인덱스도 정상인데 왜 R 테이블 만 풀스캔일까?Optimizer가 cost를 어떻게 계산하는지 직접 확인해보기로 하고 실험을 설계했습니다.실험 방법실험환경DBMS: MySQL 5.7.40Geometry: POINT 타입테이블 3종 세트 준비I TABLE: 공간 인덱스 강제 (FORCE INDEX)F TABLE: 인덱스 없음(풀스캔)O TABLE: Optim..