Amazon Web Services ブログ

Category: Database

AWS DevDay Tokyo 2018 Database トラック資料公開

Database フリークな皆様、こんにちは!AWS DevDay Tokyo 2018 Database トラックオーナーの江川です。 2018 年 10 月 29 日(月)〜 11 月 2 日(金)にかけて、AWS DevDay Tokyo 2018 が開催されました。本記事では、11/1(木)に実施された Database トラックのセッション資料をご紹介します。 セッション資料紹介に先立ち、お客様セッションとしてご登壇いただいた、Sansan株式会社間瀬様、株式会社ソラコム安川様、Amazon Pay 吉村様にお礼申し上げます。併せて、ご参加いただいた皆様、ストリーミング配信をご覧いただいた皆様ありがとうございました。   ●お客様セッション資料 AWSサービスで実現するEightの行動ログ活用基盤(Sansan株式会社 間瀬哲也様) AWSサービスで実現するEightの行動ログ活用基盤 from Tetsuya Mase DynamoDB Backed なテレコムコアシステムを構築・運用してる話(株式会社ソラコム 安川 健太様) AWS Dev Day Tokyo 2018 | Amazon DynamoDB Backed な テレコムコアシステムを構築・運用してる話 from SORACOM,INC DynamoDBとAmazon Pay で実現するキャッシュレス社会 […]

Read More

【開催報告】AWS Data Lake ハンズオンセミナー 秋

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 9月21日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。前回行ったワークショップの3回目となります。前回も盛況でしたが、今回も80名近くのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスであるAmazon S3を中心とした Data Lakeについて解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、AthenaやRedshiftのAWSサービスを駆使して実際にラムダアーキテクチャを構築してみる、というのがゴールです。とはいえすべてを構築し切るのはボリュームが大きいため、コース別に取り組めるようにハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも4名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか?   次回は冬ごろに開催予定です。ご参加お待ちしております。

Read More

AWS Database Migration Service を使用して Amazon Aurora から Amazon S3 にデータをレプリケート

このブログ記事でご紹介するのは、AWS CloudFormation テンプレートを使って Amazon Aurora のようなリレーショナルデータベースから Amazon Simple Storage Service (Amazon S3) にデータをレプリケートできるよう、設定を自動化する方法です。CloudFormation テンプレートのサンプルを使って説明していくので、ニーズに合わせて応用してください。 AWS Database Migration Service (AWS DMS) を使えば、データをあるデータソースから別のデータソースに移行できます。たとえば、Oracle から Aurora、NoSQL から SQL、オンプレミスからクラウドへの移行などがあります。顧客が DMS を利用するのは 1 回限りのデータ移行の場合だけではありません。ETL プロセスの一部として継続的な異種データレプリケーションを行う場合にもよく利用します。それこそがこのブログ記事のテーマです。 ソリューションの概要 アーキテクチャを図で示します。 この CloudFormation テンプレートのサンプルは、この例に必須のすべてのリソースを記述しプロビジョニングします。コードは GitHub で探すことができ、テンプレートをスタックとしてデプロイするには [Launch Stack] ボタンをクリックします。注意: us-east-1 リージョンでは、このテンプレートは RDS DB クラスタースナップショットを使用します。スタックを別のリージョンにデプロイしたい場合は、希望するリージョンにスナップショットをコピーして、CloudFormation テンプレート内の SnapshotIdentifier の値を置き換えます。 このプロセスの開始からスタックが作成されるまでには、約 50 分ほどかかります。このテンプレートは下記の処理を行います。 AWS DMS Sample Database […]

Read More

Amazon RDS for MySQLの delayed replicationで障害から復旧を行う

