Amazon Web Services ブログ

Category: Database

オープンソースプラットフォームで ProxySQL を使用して、Amazon Aurora クラスターでの SQL の読み取りと書き込みを分割する方法

ブログ記事Amazon Aurora PostgreSQL で読み書き用に pgpool の単一のエンドポイントを設定する方法では、Amazon Aurora PostgreSQL エンドポイントの読み取りおよび書き込みの分割機能を使用するアーキテクチャを紹介しています。このタイプのアーキテクチャは Aurora PostgreSQL クラスターに最適ですが、データベースに Amazon Aurora MySQL クラスターを使用している場合はどうでしょうか? この記事は、Aurora MySQL エンドポイントで読み取りおよび書き込みの分割を実現するための中間レイヤーとして ProxySQL を紹介することによって、元の記事を補完します。 Amazon Aurora は、プライマリ DB インスタンス (クラスターエンドポイント) と、リードレプリカ (リーダーエンドポイント) のエンドポイントを提供します。Aurora は、クラスタエンドポイントを自動的に更新するので、常にプライマリインスタンスを指し示すようできています。リーダーエンドポイントを使用して、使用可能なすべてのリードレプリカにまたがる読み取り操作のための接続に対して DNS ラウンドロビンを実行します。さらに、Amazon Aurora カスタムエンドポイントを使用して、アプリケーションのトラフィックをさらに分離することができます。 Amazon Aurora Replica では、通常 100 ms 未満のレプリケーションラグが発生します。したがって、アプリケーションで遅延が許容される場合は、以下に示すように、クラスターエンドポイントとリーダーエンドポイントの両方を使用して、水平方向に拡張されたデータベースを利用することができます。 前の図は、使用するエンドポイントを決定するアプリケーションの現在のアーキテクチャを示しています。ただし、読み取り用と書き込み用両方のデータベースエンドポイント管理は、複雑なアプリケーションになります。一部のサードパーティ製ドライバーは、より狭い範囲のユースケースしかサポートしていませんが、この記事のアイデアを読み書きを分割するユースケースにより広く適用することができます。 この記事では、ProxySQL を使って、書き込みトラフィックをクラスターエンドポイントへ、読み取りトラフィックをリーダーエンドポイントに自動的に転送する MySQL 互換の単一 Aurora エンドポイントを構築する方法をご紹介します。以下の図は、ProxySQL ミドルウェアに基づいて提案されるソリューションを示しています。 アーキテクチャ ProxySQL は、MySQL データベースとデータベースクライアント間に存在する、GNU General […]

Read More

LifeOmic の JupiterOne が Amazon Neptune によるセキュリティとコンプライアンス操作を簡素化する方法

