Kiglo’s Blog

1편에서 설치한 ArgoCD 서버가 우리의 소스 코드를 읽어올 수 있도록 GitLab 저장소를 연결하고, 애플리케이션이 실제로 배포될 타겟 EKS 클러스터를 등록하는 과정을 다룹니다. 1. GitLab Repository 연결 (HTTPS Token 방식) 프라이빗 GitLab 저장소에 접근하기 위해 SSH Key 방식 대신, 관리 및 권한 제어가 용이한 Access Token (glpat) 방식으로 진행 합니다. 1) GitLab Service Account 생성 및 Token 발급 일반 사용자 계정에 종속되지 않도록 GitLab에서 제공하는 Service Account 기능을 활용하는 것이 보다 이상적입니다. (GitLab Premium 이상에서 Group/Project 레벨 Service Account 지원) ...

서론 EKS 환경에서 GitOps를 구현하기 위한 도구인 ArgoCD의 설치 과정을 다룹니다. Kustomize를 통해 Helm Chart를 래핑하여 활용하는 방법을 다룹니다. 본 포스트에서 사용되는 설정 파일과 샘플 코드는 다음 레포지토리에서 확인하실 수 있습니다 Github 링크 설치 환경 EKS Cluster Istio Service Mesh Amazon ElastiCache (Valkey 8.2) ArgoCD 설치 (Kustomize + Helm) ArgoCD를 보다 선언적으로 관리하기 위해 ./argocd 디렉토리에 Kustomize 설정을 구성했습니다. 이 방식은 Helm Chart의 유연함과 Kustomize의 구조적 관리 장점을 동시에 가져갈 수 있습니다. ...

블로그 플랫폼 선정: 어떤 도구를 쓸 것인가? 홈서버 연재를 결심하고 가장 먼저 고민한 것은 “어디에 글을 쓸 것인가"였습니다. 제가 고려했던 세 가지 선택지는 다음과 같았습니다. 1. Velog / Medium (External Platform) 장점: 별도의 서버 세팅이 전혀 필요 없으며, 플랫폼 자체의 유입 덕분에 글을 알리기에 가장 유리합니다. 사실 운영 효율 면에서는 가장 합리적인 선택지입니다. 단점: 디자인 커스터마이징에 제약이 있고, 무엇보다 이미 구축해둔 홈서버와 개인 도메인을 최대한 활용하고 싶다는 ‘자기만족’의 관점에서 제외하게 되었습니다. 2. Ghost (Self-hosted) 장점: UI가 다채롭고 에디터가 좋습니다. 뉴스레터 기능도 기본 탑재되어 있고 실제 프로덕션에서 Ghost 를 운영하는 기업들이 많습니다. 단점: Node.js와 데이터베이스를 직접 운영해야 합니다. 버전 업데이트나 DB도 같이 관리해야 하며, 미니 PC의 리소스를 상시 점유한다는 점이 간단한 블로그 운영을 원하는 저에게는 부담스러웠습니다. 3. Hugo (SSG) 장점: 마크다운 기반으로 로컬에서 작성하며, 결과물이 정적 HTML이므로 서버 부하나 보안 위협이 거의 없습니다. 테마를 통한 커스터마이징이 가능하고, Git으로 모든 이력을 관리할 수 있습니다. 단점: 초기 테마 세팅이나 마크다운 문법에 익숙해지는 과정이 필요합니다. 최종 선택: Hugo 홈서버 운영법을 공유하는 블로그 자체가 홈서버 부하의 원인이 되는 것은 앞뒤가 맞지 않는다고 생각했습니다. “최소한의 리소스로 최고의 퍼포먼스를 내자"는 이번 홈서버 구축 철학에 맞춰, 가장 가볍고 개발자 친화적인 Hugo를 최종 선택하게 되었습니다. ...

전역 리전 모니터링의 한계와 도전 이전 글(실전 편)에서 테라폼을 이용해 2-AZ 기반의 탄탄한 네트워크 기반을 마련했습니다. 이번에는 이렇게 구축된 인프라 위에서 발생하는 중요한 이벤트들을 전역 리전 단위로 어떻게 효율적으로 관리할 수 있는지 다뤄보겠습니다. AWS에서 다중 리전을 운영하다 보면, 각 리전에서 발생하는 중요한 이벤트(GuardDuty 위협 감지, AWS Health의 점검 공지, 루팅 로그인 등)를 개별적으로 관리하는 것이 매우 번거롭다는 것을 알게 됩니다. 리전마다 람다(Lambda)를 띄우고 알림 채널(SNS/Slack)을 연동하는 것은 이른바 “노가다"에 가깝습니다. 이를 해결하기 위해 EventBridge의 리전 간 포워딩 기능을 활용한 효율적인 아키텍처를 소개합니다. ...

