oracle cloud infrastructure의 고가용성 아키텍처 배포 범 사례 · 2019-12-10 · 2 |...

Oracle Cloud Infrastructure의

고가용성 아키텍처 배포 모범 사례

오라클 참조 아키텍처 | 2018년 10월

2 | Oracle Cloud Infrastructure의 고가용성 아키텍처 배포 모범 사례

개정 이력

다음은 본 백서 최초 발간 이후 지금까지 개정된 이력을 나타낸 것입니다.

날짜 개정

2018년 10월 18일 • 폴트 도메인 (Fault Domain)에 대한 정보 추가됨

• 단일 가용성 도메인의 배포 시나리오 추가됨

2018년 8월 31일 최초 발간

최신 버전의 Oracle Cloud Infrastructure 백서는 https://cloud.oracle.com/iaas/technical-

resources에서 찾아보실 수 있습니다.

https://cloud.oracle.com/iaas/technical-resources



목차

개요 4

서론 4

고가용성 빌딩 블록 4

고가용성 솔루션 아키텍처 설계 6

컴퓨트 고가용성 설계 6

네트워크 고가용성 설계 9

로드 밸런싱 고가용성 설계 9

패스트커넥트 및 VPN 고가용성 설계 12

스토리지 고가용성 설계 18

데이터베이스 고가용성 설계 20

결론 23


개요

본 참조 아키텍처 백서는 Oracle Cloud Infrastructure에 배포될 예정인 고가용성 (HA) 솔루션

설계를 위한 아키텍처 모범 사례를 오라클 고객과 파트너에게 제공합니다. 여기에는 Oracle Cloud

Infrastructure에서만 만나볼 수 있는 여러 기능의 활용 방법에 대한 자세한 설명도 포함됩니다.

서론

본 참조 아키텍처 백서는 고가용성 (HA) 아키텍처를 계획, 설계하여 Oracle Cloud Infrastructure에

배포하는 데 필요한 모범 사례에 대해 설명하고 있습니다.

'고가용성 서비스' 또는 '고가용성 어플리케이션'이란 잠재적 가동 시간과 접근성을 극대화하기

위해 개발된 서비스 또는 어플리케이션을 말합니다. 고가용성 아키텍처를 설계하기 위해 고려해야

할 주요 요소로는 세 가지, 즉 리던던시, 모니터링, 페일오버가 있습니다.

• '리던던시'란 다수의 구성요소가 동일한 작업을 수행할 수 있는 것을 의미합니다. 리던던시

구성요소가 장애를 일으킨 구성요소를 대신에 작업을 수행하기 때문에 단일 장애점의

문제가 사라집니다.

• '모니터링'은 구성요소의 정상적인 기능 여부를 확인하는 것입니다.

• '페일오버'는 기본 구성요소에 장애가 발생할 경우 보조 구성요소가 기본 구성요소를

대신하는 프로세스입니다.

본 백서에서는 이러한 세 가지 주요 요소를 중심으로 아키텍처 설계에 대해 살펴보겠습니다.

고가용성이 어플리케이션 수준, 클라우드 인프라 수준을 포함해 매우 다양한 수준에서 구현되기는

하지만 본 백서는 클라우드 인프라 수준에 초점을 맞춰 작성되었습니다.

고가용성 빌딩 블록

Oracle Cloud Infrastructure 지역 은 가용성 도메인 1개 이상으로 구성된 지리적 분산 영역이며,

여기에서 가용성 도메인은 다시 폴트 도메인 3개로 구성됩니다.

'가용성 도메인 (Availability Domain)'이란 지역 내에 위치한 데이터 센터 1곳 이상을 말합니다.

가용성 도메인은 서로 격리되어 장애를 일으키더라도 다른 가용성 도메인에 영향을 미치지 않을

뿐만 아니라 동시에 장애를 일으킬 가능성도 거의 없습니다. 가용성 도메인은 전력, 냉각 같은

물리적 인프라 또는 내부 가용성 도메인 네트워크를 서로 공유하지 않기 때문에, 가용성 도메인

1곳에 영향을 미치는 장애가 다른 곳의 가용성에도 영향을 미칠 가능성은 극히 드뭅니다.

'폴트 도메인 (Fault Domain)'은 가용성 도메인을 구성하는 하드웨어와 인프라 그룹을 말합니다.

각 가용성 도메인에는 폴트 도메인이 3개씩 있습니다. 폴트 도메인에서는 고객이 인스턴스를

분산시킬 수 있기 때문에 단일 가용성 도메인 내에서도 인스턴스가 속하는 물리적 하드웨어가


서로 다릅니다. 결과적으로 예기치 못한 하드웨어 장애나 컴퓨트 하드웨어 유지관리로 폴트

도메인 1곳이 영향을 받는다고 해서 다른 폴트 도메인의 인스턴스까지 영향을 받지는 않습니다.

옵션으로 새로운 인스턴스를 시작할 때 폴트 도메인을 지정하거나, 혹은 시스템이 대신

선택하도록 할 수 있습니다.

지역에 속한 모든 가용성 도메인은 서로 지연 시간이 낮은 고대역폭 네트워크로 연결됩니다.

이렇게 예측 가능하고 암호화되는 가용성 도메인 연결은 고가용성과 재해 복구를 위한 빌딩

블록을 보장합니다.

그림 1. 고가용성 빌딩 블록

Oracle Cloud Infrastructure 리소스는 가상 클라우드 네트워크처럼 지역 (Region) 전용이거나, 혹은

컴퓨트 인스턴스처럼 가용성 도메인 전용입니다. 클라우드 서비스를 구성할 때 서비스가 가용성

도메인 전용이라면 다수의 가용성 도메인 또는 폴트 도메인을 이용하여 고가용성을 유지하는

동시에 리소스 장애에서 보호할 수 있도록 해야 합니다. 리던던시 컴퓨트 인스턴스를 다른 가용성

도메인이나 폴트 도메인에 생성하여 기본 컴퓨트 인스턴스 또는 도메인의 문제로 인해

어플리케이션에 미치는 영향을 피할 수 있습니다.

