Oracle Cloudで考える 高可用性アーキテクチャ Oracle Cloud Infrastructure High Availability Architecture Oracle Cloud Infrastructure 技術資料 2025年6月 

Design For Failure – 障害に備えて設計しよう ! Copyright © 2025, Oracle and/or its affiliates. 2 • サーバーは落ちるもの、データセンターは止まるもの • Oracle Cloudも他人事ではない • IaaS/PaaSではアプリケーションの障害からの回復の最終責任はユーザーが負う • 高可用性実現にかかるコストと複雑性を、軽減できるリスクに対してうまくバランスさせ る : お客様の責任範囲 : オラクルの責任範囲 ファシリティ ハードウェア 仮想基盤 OS ミドルウェア アプリケーション IaaS ファシリティ ハードウェア 仮想基盤 OS ミドルウェア アプリケーション PaaS ハードウェア 仮想基盤 OS ミドルウェア アプリケーション SaaS ファシリティ 

Copyright © 2025, Oracle and/or its affiliates. 3 クラウドで「高可用性」をどう実現するか? 

機器障害 サイト障害 広域災害 障害のレベルと一般的な対策 Copyright © 2025, Oracle and/or its affiliates. 4 制約・コスト 小 可用性 大 耐障害性(Fault Tolerance)の強化 = 落ちにくいシステムを作る • 稼働リソースの冗長性の確保 • 性能やリソース余剰のモニタリング 復元性(Resiliency)の強化 = 落ちても復旧できるシステムを作る • 障害検知の強化 • データや構成情報のバックアップ • リソース再構成(復旧)の自動化 • リカバリ手順の確認、テスト、訓練 

クラウドにおける高可用性の考え方とは？ Copyright © 2025, Oracle and/or its affiliates. 5 オンプレミスの時と本質的な考え方は同じ 幸いクラウドでは高可用性構成の実装がオンプレミスと比べ手頃な価格に • 耐障害性(Fault Tolerances)や復元性(Resiliency)を備える堅牢なリソースが用意されている • ユーザーによる高可用性構成の実装をサポートする機能を簡単に利用できる クラウドを使って以下を目指す! • オンプレで実装していた高可用性構成をより低コストで実現する or • オンプレでは諦めていたより高いレベルの可用性を実現する ・・・ How? 

Copyright © 2025, Oracle and/or its affiliates. 6 MAA – Maxiumum Availability Architecture そもそも何者か? そしてクラウドでどう活用するのか? 

https://www.oracle.com/jp/database/technologies/high-availability/maa.html Oracle Maximum Availability Architecture Copyright © 2025, Oracle and/or its affiliates. 7 • Oracle の開発チームによる、実証済み高可用性テクノロジーと、 お客様の成功事例に基づいたOracleのベスト・プラクティスのブループリン ト • コストと複雑さを最小限に抑えながら、オラクルのお客様が最適な高可用 性とデータ保護、そして障害時リカバリを実現できるようにすることを目 標に開発 • MAAは、さまざまなSLA別の構成プラクティス、ライフ・サイクルやベス ト・プラクティスを達成するためのリファレンス・アーキテクチャで構成 • データベースから発展し、クラウド、ミドルウェア、アプリケーションな どのシステムの広い領域をカバー • 高可用性、ディザスタ・リカバリおよびデータ保護を重視 • 非エンジニアド・システム、エンジニアド・システム、非クラウド、およ びクラウドのデプロイメントに適用できる 

Oracle Maximum Availability Architecture Copyright © 2025, Oracle and/or its affiliates. 8 • 可用性の要件レベルに応じて Bronze から Platinumまでの4つのリファレンス・アーキテクチャを設定 • 適切なリファレンスを選択することで、コストと複雑さを最小限に抑えながら最適な高可用性とデー タ保護、そして障害時リカバリの実装モデルを参照できる 

Press Release エディオン、大規模基幹システムを Oracle Cloud Infrastructureに全面移行 Oracle Cloud Infrastructure上に自社主導でOracle Exadataを含む100台以上の仮想化サーバーと物理 サーバーを全面移行し、災害復旧環境も構築。東 京・大阪の2拠点で合計200以上のコンピュート・ インスタンス、2つのOracle Exadata Cloud Service を活用した基幹システムが稼働。スピード経営に 不可欠なシステム変革を加速 Tokyo, Japan—2021/03/01 • 「Oracle Cloud Maximum Availability Architecture(MAA)」で推奨される最適な高可 用性構成を実装 • 24時間365日稼働する基幹システムに不可欠な高 いレベルの可用性とデータ保護を実現し、事業継 続性を強化 • アプリケーションのテストを短期間で実施す るために「Oracle Real Application Testing」を活 用 • データベースの移行には「Oracle GoldenGate」、「Oracle GoldenGate Veridata」 に加え、ファイル移行にはカスタムで開発し たツールを活用 • 一括移行、差分移行、切戻しの仕組みを可能にし、 3時間以内で確実な移行に成功 お客様事例 : エディオン様 MAAを採用し基幹システムをクラウドに移行 Copyright © 2025, Oracle and/or its affiliates. 9 

