Offcanvas

How To / 검색|인터넷 / 애플리케이션

'결코 사소하지 않다' DNS 개선 단계 8가지

2022.01.06 Lee Atchison   |  InfoWorld
DNS는 인터넷 및 현대 디지털 비즈니스의 모든 측면에서 운영을 위한 필수 요소다. DNS는 높은 가용성과 예비성, 안정성이 필요한 서비스로 기업의 애플리케이션과 비즈니스 운영을 위해 절대적으로 중요하다. DNS에 장애가 발생하면 비즈니스가 중단되고 조직의 미래가 위태로워진다.
 
DNS의 문제는 구성 파일의 작은 실수 하나가 전체 DNS에 파급 효과를 일으켜 회사 운영의 모든 측면에 타격을 입힐 수 있다는 점이다. DNS 장애가 발생하면 고객은 제품을 사용할 수 없고 회사는 돈을 벌 수 없다. 견고한 DNS 구성 관리 방안을 마련하지 않으면 사소하지만 큰 비용을 유발하는 실수에 취약한 상태가 된다.
 
DNS 변경은 워낙 흔히 일어나는 일이고 방법도 간단해서 위험한 비즈니스 작업이라는 인식이 거의 없다. 규모가 작은 조직에서는 개발 팀이 자체 DNS 서버를 관리하는 경우도 있고 그 외의 다른 방법으로 즉석에서 DNS를 변경하기도 한다. 조직의 규모가 커지고 복잡해지면 DNS 서버의 수와 DNS를 변경할 수 있는 사람들의 수도 대체로 함께 증가한다.

많은 사람들이 변경 작업을 하게 되면 수시로 문제가 발생한다 해도 놀랍지 않다. 사실 아무 문제가 없다면 그게 더 놀라운 일일 것이다.
 
ⓒ Getty Images Bank

DNS 중단을 유발하는 원인은 인적 실수, 소프트웨어 문제, 하드웨어 장애를 비롯해 여러가지다. 그러나 가장 흔한 DNS 중단 원인은 올바르지 않은 구성 파일이 DNS 서버에 배포되는 것이다.
 
적절한 DNS 위생 절차가 없는 작은 기업에서 견고한 DNS 관리 프로세스를 확보하기 위해 취할 수 있는 조치는 무엇일까? 모든 기업이 전체적인 DNS 품질을 개선해 애플리케이션을 원활하게 운영하기 위해 실천해야 하는 8가지 단계를 소개한다.
 

1단계 : 리비전 제어를 사용해 DNS 구성 관리

DNS 인프라의 품질을 개선하기 위해 할 수 있는 가장 단순하고 가장 기본적인 조치다. 기본적으로 DNS 구성은 일반 텍스트 파일이다.
 
많은 DNS 제공업체가 더욱 쉬운 변경 작업을 위해 이러한 구성 파일에 대한 프론트엔드 제어판을 제공하면서도 변경이 미치는 영향을 명확히 알려주지 않는다. 따라서 이런 제어판을 사용하지 말고, 대신 표준 텍스트 파일 형식을 사용해 구성 파일을 관리해야 한다.
 
일반 파일 형식을 택하면 애플리케이션 소스 코드를 관리하는 데 사용하는 리비전 제어 프로그램을 똑같이 사용해서 구성 파일도 손쉽게 관리할 수 있다. 대부분의 기업에서 이 프로그램은 깃(Git)의 변형 중 하나일 것이다.
 
현재 조직에 당연히 소스 코드 관리 프로세스가 있을 것이므로 이와 동일한 프로세스 또는 비슷한 프로세스를 DNS 구성 파일을 관리하는 데도 사용하면 된다.
 
간단한 변화지만 이를 통해 구성 검토, 승인 워크플로우 같은 다른 많은 프로세스도 자연스럽게 개선되며, 특정 변경이 애플리케이션에 영향을 미친 경우 이 변경을 추적하는 역량도 개선된다. DNS 서비스를 오류 없이 매끄럽게 운영하기 위한 필수적인 기본적 조치다.
 

2단계 : 필요한 모든 DNS 변경 검토

리비전 제어 프로그램을 사용해서 변경을 관리하게 되면 모든 변경이 검토와 승인을 거치도록 해야 한다. 마찬가지로 애플리케이션 소스 코드를 다룰 때와 동일하게 분기, 풀 요청, 병합을 사용해 가능하다.
 
