Amazon Web Services ブログ

Category: Database

Apache Kafka 向け Amazon Managed Streaming を使用して、データキャプチャを Neo4j から Amazon Neptune に変更

Neo4j から Amazon Neptune へのポイントインタイムデータ移行を実行した後、進行中の更新をリアルタイムでキャプチャして複製することができます。Neo4j から Neptune へのポイントインタイムグラフデータ移行の自動化については、完全に自動化されたユーティリティを使用した Neo4j グラフデータベースの Amazon Neptune への移行をご参照ください。この記事では、cdc-neo4j-msk-neptune リポジトリのサンプルソリューションを使用して、Neo4j から Neptune へのキャプチャとレプリケーションを自動化する手順について説明します。 変更データキャプチャ (CDC) パターンを使用したデータベースの継続的なレプリケーションにより、データをストリーミングして他のシステムで利用できるようにすることができます。この記事では、最新の変更を Neptune にコピーできるように、CDC を使用して Neo4j からデータをストリーミングすることにより、グラフデータベースを最新化することに専念しています。Strangler パターンのイベント傍受戦略を使用して Neo4j を最新化することにより、すべての変更を Neptune に段階的にプッシュし、アプリケーションを変更して Neptune を使用できます。Neptune は、高速で信頼性が高い、完全マネージド型グラフデータベースサービスであり、高度に接続されたデータセットと連携するアプリケーションの構築と実行を容易にします。Neptune の中核にあるのは、何十億もの関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用の高性能グラフデータベースエンジンです。 アーキテクチャの概要 この記事のソリューションは、AWS アカウントでの次のアーキテクチャのデプロイを自動化します。このアーキテクチャは、レプリケーション用の疎結合システムを構築するためにソリューションがプロビジョニングする AWS リソースを示しています。 アーキテクチャには次の要素が含まれます。 Amazon VPC 内のすべての必須 AWS リソースをブートストラップする、エンドユーザーがトリガーする AWS クラウド開発キット (AWS CDK) アプリ レプリケーション用の Docker コンテナで実行される専用サービスを実行するための Amazon Elastic […]

Read More

Amazon Aurora Global Database の書き込み転送を使用してグローバルに分散された MySQL アプリケーションを構築する

