best-practices

OCI のベストプラクティス - 専門知識

🏗️ OCI Landing Zone Terraform モジュールを使用する

車輪の再発明はしないでください。 OCI アーキテクチャには、oracle-terraform-modules/landing-zone を使用してください。

Landing Zone で解決できること：

• ❌ 悪い慣行 #1：汎用的なコンパートメント（Landing Zone は、ネットワーク／セキュリティ／ワークロードの階層構造を提供します）
• ❌ 悪い慣行 #2：日常業務に管理者権限を使用すること（Landing Zone は最小権限の IAM ポリシーを適用します）
• ❌ 悪い慣行 #4：不適切なネットワークセグメンテーション（Landing Zone はセキュリティゾーンを備えたハブアンドスポーク型トポロジを実装します）
• ❌ 悪い慣行 #8：独自の Terraform モジュールを作成すること（Landing Zone は、実績があり、Oracle が保守し、CIS 認定を受けたモジュールを提供します）

このスキルが提供するもの：Landing Zone 内にデプロイするリソース向けの、OCI 固有のアンチパターン、アーキテクチャパターン、運用知識です。

---

⚠️ OCI CLI／API に関する知識の不足

OCI CLI コマンドや OCI API の構造については把握していません。

学習データに含まれる以下の情報は、限られており、古くなっています。

• OCI CLI の構文とパラメーター（月次で更新）
• OCI API のエンドポイントとリクエスト／レスポンス形式
• OCI サービス固有のコマンドとフラグ
• 最新の OCI 機能、制限、リージョンでの提供状況
• OCI 向け CIS ベンチマークの要件

OCI の操作が必要な場合：

1. スキルのリファレンスに記載された正確な CLI コマンドを使用してください
2. OCI CLI の構文やパラメーターを推測しないでください
3. API エンドポイントの構造を想定しないでください
4. Terraform モジュールについては landing-zones スキルを参照してください

把握していること：

• 一般的なクラウドアーキテクチャの概念
• セキュリティ原則とコンプライアンスフレームワーク
• マルチティアアプリケーションの設計パターン

このスキルは、最新の OCI 固有のパターンとアンチパターンを提供することで、この知識の不足を補います。

---

あなたは OCI アーキテクチャの専門家です。このスキルでは、Claude に不足している知識、すなわち OCI 固有のアンチパターン、Always Free の詳細、用語に関する注意点、複数 AD のパターン、AWS／Azure／GCP との違いを提供します。

絶対にしてはいけないこと

❌ /24 またはそれより小さい VCN CIDR を絶対に使用しないでください（拡張できません）

# WRONG - VCN too small, cannot expand later (OCI limitation)
oci network vcn create --cidr-block "10.0.0.0/24"
# Only 256 IPs total, exhausted quickly

# WRONG - copying AWS habit (/16 VPC default)
# OCI supports larger: /16 to /30

# RIGHT - start with /16, plan for growth
oci network vcn create --cidr-block "10.0.0.0/16"
# 65,536 IPs, room for 256 /24 subnets

# CRITICAL: OCI VCNs CANNOT be resized after creation
# Must create new VCN and migrate if too small

移行コスト：VCN の再作成には、数時間のダウンタイム、IP アドレスの変更、セキュリティルールの更新が必要です

❌ AD 固有のサブネットを絶対に使用しないでください（複数 AD の HA が機能しなくなります）

# WRONG - subnet tied to single AD
oci network subnet create \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24" \
  --availability-domain "fMgC:US-ASHBURN-AD-1"  # AD-specific!

# Problem: Can't launch instances in other ADs, no HA

# RIGHT - regional subnet (works in all ADs)
oci network subnet create \
  --vcn-id <vcn-ocid> \
  --cidr-block "10.0.1.0/24"
  # No --availability-domain flag = regional
  # Instances can be in any AD in region

注意点：一部の古い OCI ガイドでは、AD 固有のサブネット（非推奨のパターン）が紹介されています

❌ セキュリティリストと NSG を絶対に混同しないでください（用途が異なります）

OCI has TWO network security mechanisms:

Security Lists (stateful, subnet-level):
- Applied to ALL resources in subnet
- Use for: Broad rules (internet egress, DNS)
- Limit: 5 per subnet
- Changes: Affect all instances in subnet

Network Security Groups (NSG, resource-level):
- Applied to specific resources
- Use for: Granular rules (app tier → DB tier)
- Limit: 5 per resource, 120 rules per NSG
- Changes: Affect only tagged resources

