Amazon Web Services ブログ

Category: Database

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

Amazon Redshift のクォータでスキーマのストレージスペースをモニタリングおよび制御する

 Yelp は、人々を地元の優れたビジネスと結びつけます。Yelp は 2004 年に立ち上げて以来、本拠地を置くサンフランシスコ 1 都市でサービスを提供するに過ぎなかったのが、30 か国以上の主要都市にまたがる多国籍企業へと成長しました。同社のパフォーマンスベースの広告およびトランザクションビジネスモデルにより、2015 年の収益は 5 億ドルを超え、前年比 46% 増加しました。Yelp はモバイル中心の企業へと進化し、検索の 70% 以上、コンテンツの 58% 以上がモバイルデバイスを基にしています。 Yelp は Amazon Redshift を使用して、モバイルアプリの使用状況データと、顧客コホート、オークション、および広告指標に関する広告データを分析しています。Yelp はすぐに新しい Amazon Redshift のスキーマストレージクォータ機能の恩恵を受けました。 「Amazon Redshift は、Yelp がデータベース管理に時間を費やすことなくデータ分析に集中することを可能にするマネージドデータウェアハウスサービスです」と、Yelp の Metrics Platform のリードエンジニアである Steven Moy 氏は言います。Metrics Platform により、Yelp のエンジニアリングチームは長期の永続的なデータストレージと SQL-on-anything クエリ機能を享受できます。「当社のデータウェアハウスユーザーがすばやく繰り返すための重要な戦略は、「tmp」と呼ばれる書き込み可能なスキーマを用意することです。これにより、ユーザーはさまざまなテーブルスキーマのプロトタイプを作成できます。ただし、クエリの実行中に十分な空き容量がないと、データウェアハウスのクエリ操作全体のパフォーマンスが低下するという課題に直面することがあります。新しいスキーマクォータ機能を使用すると、「tmp」スキーマにストレージクォータ上限をプロビジョニングして、ストレージの容量不足を未然に防ぐことができます。Amazon Redshift が提供するすべての自律型の機能を心待ちにしています」。 多くの組織がセルフサービス分析に移行しており、さまざまなペルソナが進化するデータの量、多様性、速度について独自の洞察を得て、加速するビジネスに対応しています。このデータの民主化により、データガバナンスを実施し、コストを管理し、データの誤管理を防ぐ必要が生じます。さまざまなペルソナのストレージクォータを制御することは、データガバナンスとデータストレージ運用にとって大きな課題です。この記事では、異なるペルソナごとに Amazon Redshift ストレージクォータを設定する方法を示します。 前提条件 このチュートリアルを開始する前に、次のものが必要です。 Amazon Redshift クラスター。us-east-1 […]

Read More

Amazon Neptune、Amazon Comprehend Medical、および Tom Sawyer グラフデータベースブラウザを使用して COVID-19 の科学的研究を探索する