構成のポイント • 可用性重視(複数リージョン、サーバー冗長あり) • 東京、大阪のマルチリージョンを構成し、サーバーは全 て冗長化 • リージョン間はレプリケーションを構成 • DB層 : Data Guard • AP層/その他 : ストレージレベルのレプリケーション • 四半期メンテナンス毎に定期的にプライマリ・リージョ ンとスタンバイ・リージョンを切り替え エディオン様事例 : 東阪のマルチリージョンによるMAA GOLD 相当の構成 Copyright © 2025, Oracle and/or its affiliates. 10 DNS 東京リージョン FD1 FD2 Database(RAC) WebAP 大阪リージョン FD1 FD2 Database(RAC) WebAP Backup Backup フェイルオーバー or ロードバランス Data Guard Replication 

Copyright © 2025, Oracle and/or its affiliates. 11 Oracle Cloud Infrastructure における MAAの構成要素 

要件の目安 • 計画メンテナンス : RTO=0 / RPO=数分~数時間 • アップグレード : RTO=0 / RPO=数時間 • リカバリ可能な障害 : RTO=0 / RPO=数分~数時間 • リカバリ不可能な障害 : RTO=前回バックアップ / RPO=数時 間 • サイト障害、広域災害 : 考慮しない 構成のポイント • コスト重視(サーバー冗長なし) • 各レイヤーのサーバーは同じフォルト・ドメインに集中し て配置し、機器障害やメンテナンスによるダウンタイムを 最小化 • バックアップとしてオブジェクト・ストレージを活用 • コンピュート障害時は再作成 • DB障害時はバックアップからリカバリ BRONZE- 単一リージョンの非冗長化構成 Copyright © 2025, Oracle and/or its affiliates. 12 東京リージョン FD1 Backup LB Subnet Web/AP Subnet DB Subnet 

ブロック・ボリューム : 独立し、冗長化された永続ストレージのサービス • コンピュート・インスタンスにアタッチするだけで簡単に永続化ブロックデバイスとして利用できる • コンピュートから独立しているため、ホスト障害時にもデータが保全 • 同じ可用性ドメイン内に複数のミラーを内部的に保持(ユーザーによるRAIDなど不要) • 99.99%(Four-nine)の耐久性設計 • 複数インスタンスから同時アタッチ可能(共有ディスクとしての利用) • デフォルトで暗号化 • 可用性をさらに高める仕組みを利用可能 • オブジェクト・ストレージへのバックアップ(アドホック、定期、差分) • レプリケーション(別可用性ドメイン宛、別リージョン宛) • ユーザー管理鍵を利用した暗号化の強化 永続化が必要なデータは、インスタンス内蔵ディスク(DenseIO)ではなく ブロック・ボリュームに格納するのが推奨 永続化データはブロック・ボリュームに格納する Copyright © 2025, Oracle and/or its affiliates. 13 ・・・ インスタンス Block Volume 

バックアップはオブジェクト・ストレージに取得する Copyright © 2025, Oracle and/or its affiliates. 14 ORACLE CLOUD INFRASTRUCTURE(REGION) Availability Domain 1 Availability Domain 2 Availability Domain 3 オブジェクト・ストレージ データが3つ以上のデバイスに保管 オブジェクト・ストレージの耐障害性は非常に高い • オブジェクトを置くと、リージョン内の物理的な3 つ以上のデバイスにデータが書き込まれる • リージョン内に複数の可用性ドメイン(データセン ター)がある場合には、全ての可用性ドメインに データが配置 • 99.999999999%(Eleven-nine)の耐久性設計 • 99.9%の可用性SLA 様々なサービスのバックエンドで利用 • ブロック・ボリュームのバックアップ • イメージ、カスタム・イメージ • データベースのバックアップ • ロギングサービスの出力先 など 容量あたりの単価が安い • 1TBあたりStandard ¥3,912.98/月、Archive ¥398.97/月 

OCIでは、対象シェイプのVMインスタンスでインフラ障害が発生した場合、 自動的にインスタンスをリカバリし、正常なホスト上でVMをリストアする ように試みる • おおよそ数分〜十分程度で自動リカバリが可能 • インフラ障害は発生から1分以内に検知 • 正常なホストへの移動と再起動は5分以内に自動的に開始 • 参考 : インフラストラクチャ障害によるVMリカバリ 注意すべき点 • 全てのシェイプをカバーするわけでない(Standard, GPUのみ対象) • ハードウェアより上のレイヤーの障害は検知不能(プロセス障害、CPU 高騰によるハングなど) OCIデフォルトの仮想マシン自動再起動機能(とその限界)を知る Copyright © 2025, Oracle and/or its affiliates. 15 障害 物理ホスト VMインスタンス 自動再起動 物理ホスト 

