기술 블로그 (Tech) | kt cloud

[구축사례] 흩어진 운영 데이터를 하나로, kt cloud 운영 데이터 통합 플랫폼 Deck 구축기

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Data플랫폼팀 김주환 님 📋 요약TL;DR이 글에서는 분산된 클라우드 운영 데이터를 통합하기 위한 레이크하우스 기반 데이터 플랫폼 Deck의 구축 과정을 다룹니다.운영 데이터의 기준을 일원화해 과금, 분석, 의사결정의 신뢰성을 높이는 방향을 정리합니다.#데이터플랫폼 #레이크하우스 #ObjectStorage #Trino #Kafka데이터는 넘치는데, 정작 쓸 수가 없었다클라우드를 운영할수록 로그, 지표, 이벤트, 사용량 데이터가 쉴 새 없이 쌓입니다. 문제는 이 데이터들이 시스템마다 서로 다른 형태로, 서로 다른 위치에 흩어진다는 점입니다. 정보 하나를 확인하려 여러 도구를 차례로 열어야 하고, 장애가 나면 "무..

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Cloud플랫폼팀 서준호 님 📋 요약TL;DR이 글에서는 OVN ACL Flow Sampling을 기반으로 VPC Flow Log 서비스를 개발한 과정과 아키텍처를 다룹니다.대용량 트래픽 환경에서 로깅 부하를 줄이고 네트워크 운영 가시성을 높이는 방향을 정리합니다.#OVN #ACLFlowSampling #VPCFlowLog #IPFIX #Goflow2클라우드 환경이 고도화됨에 따라 네트워크 트래픽에 대한 투명성 확보와 보안 감사(CSAP 인증 등) 요건은 점점 더 까다로워지고 있습니다. 본 포스트에서는 클라우드 플랫폼팀, 데이터플랫폼팀, 보안플랫폼팀이 협업하여 7월 릴리즈를 목표로 개발한 VPC Flow Log ..

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Cloud플랫폼팀 윤찬열 님 📋 요약TL;DR이 글에서는 IPFIX와 Goflow2를 활용해 OVN 환경의 네트워크 과금 미터링 체계를 구축한 과정을 다룹니다.정확한 트래픽 측정은 클라우드 운영 신뢰성과 과금 리스크 관리에 중요한 기준이 됨을 정리합니다. #IPFIX #Goflow2 #OVN #NetworkMetering #OpenStackiptables가 사라진 자리, 과금은 어디서 측정하나클라우드 사업에서 네트워크 과금은 민감한 영역입니다. 테넌트별로 외부와 주고받는 North-South 트래픽을 정확히 측정해야 청구서가 나가는데, 여기서 1바이트라도 어긋나면 그대로 비즈니스 신뢰도 문제로 번지기 때문입니다...

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Cloud플랫폼팀 김건희 님 📋 요약TL;DR이 글에서는 kt cloud PLATFORM의 OpenStack 내재화를 위해 Zuul.CI 기반 Gating System을 구축한 과정을 다룹니다.Upstream 변화에 따른 회귀 위험을 줄이고 안정적인 운영 검증 방향을 정리합니다.#OpenStack #ZuulCI #GatingSystem #CI파이프라인 #ktcloud1. 문제 정의: "Community 버전의 OpenStack을 내재화한다는"는 것의 무게클라우드 플랫폼을 구축할 때, 상용 배포판이 아닌 Community 버전의 OpenStack을 코어로 채택하는 순간, 그 의미를 한 번 더 짚어볼 필요가 있습니다..

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Storage플랫폼팀 엄주관 님 📋 요약TL;DR이 글에서는 Ceph 기반 스토리지 내재화로 상용 스토리지를 대체하기 위한 배경과 설계 방향을 다룹니다.비용 효율과 기술 통제권이 클라우드 운영 경쟁력에 미치는 의미를 정리합니다.#Ceph #스토리지내재화 #분산스토리지 #오브젝트스토리지 #클라우드인프라왜 스토리지 내재화가 필요했는가클라우드 서비스를 운영할수록 스토리지 비용은 누적되고, 서비스 규모가 커질수록 상용 라이선스 구조의 부담도 함께 커집니다. 특히 저장 용량 증가와 함께 비용이 지속적으로 상승하는 구조는 장기적으로 수익성에 직접적인 영향을 줍니다. 또한 벤더별 제품을 혼합 운영하는 환경에서는 운영 정책, ..

