ebson

들어가며Bastion 호스트는 오랫동안 사설망의 운영 셸을 위한 가장 짧은 답이었습니다. 사설 서브넷에 떠 있는 워크로드에 누군가가 들어가야 할 일은 늘 생기고, 그 누군가가 IGW나 NAT를 거치지 않으면서도 셸을 잡을 수 있는 자리가 필요했습니다. 그래서 22번 포트를 한 호스트에만 열어 두고, 그 호스트를 통해 안쪽으로 다시 들어가는 결의 토폴로지가 자연스럽게 자리 잡았습니다. 호텔로 비유하자면 정문 앞에 따로 두는 보안 부스 같은 자리였고, 그 부스에서 키와 신분증을 받아 안쪽 객실로 들어가는 결의 운영이었던 셈입니다. 이 글은 그 부스가 더 이상 필요하지 않은 자리, 즉 SSM Session Manager로 셸을 잡는 결정이 비교적 평이하게 성립하는 자리를 정리해 보려는 글입니다. 이 글은 실제..

들어가며SG와 NACL이라는 두 도구를 한 VPC 위에 함께 두는 일을 두고, 처음 설계 단계에서 가장 자주 듣는 질문은 "둘 다 두면 중복 아닌가요"라는 것이었습니다. 한쪽이 막는 자리를 다른 쪽이 또 막는 모양처럼 보이는 자리가 분명히 있고, 같은 트래픽이 두 번 검사받는 것처럼 느껴지는 것도 사실입니다. 그래서 이 글은 두 도구가 어디에 붙어 있고, 무엇을 다르게 막는지를 한 번 정직하게 정리해 보려는 글입니다. 비유 한 줄로 시작해 보자면, SG는 호텔의 객실 출입 통제이고 NACL은 호텔 정문의 검문에 가까운 위치에 자리 잡고 있다고 느꼈습니다. 같은 사람을 두 번 마주치는 듯해도, 한 자리는 ENI라는 객실의 문 앞이고 다른 한 자리는 서브넷이라는 정문의 검문대인 셈입니다. 이 글은 운영 단계..

들어가며VPC Endpoint, 혹은 PrivateLink라는 이름을 처음 마주한 자리에서 가장 자주 듣는 설명은 "NAT 비용을 줄여 주는 도구"입니다. 사설 워크로드가 S3, ECR, CloudWatch Logs 같은 AWS 매니지드 서비스에 접근할 때 NAT Gateway를 거치지 않도록 해 주어, NAT 처리 비용과 AZ 간 데이터 전송 비용을 함께 줄여 준다는 식의 소개가 따라옵니다. 이 설명은 틀리지 않습니다. 다만 본 글에서 정리하려는 것은, 비용 절감이라는 첫인상으로 시작했다가 막상 IaC로 PrivateLink를 그려 두면서 오히려 보안 도구의 결로 다가왔던 한 결정의 회계입니다.이 글은 실제 트래픽이 흐르는 운영 단계의 회고가 아니라, 개인 프로젝트로 VPC를 설계하고 IaC로 구축하는..

들어가며VPC 설계에서 NAT Gateway는 흔히 "그냥 하나 두면 되는 것"으로 다뤄집니다. 외부로 나가는 사설망의 트래픽에 공인 IP를 입혀 주는 한 컴포넌트라는 정의 자체는 단순하고, AWS의 매니지드 자원이라 운영 부담도 크지 않다는 인상이 따라옵니다. 그래서 "AZ마다 하나씩 둔다"는 권고가 처음 보이면 살짝 과해 보이기도 합니다. 비용이 그대로 곱해지기 때문입니다. 본 글에서 정리하려는 것은 이 권고를 마주한 자리에서 "prod에서는 AZ별로 3개를 두고 dev/beta에서는 단일 NAT 하나로 좁힌다"는 환경별 토폴로지 결정을 내리기까지의 산술적 회계입니다.이 글은 실제 트래픽이 흐르는 운영 단계의 회고가 아니라, 개인 프로젝트로 VPC를 설계하고 IaC로 구축하는 단계에서 검토한 가정과 ..

