

 このホワイトペーパーは過去の参考用です。一部のコンテンツは古く、一部のリンクは使用できない場合があります。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# セキュリティとパフォーマンスのためのアーキテクチャ
<a name="architecting-for-security-and-performance"></a>

 Amazon RDS または Amazon EC2 で Oracle Database を実行するかどうかにかかわらず、インフラストラクチャのすべてのコンポーネントを最適化することで、セキュリティ、パフォーマンス、信頼性が向上します。以下のセクション AWS では、 での Oracle Database 実装でネットワーク設定、インスタンスタイプ、データベースストレージを最適化するためのベストプラクティスについて説明します。

**Topics**
+ [ネットワーク構成](network-configuration.md)
+ [Amazon EC2 インスタンスタイプ](amazon-ec2-instance-type.md)
+ [データベースストレージ](database-storage.md)

# ネットワーク構成
<a name="network-configuration"></a>

 Amazon Virtual Private Cloud (Amazon VPC) を使用すると、 アカウント専用の の論理的に分離 AWS クラウド されたセクションをプロビジョニングできます。独自の IP アドレス範囲の選択、サブネットの作成、セキュリティ設定、ルートテーブルとネットワークゲートウェイの設定など、仮想ネットワーク環境を完全に制御できます。

 *サブネット*は、Amazon VPC 内の IP アドレスの範囲です。選択したサブネットで AWS リソースを起動できます。インターネットに接続する必要があるリソースにはパブリックサブネットを、インターネットに接続しないリソースにはプライベートサブネットを使用してください。

 各サブネットの AWS リソースを保護するために、セキュリティグループやネットワークアクセスコントロールリスト (ACLs) など、複数のセキュリティレイヤーを使用できます。

 次の表に、セキュリティグループとネットワーク ACLs の基本的な違いを示します。


|  **セキュリティグループ**  |  **ネットワーク ACL**  | 
| --- | --- | 
|  インスタンスレベルで動作します (第 1 保護レイヤー)  |  サブネットレベルで動作します (第 2 保護レイヤー)  | 
|  許可ルールのみをサポート  |  許可ルールと拒否ルールをサポート  | 
|  ステートフル: ルールに関係なく、リターントラフィックは自動的に許可されます  |  ステートレス: 返されたトラフィックがルールによって明示的に許可されます  | 
|  トラフィックを許可するかどうかを決める前に、すべてのルールを評価します  |  トラフィックを許可するかどうかを決めるときに、番号順にルールを処理します  | 
|  インスタンスの起動時に誰かがセキュリティグループを指定した場合、または後でセキュリティグループをインスタンスに関連付けた場合にのみ、インスタンスに適用されます。 |  関連付けられたサブネット内のすべてのインスタンスに自動的に適用されます (バックアップの保護レイヤーなので、セキュリティグループを指定する人物に依存する必要はありません)  | 

 

 Amazon VPC は、分離、セキュリティの強化、Amazon EC2 インスタンスをサブネットに分離する機能を提供し、プライベート IP アドレスの使用を許可します。これらはすべて、データベースの実装において重要です。

Oracle Database インスタンスをプライベートサブネットにデプロイし、Amazon VPC 内のアプリケーションサーバー、または Amazon VPC 内の踏み台ホストのみがデータベースインスタンスにアクセスできるようにします。

指定されたポートを介して特定の IP アドレスにのみアクセスを許可する適切なセキュリティグループを作成します。これらの推奨事項は、Amazon RDS と Amazon EC2 のどちらを使用しているかにかかわらず、Oracle Database に適用されます。

