Amazon Web Services ブログ

Category: RDS for Oracle

Amazon RDS Under the Hood: Multi-AZ

Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。 Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-AZと呼ばれています)。別々のAvailability Zones を持つことで、両方のデータが同時に障害に見舞われるリスクを軽減させています。データの適切な管理、簡単な再構成、およびコピーへの信頼できるユーザーアクセスは、顧客環境が要求する高可用性要件に対処するための鍵です。 この投稿では、MySQL、MariaDB、PostgreSQL、およびOracleデータベースインスタンスのAmazon RDS Multi-AZ設定について説明します。Amazon RDS for SQL ServerおよびAmazon Auroraは、異なるテクノロジースタックを使用してマルチAZ機能を提供します。 基本デザイン Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。このレイヤーは、アプリケーションの読み取りおよび書き込み要求を処理し、2つの個別のEBSボリュームコピーがある環境に適用されます。1つはローカルアクセス、もう1つはリモートアクセスです。 通常時は、レプリケーションレイヤーがインストールされた、2つのアクティブなAmazon EC2インスタンスがあります。 各インスタンスは、データの完全なコピーが行われているEBSボリュームを管理しています。この構成により、2つのインスタンスとそのボリュームがMulti-AZデータベースインスタンスとして稼働しています。 レプリケーションレイヤーは、TCP接続を介して互いに直接通信を行っています。 各インスタンスには特定のロールが割り当てられます。1つはプライマリであり、ユーザーがデータにアクセスするための外部エンドポイントを提供します。もう1つはスタンバイであり、プライマリから受信するすべてのデータを同期的に書き込むセカンダリインスタンスとして機能します。データベースの書き込みは、正常応答が呼び出し側アプリケーションに送り返される前に、データが両方のボリュームに適切に書き込まれます。ただし、読み取り操作は常にプライマリEBSボリュームを介して実行されます。データベースサーバープロセスは、スタンバイインスタンスで実行されていないため外部エンドポイントは公開されません。そのため、ユーザーはstandbyデータベースインスタンス上のデータのコピーは使用できません。 可用性を向上させるためにMulti-AZは、インスタンスの1つがプライマリロールにあることを一貫して保証し、データのコピーへのアクセスを提供します。もし可用性の問題が発生した場合、スタンバイインスタンスを自動的にプライマリロールに昇格させ、リダイレクトによって可用性を復元させます。 このイベントは、フェイルオーバーと呼ばれます。旧プライマリがまだ稼働している場合、スタンバイロールに降格されます。 新しいプライマリインスタンスへのリダイレクトは、DNSを介して提供されます。クライアントDNSクエリの結果に含まれるレコードのTTLは非常に短くなっています。アドレス情報の長期間のキャッシングを禁止することを目的としています。これにより、クライアントはフェールオーバープロセスで情報をより早く更新し、DNSリダイレクトの変更をより迅速に取得します。 以下の図が正常時のMulti-AZインスタンスの状態を示しています。 Figure 1: Multi-AZ instance データベースアプリケーション(黄色で表示されるDB APP)は、DNS)オレンジ色で表示)使用して、データへのアクセスを提供している現在の外部エンドポイントのアドレス情報を取得します。 このマルチAZインスタンスには2つのRDS DBインスタンスがあります。プライマリインスタンス(左側に緑色で表示)とスタンバイインスタンス)右側に青色で表示)です。この例では、DNSはアプリケーションをプライマリインスタンスEC2#1に向けており、Availability Zone#1で利用可能なEBS#1のプライマリコピーを提供しています。2つのEC2インスタンスの複製レイヤーが接続されています。アプリケーションが発行する書き込み操作は、2番目のインスタンスへの書き込みにもなります(パスは灰色で表示)。 レプリケーションレイヤーは、それ自体の可視性が制限されているため、より詳細な決定を下すことができません。たとえば、クライアントからの接続問題、ローカルまたはregionの停止、または予期せずサイレントな状態になったEC2ピアの状態などを知るすべがありません。このため、2つのインスタンスは、より重要な情報にアクセスし、インスタンスのステータスを定期的に監視する外部システムによって監視および管理されています。必要に応じて、管理システムは、可用性とパフォーマンスの要件が満たされてるためのアクションを実行します。 Multi-AZが提供する可用性と耐久性の改善は、最小限のパフォーマンスコストで実現しています。通常の使用例では、レプリケーションレイヤーが接続され、スタンバイEBSボリュームへの同期書き込み操作が発生します。スタンバイインスタンスとボリュームは、地理的に離れた個別のAvailability Zoneに配置されています。評価では、データベースのコミットへのオーバーヘッドが2ミリ秒から5ミリ秒増加していることが示されています。ただし、実際の使用例に対する実際の影響は、ワークフローに大きく依存します。ほとんどのお客様のMulti-AZインスタンスは、影響があったとしてもパフォーマンスにわずかな影響を示します。 この設計により、AWSはお客様のデータに対して99.95%の可用性を超えるサービスレベルアグリーメント(SLA)を提供しております。詳細については、Amazon RDSサービスレベルアグリーメントをご覧ください。 実装について ボリューム複製機能の設計は単純で簡単だと思われるかもしれません。しかし、実際の実装はかなり複雑です。これは、絶えず変化し、時には大きく変動する環境内で、2つのネットワークで接続された個別のインスタンスおよびボリュームが遭遇する可能性があるすべての事象を考慮する必要があるためです。 通常の進行中のレプリケーションは、すべてが適切に機能し、正常に動作していることを前提としています。EC2インスタンスが利用可能で、通常のインスタンス監視が機能し、EBSボリュームが利用可能で、ネットワークが期待どおりに動作しています。しかし、これらのピースの1つ以上が誤動作しているとどうなるでしょうか? 発生する可能性のある問題とその対処方法を見てみましょう。 […]

