Amazon Web Services ブログ

Category: Database

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

Amazon RDS for SQL Server での Microsoft SQL Server Reporting Services の設定

Microsoft SQL Server Reporting Services (SSRS) を Amazon Relational Database Service (RDS) for SQL Server DB インスタンスで直接実行できるようになりました。SSRS は、SQL Server 2017 Standard または Enterprise エディションの シングル AZ またはマルチ AZ インスタンスでアクティブ化できます。SSRS を Amazon Elastic Compute Cloud (Amazon EC2) で実行する場合は、SSRS を Amazon RDS for SQL Server で直接実行することによってコストを節約できるようになります。Amazon RDS for SQL Server は、SQL Server データベースと同じ RDS DB インスタンスで Report […]

Read More

PostgreSQL の行レベルのセキュリティを備えたマルチテナントデータの分離

Software as a Service (SaaS) プロバイダーには、基本的にテナントデータの分離を適用する責任があります。テナントの 1 つが別のテナントのデータにアクセスした場合、信頼はなくなり、ビジネスのブランドに永久的な損害を与える可能性があるだけでなく、さらにひどい場合には、ビジネスを失う可能性があります。 リスクが非常に大きいため、効果的なデータの分離を計画することが重要です。マルチテナントアーキテクチャは、各テナントのリソースをレプリケートするのではなく、すべてのテナントのデータストレージリソースを共有することで、俊敏性と運用コストを節約します。しかし、共有モデルで分離を適用することは難しいため、マルチテナントデータモデルで妥協して、テナントごとにコストがかかるデータベースのオプションに戻すことが可能です。 多くの場合、共有データベースモデルはソフトウェア開発者に依存しているため、記述してあるすべての SQL ステートメントで適切なチェックを実装することが唯一の選択となります。他のセキュリティ上の懸念事項と同様に、日常的なソースコードの変動性にあまり依存しないより一元的な方法で、テナントデータの分離ポリシーを適用するのがよいでしょう。 この投稿は SaaS アーキテクトと開発者を対象としており、テナントの共有データベースの利点を享受しながら一元型分離の適用を実現する方法について解説しています。 データパーティション分割のオプション マルチテナントシステムで使用する一般的なデータパーティション分割モデルには、サイロ、ブリッジ、プールの 3 つがあります。各モデルの分離方法には、それぞれ長所と短所があります。 サイロ – テナントごとに個別のデータベースインスタンスを使用すると、分離はたいていインフラストラクチャコストが高くなるだけでなく、テナントのセットアップがより複雑になります。これは、SaaS のサービスにオンボードする各テナントに、新しいデータベースインスタンスを作成および管理する必要があるためです。 ブリッジ – テナントデータをパーティション分割する 2 つ目のアプローチは、同じデータベースインスタンスを共有しながら、テナントごとに異なるスキーマを使用する方法です。リソースを共有することでモデルのコストを削減できますが、メンテナンスとテナントのセットアップはかなり複雑になる可能性があります。 プール – 3 つ目のパーティション分割モデルは、共有データベースインスタンスと名前空間の両方を使用するものです。この設計ではすべてのテナントデータを並べて表示しますが、各テーブルまたはビューには、データのフィルターに使用するパーティション分割キー (通常はテナント ID) が含まれています。 プールモデルは運用コストが最も節約でき、インフラストラクチャコードとメンテナンスのオーバーヘッドを削減します。ただし、このモデルはデータアクセスポリシーを適用するのが難しい場合があり、通常は、すべての SQL ステートメントに正しい WHERE 句を実装することが望まれます。 マルチテナントデータのパーティション分割の詳細については、次の AWS SaaS Factory ホワイトペーパーをご参照ください。 行レベルのセキュリティ RDBMS 分離ポリシーの適用をデータベースレベルで一元化することにより、ソフトウェア開発者の負担を軽減できます。このため、プールモデルの利点を活用し、かつテナント間のデータアクセスのリスクを軽減できます。 PostgreSQL 9.5 以降には、行レベルセキュリティ (RLS) と呼ばれる機能が含まれています。テーブルにセキュリティポリシーを定義すると、これらのポリシーが、SELECT クエリによって返されるそのテーブルの行、または INSERT、UPDATE、DELETE […]

Read More