발생하는 장애 등급에 따라 다수의 지역, 가용성 도메인 또는 폴트 도메인으로 구성된 솔루션을

설계할 수 있습니다.


고가용성 솔루션 아키텍처 설계

이번 단원에서는 각 Oracle Cloud Infrastructure 계층에 대해 설명하면서 고가용성 솔루션

아키텍처를 위한 모범 사례와 설계 지침에 대해 자세히 살펴보겠습니다.

그림 2. Oracle Cloud Infrastructure 고급 아키텍처

컴퓨트 고가용성 설계

Oracle Cloud Infrastructure 컴퓨트 (Compute)는 베어메탈 인스턴스와 가상 머신(VM) 인스턴스를

모두 제공하기 때문에, 작은 크기의 단일 코어 VM부터 코어 52개와 768GB RAM이 탑재되는

베어메탈 서버에 이르기까지 이러한 유연성을 바탕으로 필요에 따라 어떤 크기의 서버든 배포할

수 있습니다. 이러한 옵션은 성능과 유연성, 그리고 제어까지 보장하여 아무리 까다로운

어플리케이션이나 워크로드라고 해도 클라우드에서 실행이 가능합니다.

단일 장애점 제거

고가용성 솔루션의 주요 설계 원칙 중 하나는 단일 장애점 제거입니다.

단일 고가용성 도메인 배포

각 가용성 도메인에는 폴트 도메인이 3개씩 있습니다. 폴트 도메인을 적절하게 이용하면 Oracle

Cloud Infrastructure 기반 어플리케이션의 가용성을 높일 수 있습니다.

폴트 도메인을 사용한 인스턴스의 격리 또는 그룹화는 어플리케이션의 아키텍처에 따라

결정됩니다.

• 시나리오 1: 고가용성 어플리케이션 아키텍처

이번 시나리오에서는 고가용성 어플리케이션 (예: 웹 서버 2개와 데이터베이스 클러스터

1개)이 있다고 가정합니다. 이때는 폴트 도메인 1개에 웹 서버 1개와 데이터베이스 노드

1개로, 그리고 다른 폴트 도메인에 나머지 각 쌍의 절반으로 그룹화합니다. 이러한

아키텍처에서는 폴트 도메인 1개에 장애가 발생하더라도 어플리케이션 중단으로 이어지지

않습니다.


• 시나리오 2: 단일 웹 서버 및 데이터베이스 인스턴스 아키텍처

이번 시나리오에서는 어플리케이션 아키텍처의 가용성이 높지 않습니다. 예를 들어, 웹

서버 1개와 데이터베이스 인스턴스가 1개로 구성되기 때문입니다. 이때는 동일한 폴트

도메인에서 웹 서버와 데이터베이스 인스턴스를 구성해야 합니다. 이러한 아키텍처에서는

어플리케이션이 폴트 도메인 1개의 장애에서만 영향을 받게 됩니다.

다중 고가용성 도메인 배포

고가용성에 대한 또 한 가지 접근 방식은 동일한 작업을 수행하는 컴퓨트 인스턴스를 다중

가용성 도메인에 배포하는 것입니다. 이러한 설계는 리던던시를 도입하여 단일 장애점을 제거하는

데 효과적입니다.

다음은 리던던시 구현을 위해 웹 서버 VM이 가용성 도메인 2곳에 배포된 다이어그램입니다.

그림 3. 가용성 도메인 2곳에 배포된 웹 서버 VM

시스템 또는 어플리케이션 요건에 따라 아키텍처 리던던시를 예비 모드 또는 액티브 모드로

구현할 수 있습니다.

• 예비 모드에서는 보조 또는 예비 구성요소가 기본 구성요소와 함께 실행됩니다. 이때,

기본 구성요소에 장애가 발생하면 예비 구성요소가 기본 구성요소의 작업을 대신합니다.

예비 모드는 일반적으로 상태를 유지해야 하는 어플리케이션에 사용됩니다.

• 액티브 모드에서는 기본 또는 예비 구성요소가 없습니다. 모든 구성요소가 동일한 작업에

능동적으로 참여합니다. 이때, 구성요소 중 하나에 장애가 발생하면 관련 작업이 다른

구성요소로 이동합니다. 액티브 모드는 일반적으로 비상태 기반 어플리케이션에

사용됩니다.


플로팅 IP 주소

컴퓨트 인스턴스의 플로팅 IP 주소 (Floating IP Address)는 보조 프라이빗 IP 주소든 예약된

퍼블릭 IP 주소든 상관없이 Oracle Cloud Infrastructure의 고가용성 아키텍처 설계에서 중요한

역할을 합니다.

컴퓨트 인스턴스는 보조 프라이빗 IP 주소가 할당될 수 있습니다. 컴퓨트 인스턴스에 문제가

생기면 이 보조 프라이빗 IP 주소를 동일한 서브넷의 예비 인스턴스에 다시 할당하여 인스턴스

페일오버를 구현할 수 있습니다.

예약된 퍼블릭 IP 주소는 현재 할당된 컴퓨트 인스턴스가 종료되더라도 영구적으로 존재할 수

있습니다. 고가용성 및 페일오버 시나리오의 경우에는 예약된 퍼블릭 IP 주소를 기본

인스턴스에서 해제한 후 예비 인스턴스에 다시 할당할 수 있습니다.

Linux 고가용성 서비스 (예: Corosync, Pacemaker)를 이용하면 이러한 플로팅 IP 주소 페일오버

기능을 자동화할 수 있습니다.

데이터 가용성 및 무결성

고가용성 아키텍처에서는 컴퓨트 인스턴스의 데이터 가용성과 무결성을 모두 보호할 수 있어야

합니다. 컴퓨트 인스턴스의 데이터 가용성을 보호하려면 데이터를 다른 로케이션으로 복제하거나

백업할 수 있습니다.

또한, 동기식 또는 비동기식 복제를 사용해 컴퓨트 인스턴스에 장애가 발생한 경우 데이터를

보호할 수도 있습니다.