Read More

Oracle パフォーマンスメトリクスに基づいた Amazon RDS インスタンスを大規模で適正なサイズにする

オンプレミスのミッションクリティカルなアプリケーションを商用データベースで稼働中のエンタープライズ企業で、コスト効率の高い、マネージド型データベースサービスをお探しのお客様がいらっしゃいます。リレーショナルデータベースのワークロードを移行するプラットフォームの 1 つ、Amazon RDS をおすすめします。RDS はサイズ変更が可能な容量を提供し、時間のかかる重い非個別型管理タスクに対応します。大規模なデータベースの移行では、適切なサイズのターゲット RDS DB インスタンスを多くのデータベースに作成できる、スケーラブルかつ効果的なソリューションが必要です。 この記事では、オンプレミスの Oracle パフォーマンスメトリクスに基づいた DB インスタンス を大規模で適切なサイズにするプロセスについて説明します。Python と SQL スクリプトを使用してオンプレミスデータベースから Oracle パフォーマンスメトリクスを収集する方法、および AWS Glue と Amazon Athena を使った DB インスタンスサイズのデータ分析と推奨事項を得る方法を解説します。このソリューションは、1 つのデータベースから多数のデータベースまでの DB インスタンスのサイズ調整に有効です。 概要 オンプレミスの Oracle ワークロードの検出を目的として、1 時間ごとの I/O、CPU、メモリ使用量の統計について Oracle 自動ワークロードリポジトリ (AWR) をクエリする SQL スクリプトが開発されました。Python スクリプトを検出するデータベースのリストを含む入力ファイルから読み込んで、各データベースをループ処理して SQL スクリプトを実行します。データベースごとに .csv 出力ファイルが生成されます。 目標は、少なくとも 1 か月のパフォーマンスメトリクスを収集し、DB インスタンスのサイズをより正確に推定することです。AWR の保存期間が 1 か月未満に設定されている場合、複数回スクリプトを実行できます。スクリプトはすべて […]

Read More

新機能: Amazon RDS for Oracle Database がvCPUの削減や最適化に対応

すべてのAWSサービスと同様に、Amazon RDS のロードマップは、主にお客様からのフィードバックや製品改善リクエストに基づいています。Oracle RDS for Oracle Database でデータベースワークロードを実行しているエンタープライズの複数のお客様から、私たちはフィードバックを受けました。そのフィードバックとは、物理コアに対するRAMの比率を Amazon RDS for Oracle より大幅に高くすることで、Oracleのワークロードを実行しているエンタープライズのお客様は、ソフトウェアライセンスの価値を最大化しているというものでした。

この記事の目的は、Amazon RDS 上の Oracle Database のための2つの新機能を使用することで、仮想CPU (vCPU) の数を減らし、ライセンスコストを最適化する方法を説明することです。

Read More

Amazon RDSでのIAM multifactor authenticationの利用について

お客様からよく頂くご要望に、インスタンス、スナップショット、クラスタなどのリソースを予期しない、または悪意のあるユーザの削除から保護する方法です。これは、複数のユーザーやチームで共通のAWSアカウントを使用する場合に特に重要です。アカウント内の利用を効率的に行うことも重要ですが、重要なデータを失うことを防ぐためにセキュリティも必要です。 1つの選択肢は、AWS Identity and Access Management(IAM)ポリシーをmultifactor authentication (MFA)で使用することです。MFAでは、AWSリソースに関連した操作を行う際に、承認された認証デバイスまたはSMSテキストメッセージから取得した一意の認証コードを入力する必要があります。この記事はMFAを用いたAmzon RDSのリソースの保護についてご説明します。 たとえば、* prod *のような命名規則でタグ付けされ保護されたリソースの削除を制限するIAMポリシーを作成します。 次に、AWSマネージメントコンソールにアクセスするためにMFA認証が必要な2つ目のIAMポリシーを作成し、このアカウントに対して特定の削除権限を与えます。このようにして、アクセス権のあるすべてのユーザーを監査し、選択されたユーザーのみが必要な権限を持っていることを確認できます。 2つのポリシーを利用します。1つはAWS managed policyの、AmazonRDSFullAccessです。もう1つはcustomer managedポリシーの、RDSDenyDeleteというポリシーを作成します。このポリシーは、リソースを削除する可能性のあるコマンドの実行を制限します。 First step: Start in the IAM console IAMコンソールを開きます。Create policyを選択し、次のJSONコードをポリシーエディタボックスに貼り付けます。 { “Statement”: [ { “Effect”: “Deny”, “Action”: [ “rds:DeleteDBClusterSnapshot”, “rds:DeleteDBSnapshot”, “rds:DeleteDBCluster”, “rds:DeleteDBInstance” ], “Resource”: “*” } ] } Review policyを選択し、ポリシーに名前と説明を付けます。 次に、AmazonRDSFullAccessポリシーとRDSDenyDeleteポリシーを組み合わせたグループを作成します。 IAMコンソールのGroupsから、Create new groupを選択し、グループ名を設定します。この例ではAWSDevelopmentTeamを利用します。 Next stepを選択します。AmazonRDSFullAccessおよびRDSDenyDeleteの横にあるチェックボックスをを選択します。 Next stepを選択し、Create groupを選択します。 […]

Read More