LifeOmic の CISO である Erkang Zheng による寄稿です。 ほとんどの組織は、セキュリティ操作に対して線形のリストベースのアプローチを行っています。それは 2 次元のプロセスです。まず、リソースを特定します。次に、設定を管理します。管理用ツールとテクノロジーがセキュリティアナリストに環境の変化について警告を発するため、修復に利用するのが理想的です。 この 2 次元アプローチの問題点は、エンドポイント、脆弱性管理ツール、DevOps とクラウドツール、そしてセキュリティポリシーと手順など、環境におけるさまざまなコンポーネントの関係を接続できないことです。コンテキストがなければ、環境における変化の重要性、重大性、必要性がわかりません。その結果、攻撃を防止するには、問題を取得するために計画された各変更と偽陽性アラートを回避する必要があります。 たとえば、本番環境で重大なリソースを保護する必要があることを知っているとしましょう。指定された管理者が承認済みのメカニズムを介して、そのリソースへのアクセス権を取得しても、問題はありません。しかし、取るに足りない問題を追いかけないようにするために、デバイスに必要なセキュリティ制御を判断するには、どうすれば良いのでしょうか? すべての違いを生み出す関係マッピングでは、2 次元での停止を達成できません。 JupiterOne を使用して、組織の環境内で関係をマッピングすることによって、明確にコンテキストを組み込みました。Amazon Neptune グラフのデータベースサービスを使用してグラフモデルを構築しました。グラフモデルは、何が起こったのかを把握し、それが問題であるかどうかを判断するまでかかる時間を大幅に短縮します。 グラフモデルを入力する 組織が条件を平等にするには、環境の表示を 2 次元から 3 次元に移行する必要があります。そのためには、データと関係のマッピング方法を変更しなければなりません。チェックリストの代わりにグラフを使うことは、この複雑さを有意義に表す唯一の方法です。 JupiterOne を使用して、組織のデジタル環境を完全に捉えたグラフベースの参照データモデルを構築しました。データモデルは、一連のエンティティとその関係によって定義されます。エンティティは、デジタルインフラストラクチャのリソースを表すグラフ内のノードまたは頂点です。関係は、グラフ内の 2 つのエンティティノード間のエッジです。各エンティティと関係には、独自のクラス、タイプ、およびプロパティがあります。 エンティティとその関係の間にある点をつなげると、非常に価値が高く、コンテキストが豊かなインサイトを引き出すことができます。たとえば、このグラフの例では、実際にインターネットに公開されているアクティブな Amazon EC2 インスタンスをすばやく簡単に見分けることができます。 別の例としては、AWS アカウントの内部から外部アカウントへのクロスアカウントで、想定されているロール信頼を強調する場合があります。 いくつかのサイロ化されたサービスとツールでは、排他データへのインサイトを与えることができます。ただし、エンティティ関係グラフは、組織のインフラストラクチャ全体を取り扱うように設計されています。これには、脆弱性、イベント、アラートなどのセキュリティ制御とその検出結果だけでなく、ネットワーク、サーバー、エンドポイント、データリポジトリ、クラウドサービス、一連のアプリケーションとソフトウェア開発ツール、ユーザーと ID が含まれます。データは Amazon Neptune のグラフデータベースに保存されます。 Amazon Neptune を活用する JupiterOne の開発中で、まだ Neptune をプレビューしていたとき、評価を行う機会がありました。ライセンスの交渉やインフラストラクチャの管理ではなく、Neptune によって、JupiterOne の開発に集中できるようになったことがすぐに明らかになりました。他の AWS サービスと共通しているように、Neptune の使用量ベースのモデルでは、開発により成長を続け、ビジネスを拡大しながら、コストを抑えることができます。Neptune […]

Read More

オフラインの方法を使用して、MongoDB から Amazon DocumentDB に移行する

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメント データベース サービスです。Amazon DocumentDB 移行ガイドでは、MongoDB から Amazon DocumentDB に移行するための 3 つの主要なアプローチ (オフライン、オンライン、ハイブリッド) の概要を説明しています。 オフラインでの移行のアプローチは、3 つのうち最速で最も簡単な方法ですが、停止時間が最も長くなります。このアプローチは、概念実証、ワークロードの開発およびテスト、およびダウンタイムが主な懸念ではない本稼働のワークロードに適しています。移行に関する 3 回シリーズの第 1 回では、オフラインのアプローチを使用して、Amazon EC2 上の MongoDB レプリカセットから Amazon DocumentDB クラスターにデータを移行します。 オフライン移行の概要 次の図は、MongoDB から Amazon DocumentDB へのオフライン移行を示しています。 このアプローチには、5 つの基本的な手順があります。 ソース MongoDB デプロイメントへのアプリケーションによる書き込みを停止します。 mongodump ツールを使用して、インデックスとデータを EC2 インスタンスにダンプします。 (オプション) Amazon DocumentDB インデックスツールを使用して、Amazon DocumentDB クラスターにインデックスを復元します。 mongorestore ツールを使用して、データを […]

Read More

Amazon Aurora を使用して WordPress データベースバックエンドの容量をシームレスに増やす

今回は、Pagely の Arman Zakaryan (ホスティングオペレーション部門ディレクター) と Michael Martin (ソフトウェアエンジニア) によるゲスト投稿です。Pagely は、同社自身の言葉では、「WordPress のための非常にスケーラブルなマネージド型ホスティングソリューションを提供しています。世界で最大かつ最も革新的なブランドと協力して、オーダーメイドの WordPress ホスティングソリューションを作成しています。クライアントは、何よりもクライアントの幸せを最優先する、ベテランの DevOps エンジニアのオールスターチームによるサービスとサポートを享受できます。Pagely は、最高の状態で Enterprise WordPress をホスティングしています」。 WordPress は全ウェブサイトの 30 パーセントを駆動しています。これは、Pagely でビジネスを構築してきたコンテンツ管理システムです。当社のマネージド型 WordPress ホスティングは完全にアマゾン ウェブ サービス上で稼働します。Amazon が物理的なハードウェアやデータセンターの管理の心配からお客様を解放したのと同じように、Pagely は WordPress の管理を心配することなく自らの職務に集中できるようにします。Pagely が WordPress を大規模に実行することに対する献身的なサポートと経験は、Amazon の技術的なサービスと相性が良好です。 WordPress を実行する上で最も重要な側面の 1 つは MySQL データベースです。Amazon は Pagely のような会社が他のソリューションよりもはるかに優雅にそして効率的に業務上の職務を管理することを支援します。これは Amazon Relational Database Service (Amazon RDS) 、特に Amazon Aurora […]

