기술 블로그 (Tech) | kt cloud

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

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

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

[ kt cloud 마케팅커뮤니케이션팀 ] 📋 요약 OpenStack과 Kubernetes의 전략적 통합 흐름과 kt cloud의 차세대 플랫폼 NEXT 아키텍처를 소개합니다.글로벌 오픈소스 생태계 협력을 통해 VM과 컨테이너를 하나의 인프라에서 운영하는 방법을 다룹니다.#OpenStack #Kubernetes #클라우드플랫폼 #오픈소스 #NEXT안녕하세요, kt cloud 마케팅커뮤니케이션팀입니다! 👋최근 클라우드와 AI 분야를 둘러싼 기술 생태계가 정말 빠르게 변하고 있어요.오픈소스 프로젝트들이 서로의 영역을 넘나들며 협력하고, 전 세계 기업들이 새로운 인프라 표준을 만들어가는 움직임이 그 어느 때보다 활발해지고 있죠. 이런 흐름 속에서 많은 분들이 자연스럽게 이런 궁금증을 갖게 ..

[ kt cloud Cloud컨설팅팀 김휘집 님 ] 📋 요약 kt cloud SDK와 Grafana를 활용하여 Load Balancer의 실시간 모니터링 대시보드를 구축하는 방법을 소개합니다.Custom Exporter를 통해 안정적인 데이터 수집과 시각화를 구현하는 실무 가이드입니다.#LoadBalancer #Grafana #모니터링 #SDK #대시보드 들어가며클라우드 환경에서 Load Balancer(LB)는 트래픽을 분산하여 서비스의 안정성과 성능을 보장하는 핵심 구성 요소입니다. 하지만 여러 개의 LB를 운영하다 보면 각각의 상태와 성능을 실시간으로 파악하기 어려워집니다. “이벤트 기간동안 LB에서 수집되는 데이터가 얼마나될까?”, “LB는 직접 모니터링 할 수 없을까?”, “특정 LB에 연결된..

[kt cloud CloudSW운영팀 김호균 님] OpenStack 컴퓨팅 서비스 이해하기: 심화편지난 포스팅에서는 컴퓨팅 서비스인 Nova의 아키텍처와 기본 동작 과정에 대해서 간단히 살펴보았습니다. 또한 OpenStack 대시보드 서비스인 Horizon을 통해 가상 머신을 직접 생성해 보고, 이 과정에서 OpenStack의 여러 컴포넌트들이 어떻게 서로 상호 작용하는지 알아보았습니다.이번 포스팅에서는 가상화 관점에서 Nova를 좀 더 자세히 살펴보겠습니다.   OpenStack 가상화 방식: KVM과 QEMU Nova에 대해 설명하기 전에, KVM과 QEMU에 대해 먼저 알아보겠습니다.가상화 방식을 활용하면 호스트 시스템과 독립적인 환경에서 각각 다른 운영체제로 가상 머신(VM)을 동작할 수 있습니다..

[kt cloud 서비스개발팀 이지윤 님] BufferedReader.readLine()와 InterruptedException kt cloud의 DBaaS 상품에는 생성된 VM에 원격으로 접속해서 OS 명령어로 DB의 상태를 체크하는 과정이 주기적으로 실행되고 있습니다. 그리고 OS 명령어의 결과값을 처리할 때에는 표준 출력 스트림과 에러 스트림을 비동기식으로 처리하고 있습니다.이 과정에서 Java의 Process 객체를 사용해서 OS 명령어 처리를 위한 외부 프로세스를 관리하고,BufferedReader를 사용해서 외부 프로세스의 출력/에러 스트림을 처리하고,스트림 처리를 비동기식으로 수행하기 위해 CompletableFuture를 사용하고 있습니다.DBaaS에서 실제로 어떻게 외부 프로세스 사용 및..

[kt cloud 플랫폼Innovation팀 오준영] Kafka 이벤트 전송 최적화: Partitioner와 batch 설정 이해하기 Kafka에서 Producer는 기본적으로 Sticky Partitioner를 사용하여, 이벤트를 batch 단위로 묶어 효율적으로 전송할 수 있습니다.배치 설정은 batch.size와 linger.ms가 있으며, 각각 배치의 크기와 데이터가 쌓이는 시간을 설정해 전송 조건을 조절할 수 있습니다.본 포스팅에서는 Kafka를 활용한 이벤트 발행과 구독하는 과정에서, 겪은 이벤트 분산 이슈의 원인을 파악하기 위해 Kafka Partitioner, batch.size, linger.ms 설정을 분석한 내용을 공유합니다.  1.시나리오 테스트 환경 (Local) Kafka Clu..

[kt cloud 플랫폼Innovation팀 송재희 님] MSW로 프론트엔드 개발 프로세스 개선하기 : API Mocking 프론트엔드 개발자라면, 종종 백엔드 API가 준비되기 전까지 대기해야 하는 상황을 경험해 보셨을 겁니다. 이번 포스트에서는 백엔드 API가 준비되기 전에 동일한 규격의 API를 지원하는 가상 서버 환경을 구성하여, 생산성 높은 프론트엔드 개발을 진행할 수 있는 방법을 소개하고자 합니다. 그 중심에는 MSW(Mock Service Worker)가 있습니다.  프론트엔드 개발의 현실 프론트엔드와 백엔드가 협업하며 마주하는 어려움 중 하나는 백엔드 API 연동 과정에 있습니다. 프론트엔드는 클라이언트 UI 화면 구현을 중심으로 작업을 진행하지만, 서버 API를 연동하여 알맞은 데이터와 ..

[kt cloud 플랫폼Innovation팀 강솔 님] 효율적인 gRPC 서비스 설계: Protobuf 작성 컨벤션 도입기 클라이언트와 서버는 항상 동시에 업데이트될 수 없기 때문에, 이들이 항상 동기화될 것이라는 가정은 위험합니다. 특히, Breaking Changes(호환되지 않는 변경)가 발생했을 때 클라이언트나 서버가 최신 업데이트를 반영하지 못하면 서비스 중단이나 통신 오류가 발생할 수 있습니다. 이와 관련하여 Protobuf를 정의할 때 유의할 점에 대해 살펴보고, 이를 예방하고 안정적인 서비스 운영을 위해 저희 프로젝트에서 정의한 Protobuf 작성과 관련된 컨벤션 규칙에 대해 설명하겠습니다.   1. Proto 파일 버전에 따른 메시지 내용 변경 먼저 .proto 파일이 변경될 경우 구 ..