AWS では、AI を開発ライフサイクル全体に組み込み、人が意思決定と承認を担う開発の方法論「 AI-DLC（AI-Driven Development Life Cycle） 」を提唱しています。2026 年 9 月、日本生命保険相互会社様、ニッセイ情報テクノロジー株式会社様とともに、AI-DLC を実践するためのワークフローの最新版「AI-DLC Workflows 2.0」（以下、v2）を使った 3 日間のワークショップ「AI-DLC Unicorn Gym」を開催しました。 本記事では、まず 1 章で、対談の前提となる AI-DLC、AI-DLC Workflows、AI-DLC Unicorn Gym を紹介します。2 章では、内製の AI エージェントツールと v2 を組み合わせて個人保険の基幹系システムの保守開発に取り組まれた、ニッセイ情報テクノロジー株式会社の横井 拓磨 氏との対談をお届けします（聞き手：AWS 山根）。 1. AI-DLC と AI-DLC Workflows、AI-DLC Unicorn Gym AI-DLC とは AI-DLC は、AWS が 2025 年に提唱した開発の方法論です。AI を補助的な道具として後から組み込むのではなく、開発の中心に据えます。AI が作業の計画を立て、不明点を質問し、重要な判断は人に委ねます。人の確認を得てから AI が実行する、という進め方を開発のあらゆる工程で繰り返すことで、品質を保ちながら開発を速めることを目指しています。また、業務部門と開発部門がチームとして集まり、AI の提案をその場で検証しながら進めることを重視しています。 AI-DLC Workflows とは AI-DLC Workflows は、AI-DLC をコーディングエージェント上で実践するためのワークフローで、AWS が GitHub でオープンソースとして公開しています。2025 年 11 月に公開された最初の版（以下、v1）は、各コーディングエージェントに読み込ませるルールとして提供され、案件に応じて必要なステージだけを実行する考え方を取り入れていました。一方で、各ステージの成果物を人が確認する必要があり、人の処理速度が開発全体の速さの上限になりやすいという課題がありました。また、次に何をするかの判断も AI がルールを解釈して行うため、進め方が AI の判断に左右されることがありました。 2026 年 7 月に一般提供が始まった v2 は、方法論はそのままに、ワークフローの仕組みを作り直したものです。大きな変化は 2 つあります。 1 つ目は、ワークフローの進行や承認ゲートを AI の解釈に任せず、コードで実装したエンジンとフックで決定論的に制御するようにしたことです。次に進むステージはエンジンが決め、承認ゲートでは人の応答が記録されてから次へ進みます。 2 つ目は、人の判断を少しずつ機械に移していく考え方です。v2 の 仕様書 では、人が判断や検証に費やしている労力の多くは、判断のパターンを機械が実行できる形に落とし込む（仕様書では「蒸留」と表現）ことで減らせる、としています。作業中に人が行った修正を、人の確認を経てルールや自動チェックとして蓄積し、検証できる範囲を段階的に広げることで、人は本当に判断が必要な場面に集中できるようになります。 観点 v1 v2 組み込み方式 同じルールファイルを、各コーディングエージェントにコピーして使う 単一のコアから、各コーディングエージェント向けに専用の形で組み込む ワークフローの進行 AI がルールを解釈して進める コードで実装したエンジンが、次に進むステージを決定論的に決め、状態と監査記録を管理する 工程 3 フェーズ。案件に応じて実行するステージを AI が計画する 5 フェーズ・33 ステージ（2026 年 11 月時点）。スコープ（ワークフローの型）を選ぶ、独自のスコープを作る、Intent（開発を進める単位）ごとに必要なステージを提案させる、途中で組み替える、といったことができる 人の承認 ルールの指示に従い、AI が各ステージで人の承認を求める エンジンとフックで承認ゲートを制御し、人の応答が記録されてから次のステージへ進む 検証 各ステージの成果物を人が確認する 主要なステージでレビュー専用のエージェントが独立してレビューし、センサー（決定論的なチェック）も成果物を自動で検証する。結果は承認ゲートで人に示される 学習 なし 作業中の修正を、人の確認を経てルールやセンサーとして蓄積し、次の作業に活かす（人の判断の蒸留） v1 と v2 の違いは、「 AI-DLC Workflow V1からV2へ：人間のボトルネックを解消する設計の進化 」（AWS Builder Center）でも詳しく解説しています。 AI-DLC Unicorn Gym とは AI-DLC Unicorn Gym は、参加企業が自社の実際のテーマを持ち込み、AI-DLC を数日間で実践する AWS のプログラムです。今回は、日本生命様で業務を所管する部門（以下、所管部門）とニッセイ情報テクノロジー様から 54 名が参加し、7 チームがそれぞれの担当案件（進行中の実案件を含む）を題材に、所管部門と開発部門が同じチームで v2 を使って取り組みました。アンケートでは、満足度 4.35、「AI-DLC は働き方を変える可能性がある」4.52（いずれも 5 点満点）の評価をいただきました。 2. 対談：個人保険の保守開発に AI-DLC を取り込む ここからは、横井 氏との対談です。AI-DLC に取り組んだきっかけ、内製の AI エージェントツールの仕組み、AI-DLC Unicorn Gym での取り組みと気づき、その後の PoC と社内展開について伺いました。 ニッセイ情報テクノロジー株式会社 個人保険システム事業部 ジェネラルマネージャー 横井 拓磨 氏 横井 拓磨 氏 ニッセイ情報テクノロジー株式会社 個人保険システム事業部 ジェネラルマネージャー 2009 年に日本生命保険相互会社に入社し、ニッセイ情報テクノロジーに出向。約 17 年、個人保険の基幹システム開発に従事。AWS 認定資格 13 種をすべて保有（全冠）し、AWS を活用した社内サービスで社長賞を 7 度受賞。 AI-DLC に取り組んだきっかけ 山根（AWS） ：AI-DLC に取り組まれたきっかけを教えてください。 横井 ：当事業部では、個人保険の販売・新契約から保険金・給付金の支払までを支える、大規模でミスが許されない基幹系システムを保守・開発しています。当社は 1999 年の設立以来、高い品質要求という「壁」に真摯に向き合い、堅牢な開発工程と高い品質力を培ってきました。今後は、その壁を守るだけでなく、品質という強みを活かしながら、開発のあり方そのものを進化させていきます。 生成 AI は、開発そのものを担いうる技術として、その壁を越えてきます。我々にとって避けて通れない変革ですが、いち早くプロセスを見直すことで、むしろ新たな競争力を獲得する好機にもなります。そこで今年度の初めから AI-DLC の適用を研究し、AI-DLC Unicorn Gym をその研究と内製ツールが実案件で通用するかを確かめる場と捉えて参加しました。 内製の AI エージェントツールの仕組み 山根（AWS） ：内製された AI エージェントツールについて教えてください。 横井 ：LLM も AI-DLC Workflows も急速に進化していますが、業務に使うには、業務ドメイン知識の取り込みと、社内の開発環境や業務プロセスへの適応が欠かせません。そこを自分たちで作り込むために、AI エージェントツールを内製しました。 ブラウザから使う Web アプリケーションにしたのは、チームでの共同作業をブラウザでできるようにするためです。業務端末にソフトウェアを導入してもらうより、ブラウザで使えるほうがハードルが低く、社内に展開しやすいという利点もあります。画面は React で作っており、ファイルツリー、文書やコードを表示・編集するビュー、AI とのチャットの 3 つの領域で構成しています。フォルダごとのアクセス制御や、作業中であることを示す編集ロックを備えているので、チームで同じ作業場を共有しながら進められます。公衆インターネットには接続せず、AI の推論には国内リージョンの Amazon Bedrock 経由で Anthropic の Claude モデルを使い、社内のシステムとはプライベートな経路で接続しています。 山根（AWS） ：AI エージェントとツールは、どのように動いているのですか。 横井 ：AI エージェントは Claude Agent SDK で作っています。チャットで依頼を受けると作業を計画し、必要なツールを呼び出して実行します。複雑な作業はサブエージェントに分担させます。ツールは TypeScript で実装した自作の MCP サーバーで、主に次のような機能があります。 文書・図の可視化 ：Office 文書や PDF の Markdown への変換、図の描画、HTML 化、帳票イメージの生成などで、レビューする人が内容を理解しやすい形に整える ソースの取得・ビルド・実行 ：社内のソース管理環境からのソースの取得（依存するソースもまとめて取得できる）、構文チェック、ビルド、テストの実行と項目ごとの結果の判定を、作業ごとに実行する 規約・コード表の参照 ：社内のコーディング規約やコード表（区分値などのコードの一覧）を、社内で管理している正本のまま AI エージェントに参照させる。一般的な知識や記憶で代用させず、規約に沿ってコードを生成・レビューできるようにする 作業フォルダとリポジトリの同期 ：画面のファイルツリーに表示される作業フォルダのファイルを、 AWS CodeCommit の作業用リポジトリと同期する チケットの操作 ：Redmine（オープンソースのプロジェクト管理ツール）のチケットを起票し、資料を添付する 成果物の登録 ：Redmine の文書管理プラグイン DMSF に成果物を登録し、版を管理する 業務知識の検索 ： Amazon Bedrock Knowledge Bases を検索する自作のアプリケーションを呼び出し、蓄えた業務知識を検索する これらのツールは、AI エージェントから呼び出せるだけでなく、画面の右クリックメニューから直接実行することもできます。ソースの取得やビルドのような機械的な作業は、AI を介さずに決まった手順で実行したほうが速く確実で、AI の利用料もかかりません。判断が必要な作業は AI に任せ、決まった作業は直接実行する、という使い分けができるようにしています。 内製の AI エージェントツールの概要 業務ドメイン知識は、Excel などで作られてきた業務ドキュメントを、ドキュメントの形式に応じたプロンプトのテンプレートを使って Markdown に変換し、内製の専用エディタで人が修正して整えたうえで、作業用とは別の業務知識用のリポジトリ（AWS CodeCommit）に登録しています。Push をきっかけに Amazon Bedrock Knowledge Bases への取り込みが実行され、ベクトル化されて意味で検索できるようになる仕組みを、自分たちで作りました。案件で承認を経て確定した成果物も同じリポジトリに登録するので、案件を重ねるほど業務知識が蓄積されていきます。 承認や進捗の管理には、Redmine のチケットと DMSF を使います。承認が必要になると、所管部門にチケットで承認依頼が届きます。毎朝の進捗も、エージェントが Redmine に自動で投稿しています。業務側と開発側の拠点が離れていても、承認や進捗の確認が滞らないようにするためです。 AI-DLC Unicorn Gym で、保守開発の実案件に AI-DLC を使う 山根（AWS） ：AI-DLC Unicorn Gym には、どのような題材と準備で臨まれたのでしょうか。 横井 ：金融機関の開発は、その大半が既存システムの保守開発です。「保守開発でも AI-DLC は使えるのか」という問いに、内製ツールを含めた開発プロセスとして答えることが目的でした。題材には、法人のお客様向けの通知帳票を作成するシステムを選びました。機能が単一のシステムで完結し、結果が帳票として目に見えるためです。 準備は 3 つです。業務ドメイン知識を事前に構造化し、内製ツールから参照できるようにしたこと。ソースコードとテストデータから帳票イメージを出力するツールを用意したこと。そして、33 のステージ（2026 年 9 月実施時）から保守開発に必須のものを選び、独自のスコープとして登録したことです。 題材の案件は、この通知帳票に新しい項目や文言を加える改修です。契約内容の欄や、保険の仕組みを図で示す欄への項目の追加、内容確認用の帳票への反映など、7 つの改修に分かれており、それぞれを 1 つの Intent（v2 で開発を進める単位）としました。前の改修が後の改修の前提になるため、1 つずつ順に進めます。3 日間で、このうち 2 つの Intent を終えることができました。 山根（AWS） ：v2 が標準で対応しているコーディングエージェントとは別の、内製ツールの上で v2 を動かしたわけですね。そのために、どのような工夫をしたのですか。 横井 ：内製ツールの AI エージェントが作業のたびに読み込むルールファイル（以下、指示ファイル）に、この環境での v2 の使い方をまとめました。工程の順番や承認の状態、監査記録は v2 のエンジンが管理するので、エージェントには「v2 のエンジンに次の作業を確かめ、その作業だけを実行して、結果をエンジンに報告する」という手順を繰り返させました。そのうえで、主に次のことを教えました。 コーディング規約や命名規則は、v2 の一般的な基準よりも、規約・コード表の参照ツールで引いた社内の正本を優先する v2 の「既存のコードを調べる」「ビルドしてテストする」といった作業は、内製ツールのソース取得やビルド・実行のツールで行う 構文チェックやテストの成否は、推測で書かず、ツールが返した結果をもとに書く 標準の対応環境で自動的に働く一部の仕組み（フックなど）は使えないため、その部分は指示ファイルの決まりとして守る。承認ゲートは省略せず、必ず人に確認してから進める AI-DLC Unicorn Gym の後も、ここで得た経験をもとに、保守開発の現場に合わせてワークフローの改良を続けています。 AI-DLC Workflows 2.0 の評価 山根（AWS） ：以前から AI-DLC に取り組まれてきた立場から、v2 をどうご覧になりましたか。 横井 ：v2 は、エンタープライズの現場で回すことを前提に作られていると感じます。大きくは 3 つです。 1 つ目は、スコープの選択とステージのカスタマイズです。v1 は一本の流れとしての分かりやすさがあった反面、「全部の工程は要らないが、ここだけは絶対に外せない」という保守開発にあてはめるには、こちらで読み替えが必要でした。v2 では案件の性質に応じてスコープを選び、ステージを取捨選択できるので、保守開発に絞った独自のスコープを用意できました。 2 つ目は、承認ゲートです。v2 では承認ゲートが仕組みとして組み込まれていて、人が承認するまで次のステージに進みません。「誰が、いつ、何を見て承認したのか」が明確になることは、説明責任が強く求められる金融業界と相性が良いと感じました。「どこで承認するか」はワークフローが定めます。我々は、承認のやり方を自分たちのプロセスに合わせるため、Redmine のチケットにつなぎました。 3 つ目は、意思決定の記録で、個人的に最も参考になった部分です。内製ツールではここが弱く、何を残すべきかの知見もありませんでした。経緯が自然に記録される仕組みは、監査を重視する業界のカルチャーとも合います。 総じて v2 は、AI で速く作るだけでなく、説明できる形で作るためのワークフローだという印象です。現場に合わせて調整できる余地があらかじめ用意されていたことも、我々が金融の現場で取り込むうえで助けになりました。 3 日間で得られた気づき 山根（AWS） ：3 日間で得られた気づきを教えてください。 横井 ：大きく 3 つあります。1 つ目は、AI-DLC が前提としているとおり、開発の速さを左右するのは人の判断だと、実案件で確かめられたことです。2 つの Intent を終えられたのは、作業の速さ以上に、所管部門と開発部門が同じチームで AI の成果物をその場で判断し、確認待ちの時間がなくなったからでした。AI が速くなるほど、改善すべき課題は人の意思決定や待ち時間に移ります。 2 つ目は、業務ドメイン知識の整備の重要性です。知識が整った領域では、AI の提案の精度が明らかに高く、手戻りも少なく済みました。一方で、長年の改修の中で暗黙知になっている部分は AI には知りようがなく、人が補う必要がありました。AI が既存の資産を理解できるかどうかは、AI の性能以上に、我々がどれだけ知識を言語化・構造化できているかにかかっていると実感しています。案件で承認を経て確定した成果物を業務知識として登録しているのも、こうして人が補った知識を、次の案件で AI が使えるようにするためです。 3 つ目は、人がどこで何を見て判断するかの設計です。今回は帳票をイメージで出力し、所管部門が最終的な出力物を目で見て判断できるようにしました。設計書を読み解くよりも判断しやすく、確認のスピードと確かさの両方が上がったと感じています。 こうした気づきをもとに、AI-DLC Unicorn Gym の後に精査し、通常は 6 名で 6 か月ほどかかるこの案件を、4 名で 3 か月ほどで終えられると見込んでいます。 既存の仕組みを活かしながら、働き方そのものも変えていく。その両方が必要だというのが、3 日間の学びでした。 個人保険システム事業部が先行した理由 山根（AWS） ：AI-DLC Unicorn Gym の後、個人保険システム事業部が、社内で AI-DLC の導入に先行して取り組むことになった理由を教えてください。 横井 ：1 つは、個人保険が当社のお客様にとって最重要のビジネスドメインの一つであり、全社のアプリケーション開発でも大きな割合を占めることです。AI 駆動開発の効果が最も大きく出る領域なので、最初に成果を示すべきだと考えました。もう 1 つは、私が 5 年ほど前に立ち上げた、社内業務の効率化とクラウド人材の育成を目的とする有志の組織で、AWS を使った社内向けの Web アプリケーションを作ってきた土壌があったことです。 また、個人保険だけの特殊な事例にしないよう、同じ技術と開発プロセスを持つビジネスソリューション事業部にも、同じ AI-DLC Unicorn Gym に参加してもらいました。 現在進めている PoC 山根（AWS） ：現在進めている PoC について教えてください。 横井 ：AI-DLC Unicorn Gym と同じ帳票システムで、残りの Intent も含めて完走できるかを、体制、開発期間、品質、開発プロセス、開発環境の観点で検証しています。同じ案件を通常のウォーターフォールとも並走させて比較しています。 進め方も変えました。成果物ごとに 1 週間ほどのレビュー期間を取ることはせず、できたものをすぐに見せて、追加の要望は次の計画の場（プランニング）で取り込みます。また、承認の責任を持つ課長層は多忙で、AI-DLC のすべての工程に参加し続けることはできません。そこで、課長層の判断が本当に必要な箇所に絞って承認いただき、それ以外の承認は現場に任せるようにプロセスを整理し、ワークフローに組み込みました。課長層に承認いただくのは、Inception（要件を固め、作業単位に分解するフェーズ）で作成したバックログと、後続のテスト工程への引き渡しの 2 か所です。承認の際は成果物について AI に質問しながら判断できるので、私も Inception の承認では、成果物のフォルダを指定して AI に質問しながら内容を確認しました。現時点では順調に進んでいます。 ほかの事業部への展開 山根（AWS） ：社内にはどのように展開されていますか。 横井 ：社内の AI-CoE である AI・データ戦略企画推進部からお声がけいただき、企業保険ソリューション事業部や年金ソリューション事業部などへの展開を計画しています。ただ、ツールややり方をそのまま配って「この通りにやってください」と展開するつもりはありません。組織ごとに業務や開発プロセスの事情が違うので、それぞれの組織が自分たちのプロセスに合わせて、自分たちにとって良い形で AI-DLC を取り込んでいくことが大切だと考えています。経験は苦労も含めて伝えつつ、各組織には一度は同じ道のりをたどってもらう方針です。その過程で人が育つと考えています。 3. おわりに v2 を内製ツールとつなぎ、自分たちの開発プロセスとして取り込む横井 氏の取り組みを、AWS は引き続きご支援してまいります。AI-DLC Workflows は GitHub（awslabs/aidlc-workflows） で公開しており、 ドキュメント から v2 の詳細をご覧いただけます。 ありがとうございました。 本記事は、2026 年 9 月 14 日〜16 日に開催した AI-DLC Unicorn Gym、および 2026 年 10 月 14 日に実施したインタビューをもとに構成しました。 著者 山根 英彦 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト

本稿は、2026 年 10 月 2 日に公開された “ Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP ” を翻訳したものです。 VMware Cloud Foundation (VCF) への既存投資がある企業は、アプリケーションの再設計や運用チームの再教育を行うことなく、Oracle データベースを AWS に移行したいと考えています。 Amazon Elastic VMware Service (Amazon EVS) 上の Oracle は、既存の VMware 運用ワークフローを維持しながら、サブミリ秒のストレージレイテンシー、スナップショットベースのバックアップ、クロスリージョンディザスタリカバリ (DR)、および独立したストレージスケーリングを活用できます。 この記事では、 Amazon FSx for NetApp ONTAP を使用して Amazon EVS 上に Oracle Database 環境を設計する方法を紹介します。使い慣れた VMware 運用ツールを維持しながら、ストレージ、コンピューティング、ネットワーキング、ディザスタリカバリの各レイヤーがどのように連携して高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを実現するかを学びます。 この記事では、以下の方法を学びます。 VMware Cloud Foundation 9.1 が稼働する Amazon EVS 上の Oracle Database アーキテクチャの設計 Oracle ワークロードに最適な EC2 ベアメタルインスタンスタイプと VM サイジングの選択 Oracle のデータボリュームおよびログボリューム用の NFS データストアとして FSx for ONTAP を使用したストレージの設計 クロスリージョン DR のための SnapMirror レプリケーション計画 既存の Oracle ワークロードをオンプレミスの VMware から Amazon EVS に移行するための移行オプションの評価 Amazon EVS は、 Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス上で VMware Cloud Foundation (VCF) 環境を直接実行します。VCF 9.x では、Amazon EVS がベアメタルインフラストラクチャと VLAN サブネットをプロビジョニングし、その後 Broadcom の VCF Installer を使用して VCF をデプロイします (セルフデプロイモデル)。VCF 9.x は評価モードもサポートしているため、ライセンスキーを適用する前に設計を検証でき、Solutions for Amazon EVS GitHub リポジトリでは段階的な VCF 9 デプロイメントを自動化する AWS CloudFormation および Terraform テンプレートが提供されています。FSx for ONTAP は、NFS、SMB、iSCSI、および NVMe over TCP アクセスを備えたマネージド ONTAP ストレージを提供します。FSx for ONTAP は、サブミリ秒の応答時間、数 GBps のスループット、およびファイルシステムあたり最大 80,000 IOPS を実現できます ( FSx for ONTAP のパフォーマンス を参照)。 詳細については、 FSx for ONTAP の機能 を参照してください。 プロビジョニング、ストレージ設定、Oracle のインストール、SnapMirror のセットアップを含むデプロイメント手順については、関連記事「 Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ 」を参照してください。 ソリューションアーキテクチャ このセクションでは、2 つの AWS リージョンにまたがる Amazon FSx for ONTAP ストレージを使用した、Amazon EVS 上の高可用性 Oracle Database デプロイメントについて説明します。図 1 は、オンプレミスからハイブリッド接続を経由して本番 Amazon EVS 環境およびクロスリージョン DR に至るデータフローを示しています。 図 1: FSx for ONTAP とクロスリージョン SnapMirror DR を使用した Amazon EVS 上の Oracle Database このアーキテクチャは 8 つの機能コンポーネントで構成されており、次のセクションで説明します。 アーキテクチャコンポーネント 以下の項目は、図に示されたデータフローに対応しています。 ハイブリッドリンク — オンプレミスデータセンターは、 AWS Direct Connect を通じて AWS に接続し、低レイテンシーの専用帯域幅を確保します。 トランジットルーティング — AWS Transit Gateway が本番 VPC、DR リージョン、オンプレミスネットワーク間のトラフィックをルーティングします。 ワークロードランディング — トラフィックは、VCF 9.1 を搭載した i7i.metal-24xl Amazon EC2 ベアメタルインスタンス上で稼働する EVS データベースクラスターに到達します。 ライブマイグレーション — VMware HCX (Hybrid Cloud Extension) が、Replication Assisted vMotion または Bulk Migration を使用して、オンプレミスの VMware から Amazon EVS へ Oracle VM をほぼゼロダウンタイムで移行します。 NFS データパス — 各 ESXi ホストは FSx for ONTAP を NFS データストアとしてマウントします。Oracle VM は、データベースボリュームにブロックデバイス (NFS データストア上の VMDK) としてアクセスし、サブミリ秒のレイテンシーと最大 80,000 IOPS を実現します。各ホストは FSx for ONTAP への独立した NFS パスを持ち、クラスター全体で帯域幅を分散します。 クロスリージョン DR — SnapMirror が FSx for ONTAP ボリューム (データ、ログ、バイナリ) を、設定可能な目標復旧時点 (RPO) で DR リージョンに非同期でレプリケートします。 ダイナミックルーティング — NSX Tier-0 ゲートウェイが BGP を介して Amazon VPC Route Server とピアリングします。これは一方向の BGP です。Route Server は NSX によってアドバタイズされたルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。 DR フェイルオーバー — フェイルオーバー時、Transit Gateway は DR リージョンにルーティングし、そこで事前にプロビジョニングされたスタンバイ Oracle VM が SnapMirror レプリカボリュームをマウントします。 Amazon EVS 上の Oracle Database デプロイメントで考慮すべき要素 デプロイメントを開始する前に、利用可能なインフラストラクチャオプションに対して Oracle ワークロードの要件を評価してください。インスタンスタイプ、VM サイジング、ストレージアーキテクチャについて行う決定は、データベースのパフォーマンス、コスト、運用の複雑さに直接影響します。 Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響するため、考慮すべき重要な要素です。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ESXi ホスト向けの EC2 インスタンスタイプの選択 Amazon EVS は現在、ESXi ホスト向けに 3 つのベアメタルインスタンスタイプをサポートしています。選択は、コアあたりのコンピューティング速度 (i7i) を優先するか、ホストあたりのメモリとストレージ密度 (i4i) を優先するか、また単一ホストを垂直方向にどの程度スケールしたいかによって異なります。ほとんどの新規 Oracle デプロイメントでは、Oracle のクエリパフォーマンスが CPU の命令スループットとストレージ IO レイテンシーに敏感であるため、i7i がより良い選択です。 i7i.metal-24xl (推奨デフォルト): 96 vCPU (48 コア)、768 GiB RAM。第 5 世代 Intel Xeon は改善されたコンピューティングパフォーマンスを提供します。第 3 世代 AWS Nitro SSD は、vSAN 向けに、強化されたリアルタイムストレージパフォーマンスと低い IO レイテンシーを提供します。 i7i.metal-48xl: 24xl と同じ第 5 世代 Intel Xeon ですが、ホストあたりの容量は 2 倍 (192 vCPU、96 コア、1,536 GiB RAM、最大 100 Gbps のネットワークおよび 60 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅)。大規模な SGA、高いコア数、または VMware のホストあたりライセンスを削減するためのより少なく高密度なホストなど、単一の Oracle ホストを垂直方向にスケールしたい場合に選択します。24xl と同じコアあたりのパフォーマンスプロファイルを維持します。 i4i.metal: より高いホストあたり密度 (128 vCPU、1,024 GiB RAM、30 TB NVMe) で、より少なく大きなホストを必要とする環境に適しています。 VCF 互換性: 3 つのインスタンスタイプすべてが ESXi 9.1 (ビルド 9.1.0.0100.25433460) を備えた VCF 9.1 をサポートします。VCF 5.2.2 (ESXi 8.0U3g) は引き続き利用可能ですが、サポート終了に向かっているため、新規デプロイメントはデフォルトで 9.x を使用すべきです。Amazon EVS 環境はクラスターあたり 4〜32 ホストをサポートします。同じ SDDC 内のクラスター間でインスタンスタイプを混在させることができます。 Oracle Database ゲスト向けの VM サイジング 以下のワークロード特性に基づいて Oracle Database VM をサイジングします。 Oracle の CPU_COUNT パラメーターに一致する vCPU 数を割り当てます。 SGA + PGA + OS オーバーヘッド向けにメモリをサイジングします (通常、割り当てられた VM メモリの 75〜85% を SGA に)。 VM スワップを vSAN データストア上に設定します (NFS ではない)。vSAN は 1 桁ミリ秒のレイテンシーを持つローカル NVMe を使用します。 単一ソケットのコア数を超える VM には NUMA 対応の VM 配置を使用します。 追加コストなしで 1 桁ミリ秒のレイテンシーを得るために、OS スワップと Oracle の一時表領域を vSAN データストア上に配置します。 ストレージアーキテクチャ: vSAN + FSx for ONTAP 推奨される設計では、ストレージの役割を 2 つの階層に分割します。 vSAN (各 ESXi ホスト上のローカル NVMe ドライブで構成) は、低レイテンシーで非レプリケーションのワークロードを処理します。 ( VM ブートディスク、OS スワップ、Oracle 一時表領域) FSx for ONTAP は、スナップショットベースのバックアップとクロスリージョンレプリケーションを必要とする Oracle データファイルと REDO ログを処理します。ESXi ホストは FSx for ONTAP ボリュームを NFS データストアとしてマウントし、Oracle VM はそれらのデータストア上の標準 VMDK にアクセスします。 この分離により、一時的な IO にはローカル NVMe の速度を提供しつつ、永続的なデータベースファイルにはスナップショット、クローン、SnapMirror の機能を追加できます。 なぜゲスト内 NFS (dNFS) ではなく NFS データストア (ホストレベル) なのか？ ゲスト内 NFS では、すべての Oracle NFS トラフィックが FSx for ONTAP に到達する前に NSX オーバーレイと NSX Edge ノードを経由します。これにより単一の Edge ボトルネックが生じます。NFS データストアでは、各 ESXi ホストが自身のネットワーク帯域幅を使用して FSx for ONTAP と直接 NFS で通信します。Edge ボトルネックも余分なレイテンシーホップもありません。 FSx for ONTAP のサイジングに関する考慮事項 重要: Oracle には 100% SSD を使用します。 Oracle データベースボリュームにはキャパシティプールの階層化を使用しないことをお勧めします。すべての Oracle ボリュームで階層化ポリシーを none に設定したままにしてください。 重要: SSD の容量を計画します。 SSD 階層が容量いっぱいになると、FSx for ONTAP は書き込みをブロックします。SSD 使用率を監視し、余裕 (最低 20% の空き) を確保してください。 重要: 読み取り/書き込みスループットは非対称です。 6 GB/s のファイルシステムでは、読み取りスループットは 6 GB/s に達することができますが、書き込みスループットは約 1 GB/s に制限されます。Oracle の書き込みワークロード要件に基づいてスループット容量をサイジングしてください。この書き込み上限は高可用性 (HA) ペアごとに適用されます。単一の HA ペアを超えて書き込みスループットをスケールするには、複数の HA ペアを持つファイルシステムをデプロイし、追加のアグリゲート全体に Oracle ボリュームを分散させて、書き込みがペア間で分散されるようにします。この配置は自動ではないため、書き込みの多いデータセットのバランスを保つために、事前にレイアウトを計画してください。 ネットワークアーキテクチャ Amazon EVS は、トラフィックをセグメント化するために VLAN サブネット (環境作成時に定義され、後から変更不可) を使用します。 VPC Route Server は、VPC 内の静的ルートを置き換えます。NSX Tier-0 ゲートウェイは BGP を介して Route Server エンドポイントとピアリングします。これは一方向の BGP です: Route Server は NSX からのルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。VPC の外側では、Transit Gateway のルートは静的なままです。 Oracle 向けの NSX-T セグメンテーション 本番データベースセグメント (DB サブネット) 専用の Tier-1 ゲートウェイ。 アプリケーション層 (App サブネット) とペリメーターネットワーク用に別の Tier-1。 分散ファイアウォールルールが、Oracle リスナーアクセス (TCP 1521) を認可されたアプリケーションセグメントのみに制限。 Oracle インスタンス間のマイクロセグメンテーションが、ラテラルムーブメントを防止。 重要: セキュリティグループルールは VLAN サブネットインターフェイスでは適用されません。トラフィック制御にはネットワーク ACL と NSX 分散ファイアウォールを使用してください。 高可用性とディザスタリカバリ SnapMirror レプリケーションの頻度が RPO を決定します。ビジネス要件に基づいて設定します。 目標復旧時間 (RTO) を短縮するために、DR クラスターにスタンバイ Oracle VM を事前にプロビジョニングします。 復旧中に Oracle のインストールが不要になるように、バイナリボリュームをレプリケートします。 ヒューマンエラーを減らすために、Ansible/SnapCenter でフェイルオーバーを自動化します。 DR に関する Oracle ライセンスの考慮事項: DR レプリケーションの実装方法に基づいてライセンスへの影響があります。ライセンスに関する質問がある場合は、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 Oracle のライセンス規則に準拠するための代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。フェイルオーバーイベントが宣言された時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。VM の電源が入っていなくても SnapMirror ボリュームをデータストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリにアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。 オンプレミス VMware から Amazon EVS へのデータベース移行 以下の表は、オンプレミス VMware から Amazon EVS への移行オプションを比較しています。 オプション 方法 最適な用途 ダウンタイム 1 VMware HCX ライブマイグレーション 既存のオンプレミス VMware ほぼゼロ (vMotion) または計画的な一括移行 2 SnapMirror ONTAP-to-ONTAP NetApp ONTAP 上のオンプレミス Oracle 数分 (最終同期の切り替え) 3 Oracle PDB リロケーション PDB/CDB マルチテナントモデル 短時間 (最終切り替えのみ) 4 RMAN バックアップ/リストア 非 ONTAP のオンプレミス (汎用) 数時間 (バックアップ + リストア + 適用) 各移行オプションの詳細な手順については、関連記事「 Oracle Database Deployment on Amazon EVS and FSx for ONTAP: Best Practices 」を参照してください。 セキュリティ Amazon EVS 上の Oracle のセキュリティは、ネットワーク分離からデータベースレベルの暗号化まで、複数のレイヤーにまたがります。以下の表は、各レイヤーのセキュリティコントロールをまとめたものです。 レイヤー コントロール ネットワークセグメンテーション NSX-T Tier-1 ゲートウェイが DB/App/ペリメーターのネットワークセグメントを分離 East-West トラフィック NSX 分散ファイアウォール : TCP 1521 を認可されたアプリケーションセグメントに制限 North-South トラフィック ingress/egress フィルタリング用の FortiGate または同等のインスペクション VPC 保管時の暗号化 AWS Key Management Service (AWS KMS) で暗号化された FSx for ONTAP ボリューム 転送時の暗号化 NFS トラフィック用の VPC 暗号化、および SnapMirror クロスリージョン用の IPsec データベース暗号化 追加の保護のための Oracle TDE (Transparent Data Encryption) 管理アクセス VMware 管理コンソール向けのゼロトラストアクセス (例: Banyan または Zscaler) VLAN サブネットセキュリティ ネットワーク ACL (VLAN インターフェイスではセキュリティグループは適用されない) コスト最適化 Amazon EVS 上の Oracle のコスト最適化は、インフラストラクチャ容量をワークロード需要に合わせることと、AWS の料金モデルを使用することに重点を置いています。以下の表は、コンピューティング、ストレージ、ネットワーキング、Oracle ライセンスにわたる主要な戦略をまとめたものです。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 コンポーネント 戦略 EC2 ベアメタルホスト Compute Savings Plans または リザーブドインスタンス (最大 54% の節約) インスタンスタイプの選択 i7i.metal-24xl は i4i.metal に対して価格性能が約 10% 向上 FSx for ONTAP のスループット 書き込みワークロードに合わせて適正なサイジングを行い、臨機応変に調整 FSx for ONTAP のストレージ Oracle には 100% SSD、非本番環境にはストレージ効率化 データ転送 FSx for ONTAP を EVS クラスターと同じ AZ に配置 SnapMirror レプリケーション RPO に基づいて頻度をスケジュール (頻度が低い = 低コスト) Oracle DR ライセンス NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートし、Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせずデータ保護 (DP) ボリュームとして保持。フェイルオーバーイベントが宣言された時点で、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れる。さらなるガイドラインについては AWS Optimization and Licensing Assessment (AWS OLA) のリクエストを推奨。 非本番環境 より少ないホストを使用し、開発/テストデータに階層化を適用 まとめ FSx for ONTAP を使用した Amazon EVS 上での Oracle データベースのデプロイメントは、VMware の運用一貫性と AWS クラウドの経済性を組み合わせながら、高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを提供します。 パフォーマンス: i7i.metal-24xl は最大 23% 優れたコンピューティングと 50% 低い IO レイテンシーを提供。FSx for ONTAP は最大 80,000 IOPS でサブミリ秒のレイテンシーを提供。詳細は AWS GovCloud (US) リージョンの Amazon EC2 i7i インスタンス を参照。 可用性: vSphere HA、SnapMirror クロスリージョンレプリケーション、およびオプションの Oracle Data Guard。 管理性: データベースサイズに関係なく数秒でバックアップ、クローン、復旧を行う SnapCenter。 移行の柔軟性: HCX (ライブ)、SnapMirror ( ONTAP-to-ONTAP )、PDB リロケーション (マルチテナント)、RMAN (汎用)。 セキュリティ: NSX マイクロセグメンテーション、AWS KMS 暗号化、ゼロトラストアクセス。 コスト効率: i7i による価格性能の向上、臨機応変なスループット調整、AWS Savings Plans。 このアーキテクチャは、使い慣れた VMware の運用ツールと手順を維持しながら、Oracle RAC や Data Guard の機能に類似した高可用性、クロスリージョン DR、ストレージベースのバックアップとクローンを提供します。 次のステップ このデプロイメントを始めるには: 対象リージョンに Amazon EVS 環境をプロビジョニングします。セットアップ手順については Amazon EVS ユーザーガイド を参照します。 EVS クラスターと同じ VPC およびアベイラビリティーゾーンに FSx for ONTAP ファイルシステムをデプロイします。 NFS データストアのマウント、Oracle VMDK の作成、SnapMirror DR の設定については、関連記事のステップバイステップ手順に従います。 まず非本番環境でテストし、その後本番の Oracle ワークロードを移行します。 その他のリソース Amazon EVS ユーザーガイド Amazon EVS がサポートする VCF バージョンとインスタンスタイプ Amazon EVS を使用した FSx for ONTAP Amazon EVS の料金 AWS News Blog での Amazon EVS の紹介 Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ (関連記事) 著者について Satish Bhoi Satish Bhoi は AWS Enterprise Support のテクニカルアカウントマネージャーであり、お客様のクラウドソリューションの設計と最適化を支援しています。20 年以上の業界経験を持ち、クラウドアーキテクチャを専門とし、クラウドコンピューティングのアプリケーションを探求することに情熱を注いでいます。仕事以外では、Satish はリーグクリケットをプレイし、若い選手を指導し、旅行と冒険を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 Sudhir Balasubramanian Sudhir Balasubramanian は AWS のシニア SA データベーススペシャリストであり、Oracle ACE、VMware vExpert、Nutanix NCP、スピーカー、ブロガー、著者、テクノロジスト、エバンジェリスト、パートナー＆カスタマーアドボケイトです。Sudhir は個人ウェブサイト vracdba.com で頻繁にブログを書いています。Sudhir は、お客様やパートナーと協力して、複雑な問題を解決しカスタマーエクスペリエンスを向上させる創造的なソリューションを構築することが大好きです。仕事以外では、Sudhir はハイキング、ウォーキング、料理、そしてクラシックロックとメタルを聴くことが好きです。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

