애플리케이션을 인스턴스에 서버에 배포하는 전략은 여러 가지 방법이 존재합니다. 기존 서비스의 다운타임을 최소화하면서 새 버전을 배포해야 하기 때문에 상황에 따라 올바른 배포 전략을 사용해야 하는데요. 그 중 블루그린 배포와 카나리 배포 전략은 클라우드 환경이 대중화되면서 쉽게 사용할 수 있게 되었습니다. 클라우드 환경에서는 리소스를 쉽게 증설할 수 있고, 그에 따라 새로운 버전을 빠르고 간편하게 배포할 수 있기 때문인데요. 특히 클라우드 공급자가 제공하는 Load Balancer 서비스를 이용하면 트래픽 라우팅을 손쉽게 구성할 수 있어 다양한 배포 방법을 이용할 수 있게 되었습니다. 이번 포스팅에서는 대표적인 클라우드 공급자 중 하나인 Google Cloud Platform에서 Load Balancer ..
Kubernetes의 장점 중 하나는 리소스의 유연하고 자동화된 Scaling이 가능하다는 것 입니다. 복잡한 MSA 아키텍쳐에서 리소스를 자동으로 Scaling해주는 기능이 있기 때문에 우리는 리소스 관리 및 사용 측면에서 Cluster를 매우 편리하게 사용할 수 있습니다 Kubernetes에서는 리소스를 Scaling할 수 있는 방법 중에서도 자동화된 방법, 즉 Autoscaling 기능을 제공하고 있는데요, Pod 단위에서는 HPA(Horizontal Pod Autoscaling), VPA(Vertical Pod Autocaling), Cluster 단위에서는 CA(Cluster Autoscaling)의 3가지 기능이 있습니다. 하지만 Google의 관리형 Kuberentes 서비스인 Google ..
Kubernetes는 컨테이너 오케스트레이션을 수행하기 위해 각자의 목적을 가진 오브젝트들을 관리합니다. 대표적으로 Pod의 집합을 관리해주는 Deployment, 설정 파일을 관리해주는 Configmap, 인증을 위한 ServiceAccount 같은 것들이 존재하죠. 모든 오브젝트들이 각자의 목적을 가지고 있지만, 특히 프로덕션 수준에서 Kubernetes를 운영하기 위해서는 보안과 관련된 오브젝트도 있어야 합니다. 그래서 Kubernetes에서는 키,암호,토큰과 같은 중요한 데이터를 노출시키지 않고도 Pod에 포함시킬 수 있는 Seceret이라는 오브젝트를 제공하고 있습니다. 이번 포스팅에서는 이 Secret을 어떻게 사용할 수 있는지, Kubernetes에서는 Secret을 어떻게 해야 잘 활용할 ..
Kubernetes는 컨테이너 오케스트레이션을 구현하기 위해 독특한 네트워킹 구조를 가지고 있습니다. 이런 Kubernetes의 네트워킹 구조에서 단연 중요한 것은 Service라는 개념입니다. Service는 외부 네트워크와 격리되어 있으며 임시적이라는 특성을 가진 Pod들을 외부와 통신할 수 있도록 고정적인 주소로 노출하는 방법을 말합니다. 이 Service의 가상 IP를 구현하기 위해서는 kube-proxy라는 컴포넌트가 전적으로 맡게 되며, 각 node에 위치해 netfilter라는 linux 패킷 조작 툴을 사용해 패킷의 생명주기를 조작합니다. 예를 들어 kube-proxy가 Service의 구현을 위해 사용하는 mode 중 iptables 모드는 패킷이 node로 들어오면 kube-proxy에..
언젠가부터 빅데이터에 대한 언급이 많아지고 있습니다. 거대한 데이터를 수집하고 분석하는 작업에 대한 수요가 늘면서 이를 수행할 수 있는 툴들이 하나둘씩 나타나고 있습니다. 가령 요즘은 빅쿼리, 데이터브릭, 스노우플레이크와 같은 SaaS형태의 종합 빅데이터 분석도구가 수요를 충족하려 하고 있습니다. 하지만 이런 최근의 SaaS 툴 이전에 빅데이터 분석의 원조격으로 불리는 시스템이 존재했습니다. 그것이 바로 Apache hadoop 입니다. Apache hadoop은 분산 환경에서 빅 데이터를 처리하기 위한 Open-source 프레임워크입니다. 그리고 Apache hadoop을 중심으로 HDFS,YARN 및 연관 도구들을 일컬어 Apache Hadoop Ecosystem(아파치 하둡 생태계)라고 합니다. ..
본 포스팅은 2021년 11월 3일 필자가 GDG devfest 2021에서 발표한 내용을 기반으로 작성했습니다. 이번 Google Cloud Next 21에서 여러 Google Cloud Platform 서비스를 발표했습니다. 발표한 서비스는 Dataplex, Analytics Hub 등.. 주로 데이터 플랫폼에 힘을 실어주는 서비스가 주로 등장했습니다. 그 중에 데이터 플랫폼이 아닌 다른 분야에서 나온 서비스가 하나 있습니다. 개인적으로 타 CSP에 비해 약하고 생각했던 CI/CD 분야의 서비스인 Cloud Deploy가 그것입니다. 데이터 플랫폼은 예로부터 GCP가 강한 분야였기 때문에 이에 힘을 실어주는 서비스의 등장은 GCP의 장점을 부각시키는 것이었지만, CI/CD 분야 서비스인 Cloud D..
GCP의 Cloud armor는 L3 및 L4부터 L7 계열 ddos 공격으로부터 인프라 및 서비스를 보호해주는 WAF(Web application firewall) 서비스입니다. 본래 Cloud armor의 본질은 WAF 서비스이기 때문에 L7 계열 트래픽의 필터링 및 정책 설정이 주된 목적이지만, 볼륨 및 프로토콜 기반의 DDoS 공격에 대한 방어 기능도 제공하고 있습니다. 이번 포스팅에서는 Cloud armor의 기능 중 DDoS 방어에 대한 기능을 사용해보고, 얼마나 효과적으로 방어할 수 있는지 검증해보겠습니다. 1. Cloud armor ddos protection 세팅 Cloud armor는 크게 2종류의 ddos 공격 유형에 대한 방어 기능을 제공합니다. 첫째로는 L3,L4 계열의 DDos ..
Cloud Function은 GCP의 Serverless function 서비스입니다. Cloud Function을 통해서 우리는 인프라 걱정 없이 코드의 제공만으로 함수를 실행할 수 있는 FaaS(Function as a Service)를 이용할 수 있습니다. 하지만 개인적으로 Cloud Function을 이용하면서 불편했던 점은, 코드를 deploy하고 서버가 뜰때까지 기다려야 하기 때문에 코드를 테스트하는 과정에 너무 많은 시간이 소요된다는 것이었습니다. Local 환경이었다면 코드를 이용해서 서버를 세우고 응답을 받기까지 매우 짧은 시간이면 충분했지만 Cloud function은 원격지의 리소스를 사용하는 Cloud 서비스이기 때문에 코드를 deploy하고 요청을 보내서 응답을 받는 과정이 길어질..
이번 포스팅에서는 GCP의 Cloud DNS를 이용해서 원격지의 DNS 서버에 질의할 수 있는 Forwarding zone을 만들어 보겠습니다. Forwarding zone은 Google cloud의 Network가 가지고 있는 Internal DNS Server가 아닌 On-premise나 다른 VPC의 DNS Server를 이용하고자 DNS query를 forwarding하고 싶을때 사용할 수 있습니다. 이 DNS query를 다른 곳으로 Forwarding하는 것을 DNS Forwarding이라고 하며, 이 기능 덕분에 여러 환경의 Network를 연결해 구성하더라도 원하는 DNS Server를 이용할 수 있습니다. DNS Forwarding은 다른 네트워크와의 연결을 전제로 하기 때문에 On-pr..
목차 : 들어가기 전에 GKE에서 사용할 수 있는 CNI 플러그인 Benchmark 요약 결과 1. 들어가기 전에 쿠버네티스의 네트워크 계층을 구현하기 위해서는 CNI(Container Network Interface) 플러그인이 꼭 필요합니다. 하지만 선택할 수 있는 CNI 플러그인의 종류가 너무 많기 때문에 ( https://kubernetes.io/ko/docs/concepts/cluster-administration/networking/ 참고) 선택에 있어 많은 어려움이 따르기도 합니다. 많은 블로그와 아티클에서 k8s에서 사용할 수 있는 CNI 플러그인의 기능, 명세를 비교했지만, 실제 CNI 플러그인을 사용했을 때 나타나는 GKE에서의 성능 비교를 볼 수 있는 글은 오래되었거나, 관련 정보를 ..
