1. 스프린트 1 계획 피드백
더 해야함
2. 궁금한 것 질문
DB Subnet을 여러 개를 둬서 RDS를 가용 영역마다 두어야 하는가? 비용 문제 우려됨.
AWS DB 서비스들은 서브넷 개념이 있음
Subnet 그룹 개념이 필요한 것은 인스턴스나 클러스터를 생성 시 어떤 서브넷에 배치할 것인지 설정해야함
DB를 한 대 만들 때는 문제가 없지만 읽기복제본, 클러스터링 시 서브넷 그룹을 활용해야함
보통은 DB Subnet 그룹을 만들어 놓음
RDS, ElastiCache, DynamoDB 등을 같은 서브넷에서 관리
우리 수준에 Multi AZ를 할 필요는 없음
가용 영역 홀수(쿼럼)로 구성하려 했는데, 쿼럼…
완전 잘못 이해하고 있음
AZ가 3, 5, 7개 일 필요는 없음
구축되어있는 시스템의 경우 해당 시스템만의 클러스터링 방법이 있음
추후 쿼럼을 구축하지 않을 시 대응이 어려울 수 있다는 의미였음
쿼럼 3대 → 2대일 경우 투표 권한
죽은 인스턴스는 기권
리더일렉션의 경우에는 1:1이 되는 경우가 발생하지 않음
Raft 알고리즘 참고
dev 서버의 위치
고가용성에 대한 이야기를 하면서 기준이 중요하다고 했음
스레드 여러개, AZ 여러개 등… 실패 지점에 따라 달라짐
가장 정석적인거 - account 레벨에서 분리
account를 스위칭해야하는 불편함이 있음
VPC 분리
작업을 2배로 해야함
NAT 비용 2배
개발이랑 운영을 확실히 나누고 싶다 - VPC 분리
혹은 계정 분리
개발 환경이랑 운영 환경을 분리하기만 하면 됨
개발 서버와 운영 서버 2대로 분리
더 싼 방법 - 하나의 서버에서 다른 포트를 사용
우리 서버의 네이밍은 어떤가?
모든 서브넷에 prefix로 vpc명을 넣음
vpc는 리전명이 들어가있기 때문에
vpc, region 별로 sorting이 가능함
bastion & vpn
bastion은 proxy 역할로 쓰는 서버
vpn이 없으면 private subnet에 접속하는 방법이 없기 때문에 그럴 때 쓰기 위한 서버
후에 편하게 쓰기 위해 OpenVPN을 알려준 것
둘 중에 하나만 써야 하는가?
본인 자유
NGW에 Elastic IP를 붙여 놓은 것이 Private Subnet에서 외부로 요청 보낼 때 NGW와 Internet Gateway로 요청이 두 번 보내지는 것이 맞을까?
apt-get과 같은 명령어 시 제일 처음 보내는것이 nat고 nat에서 igw를 거쳐서 나가는 것이 맞을까?
맞음
다만 요청은 1번
우리가 설정하는 라우팅 테이블에 따라 linux의 routing table이 달라짐
iptable의 액션 중 하나로 nat가 있음
rds 시 ec2 관련 설정 시 다른 ec2와 연결이 안되는 경우가 발생 - 보안 그룹(인바운드 1, 아웃바운드 1)이 생겼던 것 같음
라우팅 테이블은 경로를 만들어줌 → 경로가 뚫리면 게이트역할을 해주는 NACL(해당 서브넷에 접근 가능, Network Interface까지 감)과 Security Group(어느 인스턴스까지 갈지?)
보안그룹은 Stateful함
요청이 trigger되면 나가는 것을 허용해줌 and 나가는 것이 허용되면 들어오는 것을 허용해줌
보안그룹이 보안그룹을 참조할 수 있음
10.0.0.0/8 등 CIDR을 통해 흐름을 제어할 수도 있지만,
Source Security Group을 통해 원천 Security Group을 정의하고 …, 어떤 포트를 허용할 지 정할 수 있음
Source Security Group이 가지고 있는 것을 허용하겠다는 의미
Source Security Group는 여러 인스턴스에서 재활용이 가능함
보안 그룹을 통해 CIDR보다 명시적인 제어가 가능함
보안은 layerd architecture
보안은 쌓아두는거지 완벽한 보안은 없고, 겹겹히 쌓아둘 수록 공격이 힘들어지는 것
가장 간편한 것은 내부망을 다 열어놓는 것
인터넷에 들어오는 공격은 다 막지만 인터넷이 뚫렸을 때, 어디든 다 접근이 가능해짐
이를 위해 보안 그룹을 세부적으로 설정하는 것
자동 생성 시 source security group만 설정되어 있어, inbound rule에 vpc cidr을 설정하면 다 되긴 할 것
source security group
cidr을 통해 설정하는 것이 아닌 security group을 선택하여 inbound/outbound 룰을 설정하는 것
prefix lists (managed prefix lists)
cidr 리스트
ex) 회사에 Office IP 대역을 선택하고 싶은데 가지각색일 때 → 보안 그룹이나 IP 정책을 쓸 때 바뀔 경우 다 바꿔야 함
prefix list를 설정하여 이를 해결
서브 도메인 vs 패스
서브도메인!
패스로 만드는 것도 가능하지만 일반적으로 서브 도메인으로 나눔
같은 API 서버면 경로별로 쪼개겠지만 성격이 다른 서버를 패스로 나누는 것은 조직 내에서 혼란이 야기될 수 있음
서로 다른 두 서버를 패스로 하면 로드밸런서 컴포넌트가 두 컴포넌트 중 하나만 트래픽이 많을 경우 로드밸런서가 별도 스케일링이 되지 않음
NLB vs ALB
api를 서브도메인으로 나누면 ip를 다르게 가져갈 수 있으니 로드밸런서에서 nlb, alb를 선택할 수 있을 거라고 고민했음 → 서브도메인, 패스 결정 여부를…
DNS 타입
A: IPv4 → DNS 쿼리로 도메인 질의 → IP 전달
CNAME: 도메인 이름을 다른 도메인 이름으로 전달
SRV: 다른 DNS로 트래픽 전달
AAAA: IPv6 연결을 위한 레코드
TXT: IP가 아닌 정보를 resolve 하기 위한 레코드
…
모든 도메인 레코드가 IP를 주는 것은 아님
NLB
앞의 host ip와 port를 통해 api 연결
port 단위로 나누는 게 아니면 거를 수 없음
ALB
뒤에 있는 path를 통해 api 연결
alb가 더 비쌈(거의 비슷)
고정 IP를 주지 않음
내부적으로 고객에게 IP를 제공하지 않고 도메인을 줌
ec2 - public dns, private dns와 같은 alb를 가르키는 dns를 줌
이를 통해 매핑 가능
CNAME (도메인을 포워딩하는 레코드)
A 레코드 Alias (AWS 에서 제공하는 기능으로, 로드밸런서를 선택하여 변경되는 도메인을 가지고 있을 수 있음)
AWS의 A 레코드 Alias를 통해 AWS 내부에서 생성되는 RDS, ALB 등의 도메인 처리가 가능함
ALB의 도메인은 퍼블릭 도메인으로 질의는 가능하나 접근을 하기 위해서는 보안 그룹 설정을 해줘야 함