Amazon Web Services ブログ

Category: Database

Amazon DynamoDB On-Demand – 事前のキャパシティプランニングが不要のリクエスト課金が可能になりました。

少し前まで、あなたのビジネスに合わせていつでもスケールし安定した低いレイテンシを提供するデータベースを作成することは困難でした。2012年にWerner VogelsがpostしたブログでAmazon DynamoDBがアナウンスされました。(これは私がAWSに入る数ヶ月前の事でした。)DynamoDBは2007年にAmazonが公表したDynamoの論文に基づいて設計されています。それから数年、多くの新機能がAWSの顧客が利用するデータベースを更に簡略化するために導入されました。今、フルマネージドかつマルチリージョン、マルチマスターデータベースとencryption at rest、point-in-time recovery、in-memory cachingなどの機能、そして99.99%のuptime SLAを提供しています。 Amazon DynamoDB On-Demand 今日我々はAmazon DynamoDB on-demand、事前のキャパシティプランニングが不要で1秒あたり数千リクエストのトラフィックにも対応が出来るフレキシブルな課金を実現する新しいオプションを案内します。DynamoDB on-demandはシンプルなpay-per-request課金モデルを提供しreadリクエストとwriteリクエストを使った分に応じて支払うだけになります。これによりシンプルなコスト計算とパフォーマンス管理を実現します。例えばtableにon-demanmd modeを適用すると、DynamoDBは即座に対応しワークロードに応じて以前に観測されたトラフィックレベルまで処理できるようにパフォーマンスを調整します。また新たなピークトラフィックが観測されたときはDynamoDBはワークロードに対応するために迅速に適応します。(翻訳者注: DynamoDBは内部的にパーテーションという概念で負荷を分散します。そのため一度拡張されたテーブルは内部的に何もしなくても拡張された状態を維持している事と、新たな負荷が発生したときも自動的に拡張して対応します。) DynamoDBのコンソールを見るとon-demand read/wriite capacity modeが新規テーブル作成時と既存テーブルのCapacityタブに追加されている事が確認出来ます。 on-demand modeを適用したTableは全てのDynamoDBの機能がサポートされ(例としてencryption at rest、point-in-time recovery、global tablesなど)、例外としてauto scalingはこのmodeでは無効になります。 on-demand modeが有効な状態でセカンダリインデックスを構築した場合も同じスケーラビリティと課金モデルが適用されます。セカンダリインデックスへも使った分だけお支払い頂き事前にキャパシティプロビジョニングする必要はありません。もしon-demand modeが有効なtableでread/writeリクエストが発生しなかった場合、支払う必要があるのはストレージ課金のみになります。 DynamoDBは予測困難なアプリケーショントラフィックへの対応や短期間で大きなスパイクが発生するワークロード、もしくはあなたのテーブルの使用率が平均では低い場合にとても有効です。例えば以下のようなユースケースです。 新たなアプリケーション開発時、もしくはワークロードが複雑で予測が困難な場合 pay-per-use な課金モデルのサーバレスサービスとの組み合わせ SaaSプロバイダやソフトウェアベンダーでシンプルかつリソース分離を必要とするようなアプリケーションを開発している on-demand modeへの変更は1日1回可能です。on-demandからprovisioned modeへの変更も可能です。 簡単にパフォーマンステストをやってみましょう では早速新たに作ったDynamoDB on-demand modeのtableに対して負荷テストを実施してみましょう。 私は2つのサーバレスアプリケーションを作ってみました。 1つ目のアプリケーションはAmazon API GatewayとAWS LambdaでHTTPインターフェイスによるDynamoDBに対してread/writeする処理を実装しています。 2つ目のアプリケーションはLambdaで1000個の並行に同時実行でランダムにHTTPメソッドを生成しendpointに各Itemに操作リクエストを生成するファンクションです。 全てのファンクションは同時実行数100でリクエストを実行し、終了するとすぐにまた別の100同時実行がスタートする処理を一分間行います。ランプアップするために必要な時間は無く、負荷の生成はフルスピードで実行されます!! DynamoDB コンソールのメトリクス tabから、ピーク時には5000request/secの負荷が流れていることとスロットリングが発生しないことをメトリクスから確認ができます。 サーバレスアプリケーションがscalingするか、API GatewayとLambdaとDynamoDBはフルマネージドで対応が出来ています。スループットやアプリケーションロジックに寄る課金の仕組みを計画する事はなく実現出来ました。 […]

