はじめに
- 年末年始暇だなーと思ってインターネットサーフィンしていたところ、以下が目に止まりまして。
- 私の所属している会社では、OCIの初級資格を取得すると、子供のお年玉くらいの報奨金が出る……ということを調べ、ちょっと狙ってみるかと一念発起して取得してみました。
- ただ資格とるだけでも良かったのですが、少し勉強し始めた(10分程度)くらいでAWSやAzureとの考え方の違いに違和感を感じてきてしまったので、違和感を整理するためにまとめています。
免責事項
- あくまで、AWS/Azureの知見がベースになっていて、その差異を埋める記載をしています。
- そのため、機能の説明は、AWS/Azureと似通っている部分は省いています。
- Oracle Cloud公式の動画(参考を参照)を見つつ、自分の理解を記載しているため、必ずしも正しいとは限りません。
- イメージを埋める補助としてご利用ください。
一応Oracle Cloud Infrastructure Foundationsとは
- Oracle Cloud Infrastructure(OCI)が提供している資格の一つ。
- 試験詳細
- 日本語受験OK！！！
- 試験時間:60分
- 受験料無料！！！
- 出題数：40問
- 合格ライン：65%=24問正解すればOK
- 受験回数：15回まで受験できる……らしい
- Foundationsという名が付いているように、OCI資格としては初心者向けに定義されています。
- AWSで言うところのクラウドプラクティショナーに相当
- Azureで言うところのAzure Fundamentals(AZ-900)に相当
- 難易度としては、AZ-900に近いイメージ
- クラウドプラクティショナーがAWSの初級資格という建付けにありながら、対象となるAWSサービスが幅広すぎて、本当に初心者向け？？
？？と疑問が出てくるレベルなのはありますが、、
- クラウドプラクティショナーがAWSの初級資格という建付けにありながら、対象となるAWSサービスが幅広すぎて、本当に初心者向け？？
- OCIにおける超基礎的なサービスの概要を理解できれば資格取得はそれほど難しくなかったです。
- ただ、後述するオンラインコースを用いて勉強しましたが、コース内でOracle RACなど、OracleDB用語の解説がなかったのでそこは個別で学習が必要かなぁと感じました。
勉強方法
- 以下OracleLearnのコースにて動画視聴+よくわからない点をggrことで補完しました。
- 勉強時間：5-6時間程度
- ただし、OracleLearnのサイトが2-3回504エラーとなり、結構イライラしました。
- 年末年始でOracleサーバリソースが足りていなかったのか、原因はわかりません。
- ツイッターで検索してみましたが、同様の状況になっている人は見つからず、ただ、2時間ほど待つことで自動回復してくれました。
- これが一番だるかったです。
- 後続の勉強メモを作成しながら理解の整理をしています。←これがこのブログのメイン
Oracle Cloud Infrastructure Foundationsの勉強メモ
OCIアーキテクチャ
- リージョン
- AWSと同じ概念
- 可用性ドメイン(AD)
- アベイラビリティゾーン(AZ)に相当していそう
- 互いに分離され、フォールトトレラントで、同時に故障する可能性が低い関係
- 物理インフラストラクチャがフォールトトレラントで共有されていない
- リージョン内には最低1つ、最大3つで構成されている
- フォルトドメイン
- AWSにはない概念。しいて言うとデータセンターに相当？
- 各可用性ドメインには3つのフォルトドメインが存在
- 異なるFDに配置されたリソースは、ハードウェア障害の単一ポイントを共有しない
- サーバを作成するときとかは、フォルトドメインを指定して作成する
- 1つだけ作成するときは、Autoで指定されるものそのままでOK
- 高可用性のために2つ以上作成する場合は、複数のフォルトドメインを意識的に指定する必要あり
OCI IAM
ユーザー向け
- ユーザー
- IAM ユーザー
- グループ
- IAM グループ
- ポリシーを付与するのはここに対して
リソース
- プリンシパル
- OCI上のリソースを一意に定めるもの
- 多分ARNとか、InstanceIDとかに相当するもの？
- 動的グループ
- OCI上のリソースをまとめたグループ
- Azureにおけるリソースグループとは違う気がする
- ポリシーを付与するのはここに対して
- コンパートメント
- これがAzureにおけるリソースグループ？
- リソースを束ねる概念で、AWSにはない
- リソース
- 名前通り
- 必ずコンパートメントに属する
権限系
- ポリシー
- IAMポリシー
- xxxグループに対してのみ権限を付与できる
- フェデレーション
- SAMLとかで統合管理するときに出てくるやつ
- ネットワークソース
- 接続元制限をかける時に出てくるやつ
リソースの特定
- Oracle Cloud ID(OCID)
- OCIリソースを一意に識別するID
# 構文 ocid1.<RESOURCE TYPE>.<REALM>.[REGION][.将来の使用].<一意ID>の形式
テナンシ設定
テナンシー
- テナンシ/ルートコンパートメント
- AWSで言うところのアカウント
- Azureで言うところのサブスクリプション
- OCIアカウントを作成すると最初に作成
- ここに紐づく形でテナンシ管理者が作成される
- テナンシ管理者
- すべての権限を持つ
- AWSで言うところのルートアカウント/ユーザー
- ベストプラクティスとしては、このアカウントは通常業務では使わない
- 別途OCI管理者アカウントを作成しておくこと
- 専用コンパートメント
- リソースを分割するために、用途に応じた専用のコンパートメントを作成、ユーザーやリソースを追加しよう
- MFA
- 設定しよう
ポリシー
- ポリシーを付与するコマンド
# 構文
Allow group <グループ名> to manage <ポリシー名> in tenancy
Allow group <グループ名> to manage <ポリシー名> in compartment <compartment_name>
# 例
Allow group OCI-admin-group to manage all-resources in tenancy
認証と認可
-
プリンシパル
- IAMユーザーの上位がグループ
- リソースプリンシパルの上位が動的グループ
-
認証
- ユーザー名、パスワード
- MFAも追加可能
- API署名キー
- APIをたたくときに利用
- AWSではアクセスキー/シークレットキーに相当する？
- 同じものはなさそう
- 認証トークン
- Azure ストレージアカウントにおけるSASトークンっぽい感じ
- ユーザー名、パスワード
-
認可
# 構文 Allow <group_name> to <verb> <resource-type> in <location> where <conditions>-
verbの種類の例
- manageを付与して、deleteだけをconditionsで除く、みたいなこともできたりする
verb アクセスのタイプ ターゲット・ユーザー inspect リソースを一覧する機能 サードパーティの監査者 read inspect + ユーザー指定のメタデータ 内部監査者 use read + 可能な操作はリソース・タイプによって異なる リソース・エンドユーザー manage リソースに対するすべての権限 管理者 -
リソースタイプの種類の例
集約リソース・タイプ 個別リソース・タイプ all-resources database-family db-systems, db-nodes, db-homes, database instance-family instances, instance-images, volume-attachments, console-histories object-family buckets, objects virtual-network-family vcn, subnet, route-tables, security-lists, dhcp-options, その他多くのリソース volume-family volumes, volume-attachments, volume-backups
-
コンパートメント
- リソースは必ず1つだけのコンパートメントに所属する
- 厳密にはルートコンパートメントと個別のコンパートメントの2つに属している状態
- 同時に上記以上に属させることはできない
- コンパートメント間のリソースの引っ越しはできる
- 同一コンパートメント内のリソースは複数リージョンをまたぐこともできる
- 特段リージョンを縛る概念ではない
- ポリシーのconditionsで利用可能なリージョンを縛ることはできる
- コンパートメント毎に予算を指定可能
- コンパートメント毎にクォーター制限もある
- OCIにサポートチケット的なものを上げると、クォーター開放ができる
ネットワーク
仮想クラウドネットワーク(VCN)
- VPCに相当
- リージョンサービス
- 必ずリージョン内に作成され、リージョン跨ぎは存在しない
- CIDRでIPアドレスを採番
- 10.0.0.0/16 とか
サブネット
- パブリックサブネット/プライベートサブネット
- VCNの範囲でIPアドレスを採番
- パブリックサブネット
- パブリックIPを振るとインターネットと通信が可能
- このサブネットにリソースを配置したからといって、パブリックIPを振らないといけないわけではない
- プライベートサブネット
- インターネットと通信をさせないリソースを配置
- 内部に隠ぺいされたサブネット
各所との通信
- インターネットゲートウェイ
- パブリックサブネットのリソースがインターネットにアクセスするために通る必要のあるルーター的なもの
- インターネットからパブリックサブネット内のリソースにアクセスさせるときにも経由
- NATゲートウェイ
- プライベートサブネットにあるリソースからインターネットにアクセスするときに通る
- インターネットからプライベートサブネットのリソースにアクセスはできない
- AWSでは以下経路になるが、それとは違ってインターネットゲートウェイを経由する必要はない
- プライベートサブネットのリソース⇒NATゲートウェイ⇒インターネットゲートウェイ⇒インターネット
- サービスゲートウェイ
- VPCエンドポイントに相当
- 動的ルーティングゲートウェイ(DRG)
- オンプレミスとの通信時に使用
- VCN↔オンプレ通信のためのVCN側のルーター的な立ち位置
- トランジットGW……とも違う、微妙なもの
- 解説の中で、リージョン間のVCNを接続というのは言われていたが、リージョン内のVCNを接続というフレーズがなかったため
- 役割は以下
- サイト間VPN
- FastConnect
- DirectConnectっぽい
- リージョン間のVCN接続
ルーティング
- ルート表
- VCN間やインターネットなど、VCNの外のルーティングを定義
- VCN内のルーティングは定義不要
- 自動的に定義される
- 宛先のCIDR/OCIサービスからターゲット(GWなど)を指定
- サブネットごとに作成する
- ピアリング
- ローカルピアリング
- 同一リージョン内のVCNを接続
- ローカルピアリングゲートウェイというものを作成して、そのゲートウェイ経由で通信を行う
- VCN間でCIDRに重複があってはいけない
- リモートピアリング
- 異なるリージョン内のVCNを接続
- 通信経路は以下のようなイメージ
- Aリージョンのリソース
- Aリージョンの動的ルーティングゲートウェイ(DRG)
- Aリージョン-Bリージョン間のリモートピアリング接続(RPC)
- インターネットではなく、Oracleのバックボーンネットワークを使用
- Bリージョンの動的ルーティングゲートウェイ(DRG)
- Bリージョンのリソース
- ローカルピアリング
- 動的ルーティングゲートウェイ v2(DRG V2)
- トランジットゲートウェイに相当
- 300個のVCNまで相互接続が可能
- 300を超えるVCNと接続したい場合、DRG同士をリモートピアリング接続する
- ただし、あくまで同一リージョンのVCN間の通信だけ
- セキュリティリスト
- サブネットにアタッチする
- サブネット間のトラフィックを制御
- ネットワークセキュリティグループ(NSG)
- インスタンスに対してアタッチ
- 別のNSGをソースとして指定が可能
- そのNSGをアタッチされたインスタンスからの通信を許可、みたいなことができる
- セキュリティリスト VS ネットワークセキュリティグループ
- OCIのファイアウォール機能の違い
- AWSでは以下で区別をしていたが、OCIではまた違うみたい
- どこにアタッチするものか
- サブネットorリソース
- ステートフルかステートレスか
- どこにアタッチするものか
- OCI的にはNSGの利用を推奨している模様
ロードバランサ
- L7ロードバランサ
- ALBに相当
- HTTP/HTTPS
- ここでTLS終端も可能
- ターゲットとしてバックエンドセットというものを作成して割り振る
- ドメイン毎にバックエンドセットを分配できる
- アクセスするパス毎に分配も
- アクティブ/スタンバイで2重化された状態で作成
- ユーザーは感知できない
- パブリックLBもプライベートLBも作成可能
- ネットワークロードバランサ(NLB)
- L7 LBよりも高速、低レイテンシ
- L4まで
- TCP/UDP
- URLやドメインの解釈はできない
- HTTP/HTTPSのポート指定は可能
コンピュート
コンピュートの基本
- コンピュート
- フレキシブルシェイプ
- 自由にCPU/メモリを割り当てできる
- vSpehreとかと同じイメージ
- インスタンスタイプのような固定ではない
- インスタンスタイプのような固定でも指定が可能
- 仮想マシン
- ベアメタル
- 利用者がそのベアメタルサーバを独占できる
- 専用ホスト(専用仮想マシンホスト)
- 専用のベアメタルサーバを独占
- そのうえで、仮想マシンを動作させることができる
- ベアメタルの専用性と仮想マシンの柔軟性のハイブリッド
- フレキシブルシェイプ
- プロセッサの選択肢
- AMD
- Intel
- Ampere
- ARMベース
- プリエンプティブルVM
- スポットインスタンス的なやつ
- 利用料が半額
- ただし、OCI側のリソースの余り状況によっては利用が強制終了させられることもある
- 検証環境や強制停止されてよい利用目的で利用が推奨
インスタンスの基本
- インスタンスはサブネット内に作成される
- 必ず1つ以上のプライベートIPを持つ
- 指定することも、autoで振ることも可能
- VNICがサブネットに作られる
- 必ず1つ以上のプライベートIPを持つ
- ストレージ
- ブートボリューム
- 必ず作成
- システムディスク的な立ち位置
- データボリューム
- データディスク的な立ち位置
- ブートボリュームもデータボリュームもリモートなボリューム
- I/Oはネットワーク帯域にも依存する
- インスタンスタイプを指定するときのシェイプにより変わる
- 基本はCPUのコア数に依存する
- インスタンス/ブートボリューム/データボリュームは、同一の可用性ドメインに閉じる
- ブートボリューム
- ホスト間のライブ移行
- データセンター内の物理サーバがダウンしたときに、別の物理サーバに移行する
- インスタンスが起動している間に、別のインスタンスに移行される
- 実行中の停止を最小限に抑える
- すべてのインスタンスがライブ移行に対応しているわけではない
- 対応していない場合は再起動移行をせざるを得ない
- ホスト間の再起動移行
- データセンター内の物理サーバがダウンしたときに、別の物理サーバに移行する
- 再起動が含まれるため、上で動いているアプリケーションは停止する
スケーリング
- 垂直スケーリング
- スケールアップ/ダウン
- CPU/メモリを増やしたり減らしたり
- 必ず同じHW/アーキテクチャである必要がある
- ダウンタイムが発生
- 変更前にインスタンスの停止が必要
- ボリュームやIPアドレスなどは変更なし
- スケールアップ/ダウン
- 自動スケーリング
- AutoScaling
- インスタンスの台数を増やしたり減らしたり
- スケーリング自体に追加コストは不要
- 自動スケーリングの設定の流れ
- 実行中のインスタンスから構成情報を取得する
- OSイメージ
- メタデータ
- シェイプ
- vNIC
- ストレージ
- サブネット
- インスタンスプールを作成
- プールのサイズ
- どこに配置するのか
- 異なる可用性ドメインを選択可能
- 3つの可用性ドメインに散らす必要がある
- インスタンスの停止、開始、終了を担う
- スケーリングルールを定義
- メトリックベースのルール
- CPUまたはメモリの使用量に応じて、スケールアウト/スケールイン
- 最大/最小の台数を定義
- スケジュールベースのルール
- 指定の日時でスケールアウト/スケールイン
- メトリックベースのルール
- 実行中のインスタンスから構成情報を取得する
Oracle Container Engine for Kubernetes(OKE)
- 概要
- コア
- マネージドなスケーラブルで可用性の高いサービス
- 開発
- 1クリックでクラスタを作成可能
- CLI/APIをサポート
- Arm/GPUベースのインスタンスをサポート
- DevOps
- 自動スケーリング
- 自動アップグレード
- クラスタ/ノードの自己修復
- コア
- コンポーネント
- コントロールプレーン
- Oracle管理
- ワーカーノード
- 顧客管理
- この分担はAWS/Azureと同じ
- コントロールプレーン
クラスタのタイプ
- 基本クラスタ
- k8sのコア機能をサポート
- SLOは定義されているが、SLAは定義されていない
- 基本使用料はかからない
- 拡張クラスタ
- 基本クラスタでサポートされていない拡張機能もサポート
- 定額使用料がかかる
- SLAが定義されている
管理
- 管理対象ノード
- コンピュートインスタンスが基本
- ノード管理はユーザー側で
- ノードへのsshも可能
- インスタンスを確保した時間に応じて課金
- 仮想ノード
- 拡張ノードでのみ利用可能
- サーバレスなオプション
- Fargateみたいな？
- セキュリティパッチなどが自動であたる
- sshによって直接接続はサポートされていない
- CPU/メモリを使った分だけ課金
コンテナインスタンス
- ECSみたいなもの
- OKEのような大規模なコンテナランタイムが必要ない時に使用
- コンテナイメージは、Docker Hubからも、コンテナレジストリ(OCR)からも指定が可能
Oracle Functions
- lambda相当
- 実行時間制限が5分(300s)
- もともと2分だったらしいが……
- 短すぎないだろうか
- デフォルトのメモリーおよびタイムアウト設定の変更
- 設定の流れ
- 実行したいコードが含まれたコンテナイメージをレジストリへpush
- ファンクションやトリガーの設定
- トリガー実行時のみコードが実行される
- ファンクション実行時のみ課金
- トリガー例
- OCIのイベント
- 直接呼び出し
- SDK/CLI/API
- ファンクション統合
- モニタリングやロギング機能と統合
ストレージ
提供されるストレージサービス
- ローカルNVMe
- ネットワークを介さない、唯一のローカル接続
- インスタンスストアに相当
- ブロックボリューム
- ネットワーク接続
- ブートボリューム/データボリューム
- EBSに相当
- ファイルストレージ
- ネットワーク接続
- NFSプロトコルで接続
- EFSに相当
- ネットワーク接続
- オブジェクトストレージ
- ネットワーク接続
- REST APIで接続
- S3に相当
- ネットワーク接続
データ転送サービス
- データ転送ディスク
- オフライン転送
- Snowball的なサービス
- データ転送アプライアンス
- オフライン転送
- Snowball的なサービス
- ストレージゲートウェイ
- オンライン転送
- オンプレミスとOCIが比較的高速なNWで接続
- ストレージゲートウェイ用のソフトウェアが提供されており、それを介して非同期通信
- オブジェクトストレージにデータを送る
オブジェクトストレージ
- リージョンサービス
- バケット
- リージョン内で一意の名前である必要がある
- ネームスぺース
- グローバルで一意の名前
- テナント名 or OCIが定めた名前
- リソースのURL
- 構文
- https://objectstorage.us-sanjose-1.oraclecloud.com/n/<ネームスペース名>/b/<バケット名>/o/<オブジェクト名>
- 例
- 構文
- オブジェクトストレージのレベル
- 注意：一度設定したストレージを変更不可
- 変更したい場合は、新しく作成してオブジェクトをコピーする
- 標準ストレージ層
- 高速、即時、頻繁にアクセス
- 最新のデータを保持するときに使用
- 頻度の低いアクセス・ストレージ層
- 頻繁にアクセスしないデータに最適
- 最小保存要件が31日
- オブジェクトを消してしまっても、31日は保持される
- Getにもコストが発生する
- アーカイブストレージ層
- アクセス頻度が低いデータ
- 最小保存要件が90日
- リストア時間が1時間
- Getするために1時間待つ必要がある
- リストア後は標準ストレージに保持されるため、ダウンロード時間は標準ストレージの費用が掛かる
- ダウンロード時間が定められる
- この時間以内にGetしないと、またリストア時間がかかってしまう
- デフォルト24時間
- 最小1時間、最大240時間
- 自動階層化
- ストレージ作成時も作成後にもON/OFFが可能
- 自動的に標準層/頻度の低いアクセス層に切り替えてくれる
- アーカイブ層との切り替えは不可
- 30日の保持期間は発生しない
- 自動階層化
- 注意：一度設定したストレージを変更不可
- オブジェクトライフサイクル
- 例
- 30日後に標準層からアーカイブ層に移動
- 180日後にアーカイブ層のオブジェクトを削除
- 例
- 自動バージョニング
- バージョン管理
- データの暗号化
- デフォルト暗号化される
- 暗号化しないことはできない
- 独自の暗号化キーを指定することも可能
- デフォルト暗号化される
ブロックボリューム
- コンピュートインスタンスにアタッチできる永続ディスク
- OCI側で冗長構成
- データが壊れる可能性は考慮不要
- 性能レベル
- IOPS毎に13段階で指定
- 大きくは4段階
- より低いコスト
- 2 IOPS/GB
- バランス
- 60 IOPS/GB
- 高いパフォーマンス
- 75 IOPS/GB
- 超高パフォーマンス
- 90-225 IOPS/GB
- より低いコスト
- 自動パフォーマンスチューニング
- パフォーマンスを自動的に再設定してくれるもの
- あくまで、デタッチしている時のみ
- 例
- アタッチしているときは高いパフォーマンスを利用
- デタッチしたときは低いコストのパフォーマンスで待機
- 再度アタッチしたときは高いパフォーマンスのものに変更
- 暗号化
- 暗号化は必須
- 独自キーを指定可能
- 転送時暗号化はON/OFF可能
- 1つのブロックボリュームを複数のインスタンスにアタッチ可能
- ただし、サブのインスタンスからは読み取りだけ可能
- オンデマンドでサイズ変更が可能
- 拡張だけできる
- 縮小はオンデマンド/オフライン状態どちらでもできない
- レプリケート
- リージョン間でコピーが可能
- ボリュームグループ
- ボリュームをグループ化して管理が可能
- しなくてもよさげ
- バックアップをする際に、このボリュームグループをまとめて……という形で指定
- ボリュームをグループ化して管理が可能
ファイルストレージ
- NFS v3、v4、v4.1、SMBに対応
- SMBには最近対応
- ファイル・ストレージの概要
- スナップショットでデータ保護
- 暗号化
- 保存時暗号化は必須
- 転送時暗号化はON/OFFできる
データ移行
- オンプレミス⇒OCI
- 帯域次第で利用サービスを使い分ける
- 低帯域の場合：データ転送サービス
- 高帯域の場合：ストレージゲートウェイ
- データ転送サービス
- データ転送ディスク
- 顧客側でディスクを用意
- データの暗号化が必須
- データをDL⇒検証⇒消去⇒ディスクを顧客に返送する
- データ転送アプライアンス
- 150TBまでの使用可能領域を持つストレージをOCIから借りて使用
- リージョンによってサイズは違う
- 東京リージョンの場合は95TBくらいだったはず
- データの暗号化が必須
- NIST 800-88に対応
- データをアプライアンスからDL⇒検証⇒消去
- 150TBまでの使用可能領域を持つストレージをOCIから借りて使用
- データ転送ディスク
- ストレージゲートウェイ
- dockerイメージとしてソフトウェアが提供
- 中継地点としての利用
- NFS V4を使用
データベース
Oracleデータベースオプション
- 仮想マシン(VM DBシステム)
- 高速プロビジョニング
- ベアメタル(BM DBシステム)
- 高速パフォーマンス
- RAC
- 2ノード構成
- マネージド高可用性
- Exadata DB
- マネージドなExadataインフラストラクチャ
- 大規模な構成の場合はこれ
- DBの中では最高峰と自称
- 最小利用期間はあるが、利用を停止することが可能
- Autonomous共有/専用
- 自動運転
- 自動保護
- 自己修復
- インフラはExadata
- 利用可能なDB
- MySQL Cloud Service
- OSS
- NoSQL Cloud Service(Key-Value)
- OSS
- Autonomous JSON DataBase
- これはOracleDB上で動作する
- MySQL Cloud Service
Autonomous Database
- 機械学習を用いてデータベースの運用を自動化
- インフラストラクチャの自動化
- 完全なデータベースの自動化
- 自動化されたデータセンター業務と機械学習
- デプロイオプション
- サーバレス
- DBのみをプロビジョニング、管理
- OracleがExadataのインフラストラクチャのデプロイと管理を処理
- ATPとADWの両方に対応
- 専用
- Exadataを排他的に使用
- その顧客専用
- ATPとADWの両方に対応
- Exadataを排他的に使用
- サーバレス
- ワークロードタイプ
- Autonomous Transaction Processing(ATP)
- Autonomous Data Warehouse(ADW)
- Autonomous JSON Database(AJD)
- NoSQLドキュメントストア
- ドキュメントの最大サイズは32MB
- Autonomous JSON Database 技術概要
- APEX Service
- 低価格だが、機能制限が多い
- 開発環境用
- 完全なデータベース自動化
- プロビジョニング
- スケールアップ/スケールアウト
- チューニング
- セキュリティとパッチ適用
- フォルトトレランス
データベースシステム
- Oracleインスタンス
- Enterprise EditionまたはStandard Edition 2
- Oracle Database 11.2、12c、18c、19c、21c
- ライセンスの4つのオプション、またはBYOL
- 管理
- 仮想マシンまたはベアメタル
- 世界のリージョンで利用可能
- クラウドの自動化
- プロビジョニング、バックアップ、パッチ、ディザスタリカバリ
- 仮想マシンとベアメタルオプション
- 仮想マシン上のOracle DB
- 最大24 CPU
- サービスを止めれば増減可能
- 最大320 GB RAM
- サービスを止めれば増減可能
- 最大40TBのブロックボリューム
- 動的拡張は可能
- 最大24 CPU
- 仮想マシン上のOracle RAC
- 最大48 CPU
- 片系だけ止めて、全体としては停止なく増減可能
- 最大640 GB RAM
- 片系だけ止めて、全体としては停止なく増減可能
- 最大40TBのブロックボリューム
- 動的拡張は可能
- RACは2ノードまでしか組めないので
- 最大48 CPU
- ベアメタル上のOracle DB
- 最大52 CPU
- 768 GB RAM
- 最大16TBのNVMeローカルボリューム
- ローカルをフルに使用しているため、増減は不可
- 標準3冗長化しているため、冗長化解除しないと16TBにできない
- 仮想マシン上のOracle DB
Oracle MySQL
- DB作成時のオプション
- 高可用性
- 自動フェイルオーバーとデータ損失ゼロのフォールトトレラントとシステム
- 3つのDBインスタンスを自動作成
- RTOは分単位/RPOはゼロ
- スタンドアロン
- 単一DBインスタンス
- 高可用性
- MySQL HeatWave
- ETL不要でMySQLデータベースに対して簡単に高性能な分析が可能
- OLTP/OLAPアプリケーションのワークロードに対応
- トランザクション用のDBと分析ツール用のDBをまとめて1つのMySQLDBで賄える！
- MySQL HeatWave：サービス概要のご紹介
セキュリティ
概要
-
共有セキュリティモデル
- 責任共有モデルに相当
クラウドガード
- 概要
- 問題の検出
- 構成のチェック
- アクティビティのモニター
- 応答の適用
- 問題の関連付け
- 修正の適用
- 問題の検出
- Security Hub的な機能
- GuardDutyとCongfigを混ぜたような？
セキュリティゾーン
- 特殊なコンパートメント
- セキュリティゾーンレシピが紐づく
- デフォルトはすさまじく強いレシピが紐づいている
- これをカスタマイズできる
- セキュリティゾーンレシピ とは
- 何かしらのセキュリティ要件を強制させるもの
- 例
- プライベートサブネットの強制
- パブリックサブネットの作成を禁止させる
- 顧客管理マスター暗号化キーの利用を強制
- OCI管理の暗号化キーの利用を禁止させる
- プライベートサブネットの強制
- セキュリティアドバイザ
- セキュリティゾーンレシピに沿ったインスタンスの作成などを支援
- ウィザードで順繰り作れるようになる
ボールト
- 暗号化キーを管理
- サポートしている暗号化アルゴリズム
- AES、RSA、ECDSA
- 保護モード
- ソフトウェア
- ハードウェアセキュリティモジュール(HSM)
- 暗号化キーのローテーションにも対応
- 2層階層 エンベロープ暗号化
- マスターキーとデータキーの2段階
- データの暗号化はデータキー
- データキーの暗号化にマスターキー
- キーのソフト削除
- 一定期間後にキーを削除
- 最短7日後
- 暗号化/複合化の流れはAWS KMSと同じ
ガバナンスと管理
価格設定
価格モデル
- Pay as you go(PAYG)
- 利用したリソースに対してのみ課金
- 前払い不要
- 最小利用期間もない
- 年間ユニバーサルクレジット
- 前払いで年間プールとして管理
- 大幅な節約になる
- 12か月以内にクレジットの消費義務あり
- BYOL
- 現在所持しているOracleライセンスを適用
- これだけ使うということはなく、OracleライセンスはBYOLし、インフラコストはPAYGか年間ユニバーサルを使用する
課金対象
- リージョン毎に価格は変わらない
- データ転送料金のみ価格が異なる
- データ転送費用
- イングレスはコストがかからない
- エグレスはコストがかかる
- そのリソースから見たときの矢印になるので注意
- Fast Connectは時間課金のコストが発生
- IN/OUTのコストはかからない
コスト管理
- OCI Budget(予算)
- テナントの予算管理
- コンパートメント毎に予算を管理
- 設定した予算を超えそうな場合に通知
- Budgetに相当
- Cost Analysis
- コスト発生個所の分析
- どのサービスにコストがかかっているのかなどを調査
- Cost Explorerに相当
- 使用状況レポート
- CSV形式で使用状況を出力
- 可視化はユーザー側で実施する必要あり
- サービスの制限と使用状況
- ユーザー側ではなく、OCI側で利用の上限を定義 - リクエストを上げることで上限解放が可能
- Service Quotasに相当
- コンパートメント割り当て
- 管理者側で、コンパートメント内に作成できるリソースなどの制限を掛けることができる
- 最大数を定義することも、作成させない(0を定義)することもできる
タグ付け
- 自由形式タグ
- 自由に設定できるタグ
- 定義済みタグ
- タグを設定することを強制化
- 値のところをユーザー側で指定が可能
- タグネームスペースに含める必要がある
- 構文：<ネームスペース>.<キー>.<値>
- 例：Operations.Environment."Production"
- 値のところは、文字列を自由に指定させることも、リスト化することも可能
- コストトラッキング用のタグとしても利用可能
Oracle Support Rewards
- OCIの消費に基づいて支払いを削減するための新しいサポートのメリット
- OCIを多く使えば使うほどお得になる
- OCIサービスの月間総消費量に基づいて、各月末に獲得
- お得になるのはリソース使用料ではなく、テクニカルサポートのコスト
- VMWareなど、3rd Prtyのテクニカルサポート費用には転嫁できない
- あくまでOCIが提供しているサポートのみ
結果
- OracleLearnのコースとこのメモを用いることで、83%の得点率でした！
- まあ……触ったことがないクラウドであればこんなもんでしょうか。