변경 배경기존 회사에서는 인프라 환경용 Application들을 모두 단일 배포로 묶어서 관리하고 있었습니다.또한 멀티 클러스터 환경임에도 불구하고 각 클러스터마다 별도의 Argo CD 인스턴스를 운영했기 때문에,환경 관리와 배포 작업이 반복되고, 변경 사항을 모든 클러스터에 동일하게 적용하는 데 많은 시간이 소요되었습니다.이러한 구조는 다음과 같은 불편함을 만들었습니다.동일한 인프라 리소스를 클러스터별로 반복 등록 및 배포공통 구성 버전 관리가 어렵고, 환경별 차이로 인한 누락 발생신규 클러스터 추가 시 배포 작업량이 기하급수적으로 증가해결 방향운영 효율성을 높이기 위해 개발자가 사용하는 Argo CD는 그대로 유지하면서,인프라 전용 Argo CD를 별도로 구축하여 모든 클러스터를 하나로 연결하는 방식..
회사에서 istio 를 사용하다 보니, 특정 IP에 대해서만 접근할 수 있는 방법들이 필요했습니다.여기서 ISTIO authorizationpolicy 를 통해서 접근 제어를 하기로 하였으며, 관련 적용을 진행할때에 대해 어려움, 그리고 적용 방법에 대해 말씀드리고자 합니다.1. AuthroizationPolicy 기본 개념 소개AuthroizationPolicy란?Istio에서 제공하는 RBAC(역할 기반 접근 제어) 기능특정 요청(Source)이 어떤 대상(Destination)으로 어떤 조건(Method, Path, IP 등) 하에 접근 가능한지 정의 가능예를 들어, 특정 IP 대역에서만 Ingress Gateway에 접근을 허용하고 싶다면 아래와 같이 설정할 수 있습니다.kind: Authoriz..
Apache Kafka 4.0 버전부터는 클라우드 네이티브 환경 최적화를 주요 목표로 하고 있습니다. 가장 큰 변화는 ZooKeeper 의존성을 완전히 제거하고 KRaft(Kafka Raft) 모드로 전환하는 것입니다.이 글에서는 기존 ZooKeeper 기반 아키텍처와 KRaft 아키텍처의 차이점, 장점, 그리고 전환 과정에서 고려해야 할 점들을 정리해 보겠습니다.---1. 기존 ZooKeeper 기반 아키텍처의 한계Kafka는 오랫동안 클러스터 메타데이터 관리를 위해 외부 시스템인 ZooKeeper에 의존해왔습니다. #### 역할- ZooKeeper: 모든 메타데이터를 저장하고 관리하는 중앙 시스템- Kafka 브로커 중 하나가 컨트롤러로 선출되어 ZooKeeper와 통신, 메타데이터 전파#### 한..
전환 목적현재 회사에서 모니터링 및 APM 도구로 Datadog 을 사용하고 있습니다.그러나 DataDog이 AWS VPC 외부에 있는 모니터링 툴이다 보니, 외부로 나가는 트래픽 비용이 상당히 발생하고 있었습니다. 또한, 외부 통신을 사용하다 보니 보안 측면에서도 고려해야 할 부분이 많다고 느꼈습니다. 고려 사항이러한 비용 문제와 보안 이슈를 해결하기 위해 내부 네트워크에서 통신할 수 있는 방법을 찾던 중, Datadog에서 제공하는 Private Endpoint를 활용하여 내부 통신을 할 수 있게 지원이 가능하다는 문서를 발견하게 되었고, 이를 적용하기 위해 몇가지를 고려해 보았습니다. 첫 번째로, 현재 사용하는 서비스가 ap-northeast-2(Seoul) 리전에 한정되어있다보니, us-east-..
Dockerfile 작성 시 주의해야 할 사항과 최적화 방법Dockerfile은 단순히 컨테이너 이미지를 만드는 도구가 아니라, 배포 속도, 운영 효율성, 유지보수성에 직접적인 영향을 미치는 중요한 요소입니다.이번 글에서는 Dockerfile을 작성하면서 고려해야 할 핵심 포인트를 정리했습니다.1. 이미지 용량 최소화이미지 용량이 커지면 배포 속도가 느려지고, 네트워크 트래픽·스토리지 비용도 증가합니다.따라서 가벼운 이미지를 만드는 것이 첫 번째 목표입니다.최적화 방법가벼운 베이스 이미지 선택풀 패키지 이미지 대신 alpine 버전을 사용해 기본 용량을 최소화합니다.예: golang:1.16-alpine, python:3.8-slim불필요한 파일 제거설치 중 생성된 패키지 캐시, 로그, 임시 파일 등을 ..
대규모 조직이나 여러 환경(Dev/Prod)을 운영하는 경우, 각각의 Kubernetes 클러스터에 Argo CD를 설치하는 것은 관리 포인트가 많아지고 운영이 복잡해질 수 있습니다.이 글에서는 하나의 중앙 Argo CD 인스턴스로 여러 Kubernetes 클러스터를 관리하는 Multi-Cluster GitOps 환경 구성 방법을 소개합니다.목적Infra 전용 Argo CD 인스턴스를 통해 여러 환경(EKS Dev/Prod 등)의 리소스를 통합 관리Argo CD의 cluster add 기능을 활용해 멀티 클러스터로 애플리케이션 배포동일한 GitOps Workflow를 모든 클러스터에 일관성 있게 적용ArgoCD Multi-Cluster Setting1. 네트워크 연결 확인멀티 클러스터 구성을 위해서는 A..
Argocd란?ArgoCD는 Kubernetes를 위한 GitOps 기반의 CD 도구 입니다. Git 저장소를 Source 저장소로 담고, ArgoCD를 통해 Kubernetes 리소스를 클러스터에 자동으로 배포하고 동기화합니다.Keycloak + Argocd 연동ArgoCD는 기본적으로 여러 인증 방식을 지원하며, 그중 OIDC(OpenID Connect)를 통해 외부 IdP(Keycloak 포함)와 쉽게 통합할 수 있습니다. 이 글에서는 Keycloak을 ArgoCD의 인증 공급자로 연동하는 방법을 알아보고자 합니다.연동 구성 개요Keycloak에서 ArgoCD용 클라이언트(Client) 생성Keycloak Realm 설정 (scope, mapper 포함)ArgoCD에 OIDC 설정 적용 (argoc..
EC2 Autoscaling Group에서 새로운 EC2가 Launch 되거나, Terminate 될때, 알림을 받을 수 있습니다!SNS을 통해서 Email로 전송을 받거나, 필요에 따라, S3나 Slack으로 전송할 수 있습니다. 1. Email 전송방법현재 Autoscaling Group 을 보면 활동 부분에 아무런 알림 설정이 되어있지 않습니다. SNS 항목으로 이동하여, 새로운 주제를 생성합니다. 새로운 주제 생성 후, 구독을 새로 생성합니다. Email 주소로 입력하게 되면, 확인 메일이 발송되게 됩니다. 메일에서 구독확인을 누르게 되면, aws 콘솔상에서도 상태가 변경됩니다. Autoscaling 그룹내에서, 알림을 생성합니다. 생성된 주제를 선택합니다. 메일발송되면, 아래와같은 내용으로 오..
1. 환경 정의 - 계정이 2개 존재 (Account A, Account B) - A 계정에서는 Kinesis Data Firehose 을 사용하고 있음. - B 계정에서는 해당 firehose내용들을 S3에 저장하고 싶음. 2. 설정 방법 1) Account B 계정 설정 - S3 생성 및 버킷 정책 설정 { "Version": "2012-10-17", "Statement": [ { "Sid": "account_A cross account access", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::[accountA_id]:root" ] }, "Action": [ "s3:GetLifecycleConfiguration", "s3:ListBucket..
1. Prometheus HA 문제 기존 프로메테우스 환경은 단일 노드에서 로컬 저장소를 사용하는 단순한 구조로 이루어져있습니다. prometheus 는 서버를 주체적으로 데이터를 수집해오는 server-side pool 방식을 사용하므로 prometheus 가 정지되어있는 동안에는 데이터 누락이 발생하게됩니다. 또한 프로메테우스 자체에서 HA구성을 지원하지 않기 때문에, 모니터링서비스가 많아질 수록, scale out을 할 수 없는 문제점이 있습니다. 2. Thanos 란 2-1) Thanos 정의 - Thanos 란 prometheus 기반 오픈소스프로젝트 - 모니터링 시스템 확장 도구 - 프로메테우스에서 scale out 이 가능한 도구 - HashMode 사용 Hashmode 란? Target의 ..