• 이전 단원에서 얘기했듯이 Oracle Cloud Infrastructure의 가용성 도메인은 서로 충분히

가깝기 때문에 고성능 네트워크를 통한 동기식 복제를 지원합니다. 따라서 즉각적인

페일오버가 필요하고 데이터 손실을 허용하지 않는 어플리케이션이라면 동기식 복제를

권장합니다. 이러한 네트워크 성능 요건 때문에 동기식 복제는 일반적으로 지역 내에서

사용됩니다.

• 지역 간 데이터 가용성을 보호해야 하는 어플리케이션일 때는 비동기식 복제를

권장합니다.

기존 백업 역시 데이터를 보호할 수 있는 또 한 가지 방법입니다. 데이터 내구성을 극대화하고

싶다면 백업 파일을 원본 컴퓨트 인스턴스와 동일한 가용성 도메인에 저장하지 마십시오. 이때는

Oracle Cloud Infrastructure 오브젝트 스토리지 (Object Storage)를 사용해 컴퓨트 인스턴스의

데이터를 백업하는 것이 바람직합니다.

로컬 NVMe 드라이브가 장착된 컴퓨트 인스턴스일 때는 RAID 어레이 보호가 NVMe 드라이브

장애에서 보호할 수 있는 최고의 방법입니다.


네트워크 고가용성 설계

Oracle Cloud Infrastructure 작업의 첫 번째 단계는 클라우드 리소스를 위한 가상 클라우드

네트워크 (VCN) 설정입니다. VCN이란 오라클 클라우드 데이터 센터에서 설정할 수 있는

소프트웨어 정의 네트워크를 말합니다. 서브넷은 클라우드 네트워크의 하위 영역입니다. 네트워크

고가용성 유지는 아키텍처 설계 시 가장 중요한 항목 중 하나입니다.

적합한 서브넷 크기 결정

각 VCN 서브넷은 단일 가용성 도메인에 존재하며, 클라우드 네트워크의 다른 서브넷과 중첩되지

않는 인접 IP 주소 범위로 구성됩니다 (예: 172.16.1.0/24). 서브넷 CIDR에서 첫 번째 IP 주소

2개와 마지막 주소 1개는 Oracle Cloud Infrastructure 네트워킹 서비스에서 예약된 주소입니다.

서브넷 크기는 생성 이후 바꿀 수 없기 때문에 생성 이전에 크기에 대해 신중하게 생각해야

합니다. 향후 워크로드 확장을 고려하는 동시에 예비 컴퓨트 인스턴스 설정 등 고가용성 요건을

해결하는 데 충분한 용량을 준비하십시오.

로드 밸런싱 고가용성 설계

Oracle Cloud Infrastructure 로드 밸런싱은 트래픽을 진입점 한 곳부터 시작해 가상 클라우드

네트워크 (VCN)에서 전송 가능한 여러 서버로 자동으로 분산시키는 기능을 지원합니다. 이

서비스는 원하는 퍼블릭 또는 프라이빗 IP 주소와 프로비저닝된 대역폭을 로드 밸런서와 함께

제공합니다.

로드 밸런싱 서비스는 리소스 사용량 개선과 손쉬운 확장을 통해 고가용성을 유지하는 데

효과적입니다. 또한, 수신되는 요청을 가상 호스트 이름, 경로 라우팅 규칙, 혹은 둘 다에 따라

다양한 백엔드 세트로 라우팅할 있도록 지원합니다.

퍼블릭 로드 밸런서

인터넷에서 수신되는 트래픽을 허용하려면 퍼블릭 로드 밸런서를 생성하여 사용하십시오. 이

서비스는 해당 로드 밸런서에 수신 트래픽의 진입점 역할을 하는 퍼블릭 IP 주소를 할당합니다.

퍼블릭 IP 주소는 DNS 공급업체를 통해 친숙한 DNS 이름과 연결되기도 합니다.

퍼블릭 로드 밸런서는 범위가 지역으로 한정되며, 서로 분리된 가용성 도메인에 각각 1개씩 2개의

서브넷이 필요합니다. 이에 따라 퍼블릭 로드 밸런서는 가용성 도메인에서 근본적으로 높은

가용성을 유지합니다. 시스템의 고가용성을 유지하기 위한 목적으로 시스템을 퍼블릭 로드 밸런서

뒤에 배치할 수도 있습니다. 예를 들어, 아래의 다이어그램처럼 백엔드 서버 집합인 웹 서버

VM을 퍼블릭 로드 밸런서 뒤에 배치하는 방법이 있습니다.


그림 4. 퍼블릭 로드 밸런서를 사용한 고가용성 아키텍처

프라이빗 로드 밸런서

로드 밸런서를 인터넷에서 격리시켜 보안 태세를 간소화하려면 프라이빗 로드 밸런서를 생성하여

사용하십시오. 로드 밸런싱 서비스는 해당 로드 밸런서에 수신 트래픽의 진입점 역할을 하는

프라이빗 IP 주소를 할당합니다.

프라이빗 로드 밸런서를 생성할 경우, 이 서비스는 기본 로드 밸런서와 예비 로드 밸런서를 모두

호스팅할 수 있는 서브넷을 1개만 요구합니다. 이때, 프라이빗 로드 밸런서 서비스는 가용성

도메인을 벗어나지 않는 범위로 제한됩니다.

그림 5. 프라이빗 로드 밸런서를 사용한 고가용성 아키텍처


고객은 가용성 도메인 사이의 고가용성을 위해 Oracle Cloud Infrastructure에서 다수의 프라이빗

로드 밸런서를 구성한 후 온프레미스 또는 프라이빗 DNS 서버를 사용해 프라이빗 로드 밸런서

IP 주소로 라운드 로빈 방식의 DNS 구성을 설정할 수 있습니다. 이러한 구성 설정 방법은 다음과

같습니다.

1. 프라이빗 로드 밸런스를 가용성 도메인마다 1개씩 2개 배포합니다.

2. VCN에서 사용자 지정 DNS VM 2개를 구성합니다.

3. 사용자 지정 DNS 분석기를 사용하도록 VCN 기본 DHCP 옵션을 수정하고 DNS 서버를