![\[Amazon VPC のプライベートサブネット内の Oracle Database\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/oracle-database-aws-best-practices/images/oracle-db-private-subnet.png)


 

 Amazon VPC のプライベートサブネット内の Oracle Database 

# Amazon EC2 インスタンスタイプ
<a name="amazon-ec2-instance-type"></a>

 AWS には多数の Amazon EC2 インスタンスタイプが用意されているため、ワークロードに最適なインスタンスタイプを選択できます。ただし、使用可能なすべてのインスタンスタイプが Oracle Database の実行に最適なわけではありません。

 Oracle Database に Amazon RDS を使用する場合、 AWS はベストプラクティスに基づいて一部のインスタンスタイプを除外し、T クラス、M クラス、R クラスインスタンスのさまざまなオプションを提供します。AWS では、エンタープライズデータベースワークロードに db.m ベースまたは r ベースの Amazon RDS インスタンスを選択することをお勧めします。R5 インスタンスは、高性能データベースなどのメモリを大量に消費するアプリケーションに適しています。

RDS インスタンスに関する最新情報については、[Amazon RDS for Oracle Database の料金](https://aws.amazon.com/rds/oracle/pricing/)」を参照してください。Amazon RDS インスタンスタイプの選択は、データベースワークロードと使用可能な Oracle Database ライセンスに基づいて行う必要があります。

 Amazon EC2 でセルフマネージドデータベースを実行している場合は、Amazon EC2 インスタンスタイプでさらに多くの選択肢があります。これは多くの場合、ユーザーが Amazon EC2 で Oracle Database を実行することを選択する理由の 1 つです。

Oracle Database は CPU 使用率に関してリソースを大量に消費するため、非常に小さなインスタンスタイプは適していません。メモリフットプリントが大きいインスタンスは、キャッシュを改善し、システムグローバルエリア (SGA) を大きくすることで、データベースのパフォーマンスを向上させるのに役立ちます。 AWS では、メモリと CPU のバランスが良いインスタンスを選択することをお勧めします。

使用する予定の Oracle Database ライセンスと実装する予定のアーキテクチャに一致するインスタンスタイプを選択します。ビジネスニーズに最適なアーキテクチャについては、ホワイトペーパー[「Advanced Architectures for Oracle Database on Amazon EC2」を参照してください。](https://d1.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf)

 Oracle Database は読み取り/書き込みオペレーションにディスクストレージを大量に使用するため、Amazon Elastic Block Store (Amazon EBS) に最適化されたインスタンスのみを使用することを AWS 強くお勧めします。Amazon EBS 最適化インスタンスは、Amazon EC2 と Amazon EBS 間の専用スループットを提供します。ストレージサブシステムへの帯域幅とスループットは、データベースのパフォーマンスを向上させるために不可欠です。ネットワークパフォーマンスが高いインスタンスを選択すると、データベースのパフォーマンスが向上します。

 次のインスタンスファミリーは、Amazon EC2 で Oracle Database を実行するのに最適です。


|  **インスタンスファミリー**  |  **特徴**  | 
| --- | --- | 
|  M ファミリー  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html)  | 
|  X ファミリー  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html)    | 
|  R ファミリー  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html)    | 
|  自分の家族  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html)    | 
|  Z1d ファミリー  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html)  | 

 

