Amazon Web Services ブログ

Category: Database

Amazon ElastiCache を Redis 向けに設定して可用性を高める

現在、Amazon ElastiCache という名前は、リアルタイムアプリケーションと同義に捉えられるようになりました。Redis の性能の高さ、シンプルさ、そして多様なデータ構造へのサポートは、非リレーショナルのキー値ストアとしては、最も人気のあるものの 1 つです。ビジネスに不可欠なリアルタイムのユースケースが Redis 上で増加する中で、可用性の保証は重要な課題となってきています。 高い可用性を実現するため、Redis 用 Amazon ElastiCache では Redis クラスターの設定をサポートし、すぐれたスケーラビリティと可用性を提供します。加えて Amazon ElastiCache では、自動フェイルオーバー機能を持つ複数のアベイラビリティゾーン (Multi-AZ) も提供しており、クラスターがゾーン間で 1 つ以上の複製を作る設定も可能です。主要ノード上で障害イベントが発生しても、Redis 用 Amazon ElastiCache では自動的に複製に対しフェイルオーバーが行われるので、高い可用性が保証されます。 最近、Redis 用 Amazon ElastiCache から、Redis アプリケーションのエンドツーエンドな可用性を向上させるための、いくつかの発表を行いました。 「Amazon ElastiCache for Redis で計画されたメンテナンス中のクラスター可用性が向上」は、自動フェイルオーバーを有効化したクラスターの、パッチ適用、更新、その他メインテナンス関連処理など、ノード置換が関係する作業中における可用性を高めるものです。Redis クラスター設定のセットアップには、Redis Cluster クライアントが使えます。これにより、予定したメインテナンスやノード置換も、書き込み中断をまったく生じずに完了します。非 Redis クラスター (非シャード) 設定では、DNS の更新時に最大で数秒間の短い書き込み中断が生じることがあります。 「Amazon ElastiCache for Redis がセルフサービスアップデートに対応開始」は、メインテナンスのための更新を開始するタイミングを制御することで、その作業の影響を最小化するものです。 「Amazon ElastiCache Redis にリーダーエンドポイントを開始」は、個別レプリカエンドポイントの変更点を管理する必要がなく、読込みトラフィックの接続を可能にするものです。これにより、アプリケーションが個別ノードエンドポイントの変更点を管理する必要性がなくなり、可用性を向上させます。この機能は、Redis クラスター設定に対しては、すでにRedis […]

Read More

Amazon Aurora Global Database による事業継続性の向上

  ビジネスがグローバルに成長するにつれて、データベースのニーズも同様に増加します。リソースは、チューリッヒのチームと北京のオフィスとの間で、同じ速度、同じセキュリティ、同様のアクセスの容易さで利用可能でなければなりません。Amazon Aurora Global Database は、世界中の Amazon Aurora データベースを拡張します。 Aurora は、保護グループと呼ばれる 10 GB の論理ブロックにストレージボリュームを構築しています。次に、同じリージョンで 3 つのアベイラビリティーゾーンに割り当てられている 6 つのストレージノードにわたって、各保護グループのデータを複製します。データの容量が現在割り当てられているストレージの容量を超えると、Aurora は需要に合わせて容量をシームレスに拡張し、必要に応じて新しい保護グループを追加します。 re:Invent 2018 で発表された Aurora Global Database は、この複製プロセスを他のリージョンにも拡張しています。これにより、リージョン間での災害復旧が高速化され、高性能、低ラグ、リージョン間の読み取りスケーリングが可能になります。Aurora Global Database を使用すると、データベースのパフォーマンスへの影響を最小限に抑えながら、データベースを複数のリージョンに拡張できます。 この記事では、Aurora Global Database を紹介し、その利点とユースケースについて説明します。 Aurora Global Database とは何ですか? Aurora Global Database は複数のリージョンにわたり、リージョン全体の停止から災害復旧を行い、低レイテンシーのグローバル読み取りを可能にします。 Aurora の機能として、Global Database は Aurora のストレージレイヤーにある専用のインフラストラクチャを使用して、リージョン間のレプリケーションを処理します。ストレージレイヤー内の専用レプリケーションサーバーがレプリケーションを処理するため、データベースのパフォーマンスを損なうことなく、復旧と可用性という目標を強化できます。 MySQL バイナリログレプリケーションと Aurora Global Database で使用されるストレージベースのレプリケーションには、いくつか重要な違いがあります。論理レプリケーション、つまり binlog レプリケーションは、データ変更ステートメントまたは行の変更を複製元 […]