모든 변경의 승인을 위한 프로세스를 정립하라. 모든 변경은 프로덕션 구성에 적용되기 전에 한 명 이상의 검토를 거쳐야 한다. 이 검토 프로세스에는 구문 오류, 올바르지 않은 DNS 설정 및 기타 잠재적인 문제에 대한 확인이 포함되어야 한다. DNS 구성 문제는 명확히 드러나지 않을 수 있으므로 풍부한 관련 지식을 갖춘 검토자의 철저하고 체계적인 검토가 필요하다.

 

3단계 : 변경 목적은 모두 문서화

모든 변경을 문서화해야 한다. 위의 단계를 따른다면 코드 체크인 주석과 풀 요청 프로세스를 사용하면 된다.
 
DNS 변경을 문서화하면 나중에 문제가 나타나거나 호환되지 않는 변경이 발생할 때 도움이 된다. 이전 변경이 이뤄진 이유를 알면 문제를 해결하는 데 도움이 되고, 특정 변경이 적절하거나 적절하지 않은 이유도 더 정확히 파악할 수 있다.
 

4단계 : 구성 배포 프로세스 자동화

구성 파일 관리 프로세스를 마련했다면 구성 파일 업데이트를 프로덕션 DNS에 배포하는 과정을 자동화하는 프로세스를 구축해야 한다. 이 프로세스를 자동화하면 올바르지 않은 변경이 프로덕션으로 푸시되거나 단순한 사람의 실수로 인해 DNS에 장애가 발생하거나 좋지 않은 결과가 일어날 가능성을 줄일 수 있다.
 
배포 프로세스 중에 한 구성 파일의 변경 내용을 복사해서 다른 구성 파일에 붙여 넣는 수작업을 한다면 실수를 저지르고 DNS 버그가 유입될 가능성이 훨씬 더 높아진다. 변경을 자동으로 배포하면 일관적이고 안정적으로 변경이 적용되도록 보장할 수 있다.

자동화된 배포 시스템에는 자동화된 롤백 메커니즘이 포함되어야 한다. 리비전 제어 프로세스를 확장한 형태일 수도 있고, 별도의 배포 롤백 프로세스일 수도 있다. 변경을 신속하고 효과적으로 되돌릴 수 있는지 여부에 따라 그 실수의 여파가 소소한 불편함에 그칠 수도, 막대한 중단 사태로 이어질 수도 있다.
 

5단계 : 더 정교한 변경 관리 시스템으로 발전

DNS의 복잡성이 높아지면 이미 구축한 단순한 버전 제어 시스템 위에 완전한 변경 관리 시스템을 배치하는 것이 바람직할 수 있다. 완전한 변경 관리에는 변경 요청 양식, 승인 요청, 여러 팀의 서명과 같은 절차가 포함될 수 있다.
 
부담스러운 변화로 보일 수 있지만 DNS 구성은 결코 대충 넘길 수 있는 분야가 아니다. 단순한 DNS 변화 하나가 조직 내의 많은 팀에 영향을 미칠 수 있으므로 변경을 하기 전에, 또는 더 나아가 변경 제안이 수락되기 전에 각 팀의 의견을 구해야 한다. 그렇게 하면 나중에 많은 골칫거리를 예방할 수 있다.
 
변경 관리 시스템의 규모와 복잡성은 조직 및 다른 소프트웨어 관리 프로세스의 크기와 복잡성에 따라 좌우된다.
 

6단계 : 독립적인 DNS 제공업체 사용

고품질의 DNS를 위해서는 구성 관리만으로는 부족하다. 고품질의 운영 환경도 필요하다.
 
기존 서비스 제공업체 중 상당수가 DNS 서비스를 제공하므로 손쉽게 활용할 수 있다. 특히 주요 클라우드 제공업체는 고품질의 DNS 서비스를 제공한다.
 
그러나 클라우드 서비스를 포함한 다른 서비스를 함께 제공하는 업체의 DNS 서비스를 사용할 때는 주의가 필요하다.
 
서비스 중단이 발생하면 중단 중에 정상적으로 운영해야 하는 가장 중요한 툴은 DNS다. 다른 대부분의 중단 문제를 진단하고 복구하는 데 DNS가 필요하다. DNS까지 함께 다운되면 중단 기간이 훨씬 더 길어진다.
 