インスタンス障害時に素早く別インスタンスで復旧する(ことも考える) Copyright © 2025, Oracle and/or its affiliates. 16 ブート ボリュー ム 停止 launch インス タンス インスタンス ブロッ ク・ボ リューム デタッチ アタッチ インス タンス インス タンス ブート ボリュー ム 別インスタンスからの利用 別インスタンスでのアタッチ コンピュート・インスタンス障害時に自動再起動 を待つのではなく、明示的に別インスタンスを作 成することで可用性を向上させる • RTOの短縮 • 自動再起動でカバーされない障害から救う(プ ロセス障害など ブロック・ボリュームに永続化されていたデータ は、別インスタンスを起動してすぐに利用可能 同一の可用性ドメイン(AD)での復旧のみ可能(別 ADや別リージョンで復旧するにはデータの複製が 必要) もちろんインスタンス障害は単純な「リブート」 で復旧する場合があるので、システム特性やケー スバイケースで考える 

インスタンス・プール(Instance Pool) • コンピュート ・インスタンスを集合として管理 • ステータス(開始、停止、終了)およびターゲット・ インスタンス数を一括管理 • ロードバランサー とセットでの利用を推奨 (インスタンスが再作成されてもトラフィックが維 持される) 非冗長化構成(Bronze)でもターゲット・イン スタンス数を1に設定しておけば、自動的に 数を保持してくれる • インスタンス停止時には同じインスタンスを再起動 • インスタンス終了時には別インスタンスを作成 ※ 再起動までの時間はインスタンスの状況により異 なる(15~20分程度が多い)ため、必ず検証の上 ご利用 ください インスタンス・プール を用いて稼働インスタンス数を維持する Copyright © 2025, Oracle and/or its affiliates. 17 インスタンス 構成 Instance Pool 起動 ターゲット・インスタンス 数 : 3 既存インスタンス ロード・バランサ トラフィックを 分散 

仮想マシン・インスタンスのライブ・マイグレーションを利用し、ホストの メンテナンスによる停止を抑止する Copyright © 2025, Oracle and/or its affiliates. 18 VMインスタンス メンテナンス ライブ・ マイグレー ション 物理ホスト 物理ホスト OCIの仮想マシン・インスタンスでは、ハードウェアの故障、セキュリティパッチの適用などのメンテナ ンスの際に、可能であればVMインスタンスを中断/再起動せずに正常なホストへライブ・マイグレー ションするようにデフォルト設定されている(Document) • メンテナンスによるアプリケーションへの影響を瞬断レベルまで抑えることが可能 • ただしライブ・マイグレーションに失敗した場合は、再起動移行(リブート・マイグレーション)機能 によってインスタンスが再起動され、ユーザーに通知(Reboot Detected)が送付される • 基本はデフォルトのまま利用を推奨、ただし予期せぬ再起動をゼロにしたい場合は、無効化(オプト アウト)可能。その場合は再起動移行のタイミングをユーザーが指定することができる(2週間以内) 

OCIモニタリングでリソース状態を常に監視 • サービスやリソースの性能や状態のメトリックを取得 • コンピュート・インスタンス、VNIC、ブロック・ボリューム、 ロードバランサーなど • 事前定義済のビジュアライゼーション・ダッシュボードの提供 • カスタム・メトリックも定義可能 • 可用性SLA : 99.9% OCIアラームによる警告の発報 • メトリックに対してアラームを作成することも可能 • アラームは通知サービスもしくはストリーミング・サービスと連 携して、 指定した条件のトリガーにメトリックが合致した場合に通知 実績のあるサードパーティ製ツールも使える • Datadog • JP1 • Zabbix • Hinemos OCI Monitoring で リソースの状態を常に監視する Copyright © 2025, Oracle and/or its affiliates. 19 OCI サービ ス メトリック アラーム Notifications CPU : 80 CPU : 90 CPU : 40 CPU : 50 Customer Applications, Services, Resources OCIコンソー ル Customer Monitoring Tool Monitoring CPU : 85 CPU : 45 集計データ 生データポ イント トリガー・ ルール Streaming 

OCI DNS でDNSをDoS攻撃から保護する Copyright © 2025, Oracle and/or its affiliates. 20 Cloud1 Datacenter1 IP Group A IP Group B IP Group C Cloud2 CDN ISP IP Group D DNS ユーザー DNS参照 グローバルレベルの耐障害性 • エニキャストDNS(単一のグローバルIPで世界 中のDNSサーバーが応答) マルチシステム対応 • OCI、他クラウド、CDN、オンプレミス DNSトラフィック管理 • グローバルロードバランシング • フェイルオーバー • ジオロケーション・ステアリング • AS番号ステアリング • IP接頭辞ステアリング 

カスタム・イメージ等を活用してインスタンスをイミュータブル(＝不変、作 成後に変更しない)にする Copyright © 2025, Oracle and/or its affiliates. 21 イミュータブルにするために • カスタム・イメージを活用してベースラインを作成 • IPアドレスは固定しない • IP直指定や/etc/hostではなく、DNSを利用して名前 解決する • cloud-init(作成時に実行されるスクリプト)の活用 • ホスト情報はインスタンス・メタデータから動的に 取得 • データは外部の永続化ストレージに格納する (RDBMS 、FSS、Object Storage) • セッション情報も外部に格納する(Redis、Coherence など)、またはステートレス/Idempotent化 • ログも外部に格納する(Object Storage) イミュータブルにするといいことは? • いつインスタンスを再作成してもOK、インスタン スプールによる自動復旧も可能 • 障害時にも、既存インスタンスを諦めていち早く 新規インスタンスを立ち上げて復旧できる • 自動スケーリングにも対応 • 開発環境、テスト環境などの立ち上げが簡単 • コンテナ化、Kubernetesの活用、Blue-Greenデプロ イメント、カナリアリリース、マイクロサービ ス・・・とか 

可用性要件の目安 • 計画メンテナンス : RTO=0 / RPO=0 • アップグレード : RTO=0 / RPO=数時間 • リカバリ可能な障害 : RTO=0 / RPO=数秒~数分 • リカバリ不可能な障害 : RTO=前回バックアップ / RPO=数時間 • サイト障害、広域災害は考慮なし(データのみ退避) 構成のポイント • コストと可用性のバランス • 各レイヤーのサーバーは全て冗長化 • 異なるフォルト・ドメインに分散配置し、機器障害 やメンテナンスによるダウンタイムを防止 • Web/APの永続化ストレージ、DBのバックアップと してオブジェクト・ストレージを活用 • バックアップは遠隔地にレプリケーション SILVER- 単一リージョンの冗長化構成 (+ 遠隔地バックアップ) Copyright © 2025, Oracle and/or its affiliates. 22 東京リージョン FD2 Backup LB Subnet Web/AP Subnet DB Subnet FD1 Database(RAC or Data Guard) 大阪リージョン Replicated Backup (Option) 

冗長化の構成にあたってはリソースの存在場所の意識が大切 すべてのOCIのリソースは存在する場所(有効範囲) が決まっている、有効範囲は大きさ別に4段階存 在 (ドキュメント) • グローバル • 作成すると、全てのリージョンで使えるようにな るもの • リージョン • 作成すると、そのリージョン内でのみ使えるよう になるもの • 可用性ドメイン • 特定の可用性ドメインを指定して利用するもの • フォルト・ドメイン • 特定のフォルト・ドメインを指定して利用するも の リソースの有効範囲を意識して適切に配置する Copyright © 2025, Oracle and/or its affiliates. 23 Oracle Cloud Infrastructure リージョン - Phoenix リージョン - Asuburn AD1 AD2 AD3 AD1 AD2 AD3 可用性ドメインに有効なリソース グローバルに有効なリソース リージョンに 有効なリソース フォルト・ドメインに有効なリソース 

日本 の OCIリージョンの構成を知る 東京リージョン、大阪リージョンは、1ADずつで 構成 • 可用性ドメイン x 1 • フォルト・ドメイン x 3 • Transit POP(FastConnect接続点) • 東京 x2 : Equinix TY4、NEC印西 • 大阪 x1 : NTT堂島テレパーク リソースの配置場所を適切に選択する Copyright © 2025, Oracle and/or its affiliates. 24 東京リージョン 大阪リージョン 可用性ドメイン1 可用性ドメイン1 フォルト・ドメイン1 フォルト・ドメイン2 フォルト・ドメイン3 フォルト・ドメイン1 フォルト・ドメイン2 フォルト・ドメイン3 Transit POP Transit POP Transit POP 

可用性ドメイン と フォルト・ドメイン 可用性ドメイン(AD) : サイトレベルの分散に利用 • AD = 1つ以上のデータセンターから構成されるリージョン内の独立したファシリティ • 各ADは建屋、電源、冷却装置、ネットワーク接続が独立、火災などの災害時に影響を受けるADは1つのみ • 複数ADは一部のリージョン(Phoenix, Ashburn, Frankfurt, London)でサポート • 可用性ドメイン(AD)間は 広帯域(>=1Tb/sec)、低レイテンシー(< 片道0.5ms)のネットワークで接続(通信は無償) フォルト・ドメイン(FD) : サーバーレベルの分散に利用 • FD = AD内のハードウェアやインフラのセット／可用性ドメイン内で同時にハードウェア障害やメンテナンス停止 が発生する可能性のある単位 • 1つの 可用性ドメインにつき3つのフォルト・ドメインで構成 • 全てのリージョンの全ての可用性ドメインで利用可能 リソースの配置場所を適切に選択する Copyright © 2025, Oracle and/or its affiliates. 25 リージョン AD1 AD2 AD3 Rack Rack Rack FD1 FD2 FD3 

フォルト・ドメインを活用しインスタンス配置場所を適切に選択して冗長化 インスタンスの冗長構成を作る • 各インスタンス作成時にフォルト・ドメイン指定が可能 • 配置場所を分離することで、障害やメンテナンスの影響を限定化 • 1 可用性ドメイン内でも、コンピュート・インスタンスの配置を別フォ ルト・ドメインに分けることで、複数インスタンスに同時に障害やメン テナンスが発生することを回避 インスタンス作成時に、配置する フォルト・ドメインを指定可能。 明示的に指定しなくてもインスタン スは必ずどこかのフォルト・ドメイ ンに所属する Copyright © 2025, Oracle and/or its affiliates. 26 OCI リージョン 可用性ドメイン 1 フォルト・ドメ イン1 フォルト・ドメ イン3 フォルト・ドメ イン2 可用性ドメイン 2 可用性ドメイン 3 

フォルト・ドメインを利用した冗長構成例 Copyright © 2025, Oracle and/or its affiliates. 27 FD FD FD 自動スケーリング 負荷に応じて インスタンスを増減 FD FD Real Application Clusters Active-Activeクラスター Replication / Data Guard 同期/非同期レプリケーション と障害時フェイルオーバー FD FD FD ロード・バランシング 複数インスタンスに トラフィックを分散 FD FD Load Balancer IPフェイルオーバー 障害時に仮想IPを使いト ラフィック経路を切替 Kubernetes Kubernetesの実行ノード を分散 VMware Solution VMware実行環境の分散と レイヤー2接続 HA / クラスタリング 障害時にスタンバイノード に切り替え FD FD FD FD IP IP FD FD FD FD FD FD 

トラフィックの高可用性をサポート • 1つのエントリ・ポイントから複数 サーバにトラフィックを自動配信 • 複数の可用性ドメイン(AD)に対して トラフィックを伝達 • バックエンドのダウン＆アップに応 じて、動的に転送先を変更 LB自体もサイトレベルの耐障害性 • 可用性ドメイン or フォルト・ドメイ ン間での冗長化 • 2つ以上の処理ノードがActive-Active で稼働し、単一障害時にも処理を継 続 ロード・バランサを活用する Copyright © 2025, Oracle and/or its affiliates. 28 AVAILABILITY DOMAIN-1 AVAILABILITY DOMAIN-2 VCN SUBNET Backend Servers バックエンド・ セット Backend Servers SUBNET Load Balancer (Active) Load Balancer (Active) リスナー パブリック IPアドレス Load Balancer Pair Internet Gateway 

自動スケーリング(Autoscaling)を活用する Copyright © 2025, Oracle and/or its affiliates. 29 最小サイズ 初期サイズ スケーリングルール スケール前のインスタンスプール スケール後のインスタンスプール If CPU or Memory > 70% add 2 Instances If CPU or Memory < 70% remove 2 instances 最大サイズ 初期サイズ • システムの負荷(CPU/メモリ使用率)をもとに動的にインスタンス数を増減 • ロード・バランサと組み合わせると自動的にトラフィックを分散 • 指定したフォルト・ドメインや可用性ドメインにインスタンスを分散配置 

VIP-2 IP-1 セカンダリIP を利用して別インスタンスへのIPフェイルオーバー Copyright © 2025, Oracle and/or its affiliates. 30 ORACLE CLOUD INFRASTRUCTURE(REGION) AD-1 AD-2 IP-1 VIP-2 VNIC1 primary Regional Subnet 10.0.1.0/24 VNIC1 primary primary primary VM1 VM2 インスタンス障害時のIPフェイルオーバー • インスタンスの仮想NIC(VNIC)には複数のセカ ンダリIPを付与できる(図のVIP-2) • VM1が障害を起こした場合、VIP-2をVM2に付 け替えることでトラフィックをフェイルオー バー • セカンダリIPは別のフォルト・ドメインや別 の可用性ドメインのインスタンスにも移動で きる 参考 : Pacemakerを使って仮想IPを別ADのインスタンス に自動フェイルオーバーする 

• 複数のコンピュート・インスタンスから一つのブロック・ボリュームを read/writeモードで同時にアタッチすることが可能。 • インスタンスへのアタッチ時にアクセス方法を以下から選択 • 読取り/書込み • 読取り/書込み – 共有可能 • 読取り専用 – 共有可能 • 「読取り/書込み - 共有可能(read/write – sharable)」を選択する場合 • 複数からの同時書き込みによるデータ破損を防止するために、ユーザー側でなんら かのクラスタ・ソフトウェアやクラスタ・ファイルシステムの導入が必要 • NEC CLUSTERPRO X • SIOS Lifekeeper/Datakeeper • OCFS2 など • OCI単独では同時書込み操作の制御は実施しない • 注)OCI上でのOracle RACは、これまでどおりOCI Database、ExaCS、ADBなどの PaaSのみでのサポート、IaaS上でのRACはサポートされません ブロック・ボリュームのマルチアタッチ機能を利用したHAクラスター Copyright © 2025, Oracle and/or its affiliates. 31 ブロック ボリューム クラスタウェア or クラスタファイルシステム 

