Amazon Web Services ブログ

Category: Database

Amazon Aurora での Cloudability のパフォーマンス向上、チューニングの簡素化、コスト削減について

Cloudability は、クラウドのコスト管理プラットフォームであり、企業が既知のクラウド財務と完全なアカウンタビリティの実行を可能にします。プラットフォームでは、殺到する請求書および利用データポイントを収集します。各クラウドベンダーの 275,000 以上のサービスとオプション、またクラウドプロバイダーごとに毎年 1,000 以上の新しいサービスが展開されており、1 リソースあたり 3,300 万件にものぼります。 分析、自動化、および Machine Learning を使用して、 Cloudability の True Cost Engine は、企業での割引、クレジット、コミットメント、予約、配分、および償却に基づいてこのデータを補強し、変換します。 Cloudability’ の TrueCost Explorer では、請求データを分析し、使用状況がどのようにコストに変換されるかを理解します。 Cloudability により、より望ましいリザーブドインスタンス (RI) の決定が可能になります。リザーブドインスタンスプランナーを使って、活用されていない RI の計画、購入、変更、および識別が可能です。 コスト、使用量、および RI データを取り込んだ後、Cloudability は、使用時間消費と RI カバレッジ周りのユーザーの可視性における追跡と改善を容易にします。 状況 2017年春、我々は True Cost Engine の新しい予測モデルを公開するプロジェクトに着手しました。AWS で実行するする顧客にさらに高いコスト効率を提供する予測モデルを開発することがこのプロジェクトの目標でした。 このような分析をサポートするためには、パフォーマンス、スケーラビリティ、費用対効果に優れ、そしてメンテナンスやチューニングが容易なデータベースが必要でした。この記事では、これらの要件を満たすための最良の選択である PostgreSQL との互換性を備えた Amazon Aurora をどのように見出したかを示します。 プロジェクト 昨年初め、Cloudability のデータサイエンスチームは、ペタバイトの顧客コスト最適化データを使用して新しい予測モデルを開発することを決めました。これらのモデルは、アカウントの過去のスポット料金の動向、顧客の RI ポートフォリオの欠損値、インスタンスの使用パターン、および顧客が指定した料金表の調整などを考慮に入れます。 このモデルは、過去の […]

Read More

MySQLデータベースをAuroraへ移行する方法をマスターする

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group 私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。 しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか? Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか? Kepler Groupでは、インフラストラクチャの95%以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。   Global Fortune 100の例 私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。 今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。 このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました: データベースメンテナンスの負荷を低く抑える インフラストラクチャコストの制限 信頼性の高いバックアップおよびリカバリプロセスを確保する 前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました: v1.0:オンプレミスハードウェア上のLinuxでMySQLを実行する v2.0:Amazon EC2上のLinuxでMySQLを実行する v3.0:MySQLと互換性を持つAmazon Aurora 次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。   Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する 2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。 利点 この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。 チャレンジ しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました: かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス […]

Read More

Amazon Elasticsearch Service の使用開始: AWS SigV4 による署名付きリクエストを簡単に送信する方法

Elasticsearch および Amazon Elasticsearch Service (Amazon ES) に関するこの導入シリーズへようこそ。今回および今後のブログ記事では、AWS で Elasticsearch の使用を開始するために必要な基本情報を紹介します。 概要 IAM ポリシーまたは Amazon Resource Name (ARN) のポリシーを使用して、ユーザーまたはロールを指定し、Amazon Elasticsearch Service ドメインへのアクセスをコントロールしている場合は、ドメインへのすべてのリクエストに対し AWS Signature Version 4 (AWS SigV4) を使用して署名する必要があります。ドメイン保護に関するさらに詳しい分析については、こちらのブログ記事もご参照ください。ポリシーの考察およびその問題解決に関する詳細は、こちらのブログ記事をご参照ください。 リクエストへの署名に関する AWS ドキュメントを読んでいただければ、非常に複雑に見えるプロセスが理解できるようになります。難しく見えますが、3 つのオープンソースライブラリを使用して、コードをいくつか書き、署名して Amazon ES にリクエストを送信するのはとても簡単です。ここでは Boto3、Python Requests ライブラリ、Requests AWS4Auth ライブラリを使用します。 コードスニペット 次のコードスニペットには、HTTP メソッド、呼び出す URL、呼び出すサービス、AWS リージョン、オプションのリクエストボディがあります。このコードでは、Boto3 の Session クラスを使用して認証情報を取得しています。Boto3 が認証情報を決定する方法の詳細については、Boto3 のドキュメントを参照してください。AWS4Auth クラスが認証情報を使用してリクエストに署名します。最後に、Requests ライブラリが Amazon ES […]