이론을 넘어 실전으로 VPC 세팅과 Peering vs TGW 글 내용을 기반으로, 2AZ VPC 를 terraform 으로 구성해 보겠습니다. 1. 변수 정의와 리전 설정 먼저 확장성을 위해 AZ 목록을 변수화하고 리전을 정의합니다. variable "region" { default = "ap-northeast-2" } variable "azs" { description = "사용할 가용 영역 리스트" type = list(string) default = ["ap-northeast-2a", "ap-northeast-2c"] # 2-AZ 전략 } variable "vpc_cidr" { default = "10.0.0.0/16" } 2. VPC와 서브넷: cidrsubnet과 count의 활용 서브넷을 하드코딩하는 것은 가장 피해야 할 습관입니다. 테라폼의 내장 함수를 사용하여 자동으로 계산되게 구성합니다. ...

네트워크 레이어 설계의 핵심 클라우드 인프라의 뼈대인 VPC를 설계할 때, “가용영역(AZ)은 무조건 최대로 쓸수록 좋다"는 생각에 빠지기 쉽습니다. 하지만 실전 아키텍처에서는 비용, 성능, 관리 복잡성 사이의 균형점이 필요하다고 생각합니다. AZ(Availability Zone) 전략: 3AZ? 2AZ? 대부분의 가이드에서는 고가용성(HA)을 위해 3개 이상의 AZ를 쓰라고 권장합니다. 하지만 실제 운영 환경, 특히 **EKS(Kubernetes)**를 운영할 때는 2개의 AZ가 더 효율적인 경우도 얼마든지 있습니다. 1. Topology Aware Routing(TAR)의 수학적 한계와 Fallback Kubernetes의 Topology Aware Routing은 트래픽을 같은 AZ 내로 유지해 비용절감에 효율적입니다. 하지만 여기에는 ‘버그’처럼 보이는 기술적 **안전장치(Safeguard)**가 있습니다. ...

“딸깍의 함정” 테라폼을 처음 접하면 모든 리소스(VPC, DB, EC2 등)를 하나의 .tf 파일 혹은 하나의 프로젝트 폴더에 몰아넣고 terraform apply를 날리고 싶다는 유혹에 빠지기 쉽다고 생각합니다. 하지만 프로덕션 환경에서 이런 방식은 매우 위험합니다. 인프라의 규모가 커질수록 **폭발 반경(Blast Radius)**을 최소화하고 관리 효율을 높이기 위한 Layered Architecture 도입이 필수적입니다. 레이어(Layer) 도입의 계기와 의의 모든 인프라를 한 곳에서 관리하면 특정 리소스(예: 보안 그룹 규칙)를 수정하다가 실수로 VPC 전체를 재생성하거나, 상태(State) 파일이 꼬여 전체 인프라가 마비되는 리스크가 존재합니다. ...

왜 GitLab인가? (GitHub vs GitLab) 홈서버의 배포 자동화를 위해 가장 먼저 고민한 것은 “어떤 플랫폼을 쓸 것인가?“였습니다. 흔히 쓰이는 GitHub Actions 대신 GitLab CI/CD를 선택한 이유는 다음과 같습니다. 비교 항목 GitHub (Free) GitLab (Free) 비고 Registry 용량 500MB 5GB 홈서버 이미지 적재 시 유리 Self-hosted Runner 가능 매우 간편함 GitLab Runner의 아키텍처가 더 직관적 CI/CD 기능 유연함 (Actions) 강력한 통합 내장된 배포 관리 기능이 풍부함 특히 홈서버는 리소스가 한정적이기 때문에, Container Registry 용량이 넉넉하고 Runner 설치 및 관리가 압도적으로 편한 GitLab이 더 매력적인 선택지였습니다. ...

Why Teleport? 홈서버를 외부에서 안전하게 접속하기 위해 기존에는 VPN(Tailscale, WireGuard)이나 단순히 SSH 포트를 개방하는 방식을 사용했습니다. 하지만 다음과 같은 이유로 Teleport를 도입하게 되었습니다. Access plane: SSH, RDP, Kubernetes, Database, Web App 등 다양한 프로토콜을 단일 Gateway로 통합 관리 Audit Log: 누가 언제 어디서 서버에 접속해서 어떤 명령어를 입력했는지 녹화 및 기록 (보안 감사) RBAC: 역할 기반 접근 통제 No VPN: 별도의 VPN 클라이언트 없이 웹 브라우저만으로도 터미널 접속 가능 더 자세한 정보는 Teleport 공식 홈페이지와 공식 문서(Documentation)를 참고하세요. ...

도메인 구매 저는 Cloudflare Registrar를 통해 도메인을 구매했습니다. Cloudflare를 선택한 이유는 관리 편의성도 있지만, 도메인 등록 비용에 별도의 수수료를 붙이지 않고 도매가 수준으로 제공하기 때문입니다. 또한, 뒤에 설명할 보안 기능들을 도메인 연동 즉시 무료 플랜에서도 대부분 사용할 수 있다는 점이 큰 장점입니다. Cloudflare Tunnel (cloudflared) 도입 기존의 서비스 노출 방식은 공유기에서 포트 포워딩(Port Forwarding) 을 설정하는 것이었습니다. 하지만 이 방식은 몇 가지 고질적인 문제가 있습니다. 보안 취약성: 특정 포트가 인터넷에 직접 노출되어 공격자의 타겟이 되기 쉽습니다. 유동 IP 대응: IP가 바뀔 때마다 DDNS 설정을 갱신해야 합니다. 포트 부족: 하나의 공인 IP에서 여러 서비스를 운영하기 번거롭습니다. 저는 이를 해결하기 위해 Cloudflare Tunnel을 사용했습니다. ...