DNS VM의 IP 주소로 설정합니다.

4. 낮은 TTL 값을 사용해 프라이빗 로드 밸런서 FQDN에 라운드 로빈 방식의 새로운 DNS

구역 항목을 추가합니다.

5. 프라이빗 로드 밸런서 2개의 IP 주소를 사용해 A 레코드 2개를 추가합니다.

6. 프라이빗 로드 밸런서에 액세스할 때는 프라이빗 로드 밸런서의 FQDN을 사용합니다.

아래의 다이어그램은 가용성 도메인 사이에 고가용성 프라이빗 로드 밸런서를 설정하는 방법을

나타낸 것입니다.

그림 6. 가용성 도메인 사이에 프라이빗 로드 밸런서를 사용한 고가용성 아키텍처


패스트커넥트 및 VPN 고가용성 설계

시스템 아키텍처를 효과적으로 설계하기 위해서는 가용성이 높을 뿐만 아니라 장애를

일으키더라도 다른 네트워크에 영향을 미치지 않는 네트워크 연결이 핵심입니다. 이번 단원에서는

네트워크 이중화 설계로 Oracle Cloud Infrastructure IPSec VPN 및 패스트커넥트 서비스 수준

계약(SLA) 요건을 충족할 수 있는 방법에 대해 자세하게 설명합니다. 또한, 리던던시 VPN 연결을

위한 고가용성 옵션과 리던던시 패스트커넥트 연결을 위한 고가용성 옵션, 그리고 백업 VPN

연결을 포함한 패스트커넥트 연결을 위한 고가용성 옵션에 대해서도 살펴보겠습니다.

기업의 비즈니스 가용성과 어플리케이션 요건은 원격 연결을 설계하면서 가장 적합한 구성을

결정하는 데 커다란 도움이 됩니다. 하지만 일반적으로 리던던시 하드웨어와, 고객의 로케이션과

오라클 데이터 센터 사이의 네트워크 서비스 공급자를 함께 사용하는 것이 바람직합니다.

무엇보다 가장 견고한 방법은 다수의 패스트커넥트 연결을 다른 네트워크 서비스 공급자의

회선과 함께 사용하는 것입니다.

네트워크 고가용성을 구현할 경우에는 다음과 같은 모범 사례를 권장합니다.

• 오라클, 네트워크 서비스 공급자 또는 고객 기업의 정기적인 유지관리 일정을

예약하십시오.

• 가용성을 위해 다수의 인터페이스를 사용하더라도 단일 장애점을 제거하십시오.

물리적으로 동일한 로케이션에서 연결하더라도 고가용성 연결을 위해서는 리던던시

하드웨어가 필요합니다.

• 패스트커넥트 공급자를 선정할 때는 네트워크 다원화를 위해 이중 공급자 방식을

고려하십시오.

• 네트워크 연결 1곳의 장애로 인해 리던던시 연결이 저하되지 않도록 네트워크 용량을

충분히 프로비저닝하십시오.

IPSec VPN을 사용한 네트워크 고가용성 설계

고객이 자신의 데이터 센터를 Oracle Cloud Infrastructure에 연결할 때 IPSec VPN 연결을

구현하도록 선택할 수 있습니다. IPSec VPN 연결은 설정이 쉽고 비용 효율적입니다.

Oracle Cloud Infrastructure 동적 라우팅 게이트웨이(DRG)에는 리던던시 활성화를 위해 각각

다수의 VPN 엔드포인트가 있기 때문에, 각 IPSec VPN 연결마다 다수의 리던던시 IPSec 터널로

구성되어 정적 라우팅으로 트래픽을 라우팅합니다. 고가용성을 유지하려면 내부 네트워크에 VPN

연결 가용성을 설정하여 아래 다이어그램과 같이 필요에 따라 한쪽 경로를 사용해야 합니다.


그림 7. IPSec VPN 고가용성 설계

넓은 범위의 CIDR을 동적 라우팅으로 사용

데이터 센터가 다수의 지리적 로케이션에 걸쳐 있다면 특정 지리적 로케이션의 CIDR에 더해 넓은

범위의 CIDR(0.0.0.0/0)을 정적 라우팅으로 사용하는 것이 좋습니다. 넓은 범위의 CIDR은 네트워크

설계 시 고가용성과 유연성을 보장하기 때문입니다.

예를 들어, 아래의 다이어그램은 별도의 지리적 위치에서 서로 Oracle Cloud Infrastructure에

연결되어 있는 네트워크 2개를 나타낸 것입니다. 각 위치마다 단일 온프레미스 라우터가 있기

때문에 IPSec VPN 연결을 2개 생성할 수 있습니다. 이때, 각 IPSec VPN 연결에는 특정 지리적

위치의 CIDR 정적 라우팅 1개와 넓은 범위(0.0.0.0/0)의 정적 라우팅까지 총 2개의 정적 라우팅이

있습니다.

그림 8. 다수의 지리적 로케이션을 이용한 IPSec VPN


시나리오 1에서는 위 다이어그램의 CPE 1 라우터가 작동하지 않습니다. 서브넷 1과 서브넷 2가

서로 통신하는 경우에도 CPE 2로 이동하는 0.0.0.0/0 정적 라우팅 때문에 VCN이 계속해서 서브넷

1 시스템에 액세스할 수 있습니다. 아래의 다이어그램은 이러한 시나리오를 나타낸 것입니다.

그림 9. IPSec VPN 고가용성 시나리오 1

또 다른 시나리오에서는 서브넷 3이 속하는 지리적 위치를 새롭게 추가하여 서브넷 2에

연결합니다. 여기에서는 라우팅 규칙을 VCN의 서브넷 3 라우팅 테이블에 추가합니다. 따라서 CPE

2로 이동하는 0.0.0.0/0 정적 라우팅 때문에 VCN이 새로운 VPN 연결을 생성하지 않고도 서브넷

3 시스템과 통신할 수 있습니다. 아래의 다이어그램은 이러한 시나리오를 나타낸 것입니다.

