Mimi.log

  "왜 아무것도 안 했는데 요금이 많이 나오죠?" 클라우드 인프라를 운영하다 보면 매달 날아오는 청구서에서 의외의 항목이 큰 비중을 차지하는 것을 발견하게 됩니다. EC2나 RDS 같은 메인 리소스가 아닙니다. 바로 ' NAT Gateway' 입니다. 보안을 위해 프라이빗 서브넷(Private Subnet)을 구성했다면 외부 인터넷 통신을 위해 NAT Gateway는 필수적입니다. 하지만 트래픽이 늘어날수록 기하급수적으로 증가하는 '데이터 처리 비용'은 스타트업과 대기업 모두에게 골칫거리입니다. 오늘은 아키텍처를 조금만 손봐서 성능은 유지하고 비용은 극적으로 낮추는 구체적인 전략을 알아봅니다. 1. NAT Gateway 요금 구조의 함정 적을 알고 나를 알아야 비용을 줄일 수 있습니다. NAT Gateway의 요금은 크게 두 가지로 나뉩니다. 시간당 요금 (Hourly Charge): 게이트웨이가 켜져 있는 시간만큼 부과됩니다. (서울 리전 기준 약 월 $40~50 수준) 데이터 처리 요금 (Data Processing Charge): 게이트웨이를 통과하는 트래픽 1GB당 부과되는 요금입니다. 문제는 바로 두 번째, 데이터 처리 요금 입니다. 많은 개발자가 "우리 서버는 외부랑 통신 별로 안 하는데?"라고 생각합니다. 하지만 서버 내부에서 일어나는 S3 파일 업로드/다운로드, 도커(Docker) 이미지 풀(Pull), 로그 전송 등이 모두 NAT Gateway를 통과한다면? 1TB만 전송해도 수십만 원의 추가 비용이 발생합니다. 이것이 요금 폭탄의 주범입니다. 2. 해결책 1: S3와 DynamoDB는 '무료 도로'를 이용하라 가장 효과적이고 즉각적인 비용 절감 방법은 VPC 엔드포인트(Gateway Type) 를 사용하는 것입니다. AWS 내부 서비스인 S3(스토리지)나 DynamoDB에 접근할 때, 굳이 인터넷망으로 나가는 NAT Gateway를 거...

  멈추지 않는 기업을 위한 보험, DR 시스템 2022년 판교 데이터 센터 화재 사건은 우리에게 큰 교훈을 남겼습니다. "데이터가 사라지면 기업도 사라진다"는 사실입니다. 천재지변, 해킹, 랜섬웨어, 혹은 단순한 작업자 실수로 시스템이 멈췄을 때, 기업이 얼마나 빨리, 그리고 얼마나 온전하게 다시 일어설 수 있는지를 결정하는 것이 바로 재해 복구(Disaster Recovery, DR) 시스템입니다. 하지만 무작정 "가장 빨리, 데이터 손실 없이"를 외치면 천문학적인 비용이 듭니다. 합리적인 DR 전략을 세우기 위해 경영진과 실무자가 반드시 합의해야 할 두 가지 기준, RTO 와 RPO 에 대해 알아봅니다. 1. RTO (Recovery Time Objective): "언제 다시 켜지는가?" RTO는 우리말로는 ' 목표 복구 시간' 입니다. 쉽게 말해, 재해가 발생한 시점부터 서비스가 재개될 때까지 걸리는 허용 시간 을 의미합니다. 이는 비즈니스 중단 시간(Downtime)과 직결됩니다. 핵심 질문: "서버가 죽으면 몇 시간 안에 다시 켜져 야 고객들이 떠나지 않을까?" 예시: RTO가 4시간 이라면, 오후 1시에 장애가 발생했을 때 늦어도 오후 5시까지는 시스템이 정상 가동되어야 합니다. 비즈니스 영향: RTO가 짧을수록 서비스 중단 시간이 줄어들어 매출 손실과 브랜드 이미지 타격을 최소화할 수 있습니다. 하지만 이를 위해서는 Active-Standby나 고가용성(HA) 장비 등 즉각적인 복구 인프라가 필요하므로 비용이 급격히 상승합니다. 2. RPO (Recovery Point Objective): "데이터를 얼마나 잃어도 되는가?" RPO는 ' 목표 복구 시점' 입니다. 재해 발생 시 데이터를 어느 시점까지 되살릴 것인가 에 대한 기준입니다. 이는 데이터 손실 허용 범위(Data Loss Tolerance)를...

  서비스 성장의 통과 의례, DB 병목 현상 사용자가 늘어나고 데이터가 쌓이면 애플리케이션 서버보다 먼저 비명을 지르는 곳이 바로 데이터베이스(DB)입니다. "사이트가 느려졌다"는 불만의 80% 이상은 DB 병목에서 시작됩니다. 이때 개발자와 인프라 담당자는 두 가지 선택지를 놓고 고민하게 됩니다. 데이터를 똑같이 복사해서 여러 곳에 둘 것인가( Replication ), 아니면 데이터를 조각내어 분산 저장할 것인가( Sharding )입니다. 이 글에서는 헷갈리기 쉬운 두 개념의 차이와 도입 시점을 명확히 정리해 드립니다. 1. 리플리케이션(Replication): 데이터를 복제하여 읽기 성능 향상 리플리케이션은 말 그대로 데이터를 '복제'하는 기술입니다. 가장 흔히 사용되는 Master-Slave(Primary-Secondary) 구조를 예로 들어보겠습니다. 작동 원리 하나의 원본 데이터베이스(Master)에 데이터가 기록되면, 그 내용이 실시간으로 연결된 여러 개의 복제 데이터베이스(Slave)로 복사됩니다. Master (주 서버): 데이터의 생성(Create), 수정(Update), 삭제(Delete) 등 '쓰기' 작업을 전담합니다. Slave (부 서버): Master로부터 데이터를 받아와 동기화하고, 오직 '읽기(Select)' 작업만 처리합니다. 장점: 읽기 분산 (Read Scalability) 대부분의 웹 서비스는 글을 쓰는 빈도보다 읽는 빈도가 압도적으로 높습니다(약 8:2 또는 9:1 비율). 리플리케이션을 적용하면 쓰기 트래픽은 Master 하나가 감당하지만, 읽기 트래픽은 여러 대의 Slave가 나누어 처리하므로 전체적인 조회 속도가 획기적으로 빨라집니다. 또한, Master가 고장 나면 Slave 중 하나를 승격시켜 서비스를 유지할 수 있어 고가용성(HA) 확보에도 유리합니다. 한계점 모든 Slave가 Master와 동일한 데이터를 가...

 웹 사이트 속도 향상의 핵심, CDN 도입 전 반드시 확인해야 할 체크리스트와 최적의 캐시 정책(TTL) 설정 가이드입니다. 서버 부하를 줄이고 사용자 경험을 극대화하는 전략적인 CDN 운영법을 소개합니다. 0.1초의 차이가 비즈니스를 바꿉니다 웹 페이지 로딩 시간이 3초를 넘어가면 사용자의 53%가 이탈한다는 구글의 통계가 있습니다. 글로벌 서비스나 고해상도 이미지가 많은 쇼핑몰에서 속도는 곧 매출입니다. 이때 가장 효과적인 해결책이 바로 CDN(Content Delivery Network) 입니다. 하지만 단순히 CDN을 연결한다고 끝이 아닙니다. 잘못된 설정은 오히려 갱신되지 않은 구형 콘텐츠를 보여주거나, 예상치 못한 비용 폭탄을 초래할 수 있습니다. 성공적인 CDN 도입을 위한 핵심 고려사항과 효율적인 캐시 정책 수립 방법을 알아봅니다. 1. CDN의 원리: 전 세계에 물류 센터 짓기 CDN을 이해하는 가장 쉬운 방법은 '물류 시스템'에 비유하는 것입니다. 오리진 서버(Origin Server): 본사  공장입니다. 원본 데이터가 저장된 곳입니다. 엣지 서버(Edge Server): 전 세계 각지에 흩어진 물류 센터(PoP)입니다. 사용자와 물리적으로 가장 가까운 곳에 위치합니다. 미국에 있는 사용자가 한국 서버(오리진)에 접속하면 데이터가 태평양을 건너야 하므로 느립니다. 하지만 미국에 있는 엣지 서버(CDN)가 미리 데이터를 받아두고(캐싱) 사용자에게 대신 전달해 주면 속도가 획기적으로 빨라집니다. 2. CDN 도입 전 체크리스트 3가지 시중에는 AWS CloudFront, Cloudflare, Akamai 등 다양한 CDN 서비스가 있습니다. 선택 전 다음 3가지를 반드시 따져보아야 합니다. ① PoP(Point of Presence) 커버리지 내 서비스의 주 사용자가 어디에 있는지 파악해야 합니다. 한국 사용자만 있다면 국내 ISP와 연동이 잘 된 로컬 CDN이 유리할 수 있고, 글로벌 서비스라...

 서버 이전 후 변경된 도메인 정보가 바로 반영되지 않는 이유는 무엇일까요? DNS 작동 원리와 캐싱, 그리고 전파 시간을 결정하는 TTL(Time To Live)의 개념을 완벽하게 정리해 드립니다. "어제 서버를 옮겼는데, 왜 아직도 옛날 사이트가 보이죠?" 웹사이트 운영자나 개발자가 호스팅을 이전하거나 서버 IP를 변경했을 때 가장 많이 겪는 당혹스러운 상황이 있습니다. 분명 설정을 다 바꿨는데, 내 컴퓨터에서는 새 사이트가 뜨고 옆자리 동료의 컴퓨터에서는 여전히 옛날 사이트가 뜨는 현상입니다. 심지어 모바일에서는 접속조차 안 되기도 합니다. 이 미스터리한 현상의 범인은 바로 DNS(Domain Name System) 의 작동 방식과 TTL(Time To Live) 이라는 설정 때문입니다. 인터넷 주소록이 어떻게 업데이트되는지, 그리고 왜 전 세계에 퍼지는 데 시간이 걸리는지 그 원리를 알기 쉽게 파헤쳐 보겠습니다. 1. DNS의 기본 원리: 인터넷의 거대한 전화번호부 우리가 인터넷을 할 때 google.com이나 naver.com 같은 문자로 된 도메인 이름을 입력합니다. 하지만 컴퓨터는 숫자로 된 IP 주소(예: 192.168.1.1)만 이해할 수 있습니다. 이때 DNS 는 우리가 입력한 도메인 주소를 컴퓨터가 이해하는 IP 주소로 변환해 주는 역할을 합니다. 마치 스마트폰 전화번호부에서 친구 이름(도메인)을 검색하면 실제 전화번호(IP)를 찾아 연결해 주는 것과 같습니다. 이 변환 과정을 ' DNS 조회(Lookup)' 라고 합니다. 2. 속도의 비결이자 지연의 원인, 'DNS 캐시(Cache)' 만약 우리가 네이버에 접속할 때마다 전 세계 어딘가에 있는 DNS 서버에 "네이버 IP가 뭐였지?"라고 매번 물어본다면 어떻게 될까요? 인터넷 속도는 끔찍하게 느려지고, DNS 서버는 과부하로 다운될 것입니다. 이를 방지하기 위해 컴퓨터와 네트워크 장비들은 한 번 알아낸 I...