Amazon DocumentDB (MongoDB 互換) について知っておくべき 12 のこと

Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする、高速かつスケーラブルで可用性に優れたフルマネージド型のドキュメントデータベースサービスです。お客様は、基盤となるインフラストラクチャの管理を気にすることなく、現在ご使用のものと同じ MongoDB 3.6 向けのアプリケーションコード、ドライバー、ツールを、そのまま Amazon DocumentDB 上でワークロードを実行、管理、そしてスケールするのに使えます。ドキュメントデータベースである Amazon DocumentDB は、JSON データの保存、クエリ、およびインデックスを容易にします。 AWS は、可用性、信頼性、耐久性、スケーラビリティ、バックアップなどに関するお客様の課題を独自の方法を用いて解決するために Amazon DocumentDB を構築しました。その過程において、当社は、付加価値を生まない手間のかかる作業を取り除き、コストを削減するために、いくつかの斬新でユニークな機能を構築しました。この投稿では、Amazon DocumentDB で MongoDB ワークロードを構築およびスケーリングするのに役立つ、まだ認識されていないかもしれない 12 の Amazon DocumentDB 機能を紹介します。 1.最新のクラウドネイティブアーキテクチャ Amazon DocumentDB は、クラウドネイティブのデータベースアーキテクチャを使用してゼロから構築されました。独自のアーキテクチャによりストレージとコンピューティングが分離されているため、各レイヤーを個別に拡張できます。Amazon DocumentDB は、3 つの AWSアベイラビリティーゾーン (AZ) にまたがって 6 つの方法でデータをレプリケートすることで高可用性と耐久性を備えた、フォールトトレラントな分散型の専用自己修復ストレージシステムを使用しています。詳細については、YouTube のAWS re:Invent 2019: Amazon DocumentDB の詳細の動画をご覧ください。次の図は、Amazon DocumentDB アーキテクチャにおけるコンピューティングとストレージの分離、およびデータが 3 つの AZ にまたがって 6 […]

Read More

Amazon RDS for PostgreSQL で高速リフレッシュ機能を構築する

この記事は CDL によるゲスト投稿です。CDL は自社を次のように紹介しています。「CDL は英国を拠点とする主要なインシュアテック企業であり、Financial Times 誌の業界に影響を与えている高成長の英国企業 Future 100 のリストに掲載されています。保険と金融サービスの分野で強力な実績を残し、そのソリューションは英国で最も収益性の高い保険代理店を支えています。 CDL はシステム上で 700 万件を超える保険契約を取引し、Sainsbury’s Bank、Tesco Bank、Swinton Insurance、Moneysupermarket.com などをクライアントに抱えています」 この記事では、CDL が Amazon RDS for PostgreSQL のマテリアライズドビューログをどう使って高速リフレッシュ機能を開発したかについて説明します。変更を追跡するために構築したものを詳述し、完全リフレッシュに代わる代替手段を示します。これにより、必要な時間が数時間から数秒に短縮されました。また、高速リフレッシュを可能にするためのオープンソースソフトウェアをより広い PostgreSQL コミュニティと共有し、関連するインストールプロセスの概要を示します。 課題 CDL は毎日数百万のトランザクションを処理しています。当時はビジネスインテリジェンス (BI) プラットフォームを Oracle から PostgreSQL に移行することを検討していました。切り替えを実際に行うには、お客様が最新のビジネスインテリジェンスへ引き続きアクセスできるようにするため、リレーショナルデータベースでこの大量の変更を処理し、ほぼリアルタイムでリフレッシュする必要がありました。 PostgreSQL は完全リフレッシュ機能のみを備えています。けれども、Google のサービスレベルアグリーメントでは 15 分ごとにデータをリフレッシュする必要があります。そして CDL は大量の変更を処理していることから、完全リフレッシュプロセスではこのタイムスケール内でこの規模のマテリアライズドビュー (MV) を処理することは不可能でした。当社の最大の MV ログは 150 GB を超えており、完全リフレッシュプロセスでは構築するのに何時間もかかります。またお客様によっては、1 日あたりのビュー数が 150 回を超える方もいらっしゃいます。 当社は、BI ソリューションの MV […]

Read More

Amazon RDS for SQL Server での Microsoft SQL Server Integration Services の使用