그림 10. IPSec VPN 고가용성 시나리오 2


패스트커넥트를 사용한 네트워크 고가용성 설계

Oracle Cloud Infrastructure 패스트커넥트 (FastConnect)에서는 데이터 센터와 Oracle Cloud

Infrastructure 사이에 전용 프라이빗 연결을 쉽게 생성할 수 있습니다. 패스트커넥트는 인터넷 기반

연결과 비교했을 때 더욱 높은 대역폭 옵션과 안정적이고 일관적인 네트워크 경험을 제공합니다.

패스트커넥트 고객은 프라이빗 피어링, 퍼블릭 피어링 또는 둘 다 사용할 수 있습니다.

• 프라이빗 피어링은 기존 인프라를 Oracle Cloud Infrastructure의 가상 클라우드 네트워크

(VCN)까지 확장하는 데 사용됩니다 (예: 하이브리드 클라우드 구현 시 또는 리프트 앤

시프트 시나리오에서). 연결 간 통신은 IPv4 프라이빗 주소 (일반적으로 RFC 1918)를

사용해 이루어집니다.

• 퍼블릭 피어링은 인터넷을 사용하지 않고 Oracle Cloud Infrastructure의 퍼블릭 서비스에

액세스하는 데 사용됩니다 (예: 오브젝트 스토리지, Oracle Cloud Infrastructure 콘솔 및

API 또는 VCN의 퍼블릭 로드 밸런서에 액세스할 때). 연결 간 통신은 IPv4 퍼블릭 IP

주소를 사용해 이루어집니다. 패스트커넥트를 사용하지 않을 경우에는 퍼블릭 IP 주소로

향하는 트래픽이 인터넷을 통해 라우팅되지만, 패스트커넥트를 사용하기 때문에 트래픽이

물리적 프라이빗 연결을 통해 이동합니다.

직접 공급자 네트워크 거점 (POP)에서 Oracle Cloud Infrastructure 라우터에 연결하거나, 혹은 오라클

파트너 한 곳을 활용해 전 세계 POP부터 Oracle Cloud Infrastructure 네트워킹 리소스까지 연결할

수도 있습니다. 오라클은 지역 1곳당 다수의 POP를 구성하거나, POP 1곳당 다수의 패스트커넥트

라우터를 구성하는 등 장애 허용 (Fault-tolerant) 연결을 구축할 수 있는 기능을 제공합니다.

패스트커넥트 리던던시

Oracle Cloud Infrastructure는 리던던시를 이용해 단일 장애점을 제거할 목적으로 다음과 같은

기능을 제공합니다.

• 각 대도시권역마다 다수의 패스트커넥트 로케이션

• 각 패스트커넥트 로케이션마다 다수의 라우터

• 각 패스트커넥트 로케이션마다 다수의 물리적 회선

오라클은 패스트커넥트 로케이션에서 라우터와 물리적 회선을 이용해 리던던시를 처리합니다.

패스트커넥트를 이용해 네트워크를 설계할 때는 고가용성 요건을 위한 다음과 같은 리던던시

구성을 고려하는 것이 좋습니다.

• 가용성 도메인 리던던시: 패스트커넥트 로케이션에 연결한 후 지역 내 가용성 도메인에

속하는 서비스에 액세스합니다. 이러한 구성은 지역 1곳마다 구축되는 다수의 POP를 통해

가용성 도메인의 탄력성을 보장합니다. 피어링 연결은 POP의 라우터에서 종단됩니다.


• 데이터 센터 로케이션 리던던시: 지역마다 다른 패스트커넥트 로케이션 2곳에서

연결합니다.

• 라우터 리던던시: 패스트커넥트 로케이션마다 다른 라우터 2곳에 연결합니다.

• 회선 리던던시: 임의의 패스트커넥트 로케이션 한 곳에서 다수의 물리적 연결을

구성합니다. 또한, 각 회선마다 통합 인터페이스/LAG에 다수의 물리적 링크를 구성하여 또

하나의 리던던시 계층을 추가할 수 있습니다.

• 파트너/공급자 리던던시: 파트너 1곳 또는 다수를 사용해 패스트커넥트 로케이션에

연결합니다.

고객은 온프레미스 데이터 센터의 로케이션에 따라 다음 중 한 가지 방법으로 패스트커넥트

연결을 구성할 수 있습니다.

• 코로케이션 (포트 속도 10Gbps): 패스트커넥트 위치에서 오라클과 함께 코로케이션

• 오라클 공급자 (1Gbps 또는 10Gbps씩 포트 속도 증가): 오라클 공급자에게 연결

코로케이션 시나리오에서 교차 연결이란 기존 네트워크를 패스트커넥트 로케이션의 오라클에

연결하는 물리적 케이블을 말합니다. 패스트커넥트 서비스를 프로비저닝할 때는 교차 연결을 2개

이상 설정하는 것이 좋습니다. 각 교차 연결은 서로 다른 라우터에 연결되어 한 라우터의 장애가

Oracle Cloud Infrastructure 리소스에 대한 연결에 영향을 미치지 못하도록 해야 합니다. 첫 번째

교차 연결을 마치면 두 번째 교차 연결을 첫 번째 교차 연결과 다른 오라클 패스트커넥트

라우터에 프로비저닝하도록 요청할 수 있습니다. 그런 다음 새로운 가상 회선을 리던던시 링크 두

곳에 모두 프로비저닝해야 합니다. 그래야만 라우터 하나가 장애를 일으켜도 온프레미스

네트워크와 Oracle Cloud Infrastructure VCN 사이의 연결을 유지할 수 있습니다.

오라클 공급자 시나리오에서는 동일한 공급자 또는 다른 공급자의 패스트커넥트 로케이션 2개를

서로 다르게 사용하여 리던던시 회선을 설정하는 것이 좋습니다. 이러한 구성이면 회선과 데이터

센터 수준에서 리던던시를 구현할 수 있습니다. 다음은 가상 회선 2개와 서로 다른 패스트커넥트

로케이션 2곳을 사용한 패스트커넥트 연결을 나타낸 것입니다.


