https://page.kiglo.org/tags/architecture/ Recent content in Architecture on Kiglo Hugo ko-kr Sun, 21 Dec 2025 10:00:00 +0900 https://page.kiglo.org/posts/iac-terraform-networking/ Sun, 21 Dec 2025 10:00:00 +0900 https://page.kiglo.org/posts/iac-terraform-networking/ <h2 id="네트워크-레이어-설계의-핵심">네트워크 레이어 설계의 핵심</h2> <p>클라우드 인프라의 뼈대인 VPC를 설계할 때, &ldquo;가용영역(AZ)은 무조건 최대로 쓸수록 좋다&quot;는 생각에 빠지기 쉽습니다. 하지만 실전 아키텍처에서는 <strong>비용, 성능, 관리 복잡성</strong> 사이의 균형점이 필요하다고 생각합니다.</p> <hr> <h2 id="azavailability-zone-전략-3az-2az">AZ(Availability Zone) 전략: 3AZ? 2AZ?</h2> <p>대부분의 가이드에서는 고가용성(HA)을 위해 3개 이상의 AZ를 쓰라고 권장합니다. 하지만 실제 운영 환경, 특히 **EKS(Kubernetes)**를 운영할 때는 <strong>2개의 AZ</strong>가 더 효율적인 경우도 얼마든지 있습니다.</p> <h3 id="1-topology-aware-routingtar의-수학적-한계와-fallback">1. Topology Aware Routing(TAR)의 수학적 한계와 Fallback</h3> <p>Kubernetes의 <strong>Topology Aware Routing</strong>은 트래픽을 같은 AZ 내로 유지해 비용절감에 효율적입니다. 하지만 여기에는 &lsquo;버그&rsquo;처럼 보이는 기술적 **안전장치(Safeguard)**가 있습니다.</p> https://page.kiglo.org/posts/iac-terraform-introduction/ Sat, 20 Dec 2025 10:00:00 +0900 https://page.kiglo.org/posts/iac-terraform-introduction/ <h2 id="딸깍의-함정">&ldquo;딸깍의 함정&rdquo;</h2> <p>테라폼을 처음 접하면 모든 리소스(VPC, DB, EC2 등)를 하나의 <code>.tf</code> 파일 혹은 하나의 프로젝트 폴더에 몰아넣고 <code>terraform apply</code>를 날리고 싶다는 유혹에 빠지기 쉽다고 생각합니다. 하지만 프로덕션 환경에서 이런 방식은 매우 위험합니다.</p> <p>인프라의 규모가 커질수록 **폭발 반경(Blast Radius)**을 최소화하고 관리 효율을 높이기 위한 <strong>Layered Architecture</strong> 도입이 필수적입니다.</p> <hr> <h2 id="레이어layer-도입의-계기와-의의">레이어(Layer) 도입의 계기와 의의</h2> <p>모든 인프라를 한 곳에서 관리하면 특정 리소스(예: 보안 그룹 규칙)를 수정하다가 실수로 VPC 전체를 재생성하거나, 상태(State) 파일이 꼬여 전체 인프라가 마비되는 리스크가 존재합니다.</p>