Amazon Web Services ブログ

Category: Database

Amazon RDS for Oracle バージョン 12.2.0.1と11.2.0.4のサポート終了のお知らせ

本投稿は、こちらのフォーラムに投稿された Amazon RDS for Oracle をご利用中のお客様向けアナウンスメントの参考和訳です。 本投稿では、Amazon RDS for Oracle Database 12.2.0.1と11.2.0.4と廃止計画とタイムラインを取り上げています。 Oracle Database 12.2.0.1 廃止計画とタイムライン 2020年4月15日、Oracle 社はサポートを契約しているお客様に対してOracle Database 12.2.0.1のLimited Error Correction (限定的なエラー修正) を2022年3月31日まで追加料金なしで提供すると発表しました[1]。Oracle Database 12.2.0.1のこの新しいサポート・タイムラインに基づき、Amazon RDS for Oracle では、全エディションのlicense-included(LI) とBring-your-own-license(BYOL) でこのバージョンを2022年3月31日までサポートする予定です。Oracle Database 12.2.0.1のLimited Error Correction の期間中、Amazon RDS for Oracle は、Oracle の四半期ごとのリリース・アップデート(RU)に基づいた新しいリリースを提供する予定です。 Extended Support のバージョンでは、BYOL のお客様は、Oracle Support から購入したサポート契約を締結するか、サポート対象バージョンにアップグレードする必要がありますのでご注意ください。BYOL のお客様のライセンスおよびサポート要件の詳細については、Amazon RDS for Oracle のよくある質問 [3]を参照してください。 Oracle […]

Read More

[AWS Black Belt Online Seminar] Amazon Quantum Ledger Database (QLDB) 資料及び QA 公開

こんにちわ、ソリューションアーキテクトのザビオ(@zabbiozabbio)です! 先日 (2020/06/09) 開催しました AWS Black Belt Online Seminar「Amazon Quantum Ledger Database (QLDB) 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20200609 AWS Black Belt Online Seminar Amazon Quantum Ledger Database (QLDB) from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q1. 運用の途中に、ジャーナルのスキーマやテーブル構造が変更される場合もPartiQLによってDDLのような形で保存されるのでしょうか。 はい、すべてのトランザクションは遡ることが可能なので、PartiQLで表現されるDDLや、Amazon ION形式として保存されます。 Q2. Amazon Quantum Ledger Database (QLDB)もチェーンコードを記述できるのでしょうか。 QLDBはDatabaseのためチェーンコードの記述はできません。 Q3. QLDB からエクスポートしたあとの、Transaction IDは固定化するのでしょうか。 従来のものからエクスポートしたものは、固定化されます。TransactioIDや、その他メタデータはそのまま値を引き継ぎます。メタデータについてはこちらを参照ください。 Q4. QLDB のデータ検証はどのように行われるのでしょうか。 Validationの機能を利用することで、いつでも暗号学に基づいたデータ検証が確認できます。 Q5. […]

Read More

Wind Mobility がサーバーレスデータアーキテクチャを構築した方法

