Amazon Web Services ブログ

Category: Database

DataSunrise Security を使用して Amazon Redshift の PII データを保護および監査する

 DataSunrise は、自社の説明によると、各種のデータベースのためのデータマスキング (動的および静的マスキング)、アクティビティモニタリング、データベースファイアウォール、および機密データ検出を含む、幅広いセキュリティソリューションを提供するデータベースセキュリティソフトウェア企業です。目標は、外部および内部の脅威と脆弱性からデータベースを保護することです。お客様はしばしば、DataSunrise Database Security を選択します。これは、Amazon Redshift、Amazon Aurora、すべての Amazon RDS データベースエンジン、Amazon DynamoDB や Amazon Athena など、AWS で実行するさまざまなデータベースエンジンを保護するときに、統一された制御とシングルユーザーエクスペリエンスを提供するからです。DataSunrise Security Suite は、Amazon Redshift の PII データを保護および監査できるツールのセットです。 DataSunrise は、アクティブなデータとデータベースセキュリティに加えて、データ監査によるパッシブなセキュリティを提供します。アクティブなセキュリティは、機密データへの不正アクセスの防止、疑わしい SQL クエリのブロック、SQL インジェクション攻撃の防止、またはリアルタイムでのデータの動的なマスキングと難読化などの事前定義されたセキュリティポリシーに基づいています。DataSunrise は、高可用性、フェイルオーバー、および Auto Scaling を備えています。 この記事では、Amazon Redshift のアクティブなセキュリティ、特に個人情報 (PII) のマスキングとアクセス制御に関する DataSunrise の機能に焦点を当てています。これは、機密情報へのアクセスの監査など、DataSunrise のパッシブなセキュリティ機能でバックアップできます。この記事では、Amazon Redshift の DataSunrise セキュリティ、その仕組み、および開始方法について説明します。 Amazon Redshift にアクティブなセキュリティが必要な理由 Amazon Redshift は、世界中で 15,000 を超えてデプロイされた、完全マネージド型のペタバイト規模のデータウェアハウス (DW) […]

Read More

大規模な Amazon DynamoDB テーブルに適切なシャード数の選択