https://jpn.nec.com/clusterpro/blog/20200602.html (参考) NEC CLUSTERPRO X を用いたHAクラスター構成 Copyright © 2025, Oracle and/or its affiliates. 32 

https://bccs.sios.jp/usecases/oci.html (参考) SIOS LifeKeeper を用いたHAクラスター構成 Copyright © 2025, Oracle and/or its affiliates. 33 

高可用性と開発生産性を両立するKubernetesプラットフォーム Container Engine for Kubernetes(OKE)でコンテナを堅牢にする Copyright © 2025, Oracle and/or its affiliates. 34 ポッドの配置と自動管理 • コンテナ化されたアプリケーションをデプロイ、 管理 クラスタとノードプールの自己回復 • 仮想サーバー/ベアメタルサーバーをノードプール に追加 • ダウンしたノードで稼働していたポッドは正常 ノードに移動し稼働を継続 • ノードプール下に新しいノードが再作成されクラ スタを回復 Virtual Machine OKE OCI Registry Service Broker Load Balancer Object Storage Database System 

高性能、高可用性を実現するOracle Database の究極のプラットフォーム Oracle Databaseの高可用性プラクティスが 詰まったExadataを、OCIではクラウド・サービス として提供 • 全てのコンポーネント、サービスが多重化 • 様々な自己復元機能を搭載 • Real Application Clusters & Oracle Clusterware : DB サーバーノードのクラスタ • Service : データベース・サービスを複数ノード上 で抽象化 • SCAN Listener : 接続サービスをクラスタレベルで 抽象化 • Automatic Storage Management : 堅牢な共有スト レージ管理 Exadata Cloud Service / Autonomous Database を使う Copyright © 2025, Oracle and/or its affiliates. 35 Oracle Clusterware Real Application Clusters Service Automatic Storage Management SCAN Listener 

