검수요청.png검수요청.png

"미러사이트"의 두 판 사이의 차이

해시넷
이동: 둘러보기, 검색
12번째 줄: 12번째 줄:
  
 
미러사이트를 설정하는 일반적인 이유 중 하나는 서버에 과부하가 걸리는 갑작스러운 트래픽 유입에 대처하기 위한 것이다. 방문자에게 미러사이트 또는 여러 사이트를 제공함으로써 사이트 소유자는 사람들이 사이트를 볼 수 있도록 사이트를 계속 운영할 수 있다. 서버 문제나 트래픽 유입으로 인해 사이트가 다운될 때 유용하다. 미러사이트는 백업으로도 사용되므로 서버가 어떤 식 으로든 손상되거나 손상된 경우 전체 파일 세트가 다른 곳에서 호스팅 되도록 한다. 소프트웨어 다운로드는 종종 서버를 압도하지 않고 사용자 편의를 위해 미러사이트에서 호스팅 된다. 예를 들어 독일에 있는 다운로드 사이트는 일본 사용자를 위해 일본에 미러사이트를 제공하여 파일을 더 빨리 다운로드할 수 있다. 또한 여러 서버에 소프트웨어를 배포하면 하나 이상의 사이트가 다운되더라도 사용자가 항상 소프트웨어에 액세스할 수 있다. 고전적으로 미러사이트는 검열과 싸우기 위해 사용되었다. 예를 들어, 사이트가 종료된 경우를 대비하여 논란이 많은 사이트가 원격 위치에 미러링 될 수 있다. 또는 검열 소프트웨어에 의해 금지된 사이트는 사람들이 여전히 액세스할 수 있도록 미러를 호스팅 할 수 있다. 미러는 원본 사이트가 중단되거나 근본적으로 재설계 될 때 견딜 수 있는 일종의 살아있는 아카이브인 빈티지 콘텐츠의 저장소 역할을 할 수도 있다. 이전 화신에서 사이트를 보거나 날짜가 있지만 여전히 관심이 있는 정보에 액세스하려는 사용자에게 유용할 수 있다.<ref>〈[https://www.netinbag.com/ko/internet/what-is-a-mirror-site.html 미러 사이트 란 무엇입니까?]〉, 《네트인백》</ref>
 
미러사이트를 설정하는 일반적인 이유 중 하나는 서버에 과부하가 걸리는 갑작스러운 트래픽 유입에 대처하기 위한 것이다. 방문자에게 미러사이트 또는 여러 사이트를 제공함으로써 사이트 소유자는 사람들이 사이트를 볼 수 있도록 사이트를 계속 운영할 수 있다. 서버 문제나 트래픽 유입으로 인해 사이트가 다운될 때 유용하다. 미러사이트는 백업으로도 사용되므로 서버가 어떤 식 으로든 손상되거나 손상된 경우 전체 파일 세트가 다른 곳에서 호스팅 되도록 한다. 소프트웨어 다운로드는 종종 서버를 압도하지 않고 사용자 편의를 위해 미러사이트에서 호스팅 된다. 예를 들어 독일에 있는 다운로드 사이트는 일본 사용자를 위해 일본에 미러사이트를 제공하여 파일을 더 빨리 다운로드할 수 있다. 또한 여러 서버에 소프트웨어를 배포하면 하나 이상의 사이트가 다운되더라도 사용자가 항상 소프트웨어에 액세스할 수 있다. 고전적으로 미러사이트는 검열과 싸우기 위해 사용되었다. 예를 들어, 사이트가 종료된 경우를 대비하여 논란이 많은 사이트가 원격 위치에 미러링 될 수 있다. 또는 검열 소프트웨어에 의해 금지된 사이트는 사람들이 여전히 액세스할 수 있도록 미러를 호스팅 할 수 있다. 미러는 원본 사이트가 중단되거나 근본적으로 재설계 될 때 견딜 수 있는 일종의 살아있는 아카이브인 빈티지 콘텐츠의 저장소 역할을 할 수도 있다. 이전 화신에서 사이트를 보거나 날짜가 있지만 여전히 관심이 있는 정보에 액세스하려는 사용자에게 유용할 수 있다.<ref>〈[https://www.netinbag.com/ko/internet/what-is-a-mirror-site.html 미러 사이트 란 무엇입니까?]〉, 《네트인백》</ref>
 
==구성==
 
데이터베이스 미러링은 상황에 맞게 3가지 구성 방법이 있다.
 
 
#'''감시 서버를 포함한 동기화 미러링'''(Synchronous mirroring) : 데이터의 손실이 없고 자동으로 장애 조치를 지원한다. 주 서버에서 일어난 [[트랜잭션]]이 미러 서버에 기록이 정확하게 이루어져야만 주 서버에 커밋이 된다. 데이터의 손실이 없는 장점에 비해 성능에 영향을 줄 수 있다.
 
#'''감시 서버를 포함한 비동기화 미러링 방식'''(Asynchronous mirroring) : 동기화 미러링 방식과는 달리 주 서버에서 트랜잭션이 바로 커밋 된다. 이런 이유로 동기화 방식에 비해 성능이 좋다. 이 방식은 주 서버와 미러 서버 간의 거리가 멀리 떨어지거나 서버 간의 지연이 있는 경우 고려할 수 있는 방식이다.
 
#'''감시 서버를 포함하지 않은 동기 미러링''' : 이 구성은 데이터의 정확성을 우선으로 하며 서버의 서비스 중지 시간을 어느 정도 인정하며 잠재적인 성능 이슈를 견딜 수 있는 상황에서 유용하다. 이 구성은 자동 장애 조치 기능이 구현되지 않는다.<ref name="데이터베이스 미러링">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=13834&boardConfigUid=9&categoryUid=216&boardIdx=73&boardStep=1 데이터베이스 미러링]〉, 《디비가이드넷》</ref>
 
 
===미러 서버 구성하기===
 
주 서버가 미러 서버에 접속 가능해야 하며 트러스터 된 상태이어야 한다. 권장하는 것은 같은 도메인상에 속해있는 것이다. 한 서버에 여러 인스턴스를 이용하여 구성이 가능하다. 하지만 이렇게 하면 성능상의 문제가 있기에 권장하지 않는다.<ref name="데이터베이스 미러링"></ref>
 
 
===미러 데이터베이스 구성하기===
 
미러 데이터베이스는 자동이 아닌 수동으로 구성된다. 두 데이터베이스(주 서버, 미러 서버)는 같은 파일 구조를 가져야 한다. 또한 전체 복구 모델로 선택되어 있어야 한다. 미러 데이터베이스 생성 즉시 주 데이터베이스의 전체 백업본을 미러 서버에 With NORECOVERY 절을 이용하여 복원해야 한다.<ref name="데이터베이스 미러링"></ref>
 
 
===미러링 구성을 위한 끝점 구성하기===
 
*'''미러 서버에 파트너 끝점 구성하기'''
 
:주 서버와의 통신을 위해 주 서버와 사용할 파트너 끝점이 필요하다. 아래의 예제 코드를 이용하면 Mirror_EndP라는 파트너 끝점을 만든다. STATE 파라미터를 STARTED로 지정하게 되면 바로 활성화된다. TCP 포트 5022는 미러링에서 기본적으로 사용하는 포트 번호이다.
 
 
CREATE ENDPOINT Mirror_EndP
 
STATE=STARTED
 
AS TCP(LISTENER_PORT=5022)
 
FOR DATABASE_MIRRORING (ROLE=PARTNER)
 
 
*'''주 서버에 파트너 끝점 구성하기'''
 
:미러 서버에서 보여준 것처럼, 주 서버는 미러링 서비스를 제공하는 SQL 서버 인스턴스와 통신을 할 파트너 끝점이 필요하다.
 
 
CREATE ENDPOINT Mirror_EndP
 
STATE=STARTED
 
AS TCP (LISTENER_PORT=5022)
 
FOR DATABASE_MIRRORING (ROLE=WITNESS)
 
 
*'''목격자 서버에 목격자 끝점 구성하기'''
 
:시나리오에 미러링 끝점이 포함되어 있으면 목격자 서비스를 제공하는 SQL 서버 인스턴스 상에 끝점이 필요하다.
 
 
CREATE ENDPOINT Mirror_EndP
 
STATE=STARTED
 
AS TCP (LISTENER_PORT=5022)
 
FOR DATABASE_MIRRORING (ROLE=WITNESS)
 
<ref name="데이터베이스 미러링"></ref>
 
 
===미러 세션 설정하기===
 
위에서 미러 서버와 데이터베이스 준비되고 각 서버에 Endpoint가 생성이 되면 다음과 같이 미러 세션을 설정한다.
 
 
*'''미러 서버에서 파트너십 생성하기'''
 
:우선 미러 서버에서 ALTER DATBASE 명령어를 수행한다.
 
 
ALTER DATABASE AdventureWorks
 
SET PARTNER =‘ TCP://Seoul:5022’
 
 
*'''주 서버에서 파트너십 생성하기'''
 
ALTER DATABASE AdventureWorks
 
SET PARTNER =‘ TCP://Busan:5022’
 
<ref name="데이터베이스 미러링"></ref>
 
 
===감시 서버 구성하기===
 
자동 장애 조치를 구성하려면 목적 서버를 구성해야 한다. 목적 서버는 주 서버 및 미러 서버와는 다른 서버에 구성이 되어야 한다. 그렇지만 하나의 목적 서버는 여러 개의 미러 세션을 담당할 수 있다.
 
 
ALTER DATABASE AdventureWorks
 
SET WITNESS =‘ TCP://DAEGU:5022’
 
<ref name="데이터베이스 미러링"></ref>
 
 
===감시 서버 제거하기===
 
미러 서버가 제거되어도 미러링 세션은 유지된다. 다만, 자동 장애 조치는 불가능하다. 감시 서버를 제거하는 방법은 다음과 같다.
 
 
ALTER DATABASE AdventureWorks
 
SET WITNESS OFF
 
<ref name="데이터베이스 미러링"></ref>
 
 
==비교==
 
고가용성 기술로서 미러링, 장애 조치 클러스터링, 로그 전달, 트랜잭션 복제, 이 네 가지가 존재하고 일부 중복되기는 하지만 각 기술마다 상대적인 장점과 단점이 있다. 이러한 네 가지 기술의 기본 기능을 비교하고 데이터베이스 미러링이 더 나은 솔루션을 보완하거나 입증할 수 있는 영역을 자세히 살펴보겠다. 다음 표는 네 가지 기술의 여러 가지 가용성 기능을 보여준다.
 
 
:{|class=wikitable width=1100
 
|+<big></big>
 
!align=center|카테고리
 
!align=center|가용성 특징
 
!align=center|데이터베이스 미러링
 
!align=center|장애 조치 클리스터링
 
!align=center|로그 전달
 
!align=center|트랜잭션 복제 장애 조치
 
|-
 
|align=center|'''장애 조치 특성'''
 
|align=center|대기 유형
 
|align=center|Hot
 
|align=center|Hot
 
|align=center|Warm
 
|align=center|Hot
 
|-
 
|align=center|
 
|align=center|자동 역할 변경
 
|align=center|예
 
|align=center|예
 
|align=center|사용자 정의 코딩 필요
 
|align=center|사용자 정의 코딩 필요
 
|-
 
|align=center|
 
|align=center|장애 조치가 커밋 된 작업을 보존
 
|align=center|예
 
|align=center|예
 
|align=center|아니오
 
|align=center|아니오
 
|-
 
|align=center|
 
|align=center|장애 조치 유형
 
|align=center|자동 및 수동
 
|align=center|자동 및 수동
 
|align=center|변수
 
|align=center|변수
 
|-
 
|align=center|
 
|align=center|장애 조치 동안
 
|align=center|10초 미만
 
|align=center|30초 +
 
|align=center|
 
|align=center|
 
|-
 
|align=center|
 
|align=center|데이터베이스
 
|align=center|
 
|align=center|데이터베이스 복구
 
|align=center|
 
|align=center|
 
|-
 
|align=center|
 
|align=center|다운 시간
 
|align=center|
 
|align=center|
 
|align=center|
 
|align=center|
 
|-
 
|align=center|'''Physical 구성'''
 
|align=center|중복 저장 위치
 
|align=center|예
 
|align=center|아니오(공유 디스크)
 
|align=center|예
 
|align=center|예
 
|-
 
|align=center|
 
|align=center|하드웨어 요구 사항
 
|align=center|표준 서버
 
|align=center|클러스터 인증 서버 및 저장
 
|align=center|표준 서버
 
|align=center|표준 서버
 
|-
 
|align=center|
 
|align=center|실제 거리 제한
 
|align=center|없음
 
|align=center|100 마일
 
|align=center|없음
 
|align=center|없음
 
|-
 
|align=center|
 
|align=center|추가 서버 역할
 
|align=center|Witness
 
|align=center|없음
 
|align=center|모니터
 
|align=center|Distributor
 
|-
 
|align=center|'''관리'''
 
|align=center|복잡도
 
|align=center|낮음
 
|align=center|높음
 
|align=center|낮음
 
|align=center|중간
 
|-
 
|align=center|
 
|align=center|대기 서버 액세스 가능
 
|align=center|데이터베이스 스냅샷을 통해 가능한 성능 영향
 
|align=center|아니오
 
|align=center|R/O, 복원과 호환되지 않음
 
|align=center|읽기 전용 작업의 경우 예
 
|-
 
|align=center|
 
|align=center|여러 보조
 
|align=center|아니오
 
|align=center|아니오
 
|align=center|예
 
|align=center|예
 
|-
 
|align=center|
 
|align=center|보조에서 로드 지연
 
|align=center|아니오
 
|align=center|아니오
 
|align=center|예
 
|align=center|아니오
 
|-
 
|align=center|
 
|align=center|가용성 범위
 
|align=center|데이터베이스
 
|align=center|서버 인스턴스
 
|align=center|데이터베이스
 
|align=center|데이터베이스
 
|-
 
|align=center|'''클라이언트 액세스'''
 
|align=center|클라이언트 리디렉션
 
|align=center|ADO.NET 및 SQL Native Client에서 지원
 
|align=center|필요 없음, 가상 IP
 
|align=center|사용자 정의 코딩 필요
 
|align=center|사용자 정의 코딩 필요
 
|}
 
 
위의 표는 네 가지 가용성 기술의 여러 가지 특성을 요약한 것이다. 다음 절에서는 몇 가지 자세한 비교를 제공한다.<ref name="고가용성 기술">〈[http://www.dbguide.net/db.db?cmd=view&boardUid=144620&boardConfigUid=9&categoryUid=216&boardIdx=68&boardStep=1 데이터베이스 미러링 및 고가용성 기술]〉, 《디비가이드넷》</ref>
 
 
===데이터베이스 미러링 및 클러스터링===
 
데이터베이스 미러링과 장애 조치 클러스터링 사이의 가장 중요한 차이는 각각이 제공하는 중복의 수준이다. 데이터베이스 미러링은 데이터베이스 수준의 보호를 제공하는 반면, 클러스터링은 서버 인스턴스 수준의 보호를 제공한다. 다른 중요한 차이점은 데이터베이스 미러링에서 주 서버와 미러 서버가 서로 다른 이름을 가진 별개의 SQL 서버 인스턴스인 반면, 클러스터의 SQL 서버 인스턴스는 클러스터의 어떤 노드가 인스턴스를 호스팅 하는지에 관계없이 동일하게 유지되는 하나의 가상 서버 이름과 IP 주소를 얻는다는 것이다. 서버 수준에서 데이터베이스를 보호해야 하는 경우(예를 들어, 응용 프로그램이 같은 데이터베이스 서버에서 동시에 많은 데이터베이스에 액세스해야 하는 경우), 장애 조치 클러스터링이 더 적절한 선택일 수 있다. 그러나 한 번에 한 데이터베이스에 대한 가용성을 제공하도록 연결된 경우 데이터베이스 미러링은 여러 가지 장점을 갖고 있다. 클러스터링과 달리 데이터베이스 미러링은 전용 하드웨어가 필요하지 않으며 공유 저장 공간이 있는 잠재적인 오류 지점이 없다. 데이터베이스 미러링은 다른 고가용성 기술보다 훨씬 빨리 대기 데이터베이스를 서비스로 가져오며 클라이언트 쪽 장애 조치의 경우 ADO.NET 및 SQL 네이티브 액세스 클라이언트의 새로운 기능에서 잘 작동한다. 클러스터 내에서 데이터베이스 미러링을 사용할 수 없지만 클러스터 인스턴스 데이터베이스의 핫 대기 서버를 만드는 방법으로 데이터베이스 미러링 사용을 고려할 수 있다. 이렇게 하면 클러스터 장애 조치가 데이터베이스 미러링의 시간 초과 값보다 길기 때문에 발생할 때 클러스터 장애 조치에 반응합니다. 클러스터 노드가 미러링 상태가 된다.<ref name="고가용성 기술"></ref>
 
 
===데이터베이스 미러링 및 트랜잭션 복제===
 
데이터베이스 미러링 및 트랜잭션 복제는 모두 원본 서버의 트랜잭션 로그 읽기를 기준으로 하지만 기술은 상당히 다르다. 트랜잭션 복제에 대한 자세한 내용은 SQL 서버 온라인 설명서의 관련 항목을 참조하면 된다. 트랜잭션 복제는 게시자 데이터 베이스의 사용자 트랜잭션을 몇 초 만에 가입자에 전달할 수 있기 때문에 고가용성에 주로 사용된다. 데이터베이스 미러링은 복제만큼 또는 복제보다 더 빠르다는 장점이 있지만 사용자 테이블과 관련된 트랜잭션만이 아니라 모든 데이터베이스의 트랜잭션을 전달한다. 트랜잭션 복제는 보고를 위해 여러 게시자에게 데이터를 확장하는 적절한 기술이다. 데이터베이스 미러링은 트랜잭션 복제와 호환되며 게시자 데이터베이스의 핫 대기를 유지하는 방법으로 가장 유용하다. 로그 전달 같은 복제 게시자를 보호하는 다른 방법은 게시자 자체 가입자에 앞서 게시자를 위해 대기 서버를 유지할 수 없다. 즉, 트랜잭션 복제는 트랜잭션 로그 백업 스키마보다 훨씬 빠르게 가입자에게 트랜잭션을 전달할 수 있다. 데이터베이스 모니터링이 아주 빠르므로 게시자 데이터베이스의 hot 대기를 유지하는 데 훨씬 적합하다. 그러나 게시자가 실패하는 경우 복구된 대기 데이터베이스를 게시자로 수동으로 다시 설정하고 배포 서버에 다시 연결해야 한다. 따라서 게시자 서버를 대기 서버로 유지하기 위해 로그 전달을 사용하는 경우 현재 수행해야 한다.<ref name="고가용성 기술"></ref>
 
 
===데이터베이스 미러링 및 로그 전달===
 
데이터베이스 미러링 및 로그 전달은 SQL 서버 데이터베이스의 복원과 복구 기능에 의존한다. 데이터베이스 미러링 미러 데이터베이스는 계속 복구 중 상태에 있으며, 주 서버에서 트랜잭션을 계속해서 재생한다. 로그 전달 보조 서버는 트랜잭션 로그 백업에서 주기적으로 적용된 트랜잭션을 재생한다. 대량 로그 데이터가 트랜잭션 로그 백업에 추가하기 때문에 로그 전달은 대량 로그 복구 모델에서 작동할 수 있다. 반면에 데이터베이스 미러링은 주 서버에서 미러 서버로 로그 레코드를 직접 전송하며 대량 로그 데이터를 전달할 수 없다. 많은 경우 데이터베이스 미러링은 고가용? 데이터 중복을 제공할 수 있다. 그러나 응용 프로그램이 한 서버의 여러 데이터베이스에 의존하는 경우 로그 전달은 동일하게 유효한 방법일 수 있다. 앞 절의 “다중 데이터베이스 고려 사항”을 참조하는 게 좋다. 또한 로그 전달이 가용성을 보충할 수 있는 데이터베이스 미러링 시나리오가 있다. 예를 들어, 고가용성 데이터베이스 미러링 구성을 가질 수 있으며 재해 복구 목적을 위해 주 서버를 원격 사이트에 로그 전달할 수 있는 방법을 보여준다. 여기의 장점은 전체 사이트의 손실이 발생하는 경우 보조 사이트에서 데이터를 사용할 수 있다. 그러나 데이터베이스 미러링 장애 조치의 경우 서버 B에서 원격 대기 서버로의 로그 전달은 일반적으로 다시 초기화해야 한다. 데이터베이스 미러링을 보완하기 위해 로그 전달을 사용하는 또 다른 시나리오는 데이터베이스 미러링 세션이 재해 복구에 사용되는 주 서버에 대한 로컬 대기 서버로 사용되는 것이다. 이 경우 미러링 세션은 원격 사이트의 미러 서버가 원격 대기 서버인 고성능 모드에 있다. 고성능 모드에서 주 서버가 실패하고 미러 서버가 강제 서비스 복구를 사용하여 복구된 경우 데이터 손실 가능성이 있다. 이전 주 서버를 로그 전달하고 이전 주 서버의 트랜잭션 로그 파일이 손상되지 않은 경우 주 서버의‘tail of the log’ 백업을 만들어 트랜잭션 로그에서 로그 레코드의 마지막 세트를 얻을 수 있다. 대기 로그 전달 데이터베이스에 다른 모든 트랜잭션 로그 백업이 적용된 경우 대기 서버에 로그 백업의 끝을 적용할 수 있으며 이전 주 서버의 데이터가 손실되지 않는다.<ref name="고가용성 기술"></ref>
 
 
==결론==
 
데이터베이스 미러링은 데이터베이스 중복을 위한 고가용성과 고성능 솔루션을 전달할 수 있는 새로운 SQL 서버 2005 기술이다. 데이터베이스 미러링에서 주 서버의 트랜잭션 로그 버퍼가 디스크에 기록될 때마다 트랜잭션 로그 레코드는 주 서버에서 미러 데이터베이스로 직접 전송된다. 이 기술은 주 서버와 거의 최신 상태로 미러 데이터베이스를 유지할 수 있으며 커밋 된 데이터는 손실되지 않는다. 고가용성 작동 모드에서는 주 서버가 실패하는 경우 미러 서버는 자동으로 새로운 주 서버가 되고 데이터베이스를 복구한다. 새로운 ADO.NET 또는 SQL 네이티브 액세스 클라이언트 드라이버를 사용하여 응용 프로그램은 클라이언트 서버에서도 자동 장애 조치를 수행할 수 있다. 데이터베이스 미러링은 SQL 서버 2005에서 지원하는 고가용성 기술에서 중요한 새 옵션이 되고 있다.<ref name="고가용성 기술"></ref>
 
  
 
{{각주}}
 
{{각주}}

2020년 8월 12일 (수) 13:34 판

미러사이트(mirror site)

미러사이트(mirror site)란 다른 사이트의 정보를 마치 거울(mirror)처럼 그대로 복사하여 동일한 정보를 제공하는 웹사이트를 말한다. 동일한 내용을 전 세계 여러 지역에 분산하여 서비스함으로써 네트워크 부하를 분산할 수 있고, 시스템 장애 시 신속히 대응할 수 있는 장점이 있다. 다만, 동일한 시스템을 여러 곳에 중복하여 구축·운영해야 하므로 관리 및 비용 부담이 큰 단점이 있다. 유사한 개념으로 콘텐츠 전송 네트워크(CDN, content delivery network)가 있다.

개요

미러사이트는 다른 웹사이트의 콘텐츠를 그대로 복사하여 갖고 있는 웹사이트 또는 컴퓨터 파일서버를 말한다. 다른 사이트의 정보를 거울처럼 그대로 복사하는 사이트라고 해서 ‘미러(mirror)’라는 이름이 붙었다. 이런 식으로 웹사이트의 파일을 동기화하는 것을 미러링이라고 부른다. 미러링의 목적은 데이터의 안정적 보존 및 본 서버에 문제가 생겼을 경우에 대한 대비이다. 미러링을 함으로써 본 서버의 접속자를 분산하거나 해당 웹페이지를 빠르고 가볍게 접속할 수 있다.[1] 접속량이 많은 사이트들은 과다한 트래픽으로 접속이 힘들거나 접속 속도가 떨어지는 경우가 있다. 이를 방지하기 위해 네트워크 이용 효율을 향상시키기 위한 목적으로 미러사이트가 개발되었다. 미러사이트를 이용하면 웹사이트나 파일의 가용성을 좋게 하고, 그 사이트에서 다운로드된 파일들이 미러사이트 부근에 있는 사용자들에게 보다 빨리 도착하게 한다.

미러사이트들은 원래 사이트가 지리적으로 어느 정도의 거리가 있을 때, 보다 빨리 액세스하기 위해 사용된다. 미러사이트는 파일의 배포 부담을 2개 이상의 파일서버로 분산하거나 통신량이 폭주하는 장거리 또는 국제 회선을 경우하지 않고, FTP 서사이트에 접근할 수 있게 하여 FTP 서버로부터 다운로드 될 수 있는 파일들에 대해서도 미러파일을 만들 수 있다. 다만 인터넷상에서 유명한 사이트의 경우 전 세계 몇 군데의 미러사이트가 있기 때문에 접속이 원활하지 않은 경우가 있어, 그런 경우에는 가까운 곳 또는 국내의 미러사이트를 이용하는 것이 바람직하다. 원래 사이트가 인터넷에 고속으로 접속되어 있지 않은 경우, 고속으로 접속되어 있는 대형 사이트에 미러사이트를 만든다면 아마도 보다 많은 방문객을 유지할 수 있을 것이다. 넷스케이프, 마이크로시스템즈, 썬 마이크로시스템즈, 그리고 다른 많은 회사들이 자신의 브라우저 소프트웨어를 다운로드 받을 수 있는 미러사이트들을 가지고 있다.[2] 한편 미러사이트는 원래 사이트의 정확한 복제품이어야 하므로 원래 사이트의 내용을 확실히 반영시키기 위해 보통 주기적으로 갱신된다는 특징이 있다.

특징

미러사이트는 주 센터와 동일한 수준의 정보 기술 자원을 원격지에 구축하고, 메인센터 재해복구센터 모두 액티브 상태로 실시간 동시 서비스를 하는 방식이다. 재해 발생 시 복구까지의 소요시간(RTO)는 이론적으로 '0'이다. 초기 투자 및 유지 보수에 높은 비용이 소요되며, 웹 애플리케이션 서비스 등 데이터의 업데이트의 빈도가 높지 않은 시스템에 적용 가능하다.[3] 미러사이트가 작동하는 방법에는 여러 가지가 있다. 가장 일반적으로 미러는 스냅 샷과 같이 원본 사이트의 정적 복사본으로, 소유자가 콘텐츠를 최신 상태로 유지하려면 미러를 자주 업데이트해야 한다. 원래 사이트의 변경 사항으로 최신 상태를 유지하는 라이브 미러를 설정할 수도 있다. 미러사이트의 용도에 따라 미러는 전체 웹 사이트를 복사하거나 파일 아카이브 역할을 할 수 있다.

미러사이트를 설정하는 일반적인 이유 중 하나는 서버에 과부하가 걸리는 갑작스러운 트래픽 유입에 대처하기 위한 것이다. 방문자에게 미러사이트 또는 여러 사이트를 제공함으로써 사이트 소유자는 사람들이 사이트를 볼 수 있도록 사이트를 계속 운영할 수 있다. 서버 문제나 트래픽 유입으로 인해 사이트가 다운될 때 유용하다. 미러사이트는 백업으로도 사용되므로 서버가 어떤 식 으로든 손상되거나 손상된 경우 전체 파일 세트가 다른 곳에서 호스팅 되도록 한다. 소프트웨어 다운로드는 종종 서버를 압도하지 않고 사용자 편의를 위해 미러사이트에서 호스팅 된다. 예를 들어 독일에 있는 다운로드 사이트는 일본 사용자를 위해 일본에 미러사이트를 제공하여 파일을 더 빨리 다운로드할 수 있다. 또한 여러 서버에 소프트웨어를 배포하면 하나 이상의 사이트가 다운되더라도 사용자가 항상 소프트웨어에 액세스할 수 있다. 고전적으로 미러사이트는 검열과 싸우기 위해 사용되었다. 예를 들어, 사이트가 종료된 경우를 대비하여 논란이 많은 사이트가 원격 위치에 미러링 될 수 있다. 또는 검열 소프트웨어에 의해 금지된 사이트는 사람들이 여전히 액세스할 수 있도록 미러를 호스팅 할 수 있다. 미러는 원본 사이트가 중단되거나 근본적으로 재설계 될 때 견딜 수 있는 일종의 살아있는 아카이브인 빈티지 콘텐츠의 저장소 역할을 할 수도 있다. 이전 화신에서 사이트를 보거나 날짜가 있지만 여전히 관심이 있는 정보에 액세스하려는 사용자에게 유용할 수 있다.[4]

각주

  1. 미러 사이트 나무위키 - https://namu.wiki/w/%EB%AF%B8%EB%9F%AC%20%EC%82%AC%EC%9D%B4%ED%8A%B8
  2. mirror site ; 미러사이트〉, 《텀즈》, 1999-11-04
  3. 제이제이 IT 스토리, 〈2차 사이트 종류별 특징〉, 《티스토리》, 2018-09-06
  4. 미러 사이트 란 무엇입니까?〉, 《네트인백》

참고자료

같이 보기


  검수요청.png검수요청.png 이 미러사이트 문서는 하드웨어에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.