本稿は、2026 年 10 月 2 日に公開された “ Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP ” を翻訳したものです。 この記事では、NFS データストアストレージとして Amazon FSx for NetApp ONTAP を使用して、 Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイするためのステップバイステップの手順を紹介します。ストレージボリュームのプロビジョニング、NFS データストアのマウント、Oracle のインストール、そしてクロスリージョンディザスタリカバリのための SnapMirror レプリケーションの設定を行います。 VMware 上で Oracle データベースを稼働させている企業は、再設計や再教育を行うことなく既存の運用ワークフローを維持できる AWS への移行パスを求めています。関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」では、 Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスの選択、VM のサイジング、vSAN と FSx for ONTAP 間でのストレージの分割、クロスリージョン DR のための SnapMirror レプリケーションの計画など、環境を設計する方法を説明しました。 この記事は、アーキテクチャ編の続きです。Oracle VM のプロビジョニングと FSx for ONTAP ボリュームの作成から、NFS データストアのマウント、Oracle 19c のインストール、SnapMirror と SnapCenter の設定まで、スタック全体をデプロイするためのステップバイステップの手順を紹介します。また、既存のオンプレミス Oracle ワークロードを Amazon EVS に移行するための 4 つの移行パスと、スナップショットバックアップ、ポイントインタイムリカバリ、データベースクローニングを含む Day 2 運用についても説明します。 アーキテクチャの決定、インスタンスタイプの選択、ストレージ設計の根拠、高可用性の計画については、関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」を参照してください。 ステップバイステップのデプロイメント手順 このセクションでは、Oracle VM のプロビジョニング、FSx for ONTAP ストレージボリュームの作成、vSphere での NFS データストアのマウント、Oracle 19c のインストール、クロスリージョン DR のための SnapMirror の設定まで、エンドツーエンドのデプロイメントワークフローを説明します。まず前提条件を完了してから、ステップ 1 から 8 を順番に実行してください。 前提条件 Amazon EVS 環境がデプロイ済み (VCF 9.1、ESXi 9.1。VCF 9.x では、Amazon EVS がベアメタルインフラストラクチャと VLAN をプロビジョニングし、お客様が Broadcom の VCF Installer を使用して VCF をデプロイします)。 クラスターあたり最低 4 ホスト。Oracle には専用の DB クラスターを推奨。 Amazon VPC Route Server エンドポイント、 AWS Transit Gateway 、 AWS Direct Connect が設定された Amazon Virtual Private Cloud (Amazon VPC) 。 FSx for ONTAP プロビジョニングのための AWS Identity and Access Management (IAM) 権限。 VCF ライセンスエンタイトルメント (Broadcom からの BYOL)。 ステップ 1: Amazon EVS 上に Oracle VM をデプロイする Amazon EVS の vCenter に接続された vSphere Client にログインします。 本番 DB クラスターに新しい仮想マシンを作成します。 ゲスト OS: Red Hat Enterprise Linux 8 (64 ビット) または Oracle Linux 8 vCPU: Oracle ワークロードに応じてサイジング (一般的に 8〜32 vCPU) メモリ: SGA/PGA 要件に基づいて 32〜256 GiB ディスク: vSAN データストア上に 100 GiB (OS + Oracle Home + スワップ + 一時表領域) ネットワーク: prod-trusted Tier-1 ゲートウェイ上の DB セグメントに接続 VM の電源を入れ、ゲスト OS を設定します。 # ホスト名を設定 hostnamectl set-hostname ora-db1 # vSAN データストア上のディスクにスワップを作成 (ローカル NVMe、1 桁ミリ秒のレイテンシー) # vSAN データストアは VM のプライマリディスクとして既に利用可能 # スワップ用に専用のパーティションまたは LV を割り当て lvcreate -L 16G -n swap vgos mkswap /dev/vgos/swap swapon /dev/vgos/swap echo "/dev/vgos/swap swap swap defaults 0 0" >> /etc/fstab # Oracle の前提条件をインストール sudo yum install -y oracle-database-preinstall-19c python3 HA/DR については、DR クラスターに別途ライセンスを取得したインスタンスを維持するのではなく、Oracle VM 全体をレプリケートすることを検討してください (関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」の「DR に関する Oracle ライセンスの考慮事項」を参照)。 Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響します。これは考慮すべき重要な要素です。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ステップ 2: FSx for ONTAP をプロビジョニングする Amazon FSx コンソールを開き、 [ファイルシステムの作成] を選択し、 [Amazon FSx for NetApp ONTAP] を選択します。 [標準作成] を選択して設定します。 設定 値 デプロイメントタイプ シングルアベイラビリティーゾーン (AZ)。Amazon EVS では必須 SSD ストレージ容量 Oracle データ + ログ + 20% の余裕に合わせたサイズ スループット容量 512〜2,048 MB/s (書き込みワークロードに合わせたサイズ。非対称性の注記を参照) IOPS 自動 (3/GiB) またはユーザープロビジョニング (最大 80,000) VPC Amazon EVS 環境と同じ VPC サブネット Amazon EVS サービスアクセスサブネット、DB クラスターと同じ AZ セキュリティグループ Amazon EVS マネジメント VLAN からの NFS (TCP 2049、111、635) を許可 fsxadmin パスワードを設定します (ONTAP CLI 自動化に必須)。 vsadmin パスワードで SVM (Storage Virtual Machine) を作成します。 自動日次バックアップを無効にします。代わりに Oracle 対応のスケジューリングには SnapCenter を使用します。 作成後、[SVM] を選択し、[エンドポイント] を選択して、NFS DNS 名をコピーします。 ステップ 3: Oracle データベースボリュームを作成する SSH ( ssh fsxadmin@management-endpoint ) を使用して FSx for ONTAP クラスターに接続し、ボリュームを作成します。 # Oracle バイナリボリューム vol create -volume oradb1bin -aggregate aggr1 -size 50G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1bin # Oracle データボリューム vol create -volume oradb1data -aggregate aggr1 -size 500G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1data # Oracle ログボリューム (REDO + アーカイブ) vol create -volume oradb1log -aggregate aggr1 -size 250G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1log すべてのデータを SSD 階層に固定するために -tiering-policy none を設定します。ログボリュームは 24 時間分のアーカイブログに合わせてサイジングします。 ステップ 4: vSphere で FSx for ONTAP を NFS データストアとしてマウントする vSphere Client で、[DB クラスター] を選択し、[設定] > [ストレージ] > [新しいデータストア] を選択します。 [NFS] を選択し、[NFS 3] を選択します。 以下を入力します。 サーバー: svm-id.fs-id.fsx.region.amazonaws.com フォルダー: /oradb1data データストア名: fsx-ora-db1-data バイナリ ( /oradb1bin ) およびログ ( /oradb1log ) ボリュームについても繰り返します。 3 つすべてのデータストアがクラスターストレージビューで正しい容量を表示していることを確認します。 ステップ 5: FSx for ONTAP データストア上に Oracle VMDK を作成する NFS データストアを ESXi ホストレベルでマウントした状態で (ステップ 4)、これらのデータストア上に Oracle 用の仮想ディスクを作成します。 vSphere Client で、Oracle VM を選択し、[設定の編集] を選択してから、[新しいデバイスを追加] > [ハードディスク] を選択します。 以下の VMDK を作成します。 VMDK データストア サイズ ゲストマウント 用途 Hard Disk 2 fsx-ora-db1-data 500 GiB /u02 Oracle データファイル Hard Disk 3 fsx-ora-db1-log 250 GiB /u03 Oracle REDO + アーカイブログ Hard Disk 4 fsx-ora-db1-bin 50 GiB /u01 Oracle Home バイナリ データおよびログ VMDK には Thick Provision, Eager Zeroed を選択します (Oracle でベストなパフォーマンスを得るため)。 Oracle Database は Oracle ASM またはファイルシステム (ローカル/NFS) 上に作成できます。この手順では、ローカル XFS ファイルシステム上に Oracle データベースを作成します。 Oracle VM ゲスト OS 内で、新しいディスクをパーティション分割してマウントします。 # 新しいディスクを識別 lsblk # 各ディスクにファイルシステムを作成 (例: データ用に /dev/sdb) mkfs.xfs /dev/sdb mkfs.xfs /dev/sdc mkfs.xfs /dev/sdd # マウントポイントを作成 mkdir -p /u01 /u02 /u03 # マウント mount /dev/sdd /u01 # Oracle Home (バイナリ) mount /dev/sdb /u02 # Oracle データファイル mount /dev/sdc /u03 # Oracle REDO + アーカイブログ # /etc/fstab に永続化 cat >> /etc/fstab <<EOF /dev/sdb /u02 xfs defaults,noatime 0 0 /dev/sdc /u03 xfs defaults,noatime 0 0 /dev/sdd /u01 xfs defaults,noatime 0 0 EOF # 所有権を設定 chown -R oracle:oinstall /u01 /u02 /u03 重要なポイント: Oracle VM は /u02 と /u03 にローカル XFS ブロックデバイスとしてアクセスします。基盤となるストレージが FSx for ONTAP 上の NFS データストアであることを認識していません。すべての NFS 通信は ESXi ホストレベルで行われ、各ホストは FSx for ONTAP へ個別のネットワークパスを使用します。 ステップ 6: Oracle 19c をインストールして設定する # oracle ユーザーとして export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 cd $ORACLE_HOME ./runInstaller -silent -responseFile /path/to/db_install.rsp データを /u02 に、ログを /u03 に配置してデータベースを作成します。 CREATE DATABASE orcl DATAFILE '/u02/oradata/orcl/system01.dbf' SIZE 1G LOGFILE GROUP 1 '/u03/oralogs/orcl/redo01.log' SIZE 512M, GROUP 2 '/u03/oralogs/orcl/redo02.log' SIZE 512M, GROUP 3 '/u03/oralogs/orcl/redo03.log' SIZE 512M; Oracle は /u02 と /u03 にローカル XFS ファイルシステムとしてアクセスします。標準の Oracle ASM またはファイルシステムベースのストレージ管理が適用されます。NFS レイヤーは ESXi ハイパーバイザーによって抽象化されているため、NFS 固有の Oracle 設定は必要ありません。 ステップ 7: クロスリージョン DR のために SnapMirror をセットアップする クラスターをピアリングします (本番 → DR)。 cluster peer create -peer-addrs <dr-cluster-intercluster-ip> \ -username fsxadmin -initial-allowed-vserver-peers * SVM をピアリングします。 vserver peer create -vserver svm-prod -peer-vserver svm-dr \ -peer-cluster FSxDR -applications snapmirror DR 側の FSx for ONTAP 上に DP ボリュームを作成します。 vol create -volume oradb1bin -aggregate aggr1 -size 50G -state online -type DP vol create -volume oradb1data -aggregate aggr1 -size 500G -state online -type DP vol create -volume oradb1log -aggregate aggr1 -size 250G -state online -type DP SnapMirror を作成して初期化します。 snapmirror create -source-path svm-prod:oradb1data \ -destination-path svm-dr:oradb1data -throttle unlimited \ -policy MirrorAllSnapshots -type DP snapmirror create -source-path svm-prod:oradb1log \ -destination-path svm-dr:oradb1log -throttle unlimited \ -policy MirrorAllSnapshots -type DP snapmirror create -source-path svm-prod:oradb1bin \ -destination-path svm-dr:oradb1bin -throttle unlimited \ -policy MirrorAllSnapshots -type DP # 初期化 snapmirror initialize -destination-path svm-dr:oradb1data snapmirror initialize -destination-path svm-dr:oradb1log snapmirror initialize -destination-path svm-dr:oradb1bin 重要: DR 戦略を計画する際は、Oracle のライセンス要件を考慮してください。代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。その時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。SnapMirror ボリュームを (VM の電源が入っていなくても) データストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリがアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ステップ 8: SnapCenter バックアップを設定する SnapCenter Server をデプロイします (または SnapCenter SaaS を使用)。 クラスター管理 IP を使用して FSx for ONTAP ストレージシステムを追加します。 各 Oracle VM に SnapCenter Plugin for Oracle をインストールします。 バックアップポリシーを作成します。 ポリシー スコープ 頻度 SnapMirror 更新 フル DB バックアップ データ + 制御ファイル + アーカイブログ 4〜6 時間ごと はい アーカイブログ アーカイブログのみ 10〜15 分ごと はい リソースグループを作成し、ポリシーを割り当て、スケジュールを設定します。 オンプレミス VMware から Amazon EVS へのデータベース移行 オプション 1: VMware HCX ライブマイグレーション 既存のオンプレミス VMware を持つ企業向け: オンプレミスに HCX Connector を、Amazon EVS に HCX Cloud Manager をデプロイします。 サイトペアリングとネットワーク拡張 (L2 ストレッチ) を作成します。 HCX vMotion (ゼロダウンタイム) または Bulk Migration を使用して Oracle VM を移行します。 移行後: スナップショット/レプリケーション機能のために、Oracle VMDK を vSAN から FSx for ONTAP NFS データストアへストレージ vMotion します。 オプション 2: SnapMirror ONTAP-to-ONTAP オンプレミスの Oracle が既に NetApp ONTAP ストレージを使用している場合: オンプレミス ONTAP と FSx for ONTAP 間で SnapMirror を確立します。 切り替えまで増分でレプリケートします。 切り替え時: Oracle を休止し、アーカイブログをフラッシュし、最終 SnapMirror 同期を行い、ミラーを解除します。 Amazon EVS 上の Oracle VM に FSx for ONTAP ボリュームをマウントし、データベースをリカバリし、サービスを開始します。 オプション 3: Oracle PDB リロケーション (マルチテナント) Oracle データベースが既に PDB/CDB マルチテナントモデルにある場合: FSx for ONTAP ストレージを使用して Amazon EVS 上にターゲット CDB を作成します。 PDB ホットクローンを使用して、オンプレミス CDB から AWS 上の CDB へ PDB をリロケートします。 サービス中断は最小限です。最終切り替えのみ短時間の停止が必要です。 オプション 4: RMAN バックアップ/リストア (非 ONTAP オンプレミス) Oracle がオンプレミスで非 ONTAP ストレージ上で稼働している場合: RMAN バックアップを作成し、 AWS DataSync または AWS Direct Connect を使用して Amazon Simple Storage Service (Amazon S3) に一時保管します。 Amazon EVS 上に Oracle VM をプロビジョニングし、FSx for ONTAP ボリュームをマウントします。 RMAN バックアップからリストアし、アーカイブログを適用します。 データベースを開始し、アプリケーションをリダイレクトします。 Day 2 運用 スナップショットバックアップ SnapCenter は、フルデータベーススナップショットをストレージレイヤーの操作として管理し、効率的なバックアップ機能を提供します。 ポイントインタイムリカバリ SnapCenter で、SCN またはタイムスタンプを選択し、ログスナップショットをマウントし、データスナップショットをリストアし、アーカイブログを適用し、RESETLOGS で開きます。 データベースクローニング SnapCenter FlexClone は、スペース効率の良いデータベースコピーを作成します。クローンは変更されていないブロックをソースと共有し、差分に対してのみストレージを消費します。開発/テスト、パッチ検証、レポーティングに使用します。 HA フェイルオーバー手順 DR ボリューム上の SnapMirror を解除します。 SnapMirror ボリュームを DR ESXi ホスト上に NFS データストアとしてマウントし、Oracle VM の電源を入れます。 利用可能な最後のアーカイブログまでリカバリします。 データベースを開きます。DNS/接続先を更新します。 クリーンアップ このデプロイメントのテスト後に料金が発生しないようにするには、以下のリソースをこの順序で削除します。 Oracle VM — Oracle データベース VM を停止し、vSphere インベントリから削除します。 NFS データストア — vSphere で ESXi ホストから FSx for ONTAP データストアをアンマウントします。 SnapMirror 関係 — DR 側の FSx for ONTAP ファイルシステム上の SnapMirror 関係と DP ボリュームを削除します。 FSx for ONTAP ファイルシステム — Amazon FSx コンソールから本番および DR の両方のファイルシステムを削除します。この操作により、それらのファイルシステム上のすべてのボリュームとデータが削除されます。 Amazon EVS 環境 — Amazon EVS コンソールから Amazon EVS 環境を削除します。これにより、基盤となる EC2 ベアメタルインスタンスが終了します。 ネットワーキング — このデプロイメントのためだけに作成された場合は、Transit Gateway アタッチメント、VPC Route Server 設定、Direct Connect 接続を削除します。 重要: FSx for ONTAP ファイルシステムを削除すると、すべてのデータが完全に削除されます。続行する前に、必要なデータをバックアップ済みであることを確認してください。 まとめ この記事では、NFS データストアストレージとして FSx for ONTAP を使用して、Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイする手順を説明しました。Oracle VM をプロビジョニングし、FSx for ONTAP ボリュームを作成し、vSphere で NFS データストアをマウントし、Oracle 19c をインストールし、クロスリージョンディザスタリカバリのための SnapMirror と Oracle 対応バックアップのための SnapCenter を設定しました。また、既存のオンプレミス Oracle ワークロードのための 4 つの移行パスと、バックアップ、ポイントインタイムリカバリ、クローニングのための Day 2 運用についても説明しました。 始めるには、 Amazon EVS ユーザーガイド と「 FSx for ONTAP で Amazon Elastic VMware Service を使用します 」を確認してから、Amazon EVS 上に最初の Oracle VM をデプロイしてください。このデプロイメントの背後にあるアーキテクチャの決定については、関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」を参照してください。フィードバックやご質問はコメント欄でお寄せください。 その他のリソース Amazon EVS ユーザーガイド Amazon EVS がサポートする VCF バージョンとインスタンスタイプ FSx for ONTAP で Amazon Elastic VMware Service を使用します Amazon EVS の料金 Amazon EVS の紹介 — AWS Blog 著者について Satish Bhoi Satish Bhoi は AWS Enterprise Support のテクニカルアカウントマネージャーであり、お客様のクラウドソリューションの設計と最適化を支援しています。20 年以上の業界経験を持ち、クラウドアーキテクチャを専門とし、クラウドコンピューティングのアプリケーションを探求することに情熱を注いでいます。仕事以外では、Satish はリーグクリケットをプレイし、若い選手を指導し、旅行と冒険を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 Sudhir Balasubramanian Sudhir Balasubramanian は AWS のシニア SA データベーススペシャリストであり、Oracle ACE、VMware vExpert、Nutanix NCP、スピーカー、ブロガー、著者、テクノロジスト、エバンジェリスト、パートナー＆カスタマーアドボケイトです。Sudhir は個人ウェブサイト vracdba.com で頻繁にブログを書いています。Sudhir は、お客様やパートナーと協力して、複雑な問題を解決しカスタマーエクスペリエンスを向上させる創造的なソリューションを構築することが大好きです。仕事以外では、Sudhir はハイキング、ウォーキング、料理、そしてクラシックロックとメタルを聴くことが好きです。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。