그 반대 역시 마찬가지다. DNS 문제가 발생한 상황에서 최악의 경우는 애플리케이션 생태계 내의 다른 서비스에 의한 중단까지 겹치는 것이다.
 
다른 서비스 없이 오로지 DNS 서비스만 제공하는 고품질 DNS 제공업체를 사용함으로써 이와 같은 문제를 피할 수 있다. 이렇게 하면 DNS(그리고 DNS와 관련한 모든 문제)를 애플리케이션의 다른 서비스와 격리해서 DNS와 관련된 장시간 중단 가능성을 낮출 수 있다.
 
선택한 업체가 현재 우리 회사와 계약한 서비스 제공업체(클라우드 업체 등)에 의존하지 않는지도 확인해야 한다! AWS에 중단이 발생하더라도 독립적인 DNS 제공업체는 정상 운영되어야 하는데, 그 DNS 제공업체도 AWS에 의존한다면 불가능한 일이다.

 
자체 DNS를 운영하는 조직도 있다. 자체 운영을 선택할 경우 애플리케이션의 나머지에서 독립적인 리소스를 사용해 운영해야 한다. 이 말은 애플리케이션의 나머지 부분과 다른 데이터 센터, 다른 가용성 영역, 나아가 다른 클라우드 지역(region)에서 DNS를 운영해야 한다는 것을 의미한다.
 

7단계 : 내부 DNS와 외부 DNS 분리

6단계에서 한 걸음 더 나아가 보자. 회사 내에 필요한 DNS가 있고, 고객이 의존하는 외부 DNS가 있다. 내부 DNS는 이메일, 통신 툴과 같은 내부 문서, 내부 시스템과 기타 내부 프로세스에 접근할 수 있게 해준다. 외부 DNS는 고객이 회사의 애플리케이션, 제품, 서비스에 접근할 수 있게 해준다.
 
이 두 가지 DNS 수요가 각기 다른 제공업체에 의해 처리되도록 해야 한다. 외부 DNS가 다운될 때 내부 DNS까지 다운되면 문제를 고치기가 훨씬 더 어려워진다. 2021년 10월 페이스북이 다운되었을 때 메타가 애플리케이션 수정에 그렇게 오랜 시간이 걸린 이유가 바로 이것이다.
 
반대로도 마찬가지다. 내부 DNS가 다운될 때 이 문제가 외부 고객에까지 확산되지 않도록 해야 한다.
 
이러한 종류의 문제를 방지하기 위해서는 다른 DNS 구성 및 구성 프로세스와 함께 서로 다른 제공업체를 사용하는 것이 중요하다.
 

8단계. 제공업체 이중화로 예비 DNS 확보

한 단계 더 나아가서, 제공업체를 두 곳으로 정해 프로덕션 DNS를 구축하는 방법이 있다. 하나를 주 제공업체로 사용하고, 다른 하나를 백업 제공업체로 사용하는 것이다. 이렇게 하면 주 DNS 제공업체가 다운되더라도 백업 제공업체로 신속하게 프로덕션 DNS를 전환할 수 있다.
 
백업 제공업체에는 DNS 구성의 완전하고 정상 작동하며 테스트를 거친 복사본이 항상 준비된 상태여야 한다. 그래야 필요할 때 즉시 가동할 수 있기 때문이다. 위에 권장된 자동 배포 프로세스를 구현했다면 이 프로세스를 더 쉽게 진행할 수 있다. 자동화된 프로세스를 두면 주 제공업체와 백업 제공업체 간에 변경 사항이 동기화 상태를 유지한다.
 
DNS는 처음부터 높은 가용성과 신뢰성을 목표로 설계해야 한다. 또한 DNS 인프라를 설계할 때는 보안에 대해서도 생각해야 한다. 예비 시스템을 두고, DNS 접근을 엄격하게 제어해야 한다.
 
마지막으로, DNS 모니터링은 시스템의 원활한 동작을 유지하기 위해 중요하다. 문제가 발생할 때 최대한 신속하게 조치를 취할 수 있도록 문제를 알려주는 툴이 필요하다.
 
DNS 중단은 흔히 발생하는 일이지만 그 때마다 회사 전체가 멈출 필요는 없다. 적절한 프로세스와 툴을 사용하면 중단의 영향을 최소화하고 원활한 비즈니스 운영을 지속할 수 있다. editor@itworld.co.kr 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
DNS
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.