Oracle은 중요한 서비스, 지속적 가용 서비스, 단일 위치 서비스 등 다양한 등급의 서비스를 구분하나요?

아니요. 구분하지 않습니다. 대신, Oracle은 종속성 수준, 가용성 범위, 데이터 평면 vs 제어 평면을 기준으로 서비스를 분류합니다. 이 범주는 가용성, 지속성, 성능 및 편리성 사이에서 다양하고 유용한 절충 효과를 제공하도록 설계되었습니다.

종속성 수준

종속성 블록 다이어그램에서는 이러한 수준을 레이어 또는 계층으로 간주할 수 있습니다. 각 레이어는 아래에 나열된 레이어에만 종속될 수 있습니다.

아래에서부터 위로:

• 코어 서비스: 이 서비스는 Oracle Cloud Infrastructure의 근간을 형성합니다. 여기에는 ID 및 접근 관리(IAM), 키 관리, 네트워킹, 컴퓨트, 블록 볼륨, 오브젝트 스토리지, 텔레메트리 및 다수의 공유 내부 서비스가 포함됩니다. 각 서비스는 서로에게 조차 최소한으로만 의존하도록 설계되었습니다. (종속성에 대한 자세한 내용은 본 문서의 뒷부분을 참고하세요).
• IaaS: 이 레이어는 코어를 기반으로 구축된 인프라 수준의 추가 기능을 제공합니다. 이 레이어에 포함된 서비스에는 Kubernetes용 파일 스토리지, 데이터베이스 및 컨테이너 엔진이 포함됩니다.
• SaaS: 이 레이어는 하위 레이어를 기반으로 하는 풍부한 서비스형 소프트웨어입니다.

가용성 범위

서비스 가용성 및 내구성 목표를 달성하기 위해, 각 서비스에 대해 다음 가용성 범위 중 하나가 선택됩니다:

• 가용성 도메인 로컬: 각 가용성 도메인에는 서비스의 독립 인스턴스 하나가 포함됩니다. 이러한 서비스는 동일한 가용성 도메인 내 복제본 간의 동기 복제를 사용하여 저장된 데이터에 높은 내구성을 보장합니다(자세한 내용은 본 문서 뒷부분의 결하 도메인 섹션을 참고하세요). 이러한 서비스는 서비스의 성격에 따라 가용성 도메인 내 세 번째 또는 그 이상의 인프라 중단을 감당할 수 있습니다. 가용성 도메인 로컬 서비스는 가용성 도메인 내 결함 격리 및 성능 격리의 논리적 그룹인 두 종류의 논리적 데이터 센터를 사용하여 이 수준의 내결함성을 달성합니다. 자세한 내용은 본 문서 뒷부분의 결함 도메인 및 서비스 셀에 대한 섹션을 참고하세요. 마지막으로 가용성 도메인이 다른 가용성 도메인과 통신할 수 없더라도 이러한 서비스는 계속 정상적으로 작동할 수 있습니다. 결과적으로 이 서비스는 다른 가용성 도메인의 손실 또는 해당 리전 내 광범위한 네트워크의 완전한 중단을 감당할 수 있습니다.
• 리전별 다중 가용성 도메인: 다중 가용성 도메인을 갖춘 각 리전에는 해당 리전의 각 가용성 도메인 구성 요소와 함께 서비스의 독립 인스턴스가 하나씩 포함됩니다. 이 서비스는 동일한 리전 내 다중 가용성 도메인에 동기 복제를 사용하여 저장된 데이터에 높은 내구성을 보장합니다. 또한 해당 리전의 단일 가용성 도메인 중단 또는 통신 불능을 감당할 수 있습니다.
• 리전별 단일 가용성 도메인: 리전에 단일 가용성 도메인만 포함되어 있는 경우, 리전별 서비스의 관찰 가능성 특성은 앞서 설명한 가용성 도메인 로컬 서비스와 동일한 수준으로 제공됩니다. 가용성 도메인 로컬 서비스와 단일 가용성 도메인 리전별 서비스 간 구별은 하나 이상의 가용성 도메인을 추가하여 단일 가용성 도메인 영역이 확장되는 경우에만 의미가 있습니다. 이러한 상황이 발생하면 각 리전별 서비스가 자동으로 확장되어 서비스의 단일 인스턴스를 유지하면서 새로운 가용성 도메인을 적절하게 사용합니다. 예를 들어 오브젝트 스토리지 데이터 평면이 확장되면 추가 가용성 도메인을 사용하여 기존 데이터의 내구성을 향상시킬 수 있습니다. 그에 비해 가용성 도메인 로컬 서비스의 경우, 새 가용성 도메인은 각 가용성 도메인 로컬 서비스별 고유하고 새로운 별도의 인스턴스를 수신합니다.
• 리전 전체에 분산: Oracle Cloud Infrastructure의 기본 원칙은 각 리전이 다른 리전과 가급적 독립적으로 운영되어야 한다는 것입니다. 가급적이라는 말은 여러 리전이 리전 간 백본 네트워크와 같은 최소한의 인프라를 반드시 공유해야 한다는 뜻입니다. 그렇지 않은 경우 Oracle은 투명한 고가용성 또는 페일오버와 같이 여러 리전에 동시에 문제를 일으킬 수 있는, 리전 간 밀접한 결합 매커니즘을 구축하지 않습니다. 대신, 느슨한 결합으로 리전 전체에 서비스를 분산시키기 위한 두 가지 매커니즘을 제공합니다.
  • 재해 복구(DR): 고객이 DR 기능을 갖춘 시스템을 구축할 수 있도록 돕는 것은 Oracle의 클라우드 관련 접근 및 투자 정책의 근간입니다. 몇몇 핵심 서비스는 이미 DR 매커니즘을 제공합니다. 예를 들어, 블록 볼륨 리전 간 백업, 오브젝트 스토리지 리전 간 복사가 있습니다. Oracle의 모든 서비스는 DR 기능을 로드맵 내 우선순위가 높은 항목으로 책정하고 있습니다.
  • 리전 간 구독: Oracle은 현재 IAM 데이터에 대해서만 리전 간 구독을 제공합니다. 개념적으로 IAM 데이터는 글로벌 범위를 가지고 있습니다. 고객은 여러 리전을 구독(수신 동의)할 수 있으며, 그러면 Oracle에서 관련 IAM 데이터 및 후속 업데이트를 지정��� 리전에 자동으로 복제합니다. 밀접 결합을 피하기 위한 복제는 비동기식이지만, 결국 일관성이 있습니다. 고객은 자신이 지정한 '홈' 리전에서 IAM 데이터를 수정합니다. 현재 어떤 이유로든 홈 리전 사용이 불가능하거나 부적합한 경우 다른 리전을 지명할 수 있습니다.