Read More

[AWS Black Belt Online Seminar] Amazon Aurora MySQL 資料及び QA 公開

先日 (2019/4/24) 開催しました AWS Black Belt Online Seminar「Amazon Aurora MySQL」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190424 AWS Black Belt Online Seminar Amazon Aurora MySQL from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. Auroraでbinlogのユースケースは、どの様なことがありますか?(※今日のウェビナーを聞いて、リストアで使う必要性はないと感じたものです) A. Amazon Auroraでは標準ではバイナリログを利用しないレプリケーションやクラッシュリカバリを採用しているため、有効にするケースは少ないと考えております。利用用途としてはAmazon Auroraに移行する際に切り戻し用途で利用されるケースがございます。バイナリログが有効な状態ですとフェイルオーバーやクラッシュリカバリの時間が無効の状態よりも長くなる可能性があるため、有効にされる際は事前の検証を推薦しております。 今後の AWS Webinar スケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております。 AWS Innovate オンラインカンファレンス ≫ 申込先 2019 年 4 月 8 日〜5 月 7 日期間中いつでもオンラインで視聴可能 AWS基礎、業種別事例、人材育成、認定対策講座などAWSが厳選した33セッションを一挙に公開 — AWS Black Belt Online Seminar […]

Read More

Amazon RDS を使った災害復旧戦略の実装

Amazon RDS (Relational Database Service) は、リレーショナルデータベースのセットアップ、運用、スケーリングを容易にできるマネージドサービスです。AWS のハイパフォーマンスなコンピューティングとストレージを基本としている Amazon RDS は、MySQL、SQL Server、PostgreSQL、MariaDB、および Oracle のデータベースエンジンをサポートしています。このサービスは、プロビジョニング、パッチング、モニタリング、そしてディザスターリカバリー (DR) のための、ソリューションを完備しています。このブログ記事では、自動バックアップ、手動バックアップ、そしてリードレプリカ という、Amazon RDS が DR 対応のために提供する 3 つの機能をご紹介していきましょう。 DR プランの必要性とは? 実稼動状態にあるシステムにとって、想定外のイベント発生からも復旧を可能にするための、注意を怠らないことは重要です。Amazon RDS は、Multi-AZ の非常に豊富な設定項目を提供しています。とはいえ、自然災害、悪意のある利用者、そしてデータベースの論理的な破損などの、全ての可能性に対処できるわけではありません。ビジネス機会を失わないためには、DR プランのデザインとテストをしっかり行うべきでしょう。 RTO と RPO について知る DR プランを作り上げる時、リカバリータイムオブジェクティブ (RTO) と、リカバリーポイントオブジェクティブ (RPO) の 2 つは、考慮すべき主要なメトリクスとなります。RTO は、災害が発生した後、業務再開にどの位の時間を要するかを表します。RPO も同じ様に時間で表現されますが、こちらは、災害が発生した際にどの規模のデータが失われるかを表します。例えば、RPO が 1 時間であるということは、災害の発生により 1 時間分に相当するデータが失われる可能性があるという意味です。 Amazon RDS の各機能は、それぞれ違うコストポイントにおいて、違うRTO と RPO をサポートします。 機能 […]

Read More

Amazon Aurora MySQL データベース設定のベストプラクティス