AWS は 2018 年に Amazon Aurora Global Database をリリースしました。Aurora Global Database は主に 2 つのユースケースで使えます。最初のユースケースは、災害復旧ソリューションをサポートすることです。これにより、低目標復旧時点 (RPO) と低目標復旧時間 (RTO) でリージョン全体の障害に対処しながら、保護対象のデータベースクラスターへのパフォーマンスへの影響を最小限に抑えることができます。Aurora Global Database を使用すると、通常、RPO は 5 秒未満、RTO は 1 分未満に抑えることができます。書き込みワークロードが大きい場合でも、ソースクラスターとターゲットクラスターの両方に対するパフォーマンスへの影響は無視できるほどに小さいものです。 Aurora Global Database の 2 番目の主なユースケースは、最大 5 つのリモートリージョンに Amazon Aurora クラスターの読み取り専用コピーを供給して、そのリージョンに近いユーザーにサービスを提供することです。これにより、リモートリージョンのユーザーは、さらに離れたプライマリリージョンに接続する必要がある場合よりも低いレイテンシーで読み取りが行えます。 次のグラフは、2 つのリージョン間で MySQL 論理レプリケーションを使用した例を示しています。クエリの数が段階的に増加すると、ターゲットクラスターで観察されるレプリケーションタイムラグは指数関数的に増加します。さらに、テスト済みの設定で処理できる 1 秒あたりのクエリ数は、ピーク時に約 35,000 でした。 対照的に、次のグラフは、Aurora Global Database を使用したのと同じワークロードとインスタンスのサイジングを示しています。レプリケーションは 1 秒未満のタイムラグを維持し、1 秒あたりのクエリ数はピーク時に約 200,000 (+ […]

Read More

Amazon Redshift 横串検索のベストプラクティス

Amazon Redshift 横串検索では、Amazon Redshift の分析機能を使用して、Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL データベースに保存されているデータを直接クエリできます。横串検索を試すことができる環境のセットアップの詳細については、「AWS CloudFormation で Amazon Redshift 横串検索の採用を加速する」を参照してください。 横串検索では、リアルタイムのデータ統合と簡素化された ETL 処理を行えます。Amazon Redshift でライブデータソースを直接接続して、リアルタイムのレポート作成と分析を行えるようになりました。以前は、PostgreSQL データベースから Amazon Simple Storage Service (Amazon S3) にデータを抽出し、COPY を使用して Amazon Redshift にロードするか、Amazon Redshift Spectrum を使用して Amazon S3 からクエリを実行する必要がありました。横串検索の利点の詳細については、「Amazon Redshift 横串検索を使用して、簡略化された ETL およびライブデータクエリソリューションを構築する」を参照してください。 この記事では、統合データセットが大きい場合、横串検索が大量のデータを取得する場合、または多くの Redshift ユーザーが統合データセットにアクセスしている場合に、横串検索のメリットを最大化するための 10 のベストプラクティスをご紹介します。これらの手法は、横串検索を一般的に使用する際には必要ありません。これらは、この興奮を覚えるような機能を最大限活用したい上級ユーザーを対象としています。 ベストプラクティスは 2 つのセクションに分かれています。1 つ目は Amazon […]

Read More

Waves における大規模なユーザークエリとレコメンデーションへの Amazon Neptune の利用

本記事は、ClearScale のソリューションアーキテクチャディレクタであり、APN のプレミアコンサルティングパートナーとしてもクラウドの全体的なプロフェッショナルサービスを提供している、Pavel Vasilyev 氏の寄稿です Waves は Y Combinator から支援を受けているデートアプリです。同社の既存の IT アーキテクチャが、Google Cloud では維持しきれなくなると経営陣が認識したとき、それは AWS への移行を開始するタイミングとなりました。Waves は、Google Cloud から AWS への移行、およびグラフデータベースエンジン専用に設計された Amazon Neptune などのサービスを使った機能を実装するにあたり、 ClearScale とパートナーを結ぶことを決めました。Neptune を使用する開発者は、相互接続したデーセットを扱うアプリケーションの構築と実行が可能になります。これは、Waves が必要としていた機能そのものです それまで Waves アプリケーションは、急速に増加するユーザー数に起因する、いくつもの課題と対峙していました。これらの課題には、特定のデータベースクエリが原因となった信頼性やレイテンシーの問題が含まれます。これらのクエリは、アプリに組み込まれたレコメンデーションエンジンが実行しているものです。加えて、Waves でのインフラストラクチャ向け予算は想定外の速さで増加し続けており、その終着点も見えない状態だったのです。 この記事では、Waves のワークロードを AWS に移行するために、ClearScale が取った手法をご紹介します。またそこで、膨大なクエリボリュームを処理できる先進的なレコメンデーションエンジンを構築するために、Neptune を導入した方法についてもご説明していきます。加えて、AWS が提供する他の機能を使用しながら、ClearScale が Waves の全体的なアーキテクチャを強化した方法も解説します。 移行プロジェクト まず、Waves と ClearScale の両者は、この共同作業が、次のような 5 つのステージに分かれることを明確化しました。 Cloud Storage から Amazon Simple Storage […]

Read More

Amazon Aurora MySQL から Amazon S3 にデータをエクスポートおよびインポートするためのベストプラクティス

複雑なアプリケーションを小さな部分に分割することにより、多数の専用データベースを使用して高度に分散したアプリケーションを構築できます。これにより、ジョブに適したデータベースを選択できます。Amazon Aurora は、OLTP ワークロードの推奨される選択肢です。Aurora により、クラウド内でリレーショナルデータベースをセットアップ、操作、スケーリングするのが容易になります。 この記事では、Aurora MySQL から Amazon Simple Storage Service (Amazon S3) にデータをエクスポートおよびインポートする方法を示し、関連するベストプラクティスについて説明します。Amazon Aurora PostgreSQL では、データを Amazon S3 機能にエクスポートおよびインポートすることもできます。このブログでは、Amazon Aurora MySQL に焦点を当てます。 Aurora と Amazon S3 の概要 Aurora は、クラウド向けに構築された MySQL と PostgreSQL の互換性があるリレーショナルデータベースで、従来のエンタープライズデータベースのパフォーマンスと可用性、およびオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。 Amazon S3 は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。つまり、どの規模と業界の顧客もこれを使用して、任意の量のデータを保存および保護できます。 前提条件 始める前に、以下を完了してください。 Aurora MySQL DB クラスターを起動します。既存のクラスターを使用することもできます。 MySQL クライアントをインストールした Amazon EC2 インスタンスを起動します。ここでは、MySQL Workbench を使用することもできます。 次の必須の Identity and Access […]

Read More

Amazon DocumentDB (MongoDB 互換) の開始方法 – パート 3; – Robo 3T の使用

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 このシリーズのパート 3 であるこの投稿では、Amazon DocumentDB と Robo 3T (旧 Robomongo) の開始方法を説明します。Robo 3T は、軽量でシェル中心のオープンソースプラットフォーム間のグラフィカルユーザーインターフェイスツールであり、MongoDB ワークロードを管理します。Robo 3T は、データベースとコレクションの作成、ユーザーやドキュメントの追加、オートコンプリート機能を搭載した 1 回限りのクエリの実行、GUI インターフェイスからの結果の視覚化を実現するため、より効率的です。 この投稿では、VPC 内に単一インスタンスの Amazon DocumentDB クラスター、同じ VPC 内の EC2 Linux VM を作成し、2 つの間に SSH トンネルを設定します。また、Robo 3T を使用してクラスターに接続し、ローカルコンピュータからいくつかのクエリを実行します。次の図は、このチュートリアルの最終的なアーキテクチャを示しています。 Amazon DocumentDB クラスターの作成 AWS コマンドラインインターフェイス […]

Read More

Amazon DocumentDB のスケーリング (MongoDB 互換性あり)、パート 1: 読み込みのスケーリング

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。Amazon DocumentDB で、MongoDB で使用しているものと同じアプリケーションコードを実行し、同じドライバー、およびツールを使うことができます。この記事では、Amazon DocumentDB の最新クラウドネイティブデータベースアーキテクチャにより、クラスターの読み込みスループットを従来のアーキテクチャよりも高速かつ柔軟にスケーリングできる方法を示します。この記事では、Amazon DocumentDB クラスターへの接続とそこからの読み込みに関する推奨事項も提供されます。 Amazon DocumentDB クラウドネイティブアーキテクチャ 従来のモノリシックなデータベースとは異なり、Amazon DocumentDB のクラウドネイティブアーキテクチャは、ストレージとコンピューティングを分離しています。Amazon DocumentDB クラスターは、分散ストレージボリュームと、ストレージボリュームからデータを読み書きする 1 つ以上のコンピューティングインスタンスで構成されます。次の図は、1 つのプライマリインスタンスと 2 つのレプリカインスタンスを持つ Amazon DocumentDB クラスターを示しています。 コンピューティングインスタンスがリクエストを処理し、クラスターのストレージボリュームはすべてのデータのコピーを 6 つ (3 つのアベイラビリティーゾーンでそれぞれ 2 つのコピー) を維持することで耐久性を提供します。このアーキテクチャは、読み込みおよび書き込み操作用の単一のプライマリインスタンスと、読み込み操作用の最大 15 個の読み込みレプリカを提供し、1 秒あたり数百万回の読み込みにスケーリングします。 Amazon DocumentDB インスタンスにはデータが含まれていないうえに、新しいインスタンスを追加するときにデータをコピーする必要がないため、クラスターに新しいインスタンスをすばやく追加および削除できます。保存されているデータの量に関係なく、新しいレプリカインスタンスを追加し、既存のインスタンスのサイズを数分で変更することができます。新しいインスタンスは通常 8〜10 分でプロビジョニングされ、アクティブになるとすぐにクエリを処理できるようになります。Amazon DocumentDB の完全マネージド型のアプローチは、このアーキテクチャを利用して、ハードウェア障害が発生した場合にインスタンスをすばやく置き換えます。その結果、従来のデータベースアーキテクチャよりもはるかに迅速に回復できます。 Amazon DocumentDB エンドポイント Amazon DocumentDB は、3 種類のエンドポイントをサポートしています。 […]

Read More

非アクティブな Amazon Aurora PostgreSQL ユーザーの管理

データはあらゆる組織にとって最も貴重な資産の 1 つであり、データを安全に保つことは常に最優先事項です。データベースの一般的なセキュリティ要件の 1 つは、ユーザーアクセスを制限することです。データベースユーザーが危険にさらされた場合、データに重大な損害を与える可能性があるからです。データベースユーザーの最小権限モデルに沿って実行する必要があります。つまり、作業に必要な一連の最小権限のみをユーザーに付与します。また、データベースユーザーが長期間非アクティブである場合は、無効にすることをお勧めします。これにより、ミスやセキュリティ違反による影響を制限できます。詳細については、PostgreSQL ユーザーとロールの管理を参照してください。 この記事では、アクティブでない Amazon Aurora PostgreSQL ユーザーを特定し、自動的にロックまたは削除するソリューションを提供します。記事では、サンプルコードと AWS CloudFormation テンプレートも共有しているため、そのまま開始できます。 次の使用例では、特定の日数 (この記事では 90 日) の間、非アクティブであったユーザーを特定する必要があります。これらのユーザーを特定したら、ロックアウトします。DBA は、いつでもこれらのユーザーをロック解除できます。ただし、ユーザーが 180 日間非アクティブである場合は、自動的に削除する必要があります。 ただし、PostgreSQL はこの機能をネイティブでサポートしていません。一部の商用データベースでは、この機能にユーザープロファイル機能を含めています。これにより、指定した日数の間データベースにログインしていないユーザーアカウントをロックできます。 PostgreSQL の場合、PostgreSQL はユーザーログインのタイムスタンプをどのカタログテーブルにも保存しないため、作業がより困難になります。したがって、ユーザーが非アクティブである期間を判別するのは簡単ではありません。さらに、PostgreSQL にはログイントリガーがないため、トリガーベースのソリューションを適用するのも不可能です。 ソリューション パラメータグループでパラメータ log_connections を 1 に設定することにより、成功した各ログインの詳細 PostgreSQL へのロギングを有効にできます。このパラメータを設定すると、PostgreSQL エンジンはログインが成功するたびに次のようなメッセージを記録します。 2020-01-07 03:51:56 UTC:10.0.0.123(52820):postgres@logtestdb:[18161]:LOG: connection authorized: user=postgres database=logtestdb SSL enabled (protocol=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, compression=off) Aurora PostgreSQL では、これらのエンジンログを Amazon CloudWatch Logs […]

Read More

Amazon Neptuneを使ってニュースパスのコメント機能を実装・運用する方法

この投稿は Gunosy によるゲスト投稿で「AWS Neptuneを使ってニュースパスのコメント機能をGraphDBで実装・運用する方法」の記事に加筆修正を加えたものです。 Gunosy は「情報を世界中の人に最適に届ける」を企業理念に掲げ、情報キュレーションサービス「グノシー」、KDDI株式会社と共同で提供する、ニュース配信アプリ「ニュースパス」、女性向け総合情報アプリ「LUCRA(ルクラ)」等のメディアの開発・運営をしています。また、これらのメディアを通じたメディア事業のほか、「Gunosy Ads」や「Gunosy Ad Network」等のアドテク事業も行っています。情報キュレーションサービスは、インターネット上に存在する膨大な量の情報の中から、特定の基準に基づき情報を収集し配信するサービスです。Gunosy は、情報の収集・整理を、人の手ではなく、アルゴリズムを用いて、ユーザーが必要とする情報を届けています。 「ニュースパス」は、かんたん操作で話題のニュースがチェックできる無料のアプリです。独自の情報解析・配信技術を用いて、提携メディアが配信するニュースの中から自動的に選定した情報をお届けします。ニュースパスではニュースの記事にコメントをつけることができます。この投稿では Amazon Neptune を使ってどのようにニュースパスのコメント機能を実装し、運用しているかについてお話しします。 なぜAmazon Neptuneを使ったのか? 最初は Amazon Aurora か Amazon DynamoDB での実装を検討していましたが、グラフ構造に適しているという理由から Amazon Neptune の採用を決めました。 また、今後記事以外に対するコメントなどといった機能追加も、データ構造的に容易であるという点にも魅力を感じました。そして、簡易的なレコメンド機能の実装も簡単に行えるという利点もありました。 Amazon Neptuneで何を解決したのか ニュースパスでは、記事へのコメント機能を Amazon Neptune を使用して実現していて、コメントデータは次の図のような形で保持されています。 コメントのデータ構造は下記の要素で構成されます。 articleとcommentの vertex (頂点)が、aboutのedge(辺)で結ばれている (記事へのコメントは記事に紐付く) commentとuserの vertex が、postの edge で結ばれている (コメントはユーザーによって投稿される) commentとuserの vertex が、likeの edge で結ばれている (コメントはユーザーからいいねされる) commentとuserの vertex が、deleteの edge で結ばれている […]

Read More

分散型可用性グループを使用したマルチリージョン SQL Server のデプロイ

 SQL Server のマルチリージョンアーキテクチャは、多くの場合、お客様と連携する際に関心を集めるトピックです。SQL Server のデプロイにマルチリージョンアーキテクチャアプローチを採用する根本的な理由は次のとおりです。 ビジネス継続性と災害復旧 地理的に分散したお客様の事業所とエンドユーザーのためのレイテンシーの改善 この投稿では、2 つ以上の AWS リージョンにまたがる可用性の高い SQL Server のデプロイを効果的に設計するためのアーキテクチャパターンについて説明します。また、マルチリージョンアプローチを使用して読み取りワークロードをスケールアウトし、グローバルに分散したエンドユーザーのためにレイテンシーを改善する方法についても学びます。 アーキテクチャ: 従来的かつ最適 この投稿では、マルチリージョンの Always On 可用性グループの従来のアプローチと、マルチリージョンの分散型可用性グループの最適なアプローチの 2 つのアーキテクチャについて説明します。 マルチリージョンの Always On 可用性グループ 従来のアプローチでは、リージョン間 VPC ピアリング接続を確立し、単一の Windows Server Failover Cluster (WSFC) が 2 つのリージョンにまたがるようにして、これら 2 つのリージョンのノードで Always On 可用性グループのデプロイを構築できます。次の図は、このアーキテクチャを示しています。 このアーキテクチャでは、リージョン A がプライマリレプリカをホストします。同期セカンダリレプリカもリージョン A でホストされています。プライマリレプリカはリージョン A の AZ1 にあり、同期セカンダリレプリカは AZ2 にあります。データ転送はレプリカ間で同期され、フェイルオーバーモードは自動フェイルオーバーです。AZ1 の接続障害またはその他の障害が発生した場合、自動フェイルオーバーが開始され、AZ2 […]

Read More