제어 평면 vs 데이터 평면

서비스의 데이터 평면은 애플리케이션에서 사용될 서비스의 기능을 구현하는 데이터 처리 인터페이스 및 구성요소의 모음입니다. 예를 들어 가상 클라우드 네트워크(VCN) 데이터 평면에는 네트워크 패킷 처리 시스템, 가상화된 라우터 및 게이트웨이가 포함되며 블록 볼륨 데이터 평면에는 볼륨 데이터에 대한 iSCSI 프로토콜 구현과 복제된 내결함성 스토리지 시스템이 포함됩니다.

서비스의 제어 평면은 다음 작업을 담당하는 API 및 구성요소의 집합입니다:

• 고객의 프로비저닝, 재구성, 수평 확장/축소 또는 리소스 종료 요청 처리
• 대규모 플리트의 자동 패치를 빠르고 안전하게 수행
• 실패, 성능 저하 또는 잘못 구성된 리소스 감지
• 자동 복구 수행 또는 운영자에게 지원 요청
• 다른 제어 평면과의 협업(예: 컴퓨트, VCN, 블록 스토리지는 Launch Instance 동안 연결됨)
• 사용되지 않은 용량 관리
• 수동 작업(예: 새로운 장비의 도착, 물리적 수리 및 유지보수)과의 조정
• 운영 가시성 및 제어 기능 제공

Oracle은 서비스의 회복 탄력성과 지속적 가용성을 어떻게 보장하나요?

모든 유형의 서비스에 회복 탄력성과 가용성을 제공하기 위해 Oracle은 동일한 엔지니어링 원칙을 적용합니다. 내결함성이 있고 확장 가능한 분산 시스템을 구축하기 위한 근본적인 엔지니어링 과제는 모든 유형의 서비스에 동일하기 때문입니다.

회복 탄력성과 지속적 가용성을 달성하려면 클라우드 규모 시스템에서 성능 저하, 처리되지 않은 오류와 같은 사용 불가 문제의 원인을 모두 파악하고 처리해야 합니다. 그 사유는 수도 없이 많기 때문에, Oracle은 이들을 근본적 특성에 따라 범주로 분류합니다

기존에는 엔터프라이즈 IT 시스템에 대한 가용성 분석은 하드웨어 장애 범주에 중점을 두었습니다. 그러나 클라우드 시스템의 경우 하드웨어 실패는 비교적 사소하고, 잘 파악된 문제입니다. 이제 대부분의 단일 하드웨어 장애 지점은 쉽게 피하거나 완화할 수 있습니다. 예를 들어 랙에 이중 전원 공급 장치와 그에 연결된 전원 분산 장치를 두는 방법도 있으며, 여러 구성요소는 핫 스왑 가능합니다. 자연 재해 등으로 인해 상당한 규모의 하드웨어 장애와 손실이 발생할 수 있습니다. 그러나 Oracle의 경험과 다른 클라우드 공급업체의 사후 퍼블릭 보고서에 따르면 전체 데이터 센터의 장애나 손실은 다른 비가용성 원인에 비해 매우 드뭅니다. 대규모 하드웨어 장애도 물론 처리해야 하지만(예: 재해 복구 및 기타 매커니즘을 통해) 만연한 가용성 문제와는 거리가 멉니다.