그림 11. 패스트커넥트 고가용성 설계

오라클의 패스트커넥트 파트너는 오라클 네트워크에 대한 리던던시 링크를 갖추고 있습니다.

따라서 파트너 고객 역시 파트너 네트워크에 대한 리던던시 링크를 갖추어야 합니다. 이러한

연결은 고객 네트워크와 파트너 네트워크에서 서로 다른 라우터를 통해야 합니다. 가상 회선을

프로비저닝할 때는 다수의 공급자 링크에 프로비저닝하십시오.

예정된 유지관리에 따른 영향 제거

라우터 1개에 대한 유지관리를 실시할 때는 가상 회로를 통해 학습된 라우팅을 바탕으로 BGP

(Border Gateway Protocol) 로컬 선호도가 계속 사용할 라우터에서 더 높도록 구성할 수 있습니다.

BGP 로컬 선호도는 온프레미스 네트워크에서 아웃바운드 트래픽 선호도를 수정하는 데

사용됩니다.

오라클에서 고객 네트워크로 전송되는 트래픽은 BGP AS 조정을 사용해 수정할 수 있습니다.

유지관리가 실행되는 라우터에서는 로컬 BGP AS 번호를 조정하면 됩니다. 이렇게 하면 오라클

클라우드 네트워크가 AS 경로가 짧은 패스트커넥트 가상 회로를 선호하게 됩니다.

BGP 로컬 선호도 수정과 AS 조정을 마친 후에는 라우터의 가상 회선 인터페이스 카운터를

모니터링하여 수신/송신 패킷 카운터 값이 매우 낮은지 확인하십시오. 이때, 링크에는 BGP

프로토콜 트래픽만 남아야 합니다.

리던던시 경로에 대한 연속 테스트

정상적으로 운영할 때는 온프레미스 네트워크와 오라클 클라우드 사이의 가용 경로를 모두

사용하는 것이 좋습니다. 이렇게 하면 장애가 발생하더라도 리던던시 경로가 이미 유효하기

때문입니다. 그 밖에도 액티브/백업 설계의 사용은 장애가 발생하더라도 백업 경로의 유효성을


신뢰한다는 의미입니다. 이러한 이유 때문에 BGP 로컬 선호도와 BGP AS 경로 길이를 동일하게

사용하는 것이 좋습니다.

IPSec VPN과 패스트커넥트 모두 사용

리던던시 계층을 하나 추가하고 싶다면 IPSec VPN과 패스트커넥트를 모두 설정하여 온프레미스

데이터 센터를 Oracle Cloud Infrastructure에 연결할 수 있습니다. IPSec VPN 연결과 패스트커넥트

가상 회선을 동일한 DRG로 설정할 때, IPSec VPN은 정적 라우팅을 사용하지만 패스트커넥트는

BGP를 사용한다는 점에 유의해야 합니다. Oracle Cloud Infrastructure는 VCN의 각 서브넷

라우팅을 패스트커넥트 가상 회선 BGP 세션을 통해 전파하지만, 정적 라우팅이 온프레미스

네트워크에서 전파하는 라우팅과 중첩될 경우에는 기본적인 라우팅 선택 방식을 재정의하여 정적

라우팅을 통한 BGP 라우팅을 선호합니다. 아래의 다이어그램은 이러한 구성을 나타낸 것입니다.

그림 12. IPSec VPN과 패스트커넥트 모두 사용

스토리지 고가용성 설계

Oracle Cloud Infrastructure는 다음과 같은 스토리지 서비스를 제공합니다.

• 블록 볼륨 (Block Volume)

• 오브젝트 스토리지 (Object Storage)

• 파일 스토리지 (File Storage)

Oracle Cloud Infrastructure 블록 볼륨은 블록 스토리지 볼륨을 동적으로 프로비저닝하여 관리할

수 있는 서비스입니다. 필요에 따라 볼륨을 생성, 연결, 이전하여 스토리지 및 어플리케이션

요건을 해결할 수 있습니다. 볼륨을 연결하여 인스턴스에 연결하면 마치 일반 하드 드라이브처럼

사용할 수 있습니다. 또한, 볼륨에 저장된 데이터는 그대로 유지하면서 볼륨을 분리하여 다른


컴퓨트 인스턴스에 연결하는 것도 가능합니다.

Oracle Cloud Infrastructure 오브젝트 스토리지는 인터넷 규모의 고성능 스토리지 플랫폼으로,

안정적이고 비용 효율적인 데이터 내구성을 자랑합니다. 오브젝트 스토리지 (Object Storage)

서비스는 분석 데이터, 리치 콘텐츠 (이미지, 동영상 등) 같은 비정형 데이터를 콘텐츠 유형에

상관없이 무제한으로 저장할 수 있습니다. 이 서비스는 지역 단위로 제공되며, 해당 지역의 모든

가용성 도메인에서 사용할 수 있습니다. 또한, 데이터가 다수의 가용성 도메인에서 여러 스토리지

서버에 저장되어 리던던시를 보장합니다.

Oracle Cloud Infrastructure 파일 스토리지는 내구성과 확장성을 갖춘 엔터프라이즈급 분산

네트워크 파일 시스템을 제공합니다. 파일 스토리지 (File Storage) 파일 시스템은 가상 클라우드

네트워크 (VCN)의 베어메탈, 가상 머신 및 컨테이너 인스턴스에서 연결할 수 있습니다. 또한,

Oracle Cloud Infrastructure 패스트커넥트와 IPSec VPN을 사용하면 VCN 외부에서도 파일

시스템에 액세스할 수 있습니다. 수천 개의 인스턴스로 구성된 대규모 컴퓨트 클러스터일 때는

파일 스토리지를 고성능 공유 스토리지로 사용할 수 있으며, 탄력적인 데이터 보호를 위해

리던던시 스토리지를 제공하기도 합니다.

고가용성과 내구성을 구현하고 싶다면 다음과 같은 스토리지 계층 모범 사례를 권장합니다.

• 오브젝트 스토리지를 사용해 어플리케이션 데이터를 백업합니다. 데이터는 다수의 가용성

