Amazon Web Services ブログ

Category: Database

SimilarWeb が Couchbase から Amazon DynamoDB に移行し、70% 節約した方法

今回は AWS ソリューションアーキテクトの Leonid Koren、および AWS シニアテクニカルアカウントマネージャーの Ziv Shenhav との共同著作による、SimilarWeb のソフトウェア開発者 Doron Grinzaig 氏のゲストブログ投稿です。 NoSQL データベースはスケーラブルで適応性があり、高機能のデータベースを必要とする現代のモバイル、ウェブ、ゲーム用アプリケーションに最適です。しかしながら、NoSQL データベースは分散型の性質を持つため、特に大きな規模になると管理が難しく、多くのリソースとかなりの注意が必要になります。SimilarWeb は数年の間、2 つの Couchbase クラスターを運用していましたが、コストと運用オーバーヘッドは高くついていました。そのため SimilarWeb は、安定性の向上とコストおよび運用オーバーヘッドの削減を目指して、Amazon DynamoDB に移行したのです。DynamoDB は完全マネージド型のデータベースサービスで、現在では複数の AWS リージョンで SimilarWeb の顧客にデータを提供している信頼性の高いデータベースの 1 つです。 このブログ投稿では、SimilarWeb が DynamoDB への移行を決めた理由を詳しく説明します。移行プロセスについて説明し、コスト削減に役立った最適化の方法についても解説します。 SimilarWeb について SimilarWebは、デジタル世界全体の動向に関する洞察を提供するマーケットインテリジェンス企業です。何千にもおよぶ顧客が同社の洞察を基に、マーケティング戦略の改善、販売促進、さらに投資に関する重要な決定を下しています。重要な意思決定に SimilarWeb が関わっていることが、データを効果的に収集かつ利用し、最終的にはユーザーに提供する SimilarWeb の能力を証明しています。 SimilarWeb はさまざまなソースから大量の生データを継続的に収集し、取り込みます。Cloudera クラスター (Apache Spark を実行している) を使って、これらのデータを並び替えて構造化します。データを Apache HBase クラスターにロードし、Amazon S3 ベースのデータレイクに保存します。過去にはデータの一部を […]

Read More

サポートが終了する VMware Clous on AWS の SQL Server インスタンスを簡単にアップグレードする

Microsoft SQL Server 2008 と 2008 R2 のインスタンスをまだデプロイしているなら、今こそアップグレードするべきです。これらの Microsoft のサポート終了日 (EoS) は 2019 年 7 月 9 日。もうすぐです。つまり、それ以降はセキュリティの問題やコンプライアンス上の問題があるため、これ以上セキュリティの更新は行われません。実行するなら今です! 今日は、SQL Server インスタンスのアップグレードの自動化を支援する新しいオープンソースのツールを GitHub で公開できることを大変うれしく思っています。この自動化により、アップグレードの実行が迅速になり、重要なデータを格納しているアプリケーションに対するセキュリティ体制を維持しつつ、EoS の前にこのプロジェクトを完了できるようになります。 開始方法 新しいツールは Upgrade-SqlServerStandaloneDatabaseEngineInstance.ps1 という名前で、GitHub で入手できます。これは vSphere インフラストラクチャにアクセスできない可能性があるデータベース管理者 (DBA) などによってローカルで開始されるか、仮想システム管理者などによってリモートで開始されることがあります。アップグレードは Microsoft Windows PowerShell と PowerShell Core の両方でテストが行われました。したがって、macOS、Linux、Windows からリモートアップグレードの起動が可能です。 この記事では、スタンドアロンの SQL Server 2008 R2 SP3 インスタンスを SQL Server 2016 にリモートでバッチアップグレードします。これを AWS の VMware […]

Read More

オープンソースプラットフォームで 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