Read More

新機能 – DynamoDB Transactions

Amazon DynanmoDBがローンチされてから多くのユースケースで使われてきました。microservicesやゲームなどのモバイルバックエンドシステム、IoTソリューションなど様々です。例えばCapital Oneのユースケースではモバイルアプリケーションから使われていたメインフレームの処理をサーバレスアーキテクチャに移行しレイテンシの軽減にもなりました。TinderはDynamoDBにゼロダウンタイムで移行し、世界中のユーザーのために必要なスケーラビリティを獲得しました。 開発者の多くはビジネスロジックの実装に複数のItemを操作し、all-or-nothingな結果を一つか複数のtableにまたがって行いたいと思う場面があると思います。要件によっては実装に不必要な複雑さが加わることがあります。今日、我々はこのユースケースに対応するためにDynamoDBにtransaction機能をネイティブサポートしました! Amazon DynamoDB Transactionsについて DynamoDB transactionsは開発者に原子性、一貫性、分離性、永続性(ACID)を保証した操作を一つか複数のテーブルに対して提供します。一つのAWSアカウントの単一リージョンで行います。アプリケーションからinsert、delete、updateを複数のアイテムに対して実施出来る事でビジネスロジックの操作を一回のリクエストで実行出来ます。DynamoDBは、複数のパーティショニングとテーブル間でトランザクションをサポートする唯一の非リレーショナルDBです。 TransacstionsはDynamoDBを利用してより広いワークロードに対してエンタープライズレベルでのbenefitとスケール、パフォーマンスをもたらします。多くのユースケースではすぐに簡単にtransactionsを利用することが可能です。例えば 金融取引 商品の受注から決済までの管理 マルチプレイヤーでの操作を提供するゲーム 複数のコンポーネントによる操作を行うシステム 2つ目にDynamoDBのオペレーションでどうtransactionsを扱うのか紹介します。 TransactWriteItems 書き込みを含む操作で利用します。一つか複数のPutItem、UpdateItem、そしてDeleteItemオペレーションをサポートします。TransactWriteItemsは指定した前提条件にマッチするかをチェックしてから更新することも可能です。これらの条件には書き込みセット内で同一Itemや異なるItemが含まれる場合があります。いずれかの条件が満たされない場合トランザクションはリジェクトされ失敗します。 TransactGetItems 読み込みを含む操作で利用します。一つか複数のGetItemオペレーションをサポートします。もしTransactGetItemsリクエストで対象となっているItemがTransactWriteItemsで書き込まれている最中は読み込みトランザクションはキャンセルされます。書き込みトランザクション処理前の値は取得可能なので通常の読み込み操作は可能です。 これらのトランザクションはユニークな10個のItemと最大4MBのデータ、条件付き書き込みがサポートされます。 この機能を利用してDynamoDBは、さまざまなアプリケーション要件を満たす複数の読み取りと書き込みのオプションを提供し、複雑なデータ駆動型ビジネスロジックを実装する開発者に大きな柔軟性を提供します。 3種類の読み込みオプション – 結果整合性の読み込み、強力な整合性のある読み込み、そしてトランザクションによる読み込み 2種類の書き込みオプション – 通常書き込みとトランザクションによる書き込み たとえば、仮想コインでアイテムを購入できるゲームを構築しているとします。 player tableでは、各playerは多数のコインと購入したアイテムの在庫を持っています。 itemsテーブルでは、各アイテムに価格が設定され、boolean値で使用可能(または使用不可)としてマークされます。 ゲーム内で商品を購入するフローの場合にアトミックトランザクション処理を実装出来ます。 始めに商品があるかを確認し、プレイヤーに必要な残高があるか確認する これらの条件が満たされている場合、商品を在庫無しに変更し所有者をプレイヤーに変更 支払ったアイテムをプレイヤーの持ち物リストに追加する JavaScriptを用いた例として、AWS SDK for JavaScript in Node.jsで例を見てみましょう。 data = await dynamoDb.transactWriteItems({ TransactItems: [ { Update: { TableName: ‘items’, Key: { id: […]

Read More

Oracle Database による AWS Database Migration Service と Accelario によるダウンタイムゼロの移行

これは Accelario の共同設立者で副社長の R&D の マイケル・リトナー (Michael Litner) のゲストポストです。 Accelario は、Amazon Web Services(AWS)に Oracle データベースを簡単かつ迅速にロードするためのデータベース移行ソフトウェアです。初期ロードの終了時に、AWS Database Migration Service (AWS DMS)を使用してデータベースの同期がすぐに開始されます。その結果、データベースのダウンタイム移行がゼロ になります。 データベースのクラウド移行時には、週7日24時間(無休)業務を必要とする事業は大問題に直面しています。これまでのところ、ダウンタイムを最小限に抑えるための経費効率の高いオプションはほとんどありませんでした。Accelario は、AWS DMS との最近の統合により、すぐに使用できるゼロダウンタイムのフルデータベース移行ソリューション、つまり、ユーザー、手順、ビューなどのデータベース全体が移行を提供します。プロセスが完了すると、データベースにアクセスしてアプリケーションで即座に使用することができます。 そのような事業に影響を及ぼすもう1つの重大問題は、機密情報がプロセスの一部として公開されないようにすることです。これは、データ保護ポリシーや規制の遵守にとって重要です。Amazon Relational Database Service (Amazon RDS)でサポートされている Oracle の組み込み機能(ネットワーク・データ暗号化を含む)を使用して、転送中のデータの暗号化を実現できます。 本投稿では、この組み合わせソリューションを使用してデータベースを Amazon EC2 または Amazon RDS(データマスキングも使用)に移行する方法について説明します。また、クラウドに入った後に簡単にデータベースをリフレッシュする方法についても説明します。 仕組みの説明 Accelario は論理的な移行を実行します。それはソースデータベースを読み取り、その内容を解析して宛先にコピーします。エンジンはデータ自体がソースからデスティネーションに直接流れて、移行プロセスを調整します。Accelario は、データベース内のすべてのオブジェクトタイプ(表、索引、パッケージ、順序、許可、表スペースなど)を処理します。 この初期ロードの終了時に、Accelario は AWS 上の新しいターゲットとソース間の 進行中の変更 を複製するAWS DMS 環境を自動的に構築します。複製が同期された後、いつでもカットオーバを要求できます。 大規模なデータベースでこのソリューションを使用する場合のベストケース 大規模なデータベース移行で Accelario を使用する一般的なシナリオを次に示します。 […]

Read More

AWS Database Migration Serviceを使用し、Amazon Kinesis Data Streamingを実施する

この投稿では、AWS Database Migration Service (AWS DMS) を使用し、Amazon Kinesis Data Streamsに変更データをストリーミングする方法について議論します。 以前の投稿 Load CDC Data では、データ処理アーキテクチャについてリアルタイムで議論しました。その一環として、AWS DMS を使用して Amazon RDS for Microsoft SQL Server のデータベースの変更を取得し、AWS Lambdaを使用して Kinesis Data Streams に送信する方法について扱いました。AWS DMS のターゲットとしての Kinesis Data Streams の開始により、変更データの取得データ(CDC)のストリーミング、分析、および格納がより簡単になりました。DMSは、成功事例を使用してデータからの変更を自動的に収集し、それを Data Streams にストリーミングします。 Kinesis Data Streamsをターゲットとして追加したため、お客様がデータレイクを構築し、データストアからデータを変更してリアルタイムで処理することができます。 データ統合パイプラインで AWS DMS を使用して、ほぼリアルタイムで Kinesis Data Stream にデータを複製できます。このアプローチを使用すれば、アプリケーションを高価なデータベース上に構築しなくても、デカップリングされ、最終的に一貫したデータベースビューを構築が可能になります。 リアルタイムの変更データのアーキテクチャ 数多くの組織がKinesis Data ストリームを使用して変更データを分析し、Webサイト、不正検出、広告、モバイルアプリケーション、IOTなどを監視しています。 この投稿では、AWS DMSを使用して関連データベースの変更データを Kinesis Data […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するベストプラクティス: 移行プロセスとインフラストラクチャに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログシリーズでは、ソースの Oracle データベースとターゲットの PostgreSQL サービス、そして AWS Database Migration (AWS DMS) サービスについて、その環境と構成の設定方法をお伝えしています。特に焦点を当てているのが、ソースおよびターゲットデータベースのインフラストラクチャと設定、そして開発からテスト、本稼働、ステージングデータベースまでの各環境の移行に使用するツールと構成です。まずは、Oracle から、PostgreSQL との互換性がある Amazon RDS for PostgreSQL または Amazon Aurora ベースのデータベースへのデータ移行から始めることにします。 環境はそれぞれ異なりますが、機能は共通です。このシリーズのブログ記事では、各コンポーネントについて、データベースを移行する際に考慮する概要情報をお伝えするにとどめています。アプリケーションのコンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事 Database Migration—What Do You Need to Know Before You Start? をお読みください。 このシリーズには 3 つのブログ記事があり、それぞれで移行の 3 段階を扱っています。 ステージ 1: 移行プロセスとインフラストラクチャに関する考慮事項。この記事では、ソースサーバーのインフラストラクチャ設定について説明しています。移行プロセスの概要レベルについても触れており、Oracle データベースとクライアントハードウェアおよびオペレーティングシステムに適宜アクセスする必要があります。 ステージ 2: Oracle および AWS DMS […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行するための成功事例: Oracle および AWS DMS CDC 環境のソースデータベースに関する留意事項

AWS クラウドにおける Oracle から PostgreSQL への移行は、評価段階からカットオーバー段階まで、さまざまな技術とスキルを伴う複雑な多段式のプロセスになる可能性があります。伴う複雑さの内容をさらに詳しく理解するには、AWS データベースのブログ投稿をご参照してください。データベースの移行 – 開始する前に知っておくべきこととは? このブログの投稿は一連の投稿の 2 回目です。前回の移行プロセスとインフラストラクチャに関する留意事項では、移行プロセスの準備について、そして最適なパフォーマンスを手に入れるためのインフラストラクチャ設定の注意点について説明しています。この 2 回目の記事では、元の Oracle データベースの構成と環境を両方とも 1 回の移行と、 change data capture (CDC) という方法による継続的なレプリケーションで設定する方法について説明しています。ソースデータベースの変更を保存するために Oracle DB コンポーネントを適切に設定することにより、思い通りに AWS Database Migration Service (AWS DMS) のサービス環境を構築することができます。このシリーズの3回目となる最後のブログ記事は、AWS DMS を使用したデータベース移行プロセスのエンドポイントである、ターゲットのPostgreSQLデータベース環境の設定を取り上げます。 AWS DMSは、Amazon RDSまたはAmazon EC2のデータベースのオンプレミスデータベースを Amazon RDS またはAmazon Auroraデータベースに移行するためのサービスです。Amazon DMS は、 Oracle から Oracle への同機種間の移行や、 AWS クラウドの Oracle から MySQL 、PostgreSQL […]

Read More

Oracle データベースを Amazon RDS PostgreSQL または Amazon Aurora PostgreSQL に移行する上でのベスト プラクティス: PostgreSQL 環境のターゲット データベースに関する考慮事項

AWS クラウドで Oracle から PostgreSQL に移行するプロセスは何段階もあって複雑になりがちです。評価ステージから切り替えステージまで、さまざまなテクノロジーとスキルが必要になります。このブログ記事は、データベース移行で考慮すべきコンポーネントに関する高水準の側面について説明するシリーズの第 3 回です。このシリーズでは、アプリケーション コンポーネントや各種のシナリオについて、込み入った複雑な点までは取り上げていません。利用状況に応じて大きく変わるからです。細かい点まで深く把握する必要がある場合は、AWS Database ブログの記事「データベースの移行—始める前に知っておく必要のある事柄」をお読みください。 以前の記事、「移行プロセスとインフラストラクチャに関する考察」および「Oracle および AWS DMS CDC 環境でのソース データベースの考察」では、Oracle データベースの構成方法について説明しました。この考察には AWS Data Migration Service (AWS DMS) および AWS Schema Conversion Tool (AWS SCT) のセットアップが含まれていました。これらの設定後、かつデータ移行の開始前に、ターゲットの PostgreSQL データベースを、関連するすべてのスキーマとパラメータを使って起動および稼動させる必要があります。 このシリーズの最後のブログ記事では、AWS DMS と AWS SCT を使用して Oracle データベースからの移行を支援するために PostgreSQL 環境を設定する方法の概要を示します。この記事では、移行セットアップに役立つ PostgreSQL データベースパラメータの構成について説明します。 移行環境では、高可用性、スケーラビリティ、アーカイブ、バックアップ、負荷分散、およびロールバックのための戦略を採用することもお勧めします。これらの戦略については、この記事では扱いません。また、データベース移行の手動部分については触れません。独自の要件やアプリケーションの依存関係の複雑さに合わせて調整できるステップバイステップの手順も含まれません。これらの詳細については、「PostgreSQL を使用した Oracle Database 11g/12c から Amazon Aurora […]

Read More

AWS Dev Day Tokyo 2018 セキュリティセッション & ワークショップ 開催レポート

  皆様、こんにちは。セキュリティソリューションアーキテクトの桐山です。 2018/10/29(月)から11/2(金)にかけて開催されたAWS Dev Day Tokyo 2018で実施された、セキュリティ関連のセッションとワークショップをおさらいしてみます。 開発者向けカンファレンスということで、この度はセキュリティに興味のある多くの開発者にご参加いただきました。これから企業がデジタルトランスフォーメーション(DX)時代に向かっていく中、開発者の役割も更に高度化・専門化しています。 事業部門で、いわゆるSysmem of Engagement(SoE)領域に携わる開発者は、下記のような今までにない新しいワークロードをセキュアに開発することに挑戦しているでしょう。 IoTサービスにより、様々なデバイスから大量の信頼性の高い実データを収集する 企業内データを一元的に集約・保存する場所(データレイク)をセキュアに管理・運用する 迅速にビジネスインサイトを活用するために、データ分析・可視化・利用をサーバーレスコンピューティング環境で実現する 上のそれぞれに相当するIoTセキュリティ、データレイクセキュリティ、サーバーレスセキュリティは新しいセキュリティ技術領域と言えます。 一方で、IT部門にて、いわゆるSystems of Record(SoR)領域に携わる開発者は、事業成長を支えるセキュリティ基盤を実現しなければなりません。ITインフラ自体を変革させると同時に、事業活動の変化やスピードに対応するためにSecurity as a ServiceやSecurity Automationに取り組むことになるでしょう。 このようなDX時代のセキュリティをAWSで実現するとしたら・・・以下のワークショップとセッションが役に立つはずです。

Read More

RDS データベースに汎用 IOPS またはプロビジョンド IOPS のどちらを使用するかを決定するための CloudWatch メトリクスの使用方法

 このブログ記事では、最高のパフォーマンスのミッションクリティカルなデータベースワークロードに対して、IO1 としても知られるプロビジョンド IOPS からメリットを得ることができる機会を把握するために Amazon CloudWatch メトリクスを使用する方法について説明します。まず、バーストを生じない一貫性のある高書き込みワークロードをシミュレートするテストケースをセットアップすることから始めます。今回は、価格とパフォーマンスのバランスを保つ、GP2 ボリュームとしても知られる汎用ストレージを使ったデータベースと、IO1 ボリュームを使ったデータベースのパフォーマンスを比較します。次に、対応する CloudWatch メトリクスが明らかにする事柄と、ワークロードのパフォーマンス結果をご覧いただきます。 数ヵ月前、GP2 ボリュームでのバーストバランスとベースラインパフォーマンスを説明する Understanding burst vs. baseline performance with Amazon RDS and GP2 という素晴らしいブログ記事が AWS データベースブログに掲載されました。GP2 ボリュームはプロビジョニングが簡単で使いやすく、低価格です。これは、GP2 ボリュームが必要時にパフォーマンスをバーストさせ、散発的なワークロード、または待機時間が発生する可能性を許容できるアプリケーションを上手く処理できることが理由です。開発、機能テスト、およびサンドボックスなどの環境では、偶発的な負担がかかる場合でさえも GP2 の使用には何ら問題がありません。絶えず負担がかかるデータベースワークロードについては、プロビジョンド IOPS ボリュームがプロビジョニングするレベルでの持続的なパフォーマンスとスループットを提供します。 前提条件 始める前に、先ほど紹介した GP2 バーストパフォーマンスについてのブログ記事、Understanding burst vs. baseline performance with Amazon RDS and GP2 を十分に検討してください。 この記事にあるコードを一通り実行したい場合は、アカウント内に同一の Amazon RDS for MySQL データベースを 2 つ作成してください。ひとつのインスタンスには […]

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