새로운 프로젝트에 대한 개발 인프라를 구축해야 하는 일이 생겼습니다. 🤔🤔
인프라 작업 계획서를 작성하고 컨펌받으면서 모르는 부분이 너무 많아서, 이번 기회에 해당 내용들을 차근차근 정리하려고 해요. 😊
사실 레코드 만드는 건 어렵지 않아요. 서브도메인 이름 알맞게 넣고, 기본 유형에 인스턴스 ip, 그리고 기존에 존재하는 다른 레코드의 ttl를 따라 하거나, 적정한 값에서 조절하면 되고 라우팅 정책도 다른 레코드와 유사하게 아니면 기본적인 값을 집어넣으면 돼요. 😎
짜잔 10초 만에 레코드를 생성할 수 있답니다. 😆😆
하지만 저는 각 항목에 대한 이해가 부족하기 때문에 이번 포스팅에서는 각각 어떤 의미를 갖고, 어떤 역할을 하는지 포스팅하려고 해요.
AWS Route 53에서 레코드를 생성할 때, 다음 첨부와 같이 항목들을 작성해야 합니다.
1. 레코드 이름 (Record Name)
DNS 레코드가 적용될 도메인 이름을 정합니다. 지금 현재 제 블로그의 URL를 보면 https://comdolidol-i.tistory.com/ 으로 되어있습니다. 여기서 'tistory.com'은 기본 도메인으로, 이 도메인을 가진 모든 하위 도메인에 대한 DNS 레코드를 설정할 수 있습니다. 티스토리는 블로그 이름을 레코드 이름으로 설정했나 봐요 🤔🤔
2. 레코드 유형 (Record Type)/ 값 설정
레코드 이름은 DNS 레코드가 적용될 도메인 또는 하위 도메인을 지정합니다. 이 레코드 이름에 따라 어떤 도메인 이름에 대한 정보를 정할지 결정하는 거죠. 레코드 유형에 따른 예를 제 블로그 주소에 대해서 설명해 볼게요. 레코드 유형은 위에 첨부된 사진처럼 12개의 유형이 존재합니다. 그중에서 5개의 레코드 유형에 대해 설명하려고 합니다.
1) A 레코드
Name: comdolidol-i.tistory.com
Type: A
Value: 192.0.2.1
'comdolidol-i.tistory.com'의 A 레코드가 '192.0.2.1'일 때, 사용자가 해당 URL에 접근하면 IP 주소 '192.0.2.1'으로 연결됩니다. 즉 웹사이트나 서버의 IP주소를 지정할 때 사용하는 레코드입니다. 일반적인 웹 사이트에 많이 사용하는 유형입니다. 😎
2) AAAA 레코드
Name: comdolidol-i.tistory.com
Type: AAAA
Value: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
'comdolidol-i.tistory.com'의 AAAA레코드로 설정하면, 사용자가 해당 URL에 접근하면 IPv6 주소 '2001:0 db8:85 a3:0000:0000:8 a2 e:0370:7334'으로 연결됩니다. IPv6 주소를 사용하는 시스템에서 도메인 이름을 통해 접근할 때 사용됩니다.
3) CNAME (Canonical Name) 레코드
Name: www.example.com
Type: CNAME
Value: example.com
'www.example.com'의 CNAME 레코드가 'example.com'일 때, 사용자가 'www.example.com'에 접근하면 실제로 'example.com'으로 리다이렉트 됩니다. 이 유형은 여러 도메인 이름이 동일한 서버를 가리킬 때 사용됩니다. 즉, 도메인 이름을 다른 도메인 이름으로 매핑이 필요할 때 사용됩니다.
4) MX (Mail Exchange) 레코드
Name: example.com
Type: MX
Value: mail.example.com
Priority: 10
이메일을 처리할 서버를 지정하는데, 이메일 시스템에서 수신 메일을 처리할 서버를 알려줍니다. 'example.com'의 MX 레코드가 'mail.example.com'일 때, 'example.com' 도메인으로 수신되는 이메일은 'mail.example.com' 서버에서 처리됩니다. 해당 레코드는 이메일 수신을 설정할 때 사용되며, 여러 메일 서버를 설정하고 우선순위를 지정할 수 있습니다.
5) TXT (Text) 레코드
Name: example.com
Type: TXT
Value: "v=spf1 include:_spf.example.com ~all"
도메인에 대한 텍스트 정보를 저장할 수 있으며, 주로 도메인 검증이나 정책을 설정하는 데 사용됩니다. 도메인 소유권 확인 또는 이메일 인증, 보안 설정 등 다양한 목적으로 처리됩니다.
3. TTL (Time to Live)
TTL은 DNS 레코드의 캐시 기간을 정의하는 값으로, 해당 레코드가 DNS 서버나 클라이언트의 캐시에 얼마나 오랫동안 저장될 수 있는지를 결정해요. TTL 값은 초 단위로 설정되며, 레코드의 유효 기간이 끝나면 DNS 서버나 클라이언트는 새로운 정보를 조회하기 우해 DNS 쿼리를 다시 보내야 하죠.
TTL 값은 보통 1시간에서 24시간 사이로 설정돼요. 하지만 TTL 값을 선택하는 것은 각자 사용하는 애플리케이션의 조건과 요구 상항에 따라 많이 달라집니다.
서버가 아직 안정화되지 않거나, DNS 레코드가 자주 변경되는 경우, TTL 값은 변경 사항이 빠르게 반영되도로 TTL 값을 낮게 설정합니다. 하지만 낮은 값은 빈번하게 DNS 쿼리로 인해 DNS 서버와 네트워크에 추가적인 부하가 발생하고, 전송 지연이 발생할 수 있습니다. 서버가 로드밸런스가 설정이 되어 있으면, 서버의 IP 주소가 바뀌기 때문에 TTL 300초로 설정하여 변경 사항을 신속하게 반영하여 사용하곤 합니다.
반대로 높은 TTL 값은 DNS 쿼리가 상대적으로 적기 때문에 DNS 서버 간에 네트워크 트래픽이 줄어들고, 캐시를 효율적으로 사용할 수 있습니다. 하지만 레코드 변경 사항이 느리게 반영되어, 사용자가 오래된 정보를 받을 수 있습니다. 그러므로 안정화된 사용 웹사이트 경우에 비교적 높은 TTL(86400 == 24 시간)으로 설정하여 캐시를 오랫동안 유지하는 것 추천합니다.
4. 라우팅 정책
1) 단순 라우팅 (Simple Routing)
단순 라우팅은 가장 기본적인 라우팅 방식입니다. 이 방식은 도메인 이름에 대한 단일 IP 주소를 반환합니다. 아주 간단하게, “누구나 같은 길을 따라가도록 하는 것”입니다. 즉 모든 트래픽이 하나의 서버로 가게 설정하는 거죠. 소규모 웹사이트나 개인블로그처럼 간단하고 변경이 적은 사이트에 적용하기 좋습니다.
Name: blog.example.com
Type: A
Value: 192.0.2.1
2) 지연 시간 라우팅 (Latency-based Routing)
지연 시간 라우팅은 사용자와 서버 간의 지연 시간(latency)을 고려하여 가장 빠른 응답 시간을 제공하는 서버로 트래픽을 라우팅 합니다. 마치 "누가 가장 빨리 갈 수 있는지 경주를 시켜서 승자를 따라가는 것"과 같습니다. 즉 여러 서버에서 각 지역으로 가장 빠른 응답을 보낼 수 있는 서버로 라우팅 되는 거죠. 저는 사용해 본 적은 없지만, 여러 지역 또는 국가로 분산된 사용자에게 빠른 응답을 제공할 때 사용된다고 합니다. 레코드 라우팅 정책으로는 사용하지는 않았지만, 브라우저 자원을 저장하려고 CDN을 도입한 적이 있는데, 이 CDN이 지연 시간 라우팅 방식과 동일하다고 볼 수 있습니다.
Name: service.example.com
Type: A
Values:
- 192.0.2.1 서버1
- 192.0.2.2 서버2
- 192.0.2.3 서버3
3) 장애 조치 라우팅 (Failover Routing)
장애 조치 라우팅은 주 서버가 장애가 발생했을 때 백업 서버로 트래픽을 전환하는 방식입니다. 제 위에 사수 개발자님들이 다 아프시면 이제 제가 개발을 맡아야 하는 상황인 거죠. 생각만 해도 끔찍하네요. 😓 보통 중단 없이 서비스를 제공해야 하는 중요한 비즈니스 애플리케이션에서 사용합니다. 저희 회사도 장애 조치 설정으로 되어있습니다. 😎 그런 일이 없도록 빌어야겠죠. 하하하
Name: api.example.com
Type: A
Primary Value: 192.0.2.1 (주 서버)
Secondary Value: 192.0.2.2 (백업 서버)
'DevOps > AWS' 카테고리의 다른 글
[AWS] AWS 보안 그룹 설정과 원본(Source) 개념- 컴도리돌이 (0) | 2024.11.06 |
---|---|
[AWS] VPC, Subnet, 보안 그룹에 대해서 - 컴도리돌이 (0) | 2024.04.20 |
[AWS] 과금 청구, 넌 얼마까지 청구 되어봤니?(feat. 1941만원, 해킹, 과금 면제) - 컴도리돌이 (52) | 2022.06.13 |