クラウド・サービスの機能でData Guardを簡単に構築する Copyright © 2025, Oracle and/or its affiliates. 36 AD-1 AD-2 Region-A Standby DB Primary DB Standby DB 同一AD 別AD Region-B AD-1 別リージョン Standby DB OCIのOracle Databaseサービス群は、Data Guard を簡単に構成可能 • 同一ADまたは別AD、別リージョンのDB間で構 成 • 管理用 Data Guard Broker が有効 • Compute + 手動 Data Guard 構築も可能 • White Paper : Hybrid Data Guard to Exadata Cloud Services OCI Documentation(日本語) Exadata DB システム> Exadata DBシステムでのOracle Data Guardの使用 

冗長化されたDBの切り替え、スケーリング時にもアプリケーションにエラーを返さない • アプリケーション・コンティニュイティと Oracle Real Application Clustersを使用 • 障害発生時にセッションの情報を透過的に追 跡および記録 • アプリケーションを変更せずに機能するよう、 データベースの内部にビルトイン • 計画外停止時にセッション状態を再構成し、 処理中のトランザクションを再実行 • 計画メンテナンス時は、TACを使用して1つ以 上のノードからセッションをドレインするこ とにより、計画メンテナンスを実施可能 • アプリケーション変更に適応 : 将来を見据えた保護 透過的アプリケーション・コンティニュイティ(TAC) Copyright © 2025, Oracle and/or its affiliates. 37 リクエスト エラー/タイムアウトが隠され る 透過的アプ リケーショ ン・ コンティ ニュイティ 