AWS クラウドで新しい Amazon Aurora MySQL インスタンスを移行または起動した後、以下の質問のうち 1 つ以上を自問したことはありますか? 「次のステップは? どうすれば、最適に動作させることができるでしょうか?」 「既存のパラメータを変更する方が良いでしょうか?」 「どのパラメータを変更すれば良いでしょうか?」 自問したことがあるなら、何をすべきか(そして、何をすべきでないか)について、このブログ記事がガイダンスを提供できることを願っています。 この記事では、MySQL との互換性を持つ Amazon Aurora の設定パラメータについて説明、明確化し、推奨事項を提供します。こうしたデータベースパラメータとその値は、AWS クラウドで新しく作成または移行されたインスタンスの引き継ぎ、チューニング、再設定を行う場合に重要です。また、Amazon RDS for MySQL インスタンスから Aurora インスタンスに引き継がれるパラメータについても説明します。どの値がデフォルト値であり、どの値がインスタンスの安定性や最適なパフォーマンスにとって重要であるかを説明します。 変更を行う前の最も重要な考慮事項は、変更の背後にあるニーズや動機を理解することです。 ほとんどのパラメータ設定はデフォルト値で問題ありませんが、アプリケーションのワークロードの変化によりこうしたパラメータの調整が必要になる場合があります。変更を行う前に、以下の質問を自問してください。 再起動やフェイルオーバーなどの安定性の問題がありますか? アプリケーションでクエリをより高速に実行できますか? Aurora パラメータグループの初歩 Aurora MySQL パラメータグループには、DB パラメータグループと DB クラスターパラメータグループの 2 種類があります。バイナリログ形式、タイムゾーン、文字セットのデフォルトなど、一部のパラメータは DB クラスター全体の設定に影響を与えます。他のパラメータは、その範囲が単一の DB インスタンスに限定されます。 このブログ記事では、Aurora クラスターの動作、安定性、機能性に影響を与えるパラメータと、変更するとパフォーマンスに影響を与えるパラメータに分類して説明します。 どちらのタイプのパラメータも出荷時に事前にデフォルト設定されており、一部のパラメータでは変更が可能です。 パラメータグループの変更や操作の基本について、最新の情報をより深く理解するには、Aurora ユーザーガイドの以下のトピックを参照してください。 DB パラメータグループおよび DB クラスターパラメータグループを使用する Aurora MySQL パラメータ 本稼働データベースを変更する前に […]

Read More

Amazon RDS で機密データを保護するためのベストプラクティスの適用

このシリーズの最初の投稿では、AWS のデータストアに適用できる一般的なセキュリティの概念とそれに対応する AWS のセキュリティコントロールについて説明しました。これらを使用して、データに関わるセキュリティ体制をより強固にすることができます。この 2 回目の投稿では、こうした概念を Amazon RDS データベースで実装する方法を説明します。 実装例の多くはすべての RDS データベースエンジンに共通していますが、一部は個々のエンジンの種類によって異なる場合があります。このような場合は、MySQL との互換性を持つ Amazon Aurora の実装例を含めますが、他のデータベースエンジンの情報を入手する場所についても説明します。 それでは、最初の投稿で説明した順序でセキュリティの概念の実装を見ていきましょう。 データの分類とセキュリティゾーンモデリング データの分類とセキュリティゾーンモデリングに関するおさらいとして、以下をご覧ください。ここで提供されているより詳細な説明、およびデータの分類とセキュリティゾーンモデリングの背景にある概念については、このシリーズの最初の投稿を参照してください。 データの分類 この投稿で後述するセキュリティコントロールのどれを適用するかを決定するには、データの分類を理解してください。たとえば、どちらもこの投稿の後半で説明しますが、データのトークン化やセキュリティのマイクロセグメンテーションなど、特殊なセキュリティコントロールは必要ないかもしれません。これらが不要であるケースとしては、データベースにクレジットカード番号や社会保障番号などの機密性の高いデータがない場合があります。 セキュリティゾーンモデリング セキュリティゾーンを設計したら、ネットワークアクセスコントロールリスト (ACL) を使用して実装します。サブネット全体をネットワークフロー制御バリアとして使用できるようにすることをお勧めします。この投稿の後半の「セキュリティグループとネットワーク ACL」セクションで、ネットワーク ACL を使用してセキュリティゾーンを実装する方法を示します。 セキュリティゾーンモデリングを実装するときは、ネットワーク設計を慎重に検討します。CIDR 範囲のサイズによって、各サブネットが表現できる IP アドレスの数が決まります。サブネット内の増加 (より多い IP アドレス) とサブネット数の増加をサポートできるように、CIDR 範囲を設計します。Amazon VPC とオンプレミスのデータセンター間、または VPC 間に矛盾のない IP アドレススペースを確保するための要件とバランスを取ります。詳細については、AWS Answers サイトの AWS 単一 VPC の設計を参照してください。 徹底的な防御 RDS 内での徹底的な防御のためのセキュリティコントロールの詳しい説明に入る前に、この投稿の後半で説明するセキュリティ設定について説明している RDS 起動ウィザードのセクションを見てみましょう。 セキュリティ設定を取得するには、AWS […]

Read More

Amazon DynamoDB: アドテックのユースケースと設計パターン