COVID-19 は人類に襲いかかった世界的な危機です。症状、治療法、危険因子など、ウイルスのあらゆる側面に関する識見を高めるために、大規模な研究が行われています。救援活動を支援するために、AWS は一般公開の COVID-19 データレイクを作成しました。これには、パンデミックとの戦いに役立つさまざまなデータセットが含まれています。詳細については、「COVID-19 データの分析用のパブリックデータレイク」と「AWS COVID-19 パブリックデータレイクの探索」を参照してください。 コロナウイルスに関するデータは研究用の出版物で大量に見つけることができます。データレイクのデータセットの 1 つは、このような出版物の大規模なコーパスで、アレン人口知能研究所が集約して更新しています。問題は、必要な情報を見つけて抽出する方法にあります。 この記事では、ナレッジグラフを用いてこの問題を解決する方法について説明します。 Amazon Neptune は、高速で信頼性が高い、完全マネージド型グラフデータベースサービスであり、高度に接続されたデータセットと連携するアプリケーションの構築と実行を容易にします。Neptune の中核にあるのは、何十億もの関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用の高性能グラフデータベースエンジンです。Neptune は、一般的なグラフモデルである Property Graph と W3C の RDF、およびそれぞれのクエリ言語である Apache TinkerPop Gremlin と SPARQL をサポートしています。これにより、高度に接続されたデータセットを効率的にナビゲートするクエリを簡単に構築できます。このチュートリアルでは、プロパティグラフを作成し、Apache TinkerPop Gremlin を使用してデータをクエリします。 高度に接続されたネットワークを評価するには、多くの場合それを見る必要があります。Neptune と合わせて使える優れたアプリケーションが、Tom Sawyer Software です。Tom Sawyer グラフデータベースブラウザでは、グラフデータベースに格納されているデータを簡単に表示して操作できます。これは、Amazon Simple Storage Service (Amazon S3) から Neptune にデータを直接インポートできるエンドツーエンドの視覚化アプリケーションであり、コマンドラインツールが不要になります。データベースに接続してすぐにデータの探索、グラフ要素のプロパティの検査、ノードとエッジの外観の変更をニーズに合わせて行えます。 グラフデータベースは、データを接続するのに優れています。これは、単に研究出版物を保存するだけでなく、意味的に重要なデータをリンクして、興味深い関連情報を明らかにするクエリを作成できます。この記事では COVID-19 Open Research Dataset を使用しています。これには、何万もの論文と、著者、発行日、ジャーナル、デジタルオブジェクト識別子などの関連メタデータが含まれています。一般的な著者や引用に基づいて論文をリンクできるため、このメタデータはグラフに適しています。 ただし、このユースケースでは、内容に基づいて論文をリンクする必要があります。意味的に論文をリンクするのは難がありますが、幸い、必要なものを正確に提供するツールがあります。Amazon Comprehend Medical […]

Read More

Amazon ElastiCache Redis のクラスターを適切にサイジングする際に考慮すべき 5 つのワークロード特性

 この投稿では、Amazon ElastiCache ワークロードに適したノードサイズとクラスタートポロジを決定するプロセス、および考慮すべき重要な要素について説明します。この投稿は、Redis とそのコマンドについて十分な知識があり、Amazon ElastiCache for Redis とオンラインでのクラスターサイズ変更、スケーリング、Amazon EC2 から ElastiCache へのオンラインでの移行、汎用およびメモリ最適化ノード、強化された I/O などの機能を理解していることを前提としています。 基準の推奨事項 エントリーレベルの小規模 (2,000 件以下の TPS と 10 GB 以下のデータサイズ) とおよび規模 (TPS が 2,000〜20,000 件、データサイズが 10 GB〜100 GB) のキャッシュワークロード (一時的なスパイクも発生する可能性があるものを含む) 使用中は、次世代の汎用バースト可能 T3 標準キャッシュノードである T3 ファミリーからキャッシュノードを選択します。ワークロードに ElastiCache を使い始めたばかりの場合は、無料利用枠の T3.micro キャッシュノードから始めてください。負荷を増やすと、T3.medium キャッシュノードまで増加できます。 最新ノードタイプは最新世代の CPU とネットワーク機能をサポートしているため、中規模から大規模 (20,000 の TPS と100 GB のデータサイズを超える) ワークロードの場合は、M5 または […]

Read More

Oracle Active Data Guard を使用した Amazon RDS for Oracle によるマネージド障害復旧とマネージドリーダーファーム

 多くの AWS ユーザーは、Amazon Relational Database Service (Amazon RDS) ポートフォリオのマネージドデータベース製品を利用して、日々の活動から均一な重労働を多く取り除いています。Amazon RDS for Oracle を使って、Oracle データベースの管理と保守にかかる管理費用を大幅に削減できます。 Amazon RDS for Oracle は、マルチ AZ 配置オプションを提供し、特定の AWS リージョン内のデータベース (DB) インスタンスの可用性と耐久性を強化しています。これは、多くの場合、ほとんどの顧客ユースケースに効果的な障害復旧 (DR) ソリューションです。ただし、ミッションクリティカルなデータベースを実行している一部のお客様は、異なる AWS リージョンにまたがる DR 構成のビジネス要件を抱えています。同時に、これらのお客様は DR への投資を活用して、本番環境の読み取りワークロードの一部を処理できることを望んでいます。 現在、Amazon RDS for Oracle のセルフマネージド DR ソリューションは、次のいずれかを使用して実装できます。 DB スナップショットを使用して、Amazon RDS for Oracle に低コストのクロスリージョン DR を実装します。詳細については、DB スナップショットと AWS Lambda を使った Amazon RDS […]

Read More