# WRONG - using Security Lists for app-specific rules
Security List: Allow app-tier → database (applies to ENTIRE subnet)

# RIGHT - use NSG for app-tier resources
NSG "app-tier": Allow egress to NSG "db-tier" on port 1521
# Only instances in app-tier NSG can reach DB

ベストプラクティス：基本設定（インターネット、DNS）にはセキュリティリストを、アプリケーション固有のルールには NSG を使用してください

❌ 単一 AD へのデプロイを許容できると絶対に想定しないでください（SLA がありません）

OCI Availability Domains (ADs):
- 3 ADs per region (most regions)
- Isolated fault domains
- <1ms latency between ADs

# WRONG - all resources in single AD
All instances in AD-1 → AD failure = complete outage

# RIGHT - distribute across ADs
Production instances: AD-1, AD-2, AD-3
Load balancer: Automatically multi-AD
Database: Autonomous (auto 3-AD) or RAC (2+ nodes)

SLA impact:
Single-AD: NO SLA (OCI doesn't guarantee)
Multi-AD: 99.95% SLA

重要：Oracle は、AD が 3 つあるリージョンでの単一 AD デプロイについて、SLA の適用を拒否しています

❌ AD 名を絶対にハードコードしないでください（テナンシーごとに異なります）

# WRONG - AD names are tenant-specific, not portable
availability_domain = "fMgC:US-ASHBURN-AD-1"  # Only works in YOUR tenancy!

# Another tenant's AD name for same physical AD:
availability_domain = "xYzA:US-ASHBURN-AD-1"  # Different prefix!

# RIGHT - query AD names dynamically
data "oci_identity_availability_domains" "ads" {
  compartment_id = var.tenancy_ocid
}

resource "oci_core_instance" "web" {
  availability_domain = data.oci_identity_availability_domains.ads.availability_domains[0].name
}

理由：セキュリティ分離のため、OCI はテナンシーごとに固有の AD プレフィックスを生成します

❌ Cloud Guard の自動修復を、テストせずに絶対に有効にしないでください

Cloud Guard = OCI threat detection + auto-response

# DANGER - auto-remediation can break production
Detector: "Public bucket detected"
Auto-remediation: Make bucket private → breaks public website!

Detector: "Security list allows 0.0.0.0/0"
Auto-remediation: Remove rule → breaks internet access!

# SAFER approach:
1. Enable detectors (read-only mode first)
2. Review findings for 1-2 weeks
3. Tune responders to avoid false positives
4. Enable auto-remediation for trusted patterns only

注意点：一部のテナンシーでは Cloud Guard がデフォルトで有効になっており、意図せずシステムを壊すことがあります

❌ Oracle Linux が必要だと絶対に想定しないでください（よくある誤解です）

OCI supports:
✓ Oracle Linux (free, optimized)
✓ Ubuntu, CentOS, Rocky Linux (free)
✓ Windows Server (BYOL or license-included)
✓ Custom images (import your own)

# WRONG assumption: "OCI = must use Oracle Linux"
Reality: Any Linux works, Ubuntu has larger community

# Cost: Oracle Linux is FREE (no license cost)
# But if team knows Ubuntu → use Ubuntu

マーケティングによる誤解：Oracle は Oracle Linux を推奨していますが、必須ではありません

OCI Always Free Tier（正確な制限）

永続的に利用できる充実した無料利用枠（クレジットカード不要のトライアルではなく、有効期限もありません）：

コンピュート

• AMD VM 2 台：VM.Standard.E2.1.Micro（各 1/8 OCPU、1 GB RAM）
• Arm OCPU 4 個：VM.Standard.A1.Flex（1×4 OCPU または 4×1 OCPU として割り当て可能）
  • 合計最大 24 GB の RAM（OCPU あたり 6 GB）
  • 例：1 OCPU／6 GB の Arm インスタンスを 4 台、永久に無料で実行できます

データベース

• Autonomous Database 2 台：各 1 OCPU、ADB あたり 20 GB のストレージ
  • ATP または ADW を選択できます
  • 制限：全リージョンを通じて、テナンシーあたり合計 2 台

ストレージ

• ブロックボリューム：合計 200 GB（100 GB のブートボリューム 2 個＋カスタムボリューム）
• オブジェクトストレージ：Standard 層 10 GB
• アーカイブストレージ：Archive 層 10 GB
• ブロックボリュームのバックアップ：10 GB

ネットワーキング

• ロードバランサー：柔軟な LB 1 台、帯域幅 10 Mbps
• VCN：リージョンあたり 2 個の VCN（無料、OCID の料金なし）
• パブリック IPv4：リージョンあたり 予約済みパブリック IP 1 個を無料で利用できます

オブザーバビリティ

• モニタリング：10億データポイントを取り込み
• ロギング：月間10 GBを取り込み
• 通知：月間100万通のメール

常時無料枠の注意点

見落としがちな重大な制限：

# Gotcha 1: 2 ADB limit is TENANCY-wide, not per region
Can have: 1 ATP in Phoenix + 1 ADW in Ashburn = 2 (limit reached)
Cannot: Add 3rd ADB in any region

# Gotcha 2: Arm instances must be VM.Standard.A1.Flex only
Cannot: Use newer A2 shapes (paid only)

# Gotcha 3: Free tier != trial credits
Free tier: Permanent, no expiration
Trial: $300 credit for 30 days (separate)

# Gotcha 4: Stopped ADB counts toward 2 ADB limit
To free slot: Must DELETE ADB, not just STOP

OCI と AWS／Azure の用語の違い

AWS／Azure から移行しますか？ 用語の違いにご注意ください。

OCI の用語	AWS での相当機能	Azure での相当機能
VCN	VPC	Virtual Network
サブネット	Subnet	Subnet
セキュリティリスト	VPC Security Group	NSG（ネットワークレベル）
NSG	Security Group	Application Security Group
DRG	Virtual Private Gateway	VPN Gateway
コンパートメント	Resource Group／OU	Resource Group
テナンシ	アカウント	サブスクリプション
リージョン	リージョン	リージョン
AD（可用性ドメイン）	Availability Zone	Availability Zone
障害ドメイン	（AZ 内）	Availability Set
動的グループ	IAM ロール（インスタンス用）	Managed Identity
インスタンスプリンシパル	EC2 Instance Profile	Managed Identity
OCIR	ECR	Container Registry
OKE	EKS	AKS

重要な違い：OCI にはセキュリティリスト（サブネット）と NSG（リソース）の両方があります。AWS にはセキュリティグループ（リソースレベル）のみがあります。

マルチ AD アーキテクチャパターン

OCI のマルチ AD 固有の仕様：

AD の分散戦略

OCI Regions with 3 ADs (most regions):
- US: Phoenix, Ashburn
- UK: London
- DE: Frankfurt
- AU: Sydney, Melbourne

Pattern: Distribute instances across all 3 ADs

AD-1: Web tier (2 instances) + DB primary
AD-2: Web tier (2 instances) + DB standby
AD-3: Web tier (2 instances) + DB standby

Load Balancer: Automatically spans ADs

注意点：一部のシェイプは特定の AD でのみ利用可能です（事前に確認してください）。

# Check shape availability by AD
oci compute shape list \
  --compartment-id <ocid> \
  --availability-domain "fMgC:US-ASHBURN-AD-1"

障害ドメインによる追加レイヤー

各 AD 内に、OCI の障害ドメイン（FD）があります。

• AD ごとに 3 つの FD
• 電源、冷却、ネットワークを分離
• AD 内のレイテンシーは 1 ミリ秒未満

Best practice: Spread instances across ADs AND FDs

AD-1:
  FD-1: Web instance 1
  FD-2: Web instance 2
  FD-3: Web instance 3

AD-2:
  FD-1: Web instance 4
  (repeat pattern)

Protection:
- AD failure: 2 ADs survive (66% capacity)
- FD failure: Only 1 instance affected (16% capacity)

FD を使用する場合：特に重要度の高いアプリに限ります（複雑さが増します）。

コンパートメント戦略のベストプラクティス

コンパートメント階層（OCI 固有の IAM 境界）：

Root Compartment (tenancy)
│
├─ SharedServices (networking, security)
│  ├─ Network (VCNs, DRGs)
│  └─ Security (Vault, KMS, Cloud Guard)
│
├─ Production
│  ├─ App1
│  │  ├─ Compute
│  │  ├─ Database
│  │  └─ Storage
│  └─ App2
│
├─ NonProduction
│  ├─ Development
│  ├─ Testing
│  └─ Staging
│
└─ Sandbox (developers, auto-cleanup)

主な原則：

1. 課金の分離：コンパートメントタグを使って、環境ごとのコストをレポートできます
2. IAM 境界：コンパートメントの範囲内でポリシーを設定します（最小権限）
3. クォータの分離：コンパートメントごとに制限を分けます
4. ライフサイクル：コンパートメント全体を削除すると、内部のすべてのリソースも削除されます

アンチパターン：階層を設けないフラットな構造（AWS で環境ごとにアカウントを分ける習慣）

OCI 固有のコスト最適化

フレックスシェイプによる節約（OCI 独自）

Fixed shapes (legacy):
VM.Standard2.4: 4 OCPUs, 60 GB RAM, $218/month

Flex shapes (right-size RAM independently):
VM.Standard.E4.Flex: 4 OCPUs, 16 GB RAM, $109/month (50% savings)

Flex advantage: Pay only for RAM you need
- 1 OCPU = 1-64 GB RAM configurable
- Most apps don't need 15GB per OCPU (fixed ratio)

移行：固定シェイプをフレックスシェイプに置き換えると、30～50％のコストを削減できます。

Arm インスタンスによる節約（充実した無料枠）

AMD instance: VM.Standard.E4.Flex (1 OCPU) = $0.03/hr
Arm instance: VM.Standard.A1.Flex (1 OCPU) = $0.01/hr (67% cheaper)

Always-Free Arm: 4 OCPUs free forever!

Use case: Web servers, CI/CD runners, dev environments
Limitation: ARM64 only (not all apps compatible)

注意点：無料枠の対象は A1 シェイプのみです。新しい A2 シェイプは有料です。

ストレージ階層化（正確な価格）

階層	コスト／GB／月	用途	取り出し
標準	$0.0255	アクティブデータ、頻繁なアクセス	即時、無料
低頻度アクセス	$0.0125（51％割引）	バックアップ、ログ（月に一度アクセス）	即時、$0.01／GB
アーカイブ	$0.0024（91％割引）	コンプライアンス、長期保存	1 時間、$0.01／GB

ライフサイクルポリシーの例：

Day 0-30: Standard ($0.0255/GB/mo)
Day 31-90: Infrequent ($0.0125/GB/mo)
Day 91+: Archive ($0.0024/GB/mo)

1 TB data for 1 year:
Without tiering: $0.0255 × 1000 × 12 = $306/year
With tiering: $0.0255 × 1000 × 1 + $0.0125 × 1000 × 2 + $0.0024 × 1000 × 9 = $72/year
Savings: $234/year (76%)

セキュリティゾーン（OCI 独自）

OCI セキュリティゾーン＝インフラストラクチャレベルでのポリシー適用：

Security Zone enforces:
✓ All storage encrypted
✓ No public buckets
✓ No internet gateways in VCN
✓ All databases private endpoint only
✓ Cloud Guard enabled

Enforcement: API rejects violating requests (preventive, not detective)

Example:
oci os bucket create --public-access-type ObjectRead
→ FAILS if compartment is in Security Zone

Use case: Production, PCI-DSS, healthcare (mandatory controls)

注意点：セキュリティゾーンによって既存の自動化が機能しなくなる場合があります（まず開発環境でテストしてください）。

段階的な読み込みに関する参考資料

OCI Well-Architected チェックリスト

次の場合に読み込んでください oci-well-architected-checklist.md：

• OCI テナンシに対するコンプライアンスチェックの実行
• CIS OCI Foundations Benchmark 監査の準備
• 自動セキュリティスキャンの実装
• よくある検出事項に対する修正スクリプトの作成
• ドリフト検出のモニタリング設定

次の場合は読み込まないでください：

• アンチパターンをすぐに参照する場合（上記の「避けるべきこと」リストに記載されています）
• アーキテクチャを決定する場合（このスキルで説明しています）
• OCI の用語を理解する場合（上記の表に記載されています）

Oracle 公式ドキュメントの参照先

主な参照先（公式ソースを50件以上スクレイピング）：

• OCI の Well-Architected Framework
• OCI アーキテクチャセンター
• CIS OCI Foundations Benchmark
• セキュリティのベストプラクティス
• コンパートメントの設計
• ネットワークアーキテクチャのパターン

注：このスキルのすべてのアンチパターン、用語の対応関係、Always-Free の制限は、Oracle の公式ドキュメントと A-Team Oracle ブログに基づいています。

---

このスキルを使用する場面

• アーキテクチャ設計：複数 AD のパターン、コンパートメント戦略、VCN のサイズ設定
• AWS／Azure からの移行：用語の対応関係、アンチパターンの回避
• コスト最適化：無料枠の計画、Flex シェイプ、ストレージ階層化
• セキュリティ：Cloud Guard の調整、Security Zones、NSG と Security Lists の比較
• 本番環境への対応：SLA 要件、高可用性パターン、フォールトトレランス