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 ..
들어가기 전에 분산된 애플리케이션을 운영하는 MSA(Micro Service Architecture) 환경이 많은 모놀리식을 대체하기 시작한지도 많은 시간이 흘렀습니다. 하지만 Kubernetes와 같은 오케스트레이션 툴이 등장했음에도 불구하고 여전히 마이크로 서비스에서 네트워크 정책을 수립하는 것은 쉽지 않습니다. 이런 문제로 인해 어플리케이션을 개발하는 개발자와 클러스터를 운영하는 운영자 모두 네트워크 레이어의 문제를 해결하기 위해 많은 노력과 시간을 쏟아야 했습니다. 그러자 개발자와 운영자는 모두가 문제를 해결하기 위해 참여하는 대신 어플리케이션 레이어의 비즈니스 로직에만 집중할 수 있는 환경을 원하기 시작했습니다. 이런 환경을 제공하기 위해 나타난 개념이 ”서비스 메쉬(Service mesh)”입..
본 포스팅은 GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(2)에서 이어지는 글입니다. GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(2) GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(1) 이번 GKE에서 관측 가능성 확보하기 시리즈의 마지막 포스팅입니다. 지금까지 GKE Cluster의 다양한 메트릭을 수집할 수 있는 Prometheus와 이 메트릭을 대쉬보드 형태로 구성해주는 Grafana까지 설치를 마쳤습니다. 이로 인해 시계열 데이터(Time-series data)에 대한 관측 가능성을 확보하는 성과를 이루었습니다. 하지만 마지막으..
본 포스팅은 GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(1)에서 이어지는 글입니다. GKE Prometheus, Loki, Grafana로 Monitoring dashboard 구성하기(1) 저번 포스팅에서 우리는 GKE Cluster의 관측 가능성을 확보하기 위해 Kubernetes 모니터링 툴인 Prometheus를 설치하고 사용해봤습니다. 이번 포스팅에서는 Prometheus에서 수집한 다양한 메트릭들을 보기 쉽도록 데이터 시각화(Data visualization) 툴인 Grafana를 이용해 대쉬보드를 구성해보겠습니다. 물론 저번 포스팅에서 봤듯이 Prometheus만으로도 메트릭을 기반으로 한 데이터 시각화는 가능했지만, Grafana의..
MSA 구조를 운영하고자 할 때 가장 힘든 것은 수 많은 마이크로 서비스에 대한 관리와 운영일 것입니다. 하지만 리소스가 어떤 상태인지 모르고 관리와 운영을 한다는 것은 어불성설이겠죠. 그래서 Kubernetes 등의 MSA 구조를 운영하고자 할 때 "관측 가능성(Observability)"을 확보하는 것이 무엇보다 중요합니다. 특히 현재 가장 대중화된 디플로이 환경인 Kubernetes의 관측 가능성을 확보할 수 있는 툴들이 많이 등장했는데요. 이번 포스팅에서는 Kubernetes의 모니터링과 로깅을 위해 가장 많이 선택하는 Prometheus + Loki + Grafana 스택을 구성해보겠습니다. 구성하는 환경은 GCP의 관리형 Kubernetes 서비스인 GKE를 기반으로 하지만 바닐라 Kubern..
Kubernetes에서 개발 환경을 구축하는 것은 일반적인 상황과 많이 다릅니다. 기존에는 소스 코드 수정 -> 서버 재구축만으로 테스트를 진행할 수 있었지만, Kubernetes 환경에서는 이 사이에 이미지 빌드 -> 레포지토리 푸쉬 및 풀 -> pod 재구성하는 과정 또한 필요합니다. 때문에 kubernetes 개발 환경에서 새 버전의 코드를 테스트하기가 매우 까다로웠습니다. 이 같은 문제를 해결하기 위해 등장한 툴이 바로 Skaffold입니다. Skaffold는 자신을 구글의 오픈소스 프로젝트로 등장한 Build automation tool이라고 소개하고 있습니다. 이번 포스팅에서는 Skaffold와 더불어 Google의 builder를 이용한 buildpack 기술로 더욱 쉽게 Kubernetes..
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에서의 성능 비교를 볼 수 있는 글은 오래되었거나, 관련 정보를 ..
Gitlab CI/CD는 Continuous Intergration, Delivery.. 등의 파이프라인을 Gitlab과 연동해 사용하게끔 해주는 소프트웨어 툴입니다. Gitlab과 GItlab CI/CD의 연동을 통해서 GItlab repository에 저장된 코드를 바탕으로 다양한 Continuous 방법론을 사용할 수 있습니다. Terraform은 기존에 GUI, 혹은 명령어로 생성해야 했던 클라우드 리소스를 코드로써 관리할 수 있게끔 해주는 툴입니다. 두 소프트웨어를 연동함으로써 Gitlab repository에 저장된 테라폼 코드를 수정 -> Commit -> Push 하는 것만으로 리소스가 실제로 배치될 수 있도록 할 수 있습니다. 이번 포스팅에서는 VS code에서 Terrafom을 GItl..