一般的な設計のベストプラクティスとして、アプリケーションをテーブル内のすべての論理パーティションキーとインデックス全体での均一な読み込みと書き込みアクティビティのために設計することによって、Amazon DynamoDB のスループットキャパシティーを最大限に活用することができます。このような設計により、テーブルのキャパシティーを過剰に消費する可能性があるホットパーティションの発生を防ぐことができます。 書き込みアクセスをパーティション全体に均等に分散させる 1 つの方法は、パーティションキースペースを拡大させることです。この戦略は、パーティションキーに追加のサフィックスを付加して、基盤となるパーティション全体での配分を向上させるもので、書き込みシャーディングと呼ばれます。 しかし、このアプローチは、いくつかの興味深い設計面での疑問を生じます。いつシャーディングを検討すればよいのか? パーティションキーごとに何個のシャードを作成するべきなのか? シャードをいつ作成するのか? シャード数をスケールするにはどうすればよいのか? シャーディングは読み込みおよび書き込みパターンにどのように影響するのか? この記事では、複合プライマリキー (パーティションキーとソートキー) が存在する DynamoDB テーブルのための動的な書き込みシャーディングのメカニズムを説明します。このメカニズムは、書き込みスループットの需要の増加に基づいてパーティションキーに新しいシャードを臨機応変に追加することによって、DynamoDB テーブルの書き込みキャパシティーを最適化できるようにしてくれます。 パーティション、キー、および書き込みシャーディング DynamoDB は水平分散されたワークロードで能力を発揮します。DynamoDB はテーブルを作成するときに、プロビジョンドスループット要件に対応するために十分なパーティションをテーブルに割り当てます。作成時、DynamoDB はテーブルのキャパシティーを基盤となるパーティション全体に均等に分散します。DynamoDB は、テーブルが作成された後で追加のパーティションをテーブルに割り当てることもあります。詳細については、「パーティションキーを効率的に設計し、使用するためのベストプラクティス」と「パーティションとデータ分散」を参照してください。 DynamoDB は、パーティションに項目を分散するために一貫した内部ハッシュ関数を使用し、DynamoDB が項目を保存するパーティションは項目のパーティションキーによって決定されます。同一のパーティションキーを共有する項目のグループ (コレクションと呼ばれます) は、コレクションがパーティションのストレージ容量を超える場合を除き、同じパーティションにマップされます。 さらに、単一のパーティションが複数のコレクションに関連付けられた項目を保持する場合があります。同じパーティションにマップされた 1 つ、または複数のコレクションに対する過剰な書き込みアクティビティは、ホットパーティションの原因になります。ホットパーティションとは、集中的な読み込みおよび書き込みアクティビティが、パーティションのプロビジョンドキャパシティー、またはパーティションの最大キャパシティーを超え、キャパシティーエラーを生じる場合のことです。 これらのキャパシティーエラーは、プロビジョンドキャパシティーモデルにおける ProvisionedThroughputExceededException、およびオンデマンドキャパシティーモデルにおける InternalServerError によって識別されます。同じコレクションの項目が同じ基盤となるパーティションにマップされるため、これらのキャパシティーエラーは大規模なコレクションで発生する可能性が高くなります。詳細については、「エラー処理」および「読み込み/書き込みキャパシティーモード」を参照してください。 書き込みシャーディングとは、コレクションを効率的に DynamoDB テーブルのパーティション全体に分散させるメカニズムです。これは、パーティションキーに対する書き込み操作を複数のパーティションに分散させることによって、パーティションキーあたりの書き込みスループットを向上させます。このため、個々のパーティションキーの書き込みスループットが基盤となるパーティションのキャパシティーを超過してもよくなり、DynamoDB のパーティションレベルでのキャパシティーエラーが最小限に抑えられます。 さらに、書き込み操作を DynamoDB のパーティション全体に分散させることによって、パーティションのキャパシティーがより均等に使用されます。これはテーブルのキャパシティーのより効率的な使用につながり、コストが削減されます。 書き込みシャーディングは、パーティションキーにシンプルな値のサフィックスを付加することによって、クライアント側から実装することができます。サフィックスの付加による書き込みシャーディングは、パーティションキーに対する 1 バイトの変更でさえも内部ハッシュ関数での異なる出力の生成につながり、項目を異なるパーティションに置くために効率的です。詳細については、「書き込みシャーディングを使用してワークロードを均等に分散させる」を参照してください。 DynamoDB は、一時的な需要のバーストを緩和するバーストキャパシティー、および不均等なアクセスパターンに合わせてパーティション間のキャパシティーを再利用するアダプティブキャパシティーの機能をネイティブに提供します。書き込みシャーディングは、DynamoDB のパーティション全体にトラフィックを均等に分散させるための補完的なメカニズムです。 事前に設定された数のシャードを使った書き込みシャーディングの例 シャーディングすると良いテーブルの例は、ファイルシステムの監査ログです。ここでのパーティションキーはファイルパス、ソートキーはアクセスタイムスタンプになります。このファイルの人気が極度に上がり、頻繁に共有されるようになった場合、単一の DynamoDB パーティションが過剰な数の書き込みリクエストを受けます。 以下の表は、3 つの異なるシャーディングスキームに出現する同一の項目を示しています。 最初のメソッドでは、データが […]

Read More

Amazon Aurora PostgreSQL から通知を送信する

企業のお客様は、Amazon Aurora PostgreSQL データベースで多くの日々のバッチジョブを実行し、そのようなジョブを完了した後にアクティビティを追跡するためにメールやテキストなどの通知方法が必要です。Aurora PostgreSQL はマネージドサービスであるため、セキュリティ上の理由から pgsmtp や pgplpythonu などのデータベース拡張機能へのアクセスを制限しています。これにより、他の自動メッセージングの手段で通知を送信するデータベースの必要性が高まります。 この記事では、組織が定期的にビジネス検証のために従業員の情報をプルし、ジョブの完了後に通知を必要とするシナリオを使用します。この記事では、Python を使用してサンプルジョブを作成し、AWS Lambda と Amazon SNS を使用して、E メールまたはテキストメッセージで通知する方法を示します。 前提条件 このソリューションには以下が必要です。 適切な AWS のサービスにアクセスできる有効な AWS アカウント。 Aurora PostgreSQL データベース。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。 VPC の外部に通知を送信するための、SNS の VPC エンドポイント。詳細については、「Amazon SNS の Amazon VPC エンドポイントの作成」を参照してください。 データベースに接続するための pgadmin または PSQL Client ツールなどのクライアントツール。 AWS Secret Manager にすでに設定および保存されているデータベースパスワード。詳細については、「AWS Secrets Manager とは」を参照してください ソリューションアーキテクチャ […]