Amazon RDS for MySQLでdelayed replicationをサポートしました。これにより、レプリカデータベースがソースデータベースより遅延する期間を設定できます。標準のMySQLレプリケーション設定では、ソースとレプリカの間の遅延が最小限に抑えられています。今回のアップデートで意図的な遅延を導入するオプションを選べるようになりました。 遅延は、人為的なエラーから復旧させる必要がある場合に非常に役立ちます。たとえば、誤ってプライマリデータベースからテーブルを削除した場合、レプリカで同じクエリを実行する必要はありません。テーブルが削除される直前でレプリケーションを停止し、レプリカをスタンドアロンインスタンスに昇格させることができます。このブログ記事では、delayed replicationを使用して、このようなシナリオから復旧させる方法をご紹介します。 次の図は、遅延が3600秒(1時間)に設定されたレプリカを人為的エラーから回復する方法を示しています。まず、レプリケーションを停止します。次に、ログの問題の箇所を見つけ、問題のクエリが実行される直前までトランザクションを実行し。最後に、レプリカをマスターに昇格させます。   前提条件 delayed replicationをチェックする前に、Amazon RDS for MySQLソースデータベースインスタンスでMySQL 5.6.40または5.7.22以降が必要です。また、インスタンスに接続するためのMySQLクライアントと、データベースにアクセスできる適切なセキュリティグループが必要です。 バイナリログを十分な時間保持していることを確認してください。バイナリログの詳細については、 MySQL Binary Logsを参照してください。次のコマンド例は、保持期限を24時間に設定する方法を示しています。 call mysql.rds_set_configuration(‘binlog retention hours’, 24);   シナリオの設定 既存のAmazon RDS for MySQLデータベースを既存のリードレプリカで使用するか、新しいデータベースを作成します。このブログ記事では、既存のRDS MySQLデータベースを利用し、新しい読み取りレプリカを作成します。 データベースの作成 MySQLインスタンス用のAmazon RDSをまだお持ちでない場合は、作成をしてください。クライアントマシンからのアクセスを許可するセキュリティグループを使用してデータベースを構成してください。作業したいMySQLデータベースがすでにある場合は、この手順をスキップしてください。 AWSマネージメントコンソール、AWS CLI、AWS SDK、またはAWS CloudFormationテンプレートを使用して、MySQLデータベース用のRDSを作成します。MySQLインスタンスの作成を支援する必要がある場合は、Create and Connect to a MySQL Database with Amazon RDSの手順に従ってください。次のスクリーンショットは、すでに設定されて使用可能な1つのデータベースインスタンスを示しています。 データベースに接続する マスターデータベース・インスタンスが作成されて使用可能になったら、そのデータベースインスタンスに接続します。Amazon EC2 Linuxマシンを使用している場合は、次のコマンドに示すように、いくつかの環境変数を設定して余分なタイピングを省くことができます。 export REGION=”us-west-2″ export […]

Read More

Amazon Dynamo DB グローバルテーブル 東京リージョン対応のお知らせ

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング エバンジェリストの亀田です。   Amazon DynamoDBのグローバルテーブル機能が東京リージョンに対応しましたのでお知らせいたします。 DynamoDBはどのような規模でも信頼性が高いパフォーマンスを維持できる、完全マネージド型の非リレーショナルデータベースです。グローバルテーブルの機能により、マルチリージョン、マルチマスターのデータベースを構築することが可能となり、そのレイテンシーを 10 ミリ秒未満に維持できるようになります。選択した AWS リージョンにテーブルの更新内容を自動的にレプリケーションすることができ、また、グローバルテーブルを使用して、DynamoDB テーブルデータを他の AWS リージョンにレプリケーションすることで可用性を高めることもできます。   作成済のDynamoDBテーブルを選択すると、「グローバルテーブル」のタブが出てきます。設定作業はテーブル作成後に行うこととなりますが、テーブルが空である必要があるのでご注意ください。 ここから、機能を有効にすることができます。機能を使うためにはDynamoDB Streamsの機能をオンにする必要があります。DynamoDB Streamsは、テーブルに対して発生した変更をキャプチャし、例えばAWS Lambdaを実行させるなどに機能をつかさどります。グローバルテーブルはこの機能を用います。 そして対象リージョンを指定すると、レプリカテーブルが指定したリージョンに作成されます。 DynamoDBは今年の5月に継続的バックアップとPITR(ポイントインタイムリカバリ)に対応しより使いやすくなっています。今回のグローバルテーブル対応で、より高度な耐障害性とリージョンワイドのアプリケーションへのより高速な対応性能を備えることなりました。 – プロダクトマーケティング エバンジェリスト 亀田

