TIL

[에스넷시스템 부트캠프] TIL Day 62~66 - 프로젝트 4주차

yulee_to 2025. 8. 23. 00:26
728x90
반응형

Day 62 - EKS 공부

최근 Kubernetes 환경에 대한 개념은 어느 정도 익숙해졌지만, AWS에서 제공하는 EKS에 대해서도 알아야겠다는 생각이 들었다. 단순히 문서를 읽는 것도 방법이지만, 이해도를 높이기 위해 AWS Korea 공식 유튜브 채널의 강의를 시청했다.

 

강의를 통해 Kubernetes의 전체적인 개념을 다시 복습할 수 있었고, EKS가 제공하는 기능과 AWS 환경에서 어떤 방식으로 활용할 수 있는지도 배울 수 있었다. 무엇보다도 AWS의 솔루션 아키텍트가 직접 강의하는 내용이라 신뢰도가 높았다.

단순히 영상을 시청하는 것에 그치지 않고, 헷갈릴 수 있는 개념들을 언제든 다시 볼 수 있도록 Notion에 정리했다. 이 정리된 내용은 앞으로 실제로 EKS Cluster를 구성할 때 참고 자료로 활용할 예정이다.

 

참고 영상

https://youtu.be/E49Q3y9wsUo?si=I-OXGG93Hc24Qg7J 

Day 63 - EKS & Terraform 공부

EKS 공부 계속하

어제 이어서 EKS 학습을 진행했다. 이번에는 보안과 네트워크 관련된 개념을 접했는데 다소 어렵게 느껴졌다. 이해가 확실치 않은 부분은 생성형 AI를 활용해 내 이해가 맞는지 검증하면서 공부했다.

영상 몇 개만으로 EKS를 완전히 이해했다고는 할 수 없지만, 적어도 환경을 구축하는 데 필요한 수준은 갖출 수 있었다. 또한 정리해둔 내용을 주기적으로 복습하면 전체적인 프로세스와 세부 개념을 함께 잡을 수 있을 것 같다.

콘솔 기반 관리의 불편함

AWS 콘솔을 통해 리소스를 직접 관리하면서 몇 가지 불편함을 크게 느꼈다.

  • 리소스를 하나씩 생성하다 보니 이름 규칙을 잊어버려 다시 확인하느라 시간이 소요됨
  • 여러 리소스를 확인하느라 브라우저 탭만 늘어남
  • 설정 변경 시 이전 상태를 추적하기 어려움

AWS CLI를 이용해 쉘 스크립트를 작성하는 방식도 있었지만 Terraform의 장점이 더 크다고 느낌

Terraform 도입 계기

Terraform

  • AWS 사용 경험 중 느낀 불편함을 해결할 수 있을 것 같아 도입
  • 명령어가 단순하고 공식 문서 튜토리얼만으로도 학습이 가능해 접근성이 높음
  • AWS 리소스 자체에 대한 이해가 필요하다는 러닝커브가 있었지만, 이는 콘솔 사용 시에도 동일하게 요구되는 부분이라 큰 문제가 되지 않음 (AI의 도움도 있고)
  • 결과적으롴 콘솔 대신 Terraform을 통해 인프라를 구성하는 편이 더 효율적이라고 판단

IaC의 장점

  • 멱등성: 여러 번 실행해도 같은 결과가 보장됨
  • 버전 관리 용이: Git을 통한 이력 관리와 롤백이 가능
  • 코드 기반 관리:
    • 모듈화와 변수 활용을 통해 재사용성이 높음
    • 하드코딩 대신 최신 값을 참조하여 유지보수가 용이
  • 리소스 종속성 관리: 리소스 간 의존 관계를 코드로 명확히 정의할 수 있어 관리 편의성 증대
  • 테스트 및 시뮬레이션 가능 : terraform plan 같은 기능으로 실제 적용 전에 변경 사항을 미리 확인 가능

Terraform 학습

Terraform의 기본 개념을 이해하기 위해 HashiCorp 공식 페이지를 참고했다.
기본적인 구조와 문법은 생각보다 어렵지 않았고, 실습 환경 구성과 적용도 금방 끝낼 수 있었다.

Terraform을 쓰다 보니 Git과 비슷한 경험을 받았다.

  • git init ↔ terraform init
  • git add/commit/push ↔ terraform apply

즉, 코드를 작성하고 기록/적용하는 흐름이 비슷해서 익숙하게 느껴졌다.

 

참고 문서

https://developer.hashicorp.com/terraform

 

Terraform | HashiCorp Developer

Explore Terraform product documentation, tutorials, and examples.

developer.hashicorp.com

Day 64 - Terraform으로 VPC 구성하기

VPC 구성 시도

어제 학습한 Terraform을 활용해 AWS 인프라를 직접 구성해보기로 했다. 가장 먼저 VPC를 정의하고, CIDR 블록과 가용 영역, 서브넷을 설정했다. 이어서 백엔드 서버가 외부 API와 통신할 수 있도록 NAT Gateway도 구성했다.

코드를 작성한 뒤 terraform plan으로 변경 사항을 시뮬레이션하고, 이어서 긴장되는 마음으로 terraform apply를 실행했다.

 

발생한 문제: Elastic IP 생성 실패

NAT Gateway를 위해 Elastic IP(EIP)를 할당해줘야 하는데, 이 EIP 생성 부분에서 에러가 났다. 