Wind Mobility の BI 部門の責任者である Pablo Giner 氏によるゲスト投稿です。 ここ数年、都市部におけるマイクロモビリティが注目を集めています。汚染指数が歴史的な高さとなっていることから、世界中の都市や企業が規制を導入し、状況を改善するための幅広い解決策に取り組んできました。 Wind Mobility では、近距離移動のための都市部における交通手段を世界中の都市に提供することにより、通勤者の生活をより持続可能かつ便利なものにすることに注力しています。 Wind Mobility では、ユーザーの要求に合わせてサービスをスケーリングし、経済的かつ環境的に実行可能な方法でサービスを提供しています。実際に使用される数よりも多くの電動キックボードを配置することで都市が混雑するのを避けるために、電動キックボードがひとまとまりで配置される数を最適化し、ユーザーが必要とする場所の近くに、かつ、ユーザーが必要とするときに電動キックボードを配置します。 これを実現するにはどうすればよいでしょうか? その答えは、業務を最大限に最適化する、ということです。そのためには、さまざまな条件下でのユーザーの行動について十分な情報を得て、まとまって配置される電動キックボードがどの程度の需要に対応できるのかを理解する必要があります。 急成長を支えるスケーラビリティと柔軟性 当社では、この課題を解決するに先立ち、ユーザーによるアプリケーションとのインタラクション、ユーザーの需要、電動キックボードからの IoT 信号、運用メトリクスなど、さまざまなソースからデータを収集する必要があることを認識していました。収集された多数のデータセットを分析し、実用的な洞察を抽出するには、データレイクを構築する必要がありました。大まかな目標は明確でしたが、対象となる範囲はそれほど明確ではありませんでした。新しい市場の開拓を続けつつ、当社は事業の拡大に懸命に取り組んでいました。急速な成長と拡大により、消費する必要のあるデータの量を予測することが非常に困難になりました。また、当社では、成長を支える新しいマイクロサービスを立ち上げました。その結果、より多くのデータソースの取り込みが必要となりました。当社がアジャイルに活動することを実現し、かつ、迅速な採用が可能な、当社の成長に対応できるアーキテクチャが必要でした。サーバーレスアーキテクチャがこれらのニーズを満たすのに最適であることが判明したことから、当社は、完全にサーバーレスのインフラストラクチャの設計を開始しました。 最初の課題は、現場での電動キックボード、モバイルアプリからのイベント、運用メトリクス、およびパートナー API からのデータの取り込みと保存でした。当社は、AWS Lambda を使用して、運用データベースとモバイルアプリの変更をキャプチャし、イベントを Amazon Kinesis Data Streams にプッシュします。これにより、リアルタイムでアクションを実行できます。また、Amazon Kinesis Data Firehose を使用して、当社が分析に使用する Amazon Simple Storage Service (Amazon S3) にデータを書き込みます。 Amazon S3 にアクセスし、最も一般的なユースケースに従って適切にパーティション分割した後 (当社は、データソースに応じて、日付、地域、およびビジネスラインでパーティション化しました)、データプロファイリング (構造、内容、および相互関係の理解のため) およびアドホック分析を行うためにこのデータをクエリする方法を見つける必要がありました。そのために、データをカタログ化するために AWS Glue クローラーを選択し、AWS Glue データカタログから読み取ってクエリを実行するために Amazon Athena […]

Read More

Amazon RDS for SQL Server において SSAS / SSRS / SSIS がサポートされました

SQL Server を利用されているお客様の中には、SQL Server に搭載されている BI 機能、SQL Server Analysis Services (SSAS) / SQL Server Reporting Services (SSRS)  / SQL Server Integration Services ( SSIS ) を利用されているお客様も多いと思います。以前はこれらの機能を利用する際は EC2上に SQL Server を構成する必要がありましたが、Amazon RDS for SQL Server でも利用可能になり(※)、マネージド型サービスならではのメリットを享受できます。有用な情報をまとめましたので、ぜひご活用頂ければと思います。 サポートするバージョン / エディション 【SQL Server Analysis Services】 SQL Server 2016 Standard エディションまたは Enterprise エディション (13.00.5426.0.v1 以降)  か SQL Server 2017 […]

Read More

クラウドへの移行: Blazegraph から Amazon Neptune への移行

