Amazon Web Services ブログ

Amazon RDS for PostgreSQL では、読み込み負荷を取り除き、災害復旧 (DR) リソースを作成するために、ソース PostgreSQL インスタンスのレプリカを簡単に設定することができます。リードレプリカは、ソースと同じリージョン、または異なるリージョン内に設定できます。 RDS PostgreSQL リードレプリカインスタンスを使用すると、読み込みワークロードをレプリカインスタンスにオフロードすると同時に、書き込みアクティビティのためにソースインスタンスのコンピューティングリソースも確保します。ただし、レプリケーション遅延を避けるには、リードレプリカを正しく設定し、適切なパラメータ値を設定する必要があります。 概要 この記事では、リードレプリカを正しく設定するためのベストプラクティスをいくつかご紹介します。リージョン内、クロスリージョン、および論理レプリケーションなどのさまざまな RDS PostgreSQL レプリケーションオプションの長所と短所を取り上げ、適切なパラメータ値と、監視するメトリクスを推奨します。以下のステップでは、レプリケーション遅延を最小限に抑えながら、DR 戦略、読み込みワークロード、および健全なソースインスタンスを最適化する方法を説明します。 一般的な推奨事項 全体的なベストプラクティスとして、リードレプリカで実行するリードクエリが、ソースインスタンスとしてデータの最新バージョンを使用することを確認してください。データバージョンは、Amazon CloudWatch メトリクスでレプリケーション遅延を調べることによって確認できます。レプリケーション遅延を最小限に抑えることによって、古いデータに基づいたクエリ出力と、インスタンスの健全性に対するリスクの両方を避けることができます。 リージョン内のレプリケーション RDS PostgreSQL は、ソースインスタンスと同じ AWS リージョン内でリードレプリカを作成するために Postgres ネイティブストリーミングレプリケーションを使用します。ソースインスタンスでのデータの変更は、ストリーミングレプリケーションを使ってリードレプリカにストリームされます。このプロセスが何らかの理由で遅れると、レプリケーション遅延が発生します。以下の図は、RDS PostgreSQL が同じリージョン内のソースとレプリカの間でレプリケーションを実行する方法を示しています。 この後のセクションでは、同じリージョン内でホストされている RDS PostgreSQL インスタンスを最適にレプリケートするために Postgres インスタンスを調整する方法について説明します。 適切な wal_keep_segments の値 Postgres では、wal_keep_segments パラメータで pg_wal ディレクトリに保存される WAL ログファイルセグメントの最大数を指定します。Postgres は、このパラメータを超える WAL セグメントを Amazon S3 バケットにアーカイブします。 リードレプリカが […]

前回の記事、「Microsoft Excel を使用した AWS DMS タスクのための AWS CloudFormation テンプレートの作成」をさらに詳しく説明するこの記事では、データベース移行を迅速化することができる、同じツールの拡張機能を取り上げます。 この機能を実証するため、Python で記述された小型のコマンドラインツールをご紹介します。このツールは、入力としての使用するために、移行されるテーブルの名前、AWS DMS エンドポイントの Amazon リソースネーム (ARN)、および DMS レプリケーションインスタンスが含まれた CSV ファイルを取り込みます。正常に実行されたら、このツールは、必要な DMS タスクの AWS CloudFormation テンプレートを出力として生成します。ただし、このツールは DMS エンドポイントとレプリケーションインスタンスの作成には対応しません。 前提条件 このツールを使用するには、以下のリソースが必要となります。 Python (バージョン 2.7 以降)。Python 2.7.15 をインストールするには、Python.org のダウンロードページをご覧ください。 DMS のソースエンドポイントとターゲットエンドポイント、および DMS レプリケーションインスタンス。 CSV テンプレートの作成 最初に、作成する DMS タスクに関するすべての情報を CSV ファイルに取り込みます。以下は、DMS タスクを作成するために必要な項目のリストです。 DMS タスクの名前 ソースエンドポイント ターゲットエンドポイント 使用するレプリケーションインスタンス 移行するテーブルのスキーマ名 移行するテーブルの名前 […]