Read More

【開催報告】Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –

こんにちは。AWS ソリューションアーキテクトの八木達也 ( @ygtxxxx ) です。 7月23日に、「Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –」を開催いたしました。 AWSジャパン主催でデジタル広告業界の方向けのイベントを開催するのは2年ぶりでしたが、定員60人のところ55名の方にお集まりいただき、盛況となりました。             このイベントは「Digital Advertising、AdTech 領域における Machine Learningの実践知」を「互いに学び合う」ことができる場を作ることを目標としていたため、AWSメンバーによるプレゼンテーションだけではなく、お客様プレゼンテーションを中心としたAGENDAを構成しました。機会学習という領域における、テクノロジー視点でのお取組み、組織育成視点でのお取組み、それぞれの視点で最先端な活動をなさる方々よりご登壇を頂きました。 まずは主催者の唐木/八木よりオープニングセッションを行いました。 唐木より全体の説明を行い、八木より「Machine Learning for Digital Advertising」というタイトルでプレゼンテーションを行いました。 Machine Learning for Digital Advertising from Amazon Web Services Japan 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update from Amazon […]

Read More

1億2500万人のゲーマーをオンラインでスムーズにプレーするにはどうすればいいでしょうか?Epic GamesがFortniteについて語ってくれました。

FortniteのクリエイターであるEpic Gamesは、2018年7月17日にニューヨークのJavits Centerで開催されたAWSサミットでAWSサービスへオールインを明らかにしました。 ゲーム上に1億2500万人のプレイヤーを想像してください。1億2500万人、それはニューヨークの人口の15倍になります。マルチプレイヤーゲームをプレイしているすべての人が、夢を実現するでしょう。 プレイヤー全員が素晴らしい時間を過ごすことを保証しなければなりません。どのようにしてこの大変多くの人々のすべてのデータを取り扱うのでしょう? Epic GamesのFortnite クリエイターが今年、自分自身でそれを見つました。Fortomiteのこの驚異的な成長により、Epic Gamesが毎月2ペタバイトのデータを扱わなければいけないことを意味します。2,000テラバイトのハードドライブが積み上がっていることを想像してください。どのようにゲームデベロッパーがその規模の情報量を処理するでしょうか?

Read More

Database Migration Service を使用して、リレーショナルデータベースから Amazon Kinesis に CDC データをロードする

多くの大企業は、タイムリーな情報を得るために、データ処理をバッチ処理からリアルタイム処理に移行しています。そうすることの課題は、リアルタイムのデータ処理アーキテクチャが着信データストリームに追いつけなければならないということです。これには、強固な耐障害性と伸縮性が必要です。 このブログ記事では、リアルタイムのデータ処理アーキテクチャと、Amazon RDS for SQL Server データベースへの変更をキャプチャして Amazon Kinesis Data Streams に送信する方法について解説します。Amazon S3 および AWS Lambda をデータの初期ロードに使用する方法と、AWS Database Migration Service を進行中のレプリケーションに使用する方法を示します。 AWS では、Amazon Kinesis Data Streams、AWS Database Migration Services (DMS)、AWS Lambda などのデータ処理を適正に行うためのサービスを数多く提供しています。DMS は、既存のデータを移行し、進行中の変更データをソースシステムからターゲットシステムにレプリケートするのに役立ちます。 前提条件および仮定 このソリューションを自分で使用するには、AWS のサービスへのアクセスを提供する AWS アカウントが必要です。 サービスは us-east-1 リージョンで作成する必要があり、ネットワーキングの考慮事項を簡素化するために us-east-1 リージョンの同じ VPC で設定する必要があります。 Lambda 関数のコンパイル済み Java コードは、この Amazon Repository にある ZIP ファイルに含まれています。S3 バケットを作成し、ZIP […]

Read More