들어가며새 VPC를 설계할 때 자주 마주치는 질문이 있습니다. "서브넷은 그냥 /24면 되지 않나요." 250개 정도면 충분해 보인다는 직감은 사내 데이터센터 시절의 IP 계획에 깊이 뿌리내리고 있고, 한동안은 클라우드 위에서도 그 직감이 어느 정도 통하던 시기가 있었습니다. 그러나 ECS Fargate 위에 마이크로서비스를 올리고, 그 위에 Blue/Green 배포 전략을 얹는다고 가정하는 순간 이 직감은 조금 다른 결로 흔들립니다. 본 글에서 정리하려는 것은 개인 프로젝트로 VPC를 설계하면서 "Private-App 서브넷을 왜 /24가 아니라 /20으로 잡았는가"라는 하나의 결정을 산술적으로 풀어 보는 일입니다. 실제 트래픽이 흐르는 운영 단계의 회고가 아니라, 설계와 IaC 구축 단계에서 검토한 ..

들어가며VPC를 새로 그리는 자리에 앉을 때마다 한 번쯤은 "그래서 IPv6는 어떻게 하실 건가요"라는 질문이 따라옵니다. 듀얼스택을 켜 두는 일이 마치 모던 인프라의 표지처럼 받아들여지는 분위기도 분명히 있습니다. 그러나 듀얼스택이 만들어내는 효용과 그것이 데려오는 운영 비용은 분리해서 살펴봐야 합니다. 둘을 같은 표 위에 올려놓고 단순히 더해 봤을 때, 합계가 양(+)인 아키텍처가 있고 음(-)인 아키텍처가 있다고 생각합니다.본 글에서 정리하려는 것은 개인 프로젝트로 VPC를 설계하고 IaC로 구축하는 과정에서 "지금 단계에서는 IPv6 듀얼스택을 적용하지 않는다"는 결정을 내린 흐름입니다. 실제 트래픽이 흐르는 운영 단계의 회고가 아니라 설계와 구축 단계에서 검토한 가정과 합계를 정리하는 글이라는 ..

CI/CD 파이프라인은 실패하면 가급적 빨리 알아차려야 합니다. 빌드가 20초 더 느려진 이유, 큐에 빌드가 쌓이는 이유, 어제까지 멀쩡하던 Job이 오늘 갑자기 실패한 이유를 사람의 기억이나 Console Output을 뒤로 감아가며 찾는 데에는 분명한 한계가 있습니다. 애플리케이션 서버에 APM을 붙이듯, CI/CD 자체에도 관측 가능성(Observability)이 필요하다고 느끼게 되는 이유입니다.이 글은 Spring Boot API 6종과 단명 Spring Batch 한 벌을 로컬 단일 노드 Jenkins로 운영하는 참고 프로젝트에 Metrics, Traces, Logs 세 축을 붙이면서 정리한 기록입니다. Jenkins Prometheus Plugin과 OpenTelemetry Plugin, 그..

CI/CD 파이프라인은 한 번 만들면 오래 갑니다. 정확히는, 한 번 만든 그대로 오래 "가 보이기만 할" 때가 많습니다. 콘솔 로그 마지막 줄에 BUILD SUCCESS가 찍히고 빨간 아이콘 대신 파란 아이콘이 남으면, 그다음부터는 아무도 그 파이프라인을 다시 열어보지 않게 됩니다. 문제가 수면 위로 떠오르는 순간은 대개 배포 중 장애가 났을 때이고, 그제서야 pkill -f 한 줄이 의도치 않은 프로세스를 죽였거나, PID 파일이 남은 채 프로세스만 사라진 좀비 상태였거나, 헬스체크가 끝나기도 전에 Jenkins가 자식 프로세스를 함께 거둬간 것이 드러납니다.이 글은 Spring Boot API 6종과 Spring Batch 1종을 로컬 단일 노드 Jenkins로 운영하는 참고 프로젝트에서, 기본값만..