AWS はあらゆる開発者が機械学習を手にすることを目指しています。たとえば、コンピュータビジョンや言語などの分野向けに、事前トレーニング済の AI サービスを提供しており、これで機械学習の専門知識がなくても AI の利用が可能となります。本日より Prediction という新しいカテゴリを追加し、この目標に向かって Amplify フレームワークはさらに前進しました。この結果、ほんの数行のコードで、ウェブおよびモバイルアプリケーション向けの AI/ML ユースケースの追加や設定が可能となりました。 AWS Amplify とは、AWS でモバイルアプリケーションとウェブアプリケーションを簡単に構築するための開発フレームワークと開発者用サービスです。オープンソースの Amplify フレームワークは、ライブラリ、ユーザーインターフェイス (UI) コンポーネント、コマンドラインインターフェイス (CLI) の個性豊かなセットを提供しています。これで、クラウドバックエンドを構築し、それをウェブアプリケーションやモバイルアプリケーションと統合できるようになります。 Amplify ではストレージ、認証と承認、API (GraphQL や REST)、分析、プッシュ通知、チャットボット、AR/VR などのカテゴリにある AWS のサービスの中核となるセットを活用しています。 Amplify フレームワーク CLI を使用すれば、Amplify init で対話的にプロジェクトを初期化できます。その後、ストレージ (Amplify add storage) やユーザー認証と承認 (Amplify add auth) のオプションを選択できます。 こうして、amplify add predictions を使ってアプリを次のように設定できるようになります。 イメージ内のテキスト、エンティティ、ラベルを識別するには Amazon Rekognition を、フォーム内のフィールドのコンテンツおよびテーブルに格納した情報を取得するには Amazon Textract を使用します。 テキストを別の言語に変換するには […]

2011 年の初めに、AWS CloudFormation が AWS CloudFormation – Create Your AWS Stack From a Recipe および AWS CloudFormation in the AWS Management Console という 2 つの記事でローンチされました。このローンチ以来、AWS は CloudFormation が効率性、スケーラビリティ、かつ高可用性を確保できるように、数多くの AWS リソースタイプに対するサポートを追加し、数多くの新機能をローンチして、舞台裏で作業を続けてきました。 公開カバレッジロードマップ CloudFormation の使用は AWS そのものよりも急速に拡大しており、チームは完全なリソースカバレッジよりもスケーラビリティを優先してきました。AWS の 100% カバレッジの提供という目標はそのままですが、その目標を達成するにはしばらく時間がかかるというのが現実です。AWS の優先順位についてより透過的になり、それらを管理する機会をユーザーに提供するため、皆さんに待望の CloudFormation Coverage Roadmap についてお知らせしたいと思います。 人気の AWS コンテナロードマップのスタイルを模した CloudFormation Coverage Roadmap には、4 つのカラムがあります。 Shipped – すべてのパブリック AWS […]

AWS re:Invent 2018 にて発表された Amazon SageMaker Ground Truth を使用すると、機械学習 (ML、machine learning) システムのトレーニングに必要なデータセットを、効率的かつ正確にラベル付けすることが可能になります。Ground Truth にはラベル付けのワークフローが組み込まれており、ラベル付けワーカーは、それによってステップバイステップでタスクを実行したり、成果をあげるのに役立つツールを利用したりすることができます。組み込まれたワークフローは現在、物体検出、画像分類、テキスト分類、セマンティックセグメンテーションによるラベル付けジョブで利用可能です。 そして本日より AWS は、新しいユースケースである固有表現抽出 (NER、named entity recognition) のサポートを開始しました。NER とは、テキストデータを選別して固有表現と呼ばれる名詞句を特定し、「人」「組織」「ブランド」などのラベルによってそれぞれを分類する作業のことです。 たとえば「私は最近 Amazon プライムに登録した」というテキストがあった場合、「Amazon プライム」が固有表現とみなされ、「ブランド」として分類されます。 こうしたユースケースを拡大して、あらかじめ規定されたラベルを使って、もっと長いテキストのラベル付けや配列の分類を行うことが可能です。例として、次のスクリーンショットをご覧ください。パフォーマンス評価のテキストにおいて、Amazon のリーダーシッププリンシプルである「Customer Obsession」についての言及箇所が特定されています。 概要 この記事では、NER のラベル付けジョブの作成方法について解説していきます。 データセットを収集します。 ラベル付けジョブを作成します。 労働力を選択します。 タスクの指示を作成します。 今回の例では、NER のラベル付けタスクとして、データセットからブランド名の特定を行います。サンプルのデータセットとして、Amazon の Twitter アカウントから 10 個のツイートを用意しました。これを使用してもいいですし、自分でデータセットを用意して、個々のユースケースに関連した NER のラベル付けタスクを定義してもらっても構いません。 前提条件 以下の手順を実行するには、AWS アカウントを所有していて、AWS のサービスにアクセスできることが前提となります。 ステップ 1: データセットを収集して Amazon S3 に保存する […]

