반응형
개요
최근 개발자 친구들과 함께 토이 프로젝트를 시작했다.
토이 프로젝트를 하는 목적은 아래와 같다.
- 현업에서 사용해보지 않았던 기술들 (Terraform, GitHub Actions, ECS launch type ec2) 사용해보기
- Front-End 및 Back-End 키워드 얻기
일단 현재 다룰 수 있는 기술이 많지 않기 때문에 바운더리를 조금 늘리고 싶었다. 지난 분기 회고에도 동일한 생각을 갖고 있었다. 그래서 Terraform과 Github Actions 또 AWS SAP 자격증 공부를 하고자 했는데, SAP는 그리 급하지 않다고 느껴졌고 많은 회사에서 요구하는 IaC와 CI/CD에 할애하고자 했다. 그래서 개인 시간을 활용해 토이 프로젝트를 진행하며 개인적으로 부딪혀가며 공부해보는게 좋다고 생각했다. 물론 CS 지식도 아직 할게 많이 남았으나... 밥 벌어먹고 사는데 큰 지장은 없고, 프로젝트 진행하면서 얻을 키워드도 많을것이기에 천천히 부숴볼까 한다. (잘못된 생각일수도 있다고 듦ㅠㅠ)
뭐 아무튼 서론이 길었는데, 위와 같은 목적을 달성하기 위해서 주변 개발자 친구 2명과 DevOps에 관심이 있는 나를 주축으로 프로젝트를 만들어 보기로 했다.
주요 내용은 아래와 같다.
- 개요 : 친숙한 가족을 위한 웹 애플리케이션 서비스
- 내용 : 주변을 보면 1인 가구가 점점 늘고있고, 가족 간 대화가 많지 않은 것 같다. 가족 간 단톡에는 집에 언제 오는지 밥은 같이 먹는지 또는 간단한 안부 조차 묻지 않고 있다. 해당 서비스는 가족 개개인의 아바타를 가져 아바타를 꾸밀 수 있고, 해당 아바타를 한눈에 볼 수 있는 아바타 룸(가칭), 가족 간 미션을 자유롭게 발부해 미션을 해결한다. 이러한 기능을 통해 가족 간 친목을 도모함과 동시에 가족을 조금 더 친숙하게 만들 수 있는 애플리케이션을 만들어보고자 한다.
- 인프라 : 주된 리소스는 AWS를 사용하며 3-Tier 아키텍쳐를 IaC(Terraform)으로 구성해보고자 했다. 자세한 내용은 아래 기술하겠다.
- 개발 : React.js와 Java Spring Boot을 이용한 개발
인프라 구성 내용
서비스 단위 별 작성
- VPC
- VPC의 경우 DEV, PROD 로 구성
- VPC의 CIDR은 아래와 같이 결정했으며, 서비스 규모에 따라 23 Bit로 결정함. 23 Bit의 경우 512 개의 IP 주소를 갖고 있음. 서비스 규모의 특성 상 그렇게 많은 IP를 사용하지 않을거라 생각이 듦
- DEV VPC :10.0.0.0/23
- PROD VPC :10.0.2.0/23
- Subnet
- Subnet의 A zone, C Zone으로 구성하여 가용성을 보장한다.
- Subnet의 CIDR은 아래와 같이 결정했으며, 서비스 규모에 따라 25 Bit로 결정함
- DEV
- 10.0.0.0/25 (Public Subnet - A Zone)
- 10.0.0.64/25 (Public Subnet - C Zone)
- 10.0.1.0/25 (APP Private Subnet - A Zone)
- 10.0.1.64/25 (APP Private Subnet - C Zone)
- 10.0.1.128/25 (DB Private Subnet - A Zone)
- 10.0.1.192/25 (DB Private Subnet - C Zone)
- PROD
- 10.0.2.0/25 (Public Subnet - A Zone)
- 10.0.2.64/25 (Public Subnet - C Zone)
- 10.0.3.0/25 (APP Private Subnet - A Zone)
- 10.0.3.64/25 (APP Private Subnet - C Zone)
- 10.0.3.128/25 (DB Private Subnet - A Zone)
- 10.0.3.192/25 (DB Private Subnet - C Zone)
- DEV
- SG
- SG의 경우 체이닝으로 구성하며 CloudFront → Web ALB → ECS EC2(API) → RDS(DB) 로 구성한다.
- CloudFront 나 개발자 및 관리자 IP 리스트를 Prefix IP list를 활용해 허용해주는 방법도 있을 것이다.
- Route Table
- Public Subnet의 경우 IGW와 연결되는 라우트를 추가한다.
- APP Subnet의 경우 S3와 연결되는 VPC Endpoint를 추가하고 NAT 게이트웨이의 라우트를 추가한다.
- DB Subnet의 경우 동일하게 APP Subnet의 Route Table에 연결한다.
- IGW
- DEV, PROD 가각 1EA 프로비저닝 한다.
- NAT Gateway
- DEV, PROD 모두 각 A Zone에 위치한다.
- Route53
- Frontend 도메인 제공을 위해서 사용하고, A 레코드로 CloudFront의 배포 ID를 Alias로 넣는다.
- Hosted Zone의 경우 "familiar.link" 로 설정한다.
- me $25.00 $0.00 $115.00 $25.00 Renewed with transfer
in $15.00 $0.00 $26.00 $15.00 Renewed with transfer
fr $12.00 $12.00 $12.00 $12.00 Renewed with transfer
be $9.00 $9.00 $19.00 $9.00 Renewed with transfer
link $5.00 $0.00 $53.00 $10.00 Renewed with Transfer
click $3.00 $0.00 $53.00 $10.00 Renewed with Transfer - 여러 후보가 있었는데 link가 보기 좋고 제일 비용이 저렴했음
- ACM
- HTTPS 통신을 위해 인증서 발급 및 관리 용도로 사용하고 "familiar.link" 도메인에 대해 인증서를 발급함
- SSM Parameter Store
- 서버 배포 시 필요한 환경 변수나 Access Key 및 Secret 변수를 불러오기 위해 사용한다.
- Secrets Manager
- Access Key 및 민감 데이터를 관리하는 Secret을 생성하고 관리하기 위해 사용한다.
- ECS
- EC2 Cluster를 프로비저닝하고 작업 정의를 생성해 API를 구동할 수 있게 한다.
- ECR
- API를 구동하기 위해 Docker Image를 관리한다.
- RDS
- DEV 환경의 경우 한 개의 인스턴스를 사용하고, PROD의 경우 Read Replica를 한 개 두어 이중화 한다.
- Type은 DEV의 경우 Free tier로 이용할 수 있는 db.t3.micro 를 사용하고, PROD의 경우 동일하게 db.t3.micro 를 사용하고 테스트 진행 후 가용할 수 있는 타입으로 변경 또는 유지.
- IAM
- 개발자, 인프라 운영자 그룹을 생성하고 개인 유저를 생성하며 MFA 강제 정책을 부여함.
- SaaS를 사용해야 할 경우 Application 유저를 생성하고 최소 권한 원칙에 따라 권한을 부여한다.
- CloudFront
- S3를 Origin으로 두어 Static Contents를 제공해주며,
- ALB를 Origin으로 두고 path를 /api로 두어 Dynamic Contents를 Serving 해주는 방식으로 정/동적 콘텐츠를 나누어 콘텐츠를 제공해준다.
- S3
- VPC Flow Logs 등의 로그를 저장하거나, Athena로 로그를 쿼리한 쿼리 결과를 저장하는 용도로 사용
- 웹이나 애플리케이션에서 사용하는 정적 데이터를 저장하는 데 사용
- Athena
- S3에 있는 각종 로그를 쿼리하는 용도로 사용한다.
- 쿼리 샘플을 작성할 수 있도록 함
- CloudTrail
- S3에 로그를 저장한다.
- Github Actions
- Front-End, Back-End
- DEV/PROD 배포
- DEV/PROD 롤백
- Terraform
- DEV/PROD 배포
- DEV/PROD 롤백
- Github Actions는 Code Commit 대비 개발자가 더 친숙함
- CI/CD 전 과정을 Workflows에 통합해 CD 소스를 따로 분리하는 것을 피해 관리 포인트를 줄임 (CodeDeploy 사용할 수도 있으나 하지 않은 이유)
- Marketplace를 사용해 빠른 CI/CD 개발 후 다른 작업에 집중
- Jenkins의 경우 추가적으로 서버를 프로비저닝해야 하는데, 비용 절감을 위해 Github Actions의 무료 플랜을 사용함. 무료 플랜의 경우 꽤나 고스펙의 Runner가 제공됨. 링크에서 확인 가능
- Front-End, Back-End
- Terraform
- 공통 Module을 분리해 DEV/PROD를 배포할 수 있도록 함
- PROD의 경우 Approval을 무조건 거치도록 함
- 모니터링
- Prometheus, Grafana로 생각 중이긴 하나 Prometheus는 어려울 수도 있음
규정
- 리소스 명명 규칙
- EC2 및 VPC 등 기본적으로 "리전-프로젝트-환경-서비스-숫자" 의 형식으로 구성.
예시로는 usea1-familiar-dev-vpc-01 - S3도 동일함
예시로는 usea1-familiar-dev-vpcflowlog-01 - 기본적인 리소스 명명 규칙은 소문자 케밥의 형태
- EC2 및 VPC 등 기본적으로 "리전-프로젝트-환경-서비스-숫자" 의 형식으로 구성.
- 태깅 정책
- Environment, Application 태그를 필수 태그로 지정
- 그 외 태그는 서비스에 따라 다름
- https://peritossolutions.com/aws/aws-tagging-rules/ 참조
- 리소스 축약어
- https://geekflare.com/aws-related-acronyms/ 참조
- 리소스 축약어는 별도 기재
- IAM User 비밀번호 정책
- 백업 및 복구
- RDS의 경우 자동 백업 사용
- EC2의 경우 ECR로 태깅을 통해 백업. Golden Image의 경우 태깅에 Golden으로 표기
- 알람 정책
- (작성 예정)
리소스 축약어
|
Amazon Web Services
|
AWS
|
|
Relational Database Service
|
RDS
|
|
Amazon Machine Image
|
AMI
|
|
Elastic Load Balancer
|
ELB
|
|
Application Load Balancer
|
ALB
|
|
Auto Scaling Group
|
ASG
|
|
Elastic Container Service
|
ECS
|
|
Elastic Container Registry
|
ECR
|
|
CloudFront
|
CF
|
|
Elastic Block Store
|
EBS
|
|
Elastic Network Interface
|
ENI
|
|
Elastic IP
|
EIP
|
|
Virtual Private Cloud
|
VPC
|
|
Identity & Access Management
|
IAM
|
반응형
'기타 > 토이프로젝트' 카테고리의 다른 글
| [Familiar] Terraform output for 반복문 사용하기 (0) | 2024.08.20 |
|---|---|
| [Familiar] Terraform 구조 잡기 & 문제 해결 (0) | 2024.08.08 |
| [Familiar] Terraform plan & apply with GitHub Actions (0) | 2024.08.06 |
| [Familiar] 테라폼 사용을 위한 Github Actions OIDC 설정 (0) | 2024.08.02 |
