Amazon Web Services ブログ

Category: Amazon Aurora

[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

改元はどのように 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 Aurora MySQL 互換エディションでグローバルトランザクション ID (GTID) によるレプリケーションがサポートされるようになりました

Amazon Aurora MySQL 互換エディションは、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Amazon Aurora with MySQL compatibility は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 本ブログ記事では、オンプレミスまたは Amazon EC2 上でホストされている MySQL DB を、新たにリリースされた GTID べースのレプリケーション機能を使用する Aurora MySQL に移行するのに役立つガイダンスについて解説します。 GTID ベースのレプリケーションとは? グローバルトランザクション ID (GTID) とは、MySQL、または MySQL 互換エンジンを実行するデータベースサーバー上でコミットされた各トランザクションに作成され、関連付けられる固有の識別子です。この ID は元のサーバーと、さらにトランザクションの両方を個別に識別します。 フェイルオーバーやダウンタイム後、データベース管理者にとって最大の課題は、ひとつの変更もスキップされることなく、また、一切の競合が生成されることない方法でレプリケーションを復元することです。ワークロードが動的に、スケーラブルに、また複雑になるに従って、これらの再構成タスクもますます頻度が増えていきます。その結果として、バイナリログファイルの位置を特定するのに必要な管理的オーバーヘッドが増大し、それによって、復旧時間が長引きます。

Read More

2018 年に最もよく読まれた AWS データベースブログ

この記事では、私たちが 2018 年に掲載した AWS データブログ記事で、最もよく読まれた10本を紹介しています。このリストをガイドとして使って、まだ読んでいないデータベースブログに目を通す、または特に有益だと思った記事を読み返すことができます。

Read More

Intuit 社の導入事例: オンプレミス MySQL から Amazon Aurora への移行の自動化

Intuit社はレガシーデータセンターを売却し、顧客向けアプリケーションである QuickBooks、TurboTax、および Mint を AWS に移動させており、今後数年の間には完全に移行させる予定です。このブログ記事では、彼らがオンプレミスMySQLの移行先として、どのような基準で Amazon Aurora を選び、どのようにして最小限のダウンタイムで移行したのかについて共有されています。

Read More

Oracle から PostgreSQL へ移行する際に、よく直面する課題を解決する方法

企業は年々データが急激に増加するのを目の当たりにしています。データベースとハードウェアインフラストラクチャをスケーリングし続けることは、ますます困難になっています。ワークロードが非リレーショナルデータストアに適していない場合に、基盤となるインフラストラクチャの管理に膨大な費用を費やすことなく、スケーリングの課題をどのように克服したらいいでしょうか? Amazon RDS for PostgreSQL と Amazon Aurora with PostgreSQL により、コスト効率の高い方法で PostgreSQL クラウドのデプロイを簡単にセットアップ、運用、拡張することができます。昨年、私たちは (数百 GB から数 TB に及ぶ) 100 を超える Oracle データベースを Amazon Aurora PostgreSQL と Amazon RDS for PostgreSQL に移行しました。 この記事では、移行中に持ち上がった最も一般的な問題のいくつかについて説明します。皆さんは AWS Database Migration Service (AWS DMS) を使用して、あるデータベースから別のデータベースにデータを移動させた経験があることでしょう。私も AWS Schema Conversion Tool (AWS SCT) をかなり使い込みました。手始めに、データ抽出プロセスで直面する可能性のある問題を取り上げます。次に、データの移行中に起こる問題について取り上げます。最後に、移行後に PostgreSQL で観察するパフォーマンスの問題について説明します。 抽出フェーズの問題 このフェーズで一般的に直面する問題は、大きなテーブルのデータ抽出が遅くなり、ソース DB で ORA-01555 エラー (スナップショットが古すぎます) […]

Read More

Amazon Aurora PostgreSQL によるフェイルオーバー

レプリケーション、フェイルオーバー、レジリエンス、災害対策、バックアップ—従来の、または非クラウドベースのアーキテクチャでは、これらの一部またはすべてを実現するのはとても困難です。さらに、時にはかなりのリエンジニアリング作業が必要になることがあります。関係する実装やインフラストラクチャのコストが高いため、一部の企業では最も重要なアプリケーションのみが適切に保護されるようにアプリケーションを階層化せざるを得ません。 こうした懸念は、Amazon Aurora for PostgreSQL に移行すること軽減できます。AWS は、Oracle、MySQL、PostgreSQL、Aurora を含む (ただしこれらに限定されない) 幅広い種類のリレーショナルデータベースエンジンを提供しています。PostgreSQL の場合、AWS は Amazon EC2 インスタンスでの PostgreSQL、Amazon RDS for PostgreSQL、Amazon Aurora with PostgreSQL compatibility を含むさまざなバリエーションをサポートしています。適切なバージョンの PostgreSQL を選択するための多くの指標の中で、以下のいくつかが重要です。 高可用性 (HA) パフォーマンス 管理のしやすさ それでは、Amazon Aurora PostgreSQL がこうした基準をどのように満たしているかを掘り下げてみましょう。 高可用性: HA は、Aurora PostgreSQL のアーキテクチャに組み込まれており、3 つのアベイラビリティーゾーンにわたって 6 つのデータコピーが維持されています。つまり、アベイラビリティーゾーンごとに 2 つのコピーがあることになり、いずれかのアベイラビリティーゾーン全体がダウンしてもわずかな中断で済むことから可用性が向上します。さらに、データベースは Amazon S3 に継続的にバックアップされるため、S3 の高耐久性 (99.999999999) をバックアップで利用できます。Aurora PostgreSQL は、ポイントインタイムリカバリもサポートしています。 パフォーマンス: Amazon Aurora […]

Read More

SQL Server エージェントのジョブを AWS Step Functions に置き換える

Microsoft SQL Server から Amazon Aurora PostgreSQL への移行の場合に、SQL エージェントのジョブを簡単に移動できないことにお気づきかもしれません。Aurora PostgreSQL ではジョブエージェントツールがサポートされていません。この制限を克服するには、AWS Step Functions を使用して SQL エージェントのジョブを置き換えます。 このブログ記事では、ステップ関数を作成して、SQL ストアドプロシージャを実行する SQL エージェントのジョブを置き換える方法を示します。 ソリューションを実行するためのステップ このソリューションを実行するためのコードと AWS CloudFormation テンプレートは、この GitHub Amazon Repository にあります。 ソリューションを作成するために、CloudFormation テンプレートを使用して以下を準備します。 パブリックで利用可能なスナップショットからの SQL Server データベース用の Amazon RDS。 ステートマシン用の IAM ロール。 Step Functions アクティビティ。 Step Functions ステートマシン。 Step Functions ステートマシンを起動するための Amazon CloudWatch Events ルール。 CloudFormation テンプレートを使用して上記のリソースを準備した後に、以下の操作を実行します。 […]

Read More

AWSデータベース対応プログラムの紹介

新しいAWS Database Ready Programを導入し、ソフトウェアベンダーが彼らのソフトウェアを現代化し、Amazon Auroraをサポートできるようにします。 顧客は、商用データベースのライセンス費用を掛けずに、Amazon Auroraの性能、可用性、およびオープンソースの簡潔性を活用するクラウドネイティブアプリケーションを求めています。 AWS Database Readyは、元々AWSデータベースサービスで実行されるアプリケーションを使用してクラウド移行を加速することを可能にするものです。

Read More

Amazon Aurora を使用してエンドユーザーの待ち時間を 3 倍に改善する方法

  AWS で誕生 2011年の創業以来、我々の旅に加わっている InfoScout は AWS で誕生しました。友人や家族からアップロードされたレシートを収集する 1 つの Amazon EC2 インスタンス とともにすべてが始まりました。それから7年後、モバイルアプリケーション、データパイプライン、マシンラーニングモデル”→”機械学習モデル、SaaS 分析プラットフォームをサポートするため、現在では 150 以上の AWS インスタンスを管理しています。この記事では、増加するインフラストラクチャとデータベース移行での課題を詳細に分析しています。 我々のビジネスはシンプルです。日常の消費者がショッピングレシートの写真を撮影してクラウドにアップロードが可能なモバイルアプリケーションのポートフォリオを持っています。我々はこのデータを分析し、ブランド、小売業者、代理店、消費者パッケージ商品 (CPG) 企業の買い物客に深い識見を提供します。大規模なデータ収集に対するこの消費者中心のアプローチは、ブランドが最終的に非常に多くの問いの背後にある「なぜ」に答えることを可能にします。「なぜ、私のカテゴリーで売上高が 5% 減少したのでしょうか ? 」「このカテゴリーのどのような消費者シフトが私のブランドに売上に貢献しているのでしょうか ? 」「消費者のどのセグメントがオンラインに移行しているのでしょうか ? 」 米国では 500 回の購入で 1 回のキャプチャを行い、1 日に 300,000 枚のレシート画像をストリームします。 AWS でインフラストラクチャとアプリケーション全体を強化するために、Amazon EC2 、Amazon RDS 、Amazon S3 、Amazon VPC 、および Route 53 を大量に使用しています。2011 年にはカリフォルニア北部の single VPC 1 […]

Read More