広告技術 (アドテック) 企業は、Amazon DynamoDB を使用して、ユーザープロファイル、ユーザーイベント、クリック数、訪問済みリンクなどのさまざまな種類のマーケティングデータを保存します。用途としては、リアルタイム入札 (RTB)、広告ターゲティング、アトリビューションなどがあります。このブログ記事では、DynamoDBを使用するアドテック企業の最も一般的なユースケースと設計パターンを特定します。 こうしたユースケースでは、高いリクエスト率 (1 秒あたり数百万件のリクエスト)、低くて予測可能なレイテンシー、および信頼性が必要です。大規模な読み取りボリュームがある場合、またはミリ秒未満の読み取りレイテンシーが必要な場合、企業は DynamoDB Accelerator (DAX) によるキャッシングを利用します。ますます多くのアドテック企業が、複数の地域で RTB や広告ターゲティングプラットフォームをデプロイしており、これには AWS リージョン間でのデータレプリケーションが必要になります。 完全マネージド型サービスである DynamoDB を使用すると、アドテック企業はデータベースの運用にリソースを投資することなく、こうした要件をすべて満たすことができます。また、こうした企業は、DynamoDB への移行によってデータベースの支出が削減されるため、DynamoDB の費用対効果も高いことに気付きます。たとえば、GumGum が自社のデジタル広告プラットフォームを DynamoDB に移行したとき、古いデータベースに比べてコストが 65〜70% 削減されたと推定しています。 この記事で使用される用語 この記事では、以下のデータモデリングと設計パターンの用語を使用します。 1:1 モデリング: パーティションキーをプライマリキーとして使用する 1 対 1 関係のモデリング。 1:M モデリング: パーティションキーとソートキーをプライマリキーとして使用する 1 対多関係のモデリング。 DAX によるキャッシング: DynamoDB の前で読み取りキャッシュとして DAX を使用すると、読み取りのレイテンシーを短縮できるだけでなく、頻繁にアクセスされるアイテムに対する高い読み取り負荷を費用効果の高い方法で処理することができます。 アドテックのユースケースと設計パターン ユースケース データモデリングまたは設計パターン RTB および広告ターゲティングでのユーザープロファイルの保存 1:1 モデリング、1:M モデリング […]

Read More

Amazon DocumentDB の新しい集約パイプライン機能を使いパワフルな集約型クエリを記述する

 Amazon DocumentDB (MongoDB 互換) は、MongoDB のワークロードをサポートする高速でスケーラブル、かつ可用性に優れた完全マネージド型のドキュメントデータベースサービスです。お客様は、現在ご使用のものと同じ MongoDB 向けアプリケーションコードや、ドライバー、およびツールを、そのまま Amazon DocumentDB 上で実行や管理をしたり、処理負荷の調整などに使えます。これにより、基本インフラストラクチャの管理に煩わされることなく、向上したパフォーマンス、スケーラビリティ、および可用性を活用することが可能です。 2 月のブログで解説した機能を基に、 今回、Amazon DocumentDB に新たな集約パイプライン処理に関するサポートが追加されました。この新機能には以下のものが含まれます。 7 個の集約文字列演算子 ($indexOfCP、$indexOfBytes、$strLenCP、$strLenBytes、$toLower、$toUpper、$split) 9 個の日付時間演算子 ($dayOfYear、$dayOfMonth、$dayOfWeek、$year、$month、$hour、$minute、$second、$millisecond) $sample 集約パイプラインステージ このブログでは、一般的なユースケースとして上記演算子の使用法を示しながら、そこに新しく加わった機能をご紹介していくことにします。 Amazon DocumentDB の使用開始 Amazon DocumentDB の初心者の方は、次のいずれかから使用を開始することができます。 Amazon DocumentDB の開始方法 Amazon DocumentDB Quick Start Using AWS CloudFormation Getting Started with Amazon DocumentDB (YouTube 動画)  新機能 Amazon DocumentDB クラスターを作成して接続したら、次の例をよく理解して拡張することができます。 1.集約文字列演算子 ドキュメント内に格納された文字列は、多様な利用法に応じ、必要とされる部分ごとに分けて取り出す操作が可能です。この文字列では、追加の処理や比較、あるいはデータのクリーンアップなどが行えます。アプリケーションコードで文字列処理を記述しなくても、集約文字列演算子を用いてデータ処理をデータベース内に落とし込むことができます。現状で、Amazon […]

Read More