Amazon Web Services ブログ

Category: RDS for MariaDB

SSL/TLS を経由して RDS MySQL, RDS MariaDB, and Amazon Aurora MySQL に sysbench を実行する

sysbench は MySQL 互換のデータベースでベンチマークを実行するために有用なツールです。もし、sysbench を使って Amazon Aurora MySQL のパフォーマンスの評価をしたい場合、Amazon Aurora Performance Assessment Technical Guide が役に立つでしょう。しかし、もし SSL/TLS を経由して sysbench を実行したい場合、このツールや AWS のサービスにあるいくつかの制限について考える必要があります。 この投稿では、RDS MySQL, RDS MariaDB, and Aurora MySQL で sysbench を実行するにあたっての考慮点と、どのように準備するべきかについて、お話いたします。 考慮点 sysbench の最新のパッケージリリースは 1.0.17 になります。もし、yum や RPM のようなパッケージマネージャから sysbench をインストールした場合、このバージョンがインストールされます。このバージョンでは、sysbench は SSL/TLS を使用するにあたって、以下のような制限を持っています: –mysql-ssl オプションは ON または OFF のみが指定可能で SSL_MODE は REQUIRED 固定 クライアント秘密鍵、クライアント公開鍵、CA […]

Read More

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

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

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

Amazon RDS for MySQLとMariaDBのログをAmazon CloudWatchで監視出来るようになりました

Amazon RDSは、トラブルシューティングなどの目的にお使い頂けるように、DBインスタンスで生成されたログを表示およびダウンロードする機能を提供してきました。Amazon Relational Database Service(Amazon RDS) for MySQLとAmazon RDS for MariaDBでは、DBインスタンスのログイベントをAmazon CloudWatch Logsに直接保存出来るようになりました。これにより、AWSサービスを使用して、よりシームレスにDBインスタンスログを扱うことができます。 DBインスタンスログのニアリアルタイム分析 Amazon CloudWatch Logsを使用すると、アプリケーションの様々なコンポーネントからのログを集中的かつ永続的に保存できます。また、特定のフレーズ、値、パターン(メトリック)について、ニアリアルタイムでログを監視することもできます。さらに、設定した状態が発生したときに警告するアラームを設定することもできます。Amazon CloudWatchは他の様々なAWSサービスと統合することが可能です。これにより、以下のような幅広いユースケースでログを利用する価値を向上できます: 通常デジではありえない大量のスロークエリや接続の失敗など、異常な状態を検知するためのアラーム設定 他のアプリケーションログと関連させる セキュリティおよびコンプライアンスの目的でログを保持する ログデータの傾向を分析する 以下の図がアーキテクチャの概要です: ログエクスポートの概念 新しいログエクスポート機能は、MySQLおよびMariaDBの次のログタイプをサポートしています: Error log – 起動および停止にデータベースエンジンによって生成された診断メッセージが含まれています General query log – クライアントから受け取ったすべてのSQLステートメントのレコードと、クライアントの接続および切断時間を含みます Slow query log – 設定された時間よりも実行に時間かかったクエリや、定義された行数を超える行を走査したSQL文のレコードが含まれています。 両方の閾値は設定可能です Audit log – MariaDB Audit Pluginを使用して提供されるこのログは、監査目的でデータベースアクティビティを記録します これらのソースからのログイベントは、Amazon CloudWatchのロググループにログストリーム(ログイベントのシーケンス)の形式で保存されます。 各DBインスタンスとログの種類に応じて、DBインスタンスと同じAWS Region内に別のグループを次の命名パターンで作成します: /aws/rds/instance/<db-instance-id>/<log-type> ログデータは耐久性のあるCloudWatch Logsに保存され、透過的に暗号化されます。ただし、ログには機密情報が含まれている可能性があります。データを保護するために、アカウント内の適切なユーザーにアクセスを制限する必要があります。そのために、データベースログを含むロググループに対して適切なIAMアクセスポリシーを設定することが重要です。 Amazon RDSはDBインスタンスと同じアカウント内のロググループにservice-linked roleを使用してログを送信します。これにより、Amazon RDSはアカウント内の関連するロググループにアクセスできます。ログの送信を有効にすると、AWSServiceRoleForRDSという追加のIAMロールが表示されることがあります。 CloudWatch Logsへログの送信を有効にするには、以下のように設定を行います。 […]

Read More

Amazon RDSのリードレプリカがMulti-AZ配置をサポートしました

本日より、Amazon RDS for MySQL, MariaDBのリードレプリカがMulti-AZ配置をサポートしました。Multi-AZ配置を設定したリードレプリカを利用することによって、データベースエンジンのアップグレードプロセスの簡素化やディザスタリカバリを見据えた環境を構築することが可能になります。 Amazon RDSのリードレプリカは1つ以上の読み込み専用のデータベースインスタンスをマスターインスタンスと同一のAWSリージョン、もしくは異なるAWSリージョンに作成することが出来ます。ソースデータベースで行われた変更は非同期でリードレプリカへ伝播されます。読み込みが多いワークロードに対するスケーラビリティに加えて、リードレプリカを必要に応じて単一のデータベースインスタンスへ昇格させることも可能です。 Amazon RDS Multi-AZ配置は1つのAWSリージョン内での可用性を向上させます。Multi-AZ環境では、異なるアベイラビリティゾーン(AZ)に存在するスタンバイインスタンスに対してデータが同期的に伝播されます。インフラストラクチャの障害が発生した場合、Amazon RDSはスタンバイインスタンスへ自動的にフェイルオーバーを行い、アプリケーションへの影響を最小限に抑えます。 本番データベースへのディザスタリカバリ(DR)対応として、Multi-AZ配置のリードレプリカをお使いいただけるようになりました。よくデザインされ、テストされたDRプランは災害が発生した後の事業継続性に対して非常に重要な要素になります。ソースデータベースとは別のリージョンにある、リードレプリカをスタンバイ・データベースとして使用し、万が一リージョン障害が発生した場合に新しい本番データベースへ昇格することが可能です。 また、データベースエンジンのアップグレードプロセスにMulti-AZ配置のリードレプリカを利用可能です。本番データベースにリードレプリカを作成し、新しいデータベースエンジンバージョンへ更新します。アップグレードが完了した後に、アプリケーションを一時的に停止し、リードレプリカを単一のデータベースインスタンスとして昇格させます。そして、アプリケーションの接続先を変更します。既に昇格したデータベースインスタンスはMulti-AZ配置になっているため、追加の作業は必要ありません。 更に詳細な情報はこちらをご覧ください。リードレプリカでMulti-AZ配置を行う際に注意していただきたいパラメータについて記載しています。   翻訳は星野が担当しました。(原文はこちら)

Read More