OCI 아키텍처 기본: 리전, 도메인 및 IAM이 실제로 어떻게 맞물리는지
Source: Dev.to
번역하려는 텍스트가 제공되지 않았습니다. 번역이 필요한 본문을 알려주시면 한국어로 번역해 드리겠습니다.
🧠 OCI의 핵심 아이디어
OCI는 하나의 가정에 기반합니다:
실패는 정상이다. 이를 대비하라.
그 아이디어는 여기 어디서든 나타납니다:
- Oracle이 데이터 센터를 설계하는 방식
- 워크로드가 배포되는 방식
- 접근이 제어되는 방식
OCI의 기반은 두 층으로 구성됩니다:
- 물리적 복원력 – 워크로드가 실행되는 곳
- 논리적 제어 – 누가 무엇에 접근할 수 있는지
둘 모두를 살펴보겠습니다.
🌍 지역
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:
| Scope | Recommendation |
|---|---|
| 하나의 AD 내 | 다른 Fault Domain에 동일한 워크로드 배포 |
| 여러 AD에 걸쳐 | 전체 데이터센터 장애에 대비해 워크로드 복제 |
| 여러 지역에 걸쳐 | 재해 복구를 위해 지역 쌍 사용 |
경험 법칙
- FDs → 하드웨어 장애
- ADs → 데이터센터 장애
- Regions → 재해 복구
OCI는 도구를 제공하지만, 시스템을 얼마나 복원력 있게 만들지는 여러분이 결정합니다.
🔐 OCI Identity and Access Management (IAM)
워크로드가 실행된 후, 다음 질문이 당연히 떠오릅니다:
누가 이것을 조작할 수 있나요?
IAM은 두 가지 책임을 가집니다:
- Authentication – 당신이 누구인지 (신원 증명)
- 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단계까지 중첩 가능
- 격리, 청구, 할당량, 접근 제어에 사용됩니다
정책은 리소스가 아니라 컴파트먼트를 기준으로 적용됩니다.
베스트 프랙티스: 가능한 가장 낮은 수준에 정책을 부착합니다.
👥 그룹 및 위임된 관리
권한은 개별 사용자 대신 그룹에 할당됩니다.
좋은 실천법
- 역할에 따라 그룹을 생성합니다
- 그룹에 정책을 부착합니다
- 사용자를 그룹에 추가합니다
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에서 대부분의 접근 문제는 정책 설계 때문인 이유를 다룹니다.
계속 지켜봐 주세요.