도메인에서 여러 스토리지 서버에 저장되어 리던던시를 보장합니다. 또한, 체크섬을

사용해 데이터 무결성을 능동적으로 모니터링하고 손상된 데이터를 탐지해 자동으로

복구합니다. 그 밖에도 데이터 리던던시 손상을 자동으로 탐지해 교정하기 때문에

고객에게 미치는 영향은 전혀 없습니다.

• 블록 볼륨 정책 기반 백업을 사용해 자동 예약 백업을 실행하고, 백업 정책에 따라 백업

파일을 보관합니다. 이렇게 일관적인 데이터 백업은 데이터 규제 준수 및 규제 요건을

충족하는 데 효과적입니다.

• 특정 시점에 블록 볼륨의 직접 디스크-디스크 복사가 필요하다면 블록 볼륨 복제 기능을

사용하는 것이 좋습니다. 볼륨 복제는 쓰기 시 복사 (COW) 또는 원본 볼륨에 대한

의존성이 없다는 점에서 스냅샷과 다릅니다. 관련된 백업은 없습니다. 복제 작업은 즉시

이루어지며, 복제된 볼륨은 복제 작업이 시작되자마자 바로 사용 가능합니다. 복제된

볼륨의 상태가 사용 가능으로 바뀌면 일반 볼륨과 똑같이 연결하여 사용할 수 있습니다.

• 테스트를 거치지 않았거나 신뢰할 수 없는 어플리케이션의 우발적인, 또는 악의적인

수정으로부터 데이터를 보호해야 한다면 블록 볼륨을 읽기 전용 첨부 기능과 함께

사용하십시오. 읽기 전용 첨부 기능은 볼륨을 읽기 전용으로 표시하기 때문에 볼륨

데이터가 변경되지 않습니다. 그 밖에 다수의 컴퓨트 인스턴스가 읽기 전용을 목적으로

동일한 볼륨에 액세스할 때도 읽기 전용 첨부 기능을 사용할 수 있습니다. 예를 들어,

여러 인스턴스가 정적 제품 카탈로그 정보를 고객에게 알려주는 웹 프런트 엔드를 실행할

수도 있습니다.


• 워크로드가 파일 의미 체계와 함께 고가용성 공유 스토리지를 요구하는 동시에 데이터

보호를 위한 내장 암호화와 스냅샷이 필요하다면 파일 스토리지를 사용하십시오. 파일

스토리지는 업계 표준인 NFS (Network File System) 파일 액세스 프로토콜을 사용하기

때문에 수천 개의 컴퓨트 인스턴스에서 동시 액세스가 가능합니다. 또한, 어플리케이션의

성능을 높이고 탄력적으로 데이터를 보호할 수도 있습니다. 그 밖에도 파일 스토리지

서비스는 단일 가용성 도메인의 로컬에서 실행됩니다. 가용성 도메인 내에서 동기식

복제와 고가용성 페일오버를 사용해 데이터의 안전과 가용성을 유지합니다.

• 다수의 가용성 도메인에서 어플리케이션에 고가용성이 필요하다면 블록 볼륨 서비스에

추가로 GlusterFS를 사용하십시오.

• 향후 확장 요건을 고려하여 스토리지 용량을 계획하고 크기를 결정하십시오.

데이터베이스 고가용성 설계

Oracle Cloud Infrastructure 데이터베이스 서비스에서는 오라클 데이터베이스 시스템을 빠르게

시작하여 데이터베이스를 1개 이상 생성할 수 있습니다. 데이터베이스 서비스는 크기부터 가격,

성능에 이르기까지 여러 가지 유형의 DB 시스템을 지원합니다.

엑사데이터 DB 시스템 사용

엑사데이터 DB 시스템은 Oracle Cloud Infrastructure에서 엑사데이터의 이점을 이용할 수 있는

DB 시스템입니다. 컴퓨트 노드와 스토리지 서버가 탑재되는 쿼터 랙, 하프 랙 또는 풀 랙으로

구성되며, 여기에 지연 시간이 낮은 고속 InfiniBand 네트워크와 지능형 엑사데이터 소프트웨어가

추가됩니다. 자동 백업을 구성하거나, 다른 워크로드에 최적화하거나, 수요 증가에 따라 시스템을

확장할 수도 있습니다.

엑사데이터 DB 시스템은 여러 가지 고가용성 기능이 내장되어 있습니다. 온프레미스 엑사데이터

DB 시스템을 사용하는 기존 모범 사례들도 모두 적용됩니다.

2-노드 RAC DB 시스템 사용

Oracle Cloud Infrastructure는 가상 머신 컴퓨트 인스턴스에서 2-노드 RAC DB 시스템 (RAC DB

System)을 제공합니다. 2-노드 RAC DB 시스템은 고가용성 기능이 내장되어 있어서 고가용성을

요구하는 솔루션이라면 2-노드 RAC DB 시스템 사용을 권장합니다.

또한, Oracle Cloud Infrastructure 오브젝트 스토리지를 자동으로 백업하도록 데이터베이스

서비스를 구성할 수 있습니다.


아래의 다이어그램은 2-계층 웹 어플리케이션의 고가용성을 지원하는 2-노드 RAC DB 시스템의

배포를 나타낸 것입니다.

그림 13. 2-계층 웹 어플리케이션의 고가용성을 지원하는 2-노드 RAC DB 시스템

데이터 가드 작업

단일 노드 DB 시스템을 사용하는 솔루션이라면 고가용성을 위해 오라클 데이터 가드 (Oracle

Data Guard)를 사용하도록 권장합니다. 데이터 가드는 엔터프라이즈 데이터의 고가용성, 데이터

보호 및 재해 복구를 보장합니다.

Oracle Cloud Infrastructure 데이터베이스 서비스에서 데이터 가드를 구현하려면 기본 역할 1개와

예비 역할 1개까지, 데이터베이스가 총 2개 필요합니다. 2개의 데이터베이스가 데이터 가드

연결을 구성합니다. 대부분의 어플리케이션은 기본 데이터베이스에 액세스합니다. 예비