Read More

Amazon RDS で詳細なバックアップストレージ請求をサポート開始

 最近、AWS は、Amazon RDS の詳細なバックアップストレージ請求機能を一般提供することを発表しました。この機能は、PostgreSQL、MySQL、MariaDB、Oracle、および SQL Server データベースのエンジンに適用されます。この機能がリリースされる前の Amazon RDS バックアップ料金は、毎月の請求書のリージョンごとに単一行の項目として提示されていました。ただし、毎日の自動データベースバックアップと手動 DB スナップショットの両方による Amazon RDS バックアップ請求料金の内訳は理解が困難でした。今後は、AWS Cost Explorer および Cost and Usage Report (CUR) で、コストアロケーションタグに基づいて Amazon RDS バックアップストレージの請求を表示できます。 このブログ投稿では、Amazon RDS データベースインスタンスにタグ値を設定し、コストアロケーションダッシュボードでこれらのタグをアクティブにし、AWS Cost Explorer と CUR で詳細なバックアップストレージ請求コストを表示する方法を示します。 設定 AWS マネジメントコンソールにログインしたら、Amazon RDS バックアップストレージ請求を表示するように設定するために、簡単なステップがいくつか必要です。DB インスタンスに既にタグが付いている場合は、RDS コンソールから、または AWS Cost Explorer から直接開始できます。 ステップ 1: Amazon RDS コンソール、AWS CLI、または API を介して […]

Read More

AWS Step Functions および AWS Glue を使用した Amazon Redshift ベースの ETL ワークフローのオーケストレーション

 Amazon Redshift は、ペタバイト規模の完全マネージド型クラウドデータウェアハウスサービスで、現在お使いのものと同じ SQL ベースのツールとビジネスインテリジェンスアプリケーションを使用した迅速なクエリパフォーマンスを提供します。お客様の多くは、既存の SQL ベースのスクリプトを素早く移行するために既存の SQL 開発者スキルセットを使用する ETL (抽出、変換、ロード) エンジンとして Amazon Redshift を利用しておられると共に、Amazon Redshift が完全に ACID 対応であることから、ソースデータシステムからの変更データを統合するための効率的なメカニズムとしても利用しておられます。 この記事では、AWS Step Functions および AWS Glue Python Shell を使用して、完全にサーバーレスな方法でこれらの Amazon Redshift ベースの ETL ワークフローのタスクをオーケストレーションする方法をご紹介します。AWS Glue Python Shell は、SQL クエリを送信して応答を待つといった小規模から中規模の ETL タスクを実行するための Python ランタイム環境です。Step Functions は、一連の ETL タスクを簡単に実行して監視できるように、複数の AWS サービスをワークフローにまとめることを可能にします。AWS Glue Python Shell と Step Functions […]

Read More

Amazon DocumentDB と Amazon ElastiCache を使用したパフォーマンスのためのキャッシング