클라우드 규모 시스템 관련 사용 불가의 주요 원인은 다음과 같습니다:

• 소프트웨어 버그
• 구성 오류
• 인간 운영자의 실수
  참고: 업계로부터 얻은 주요 교훈은, 이 세 가지 형태의 사용자 오류가 지금까지 사용 불가의 가장 큰 원인이라는 것입니다. 도구, 자동화 및 교육을 통해 오류 발생 빈도를 줄일 수는 있지만 완전히 없앨 수는 없습니다. 따라서 시스템의 아키텍처, 설계 및 구현에 있어 주요 문제로 다루어야 합니다.
• 어떤 이유에서든 용인할 수 없는 성능(대기시간 또는 처리량) 편차에는 다음이 포함됩니다:
  • 다중 테넌트 노이지 네이버(QoS 방식의 실패)
  • 유용한 작업을 계속하면서 (우발적이거나 악의적인)오버로드를 효과적으로 제거할 수 없는 경우
  • 분산 스래시, 메시지 폭풍, 재시도 폭풍, 기타 비용이 많이 드는 '긴급' 상호작용
  • 전원주기, 특히 여러 시스템의 동시 전원주기 이후 콜드 쇼크(캐시 비우기)
  • 시스템 확장 시 오버헤드(예: 재샤딩)
• 앞서 발생한 이슈의 '폭발 반경'(영향을 받은 고객 및 시스템의 수)을 제한하지 못함

이러한 당면 과제는 클라우드 규모 분산 시스템의 '물리학 법칙'을 따르는 보편적인 과제입니다.

앞의 각 범주에 대해 Oracle은 검증된 엔지니어링 전략을 사용하여 문제를 처리합니다. 그 중 가장 중요한 것은 다음과 같습니다:

• 아키텍처 및 시스템 설계 원칙
• 새로운 아키텍처 개념(일반적으로 이 원칙 적용으로 인해 발생)
• 서비스 엔지니어링 절차

아키텍처 및 시스템 설계 원칙

다양한 원칙이 있지만 회복 탄력성 및 가용성과 가장 크게 관련된 항목을 중점적으로 다루겠습니다.

복구 지향 컴퓨팅

상대적으로 국지적인 영향을 미치는 운영자 실수와 소프트웨어 버그를 처리하기 위해 Oracle은 복구 지향 컴퓨팅¹ 원칙을 따릅니다. 간단히 말해, 문제가 발생하지 않으리라고 보장하기보다는(테스트 불가능) 테스트 가능한 방식으로 드러나지 않게 문제를 처리하는 데 초점을 맞추고 있다는 뜻입니다. Oracle은 특히 문제의 평균 포착 시간, 평균 진단 시간, 평균 완화 시간을 한데 합친 개념인 평균 복구 시간(Mean Time to Recovery, MTTR)을 최소화하는 데 중점을 두고 있습니다.

당사의 목표는 사용자들이 발생한 문제로 인한 불편을 채 겪기도 전에 빠르 문제를 해결하는 것입니다. 다음과 같은 특징은 이러한 목표를 달성하는 데 도움이 됩니다:

• 코드에 사용하는 광범위한 검증과 모든 수준에 걸친 ���동적인 모니터링과 경보를 통해 운영자 실수 및 버그 증상을 신속하게 자동으로 감지합니다.
• 느슨하게 결합된 여러 세분화된 별도의 격리 단위(스레드, 프로세스, 파이버, 상태 머신 등)에 기능을 패키지화하여 제공하기 때문에 오염될 수 있는 메모리를 직접 공유하지 않습니다.
• 운영자에 의한 버그 또는 오류의 증상이 감지되면 가능한 신속하게 격리의 포함 단위를 자동으로 재시작합니다. 재시작은 테스트를 통과한 상태와 불변성을 복원하려는 시도이기 때문에, 임의의 장애로부터 복구를 시도하는 실용적인 방법입니다.
• FGAC(상세한 격리 수준)에서 복구가 작동하지 않는 경우(예: 해당 수준에서 assertion이 너무 자주 지속되고 스핀 충돌을 유발) 그 다음으로 큰 단위(프로세스, 런타임, 호스트, 논리적 데이터 센터, 운영자 페이징)로 에스컬레이션합니다.
• 불량 커밋을 신속하게 식별 및 취소하기 위해 모든 영구 상태와 구성의 버전 지정 등 '시스템 차원의 실행 취소'를 실행하는 매커니즘을 구축합니다.

문제의 영향 최소화

광범위한 영향을 미칠 수 있는 오류와 버그를 처리하기 위해 모든 문제의 '폭발 반경'을 최소화하는 매커니즘을 구성합니다. 즉, 특히 까다로운 멀티테넌트 '노이지 네이버' 문제, 오버로드, 용량 감소, 분산 스래시 등 문제의 영향을 받는 고객, 시스템 또는 리소스의 수를 최소화하는 데 집중한다는 뜻입니다. 다양한 격리 경계 및 변경 관리 관행을 사용하여 이 목표를 달성합니다(다음 섹션 참고).