╷
│ Error: creating EC2 EIP: operation error EC2: AllocateAddress, https response error StatusCode: 400, RequestID: 9058c663-1c65-49ef-8652-001832c3459d, api error AddressLimitExceeded: The maximum number of addresses has been reached.       
│
│   with aws_eip.nat[0],
│   on vpc.tf line 53, in resource "aws_eip" "nat":
│   53: resource "aws_eip" "nat" {
│
╵
╷
│ Error: creating EC2 EIP: operation error EC2: AllocateAddress, https response error StatusCode: 400, RequestID: fe6c6867-311f-4505-a468-4f31e2b7ef74, api error AddressLimitExceeded: The maximum number of addresses has been reached.       
│
│   with aws_eip.nat[1],
│   on vpc.tf line 53, in resource "aws_eip" "nat":
│   53: resource "aws_eip" "nat" {
│

문제

Elastic IP Address 생성 및 할당 실패

원인

AWS에서는 Elastic IP Address가 리전 당 최대 5개 할당 가능한데, 현재 우리가 사용하고자 하는 리전에서 5개를 할당해놔서 실행에 실패함

해결

NAT Gateway 서비스를 이용하지 않고 EC2를 NAT Gateway 용도로 사용하기 위해 NAT Instance를 생성함

배운점

이번 경험을 통해 AWS 리소스에는 서비스별 기본 제한이 존재한다는 사실을 다시금 체감했다. 서비스별 기본 제한을 영어로는 Soft Limit이라고 부른다고 한다. 

앞으로는 인프라 설계 시, 단순히 구조만 생각하는 것이 아니라 리소스 제한과 비용 요소까지 고려해야 한다는 교훈을 얻었다. 

Day 65 - Terraform으로 나머지 인프라 구성하기

인프라 구성 진행

어제 VPC 구성을 마친 데 이어, 오늘은 Terraform으로 나머지 주요 인프라를 구축했다.

  • EKS Cluster
  • S3 (정적 페이지 서빙용 버킷)
  • CloudFront (CDN)
  • DynamoDB (데이터 저장)
  • Route53 (도메인 관리)
  • WAF (웹 방화벽)

각 리소스를 하나씩 코드로 정의하고 terraform apply로 배포를 진행했다. 또한 인프라 리소스들이 정상적으로 상호 연결될 수 있도록 IAM Role과 Policy 설정도 함께 구성했다.

terraform 코드



terraform plan 실행
정적 페이지를 위한 S3 Bucket

 

 

Day 66 - S3 Bucket 추가 구성 및 연동 확인

코드 버전 관리 (GitHub 업로드)

이번에 만든 Terraform 코드와 백엔드 코드를 각각 GitHub에 올려 버전 관리를 시작했다.

  • 인프라 관련 코드는 별도의 리포지토리를 만들어 관리
  • 애플리케이션 코드와 분리하여, IaC와 애플리케이션 개발 흐름을 독립적으로 관리 가능

버전 관리를 적용하면서, 앞으로는 단순히 로컬에서 실험하는 것에 그치지 않고 팀 단위 협업 및 변경 이력 추적이 가능해졌다.

S3 Bucket 추가 생성

Terraform으로 인프라 구성을 마무리했다고 생각했지만, 중요한 부분을 하나 놓치고 있었다. 애플리케이션에서 사용하는 이미지 저장용 S3 Bucket을 별도로 만들지 않았던 것.

처음 설계도에는 정적 페이지 서빙을 위한 S3 Bucket만 정의해두었기 때문에, 이미지 업로드 기능을 위해 새로운 S3 Bucket을 생성했다. 이후 기존에 만들어둔 CloudFront와도 연결해주었다.

cloudfront

연동 테스트

애플리케이션을 수정하기 전에, S3와 CloudFront, Route53 간에 연동이 잘 되어 있는지 먼저 테스트를 진행했다.

  • 팀원이 개발해둔 프론트엔드 코드를 S3에 업로드
  • CloudFront 도메인으로 접속해 확인

처음에는 페이지가 뜨지 않아 당황했지만, 원인은 CloudFront 캐싱이었다.
TTL이 남아 있어 새로운 파일이 반영되지 않은 것이었고, 캐시를 초기화(Invalidation) 해주자 정상적으로 프론트 페이지가 로딩되었다.

Route53 연동 문제

Route53에 팀원이 등록해둔 도메인에 CloudFront 도메인을 지정해 두었기 때문에, 바로 접속이 가능할 줄 알았다.
하지만 시간이 지나도 연동이 되지 않았고, 아직 해결되지 않은 상태다. 이 부분은 주말이나 다음 주 중에 따로 확인할 예정이다.

 

✍️ 주간 회고

Jira 보드

이번 주는 기획에 없던 Terraform을 새로 도입하느라 예상보다 시간이 조금 더 걸렸다. 사실 초반에는 “굳이 지금 해야 할까?” 하는 고민도 있었는데, 막상 적용해보니 웹 콘솔에서 리소스를 하나씩 확인하던 번거로움이 사라지고 훨씬 체계적으로 관리할 수 있어 뿌듯했다. 지금은 조금 돌아온 것 같아 보여도, 앞으로 갈수록 이 선택이 좋은 발판이 될 거라는 확신이 든다.

 

이번 주에는 Figma 대신 Jira를 보면서 진행 상황을 정리했는데, 한눈에 흐름을 볼 수 있어 나름의 성취감도 느낄 수 있었다.

다만 아쉬운 점은, Terraform 세팅에 몰두하느라 EKS 클러스터에 애플리케이션을 배포하는 본격적인 단계에 빨리 들어가지 못했다는 것. 다음 주에는 드디어 핵심 단계에 돌입할 생각을 하니 설레기도 하고, 동시에 잘 마무리할 수 있을지 긴장도 된다. 그래도 이번 주에 다져둔 기반이 든든하니, 조금 더 자신감을 가져도 되지 않을까 싶다.

728x90
반응형