기술 블로그 (Tech) | kt cloud

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud 플랫폼엔지니어링팀 김지웅 님 📋 요약TL;DR이 글에서는 이기종 데이터 통합 서비스의 확장성을 높이기 위한 수집·식별·소비의 3가지 아키텍처 경계를 다룹니다.모니터링 통합 사례를 통해 변화가 전파되는 지점을 격리하고 공통화 범위를 판단하는 설계 기준을 정리합니다.#이기종데이터통합 #모니터링통합 #SourceAdapter #EntityResolver #ReadModel1. 들어가며 — 통합은 "한 번 붙이고 끝"이 아니다최근 인프라 환경은 한 방향으로 움직이고 있습니다. 멀티클라우드와 컨테이너가 확산되면서 관측해야 할 대상은 빠르게 늘고, 그만큼 모니터링·관측(Observability) 도구도 함께 증식합니다. 동..

Tech-Frontier.md kt cloud$ whoami --team❯ kt cloud Data플랫폼팀 유지연 님 📋 요약TL;DR이 글에서는 KCP 클라우드 환경에서 Observability Alert 플랫폼을 구축하고조직별 Alert 격리, 통합관제 연동, 이력 관리 체계를 설계한 과정을 다룹니다.안정적인 클라우드 운영을 위해 Alert를 단순 알림이 아닌 운영 정책으로 관리해야 하는 이유를 정리합니다.#Observability #Alert플랫폼 #LGTM스택 #통합관제 #멀티테넌트1. 왜 Observability Alert 플랫폼을 직접 만들었나 — 문제의 출발점클라우드 플랫폼을 운영하다 보면 자연스럽게 모니터링과 알림 체계가 고도화됩니다. 가상 서버, 네트워크, 컨테이너 플랫폼 각각을 감시하..

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)을 분리했는데도 장애가 전면 확산되는 케이스가 반복됩니다. 멀티 리전..