グラフデータベースアプリケーションのライフスパン中、アプリケーション自体には基本的な要件、つまり、W3C 標準の SPARQL エンドポイントを機能させることのみが備わっている傾向があります。けれども、グラフデータベースが重要なビジネスアプリケーションに組み込まれるようになると、ビジネスと運用の両面からさらに多くのものが求められるようになります。重要なビジネスインフラストラクチャは、単に機能するだけでなく、可用性が高く、安全で、拡張可能で、費用対効果が優れていることが求められます。これらの要件により、オンプレミスまたはセルフホストソリューションから、Amazon Neptune などのフルマネージドグラフデータベースソリューションへの移行が求められます。 Neptune は、ビジネスクリティカルなグラフデータベースアプリケーションの構築と実行を容易にする、高速で信頼性の高い、フルマネージドグラフデータベースサービスです。Neptune は、数十億の関係を格納し、ミリ秒のレイテンシーでグラフをクエリするように最適化された専用の高性能グラフデータベースエンジンです。Neptune は、リードレプリカ、ポイントインタイムリカバリ、Amazon Simple Storage Service (Amazon S3) への継続的なバックアップ、およびアベイラビリティーゾーン間のレプリケーションにより、高可用性を実現するように設計されています。Neptune は、AWS Identity and Access Management (IAM) 認証、HTTPS 暗号化クライアント接続、および保管時の暗号化をサポートしており、安全です。Neptune は、開発とテストを対象とした低コストインスタンスを含む、さまざまなインスタンスタイプも提供しています。これにより、予測可能で低コストのマネージドインフラストラクチャがもたらされます。 現在のオンプレミスまたはセルフホストのグラフデータベースソリューションから Neptune への移行を選択する場合、この移行を実行するための最良の方法は何でしょうか? この記事では、オープンソースの RDF トリプルストア Blazegraph から Neptune に次の手順を実行して移行する方法を説明します。 AWS インフラストラクチャをプロビジョニングします。まず、AWS CloudFormation テンプレートを使用して必要な AWS インフラストラクチャをプロビジョニングします。 Blazegraph からデータをエクスポートします。この記事では、Blazegraph からデータをエクスポートするための 2 つの主要な方法について説明します。それは、SPARQLCONSTRUCT クエリを使用するか、Blazegraph エクスポートユーティリティを使用する方法です。 Neptune にデータをインポートします。Neptune ワークベンチと Neptune バルクローダーを使用して、エクスポートしたデータファイルを Neptune にロードします。 […]

Read More

AWS Glue ジョブブックマークを使用して、さまざまなデータ取り込み頻度でデータを処理する

データの取り込み頻度がさまざまな複数のデータセットをマージする必要があるデータ処理の要件はよく見られます。これらのデータセットの一部は、一度にすべてが取り込まれ、受信頻度が低く、全体を通して常に使用されます。一方、その他のデータセットは増分で取り込まれ、一定の間隔で受信し、完全なデータセットと結合して出力を生成します。このような要件に対応するため、この投稿では、AWS Glue を使用して抽出、変換、ロード (ETL)パイプラインを構築する方法をご紹介します。 AWS Glue の使用 AWS Glue は、分析のために複数のソースから多数のデータセットを抽出、変換、およびロードするサーバーレス環境を提供します。AWS Glue には、スケジューリングされた間隔でジョブを再実行するときに増分データを処理するジョブブックマークと呼ばれる機能があります。ジョブブックマークは、ソース、変換、ターゲットなど、さまざまなジョブ要素の状態で構成されます。AWS Glue が古いデータを再度処理しないようにするジョブ実行からの状態情報を保持することで、これを実行します。 このユースケースでは、ジョブブックマークが有効になっている AWS Glue ジョブを使用して、さまざまな頻度で受信するファイル(一度に受信するファイルを示す完全なデータセットと、特定の定期的な間隔で受信するファイルを示す増分データセット)を処理します。これらのファイルは、まとめてマージされます。ジョブブックマークを有効にするだけでなく、AWS Glue PySpark 動的フレームでオプションのパラメータ transformation_ctx(変換コンテキスト)も使用します。これは、ETL 演算子インスタンスの一意の識別子として機能するもので、特定の演算子のジョブブックマーク内の状態情報を識別します。AWS Glue は transformation_ctx を使用して、キーをブックマークの状態にインデックス付けします。 変換コンテキストを使用することで、増分データセットの状態情報を取得および維持し、再処理を回避できます。完全なデータセットファイルでは変換コンテキストが省略されるため、完全なデータセットに対するジョブ実行状態情報が取得されず、次の処理イベント全体で使用されます。AWS Glue ジョブレベルでジョブブックマークフラグが有効になっている場合でも、完全なデータセットの変換コンテキストが省略されるため、ジョブを実行するたびに、完全なデータセットのデータ全体がジョブの一部として使用されます。一方で、新しく到着したデータセットのみが増分データセットとして処理されます。 ソリューションの概要 AWS Glue のジョブブックマークのユーティリティをデモするのに、TLC 移動レコードデータのデータセットを使用します。増分データセットとしてニューヨーク市イエローキャブの移動データの月間ファイルを使用し、フルデータセットとしてニューヨーク市のタクシーゾーンルックアップを使用します。月間イエローキャブ移動データには、PULocationID (乗客を拾った場所)という名前のフィールドがあり、ニューヨーク市タクシーゾーンルックアップファイルの LocationID フィールドと結合して、ニューヨーク市のタクシーゾーンルックアップデータセットの Borough、Zone、service_zone と、月間のニューヨーク市タクシー移動データファイルのすべてのフィールド(PULocationID フィールドを除く)を含む出力データセットを作成します。 次の図は、処理のハイレベルアーキテクチャを示しています。 図の説明 2 つの Amazon S3 Raw バケットの場所は、受信 CSV ソースデータ(ニューヨーク市タクシーの月間ファイル(増分データセット)とニューヨーク市タクシールックアップファイル(完全データセット))を格納するのに使用します。 ブックマークを有効にした Glue ジョブは、月間移動データファイルとタクシーゾーンルックアップファイル間のデータを結合して、出力 Parquet […]