技術の世界で、キャッシュはどこにでもあるものです。CPU は L1、L2、および L3 キャッシュを使用し、携帯電話はアプリのデータをローカルにキャッシュします。ストリーミングサービスはエッジでコンテンツをキャッシュし、ブラウザーは画像をキャッシュするなどです。 同じことは、データベースにも言えます。 もし、ゲームのサイトで、毎回リーダーボードが表示され、そのたびに、クエリが合計を行い、ゲームのすべてのプレーヤーをソートする必要があったらどうでしょうか。または、eコマースのサイトに行くたびに、特定の製品の価格をそれぞれの顧客のディスクから読み取らなければならないとしたらどうでしょうか。パフォーマンスは受け入れがたいものであり、コンピューティングの量でコストはかなり高額になります。 データベースで、キャッシングの主な動機として、パフォーマンスとコスト節約の 2 つが挙げられます。ミリ秒のパフォーマンスでは十分ではないときにマイクロ秒のパフォーマンスを求める場いいでも、一般的に使用されるデータをキャッシングすることにより、データベースから費用のかかる運用を外したい場合などです。 ソリューションの概要 この記事では、Amazon DocumentDB (MongoDB 互換性を使用) および Amazon ElastiCache を統合して、マイクロ秒の応答時間を達成し、コスト全体を減らす方法を示します。次の図では、この記事のソリューションに対するアーキテクチャを示しています。 この例の運用データベースは、Amazon DocumentDB です。これは高速で信頼性があり、容易にクラウドでの Mongo DB互換のデータベースをセットアップ、運用、およびスケールすることができる完全管理型のデータベースです。Amazon DocumentDB で、MongoDB で使用しているものと同じアプリケーションコードを実行し、同じドライバ、およびツールを使うことができます。 Amazon DocumentDB の柔軟性のあるドキュメントモデル、データタイプ、インデックス作成機能を使用して、コンテンツを素早く、直感的に保管し、クエリすることができます。たとえば、ショッピングサイトやカタログのユーザーレビューやでもビデオ、POS 端末の在庫リスト、トレーディングプラットフォームの財務取引などです。 キャッシングレイヤーの場合、Amazon ElastiCache を使用します。これは、AWS の分散型メモリ内キャッシュ環境を容易にセットアップ、管理、スケールできるようにします。ElastiCache は高いパフォーマンス、サイズ変更可能で、コスト効率の良いメモリ内キャッシュを提供する一方で、分散型キャッシュ環境のデプロイと管理に関連付けられた複雑性を排除します。ElastiCache は、Redis と Memcached エンジンの両方と互換性があります。 気に入った歌を見つけることができるようにするアプリケーションを構築することにより、これらの 2 つのサービスを統合する方法を示します。REST API クライアントを使用して、アプリケーションのエンジンに歌のタイトルを送信します。 アプリケーションエンジンは、要求された歌の歌手の名前と可視を含むドキュメントを ElastiCache レイヤーから取得することにより、API 要求を処理します。その歌の要求がすでに前もってあった場合、ElastiCache による読み取りが行われます。そうではない場合、アプリケーションエンジンは Amazon DocumentDB にクエリし、要求されたドキュメントを JSON ドキュメントとしてアプリケーションに返します。 […]

Read More

AWS DMS でのテーブルマッピング作成の自動化

AWS Database Migration Service (AWS DMS) を使えば、オンプレミスデータベースを AWS に迅速かつ安全に移行できます。同種間だけでなく、異種間の移行もサポートしています。移行の実行中やテスト中でも、ソースデータベースは稼働を続けます。移行は、DMS レプリケーションサーバー、ソース、ターゲットエンドポイント、移行タスクを使って行います。 DMS を使って多くのデータベースを移行したい、そして少数のテーブルだけを選択して JSON ファイルの作成を自動化したいなら、この投稿はお役に立つことと思います。この投稿では、DMS タスクの JSON ファイル作成を自動化するツールについて説明します。 自動化の必要性 DMS は、移行プロジェクトに関連する難しいまたは面倒なタスクを数多く引き継いでくれます。ロギングやエラー処理などの特別な処理を行うとともに、移行するスキーマとテーブルを指定します。 移行タスクには次のものが含まれます。 名前 内容 ソース ターゲットエンドポイント テーブルマッピング この投稿では、特にテーブルマッピングのセクションに焦点を当てています。テーブルマッピングではいくつかのタイプのルールを使用して、データソース、スキーマ、タスク中に発生する変換などを指定します。 テーブルマッピングを指定するには、ガイド付きと JSON の 2 つの異なる方法があります。 ガイド付きの方法では、個々のテーブル名またはワイルドカード文字 (% や ABC%) としてテーブル名を入力できます。移行のために選択したテーブルを含めたり除外したりする必要のあるテーブルが多数ある場合、ガイド付きの方法は時間がかかります。 一方 JSON の自動化オプションは、同じ情報を詳細に入力できます。 この投稿では、Python ツールを使用した JSON ファイル作成の自動化を取り上げています。JSON ファイルは手動で作成できますが、記述されているルールの数によっては扱いにくく、あるいはエラーが発生しやすくなります。 自動化ソリューションの説明 この投稿では Python ベースのツールをご紹介します。これは、入力を CSV ファイルとして受け取り、必要とする除外ルールとアクションルールのコンポーネントを含んだ単一の JSON ファイルを生成します。特定のフォルダーに複数の入力ファイルが存在する場合があります。ツールへ唯一入力できる場所はフォルダーです。 このフォルダー内のすべてのファイルの名前は、include* または […]

