OCI 아키텍처 기본: 리전, 도메인 및 IAM이 실제로 어떻게 맞물리는지

발행: (2026년 1월 19일 오전 09:51 GMT+9)
11 min read
원문: Dev.to

Source: Dev.to

번역하려는 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.

🧠 OCI의 핵심 아이디어

OCI는 하나의 가정에 기반합니다:

실패는 정상이다. 이를 대비하라.

그 아이디어는 여기 어디서든 나타납니다:

  • Oracle이 데이터 센터를 설계하는 방식
  • 워크로드가 배포되는 방식
  • 접근이 제어되는 방식

OCI의 기반은 두 층으로 구성됩니다:

  1. 물리적 복원력 – 워크로드가 실행되는 곳
  2. 논리적 제어 – 누가 무엇에 접근할 수 있는지

둘 모두를 살펴보겠습니다.

🌍 지역

OCI가 클라우드 인프라를 운영하는 지리적 위치를 Region이라고 합니다.

다음과 같은 기준으로 지역을 선택합니다:

  • 지연 시간 – 사용자에 가깝게 할수록 좋습니다
  • 법적 및 데이터 거주 요구사항
  • 서비스 가용성

지역은 서로 격리되어 있습니다. 전체 지역이 중단되더라도 다른 지역에는 영향을 주지 않습니다. 이러한 격리 덕분에 재해 복구가 가능해집니다.

🏢 Availability Domains (ADs)

Availability Domains는 리전 내에서 물리적으로 분리된 데이터 센터입니다.

각 AD:

  • 자체 전원, 냉각 및 하드웨어를 가짐
  • 다른 AD와 물리적 인프라를 공유하지 않음
  • 저지연 링크를 통해 다른 AD와 연결됨

한 AD가 다운되면, 다른 AD에 있는 워크로드는 계속 운영됩니다. 모든 리전에 다수의 AD가 있는 것은 아니며, 이는 고가용성을 설계하는 방식에 직접적인 영향을 미칩니다.

🧩 Fault Domains (FDs)

Fault Domains는 가용성 도메인(Availability Domain) 내부에 존재합니다.

Fault Domain은 AD 내에서 하드웨어를 논리적으로 그룹화한 것입니다.

핵심 포인트

  • 각 AD에는 세 개의 Fault Domain이 있습니다
  • 랙, 전원 장치, 냉각 장치와 같은 하드웨어는 FD별로 격리됩니다
  • OCI는 한 번에 하나의 FD에서만 유지보수를 수행합니다

다른 Fault Domain에 여러 인스턴스를 배치하면:

  • 단일 하드웨어 장애가 모든 것을 중단시키지는 않습니다
  • 계획된 유지보수가 한 번에 모든 인스턴스에 영향을 주지는 않습니다

FD는 로컬 하드웨어 장애로부터 보호하고, AD는 데이터센터 장애로부터 보호합니다.

🛡️ 고가용성을 위한 설계

A simple, practical strategy:

ScopeRecommendation
하나의 AD 내다른 Fault Domain에 동일한 워크로드 배포
여러 AD에 걸쳐전체 데이터센터 장애에 대비해 워크로드 복제
여러 지역에 걸쳐재해 복구를 위해 지역 쌍 사용

경험 법칙

  • FDs → 하드웨어 장애
  • ADs → 데이터센터 장애
  • Regions → 재해 복구

OCI는 도구를 제공하지만, 시스템을 얼마나 복원력 있게 만들지는 여러분이 결정합니다.

🔐 OCI Identity and Access Management (IAM)

워크로드가 실행된 후, 다음 질문이 당연히 떠오릅니다:

누가 이것을 조작할 수 있나요?

IAM은 두 가지 책임을 가집니다:

  1. Authentication – 당신이 누구인지 (신원 증명)
  2. Authorization – 당신이 무엇을 할 수 있는지 (권한 적용)

👤 Authentication (AuthN)

Authentication은 접근을 허용하기 전에 당신이 누구인지 확인합니다. OCI는 다음을 지원합니다:

  • 사용자 이름 및 비밀번호
  • API 키
  • OAuth 2.0 토큰
  • 다중 인증(MFA)
  • 인스턴스 프린시플(저장된 자격 증명 없음)
  • 외부 아이덴티티 공급자를 이용한 SAML 2.0 연동

목표는 비밀을 노출하지 않으면서 안전하고 검증 가능한 접근을 제공하는 것입니다.

🪪 Authorization (AuthZ): 정책이 접근을 결정합니다

OCI는 기본 거부(deny‑by‑default) 권한 부여 방식을 사용합니다. 정책이 명시적으로 허용하지 않는 한 어떤 작업도 허용되지 않습니다.