オープンソースの Amplify フレームワークは、ライブラリ、ユーザーインターフェイス (UI) コンポーネント、およびコマンドラインインターフェイス (CLI) のセットを提供します。AWS CloudFormation を使用してバックエンドリソースをプロビジョニングすることにより、洗練されたクラウド機能をウェブまたはモバイルアプリに簡単に追加できます。 お客様とお話しするときに、新しい機能を追加したりバグを解決したりするときは、できるだけ早く反復して、操作からすばやくフィードバックを得ることが重要だという話をよく耳にします。開発体験はどのように改善できますか? さて、先週、Amplify チームは新しい Predictions カテゴリを作り、機械学習機能をウェブまたはモバイルアプリにすばやく追加できるようにしました。今日、彼らは再び改善を試みます。Amplify CLI を使用して、提供している中で最も一般的なクラウドサービスの一部をモックし、アプリケーションをローカルで 100% テストできるようになりました。 ここでモックするということは、実際のバックエンドコンポーネントを使用する代わりに、クラウドサービスの場合は API を使用する代わりに、その API のローカルで単純化されたエミュレーションを代わりに使用できることを意味します。このエミュレーションは、開発中のテストに必要な基本機能を提供しますが、本番サービスから得られる完全な動作は提供しません。 この新しいモック機能を使用すると、すべてのステップで使用しているクラウドリソースをプロビジョニングまたは更新する必要なく、変更をすばやくテストできます。この方法で、クラウドバックエンドに影響を与えることなく、迅速に実行できる単体テストと統合テストを設定できます。アプリのアーキテクチャに応じて、バックエンドリソースをプロビジョニングせずに CI/CD パイプラインで自動テストを設定できます。 これは、Apache Velocity Template Language (VTL) で記述されたAWS AppSync リゾルバマッピングテンプレートを編集するときに非常に便利です。リクエストを入力として受け取り、リゾルバの指示を含む JSON ドキュメントを出力します。これで、編集内容に関するフィードバックをすぐに受け取ることができ、更新するたびにデプロイを待つことなく、リゾルバが期待どおりに機能するかどうかをテストできます。 最初のリリースでは、Amplify CLI をローカルでモックできます。 リゾルバマッピングテンプレートおよび Amazon DynamoDB がサポートするストレージを含む AppSync GraphQL API。 AWS Lambda 関数は、直接または GraphQL API のリゾルバとして呼び出されます。 アプリケーションのストレージとして使用する Amazon Simple […]

