本記事は 2026 年 3 月 6 日に公開された “ AWS Load Balancer Controller adds general availability support for Kubernetes Gateway API ” を翻訳したものです。 AWS は最近、 Amazon Web Services (AWS) Load Balancer Controller による Kubernetes Gateway API サポートの一般提供を発表しました。これまで、AWS Load Balancer Controller は Kubernetes Ingress と Service リソースの要件を満たすため、それぞれ Application Load Balancer (ALB) と Network Load Balancer (NLB) をプロビジョニングしていました。この新機能により、標準の Kubernetes Gateway API を使用してAWSロードバランシング機能を定義できるようになりました。この投稿では、AWS Load Balancer Controller の Kubernetes Gateway API サポートをご紹介します。Gateway API 統合の構成ベストプラクティス、機能、ユースケースを共有し、AWS 上での Kubernetes デプロイメントのモダナイゼーションと合理化を支援します。 前提条件 Kubernetes API、コントローラー、Deployments、Services、カスタムリソースなどのリソースタイプを含む Kubernetes の概念に精通していることを前提としています。また、 Amazon Elastic Kubernetes Service (Amazon EKS) と AWS ロードバランシングサービスについての基本的な理解も必要です。これらの概念を復習する必要がある場合は、Kubernetes ドキュメントと Amazon EKS ユーザーガイドから始めることをお勧めします。 Gateway API 概要 Gateway API は、Kubernetes クラスターで L4 (TCP/UDP) および L7 (HTTP/gRPC) トラフィックルーティングを管理するための次世代フレームワークです。従来の Ingress API よりも柔軟で表現力豊かなロール指向のアプローチを提供し、Ingress における以前の制限に対処しています。流入トラフィック (north-south トラフィック) やサービス間接続 (east-west トラフィック) を含む、幅広いトラフィック管理ニーズに対応する標準化された、ポータブルで拡張可能な仕様を提供します。 Ingress API は長年にわたって Kubernetes ユーザーによく貢献してきましたが、Gateway API が対処するいくつかの制限があります。Ingress は高度な機能に対してベンダー固有のアノテーションに依存しており、異なる実装間での構成の移植性を低下させています。さらに、ロールベースのリソース管理のネイティブサポートが不足しており、これはクラスター運用者とアプリケーション開発者が同じ構成面を共有することを意味します。Gateway API は、インフラストラクチャプロバイダー (GatewayClass)、クラスター運用者 (Gateway)、アプリケーション開発者 (Routes) に対して異なるリソースを持つロール指向設計を導入しています。この分離により、より良い組織ポリシーとセキュリティ境界が可能になります。さらに、Gateway API は、クロス名前空間ルーティング、重み付きトラフィック分割、ヘッダーベースルーティング、L4 と L7 の両方のプロトコルに対するネイティブサポートを提供します。これらの機能は以前は複雑な回避策が必要であったか、Ingress だけでは不可能でした。これらの改善により、Gateway API はより表現力豊かで拡張可能であり、現代のクラウドアーキテクチャに適したものになります。 AWS のフルマネージドアプリケーションネットワーキングサービスである Amazon VPC Lattice は、 Amazon VPC Lattice Gateway API Controller を通じて Kubernetes Gateway API のサポートを既に提供しています。これは、VPC とアカウント内の EKS クラスター間でサービス間接続を可能にする別のコントローラーです。AWS Load Balancer コントローラーも Gateway API 仕様をサポートすることで、ALB と NLB による流入 (north-south）トラフィック管理と、east-west サービスメッシュ機能に VPC Lattice を使用する柔軟性の両方について包括的なカバレッジを得ることができます。そして、これらはすべて同じ標準化された Gateway API リソースを使用して実現されます。 Gateway API コンポーネント Gateway API は、Kubernetes クラスターへのトラフィックの流入と通過の方法を定義するために連携する 3 つのコアリソースを導入します。これらのコンポーネントとそれらが AWS インフラストラクチャにどのようにマッピングされるかを理解することで効果的なトラフィック管理戦略を設計できます。図 1 は Gateway API 仕様のコンポーネントを示しています: 図 1 : Gateway API コントローラーコンポーネント [ 出典 ] GatewayClass GatewayClass は、共通の構成と動作を持つ Gateway を作成するためのテンプレートを定義します。プラットフォームチームは GatewayClass を使用して組織ポリシーとインフラストラクチャテンプレートを確立します。例えば、GatewayClass はどのコントローラーが Gateway を管理するか (AWS Load Balancer Controller など) と、どのタイプのロードバランサーをプロビジョニングするか (ALB または NLB) を指定します。 以下は、ALB をプロビジョニングする GatewayClass の例です: apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: aws-alb spec: controllerName: gateway.k8s.aws/alb Gateway Gateway はロードバランサーをインスタンス化し、トラフィックがクラスターにどのように入るかを定義します。クラスター運用者は、リスナー (プロトコルとポートの組み合わせ)、ホスト名、TLS 設定を指定するように Gateway を構成します。Gateway を作成すると、AWS Load Balancer Controller は指定されたリスナーで対応する AWS ロードバランサーをプロビジョニングします。 以下は、HTTP と HTTPS リスナーを持つ ALB を作成する Gateway の例です: apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway namespace: default spec: gatewayClassName: aws-alb listeners: - name: http protocol: HTTP port: 80 - name: https protocol: HTTPS port: 443 hostname: example.com Routes Routes は、リスナーをバックエンド Kubernetes サービスにマッピングするルーティングルールを定義します。アプリケーション開発者は、パス、ヘッダー、ホスト名などのリクエスト属性に基づいてトラフィックがサービスにどのように分散されるかを制御するために Routes (HTTPRoute、GRPCRoute、TCPRoute、UDPRoute、TLSRoute) を作成します。 以下は、Gateway の HTTP リスナーから Kubernetes サービスにトラフィックをルーティングする HTTPRoute の例です: apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: my-route namespace: default spec: parentRefs: - name: my-gateway sectionName: http rules: - matches: - path: type: PathPrefix value: /app backendRefs: - name: my-service port: 8080 AWS Load Balancer Controller は Kubernetes Gateway API オブジェクトの調整をサポートしています。以下を満たします: TCPRoute や UDPRoute などの L4 ルートを AWS NLB で HTTPRoute や GRPCRoute などの L7 ルートを AWS ALB で 動作の仕組み AWS Load Balancer Controller が Gateway API リソースを AWS インフラストラクチャにどのように変換するかを理解することで、より信頼性の高いアプリケーションを設計し、問題をより迅速にトラブルシューティングできます。コントローラーの調整モデルにより、Kubernetes の定義が AWS ロードバランサーと同期された状態を保ち、継続的な検証とリアルタイムステータスフィードバックを提供します。 高レベルでは、以下のステップが調整ループの動作を示しています: API 監視 : Gateway API リソースの作成、変更、削除について、Kubernetes API が継続的に監視されます。 キューイング : コントローラーは特定されたリソースを処理のための内部キューに追加します。 処理 : 内部キューの各アイテムに対して: コントローラーは関連する GatewayClass をチェックして、ユーザーが AWS ロードバランサーを要求しているかどうかを確認します。 yes の場合、対応する Gateway リソースの Gateway API 定義が、NLB/ALB、リスナー、リスナールール、ターゲットグループ、またはアドオンなどの AWS リソースにマッピングされます。 これらのマッピングされたリソースは、AWS の実際の状態と比較されます。差分があると、コントローラーは AWS の状態を Gateway オブジェクトによって設定された望ましい状態と一致させます。 ステータス更新 : 調整後、AWS Load Balancer Controller は対応する Gateway および Route リソースのステータスフィールドを更新します。これにより、ALB の DNS 名や Amazon Resource Name (ARN) などのプロビジョニングされた AWS リソース、およびデバッグを支援するエラー詳細について、リアルタイムフィードバックが提供されます。例えば、HTTPRoute を作成すると、ステータスフィールドにはルートが受け入れられたかどうか、それが接続されている Gateway、およびプロビジョニング時にトラフィックルーティングに使用する ALB の DNS 名がすぐに表示されます。無効な証明書 ARN などの構成エラーがある場合、ステータスフィールドは実用的なエラーメッセージを提供します。 図 2 は、この調整フローを詳細に示しています。コントローラーは Gateway API リソースに対するウォッチを確立し、内部キューを通じて変更を処理し、望ましい状態の中間表現を構築し、対応する AWS リソースを実現します。このプロセス全体を通じて、プロビジョニングの進行状況と発生したエラーを反映するためにステータス条件が更新されます。 図 2 : Gateway API コントローラー調整フロー この宣言的アプローチは、望ましいロードバランシング構成を一度定義すると、コントローラーが AWS がその意図と一致することを継続的に保証することを意味します。これにより、ドリフトと構成変更が自動的に処理されます。 主要機能 このセクションでは、Load Balancer Controller Gateway API サポートの主要機能について説明します: 強化されたカスタマイズ AWS Load Balancer Controller は、適切に定義された Kubernetes Custom Resource Definitions (CRD) を採用し、アノテーションベースの構成を廃止します。この変更により、検証や IDE サポートが不足しているアノテーション文字列に複雑なデータ構造を埋め込むという制限に対処します。例えば: Before (アノテーションベースアプローチ): apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress annotations: alb.ingress.kubernetes.io/target-group-attributes: | deregistration_delay.timeout_seconds=30, stickiness.enabled=true, stickiness.type=lb_cookie After (CRDベースアプローチ): apiVersion: gateway.k8s.aws/v1beta1 kind: TargetGroupConfiguration metadata: name: my-app-tg-config namespace: my-app spec: targetReference: name: my-service defaultConfiguration: targetGroupAttributes: - key: deregistration_delay.timeout_seconds value: "30" - key: stickiness.enabled value: "true" - key: stickiness.type value: lb_cookie healthCheckConfig: healthyThresholdCount: 5 healthCheckInterval: 30 healthCheckPath: /health healthCheckPort: "8080" healthCheckProtocol: HTTP healthCheckTimeout: 5 unhealthyThresholdCount: 2 AWS Load Balancer Controller は Gateway API カスタマイズのために 3 つの CRD を導入しています： TargetGroupConfiguration : サービスレベルでヘルスチェック、登録解除遅延、スティッキネス設定を含むターゲットグループプロパティを構成 LoadBalancerConfiguration : Gateway または GatewayClass レベルでサブネット配置、セキュリティグループ、アクセスログなどのリスナーおよびロードバランサープロパティを定義 ListenerRuleConfiguration : Amazon Cognito または OIDC プロバイダーを通じた認証を含む AWS 固有のルーティング動作で HTTPRoute および GRPCRoute リソースを拡張 これらの CRD は、スキーマ検証、タイプセーフティ、GitOps ワークフローとのネイティブ統合を提供します。構成エラーは実行時ではなく適用時に表面化し、運用オーバーヘッドを削減し、インフラストラクチャの信頼性を向上させます。 Cross-Namespace トラフィックルーティング Gateway API は、Cross-Namespace ルーティングを通じてインフラストラクチャ運用者とアプリケーション開発者の間の関心の分離を可能にします。プラットフォームチームは共有 Gateway リソースをプロビジョニングし、アプリケーションチームはクラスターレベルの権限を必要とせずに独自の Rout を管理します。 このモデルでは、プラットフォームチームがアクセス制御された専用の名前空間に Gateway をデプロイします。別々の名前空間のアプリケーションチームは、共有 Gateway を参照する Route リソースを作成します。コントローラーは、これらの分散された定義に基づいてトラフィックをルーティングするようにロードバランサーを自動的に構成します。 このアーキテクチャは、Kubernetes API レベルで RBAC 境界を強制します。アプリケーションチームは、サブネット配置やセキュリティグループ割り当てなどのインフラストラクチャレベルの構成にアクセスすることなく、サービスのルーティングロジックを管理します。 自動 TLS 証明書検出 AWS Load Balancer Controller は、L4 と L7 の両方のプロトコルについて、Ingress API から Gateway API リスナーへの証明書検出を拡張します。Gateway リスナーまたは Route ホスト名でホスト名が指定されると、コントローラーは AWS Certificate Manager (ACM) にクエリを実行して、ホスト名マッチングに基づいて一致する証明書を見つけて添付します。 コントローラーは証明書の更新について ACM を監視し、ロードバランサー構成に変更を自動的に適用します。これにより、手動での証明書 ARN 管理が不要になり、複数の環境間での証明書ローテーションの運用複雑性が軽減されます。 これらの機能により運用オーバーヘッドを削減し、関心の分離を改善した本格的な AWS 上の Kubernetes ネットワーキングが可能になります。型安全な CRD、Cross-Namespace ルーティング、自動証明書管理の組み合わせにより、チームはインフラストラクチャ構成ではなくアプリケーション配信に集中できます。 始め方 初回ユーザーの場合は、インストールガイドに従ってください。このガイドでは、必要な AWS Identity and Access Management (IAM) 権限を設定し、AWS Load Balancer Controller を Kubernetes クラスターにデプロイします。 AWS Load Balancer Controller で Gateway API サポートを有効にするには、まず 前提条件 が満たされていることを確認してください。その後、Gateway API サポートを有効にするには、 こちら で説明されているように機能フラグを有効にする必要があります。 構成例 この例では、AWS Load Balancer Controller Gateway API 統合の 3 つの主要機能を実証します : HTTP ルーティング、自動証明書検出を使用した HTTPS ルーティング、ListenerRuleConfiguration を使用したカスタムルーティングルール。デプロイメント手順と検証コマンドを含む完全なウォークスルーについては、AWS Load Balancer Controller Gateway API の例を参照してください。 この例では、以下のアーキテクチャでALBをプロビジョニングします： ポート 80 の HTTP リスナーが blue デプロイメントにルーティング ポート 443 の HTTPS リスナーが自動証明書検出により orange デプロイメントにルーティング HTTP リスナー上の /alb-response パスに対して固定レスポンスを返すカスタムルーティングルール 構成概要 構成には以下が含まれます: AWS Load Balancer Controller を実装として定義する GatewayClass : # alb-gatewayclass.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: GatewayClass metadata: name: aws-alb-gateway-class spec: controllerName: gateway.k8s.aws/alb HTTP および HTTPS リスナーを持つ Gateway : # my-alb-gateway.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: my-alb-gateway namespace: example-ns spec: gatewayClassName: aws-alb-gateway-class infrastructure: parametersRef: kind: LoadBalancerConfiguration name: lbconfig-gateway group: gateway.k8s.aws listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: Same - name: https hostname: "sample.com" protocol: HTTPS port: 443 allowedRoutes: namespaces: from: Same スキームまたはその他のゲートウェイ構成パラメータ用の LoadBalancerConfiguration : # lb-config-gateway.yaml apiVersion: gateway.k8s.aws/v1beta1 kind: LoadBalancerConfiguration metadata: name: lbconfig-gateway namespace: example-ns spec: loadBalancerName: "my-example-gateway-alb" scheme: internet-facing カスタムルーティング動作用の ListenerRuleConfiguration : # listener-rule-config-blue.yaml apiVersion: gateway.k8s.aws/v1beta1 kind: ListenerRuleConfiguration metadata: name: blue-lrc-config namespace: example-ns spec: actions: - type: "fixed-response" fixedResponseConfig: statusCode: 404 contentType: "text/plain" messageBody: "customized text" リスナーをバックエンドサービスにマッピングする HTTPRoutes : # httproute-blue.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-blue namespace: example-ns spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: my-alb-gateway sectionName: http rules: - matches: - path: value: "/alb-response" filters: - type: ExtensionRef extensionRef: group: "gateway.k8s.aws" kind: "ListenerRuleConfiguration" name: "blue-lrc-config" - backendRefs: - name: service-blue port: 80 # httproute-orange.yaml apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: http-route-orange namespace: example-ns spec: parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: my-alb-gateway sectionName: https rules: - backendRefs: - name: service-orange port: 80 デプロイとテスト この例をデプロイするには、バックエンドの DeploymentsとServices が必要です。以下のリソースを作成してください: # deployment-orange.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-orange namespace: example-ns spec: selector: matchLabels: app: orange-app replicas: 1 template: metadata: labels: app: orange-app spec: containers: - image: k8s.gcr.io/e2e-test-images/echoserver:2.5 imagePullPolicy: Always name: echoserver ports: - containerPort: 8080 --- # deployment-blue.yaml apiVersion: apps/v1 kind: Deployment metadata: name: deployment-blue namespace: example-ns spec: selector: matchLabels: app: blue-app replicas: 1 template: metadata: labels: app: blue-app spec: containers: - image: k8s.gcr.io/e2e-test-images/echoserver:2.5 imagePullPolicy: Always name: echoserver ports: - containerPort: 8080 --- # service-orange.yaml apiVersion: v1 kind: Service metadata: name: service-orange namespace: example-ns spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: NodePort selector: app: orange-app --- # service-blue.yaml apiVersion: v1 kind: Service metadata: name: service-blue namespace: example-ns spec: ports: - port: 80 targetPort: 8080 protocol: TCP type: ClusterIP selector: app: blue-app Gateway がプロビジョニングされるまで待機します: kubectl wait --for=condition=Programmed gateway/my-alb-gateway -n example-ns デプロイメントの検証 blue デプロイメントへの HTTP ルーティングをテストします: # ALB ホスト名を取得 ALB_HOSTNAME=$(kubectl get gateway my-alb-gateway \ -n example-ns \ -o jsonpath='{.status.addresses[0].value}') # HTTP エンドポイントをテスト curl http://$ALB_HOSTNAME orange デプロイメントへの証明書検出を使用した HTTPS ルーティングをテストします: curl -k https://$ALB_HOSTNAME -H "Host: sample.com" カスタムルーティングルールをテストします: curl http://$ALB_HOSTNAME/alb-response NLB 構成、Cross-Namespace ルーティング、高度なカスタマイゼーションシナリオを含むその他の例については、AWS Load Balancer Controller ドキュメントを参照してください。 考慮事項 GatewayClass によるポリシー強制 : プラットフォームチームは、サブネット配置、セキュリティグループ割り当て、アクセスログを制御する LoadBalancerConfiguration 設定を持つ GatewayClass リソースを定義します。アプリケーションチームは、インフラストラクチャ変更権限なしに承認された GatewayClass オプションから選択します。これにより、 Kubernetes RBAC を通じて内部ワークロードをインターネット向けロードバランサーから分離するなどの組織ポリシーが強制されます。 標準ベースの移植性 : Gateway、GatewayClass、Route リソースは Kubernetes Gateway API 仕様に従います。コアルーティングロジックは実装間で一貫性を保ちます。AWS 固有の CRD (LoadBalancerConfiguration、TargetGroupConfiguration、ListenerRuleConfiguration) はオプションのままで、コアルーティング定義から分離されています。これにより、必要に応じてAWS固有の機能を持つポータブルなアプリケーション構成が可能になります。 運用可視性 : コントローラーは、リアルタイムプロビジョニング進行状況、リソース識別子 (ロードバランサー ARN と DNS 名)、エラーメッセージで Gateway API ステータスフィールドを更新します。これにより、トラブルシューティング時間が短縮され、リソース状態を確認するための直接的な AWS API クエリが不要になります。 AWS サービス統合 : この実装は、自動証明書検出のための ACM、アプリケーション保護のための AWS WAF 、DDoS 保護のための AWS Shield Advanced と統合されます。ターゲットグループ構成、ヘルスチェック、アクセスログは Amazon S3 および Amazon CloudWatch と統合されます。 GitOps 互換性 : スキーマ検証を持つ型安全な CRDは、デプロイ前検証中に構成エラーを表面化します。Infrastructure as Code (IaC) ツールである Flux 、 ArgoCD 、Kubernetes 用 AWS Cloud Development Kit (AWS CDK) は、自動ドリフト検出を伴う宣言的インフラストラクチャ管理のための Gateway API サポートを提供します。 まとめ AWS Load Balancer Controller の Gateway API サポートは、AWS 上での Kubernetes トラフィック管理に対する標準ベースのアプローチを提供します。Gateway API 仕様を採用することで、Kubernetes 環境間での移植性を維持しながら、ロール指向のリソース管理、Cross-Namespace ルーティング機能、型安全な CRD による拡張されたカスタマイゼーションを得ることができます。プラットフォームチームが Ingress ベースの構成から移行する場合でも、新しい Kubernetes デプロイメントを構築する場合でも、Gateway API 統合によってアプリケーションチームにセルフサービスルーティング機能を提供しながら組織ポリシーを強制することができます。この実装は、証明書管理、セキュリティ、可観測性のためのネイティブ AWS 統合と組み合わせることで運用ワークフローを合理化し、構成の複雑性を軽減します。AWS Load Balancer Controller デプロイメントで Gateway API サポートを有効にして、今すぐ始めましょう。詳細な構成例とベストプラクティスについては、AWS Load Balancer Controller ドキュメントを参照してください。

本記事は 2026/2/24に投稿された Well-Architected design for resiliency with Oracle Database@AWS を翻訳した記事です。 Oracle Database@AWS は、Amazon Web Services（AWS）データセンター内で Oracle Cloud Infrastructure（OCI）によって管理される Oracle Exadata インフラストラクチャを使用する データベースサービス を通じて、エンタープライズグレードのデータベース機能を提供します。Oracle Database@AWS を使用して、オンプレミスの Oracle Exadata と同じパフォーマンスと機能を維持しながら、Oracle Exadata ワークロードを AWS に移行できます。Oracle Exadata と AWS 上で実行されているアプリケーション間で低遅延接続を確立することで、アプリケーション遅延の削減という恩恵を受けることができます。さらに、観測可能性、分析、人工知能と機械学習（AI/ML）、生成 AI アプリケーションの構築など、様々な機能のために Oracle Database@AWS を他のAWS サービスと統合できます。複数のアベイラビリティーゾーンにわたって自動管理、最適化されたパフォーマンス、および組み込みセキュリティ機能を提供することで、Oracle Database@AWS は最高レベルのデータベース信頼性とパフォーマンスを維持しながら運用オーバーヘッドの削減に役立ちます。 高可用性（HA）と災害復旧（DR）オプションは、Oracle Database@AWS で重要なデータベースを移行または展開する際に考慮すべき重要な側面であり、アーキテクチャがアプリケーションのサービスレベルアグリーメント（SLA）を満たせるようにするためにも役立ちます。ハードウェア障害、リージョン障害、またはその他の中断によってデータベースにダウンタイムが発生すると、重大な収益損失、顧客関係の悪化、および潜在的なコンプライアンス違反に直面する可能性があり、堅牢な可用性ソリューションがビジネスにとって必要不可欠です。これらの課題に対処するために、Oracle Database@AWS の多層的なアプローチを使用して、包括的な保護戦略を実装できます。高可用性のためのクロス AZ 構成と災害復旧のためのクロスリージョン設定の両方で Oracle Data Guard を使用することにより、ローカルハードウェア障害から AWS リージョン全体の障害まで及ぶ多層防御保護を構築できます。 この投稿は、Oracle の Maximum Availability Architecture（MAA） のベストプラクティスと AWS の Well-Architected フレームワーク に従った Data Guard 構成の実装と維持に役立ちます。適切なネットワークアーキテクチャの選択方法と、クロス AZ とクロスリージョンの両方に Data Guard アソシエーションを構成する方法を示します。これにより、ロール移行中にアプリケーションがシームレスな接続を維持できるようにします。 Data Guard を使用した Oracle Database@AWS での HA とDR Oracle Database@AWS で提供される Exadata Database Service on Dedicated Infrastructure（ExaDB-D）と Autonomous Database Dedicated（ADB-D）サービスは、Data Guard 構成を作成および維持するためのマネージド体験を提供します。プライマリとスタンバイの仮想マシン（VM）クラスター間で必要な接続が確立された後、OCI コンソールまたはコマンドラインインターフェース（CLI）を使用してプライマリサイトとスタンバイサイト間の Data Guard 構成を構築できます。次の図は、同一リージョン内の2つの AZ 間およびリージョン間で Data Guard アソシエーションを使用した ExaDB-D の HA/DR 構成のリファレンスアーキテクチャを示しています。 次の表は、ExaDB-D と ADB-D サービスで利用可能な Data Guard アソシエーション機能の比較を示しています。 機能 ExaDB-D ADB-D Data Guardの作成と管理のマネージド体験 はい はい クロス AZ 構成の自動フェイルオーバー はい：顧客管理の Data Guard Observer（FSFO） はい クロスリージョン構成の自動フェイルオーバー はい：顧客管理の Data Guard Observer（FSFO） はい サポートされるスタンバイデータベース数（ローカルとリモートを含む） 6 2 推奨構成 クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) クロス AZ では最大可用性(Maximum availability)、クロスリージョンでは最大パフォーマンス(Maximum performance) Data Guard アソシエーションのネットワーク接続を確立するには、2つのオプションから選択できます： AWS Transit Gateway を使用して、2つの AZ または2つのリージョンにある2つのODBネットワークを接続する。 クロス AZ 構成ではローカルピアリングゲートウェイを使用し、クロスリージョンでの Data Guard 構成の場合はリモート VCN ピアリングと 動的ルーティングゲートウェイ （DRG）を使用して、OCI Virtual Cloud Network（VCN） レベルでピアリングを確立する。 次のセクションでは、Oracle Database@AWS の Data Guard アソシエーションにおける様々な接続オプションのネットワーク詳細、利点、およびコストへの影響について詳しく説明します。 同一リージョン内のクロス AZ デプロイメント AWS 上のレジリエンシーのあるデータベースアーキテクチャの基盤は、プライマリ AZ の障害から重要なデータベースを保護することから始まります。ExaDB-D と ADB-D の両方のサービスで利用可能なクロス AZ Data Guard 構成のネットワークオプションを見ていきましょう。 Data Guard 接続に2つの ODB ネットワークを接続するための Transit Gateway を使用する Transit Gateway を使用して、リージョン内の2つの AZ にある2つの ODB ネットワーク 間のトラフィックを AWS ネットワーク内でルーティングできます。次の図は、2つの AZ （ az1 と az2 ）でホストされている2つの Exadata VM クラスターと ODB ネットワーク間の構成の詳細を示しており、各 ODB ネットワークとピアリングされたトランジット仮想プライベートクラウド（VPC）を経由してルーティングされる接続を持つ Transit Gateway を使用しています。 この例では、b.b.b.b/b は az1 の ODB ネットワークのクライアントサブネット CIDR 範囲、a.a.a.a/a は az1 の ODB ネットワークとピアリングされた Transit VPCの CIDR 範囲、y.y.y.y/y は az2 の ODB ネットワークのクライアントサブネット CIDR 範囲、x.x.x.x/x は az2 の ODB ネットワークと ODB ピアリングされた Transit VPC の CIDR 範囲です。 ネットワーク CIDR プライマリ Transit VPC a.a.a.a/a プライマリ ODB ネットワーククライアントサブネット b.b.b.b/b スタンバイ Transit VPC x.x.x.x/x スタンバイ ODB ネットワーククライアントサブネット y.y.y.y/y Oracle Database@AWS のネットワークアーキテクチャと ODB ピアリングの概念について学ぶには、 ODB ピアリング を参照してください。 次の図は、リージョン内の2つの AZ 間で Transit Gateway を使用して Data Guard トラフィックの接続を設定する方法を示しています。 このアーキテクチャを実装するには、次の手順に従う必要があります： ODB ピアリング方法 を使用して、Transit VPC1（CIDR a.a.a.a/a）を ODBNetwork-az1 （クライアント CIDR b.b.b.b/b）とピアリングし、Transit VPC2（CIDR x.x.x.x/x）を ODBNetwork-az2 （クライアント CIDR y.y.y.y/y）とピアリングします。 Transit Gateway をプロビジョニングするか既存の Transit Gateway を使用し、ODB ネットワークがデプロイされている AZ にマッピングされたサブネットに対して、Transit VPC1 と Transit VPC2の両方にアタッチします。Transit VPCへの Transit Gateway アタッチメントは、ODB ネットワークがプロビジョニングされている AZ にマッピングされたサブネットのみをカバーする必要があります。 Transit VPC1 のルートテーブル（Transit Gateway アタッチメント用のサブネットで使用される）を変更して、Transit VPC2 CIDR（x.x.x.x/x）と ODBNetwork-az2 CIDR（y.y.y.y/y）を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 Transit VPC2 のルートテーブル（Transit Gatewayアタッチメント用のサブネットで使用される）を変更して、Transit VPC1 CIDR（a.a.a.a/a）と ODBNetwork-az1 CIDR（b.b.b.b/b）を対象とするトラフィックを Transit Gateway アタッチメント経由でルーティングします。 これらのサブネットにアタッチされたルートテーブルからのルートは、Transit Gateway のルートテーブルに自動的に入力されます。 Transit Gateway に直接接続されていない両方の AZ の ODB ネットワーククライアント CIDR に対して、Transit Gateway 上に2つの静的ルートを追加します。CIDR b.b.b.b/b とy.y.y.y/y の静的ルートは、Transit VPC の対応する Transit Gateway アタッチメントを指す必要があります。 ODB ピアリング接続を変更して、他の ODB ネットワークとその Transit VPC のピアリング CIDR 範囲を追加します： ODBNetwork-az1 の ODB ピアリング接続を変更して、x.x.x.x/x と y.y.y.y/y をそのピアリング CIDR リストに追加します。 ODBNetwork-az2 の ODB ピアリング接続を変更して、a.a.a.a/a と b.b.b.b/b をそのピアリング CIDR リストに追加します。 ODB ピアリング接続のピアリング CIDR リストを変更することで、対応する OCI VCN のネットワークセキュリティグループが自動的に更新されて必要なトラフィックが許可されます。データベースリスナーポート、SSH（22）、および ICMP での接続を確認するために、ネットワークセキュリティグループルールを確認できます。 接続をテストして、ソリューションが適切に実装されていることを確認します。 グローバル接続を管理するために AWS Cloud WAN を使用している場合は、 Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じものを使用できます。 Data Guard 接続に OCI VCN でローカルピアリングゲートウェイを使用する VM クラスター間の接続を確立する2番目のオプションは、ローカルピアリングゲートウェイを使用して ODB ネットワークに関連付けられた2つの OCI VCN 間でトラフィックをルーティングすることです。 次の図では、 ODBNetwork-az1 はクライアント CIDR b.b.b.b/b を持つ AZ1 の ODB ネットワークの名前であり、 ODBNetwork-az2 はクライアント CIDR y.y.y.y/y を持つ AZ2 の ODB ネットワークの名前です。 OCI VCN をピアリングして接続を実装するには、次の手順に従う必要があります： OCI コンソールから ODB ネットワークに関連付けられた OCI VCN を特定し、クライアントネットワークの CIDR 範囲を記録します。 各 VCN に1つのローカルピアリングゲートウェイを追加します。 2つのローカルピアリングゲートウェイをピアリングします。 ODBNetwork-az1 に対応する OCI VCN のデフォルトルートテーブルを変更して、 ODBNetwork-az2 の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。 ODBNetwork-az2 に対応する OCI VCN のデフォルトルートテーブルを変更して、 ODBNetwork-az1 の CIDR のトラフィックをローカルピアリングゲートウェイ経由でルーティングします。 各 OCI VCN のネットワークセキュリティグループ（名前が調整可能なもの）を変更して、他の ODB ネットワーククライアント CIDR からのトラフィックを許可します。 接続をテストして、ソリューションが適切に実装されていることを確認します。 この構成の詳細については、 Oracle Database@AWS でのクロスゾーン Data Guard を使用したディザスタ・リカバリの実装について を参照してください。 クロス AZ Data Guard アソシエーションの接続オプションの比較 次の表は、Transit Gateway と OCI VCN ピアリングを使用して AZ 間で Data Guard トラフィックをルーティングする2つのオプションを比較しています。 機能 Transit Gateway OCI VCN ピアリング トラフィック分離 AWS ネットワーク OCI ネットワーク レイテンシー 1桁台前半のミリ秒 1桁台前半のミリ秒 コスト Transit Gateway と クロス AZ 料金 データ転送料金なし データ常駐とコンプライアンス要件 トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない トラブルシューティングの責任 AWS OCI ExaDB-D は Data Guard アソシエーションを追加する際、自動フェイルオーバー用の Data Guard Observer を自動的に構成しません。ただし、Observer 構成を手動で構築することができます。アプリケーションとデータベース間の接続が影響を受けた際にフェイルオーバーをトリガーするために、アプリケーションスタックが主に配置されている AWS ネットワーク上に Data Guard Observer インスタンスをホストすることが推奨されます。次の図は、Fast-Start Failover（FSFO）用に3番目の AZ に展開された Observer 構成を持つ、2つの AZ にわたる Data Guard アソシエーションのリファレンスアーキテクチャを示しています。ADB-D の場合、Observer プロセスを手動で構成することなく、クロス AZ 構成の自動フェイルオーバーを有効にできます。 Data Guardアソシエーションを使用したクロスリージョンディザスタリカバリー AZ 間で HA 構成を確立した後、次のステップは DR 保護を実装することです。DR 要件がクロス AZ 構成で提供できる範囲を超える場合は、リージョン間で Data Guard を実装します。クロスリージョン Data Guard 構成で利用可能な接続オプションを検討し、その効果を比較してみましょう。 リージョン間での2つの ODB ネットワークを接続するために Transit Gateway を使用する 次の図に示すように、Transit Gateway 構成を使用して、AWS ネットワーク内の2つのリージョンにある2つの ODB ネットワーク間でトラフィックをルーティングできます。 この構成の高レベルの手順には以下が含まれます： 各リージョンに1つずつ、2つの Transit Gatway をプロビジョニングします。既存の Transit Gateway を使用することもできます。 各リージョンの ODB ピアリングVPCに、ODB ネットワークが存在する AZ にマッピングされたサブネットへ Trasnit Gateway をアタッチします。 AWS Transit Gateway の Transit Gateway ピアリングアタッチメント で説明されているように、ピアリングアタッチメントを作成し、ピアリングリクエストを受け入れて、Transit Gateway 間の接続を確立します。 クロス AZ トラフィック用の Transit Gatway 構成について前述した手順に従って、ルーティングルールを更新します。 ODB ネットワーク構成を変更して、リモート ODB ネットワークからのトラフィックを許可するように ODB ネットワークのピアリング CIDR リストを更新します。 接続をテストして、ソリューションが適切に実装されていることを確認します。 グローバル接続を管理するために Cloud WAN を使用している場合は、 Connecting AWS Cloud WAN to Oracle Database@AWS (ODB@AWS) で説明されているように、Data Guard トラフィックに同じ手順を使用できます。 OCI VCN とのリモート VCN ピアリングを使用する クロスリージョンの Data Guard 構成のための接続を確立するためにバックエンドの OCI VCN をピアリングする2番目のオプションでは、各側に追加の HUB VCN を構成する必要があります。これは、OCI VCN は1つの DRG にのみアタッチできるためであり、ODB ネットワークにマッピングされた VCN はすでに AWS-OCI ネットワーク統合のために DRG にアタッチされているためです。そのため、HUB VCN を導入し、ODB ネットワークの OCI VCN と HUB VCN 間でローカルピアリングゲートウェイ接続を確立します。その後、次の図に示すようにクロスリージョン接続のために DRG にアタッチできます。 詳細な構成手順については、 Oracle Database@AWS 上のリージョン間 Active Data Guard によるディザスタ・リカバリの実装 を参照してください。 クロスリージョン Data Guard アソシエーションの接続オプションの比較 次の表は、Transit Gateway と OCI VCN ピアリングを使用してリージョン間でData Guardトラフィックを行う接続オプションを比較しています。 機能 Transit Gateway OCI VCN ピアリング トラフィック分離 AWS ネットワーク OCI ネットワーク レイテンシー ミリ秒 ミリ秒 コスト Transit Gateway 料金 と クロスリージョンデータ転送料金 クロスリージョンデータ転送料金 データ常駐とコンプライアンス要件 トラフィックが AWS ネットワーク内に留まる必要がある場合は要件を満たす データは物理的に AWS に保存されているが Data Guard トラフィックが OCI ネットワーク経由でルーティングされるため、データ常駐要件を満たさない トラブルシューティングの責任 AWS OCI ExaDB-D と ADB-D の Data Guard アソシエーションの構成 ExaDB-D と ADB-D は両方とも、バックアップ、リストア、および Data Guard 構成の手順を手動で実行することなく、コンソールまたは API と CLI を使用して Data Guard アソシエーションを設定するためのマネージド体験を提供します。ExaDB-D の場合は、次の手順を実行します： OCI コンソールを使用して OCI テナンシーにログインします。 Oracle AI Database セクションで Oracle Exadata Database Service on Dedicated Infrastructure を選択します。 プライマリデータベース用の VMC を選択します。 プライマリデータベースを選択します。 Data Guard associations を選択します。 スタンバイインスタンスに適切なターゲット AD、インフラストラクチャ、および VMC を選択して、スタンバイ追加オプションを使用して構成します。 構築完了後にスイッチオーバーをテストします。 ADB-D の場合は、次の手順を実行します： OCI コンソールを使用して OCI テナンシーにログインします。 Oracle AI Database セクションで Autonomous Database on Dedicated Infrastructure を選択します。 Autonomous Container Database（ACD）を選択します。 Data guard associations を選択します。 スタンバイに適切なターゲット AD、インフラストラクチャ、および AVMC を選択して、スタンバイ追加オプションを使用して構成します。 構築完了後にスイッチオーバーをテストします。 クロス AZ Data Guard フェイルオーバーとスイッチオーバーのアプリケーション接続 データベースへのアプリケーション接続は、ADB-D と ExaDB-D の両方で Data Guard のスイッチオーバーとフェイルオーバーのシナリオを計画する際に慎重な検討が必要です。このセクションでは、適切な TNS 構成を使用することで、アプリケーションが再構成なしにロール移行シナリオ全体でデータベースへの接続を透過的に確立できるようにする、アプリケーションスタックからデータベースへの接続のための Well-Architected で推奨されるモデルについて説明します。 ほとんどの場合、顧客は高可用性のために異なる AZ にマッピングされたサブネットにまたがる VPC 内にアプリケーションスタックをデプロイします。VPC はプライマリ AZ とスタンバイ AZ の ODB ネットワークと同時にピアリングできるため、その VPC で実行されているアプリケーションは、次の図に示すように Data Guard のスイッチオーバーとフェイルオーバーのシナリオ全体でデータベースへの透過的な接続を促進できます。 Transit Gateway を介して ODB ネットワーク内のデータベースにアプリケーションが接続されている場合、プライマリおよびスタンバイ AZ の ODB ネットワークとピアリングされた Transit VPC を Transit Gatway にアタッチすることで、スイッチオーバーとフェイルオーバーのシナリオ全体で透過的な接続を確立できます。次の図に示すように、アプリケーションは Transit Gateway を介して ODB ネットワークに接続し、ODB ピアリング VPC は単にトランジットパスとして機能します。 このアーキテクチャでは、Transit VPC はアプリケーションコンポーネントをホストせず、アプリケーションは Transit Gateway を使用してデータベース層に接続します。 まとめ この投稿では、Oracle Database@AWS で実行されている重要なデータベースの HA と DR 要件を満たすために Data Guard を使用する方法を示しました。また、Data Guard トラフィックをルーティングするための接続オプションについて説明し、データベースへのアプリケーション接続のベストプラクティスを共有しました。Oracle RAC (Real Application Clusters) が提供するサーバーラックレベルのレジリエンシー、Data Guard マルチ AZ レプリケーション、クロスリージョンディザスタリカバリなど、複数の保護層を慎重に実装することで、Oracle Database@AWS にデプロイされたデータベースに対して望ましい保護レベルと可用性を実現できます。現在の可用性要件を評価し、適切な Data Guard 構成を選択し、ビジネスニーズに最適なネットワークアーキテクチャを実装することで、包括的なデータベースレジリエンシーへの取り組みを今日から始めましょう。この投稿の詳細な構成手順とアーキテクチャパターンは、アプリケーションのビジネス継続性を提供する堅牢な Oracle Database@AWS 環境の構築と維持に役立ちます。 Oracle Database@AWS の機能と構成について詳しく学ぶには、 Oracle Database@AWS ユーザーガイド を参照してください。 著者について Jobin Joseph Jobin は、トロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンに焦点を当て、顧客のデータベースワークロードの AWS への移行とモダナイズを支援しています。25年以上の Oracle Database 経験を持つ Oracle 認定マスターです。 Julien Silverston Julien は、25年の経験を持つ Oracle Cloud Infrastructure マルチクラウドチームのプリンシパルソリューションアーキテクトです。Julien は、マルチクラウド、ハイブリッドクラウド、およびクラウドベースのソリューションに精通しています。Oracle Cloud Infrastructure 認定ソリューションアーキテクトです。 Jeremy Shearer Jeremy は、ヒューストンを拠点とし、Oracle Alliance に専念する AWS のプリンシパルパートナーソリューションアーキテクトです。約30年の Oracle 経験を持ち、特に JD Edwards などの Oracle エンタープライズ ERP システムのインストール、構成、管理、および移行を専門としています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