설계 원칙에서 비롯되는 아키텍처 개념

다양한 개념이 있지만, 폭발 반경의 제한 개념을 중점적으로 다루겠습니다.

Oracle의 퍼블릭 API에 명시된 배포 개념: 리전, 가용성 도메인 및 결함 도메인

결함 도메인은 비교적 새로운 개념이기 때문에 좀 더 자세히 다루겠습니다.

결함 도메인은 시스템이 실제로 변경 중일 때 발생하는 문제(예: 배포, 패치, 하이퍼바이저 재시작, 물리적 유지보수)의 폭발 반경을 제한하는 데 사용됩니다.

이로 인해 주어진 가용성 도메인 내의 최대 하나의 결함 도메인에 포함된 리소스가 언제든 변경될 수 있습니다. 변경 프로세스에 문제가 발생하면 해당 결함 도메인의 일부 또는 모든 리소스를 잠시 동안 사용하지 못할 수 있지만 가용성 도메인의 다른 결함 도메인은 영향을 받지 않습니다. 단일 가용성 도메인 내에서 높은 가용성으로 쿼럼 기반 복제 시스템(예: Oracle Data Guard)이 호스트될 수 있도록, 각 가용성 도메인에는 최소 3개의 결함 도메인이 포함됩니다.

결과적으로 소프트웨어 버그, 구성 오류, 운영자 실수, 변경 절차 중에 발생하는 성능 문제 등 흔히 발생하는 가용성 문제의 범주에 대해 각 결함 도메인은 가용성 도메인 내에서 별도의 논리적 데이터 센터로 작동합니다.

결함 도메인은 몇 가지 국지적인 하드웨어 장애도 방지합니다. 결함 도메인의 속성상, 서로 다른 결함 도메인에 배포된 리소스는 해당 가용성 도메인 내에서 발생할 수 있는 단일 하드웨어 장애 지점을 공유하지 않도록 최대한 보장합니다. 예를 들어, 서로 다른 결함 도메인의 리소스는 동일한 TOR(Top-of-rack) 네트워크 스위치를 공유하지 않습니다. 스위치의 표준 설계에 중복성이 없기 때문입니다.

그러나 결함 도메인이 하드웨어 또는 물리적 환경의 문제를 방지하는 기능은 로컬 수준에서 중지됩니다. 가용성 도메인 및 영역과 반대로 결함 도메인은 인프라의 대규모 물리적 격리를 제공하지 않습니다. 드문 경우지만 자연 재해 또는 가용성 도메인 전체 인프라 오류가 발생하면 여러 결함 도메인의 리소스가 동시에 영향을 받을 수 있습니다.

Oracle 내부 서비스는 고객이 사용하는 것과 동일한 방식으로 결함 도메인을 사용합니다. 예를 들어 블록 볼륨, 오브젝트 스토리지, 파일 스토리지 서비스는 3개의 개별 결함 도메인에 데이터 복제본을 저장합니다. 모든 제어 평면 및 데이터 평면의 모든 구성 요소는 3개 결함 도메인(또는 다중 가용성 도메인 영역, 여러 가용성 도메인)에서 호스팅됩니다.

서비스 셀

서비스 셀은 시스템이 실제로 변경되지 않는 경우에도 발생하는 문제의 폭발 반경을 제한하는 데 사용됩니다. 다중 테넌트 클라우드 시스템의 워크로드가 언제든 극단적인 방식으로 변경될 수 있고, 대규모 분산 시스템에서 언제든 복잡한 대규모 부분 실패가 발생할 수 있기 때문에 이러한 문제가 발생할 수 있습니다. 이러한 시나리오는 미묘한 숨겨진 버그 또는 새로운 성능 문제를 유발할 수 있습니다.

또한 서비스 셀은 시스템이 활발하게 변경될 때 드물지만 까다로운 일부 시나리오에서 폭발 반경을 제한합니다. 대표적인 예로, 개별 결함 도메인에 대한 배포가 성공적인 것처럼 보이는 경우에도(오류 또는 성능 변화 없음) 두 번째 또는 마지막 결함 도메인이 업데이트되는 즉시(운영 워크로드를 지원하는 전체 클라우드 규모) 시스템 내부의 새로운 상호작용이 성능 문제를 야기할 수 있습니다.

서비스 셀은 Oracle Cloud API 또는 SDK에서 명시적으로 명명된 개념이 아니라 아키텍처 패턴입니다. 모든 멀티테넌트 시스템은 이 아키텍처 패턴을 사용할 수 있으며, 클라우드 플랫폼의 특별한 지원이 필요하지 않습니다.

서비스 셀은 다음과 같은 방식으로 작동합니다:

• 각 서비스 인스턴스(예: 특정 영역 또는 가용성 도메인 로컬 서비스의 특정 가용성 도메인에서)는 서비스 소프트웨어 스택의 여러 개별 배포로 구성됩니다. 각각의 개별 배포를 셀이라고 합니다. 각 셀은 실제 필요한 만큼 자체 인프라에서 호스트됩니다. 최소 규모의 셀은 호스트 또는 VM을 공유하지 않습니다.
• 서비스는 각 가용성 도메인 또는 리전에서 소수의 셀로 시작될 수 있습니다. 증가하는 수요에 따라 서비스 규모가 커지는 경우, 더 많은 셀이 추가되어 문제 발생 시 폭발 반경 크기를 제한합니다. 대규모 인기 서비스는 많은 셀을 보유하고 있을 수 있습니다. 즉, 셀은 별도의 호스팅 환경(리소스 격리를 위한 별도의 섬들)으로 고객 워크로드의 n-to-m 다중화를 제공합니다. 셀에는 결함 도메인에 존재하는 것과 같은 명백한 관계차수가 없습니다. (앞에서 언급한 대로 쿼럼 기반 복제 시스템을 단일 가용성 도메인에서 높은 가용성으로 호스팅하기 위한 결함 도메인의 관계차수는 가용성 도메인 하나당 3개입니다.)
• 고객 워크로드의 각 '자연 단위'는 특정 셀에 할당됩니다. '자연 단위'의 정의는 특정 서비스의 성격에 달려 있습니다. 예를 들어 내부적으로 공유되는 워크플로 서비스(나중에 설명)의 경우 자연 단위는 '특정 제어 평면을 위한 가용성 도메인 또는 리전 내 모든 워크플로'일 수 있습니다.
• 각 셀 그룹 앞에는 셀 엔드포인트를 찾기 위한 최소 경로 지정 계층 또는 API가 있습니다. 예를 들어 스트리밍/메시징 시스템에는 특정 토픽에 대한 현재 데이터 평면 엔드포인트를 검색하는 API가 있으며 내부 메타데이터 저장소에는 셀당 별도의 엔드포인트가 있습니다. 그러나 다른 셀 기반 서비스들은 단일 데이터 평면 엔드포인트와 공유 라우팅 레이어를 보유합니다. 라우팅 레이어는 여러 셀이 상호 관련된 장애를 일으킬 수 있는 잠재적 원인이지만, 라우팅 레이어를 매우 단순하고 예측 가능하며 성능이 뛰어난(비싼 작업이 아님) 상태로 유지하는 동시에, 풍부한 헤드룸 용량과 정교한 QoS 쿼터 및 스로틀링 매커니즘으로 프로비저닝함으로써 보완할 수 있습니다.
• 서비스 소유자는 필요에 따라 한 셀에서 다른 셀로 워크로드를 이동할 수 있습니다. 다음은 몇 가지 예제 시나리오입니다:
  • 셀의 다른 사용자가 영향을 받지 않도록 대용량 워크로드를 이동하여 멀티테넌트 '하드웨어 공유' 문제를 방지하고자 합니다.
  • 분산 서비스 거부 공격 등으로 인한 과부하 또는 전압 저하를 복구하는 데 도움을 주고자 합니다. 이러한 공격으로부터 시스템을 보호하기 위한 할당량 및 스로틀링 매커니즘이 마련되어 있지만, 현재 할당량이나 조절 시스템에서는 이해하기 힘든 극단적이고 특정한 사용 사례(API, 접근 패턴)가 가끔 발생합니다. 셀은 단기적인 방어를 위한 매커니즘을 제공합니다.
  • 중요한 워크로드를 여러 셀로 분리하여 상관관계가 있는 장애가 발생할 확률을 크게 줄이고자 합니다. 예를 들어, 컨트롤 평면에 대한 내부 공유 워크플로의 경우 '중요한 핵심' 제어 평면(예: 플랫폼, 컴퓨트, 네트워킹 및 블록 볼륨)은 서로 다른 셀에 할당되므로 셀이 사용되지 않았거나 동일한 셀에 할당되었을 경우와 비교하여 실패 상관관계가 훨씬 적습니다.
    참고: 이처럼 셀을 사용하면 탄력적인 애플리케이션을 구축하기 위해 고객이 서비스의 내부 종속성을 고려할 필요가 없습니다. 물론 종속성 그래프를 고려하는 것도 좋은 방법이지만(본문 뒷부분에 자세히 서술), 비상관화 매커니즘이 이미 활성화되어 있는 경우 사용할 필요성이 적습니다.

결과적으로 각 서비스 셀은 단일 가용성 도메인 또는 영역 내에서 또 하나의 '논리적 데이터 센터', 즉 성능 격리 및 결함 격리의 논리적 그룹입니다.

요컨대 서비스 셀과 결함 도메인은 다음과 같은 방식으로 상호 보완합니다:

• 결함 도메인은 시스템이 실제로 변경되는 동안 문제를 방지합니다.
• 서비스 셀은 시스템이 실제로 변경 중이든 그렇지 않든, 잠재적으로 심각한 문제를 겪을 때 폭발 반경을 제한합니다.

Oracle은 결함 도메인 및 서비스 셀의 속성을 단일화된 전략으로 결합하여 배포 및 패치를 수행합니다.

서비스 엔지니어링 절차

테스트 및 운영 탁월성은 모두 클라우드 시스템의 안정성에 중요하기 때문에 여러 엔지니어링 절차가 필요합니다. 다음은 앞 섹션에서 언급한 개념을 활용하는 보다 중요한 항목들입니다:

• Oracle은 서비스를 점진적으로 배포하며, 각 단계마다 꼼꼼한 검증을 거칩니다. 또한 예상치 못한 일이 발생할 경우 반사 롤백을 수행합니다. 구체적인 프로세스는 다음과 같습니다:
  • 각 가용성 도메인에서는 한 번에 하나의 서비스 셀에 배포합니다. 각 셀에 대해 결함 도메인을 한 번에 하나씩 배포하며, 이를 해당 셀에 대한 결함 도메인 배포 작업이 완료될 때까지 계속합니다. 그런 다음 가용성 도메인의 다음 셀에 대한 작업을 진행합니다.
  • 배포의 각 단계 마지막에는(즉, 각 결함 도메인 및 셀 작업 완료 후에는) 변경 사항이 의도한 대로 적용되었는지, 즉, 성능 저하가 발생하였거나 대상 셀의 내/외부에 새로운 오류를 추가하지는 않았는지 여부를 확인합니다. 올바르지 않거나 예상치 않은 항목이 관찰되면 변경 사항을 반사적으로 롤백합니다. Oracle은 영구 상태 또는 스키마에 영향을 미치는 변경을 포함하여 롤백 절차의 준비 및 테스트(자동 테스트 포함)에 중점을 둡니다.
  • 이런 식으로 각 영역마다 한 번에 하나의 가용성 도메인 변경을 배포합니다. Oracle은 고객이 기본 및 재해 복구 사이트에 사용 중일 수 있는 리전 쌍을 동시에 수정하지 않는 방식으로 영역의 모든 리전에 배포합니다.
• Oracle은 정기적으로 오류 처리 매커니즘 및 기타 방어 조치가 예상대로 작동하는지 검증하고, 문제가 커져 악화되지 않게 방지합니다. 이러한 테스트를 수행하지 않으면 오류 처리 매커니즘(재시도, 충돌 복구 알고리즘, 상태 머신 재구성 알고리즘)에 버그가 발생하거나, 큰 비용이 들거나, 예기치 못한 방식으로 상호작용하여 분산 스래시 또는 기타 심각한 성능 문제로 이어지기 쉽습니다.
• 앞서 설명한 것처럼 Oracle은 영구 상태 및 스키마를 포함하여 마지막으로 알려진 정상 소프트웨어와 구성으로 신속하고 안전하게 롤백할 수 있는지 확인합니다.

여러 가용성 도메인이 포함된 Oracle 리전에서는 모든 중요 서비스가 가용성 도메인에 분산되어 있나요?

네. 각 리전에서 모든 가용성 도메인은 동일한 서비스 집합을 제공합니다.

Oracle과 고객들이 주요 서비스가 단일 논리적 데이터 센터에 의존하지 않도록 하기 위해 취하는 방법은 무엇인가요?

단일 가용성 도메인 리전에서 고객은 결함 도메인(그룹 간 장애 모드를 비상관화한 논리적 그룹)을 사용하여 개별 '논리적 데이터 센터'의 속성을 대부분 획득할 수 있습니다. 고객은 재해 복구(DR)를 위해 여러 리전을 사용할 수도 있습니다.

다중 가용성 도메인 리전에서도 고객은 동일한 방식으로 결함 도메인을 사용할 수 있습니다. 또한 고객은 가용성 도메인 로컬 서비스, 가용성 도메인 간 복구 기능(예: Data Guard와 DBaaS) 및 리전 서비스(오브젝트 스토리지, 스트리밍)를 결합하여 상위 수준 '논리적 데이터 센터'(가용성 도메인)에 걸쳐 완전한 HA를 달성할 수도 있습니다. 마지막으로, 고객은 DR을 위해 여러 리전을 사용할 수도 있습니다.

모든 경우 고객은 서비스 셀이라는 개념을 사용하여 분산 스래시와 같은 가장 심각한 문제조차도 더 효과적으로 격리할 수 있습니다.

Oracle은 어떻게 중요한 고객 서비스의 일시적 사용 중단 없이 유지 관리 작업을 수행하나요?

Oracle은 결함 도메인, 서비스 셀, 그리고 단계별 배포 및 검증을 위한 운영 절차를 통해 이를 달성합니다. 본 문서의 앞부분을 참고하세요.

고가용성 달성을 위해 여러 논리적 데이터 센터에 서버리스 플랫폼 서비스를 배포할 수 있나요?