DBサーバーの更新時に 1 分のブラックアウトを1秒以下に削減 透過的アプリケーション・コンティニュイティの効果 Copyright © 2025, Oracle and/or its affiliates. 38 

インターネットVPN 接続経路を冗長化する Copyright © 2025, Oracle and/or its affiliates. 39 東京リージョン Transit POP 可用性 ドメイン Virtual Machine Database System 顧客サイト 顧客ルーター (CPE) VPN エンドポイント IPsec接続 インターネットVPN経路の冗長化 • VPN接続のゲートウェイ(DRG : Dynamic Routing Gateway)には、2つのVPNエンドポイントが構 成 • それぞれのエンドポイントに対し、顧客サイ ト側の別の物理ルーターから複数のIPsec接続 を張ることで冗長化 • 冗長化された経路に対しては、OCI側からは等 価ルーティング(ECMP)が行われる 

FastConnect x2 で経路を冗長化 • 各リージョンには専用線/閉域網の接続ポイント (Transit POP)あり、Transit POPにはFastConnectルー ターが冗長化されて設置 • FastConnectサービスを2ポート契約することで物 理的にポートおよびルーターを冗長化 • 冗長化されたポート(ルーター)に対し別回線(物理回 線 or 仮想回線)を接続することで、経路を冗長化 (注)回線の冗長化方法は接続プロバイダや方式によ り異なるため、左図の限りではありません または、主 : FastConnect、副 : インター ネットVPNも可能 • 優先経路はBGPで制御 専用線/閉域網 接続経路を冗長化する Copyright © 2025, Oracle and/or its affiliates. 40 東京リージョン Transit POP 可用性 ドメイン Virtual Machine Database System 顧客サイト 仮想回線 閉域網 顧客ルーター (CPE) FastConnect ルーター 