Read More

AWS SCT および AWS DMS を使用した移行後のデータベースオブジェクトの検証

データベースの移行は複雑なタスクになりかねません。移行には、ソフトウェアプラットフォームの変更、ソースデータの複雑性の把握、データ損失チェック、既存機能の詳細なテスト、アプリケーションパフォーマンスの比較、およびデータの検証といったあらゆる課題が伴います。 AWS では、移行前チェックリストと移行評価を提供するツールとサービスをいくつかご用意しています。AWS Schema Conversion Tool (AWS SCT) は、既存のデータベーススキーマをひとつのデータベースエンジンから別のデータベースエンジンに変換するために使用できます。AWS Database Migration Service (AWS DMS) は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、およびその他のタイプのデータストアの移行を容易にしてくれます。AWS DMS は、AWS クラウドへのデータの移行、またはオンプレミスインスタンス間 (AWS クラウドセットアップ経由)、クラウドとオンプレミスセットアップとの組み合わせの間でのデータの移行に使用できます。 さらに、AWS はデータベース移行の全体を通じてユーザーをガイドする幅広いドキュメントも提供しています。詳細については、「Oracle データベースの PostgreSQL への移行」を参照してください。 AWS SCT は、スキーマオブジェクトを変換するために役立ち、AWS SCT が PostgreSQL に変換した Oracle コードの割合と、手動で変換する必要があるコードの量を示すレポートを構築します。データベースオブジェクトの移行中は常に、ターゲットデータベースでオブジェクトが欠落している、新しいオブジェクトを作成する、またはソースオブジェクト全体を意図的に無視する可能性のリスクがあります。検証は、移行対象のすべてが正常に移行されたことを顧客に証明するプロセスです。 この記事は、データベースオブジェクトの移行とコードの変換の完了後に、ソース Oracle データベースと PostgreSQL ターゲット間でオブジェクトを検証する方法の概要を説明します。 オブジェクトの検証 問題になるのは、何を検証するかということです。 これを理解するためには、Oracle データベースオブジェクトの異なるタイプと、それらに相当する PostgreSQL データベースオブジェクトのタイプを知っておく必要があります。 以下の表は、Oracle (ソース) データベースのオブジェクトと、対応する PostgreSQL (ターゲット) のオブジェクトのタイプを示しています。DB 変換が正常に行われたことを確認するには、これらのオブジェクトを詳細に検証しなければなりません。 Oracle オブジェクト […]

Read More

SPARQL explain を使用して、Amazon Neptune のクエリ実行を理解する

 お客様は、AWS 内で使用するサービスの可視性と制御の向上を引き続き求めています。データベースサービスに関しては、お客様からは通常、特定のデータベース内でのクエリの最適化と処理に関する洞察を求めるリクエストを中心に受けています。データベースの開発者と管理者は、ほとんどの場合、データベースクエリ実行プランのアイデアと使用法をすでによく知っています。お客様の議論に動機付けられて、Amazon Neptune に SPARQL クエリの explain 機能が追加されました。 Amazon Neptune は、高度に連結されたデータの保存とクエリのために最適化された、高速で信頼性に優れた完全マネージド型のグラフデータベースで、データ内の接続のナビゲートと活用に依存するオンラインアプリケーションに最適です。 Amazon Neptune は、SPARQL クエリ言語を使用してクエリできる W3C Resource Description Framework (RDF) グラフをサポートしています。また、Gremlin グラフトラバーサルおよびクエリ言語を使用してクエリできる Apache TinkerPop プロパティグラフもサポートしています。 このブログ記事では、新しい SPARQL explain 機能とその使用方法について詳しく説明します。また、この記事の最後に、今日 SPARQL explain を試してみたい人のために、ワークロードと設定の例を示しました。 explain を使用した SPARQL クエリのランタイム動作の理解 SPARQL クエリが Neptune クラスターに送信されると、データベースエンジンはクエリを SPARQL クエリオプティマイザーに転送します。これにより、利用可能な統計とヒューリスティックに基づいてクエリプランが生成されます。オプティマイザーは、個々のトリプルパターンと接続演算子によってクエリを分割し、最適な実行を提供するために自動的に並べ替えます。このタイプの最適化により、クエリ開発者はクエリを評価する最適な順序を考慮する必要がなくなります。 場合によっては、オプティマイザーが選択したトリプルパターン (より一般的には実行プラン) の評価順序についてより多くの洞察を得たい場合があります。ここで、新しい SPARQL explain 機能の出番です。生成された評価プランを検査して、実行順序を理解できるためです。 クエリ explain 出力は、追加パラメータ「explain=<MODE>」を HTTP リクエストに追加するだけで取得できます。 次の curl […]