네. 복원성 및 지속적인 가용성을 보장하기 위해 결함 격리 및 성능 격리를 구분한 별도 논리적 그룹인 여러 논리적 데이터 센터에 모든 범주 서비스가 배포됩니다.

회복 탄력성이 기본 구성이 아닌 경우 다중 논리적 데이터 센터 배치(예: 다중 가용성 도메인 또는 리전 간 구성)를 고객이 선택할 수 있나요?

Oracle은 단일 가용성 도메인 영역에서 '다중 논리적 데이터 센터'의 매커니즘으로 결함 도메인을 제공합니다. 자세한 내용은 본 문서의 다른 부분에서 확인할 수 있습니다.

다중 가용성 도메인 영역에서 동기적으로 복제된 데이터의 물리적 내구성을 더욱 높여주는 서비스 및 기능을 제공합니다(리전의 가용성 도메인 간 거리와 빛의 속도 덕분에 적당한 성능과 비용 가능).

여러 리전에 걸친 자동 HA 또는 페일오버 매커니즘을 제공하지 않습니다. 리전 간에 긴밀한 결합 관계가 생성되고 여러 리전에서 동시에 문제가 발생할 위험이 있기 때문입니다. 그 대신, 리전 간 다양한 형식의 비동기 복제를 지원하고 비동기 복제 및 백업 등의 기능을 지속적으로 업데이트하여 여러 리전에 걸친 재해 복구를 보장합니다.

Oracle은 다양한 인프라와 플랫폼 서비스 간의 내부 종속성으로 인해 발생하는 애플리케이션의 상관관계 장애를 방지할 수 있도록 어떤 지원을 제공하나요?

이는 복잡한 질문이므로, 그 의미를 분명히 하기 위해 내포된 내용들을 다음과 같이 풀어 써 보겠습니다.

• 고객이 두 개의 Oracle 서비스(서비스 A 및 서비스 B)를 사용 중인데 두 서비스 중 하나가 중단될 경우, 회복 탄력성이 높은 애플리케이션을 구축하려는 고객은 내부적으로 서비스 A가 서비스 B에 종속되는지 여부를 알아야 할까요? 내부 종속성은 상당한 수준의 상관관계가 있는 장애를 일으키나요? 이 경우 고객은 애플리케이션 레벨에서 자체 복원성 매커니즘을 구축할 때 서비스 A와 서비스 B를 다른 용도로 사용할지, 그 대신 추가 사례에 대해 관련이 없는 서비스 C를 풀인할지 여부를 결정하기 위해 이러한 내부 종속성에 대해 알아야 할 수 있습니다.
• 고객이 Oracle 서비스의 상관관계가 있는 장애로부터 스스로를 방어하는 가장 효과적인 방법은 무엇인가요?

두 가지 답을 드릴 수 있습니다.

아키텍처 원칙

Oracle은 종속적인 서비스 전반에 걸쳐 관련된 장애를 크게 줄이는 아키텍처 원칙을 사용합니다. 일부 경우 이 기술은 가용성 SLA(Service Level Agreement)에 부합하는 선에서 무시할 수 있는 상관관계 장애가 발생할 확률을 낮춥니다.

특히 이 문서의 앞부분에서 설명한 대로 서비스 셀을 사용합니다. 내부 서비스 A가 종속성 중 하나인 서비스 B의 문제로 영향을 받는 경우 서비스 B의 문제는 단일 셀로 제한될 수 있으므로 셀은 이 문제 해결에 유용합니다. 서비스 B를 사용하는 다른 서비스, 고객의 자체 애플리케이션은 영향을 받지 않는 다른 셀을 사용 중일 수 있습니다. 이는 변화하는(증가하는) 숨겨진 내부 매개변수인 셀 개수에 따라 달라지는 확률적 인수이므로 서비스 A 및 B의 독립형 서비스 SLA 이상으로는 정량화 또는 보증이 제공되지 않습니다. 그러나 실제로는 서비스 간 장애를 상당히 비상관화할 수 있습니다.

제어 평면에 대한 워크플로우 및 메타데이터 서비스, 스트리밍/메시징 서비스와 같은 많은 공유 내부 서비스는 서비스 셀을 사용하여 이를 사용하는 업스트림 서비스에 대한 중단을 비상관화합니다.

종속

낮은 수준의 구현과 서비스 세부정보가 변경될 수 있으므로, 다음 지침은 높은 수준의 지침입니다. 그러나 컴퓨트, 스토리지, 네트워킹 및 인증/인가의 주요 차원에 대해서는 다음과 같은 종속성을 명시합니다.

제어 평면의 경우 공통 종속성은 다음과 같습니다.

• 인증 및 권한 부여를 위한 ID/플랫폼 데이터 평면
• 감사 추적 서비스
• 워크플로, 메타데이터 저장소 및 로깅 등을 제공하는 내부 서비스
• 다양한 유형의 로드 밸런서