데이터베이스는 기본 데이터베이스와 일치하는 트랜잭션 복사본입니다.

가용성과 재해 복구를 개선하려면 예비 데이터베이스의 DB 시스템을 기본 데이터베이스의 DB

시스템과 다른 가용성 도메인에 배치하는 것이 좋습니다. Oracle Cloud Infrastructure 가용성

도메인 사이의 고성능 네트워크에서는 이러한 배포가 가능합니다.


그림 14. 고가용성 데이터베이스 설계를 위한 데이터 가드 사용

데이터 가드는 기본 데이터베이스에서 redo 데이터를 전송해 적용함으로써 예비 데이터베이스를

유지합니다. 이후 기본 데이터베이스에 장애가 발생하면 데이터 가드를 사용해 예비

데이터베이스를 기본 데이터베이스로 전환할 수 있습니다.

데이터 가드를 사용할 경우 고가용성 지원을 위해 다음과 같은 작업이 가능합니다.

• 역할 전환: 기본 데이터베이스 역할과 예비 데이터베이스 역할을 서로 바꿉니다. 각

데이터베이스는 새로운 역할에서도 데이터 가드 연결에 계속해서 참여합니다. 역할 전환이

일어나더라도 데이터 손실은 전혀 없습니다. 또한, 기본 데이터베이스에서 예정된

유지관리를 실행하기 전에 먼저 역할을 전환할 수도 있습니다.

• 페일오버: 기존 기본 데이터베이스가 장애를 일으키거나 통신이 안 될 경우 예비

데이터베이스를 기본 역할로 전환합니다. Maximum Performance 보호 모드로 사용할

경우에는 페일오버로 인해 일부 데이터 손실이 발생할 수 있습니다.

• 상태 복구: 데이터베이스를 데이터 가드 연결을 구성하는 예비 역할 상태로 복구합니다.

상태 복구 명령을 사용하면 장애 원인을 복구하여 장애를 일으켰던 데이터베이스를 다시

사용할 수 있습니다.

자동 CPU 및 스토리지 확장

솔루션에 고가용성을 구현하려면 먼저 DB 시스템의 용량이 충분해야 합니다. Oracle Cloud

Infrastructure에서의 데이터베이스 서비스는 CPU 코어 또는 데이터베이스 스토리지를 다양한

데이터베이스 서비스 Shape에 따라 동적으로 확장할 수 있습니다.


베어메탈 컴퓨트 인스턴스 기반 DB 시스템이라면 최소 CPU 코어 수부터 시작해 필요에 따라

CPU 코어 수를 동적으로 늘리는 것이 좋습니다.

가상 머신 컴퓨트 인스턴스 기반 DB 시스템이라면 스토리지 크기를 동적으로 늘릴 수 있습니다.

결론

배포를 계획할 때는 무엇보다 가용성 계획이 중요합니다. 본 참조 아키텍처 백서는 컴퓨트,

네트워크, 스토리지, 데이터베이스 계층 등 Oracle Cloud Infrastructure에서 고가용성 (HA)

솔루션을 설계하는 데 도움이 될 수 있는 지침과 함께 다음과 같은 계획을 위한 몇 가지 모범

사례도 제공하고 있습니다.

• 리던던시를 통해 단일 장애점을 제거합니다.

• 어플리케이션 또는 솔루션 구성요소를 다수의 지역에, 단일 지역 내 다수의 가용성

도메인에, 또는 단일 가용성 도메인 내 다수의 폴트 도메인에 배포합니다.

• 향후 확장을 염두에 두고 설계하여 리소스 용량을 충분히 확보합니다.

• 오라클 데이터베이스 데이터 가드와 동적 확장 기능을 이용합니다.

• 어플리케이션 데이터를 여러 가용성 도메인에 복제합니다.

• 문제 해결 및 페일오버 프로세스를 자동화합니다.

Oracle Cloud Infrastructure는 새로운 기능을 끊임없이 개발하고 있습니다. 최신 정보, 문서 및

교육 프로그램은 https://cloud.oracle.com에서 확인할 수 있습니다.


오라클 본사

500 Oracle Parkway

Redwood Shores, CA 94065, USA

문의처

전화: +1.650.506.7000

팩스: +1.650.506.7200

소셜 계정

blogs.oracle.com/oracle

facebook.com/oracle

twitter.com/oracle

oracle.com

통합 클라우드 어플리케이션 및 플랫폼 서비스

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. 본 문서는 정보의 목적으로만 제공되며 일체의 내용은 고지 없이

변경될 수 있습니다. 본 문서는 오류에 대해 책임지지 않으며 특정 목적에 대한 적격성 및 적합성과 관련된 묵시적 보증 및 계약

조건을 포함해서 명시적, 묵시적 기타 모든 보증 또는 계약 조건에 의해 구속 받지 않습니다. 오라클은 본 문서와 관련해 어떠한

법적 책임도 지지 않으며, 본 문서로 인해 직간접적인 어떠한 계약 구속력도 발생하지 않습니다. 본 문서는 오라클의 사전 서면 승인

없이는 어떠한 형식이나 수단 (전자적 또는 기계적) 또는 목적으로도 복제하거나 배포할 수 없습니다.

오라클 (Oracle) 및 자바 (Java)는 오라클 및 그 계열사의 등록 상표입니다. 기타 명칭은 해당 소유업체의 상표입니다.

Intel 및 Intel Xeon은 Intel Corporation의 등록 상표 또는 상표입니다. 모든 SPARC 상표는 사용 허가를 받아 사용해야 하며 SPARC

International, Inc.의 등록 상표 또는 상표입니다. AMD, Opteron, AMD 로고 및 AMD Opteron 로고는 Advanced Micro Devices의 등록

상표 또는 상표입니다. UNIX는 The Open Group의 등록 상표입니다. 1018

Oracle Cloud Infrastructure의 고가용성 아키텍처 배포 모범 사례

2018년 10월

작성자: Changbin Gong, Adeel Amin

oracle cloud infrastructure의 고가용성 아키텍처 배포 범 사례 · 2019-12-10 · 2 |...

Documents