バケットのレプリケーション機能を使ってデータを転送 オブジェクト・ストレージのバケットから別バ ケットへのレプリケーション • 宛先は同一または別リージョン • バケット単位での設定 レプリケーションの動作 • 非同期レプリケーション • レプリケーション設定後にソースバケットの オブジェクトを操作(アップロード、削除)する と自動的に宛先バケットに反映される • レプリケーション先バケットは読み取り専用 となる バックアップを別リージョンに遠隔地転送する Copyright © 2025, Oracle and/or its affiliates. 41 OCI Tokyo Region Compute VCN Object Storage （ソースバケット） Database System OCI Osaka Region Compute VCN Object Storage （宛先バケット） Database System レプリケーション 

可用性要件の目安 • 計画メンテナンス : RTO=0 / RPO=0 • アップグレード : RTO=0 / RPO=数秒 • リカバリ可能な障害 : RTO=0 / RPO=数秒 • リカバリ不可能な障害 : RTO=0 / RPO=数秒 • サイト障害、広域災害時も業務継続 構成のポイント • 可用性重視(複数リージョン、サーバー冗長あり) • 複数リージョンをActive-ActiveまたはActive-Passiveで 利用 • 各レイヤーのサーバーは全て冗長化 • 異なるフォルト・ドメインに分散配置し、機器障害 やメンテナンスによるダウンを防止 • Web/APの永続化ストレージ、DBのバックアップと してオブジェクト・ストレージを活用 GOLD & PLATINUM- マルチリージョンの構成 Copyright © 2025, Oracle and/or its affiliates. 42 東京リージョン 大阪リージョン FD1 FD2 FD1 FD2 フェイルオーバー or ロードバランス Data Guard Replication (rsyncなど) DNS WebAP WebAP Database(RAC) Database(RAC) Backup Backup 

複数リージョンを有効化する Copyright © 2025, Oracle and/or its affiliates. 43 1つの契約において、世界中のOracle Cloud Infrastructure のリージョンが利用可能 初期は1つだけがホームリージョンとして 有効になっている(緑のアイコン)、管理者 ユーザーが「Subscribe To This Region」ボタ ンを押すことで他リージョンも有効化でき る セレクターで有効化済のリージョンを選択 して利用 

DR用途に最適な専用線 • 低遅延、低ノイズ • 通信は暗号化、VPN構成不要 • オラクルが冗長化された占有回線を保持 リモートVCNピアリングを構成して利用 アウトバウンド・データ転送料金が適用 • 最初の10TB/月 : 無料 • 10TBを超える分/月 : 3円/GB ベストエフォート • 東京-大阪間は約8ms程度 • ただしベストエフォート、帯域保障が必要な 場合は FastConnect の利用を推奨 リージョン間のバックボーンを使う Copyright © 2025, Oracle and/or its affiliates. 44 OCI リージョン OCI リージョン OCI リージョン 

• 異なるリージョンにあるVCN同士を結合する機能 • Oracleの持つ広帯域、低遅延のバックボーンを経由 リモートVCNピアリングでリージョンを跨いだWANを構成する ORACLE CLOUD INFRASTRUCTURE(REGION 1) AD1 AD2 AD3 ORACLE CLOUD INFRASTRUCTURE(REGION 2) AD1 AD2 AD3 Copyright © 2025, Oracle and/or its affiliates. 45 