Read More

Moovit は、Amazon Redshift クラスターを拡張して毎日何十億ものデータポイントを分析することにより、データレイクアーキテクチャを活用

Amazon Redshift は高速なフルマネージド型クラウドネイティブデータウェアハウスで、標準 SQL や既存のビジネスインテリジェンスツールを使用して、すべてのデータをシンプルかつコスト効率よく分析できます。 Moovit は、Mobility as a Service (MaaS) ソリューションプロバイダーで、都市型モバイルアプリのトップメーカーです。Moovit は、103 か国の 3,200 を超える都市の 8 億人を超えるユーザーに効果的かつ便利に街を歩き回るようにガイドを提供してきて、過去数年間でサービスが飛躍的に成長しました。同社は、1 日あたり最大 60 億の匿名データポイントを収集し、トランジットデータと都市モビリティデータの世界最大のリポジトリに追加します。これは、他では活用されない都市のローカル交通情報をマッピングおよび維持するのを支援する 685,000 人を超える Moovit のローカル編集者のネットワークで支えられています。 Moovit と同様に、今日多くの企業が Amazon Redshift を使用してデータを分析し、データをさまざまな形に変換しています。ただし、データが成長し、さらに重要になるにつれて、企業はデータから貴重な洞察を引き出すためのより多くの方法を模索するようになりました。これには、ビッグデータ分析、多数の機械学習 (ML) アプリケーション、新しいユースケースとビジネスプロセスを促進するさまざまなツールなどがあります。企業はいつでもすべてのデータにどのユーザーもアクセスでき、迅速な回答を得られるようにすることを求めています。これらすべての要件を満たす最適なソリューションは、企業がデータレイクを構築することです。データレイクは、規模を問わず、すべての構造化データ、半構造化データ、および非構造化データを格納できる中央リポジトリです。 Amazon Simple Storage Service (Amazon S3) で構築されたデータレイクを用いると、Amazon EMR や AWS Glue などのサービスを使用してビッグデータ分析を簡単に実行できます。Amazon Athena や Amazon Redshift Spectrum を使用して、構造化データ (CSV、Avro、Parquet など) および半構造化データ (JSON や […]

Read More

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