일부 제어 평면은 분명 서비스별 종속성을 보유합니다. 예를 들어 베어메탈 또는 VM 인스턴스를 시작할 때 컴퓨트 제어 평면은 다음 요소에 따라 달라집니다.

• 오브젝트 스토리지(지정된 운영체제 이미지 검색)
• 블록 볼륨 제어 평면(부트 볼륨 프로비저닝 및 연결)
• 네트워킹 제어 평면(VNIC 프로비저닝 및 연결)

핵심 서비스 데이터 평면의 일반적인 원칙은 높은 가용성, 신속한 진단 시간 및 신속한 복구 시간을 달성하기 위해 각 데이터 평면이 의도적으로 최소한의 종속성을 갖도록 설계하는 것입니다. 그 원칙의 결과는 다음과 같습니다:

• 네트워킹 데이터 평면에는 모든 기능이 자체 내장되어 있습니다.
• 블록 볼륨 데이터 평면에는 모든 기능이 자체 내장되어 있습니다.
• 컴퓨트 베어메탈 및 VM 인스턴스는 블록 볼륨 데이터 평면(부트 볼륨용)과 네트워킹 데이터 평면에 종속됩니다.
• 오브젝트 스토리지 데이터 평면은 인증 및 권한 부여를 위한 ID/플랫폼 데이터 평면에 종속됩니다(업계의 기대 때문). 오브젝트 스토리지 데이터 평면은 블록 볼륨 또는 파일 스토리지에 종속되지 않습니다.
• 백업 및 복원을 지원하는 모든 서비스는 해당 기능의 오브젝트 스토리지 데이터 평면에 종속됩니다.

IaaS 데이터 평면의 경우 일반적인 원칙은 순환 종속성을 피하기 위해 핵심 또는 하위 레벨 데이터 평면에만 종속되는 것입니다.

• 데이터베이스 다중 노드 RAC는 네트워킹 데이터 평면 및 블록 볼륨 데이터 평면에 종속됩니다.
• Kubernetes용 컨테이너 엔진은 분명히 Kubernetes와 그 전이적 종속성(예: etcd) 및 네트워킹 데이터 평면에 종속됩니다.
• 모든 백업 및 복원 지원은 오브젝트 스토리지 데이터 평면에 종속됩니다.

리전별 API 엔드포인트를 비롯한 리전 내 Oracle Cloud Infrastructure 서비스는 글로벌 제어 평면 기능으로부터 격리되어 있더라도 계속 작동되나요?

네. Oracle Cloud Infrastructure 서비스는 리전 독립적인 서비스로 설계되어 있기 때문에, Oracle Cloud Infrastructure 리전의 서비스가 다른 Oracle Cloud Infrastructure 리전 및/또는 글로벌 제어창에서 분리되어 있더라도 계속 작동할 수 있습니다. 서비스 API 엔드포인트를 포함한 데이터 평면 및 제어 평면 기능은 리전이 격리되어 있더라도 계속 사용할 수 있습니다.

많은 Oracle Cloud Infrastructure 서비스는 Oracle Cloud Infrastructure Object Storage에서 제공하는 리전 간 오브젝트 복사 기능과 같은 리전 간 기능을 제공합니다. Oracle Cloud Infrastructure의 리전 간 기능은 항상 코어 서비스상의 계층으로 설계되므로 리전 간 기능에 영향을 주는 경우에도 리전 격리가 핵심 서비스에 영향을 주지 않습니다. 예를 들어 Oracle Cloud Infrastructure 오브젝트 스토어 리전 간 복사 기능은 오브젝트 스토어 서비스의 계층으로 설계되므로 특정 지역을 격리해도 관련 지역 간 복사 기능은 영향을 받을 수 있지만 해당 지역의 핵심 오브젝트 스토리지 서비스에 영향을 주지 않습니다.

지역 제어 평면 기능과 격리되는 경우에도 논리적 데이터 센터의 Oracle Cloud Infrastructure 서비스는 계속 운영되나요?

네. Oracle Cloud Infrastructure 서비스는 모든 논리적 데이터 센터의 데이터 평면 기능이 해당 리전의 제어 평면과 격리된 경우에도 계속 운영되도록 설계되었습니다. 예를 들어 데이터 센터가 컴퓨트, 블록 스토리지, VCN 및/또는 ID 및 접근 관리의 컨트롤 플레인 기능과 격리되어 있더라도 논리적 데이터 센터의 Oracle Cloud Infrastructure(OCI) 컴퓨트 인스턴스는 연결된 블록 볼륨 및 관련 가상 네트워크 기능과 함께 계속 작동합니다.

Oracle Cloud Infrastructure 리전은 고가용성을 위한 중복 인터넷 연결을 제공하나요?

네. Oracle Cloud Infrastructure는 모든 상용 리전의 여러 중복 제공업체를 거쳐 인터넷에 연결됩니다. 이러한 연결에는 BGP(Border Gateway Protocol)가 사용됩니다.