イベント概要 自動車・製造業を中心にCAEワークロードを実行されているお客様向けに、本年2月（東京リージョンは3月）に一般提供開始した Hpc8aインスタンス をはじめとしたAWSの最新ソリューション、並びにその基盤となるアーキテクチャを提供するAMD様、業界内で強力なリーダーシップを有するSIパートナー様や主要なアプリケーションベンダーの皆様から最新情報をお届けする集中イベントを、4月20日週に東京・大阪・名古屋 3か所のロードショーの形で実施いたします。AWSでグローバルにCAEワークロード責任者を務める Sandeep Sovani も来場します。是非お近くの会場にてご参加ください。 開催日程 東京: 　　4月20日(月) @AWS目黒オフィス　13:15 ～ 17:15 （受付: 12:45～） 大阪: 　　4月22日(水) @AWS大阪オフィス　13:15 ～ 17:15 （受付: 12:45～） 名古屋: 　4月23日(木) @ウインクあいち　13:15 ～ 17:15 （受付: 12:45～） （※セミナー終了後、ネットワーキングセッションを実施いたします。こちらも奮ってご参加ください。） イベントプログラム 時間 内容（※一部リモート・録画投影にて実施予定） 13:15 – 13:30 オープニング 13:30 – 14:00 AWSセッション 14:00 – 14:30 AMD様セッション 14:30 – 15:00 CAE SIer様セッション 15:00 – 17:00 CAEアプリケーションベンダー様セッション（調整中） 17:00 – 17:15 Q&A / クロージング 17:15 – 19:00 ネットワーキングセッション（※ご参加可能な方） 軽食・飲み物をご用意しております ※当日迄にセッション時間内訳等変更となる可能性がございます。 ※一部のセッションは英語での提供となりますが、通訳を手配する予定です。 セミナー参加情報 開催形式 : 　会場参加型セミナー（オンライン配信はありません） 東京会場(4/20)            〒 141-0021東京都品川区上大崎3-1-1 目黒セントラルスクエア21階　AWS目黒オフィス内セミナールーム 大阪会場(4/22)            〒 530-0005 大阪市北区中之島 3-3-3 中之島三井ビルディング26F　AWS大阪オフィス内セミナールーム 名古屋会場（4/23)      〒 450-0002 愛知県名古屋市中村区名駅4丁目4-38 ウインクあいち 1307会議室 参加費用 無料 参加対象者 CAEワークロードを持つ自動車・製造業等のお客様、エンジニア、事業部門、意思決定者の方まで多くの方にご参加いただけます。 定員 各回30名 ※定員に達した場合は申込を締め切らせていただきます。 お問い合わせ アマゾンウェブサービスジャパン セミナー事務局 Email : aws-jp-hpc@amazon.com お申込サイト https://bit.ly/4uzniiM ※開催日が近くなりましたらお申込みいただいた方のご連絡先に 入館証他詳細をご連絡させていただきます。