논리는 언제나 다음과 같습니다:

Who → can do what → on which resources → in which location

정책은 IAM을 예측 가능하고 감사 가능하게 만드는 시행 계층입니다.

Source:

🧑‍🤝‍🧑 Identity Domains

Identity Domain은 ID를 위한 논리적 컨테이너입니다. 여기에는 다음이 포함됩니다:

  • Users
  • Groups
  • Applications
  • Federation settings

Identity Domain을 사람을 위한 compartment(구획)이라고 생각하면 됩니다.

High‑level view

OCI Tenancy
└─ Compartment
   └─ Identity Domain
      └─ Users / Groups / Applications

The Default Identity Domain

모든 OCI tenancy에는 Default Identity Domain이 기본으로 제공됩니다.

중요한 사실:

  • 삭제하거나 비활성화할 수 없습니다.
  • 구독된 모든 리전으로 복제됩니다.
  • 로그인 페이지에 항상 표시됩니다.

포함 내용:

  • 하나의 사용자 – tenancy를 만든 사람
  • 전체 tenancy 접근 권한을 가진 Administrators 그룹
  • All Domain Users 그룹

이 도메인은 일반적으로 OCI 인프라스트럭처 접근을 관리하는 데 사용됩니다.

Why Create Additional Identity Domains?

여러 개의 Identity Domain은 격리와 제어를 위한 것입니다.

Common use cases

  • Production과 Development 접근을 분리
  • 파트너 접근을 격리
  • 공개 애플리케이션을 위한 소비자 ID 관리

각 도메인은 다음을 가질 수 있습니다:

  • 자체 관리자
  • 자체 보안 정책
  • 자체 사용자 풀

이를 통해 한 팀의 실수가 다른 팀에 영향을 주는 것을 방지할 수 있습니다.

📦 컴파트먼트

컴파트먼트는 OCI 리소스를 위한 논리적 컨테이너입니다. 특징은 다음과 같습니다:

  • 전역(리전 전체)에서 사용 가능
  • 최대 6단계까지 중첩 가능
  • 격리, 청구, 할당량, 접근 제어에 사용됩니다

정책은 리소스가 아니라 컴파트먼트를 기준으로 적용됩니다.

베스트 프랙티스: 가능한 가장 낮은 수준에 정책을 부착합니다.

👥 그룹 및 위임된 관리

권한은 개별 사용자 대신 그룹에 할당됩니다.

좋은 실천법

  1. 역할에 따라 그룹을 생성합니다
  2. 그룹에 정책을 부착합니다
  3. 사용자를 그룹에 추가합니다

OCI는 다음과 같은 위임된 관리자 역할도 지원합니다:

  • 보안 관리자
  • 애플리케이션 관리자
  • 헬프 데스크 관리자
  • 감사 관리자

이를 통해 모든 사용자에게 전체 관리자 권한을 부여하는 것을 방지할 수 있습니다.

🌐 네트워크 소스

A Network Source는 허용된 IP 범위 또는 VCN을 정의합니다.

사용 목적:

  • 신뢰할 수 있는 네트워크로 API 호출 제한
  • IAM에 대한 소스 IP 기반 정책 적용

전형적인 시나리오: 민감한 작업을 기업 네트워크로 제한.

세부적인 제어를 위해 정책에서 직접 참조됩니다.

✅ Final Takeaway

OCI isn’t complex by accident. It’s structured because it’s designed for scale and failure.

  • Regions, ADs, and FDs protect availability
  • Compartments organize resources
  • Identity Domains organize people
  • Policies enforce least privilege

When you treat IAM and infrastructure as architecture decisions, OCI becomes predictable, scalable, and secure. And that’s the point.

🔔 What’s Coming Next

이 문서는 OCI의 아키텍처 및 IAM 기반에 초점을 맞춥니다.

다음 파트에서는 IAM 정책에 대해 더 깊이 살펴볼 것입니다: 권한 부여가 실제로 어떻게 작동하는지, 정책이 어떻게 평가되는지, 그리고 OCI에서 대부분의 접근 문제는 정책 설계 때문인 이유를 다룹니다.

계속 지켜봐 주세요.

Back to Blog

관련 글

더 보기 »

기술은 구원자가 아니라 촉진자다

왜 사고의 명확성이 사용하는 도구보다 더 중요한가? Technology는 종종 마법 스위치처럼 취급된다—켜기만 하면 모든 것이 개선된다. 새로운 software, ...

에이전틱 코딩에 입문하기

Copilot Agent와의 경험 나는 주로 GitHub Copilot을 사용해 인라인 편집과 PR 리뷰를 수행했으며, 대부분의 사고는 내 머리로 했습니다. 최근 나는 t...