対話をサポートするためボットを構築しようとした人なら、会話の流れの管理がいかに難しいかを理解できるでしょう。リアルなユーザー (明らかにスクリプトをリハーサルしていないユーザー) の会話は、途中で本題からそれることがあります。リアルなユーザーは今話しているトピックに関連した質問することもあれば、まったく新しい会話を始めることもあります。自然な会話は動的であり、複数のトピックを扱うことがほとんどです。 この投稿では API を使用して、新しいインテントへの切り替えや以前のインテントへの復帰を含む会話のフローを管理する方法を見ていきます。次のスクリーンショットは、リアルなユーザーと人間のカスタマーサービスエージェントの会話の例を示しています。 上記の例の残高に関するユーザークエリ (「ちょっと待って。カードの残高合計はいくら?」) は、支払いという本題から逸脱しています。私たちはトピックを簡単に変更します。しかしボットは会話の脱線が発生したときにその会話状況を保存し、違う質問に答えてから、元のインテントに戻って、ユーザーに本題を思い出させる必要があります。 この例で言えば、ユーザーがカードで支払いをしたいことをボットは覚えておかなければなりません。支払いについてのデータを保存した後、コンテキストを切り替えて、同じカードの合計残高の情報を引き出しています。ユーザーに応答した後、支払いを続けます。この会話を 2 つの部分に分けるには、次のように行います。 図 2: 会話の脱線と再開 美味しそうな例を考えてみましょう。「フライドポテトも付いていますか?」と何回言ったかを考慮し、その後の会話を想像してみてください。 よく構成されたボットは、会話の脱線を検出できます。Lambda 関数を使用してサーバー側でインテントを切り替えたり、Amazon ElastiCache または Amazon DynamoDB で会話状態を維持したり、事前に入力されたスロットと新しいプロンプトで以前のインテントに戻ることができます。現在では、これらすべてを行うことが可能です。しかし実際のボットではコードを作成し管理する必要があります。これは天気をチェックするといったような簡単な作業ではありません。(ここで天気ボットを悪く言っているのではなく、正しい都市を見つけるだけなのに私の会話がそれて行ってしまうんです。) それで、何が言いたいの? 今日からは、新しいセッション状態 API を使用して、この種の脱線や他にもおもしろそうなリダイレクトに対処する Amazon Lex ボットを構築できます。この API を使用すると、クライアントアプリケーションから直接 Amazon Lex ボットとのセッションを管理し、会話フローをきめ細かく制御できます。 この投稿での会話の実装には、GetSession API 呼び出しを Amazon Lex に発行して、会話の前のインテント履歴を取得します。その後、PutSession オペレーションを使用して、正しいインテントを使用するようにダイアログマネージャーに指示し、次のダイアログアクションを設定します。これにより、ダイアログの状態、スロット値、属性を管理して、会話を前のステップに戻すことが可能となります。 前出の例では、ユーザーが合計残高についてクエリすると、クライアントは GetSession に続いて PutSession を呼び出し、支払いを続行することで、会話の脱線を処理しています。GetSession オペレーションからの応答には、ユーザーがやり取りした最後の 3 つのインテントの状態の概要が含まれます。これにはインテント MakePayment (accountType: credit, amount: $100)、および […]

企業がデジタル形式のデータを持つようになるとすぐに、データウェアハウスを構築し、顧客関係管理 (CRM) やエンタープライズリソースプランニング (ERP) システムなどの運用システムからデータを収集し、この情報を使用してビジネス上の意思決定をサポートできるようになりました。 ストレージコストの削減と、Amazon S3 などのサービスによって大量のデータ管理の複雑さを大幅に削減することが可能になり、企業は、ログ、画像、ビデオやスキャンされたドキュメントといった構造化されていない生データなど、より多くの情報を保持できるようになりました。 これは、すべてのデータを 1 つの集中リポジトリに任意の規模で保存するという、データレイクの考え方です。このアプローチの採用は、Netflix、Zillow、NASDAQ、Yelp、iRobot、FINRA、Lyft などのお客様に見られます。単純な集計から複雑な機械学習アルゴリズムまで、このより大きなデータセットで分析を実行することで、データのパターンをより適切に発見し、ビジネスをよりよく理解できます。 昨年の re:Invent で AWS Lake Formation のプレビューを紹介しました。これは、データの取り込み、クリーニング、カタログ化、変換、セキュリティ保護を容易にし、分析や機械学習で利用できるようにするサービスです。 今日、Lake Information が一般公開されたことをお伝えできることをうれしく思います。 Lake Formation には、データベースやログなどの複数のソースからデータレイクにデータを移動するジョブを設定するなど、データレイクを管理するための中央コンソールがあります。このように大量の多様なデータがあると、適切なアクセス許可を設定することも非常に重要になってきます。 Lake Formation で定義された詳細なデータアクセスポリシーの単一セットを使用して、Glue Data Catalog のメタデータおよび S3 に保存されたデータへのアクセスを保護できます。これらのポリシーを使用すると、テーブルおよびカラムナレベルのデータアクセスを定義できます。 Lake Formation で最も気に入っている点の 1 つは、すでに S3 にあるデータで動作するところです! Lake Formation に既存のデータを簡単に登録でき、データを S3 にロードする既存のプロセスを変更する必要はありません。データはアカウントに残っているため、完全に制御できます。 Glue ML Transforms を使用して、データを簡単に重複排除することもできます。重複排除は、必要なストレージの量を減らすために重要ですが、オーバーヘッドも同じデータを 2 回見るという混乱もないため、データの分析をより効率的に行うためにも重要です。重複レコードが一意のキーで識別できる場合、この問題はささいですが、「あいまい一致」を行う必要がある場合は非常にやっかいになります。 レコードの連結にも同様のアプローチを使用できます。たとえば、一意のキーを共有しない 2 つのデータベースの「ファジー結合」を行うなど、異なるテーブルで類似のアイテムを探している場合です。 このように、ゼロからデータレイクを実装する方がはるかに高速で、データレイクを管理する方がはるかに簡単で、これらのテクノロジーをより多くのお客様が利用できます。 データレイクの作成 Lake Formation […]