Autodesk が Amazon Aurora を使用してデータベースのスケーラビリティを向上させ、レプリケーションラグを削減した方法

Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアのリーダーです。Autodesk は物を作る人のためのソフトウェアを作成しています。高性能の車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万人もの Autodesk ユーザーがソフトウェアで行っていることを体験したことがあると思われます。 Autodesk は Amazon RDS で稼働するマネージド MySQL データベースと Amazon EC2 でホストされるセルフマネージド MySQL データベースの両方からAmazon Auroraに移行しました。このブログ記事は、その経験をまとめ、次の点について取り上げます。 Autodesk の Amazon Aurora への移行決定に影響を与えた要因 移行上の特定の利点 移行と最適化に関して学んだベストプラクティスと教訓 まず、クラウドで生まれた Autodesk Access Control Management (ACM) アプリケーションの移行パスを確認します。始めに Amazon RDS for MySQL を選択し、スケーラビリティ、可用性、およびパフォーマンスを向上させるために Aurora に移行しました。ACM が移行を問題なく完了させたことで、Autodesk の他のいくつかのアプリケーションが Aurora に移行する意欲が高まりました。EC2 でホストされているセルフマネージド MySQL データベースを Amazon Aurora に移行する主要な例として、BIM 360 Field Classic について説明します。 […]

Read More

統合ワークロードに向けた MySQL と互換性がある Amazon Aurora を計画・最適化する方法

MySQL と互換性がある Amazon Aurora はデータベースワークロード統合を検討中のお客様から好評をいただいています。Aurora MySQL は、ハイエンドな商用データベースの速さや信頼性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。また Aurora MySQL は、標準の MySQL Community Edition に比べ最大 5 倍のスループットを実現します。 今回のブログ記事では、大規模な統合データベースワークロードのために行う Amazon Aurora の最適化に役立つガイダンスをいくつかお伝えします。また、「統合の費用はどれくらいかかりますか?」や「データセットはどのくらいの大きさにできますか?」など、よくある質問にお答えします。 上記の質問はシンプルですが、必ずしも回答がシンプルになるわけではありません。回答は、お使いのデータセットやワークロードのパターンによって大きく異なります。 データベース統合の定義 統合のユースケースに関しては、以下の要素に的を絞り、それからコンテキストに応じた Aurora MySQL の操作方法について詳細を説明します。 テーブルのサイズ。統合により、一般的にテーブルは大きくなります。アドテック、IoT、消費者向けアプリケーション分野の場合、通常は大きな同種アプリケーションのデータベースをそれぞれにデータのサブセットが含まれる大量のシャードに分割します。Aurora ではシャーディングを完全になくすことはできないかもしれませんが、より少数のシャードに統合して操作上のオーバーヘッドを減らすことができます。 テーブルの数。テーブル数の増加も、統合の結果見られることです。この結果は、各テナントが通常、独自のデータベースまたはテーブルセットを有する場合にテナントの分離が必要な SaaS アプリケーションで一般的なものです。このタイプの複数のテナントは数が少なくより大きな Aurora クラスターにまとめられ、テナントあたりの操作コストを削減します。 データベースの使用率。さらに多数の同時接続を行うなど、統合データベースワークロードの使用率が多くのメトリクスで増加します。 実際には、同じプロジェクト内の複数の要素で使用率が増加することになります。以下のガイドラインは、各要素でワークロードを最適化するのに役立つはずです。 「大きい」とは具体的にどのくらいのサイズですか? Amazon Aurora には最大容量に制限があります。私たちの最も重要な成果は、Aurora クラスターで 64 TB という最大の保存容量です。最大容量により、Aurora クラスターに物理的に保存できるデータ量の上限が決められます。また、個々のテーブルの大きさについて上限が決められます。 加えて、MySQL と互換性があるデータベースエンジンとして、Aurora MySQL は MySQL と InnoDB ストレージエンジンから多くの特徴を受け継いでいます。これらの特徴には効果的な統合に影響を与えるものがあります。 大きなテーブルサイズを最適化する方法 Amazon Aurora […]

Read More