Read More

Aurora PostgreSQL ストレージの I/O コストを削減

多くの企業における IT 部門では、オンプレミスのワークロードをクラウドに移行することの最大の理由の 1 つがコスト削減となっています。今回の記事では、コスト管理についての実例を、Amazon Aurora PostgreSQL のチューニングに着目しながらご紹介していきます。 ヒストリー 私は最近、当社の自動車向けテレマティクスアプリケーションの、AWS への実装作業を指揮するという機会に恵まれました。少し説明しますと、テレマティクスアプリケーションとは、データ提供者から運転データをストリーミングで受信するものです。このデータは、検証、修正、および正規化されます。そして、処理に合わせた変換が行われた後、専用のスコアリングアルゴリズムを用いて、ドライバーの点数付け計算に使われます。このプロジェクトには、次に示す主要な目的がありました。 高い可用性 (HA) の実現 (99.999%) 。 レスポンスタイプは、数ミリ秒台という高いパフォーマンスの実現。 現状の TCO をその何割かまでに削減する。これには、人的および設備的なリソースの削減も含まれます。 実際の使用量を反映した、従量課金制の支払に移行する。 国や地域を問わず、デプロイと新規顧客の受け入れを容易にする。 規模の拡大と需要変動に適応できる、スケーラビリティと伸縮性の獲得。 コストと HA での目標を達成するため、アプリケーションはサーバーレス/マネージド型のアーキテクチャを用いて、ゼロから再設計と再コーディングが行われました。これにより、保守に必要なリソースの最小化と従量課金制の利用がはかられましたこの再設計は、ほとんどの目的を達成し大きな成功となりましたが、コストだけに問題が残りました。オンプレミスに比べればコスト削減ができたものの、依然として想定した金額の 3 倍の金額になってしまったのです。 概要 他のどの変更作業と同様に、オンプレミスから AWS への移行要素には、次の 3 つが含まれます。 人材 処理 テクノロジー 個人的には、人材の要素がキーになると思います。オンプレミス環境とは違い、AWS でのインフラストラクチャーのコストは、いわゆる埋没費用ではありません。AWS での運用コストは、サービス利用量をベースに変化するからです。この利用量には、サービスの実行/経過時間だけでなく、メモリー、ストレージ、I/O といった、サービス毎に違いがうまれるものの利用も含まれます。AWS での課金手法になじむには、少し時間がかかることもあります。作業の工程の見直しやサービスの自動化は、AWS の環境が提供するメリットを活用するための重要なポイントです。 AWS を利用する上でのコスト削減の取り組みは、次のようなステップにグループ分けされます。 AWS のコストを理解する: まず始めに、請求管理ダッシュボードの使用になれることです。それぞれのサービスが、AWS のコストにどの程度影響しているかを理解します。タスクを優先付けするために、まず上位 3 つの高コスト要件に取り組みます。また最終的には、これらの検証がコスト面での重要性だけでなく、セキュリティーの抜け道を洗い出す目的にも重要となります。 ハウスキーピング: サーバーレスでマネージド型のサービスに移行するからといって、データのクリーニングやアプリケーションの保守のためにオンプレミスで行ったベストプラクティスが完全に不要になるわけではありません。むしろ、そういった作業はより厳格に行う必要が生まれます。 アプリケーションとサービスの低い機能を特定し調整します。 詳細情報 […]

Read More