https://docs.oracle.com/ja-jp/iaas/Content/Block/Concepts/volumereplication.htm ブロック・ボリュームとブート・ボリュームのク ロス・リージョン・レプリケーション • 別リージョンへのDR用途などに活用 • AD間レプリケーションも可能 • 顧客管理キーを利用した暗号化ボリュームは 非サポート • レプリケーションを有効化したボリュームは リサイズ不可 • RPOは30分以内だがデータ変更量によっては それ以上になることもある • レプリケーション先は事前定義済みのリー ジョンから選択 ブロック・ボリュームを他リージョンにレプリケーションする Copyright © 2025, Oracle and/or its affiliates. 46 OCI Tokyo Region Instance Block Volume Boot Volume OCI Osaka Region Boot Volume Replica レプリケーション アクティブ化（クローン） することで利用可能 

ヘルス・チェックで外部からエンドポイントの状態を能動的に監視する Copyright © 2025, Oracle and/or its affiliates. 47 インターネットに公開しているサービスの可用性を監視および警告する機能を提供 マルチクラウド、オンプレミス環境など環境に依存せずハイブリッド環境のエンドポイントの監視が可能 サービス障害を検知した場合、Traffic Managementサービスと連携して自動的にDNSフェイルオーバ、またはAlarm サービスと連携して通知が可能 OCIのコンソールに統合され、UIによる一貫した操作を提供 Your Server @ OCI • 世界中の23か所のVantage Point(AWS, Azure, GCP 上で提供) – North and South America – Europe – Asia & Australia • HTTP , HTTPS , Ping(TCP , ICMP) • Optional HTTP Header value check 

トラフィックを別のリージョンにフェイルオーバーする Copyright © 2025, Oracle and/or its affiliates. 48 User Recursive Server OCI DNS Primary Region Redundant Region Outage Available プライマリ・リージョンのサービスのダウ ンを検知すると、OCI DNSの機能でトラ フィックをスタンバイ・リージョンに切り 替える OCIヘルスチェック機能を使って死活を監 視 フェイルオーバーの他に以下もサポート • ロードバランス • ジオロケーション・ステアリング • ASNステアリング • IP接頭辞ステアリング トラフィック管理(Traffic Management) 

Real Application Clusters (RAC) • Active-Activeのクラスタ機能 • パブリッククラウドで唯一利用可能 Data Guard • 災害/障害対策のためのレプリケーション機能 • 東京/大阪リージョン間で自動構成 Oracle Database マネージドサービスの高可用性機能を活用する ノード数を2に設定するとRACを自動構成 Public Compute Block Volume VCN AD AD Tokyo Region Osaka Region Public Compute Block Volume プライマリ Block Volume Database * 2 (EE) 4 CPU RAC セカンダリ Block Volume Database (EE) 1 CPU Data Guard Copyright © 2025, Oracle and/or its affiliates. 49 

Zero Down Time Migration/Upgrade GoldenGateを利用しデータベース移行の切替時間を極小化する 1)システム移行前 2)システム切替当日 3)システム移行後 切り戻し に活用 現行DB 新環境DB 現行DB 新環境DB 現行DB 新環境DB GoldenGate GoldenGate GoldenGate 50 Copyright © 2025, Oracle and/or its affiliates. 50 

GOLD & PLATINUM –(派生)ハイブリッド・クラウドの構成 Copyright © 2025, Oracle and/or its affiliates. 51 要件の目安 サイト障害、広域災害時 : RPO <30分 / RTO <30分 機器障害時 : RPO 0 / RTO 0 構成のポイント • 本番系はオンプレミス、待機系はクラウドで構 成 • OCIのDNS機能を利用して切り替え / 移行 • データ移行/レプリケーションにはData Guard、 GoldenGate、またはRMANバックアップを利用 オンプレミス 東京リージョン FD1 FD2 フェイルオーバー Data Guard GoldenGate Replication (rsyncなど) DNS WebAP WebAP Database(RAC) Database(RAC) Backup SLB RMAN Backup FastConnect 

まとめ Copyright © 2025, Oracle and/or its affiliates. 52 ✓ Design For Failure : サーバーは落ちるもの、データセンターは止まるもの ✓ 高可用性の考え方は、クラウドでもオンプレミスでも本質は同じ ✓ クラウドの機能を活用すると、より低コストでより高いレベルの可用性を実現できる ✓ クラウドでも高可用性を構成するにあたり、 MAA(Maximum Availability Architecture)をう まく参照・活用することで、素早い検討と実装が可能になる 

Thank you 53 Copyright © 2025, Oracle and/or its affiliates. 

No content

Our mission is to help people see data in new ways, discover insights, unlock endless possibilities.