Read More

Amazon Linux 2 AMI および Ubuntu AMI での SQL Server 2017 の設定方法

AWS で Microsoft SQL Server をデプロイするときは、アプリケーションのパフォーマンス、可用性、信頼性、およびコストをどのように最適化するかに関する数多くの選択肢があります。Amazon では、使用方法を最適化し、コストを削減するために、複数の SQL Server バージョン、幅広いコンピューティングオプション、および多数のライセンスオプションをご用意しています。従量制料金モデルを選択して AWS のライセンスが包含されたオプションを使用する、または Amazon EC2 で独自のライセンスを使用する (BYOL) ことができます。 EC2 インスタンスで利用できる SQL Server 2017 には、Amazon EC2 で実行される Microsoft Windows または Linux オペレーティングシステムのどちらかに SQL Server ベースのアプリケーションをデプロイする柔軟性があります。AWS は本日、ライセンスが包含された Amazon Machine Image (AMI) を提供することによる、Amazon Linux 2 および Ubuntu での Microsoft SQL Server のサポートを発表しました。このリリースでは、ライセンスが包含された AMI を EC2 コンソールから直接使用して、Amazon Linux 2 LTS […]

Read More

Active Directory 認証と承認を使って Amazon Elasticsearch Service ドメインをセキュリティ保護する