アップタイム要件が高いトランザクション性のアプリケーションをお持ちですか? これらの要件を満たすために、クラウドにリレーショナルデータベースが必要ですか? 新しく開始された Amazon Aurora Multi-Master は、ノードの障害に柔軟性のあるリレーショナルデータベースを必要とするアプリケーションのために設計され、読み取りと書き込みの両方に利用可能です。 Amazon Aurora は、ハイエンドな商用データベースの速さや可用性と、オープンソースデータベースのシンプルさと高い費用対効果とを組み合わせたリレーショナルデータベースエンジンです。MySQL 互換エディションの Aurora は、同じハードウェアで動作する標準 MySQL の最大 5 倍のスループットを実現します。これにより、既存の MySQL アプリケーションおよびツールを変更することなく実行できます。Amazon Aurora は 1 個のライターと最高 15 個の読み取りレプリカを 1 つ以上のアベイラビリティ―ゾーンとリージョンでサポートします。 Amazon Aurora Multi-Master は Aurora の MySQL 互換エディションに使用可能です。クラスターの各ノードはライターノードで、厳しいアップタイム要件をもつトランザクション性アプリケーションを実行するための追加パワーを与えます。 この記事では、MySQL 互換エディションのデータベース用の Aurora Multi-Master を最大限利用するために知っておくべきことを見直します。 アーキテクチャ Aurora Multi-Master は、データベースノードのクラスター全体で高可用性と ACID トランザクションを実現し、読み取り / 書き込み後の整合性を設定できるように設計されています。そのコアで、Aurora クラスターは計算 (データベース) ノードと共有ストレージボリュームのセットから構成されています。ストレージボリュームは、ユーザーデータの高可用性と耐久性のために、3 つのアベイラビリティーゾーンに配置された 6 つのストレージノードで構成されています。クラスターの各データノードは、ステートメントの読み取りと書き込みを実行できるライターノードです。 下図は […]

2012 年に、Windows PowerShell 用の AWS Tools for PowerShell モジュールの最初のバージョンを発表しました。これには、約 20 のサービスをサポートする約 550 のコマンドレットが含まれています。それ以来、AWS の成長により、モジュールは 160 以上のサービスにまたがるほぼ 6,000 のコマンドレットに拡張され、さらにクロスプラットフォームで実行できる PowerShell 6 以上のユーザー向けの追加 (ただし同一) モジュールが加わりました。 これらすべてのコマンドレットを単一のモジュール (Windows では PowerShell v2 から v5.1 までの AWSPowerShell、Windows、macOS、Linux では PowerShell v6 以上の AWSPowerShell.NetCore) に入れることには欠点があります。まず、モジュールのインポート時間が大幅に増加します。私の第 8 世代 Core i7 ラップトップでは、いずれかのモジュールをインポートする時間が 25 秒を超えています。次に、チームがモジュールマニフェスト内のすべてのコマンドレットのリストに関する問題を発見したため、CmdletsToExport マニフェストプロパティに「*」を指定する必要があります。これにより、モジュールが明示的にインポートされるまでPowerShell はモジュール内のコマンドレットを決定できなくなり、コマンドレット名のタブ完了に影響します。 私のシェルプロファイルでは、Set-AWSCredential および Set-DefaultAWSRegion コマンドレットを使用して、シェルの初期スコープを設定しています。したがって、最初にモジュールを明示的にインポートしてから、シェルが使用可能になるまで待つ必要があります。この遅い読み込み時間は明らかに容認できません。特に、起動時間を速くしたいときに、PowerShell で AWS Lambda 関数を作成する場合はなおさらです。 リファクタリングされた […]