# データベースストレージ
<a name="database-storage"></a>

 ほとんどのユーザーは、通常、データベースストレージに Amazon EBS を使用します。一部の非常に高性能なアーキテクチャでは、インスタンスストレージ SSDsを使用できますが、信頼性の高い永続性を実現するために、Amazon EBS ストレージで拡張する必要があります。

 高い IOPS と一貫したデータベースパフォーマンスを実現するために、AWS では汎用 (GP2) ボリュームまたはプロビジョンド IOPS (PIOPS) ボリュームを使用することを強くお勧めします。GP2 ボリュームと PIOPS ボリュームは、Amazon EC2 と Amazon RDS の両方で使用できます。GP2 ボリュームタイプと PIOPS ボリュームタイプの両方のボリュームあたりの IOPS の最新の制限については、[「Amazon RDS DB インスタンスストレージ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。GP2 ボリュームは、ほとんどのデータベースのニーズに対して価格とパフォーマンスの優れたバランスを提供します。データベースで GP2 が提供できるものよりも高い IOPS が必要な場合は、PIOPS ボリュームが適しています。

 PIOPS ボリュームの場合、ボリュームの作成時に IOPS レートを指定します。Amazon EBS は、特定の 1 年間に 99.9% の時間でプロビジョンド IOPS パフォーマンスの 10% 以内に配信します。リクエストされたボリュームサイズに対してプロビジョニングされる IOPS の比率は、最大 30 です。たとえば、3,000 IOPS を取得するには、ボリュームサイズが 100 GB 以上である必要があります。

 PIOPS ボリュームと同様に、GP2 ボリュームも SSD ベースですが、GP2 ボリュームから得られる IOPS は、ベースライン IOPS からボリュームあたりバースト可能な最大 3,000 IOPS まで異なる場合があります。これは、ほとんどのデータベースワークロードで非常にうまく機能します。これは、データベースに必要な IOPS パフォーマンスが、ロードサイズと実行されるクエリの数に基づいて一定期間に何度も異なるためです。

 汎用 (SSD) ボリュームのパフォーマンスはボリュームサイズによって管理され、ボリュームの基本パフォーマンスレベルと I/O クレジットの蓄積速度が決まります。ボリュームサイズが大きいほどベースパフォーマンスレベルが高くなり、I/O クレジットの取得速度も速くなります。

 I/O クレジットは、基本パフォーマンス以上が必要な場合に、汎用 (SSD) ボリュームが大量の I/O をバーストするために使用できる帯域幅を表します。I/O に対するボリュームのクレジットが多いほど、基本パフォーマンスレベルを超えてバーストできる時間が増え、パフォーマンスの向上が必要な場合にパフォーマンスが向上します。

 スループット最適化 HDD ボリューム (st1) は、IOPS が少なくスループットが高い負荷の高いワークロード向けに設計された低コストの HDD ボリュームを提供します。データウェアハウスとデータ分析の目的で使用される Oracle データベースは、st1 ボリュームを活用できます。

高スループットを必要とする Oracle 外部テーブルや外部 BLOB ストレージなどのログ処理またはデータステージング領域は、st1 ボリュームを活用できます。スループット最適化 (st1) ボリュームは、ボリュームあたり最大 500 IOPS を処理できます。

 Cold HDD ボリューム (sc1) は、レガシーシステムの処理に適しています。レガシーシステムは、ときどき参照やアーカイブの目的で保持されます。これらのシステムへのアクセス頻度は低く、ボリュームに対して 1 日に数回のスキャンが実行されます。

 適切な方法は、データベースに一貫して必要な IOPS の量を推定し、その数の IOPS を取得するのに十分な GP2 ストレージを割り当てることです。定期的なスパイクに必要な追加の IOPS は、利用可能なクレジットに基づいてバーストパフォーマンスでカバーする必要があります。

Oracle Database の IOPS ニーズを判断するために使用できる推定方法については、[「AWS での Oracle Database の IOPS ニーズの決定](https://docs.aws.amazon.com/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html)」ホワイトペーパーを参照してください。

 ボリュームのバースト期間は、ボリュームのサイズ、必要なバースト IOPS、およびバーストが開始された時点のクレジットバランスによって異なります。ボリュームのパフォーマンスが頻繁にベースレベルに制限される場合 (I/O クレジットバランスが空であるため）、10,000 IOPS を超える持続的な IOPS パフォーマンスを必要とするワークロードには、より大きな汎用 (SSD) ボリューム (基本パフォーマンスレベルが高い) を使用するか、プロビジョンド IOPS (SSD) ボリュームに切り替えることを検討する必要があります。GP2 ボリュームの詳細については、[「Amazon EBS ボリュームタイプ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)」を参照してください。

 Amazon RDS の場合、汎用 (SSD) ストレージは、プロビジョニングされた GB あたり 3 IOPS の一貫したベースラインを提供し、最大 3,000 IOPS をバーストする機能を提供します。Amazon RDS にマグネティックストレージを既に使用している場合は、汎用 (SSD) ストレージに変換できますが、その場合は可用性にわずかな影響が生じます。プロビジョンド IOPS を使用すると、データベースインスタンスあたりの現在の最大ストレージ制限と最大 IOPS までプロビジョニングできます。

実際の実現 IOPS は、データベースワークロード、インスタンスタイプ、データベースエンジンに基づいてプロビジョニングした量とは異なる場合があります。詳細については、[*「Amazon RDS ユーザーガイド*」の「実現 IOPS レートに影響する要因](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)」を参照してください。

 Amazon EC2 上の Oracle Database の場合、複数のボリュームをストライプして IOPS を増やし、容量を増やします。複数の Amazon EBS ボリュームを異なるデータファイルに個別に使用できますが、それらをストライピングすることで、バランスとスケーラビリティが向上します。

Oracle Automatic Storage Management (ASM) はストライピングに使用できます。データファイル、ログファイル、バイナリを別々の Amazon EBS ボリュームに保存し、ログファイルボリュームのスナップショットを定期的に作成します。ローカル SSD ストレージでインスタンスタイプを選択すると、Smart Flash Cache (オペレーティングシステムが Oracle Linux の場合) を使用し、一時ファイルとテーブルスペースにローカルストレージを使用することで、データベースのパフォーマンスを向上させることができます。

 Oracle Database on VMware Cloud on AWS の場合、vSAN はベアメタルホスト全体で必要な仮想化ストレージストライピングを提供します。vSAN 仮想化ストレージ機能は、Oracle RAC で使用して、高性能の共有ストレージとして使用できます。

Oracle RAC 用に作成された VMDK (仮想マシンディスク) ファイルは、厚みがゼロになるようにプロビジョニングし、マルチライターフラグを有効にする必要があります。VMware は、VMware Cloud on AWS での Oracle データベースの[詳細なパフォーマンス調査](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/vmw-oracle-performance-on-the-vmware-cloud-on-aws.pdf)を発表しました。