Read More

スキーマ設計を通じた Amazon DynamoDB スキャンレイテンシーの最適化

この記事では、Amazon DynamoDB のテーブル構造がスキャンパフォーマンスにどのように影響するかについて説明し、テーブルのスキャン時間を最適化する方法をご紹介します。 Amazon DynamoDB は、柔軟なスキーマを使用できる NoSQL データベースです。これは、項目それぞれにどのような属性が存在するかという点で、同じテーブル内の項目が互いに異なることを意味します。 DynamoDB のスキーマとアクセスパターンの大部分は GetItem 操作と Query 操作を中心に方向づけと最適化が行われ、これによってテーブルまたはインデックスから単一項目にアクセスするときに一貫した 1 桁台のミリ秒での応答時間が提供されますが、ユースケースとアクセスパターンには、テーブルとインデックスのスキャンが必要なものもあります。 概要 柔軟なスキーマを持つデータベースでは、データベーススキャンから返されたすべての項目について、ネットワーク応答にデータだけでなく、メタデータも含まれています。このメタデータには、各属性の属性名とデータタイプが含まれる場合があります。 各項目により多くの属性を追加すると、クライアントオーバーヘッドもいくらか追加されます。これは、ネットワーク応答の各列が、適切なクライアントデータ構造にマーシャルされる必要があるからです。その例は Python ディクショナリー、Node.js マップ、Java オブジェクトなどです。 属性メタデータは容量を消費するため、DynamoDB 応答の 1 MB 上限に収まる項目数が少なくなります。その結果として、データのスキャンに必要な往復回数が増えることになります。 テスト方法 パーティションキーとソートキー (どちらも文字列) で構成されるプライマリキーというシンプルな構造のテーブルを 1 つ作成しました。144 個のランダムな文字の文字列が含まれる field1 という名前の 3 番目の文字列属性もあります。 また、3 文字および 6 文字の属性値の両方を持つ、7 文字の属性名 (field01… field24) の異なる組み合わせを使ったテーブルも作成しました。これらのテーブルには、最初のテーブルと同じプライマリキー構造があります。 柔軟なスキーマを持つ NoSQL データベースは、項目ごとに属性名を保存する必要があります。項目の属性が増える、または属性名が長くなると、項目は属性名を保存するためにより多くの容量を消費します。 最後に、24 個の属性 (それぞれが同じ 7 文字の属性名と […]

Read More

Amazon Aurora PostgreSQL でのクエリ計画管理のユースケース

このブログの投稿は一連の投稿の 2 回目です。前回のブログ記事では、SQL ステートメントの実行計画に回帰を引き起こす可能性があるその他の変更の中で、安定かつ一貫したデータベースパフォーマンスの必要性について説明しました。また、PostgreSQL と互換性のある Amazon Aurora のクエリ計画管理 (QPM) が、計画安定性と計画適応性の問題を克服できるようにする方法も述べています。 この記事では、引き続き Aurora PostgreSQL QPM の機能について説明します。特に、これらの機能によって、さまざまな高度なユースケースに対して計画安定性と適応性を実現する方法についてお話します。 ユースケース #1: QPM 手動取得による計画安定性と適応性の支援 最初のユースケースでは、QPM が計画安定性を確保する方法について例を挙げて説明します。次に、前回の記事 Aurora PostgreSQL クエリ計画管理の概要で説明した変更を行います。QPM を使用しない場合は、これらの変更により計画の回帰が生じる可能性があります。 ほとんどの場合、自動計画取り込みを使用するように QPM を設定して、2 回以上実行されるすべてのステートメントを取得することもできます。ただし、手動で指定した特定のステートメントセットの計画を取得することもできます。そのためには、デフォルトに capture_plan_baselines = off を設定します。セッションレベルでは、capture_plan_baselines = manual を設定します。設定の仕方については後で説明します。 手動計画取り込みを有効にして、目的の SQL ステートメントの実行計画を手動で取得するように QPM に指示します。 pg105db=> SET apg_plan_mgmt.capture_plan_baselines = manual; SET QPM がクエリ計画を取得できるように、クエリ説明計画を実行します (説明計画の以下の出力は、簡潔にするために省略されています)。 pg105db=> explain (hashes true) SELECT […]

Read More

Aurora PostgreSQL クエリ計画管理の概要

すべての AWS サービスと同様に、Amazon Aurora PostgreSQL のロードマップは、主にお客様のご意見と製品強化のご要望によって推進されます。Oracle と Microsoft SQL Server から Amazon Aurora にデータベースを移行した、複数の企業お客様からいただいたフィードバックは、2 つの点を示唆しています。重要なアプリケーションのデータベースワークロードを実行する企業は、最適なデータベースパフォーマンスを必要とします。また、企業には Aurora PostgreSQL と互換性のあるデータベースでさまざまなシステム変更を行っても、安定かつ一貫性を保つパフォーマンスが必要です。 PostgreSQL データベースのパフォーマンスが変動する主な原因の 1 つはチェックポイントプロセスにあります。多くの場合、パフォーマンスと回復性の間のトレードオフのことです。Aurora PostgreSQL では、データベースのチェックポイントを排除することでこの問題に対処してきました。ログ記録とストレージレイヤーを切り離すために、ログベースのストレージサブシステムを実装します。応答時間が変動するもう 1 つの主な原因は、クエリ計画の不安定性によるものです。クエリ実行計画を予期せずに変更する、さまざまな要因があります。以下に例を挙げます。 オプティマイザ統計の変更 (手動または自動) クエリ計画設定のパラメータに対する変更 新しいインデックスの追加など、スキーマに対する変更 クエリで使用されるバインド変数に対する変更 PostgreSQL データベースバージョンへのマイナーバージョンまたはメジャーバージョンのアップグレード。PostgreSQL 9.6.x から 10.x など クエリ計画管理 Aurora PostgreSQL クエリ計画管理 (QPM) 機能は、データベースユーザーが一連の管理 SQL ステートメントに対して安定かつ最適なパフォーマンスを維持できるようにすることで、計画不安定性の問題を解決します。QPM では主に 2 つの目的を果たすことができます。 計画安定性。システムに上記の変更が発生した場合、QPM は計画の回帰が生じないようにして、計画安定性を向上させます。 計画適応性。QPM は、新しい最小費用計画を自動的に検出し、新しい計画が使用されるときに制御し、その変更に適応します。 QPM の仕組み 以下のフローチャートは、QPM […]

Read More

RDS Classic から Aurora MySQL へのミッションクリティカルな SaaS プロダクションワークロードの移行

Sumo Logic は、AWS スタックが成熟し始めた頃とほぼ同じ時期に創業しました。同社は当初、試行とテストが行われたインフラストラクチャを選択しましたが、同時に最先端のインフラストラクチャ、つまり Amazon RDS for MySQL インスタンスも選択しました。 けれども、時が経つにつれ、その選択で開発者のかなりの時間が取られるようになりました。開発者は、MySQL バージョンのアップグレード、データベース接続の増加によるインスタンスのスケーリング、顧客からのデータと需要の増大に伴うストレージのスケーリングに時間を使いました。 つまり、顧客に見えるダウンタイムを持つことと、古いバージョンの MySQL を長期間使用し続けることとの間に絶え間ない葛藤がありました。当社は、成長するにつれて見込まれる将来のワークロードに対する、より手を加えず、堅牢で柔軟なソリューションを必要としていました。 当社について Sumo Logic は、安全なクラウドネイティブのマシンデータ分析プラットフォームです。アプリケーションのライフサイクルおよびスタック全体にわたって、構造化データ、半構造化データ、および非構造化データからリアルタイムの継続的なインテリジェンスを提供します。 世界中の 2,000 人以上の顧客が最新のアプリケーションとクラウドインフラストラクチャを構築、実行、および保護するための分析と洞察を求め、Sumo Logic を当てにしています。Sumo Logic を利用すると、マルチテナントサービスモデルの優位性を得て、継続的なイノベーションへの移行を加速し、競争上の優位性、ビジネス上の価値、および成長を促進することができます。 Amazon Aurora に移行した理由 Amazon Aurora へ移行することで、Amazon が提供する従来の RDS の実装を超えるいくつかの利点がもたらされました。 完全マネージド: Aurora インスタンスとクラスターは、Amazon RDS によって完全に管理されています。この管理機能により、最小限のダウンタイムでスケーリング、ストレージの追加、アップグレードやパッチの適用を行うことができます。ほとんどの場合、これらはクライアントの中断を招くことなく行われます。これは、Sumo Logic の非常に高い成長率と規模をサポートしているインフラストラクチャチームにとって大きなメリットです。 高可用性と耐久性: 従来の MySQL に関する最大の懸念の 1 つは、メンテナンス、ネットワークパーティション、またはサービスの喪失に伴う、顧客に見える停止時間でした。Aurora はこれらの点ではるかに高い回復力をもたらします。 互換性: Aurora のカギを握る機能は MySQL との互換性です。つまり、クライアントでコードを変更する必要はありませんでした。導入するとすぐにうまくいきました。 デフォルトの VPC: […]

Read More

RDS SQL Server での SQLAgentOperatorRole の活用

SQL Server DBA およびユーザーは、SQL Server インスタンスでジョブをスケジュールするために SQL Server エージェントを長い間使用してきました。これは、スケジュールに従って、アドホックベースで、またはイベントに応じてジョブを起動できる便利なツールです。SQL Server エージェントは常に Amazon Relational Database Service (Amazon RDS) でサポートされていますが、権限が制限されています。たとえば、RDS マスターユーザーでも SQL Server Management Studio (SSMS) ユーザーインターフェイスを使用して、インスタンスでスケジュールされたすべてのジョブを確認することはできません。最近の RDS の変更により、より多くの権限がマスターユーザーに付与されており、上記の制限はなくなりました。このブログでは、権限への変更と、新しい権限をシームレスに使用する方法について説明します。 新しい SQL Server エージェントの権限 RDS SQL Server は、Enterprise、Standard、および Web エディションで SQL Server エージェントをサポートしています。RDS SQL Server インスタンスのマスターユーザーは、デフォルトで SQLAgentUserRole に追加されます。マスターユーザーは他のユーザーを SQLAgentUserRole に追加することもでき、このロールの一部であるすべてのユーザーは SQL エージェントジョブを作成できます。ジョブを作成したユーザーだけが、そのジョブを表示、有効化、無効化、編集、実行、開始、および停止できます。これは一部のユースケースでは十分ですが、このレベルのアクセスでは不十分なユースケースもあります。たとえば、メンテナンスジョブが個々のユーザーアカウントを使用して作成されるデータベース管理者 (DBA) のチームでは、ジョブを作成した DBA が多忙なときは別の DBA がジョブを開始することがあります。この要件やその他の要件に対処するため、2019 […]

Read More

SimilarWeb が Couchbase から Amazon DynamoDB に移行し、70% 節約した方法

今回は AWS ソリューションアーキテクトの Leonid Koren、および AWS シニアテクニカルアカウントマネージャーの Ziv Shenhav との共同著作による、SimilarWeb のソフトウェア開発者 Doron Grinzaig 氏のゲストブログ投稿です。 NoSQL データベースはスケーラブルで適応性があり、高機能のデータベースを必要とする現代のモバイル、ウェブ、ゲーム用アプリケーションに最適です。しかしながら、NoSQL データベースは分散型の性質を持つため、特に大きな規模になると管理が難しく、多くのリソースとかなりの注意が必要になります。SimilarWeb は数年の間、2 つの Couchbase クラスターを運用していましたが、コストと運用オーバーヘッドは高くついていました。そのため SimilarWeb は、安定性の向上とコストおよび運用オーバーヘッドの削減を目指して、Amazon DynamoDB に移行したのです。DynamoDB は完全マネージド型のデータベースサービスで、現在では複数の AWS リージョンで SimilarWeb の顧客にデータを提供している信頼性の高いデータベースの 1 つです。 このブログ投稿では、SimilarWeb が DynamoDB への移行を決めた理由を詳しく説明します。移行プロセスについて説明し、コスト削減に役立った最適化の方法についても解説します。 SimilarWeb について SimilarWebは、デジタル世界全体の動向に関する洞察を提供するマーケットインテリジェンス企業です。何千にもおよぶ顧客が同社の洞察を基に、マーケティング戦略の改善、販売促進、さらに投資に関する重要な決定を下しています。重要な意思決定に SimilarWeb が関わっていることが、データを効果的に収集かつ利用し、最終的にはユーザーに提供する SimilarWeb の能力を証明しています。 SimilarWeb はさまざまなソースから大量の生データを継続的に収集し、取り込みます。Cloudera クラスター (Apache Spark を実行している) を使って、これらのデータを並び替えて構造化します。データを Apache HBase クラスターにロードし、Amazon S3 ベースのデータレイクに保存します。過去にはデータの一部を […]

Read More

サポートが終了する VMware Clous on AWS の SQL Server インスタンスを簡単にアップグレードする

Microsoft SQL Server 2008 と 2008 R2 のインスタンスをまだデプロイしているなら、今こそアップグレードするべきです。これらの Microsoft のサポート終了日 (EoS) は 2019 年 7 月 9 日。もうすぐです。つまり、それ以降はセキュリティの問題やコンプライアンス上の問題があるため、これ以上セキュリティの更新は行われません。実行するなら今です! 今日は、SQL Server インスタンスのアップグレードの自動化を支援する新しいオープンソースのツールを GitHub で公開できることを大変うれしく思っています。この自動化により、アップグレードの実行が迅速になり、重要なデータを格納しているアプリケーションに対するセキュリティ体制を維持しつつ、EoS の前にこのプロジェクトを完了できるようになります。 開始方法 新しいツールは Upgrade-SqlServerStandaloneDatabaseEngineInstance.ps1 という名前で、GitHub で入手できます。これは vSphere インフラストラクチャにアクセスできない可能性があるデータベース管理者 (DBA) などによってローカルで開始されるか、仮想システム管理者などによってリモートで開始されることがあります。アップグレードは Microsoft Windows PowerShell と PowerShell Core の両方でテストが行われました。したがって、macOS、Linux、Windows からリモートアップグレードの起動が可能です。 この記事では、スタンドアロンの SQL Server 2008 R2 SP3 インスタンスを SQL Server 2016 にリモートでバッチアップグレードします。これを AWS の VMware […]

Read More

オープンソースプラットフォームで ProxySQL を使用して、Amazon Aurora クラスターでの SQL の読み取りと書き込みを分割する方法

ブログ記事Amazon Aurora PostgreSQL で読み書き用に pgpool の単一のエンドポイントを設定する方法では、Amazon Aurora PostgreSQL エンドポイントの読み取りおよび書き込みの分割機能を使用するアーキテクチャを紹介しています。このタイプのアーキテクチャは Aurora PostgreSQL クラスターに最適ですが、データベースに Amazon Aurora MySQL クラスターを使用している場合はどうでしょうか? この記事は、Aurora MySQL エンドポイントで読み取りおよび書き込みの分割を実現するための中間レイヤーとして ProxySQL を紹介することによって、元の記事を補完します。 Amazon Aurora は、プライマリ DB インスタンス (クラスターエンドポイント) と、リードレプリカ (リーダーエンドポイント) のエンドポイントを提供します。Aurora は、クラスタエンドポイントを自動的に更新するので、常にプライマリインスタンスを指し示すようできています。リーダーエンドポイントを使用して、使用可能なすべてのリードレプリカにまたがる読み取り操作のための接続に対して DNS ラウンドロビンを実行します。さらに、Amazon Aurora カスタムエンドポイントを使用して、アプリケーションのトラフィックをさらに分離することができます。 Amazon Aurora Replica では、通常 100 ms 未満のレプリケーションラグが発生します。したがって、アプリケーションで遅延が許容される場合は、以下に示すように、クラスターエンドポイントとリーダーエンドポイントの両方を使用して、水平方向に拡張されたデータベースを利用することができます。 前の図は、使用するエンドポイントを決定するアプリケーションの現在のアーキテクチャを示しています。ただし、読み取り用と書き込み用両方のデータベースエンドポイント管理は、複雑なアプリケーションになります。一部のサードパーティ製ドライバーは、より狭い範囲のユースケースしかサポートしていませんが、この記事のアイデアを読み書きを分割するユースケースにより広く適用することができます。 この記事では、ProxySQL を使って、書き込みトラフィックをクラスターエンドポイントへ、読み取りトラフィックをリーダーエンドポイントに自動的に転送する MySQL 互換の単一 Aurora エンドポイントを構築する方法をご紹介します。以下の図は、ProxySQL ミドルウェアに基づいて提案されるソリューションを示しています。 アーキテクチャ ProxySQL は、MySQL データベースとデータベースクライアント間に存在する、GNU General […]

Read More