Amazon Web Services ブログ

Category: Database

オフラインの方法を使用して、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

改元はどのように RDS で実行されている MySQL 互換エンジンに影響を与えるか

RDSもしあなたのソフトウェアやシステムが日本のお客様をサポートしており、さらにそのソフトウェアやシステムが元号を表示する必要がある場合、新しい元号を表示するように改修の必要があるかもしれません。新しい元号は、現在の天皇陛下が退位される 2019 年 5 月 1 日から有効になります。 このブログ記事では、かかる元号の変更(改元)にかかわる背景について説明し、その後、どのように改元の影響を調べるかを、私が RDS で実行される MySQL 互換のデータベースエンジンについて調査した際の方法を元に、詳しく解説します。またその調査の結果、RDS で実行される MySQL 互換のデータベースエンジンは改元の影響を受けない、という結果を得たことを報告します。 改元について 元号は、日本で、主に政府のシステムや公的な文書などを中心に、未だ広く使われています。そのようなシステムをサポートするために、いくつかのソフトウェアでは元号をサポートするための機能が実装されています。例えば、Windows では元号をレジストリに格納していたり、Oracle データベースは元号を表示するためのカレンダー・ファイルを持っていたり、glibc ライブラリの strftime()関数は元号を表示するための機能があり、日本語のロケール・ファイルには元号の情報が含まれていたりします。 来る 2019 年 4 月 30 日に、現在の天皇陛下が退位され、それにともない 2019 年 5 月 1 日から元号が変更されます(改元)。そのため、元号をサポートするソフトウェアは、新しい元号を表示できるように更新する必要があります。 新しい元号は2019 年 4 月 1 日に発表される予定となっており、ソフトウェアのアップデートを準備する時間は 1 ヶ月未満の短い期間しかありません。 条件の理解 基本的に、Linux ビルトインのソフトウェアのうち、元号の表示に対応しているものは glibc() ライブラリの strftime() 関数のみです。 strftime()は日付や時刻の表示フォーマットを変更するための関数で、元号を使用して日付を変更する機能を持ちます。日本語 (ja_JP) ロケールを使用しているシステムでフォーマット指定子 (format specification) として […]

Read More

レイテンシーを考慮した Amazon DynamoDB アプリケーションのための AWS Java SDK HTTP リクエスト設定の調整

Amazon DynamoDB は、大規模に実行されるアプリケーションとサービスに低レイテンシーと高スループットのパフォーマンスを提供するために設計された NoSQL クラウドデータベースサービスです。ユースケースの例には以下が含まれます。 大規模多人数参加型オンラインゲーム (MMOG) バーチャルリアリティとオーグメントリアリティ e コマースでのチェックアウトと注文処理 リアルタイムの株価情報と売買 そのようなシステムをグローバルで運営していると、時折レイテンシースパイクが発生することがあります。これらのスパイクは、一時的なネットワーク中断による再試行、サービス側およびネットワーク側の問題、または過剰な負荷がかかった応答が遅いクライアントが原因で発生する場合があります。 根本的な原因にかかわらず、DynamoDB サービスとやり取りするアプリケーションは、レイテンシースパイクを回避するために役立つ再試行戦略に従うよう調整しておく必要があります。使用している AWS SDK に応じて、基盤となる HTTP クライアントの動作は、HTTP を経由する低レベルのクライアント対サーバー通信がアプリケーションのレイテンシー要件に従うことができるように、デフォルト設定を設定し直すことが可能です。このブログ記事では、レイテンシーを考慮した DynamoDB クライアントのための、HTTP リクエストのタイムアウトと再試行動作の微調整に利用できる AWS Java SDK 設定オプションについて説明します。また、適切な設定のメリットを実証するために、2 つの仮定上のアプリケーションシナリオについても説明します。 DynamoDB クライアントのための AWS Java SDK HTTP 設定 AWS Java SDK は、HTTP クライアントの動作と再試行戦略に対する完全な制御を提供します。標準 HTTP 設定の情報については、「クライアント側の設定」を参照してください。一方で、レイテンシーを考慮した DynamoDB アプリケーションクライアントを構築するために必要なより詳しい設定は、ClientConfiguration (JavaDocs) コード実装にあります。 このブログ記事では、非同期 DynamoDB クライアント を Java でゼロから構築し、AWS SDK からの ClientConfiguration […]

Read More