Microsoft SQL Server Integration Services (SSIS) を Amazon Relational Database Service (RDS) for SQL Server 上で定義できるようになりました。SSIS は、シングル AZ およびマルチ AZ の DB インスタンスにおいて Standard および Enterprise のエディションで機能します。使える SQL Server は、2016 もしくは 2017 の メジャーバージョンです。 従来も、RDS for SQL Server を SSIS のターゲットソースとして使用できましたが、SSIS を RDS for SQL Server データベース自体と同じサーバー上で動作させることはできませんでした。現在でも SSIS は Amazon Elastic Compute Cloud (Amazon EC2) […]

Read More

Amazon RDS および Amazon Aurora for PostgreSQL データベースの一般的な管理者の責任

アマゾン ウェブ サービス (AWS) は、完全マネージド型のリレーショナルデータベースサービスとして、Amazon Relational Database Service (RDS) および Amazon Aurora を提供します。コマンドをいくつか使用するだけで、本稼働データベースのインスタンスを AWS で起動して実行することができます。 オンラインデータベースを使用すれば、データベース管理者 (DBA) は多くのメンテナンスタスクや管理タスクから解放されます。ただし、注意すべき重要な責任がいくつかあります。この記事では、PostgreSQL との互換性のあるデータベースを備えた Amazon RDS for PostgreSQL および Aurora で実行するための DBA タスクについて説明します。 DBA として、お客様はさまざまな分野でビジネスに価値を提供するという日々のプレッシャーに直面しています。ミッションクリティカルなデータベースを実行するための適切なプラットフォームを維持することは、ますます困難になってきています。メンテナンスも、課題の多い作業です。 Amazon RDS と Aurora のリリースにより、インストール、構成、モニタリング、セキュリティなどのタスクに費やす時間は大幅に短縮されました。それでも、複数の重要なタスクを実行する必要はあります。そのいくつかは毎日または週に数回実行し、またいくつかは Amazon RDS または Aurora のインストール時 (インスタンスの作成時) にのみ実行するものです。 実行する必要がある管理タスクには、以下が含まれます。 パラメータグループの設定 セキュリティ グループを使用した IP トラフィックの管理 データベースログファイルの監査 メンテナンスおよび管理アクティビティ バックアップおよびリカバリ戦略の計画 ユーザー管理 データベースのモニタリング パラメータグループの設定 オンプレミスの […]

Read More

Amazon RDS for PostgreSQL クロスリージョンリードレプリカのためのベストプラクティス

Amazon RDS for PostgreSQL のマネージドサービスのひとつにクロスリージョンリードレプリカがあります。クロスリージョンリードレプリカを使用することで、災害対策ソリューションの確保、データベースの読み込みワークロードのスケーリング、およびリージョン間での移行が可能になります。クロスリージョンリードレプリカは、Amazon RDS コンソール、AWS CLI、または create-db-instance-read-replica API を使用して作成できます。クロスリージョンリードレプリカには、追加のデータ転送料金がかかります。 Amazon RDS はクロスリージョンリードレプリカを容易にしますが、最良の経験を実現するために認識しておく必要がある注意点がいくつかあります。この記事では、以下のトピックに関する Amazon RDS for PostgreSQL クロスリージョンレプリケーションのベストプラクティスを説明します。 クロスリージョンリードレプリカの作成の流れ レプリケーション遅延を最小限化する方法 Amazon RDS for PostgreSQL クロスリージョンレプリカの使用中における一般的な問題 クロスリージョンリードレプリカの作成の流れ クロスリージョンリードレプリカは、Amazon RDS for PostgreSQL のバージョン 9.5.2 以降でサポートされます。クロスリージョンレプリカの作成中、システムは以下のステップを実行します。 ソースインスタンスのスナップショットを作成する。 スナップショットをレプリケーション先のリージョンにコピーする。 ソースとクロスリージョンレプリカ間におけるストリーミングレプリケーションスロットを設定する。 ソースからレプリカへのログ先行書き込み (WAL) のストリーミングを開始する。WAL ファイルは PostgreSQL のトランザクションログです。データ変更は、まず WAL ファイルに記録されてから、永続ストレージに書き込まれます。 Amazon RDS for PostgreSQL のクロスリージョンレプリカは、以下の手順に従うことで最も簡単に作成できます。 Amazon RDS コンソールで、Amazon RDS for […]

Read More