[ kt cloud 제안TF 심대섭 님 ] 📋 요약 이 글에서는 Multi-AZ와 Multi-Region의 차이와 재해복구 설계 시 고려해야 할 핵심 요소를 다룹니다.안정적인 서비스 운영과 장애 대응 수준을 결정하기 위한 현실적인 설계 방향을 정리합니다.#Multi-AZ #Multi-Region #재해복구 #DR #RTO #RPO Multi-AZ vs Multi-Region DR 설계 전략클라우드 아키텍처를 설계할 때 많은 조직이 가장 먼저 고민하는 주제가 있습니다. Multi-AZ과 Multi-Region 중 어떤 구조가 더 안전한가 하는 질문입니다.겉보기에는 여러 Region을 사용하는 구조가 더 안전해 보입니다. 그러나 실제 서비스 운영이나 DR 훈련 환경에서는 상황이 그렇게 단순..

[ kt cloud Cloud컨설팅팀 심대섭 님 ] 📋 요약 이 글에서는 클라우드 네이티브 환경에서 상태를 분리하고 데이터 일관성을 유지하여시스템의 가용성을 확보하는 설계 전략을 다룹니다.분산 시스템에서 발생할 수 있는 장애와 데이터 불일치 위험을 최소화하고,비즈니스 연속성을 지키기 위한 실무적인 운영 방향을 정리합니다. #클라우드네이티브 #상태관리 #데이터일관성 #분산트랜잭션 #고가용성cloud native 가용성은 ‘상태 설계’가 좌우한다. 인터넷에서 쇼핑을 하다 보면, 분명히 담아둔 상품이 어느 순간 장바구니에서 사라져 보이는 경험이 있습니다. 사용자는 “버그인가?”라고 느끼지만, 시스템 관점에서는 상태(state)가 끊기거나 지연된 값을 읽는 전형적인 신호인 경우가 많습니다. 이..

[ kt cloud Cloud컨설팅팀 심대섭 님 ] 📋 요약 이 글에서는 클라우드 네이티브 환경에서 멀티 리전 구성 시 장애 도메인과 격리 설계를 통해가용성과 복원력을 강화하는 아키텍처 전략을 다룹니다.리전 분리만으로는 장애 전파를 막을 수 없으며,공유 지점 최소화와 독립 운영 단위 설계가 실제 장애 국지화의 핵심임을 정리합니다. #클라우드네이티브 #장애도메인 #멀티리전 #고가용성 #DR #share-nothing멀티 리전을 썼는데도 서비스가 같이 멈추는 구조적 원인클라우드 네이티브 가용성을 이야기할 때 가장 흔한 기대는 “리전을 두 개 이상 쓰면 고가용성이 된다”입니다. 그런데 운영 현장에서는 리전과 가용 영역(AZ)을 분리했는데도 장애가 전면 확산되는 케이스가 반복됩니다. 멀티 리전..

[ kt cloud Cloud컨설팅팀 심대섭 님 ] 📋 요약 이 글에서는 클라우드 네이티브 환경에서 애플리케이션 이식성을 강화하기 위한컨테이너 패키징, 설정 외부화, 배포 전략의 핵심 원칙과 실무 적용 방법을 다룹니다.이를 통해 장애 발생 시 수리가 아닌 재배포 중심의 복구 전략을 수립하고,무중단 배포와 운영 복원력을 확보하는 방향을 정리합니다. #클라우드네이티브 #컨테이너 #쿠버네티스 #애플리케이션이식성 #배포전략현재 대부분의 신규 서비스는 컨테이너와 쿠버네티스를 전제로 설계합니다. 그런데 장애 분석 회의에 들어가 보면 원인은 여전히 익숙한 패턴에서 나옵니다. 특정 노드에만 설치된 라이브러리, 환경마다 미묘하게 다른 설정, 롤백이 안 되는 배포 파이프라인 같은 것들입니다. 인프라는 멀..

[ kt cloud Cloud컨설팅팀 심대섭 님 ] 📋 요약 이 글에서는 클라우드 네이티브 환경에서 서비스 가용성을 확보하기 위한네 가지 핵심 설계 원칙(애플리케이션 이식성 및 배포 전략,장애 도메인과 격리 설계, 상태 관리와 데이터 일관성, 카오스 엔지니어링과 복원력 검증)을 다룹니다. 장애의 출발점이 인프라가 아닌 변경과 운영 방식으로 이동한 현실에서,실제 아키텍처 의사결정에 적용 가능한 설계 프레임워크와 검증 방법을 정리합니다.#클라우드네이티브 #가용성설계 #장애격리 #카오스엔지니어링 #멀티리전현재, 조직의 규모와 무관하게 대부분의 조직은 어떤 형태로든 클라우드를 활용하고 있습니다. 신규 서비스는 컨테이너와 Kubernetes 기반으로 구축되고, 기존 레거시 시스템도 단계적으로 클..