この記事では、Amazon Elasticsearch Service (Amazon ES) ドメインを Microsoft Active Directory (AD) に基づく認証および承認を使ってセキュリティ保護する方法を示します。これには、カスタム認証コードを実行している Nginx リバースプロキシを使用します。Amazon ES には、アクセス制御のための AD / LDAP との統合サポートは組み込まれていません。この記事では、この問題に対する単純で強力な解決策を提供します。 Amazon Elasticsearch Service (Amazon ES) は、Elasticsearch の使いやすい API とリアルタイム機能、ならびに本稼働ワークロードに必要な可用性、スケーラビリティ、セキュリティを提供する完全マネージド型のサービスです。このサービスには、Kibana、Logstash、および Amazon Kinesis Firehose、AWS Lambda、Amazon CloudWatch などの AWS サービスとの統合が組み込まれているため、ソリューションの迅速な構築が可能です。 Amazon ES では、AWS Identity and Access Management (IAM) を使用してクラスタ内のデータへのアクセス制御をきめ細かく行うことができます。前の記事では、クライアント アプリケーションでリソースベースのアクセス権、アイデンティティベースのアクセス権、および Signature Version 4 署名を適用して Amazon ES ドメインへのアクセスを制御する方法を学びました。この記事を読んだ後は、社内 AD (オンプレミスまたは […]

Read More

Amazon Aurora MySQLやAmazon RDS for MySQLへIAM authenticationを利用してSQL Workbench/Jから接続する

この記事では、Aurora MySQLクラスタに接続するために既に使用しているツールでIAM認証を使用する方法を説明します。この手順は、Amazon RDS for MySQLインスタンスでも同様にご利用頂けます。提供されたスクリプトを使用して、リソースをプロビジョニングしたり、IAM認証用に環境を構成したりすることができます。

スクリプトを使用してIAM認証情報を使用して、mysqlコマンドラインツールまたはSQL Workbench / Jを使用してクラスタに接続します。GitHubリポジトリでは、この投稿で使用されているコードサンプルをご覧いただけます。

Read More

AWS CloudFormationを使用してOracleからAmazon Aurora MySQLに移行する方法(パート1)

特に、OracleからAmazon Aurora PostgreSQL、OracleからAmazon Aurora MySQL、またはMicrosoft SQL サーバーからMySQLへの異種データベースの移行では、データベースの移行はかなり難しいです。ソース・データベースのスキーマ構造、データ・タイプ、およびデータベースのコードは、ターゲット・データベースのスキーマ構造、データ・タイプ、およびデータベース・コードとかなり異なる場合があり、データの移行が開始される前にスキーマおよびコードの変換ステップが必要です。これにより、異種データベースの移行が二段階のプロセスになります。 この2部構成の移行ブログシリーズの第1部では、AWS CloudFormationスタックを構築し、OracleデータベースからAmazon Aurora MySQLデータベースにデータを移行するプロセスを示すのに役立つリソースをデプロイします。パート2では、この記事で作成したリソースを基に、AWS Glueを使用してデータを抽出、変換、ロード(ETL)する方法を示します。 AWSには、異種の2段階移行のための AWS Schema Conversion Tool(AWS SCT)やAWSデータ移行サービス(AWS DMS)などの直感的なツールがあります。これらのツールは、移行オーバーヘッドと複雑さを軽減します。移行プロセスを最適化するためのこれらのツールおよび設定の詳細については、 「OracleデータベースをAmazon Auroraに移行する方法」をご参照ください。 図1:異種データベースの移行手順 この記事では、セルフサービスのデモンストレーションによる簡単な移行を紹介します。AWS SCTおよびAWS DMSコアの概念を理解し、なれるのに役立ちます。現在、Amazon Aurora、Amazon Redshift、または Amazon DynamoDB への移行の場合には、1 インスタンスごとに AWS DMS を 6 ヵ月無料で利用することができます。 移行プロセスを実証するため、AWS CloudFormationスクリプトを使用して、Oracleデータベース(HRDATA)が事前にインストールされたAmazon EC2インスタンス、Aurora MySQLクラスタ、およびAWS DMSレプリケーションインスタンスをデプロイします。移行プロセスに役立てるため、Amazon Virtual Private Cloud (Amazon VPC)、およびそのネットワーキング構成、Amazon S3バケット、そして AWS Identity and Access Management (IAM) のロールとポリシーなどのその他の必要なコンポーネントも使用します。AWS CloudFormationスタックのデプロイには、10〜12分かかります。この例の全体的なウォークスルーは1時間以内で完了できます。 […]

Read More

AWS DMS を使用して Oracle ASM からAWSに移行する方法

このブログ記事では、ストレージインフラストラクチャが Oracle ASM のOracleソースエンドポイントでの AWS Database Migration Service (AWS DMS) の Change Data Capture (CDC) の使い方について説明します。

Oracle 自動ストレージ管理 (ASM) データベースフレームワークは、Oracleデータベースファイル用のボリュームマネージャとファイルシステムを提供し、シングルインスタンスの Oracle Database と Oracle Real Application Clusters (Oracle RAC) をサポートしています。ASMにはファイルシステムとデータベース内のボリュームを直接管理するためのツールがあります。これらのツールを使用すると、データベース管理者 (DBA) は標準的なOracle環境で使いなれたSQL文を使用してボリュームやディスクを制御できます。

Read More

分散型可用性グループを使用して、ハイブリッドMicrosoft SQL Serverソリューションを設計する方法

モノリシックでミッションクリティカルなMicrosoft SQL ServerデータベースをオンプレミスからAWS(Amazon EC2ベースのSQL Server)に移行することは、しばしば困難な作業です。主な課題は次の通りです: 継続的なダウンタイム – ビジネスに悪影響を及ぼす可能性のあるカットオーバー中の継続的なダウンタイムウィンドウが発生する課題 データ同期の課題 – オンプレミスに配置されたデータベースとAWS上のデータベースを同期した状態に維持するための課題 柔軟性の欠如 – 移行のための段階的なアプローチを計画・実行する為の柔軟性を確保する課題 この記事では、重要なSQL ServerデータベースをAWSにリフト&シフト(またはリフト&トランスフォーム)するためのハイブリッドソリューションの構築方法について詳しく説明します。このソリューションでは、SQL Server 2016で導入された新しい機能である分散型可用性グループを使用します。この記事では、分散型可用性グループを使用して移行を制御し、柔軟性を高める段階的アプローチについても説明します。 分散型可用性グループの概要 分散型可用性グループは、2つの個別の可用性グループにまたがる特別なタイプの可用性グループ(AG)です。分散型可用性グループは複数の可用性グループの1つ(または複数のAGの中の1つ)と考えることができます。基礎となる可用性グループは、2つの異なるWindows Server Failover Cluster(WSFC)で構成されます。 分散型可用性グループアーキテクチャは、既存のオンプレミスWindows Server Failover Cluster(WSFC)をAWSに拡張するよりも効率的です。データは、オンプレミスのプライマリからAWS上の1つのレプリカ(フォワーダ)にのみ転送されます。フォワーダは、AWS上の他のリードレプリカにデータを送信する役割を担います。このアーキテクチャにより、オンプレミスとAWSの間のトラフィックフローが削減されます。 アーキテクチャ概要 次の図は、ソリューションの全体的なアーキテクチャを示しています。 図に示されているように、最初のWSFCクラスタ(WSFC1)はオンプレミスでホストされています。オンプレミス可用性グループ(AG1)はこのWSFCクラスタに配置されます。 2番目のWSFCクラスタ(WSFC2)はAWSでホストされます。 AWS可用性グループ(AG2)はこのWSFCクラスタに配置されます。 このユースケースでは、オンプレミスのSQL Serverインスタンスとデータベースは、従来の物理サーバーまたは仮想マシン(VM)によってホストされています。 AWSのSQL ServerインスタンスはAmazon EC2でホストされ、SQL ServerデータベースはAmazon EBSボリュームで構成されます。 AWS Direct Connectによって、オンプレミスからAWSへの専用ネットワーク接続を確立しています。 前述のアーキテクチャ図に示すように、オンプレミス可用性グループ(AG1)には2つのレプリカ(ノード)があります。これらの間のデータ転送は、自動フェイルオーバーを使用して同期します。オンプレミスレプリカの1つに障害が発生すると、AGは2番目のレプリカにフェールオーバーすることで、アプリケーションとユーザーはDBを使用できます。各可用性グループは、1つのプライマリレプリカと最大8つのセカンダリレプリカをサポートしています。高可用性の要件と拡張性のニーズに基づいて追加のレプリカを同期または非同期にする必要があるかどうかを判断します。 AWS可用性グループ(AG2)にも2つのレプリカがあり、それらの間のデータ転送は自動フェールオーバーで同期しています。 EC2インスタンスまたは1つのアベイラビリティゾーンに障害が発生すると、AGは別のアベイラビリティゾーンにある2番目のEC2インスタンスにフェールオーバーします。 このソリューションの一環として、分散型可用性グループを構成します。このグループには、オンプレミス可用性グループ(AG1)とAWS可用性グループ(AG2)の両方が含まれます。分散型可用性グループは、前述の図において赤い点線で示すように、データベースを非同期で同期させます。 フォワーダ(前述の図で緑文字で表されている)は、AWS内の他のリードレプリカにデータを送信する役割を担います。このデータ転送により、オンプレミスとAWS間のトラフィックフローが減少します。オンプレミスからAWSへのデータ転送はプライマリレプリカから一度だけ実施され、フォワーダは残りの伝播を処理します。 どの時点でも、書き込みに使用できるデータベースは1つだけです。残りのセカンダリレプリカデータベースは読み取り用に使用できます。前述のサンプルアーキテクチャ図では、社内のプライマリデータベースを読み取り/書き込み可能にし、AWSセカンダリデータベースを読み取りに使用できます。 AWSでリードレプリカを追加できることが重要なメリットです。この能力があれば、AWSへの移行に際して、読取り専用アプリをAWSに最初に移行することができます。また、データベースは、AWS上のアプリケーションとそのユーザーにも近くなります。 読み込みのワークロードをスケールアウトする場合は、AWSにさらに多くのリードレプリカを追加できますし、複数のアベイラビリティゾーンに配置することも可能です。このアプローチは、以下のアーキテクチャ図で表されます。この図では3つの異なるアベイラビリティゾーンに、それぞれリードレプリカを配置しています。 段階的な移行方法 分散型可用性アーキテクチャを使用することで、段階的な移行が可能となり、移行における柔軟性を高めることができます。 フェーズ1 この段階では、ほとんどの読取り専用アプリケーションをAWSに移行して、AWS上の読取り専用セカンダリデータベースにアクセスします。読み取り/書き込みを行うアプリケーションは、引き続きオンプレミスのプライマリ・データベースにアクセスします。 クラウド移行のこのフェーズでは、ストレステスト、機能テスト、およびデータベース作業負荷の回帰テストが重要な要素です。読取りワークロードをサポートするためにEC2インスタンスを正しくサイジングすることもこのフェーズの重要なステップです。 […]

Read More

Database Migration Playbook が公開されました!

Database Migration Playbooks(Amazon Web Services と NAYA Tech の共同プロジェクト)とは、異種間データベース移行計画を成功させるためのベストプラクティスに焦点を当てた一連のガイドです。このプレイブックは、AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Servies (AWS DMS) を含む、既存の自動化および半自動化されたAmazonデータベース移行ソリューションおよびツールを補完するものです。

「Oracle to Amazon Aurora Migration」プレイブックの初版では、Oracle 11g と12cのデータベース機能とスキーマオブジェクトを Amazon Aurora with PostgreSQL compatibility に移行するためのベストプラクティスに重点を置いています。移行するためには、PostgreSQLデータベースエンジン自体に組み込まれている機能と、様々なAWSサービスやソリューションの両方を使用しています。

Read More