Amazon Web Services ブログ

Amazon Simple Storage Service (Amazon S3) では、クロスリージョンレプリケーション (CRR) を使用して、異なる AWS リージョン内のバケット間でオブジェクトを自動的かつ非同期にコピーできます。CRR はバケットレベルの設定であり、データのコピーを異なるリージョンに保存することで、コンプライアンス要件を満たし、レイテンシーを最小限に抑えるのに役立ちます。CRR は、プレフィックスとタグによって制御されるソースバケット内のすべてのオブジェクト、またはオプションでサブセットを複製します。 CRR を有効にする前に存在していたオブジェクト (既存のオブジェクト) は複製されません。同様に、レプリケーションに使用される IAM ロールまたはバケットポリシー (バケットが異なる AWS アカウントにある場合) のいずれかで権限が設定されていないと、オブジェクトの複製に失敗することがあります (失敗したオブジェクト)。 お客様との作業では、前述の理由で多数のオブジェクトが複製されないという状況を経験しました。この記事では、既存のオブジェクトと失敗したオブジェクトに対してクロスリージョンレプリケーションをトリガーする方法を説明します。 方法論 高いレベルで、既存のオブジェクトと失敗したオブジェクトに対してコピーインプレース操作を実行する戦略です。この操作では、Amazon S3 API を使用して、タグ、アクセスコントロールリスト (ACL)、メタデータ、および暗号化キーを保持しながら、オブジェクトを自分自身の上にコピーします。操作は、オブジェクトの Replication_Status フラグもリセットします。これにより、クロスリージョンレプリケーションがトリガーされ、次にオブジェクトが宛先バケットにコピーされます。 これを達成するために、以下を使用します。 その場でコピーするオブジェクトを識別する Amazon S3 インベントリ。これらのオブジェクトはレプリケーションステータスがないか、または FAILED ステータスを持っています。 S3 インベントリファイルをテーブルとして公開するための Amazon Athena と AWS Glue。 AWS Glue テーブルをクエリしてインプレースコピー操作を実行する Apache Spark ジョブを実行するための Amazon EMR。 […]

お客様がストリーミングデータを使用している様子を見て、いつも驚いてしまいます。たとえば、ビジネスと専門分野で世界で最も信頼されるニュース会社の 1 つである Thomson Reuter は、分析データを取り込み、分析し、可視化して、製品チームが継続的にユーザーエクスペリエンスを向上させるのを支援しています。Hay Day、Clash of Clans、Boom Beach などのゲームを提供するソーシャルゲームの会社である Supercell は、1 日あたり 450 億のイベントを処理するリアルタイムのゲーム内データ配信を行っています。 re:Invent 2013 で当社は Amazon Kinesis をローンチして以来、顧客が AWS 上でストリーミングデータを操作する方法を継続的に拡大してきました。いくつかの利用可能なツールには、次のものがあります。 Kinesis Data Streams。固有のアプリケーションでデータストリームを取り込み、保存し、処理します。 Kinesis Data Firehose。, データを変換し、 Amazon S3、Amazon Elasticsearch Service、および Amazon Redshift などの保存先に収集します。 Kinesis Data Analytics。SQL または Java (Apache Flink アプリケーション経由) を使用して継続的にデータを分析します。たとえば、異常を検出したり、時系列集約のために使用するためなどです。 Kinesis Video Streams。メディアストリームの処理を簡素化します。 re:Invent 2018 では、私達はオープンプレビューで Amazon Managed […]

昨年11月にAWS IoT Things Graph を発表 し、IoTアプリケーションを視覚的に構築できるようにするツールとして説明しました。本日、このサービスが利用できるようになりました。 ここでご覧いただけるように、ビジネスロジックをデバイスとサービスから構成されるフローで表すことができます。各ウェブサービスとそれぞれのタイプのデバイス (センサー、カメラ、ディスプレイなど) は、モデル として Things Graph に表されます。このモデルは、特定のブランドやデバイスのモデルに固有の実装の詳細を隠し、ハードウェアとともに進化するフローを構築することを可能にします。各モデルにはアクション (入力)、イベント (出力)、および 状態 (属性) のセットがあります。Things Graph には、事前定義されたモデルのセットが含まれ、固有のものを定義することもできます。また、フローの一部として マッピング を使用して、1 つのデバイスからの出力を他のデバイスが期待する形式に変換することができます。フローを構築した後で、ローカルでの実行のために、AWS IoT Greengrass対応デバイスにデプロイできます。フローがデプロイされると、ローカルで接続されたデバイスとウェブサービスの間のインターラクションを調整できます。 AWS IoT Things Graph の使用 AWS IoT Things Graph Consoleの概要を見ていくことにしましょう。 最初の手順では、フローで使用するデバイスとウェブサービスを表すモデルがあることを確認します。コンソールナビゲーションの [Models] をクリックして、開始します。 コンソールはモデルを作成するために従わなければならない 3 つの手順を概説し、また、既存のモデルもリストします。 上記にリストされた各デバイスの URN にaws/examples があることは、それらが事前定義され、パブリック AWS IoT Things Graph 名前空間の一部であることを示します。[Camera] をクリックして、このモデルの詳細を確認します。 [Properties]、[Actions]、および [Events]を確認できます。 モデルは GraphQL […]

リレーショナルデータベースにアクセスするコードをこれまでに書いたことがあれば、そのドリルを知っているでしょう。接続を開き、そのコードを使用して 1 つ以上の SQL クエリや他のステートメントを処理してから、接続を閉じます。おそらくご自身のオペレーティングシステム、プログラミング言語、データベースに特有のクライアントライブラリを使用したのでしょう。ある時点で、接続の作成には多くの時間がかかり、データベースエンジンのメモリを消費していることに気付き、その直後に接続プールやその他のトリックに対処できる (または対処しなければならなかった) ことがわかった、という話は聞き覚えがありませんか? 上で説明した接続志向モデルは、セットアップ時間を数時間または数日にわたって使える従来の長期実行プログラムに適しています。ただし、頻繁に呼び出され、ミリ秒から数分の時間間隔で実行されるサーバーレス機能には、あまり適していません。長時間稼働しているサーバーがないため、再利用のために接続識別子を格納する場所がありません。 Aurora Serverless Data API サーバーレスアプリケーションとリレーショナルデータベース間のこの不一致を解決するために、Amazon Aurora Serverless のMySQL 互換バージョン用の Data API をローンチします。この API により、従来の接続管理に伴う複雑さとオーバーヘッドから解放され、Amazon Aurora Serverless Database インスタンスにアクセスして変更する SQL ステートメントを迅速かつ簡単に実行することができます。 Data API は、従来のアプリケーションとサーバーレスアプリケーションの両方のニーズを満たすように設計されています。データベースへの長期的な接続の管理とスケーリングを行い、データを JSON 形式で返して簡単に解析できるようにします。すべてのトラフィックは安全な HTTPS 接続を介して流れます。含まれる機能は以下のとおりです。 ExecuteStatement – オプションのトランザクション内で単一の SQL ステートメントを実行します。 BatchExecuteStatement – オプションのトランザクション内で、データの配列全体にわたって単一の SQL ステートメントを実行します。 BeginTransaction – トランザクションを開始し、トランザクション識別子を返します。トランザクションは短くなることが予想されます (通常 2〜5 分)。 CommitTransaction – トランザクションを終了し、その中で行われた操作をコミットします。 RollbackTransaction […]

過去 4、5 年間にわたる多くの発表からご存知かもしれませんが、私たちは幅広い一連のモノのインターネット (IoT) サービスと機能の構築に取り組んでいます。以下に要約します。 2015 年 10 月 – AWS IoT Core – コネクテッドデバイス向けのクラウドサービスの基本的なセット。 2017 年 6 月 – AWS Greengrass – コネクテッドデバイス上で AWS Lambda 関数を実行する機能。 2017 年 11 月 – AWS IoT Device Management – コネクテッドデバイスのオンボーディング、編成、モニタリングおよびリモート管理。 2017 年 11 月 – AWS IoT Analytics – IoT デバイス向けの高度なデータ分析。 2017 年 11 月 – Amazon […]

ドキュメントは、金融、医療、法律、および不動産などの数多くの業界全体における記録管理、コミュニケーション、コラボレーション、そして取引のための主な手段です。毎年処理される何百万もの住宅ローン申請、そして何億もの W2 納税申告書は、そのようなドキュメントの数例にすぎません。多くの情報は、非構造化ドキュメントに閉じ込められています。これらのドキュメントの検索と検出、ビジネスプロセスの自動化、およびコンプライアンス管理を可能にするには、時間がかかる複雑なプロセスが必要になるのが通常です。 この記事では、Amazon Textract を利用して、機械学習 (ML) の経験がなくてもスキャンされたドキュメントからテキストとデータを自動的に抽出することができる方法を説明します。AWS が可用性に優れたスケーラブルな環境での高度な ML モデルの構築、トレーニング、およびデプロイメントを処理するので、皆さんには簡単に使用できる API アクションでこれらのモデルを活用していただきます。この記事で取り上げるユースケースは以下のとおりです。 ドキュメントからのテキスト検出 複数の列の検出と読み順 自然言語処理とドキュメント分類 医療ドキュメントのための自然言語処理 ドキュメント翻訳 検索と検出 フォームの抽出と処理 ドキュメント編集によるコンプライアンス管理 表の抽出と処理 PDF ドキュメントの処理 Amazon Textract ユースケースについての説明を始める前に、コア機能をいくつか見直して、ご紹介したいと思います。Amazon Textract は、シンプルな光学文字認識 (OCR) という枠を超えて、フォーム内のフィールドのコンテンツや、表に格納された情報も識別します。これにより、Amazon Textract を使用して、手動での工数やカスタムコードを必要とすることなく、実質上どのようなタイプのドキュメントでも瞬時に「読み取り」、テキストとデータを正確に抽出することが可能になります。 以下の画像は、サンプルドキュメントと、AWS マネージメントコンソールにある Amazon Textract を使用して抽出したドキュメントのテキスト、フォーム、および表のデータです。 以下の画像は、ドキュメントから未処理のテキストとして抽出された行です。 以下の画像は、抽出されたフォームフィールドとそれらに対応する値です。 以下の画像は、抽出された表、セル、およびこれらのセル内のテキストです。 出力を含む zip ファイルをすばやくダウンロードするには、[結果をダウンロードする] をクリックします。フォームと表については、未処理の JSON、テキスト、および CSV ファイルなどのさまざまな形式を選択できます。 検出された内容の他にも、Amazon Textract は検出された要素の信頼度スコアとバウンドボックスといった追加情報も提供し、抽出されたコンテンツをどのように利用して、さまざまなビジネスアプリケーションに統合させるかをコントロールできるようにしてくれます。 Amazon Textract は、ドキュメントテキストを抽出し、ドキュメントテキストのデータを分析するために、同期および非同期両方の API […]

皆さん、こんにちは。アマゾン ウェブ サービス ジャパン株式会社 (AWS) アソシエイトソリューションアーキテクトの小田桐昂史です。暑い日が続いておりますが、いかがお過ごしでしょうか。 5/30 (木) AWS Loft Tokyo において、AWS DeepRacer リーグ テクニカル・ワークショップが開催され、満席となる非常に多くの方にご参加いただきました。今回は、AWS DeepRacer カー実機の登場によって、毎日の暑さにも負けないほどに盛り上がったこのイベントの様子についてお伝えしたいと思います。次回 6/6 (木) のお申し込みも受け付けております(内容は今回とほぼ同様となります)。 まずはじめに、AWS DeepRacer リーグの開催概要について説明いたしました。AWS DeepRacer リーグは、実際のサーキットで行う「Summit サーキット」と「バーチャル サーキット」の2つのタイプがあります。Summit サーキットは、世界各地で行われるAWS Summitの会場に設置され、日本では、6/12 (水) 〜 14 (金) 幕張メッセで行われるAWS Summit Tokyo 2019にて3日間、開催されます。 Summit サーキットでは、学習したモデルをお持ちいただき、AWS DeepRacer カーにインストールし、レースを行なってもらいます。1人あたり4分の持ち時間が与えられ、周回したうちベストラップを記録とします。各AWS Summitでの優勝者には、re:Invent 2019にご招待します。また、1位から10位の入賞者にはAWS DeepRacer カーを贈呈いたします。 バーチャル サーキットは、AWS DeepRacer コンソールを使い世界中のどこからでも参加できるレースで、毎月新しいコースが公開され、月ごとの優勝者にはSummit サーキット同様にre:Invent 2019へ招待される権利が贈呈されます。 続いて、AWS 機械学習ソリューションアーキテクトの宇都宮よりAWS DeepRacerについて、その概要から構成要素、リーグのためのモデルを学習する方法，シミュレーション環境やコンソールの利用方法について説明いたしました。AWS DeepRacerの学習には、強化学習が利用されています。車の動きや環境を記述する、シミュレータとの相互作用を通して、最適な方策を学習していきます．報酬関数が重要な役割をもっており、学習に利用できる車からの情報(位置情報や速度等)と、観測結果であるカメラ画像を元にした方策を効果的に学習することで、モデルはセンターラインに沿って走ったり、コーナーを曲がったりすることができるようになります。AWS […]

多くの組織では、AWS のサービスログを含むさまざまなログの保存先として Amazon Simple Storage Service (Amazon S3) を主に使用しています。ログデータを Amazon S3 に保存する利点の 1 つは、さまざまな方法でアクセスできることです。一般的な方法の 1 つは、S3 上のデータに対するサーバーレスのクエリエンジンである Amazon Athena を使用してクエリを実行することです。ログのクエリの一般的なユースケースは、サービスとアプリケーションのトラブルシューティング、パフォーマンス分析、およびセキュリティ監査です。Athena で最高のパフォーマンスを得てクエリコストを削減するには、AWS ビッグデータブログの「Top 10 Performance Tuning Tips for Amazon Athena」で概説されているように、一般的なベストプラクティスに従うことをお勧めします。これらのベストプラクティスには、Apache Parquet のようなデータを円柱形式に変換し、結果として得られたデータを S3 で分割することが含まれます。 この記事では、Athena Glue Service Logs (AGSlogger) として知られる Python ライブラリをオープンソース化しています。このライブラリには、最も一般的なログ形式を解析および最適化するための定義済みテンプレートがあります。このライブラリは、AWS Glue のスキーマの定義、パーティションの管理、および抽出、変換、ロード (ETL) ジョブ内でのデータ変換のためのメカニズムを提供します。AWS Glue は、サーバーレスのデータ変換およびカタログ作成サービスです。このライブラリを AWS Glue ETL ジョブと組み合わせて使用すると、ログデータを処理するための共通のフレームワークを有効にできます。 AWS Glue ETLで Python […]

この記事は、Ibotta 社の機械学習マネージャー、Evan Harris 氏によるゲスト投稿です。Ibotta 社によると、「Ibotta は、単一のスマートフォンアプリを通じて消費者が簡単に普段の買い物に対するキャッシュバックを獲得できるようにすることでショッピング体験を変革しており、食料品、電子機器、衣料、ギフト、家庭および事務用品、レストランでの食事などに対する特典を提供するために、一流のブランドおよび小売業者と提携してる」とのことです。 急成長するミドルステージの企業間における技術面での隔たりは、ユニークな課題を生みがちです。  このような企業の多くで重要視されるのは、高品質アプリケーションを迅速かつ効率的に構築することです。 普段の買い物に対するキャッシュバックを何百万ものユーザーに提供するモバイルアプリ、Ibotta の機械学習 (ML) チームは、このトピックについてかなりの考察と実験を行ってきました。  今日は、Amazon SageMaker を使った検索など、コア機能を実現するために当社が AWS を活用する方法についてお話したいと思います。 この記事では、Ibotta の検索エンジンのアーキテクチャ、そしてリアルタイムの ML を当社のモバイルアプリケーションの検索経験に統合するために Amazon SageMaker とその他の AWS サービスを使用する方法について説明します。この記事が、皆さんの組織の規模に関わらず、組織内における同じような課題に対する実行可能なソリューションを探す期間を短縮するために役立てば幸いです。 包括的で使いやすい検索フローを備える能率化されたモバイルアプリ経験を生み出すことは、私たちのビジネスにとって必要不可欠です。買い物前にお買い得情報を探すお客様は、価値ある情報をすばやく見つける必要があり、そうでなければあきらめてしまう傾向があります。 検索関連性エンジニア、ML エンジニア、設計者、およびモバイル開発者の専属チームを持つ当社では、検索関連性に対する新しくクリエイティブな改善を迅速に開発し、テストするために出来る限り多くの最新テクノロジーを使用しています。Ibotta はデータ主導のインテリジェンスを検索エンジンに投入するための ML の使用を優先しており、これは私たちを従来の情報取得手法を超えたレベルに押し進めます。 基礎を成す検索インフラストラクチャ Ibotta での検索のコアインフラストラクチャは、アプリの幅広いマイクロサービスを土台としています。インデックス化されたドキュメントは Amazon Elasticsearch Service に保存され、これにはモバイルクライアントが任意の時点で利用できるコンテンツのすべてが収められています。リクエストに応じて社内のコンテンツサービスがこのドキュメントストアと通信し、リクエストを行っているユーザーが利用できるコンテンツのみが返されることを確実にするための、追加のルールベースのフィルタリング機能を提供します。 このコンテンツサービスは入力検索クエリを受け取り、他の文脈上の考慮事項を計算に入れながら、関連するコンテンツで応答することができます。コンテンツサービスは典型的な lucene スタイルの検索関連性手法を使用して Elasticsearch ドキュメントストア内の適切なコンテンツを取得します。 ML で強化された検索インフラストラクチャ 基礎となる検索インフラストラクチャには、大きな改善の余地があります。Ibotta の検索問題領域には、特にコンテンツに関してユニークな課題があり、ある週に特定ブランドのための特典がアプリ内にあっても、別の週にはその特典がなくなっているという場合があります。これは、私たちが提携する小売業者によるものです。小売業者は、限定された期間だけアイテムを宣伝したいということが多々あるからです。 これに加えて、当社のアプリでは全く利用できないブランドと製品のカテゴリもあります。これは、当社がまだこれらの小売業者と連携していないからですが、私たちは、ユーザーの検索クエリがアプリ内のコンテンツに完全に一致しない場合でも、それらのユーザーに関連するコンテンツを表示したいと考えています。例えば、取り扱っていないブランドのコーヒーに対する検索は、重要な属性 (フレーバー、サイズ、価格など) 全体に一致する他のコーヒーブランドを返すべきです。 これに対するソリューションがクエリ拡大です。これは、データストアをクエリする前に、ユーザーの検索クエリにコンテンツを追加する一般的な検索手法です。ある状況では、リアルタイムで検索クエリをカテゴリ別に分類することによって価値を付加し、コンテンツ取得とソートアルゴリズムを強化します。別の状況では、カテゴリに分類した後、予測されたカテゴリを専門とするオンライン小売業者を検索してソートし、それらを提案としてユーザーに返します。 Ibotta では、これらのオンデマンドのカテゴリ推論をリアルタイムで行うために Amazon […]

AWS を利用する際に最も重要なこととして、AWS リソースのセキュリティの確保があります。誰にリソースにアクセスさせるのか、注意深くコントロールする必要があります。これは、AWS ユーザーがプログラムを使ったアクセスをしている場合にも同様です。プログラムからのアクセスは、自社で作成したアプリケーションもしくはサードパーティーのツールから AWS リソースにアクションすることを実現します。AWS サービス側でアクセスリクエストを認可させるためにアクセスキー ID とシークレットアクセスキーを使ってリクエストに署名することが可能です。このようにプログラムによるアクセスは非常にパワフルなため、アクセスキー ID とシークレットアクセスキーを保護するためにベスト・プラクティスを活用することが重要です。これは不意のアクセスあるいは悪意のあるアクテビティビティからアカウントを保護するために重要です。この投稿では、いくつかの基本的なガイドラインを提示し、アカウントを保護する方法を示します。また、プログラムからの AWS リソースへのアクセスを行う際に利用出来るいくつかの方法を提示します。 ルートアカウントを保護する AWS のルートアカウント –  AWS にサインナップするときに最初に作られるアカウント – は全ての AWS のリソースに無制限でアクセス出来ます。ルートアカウントには権限による制御が効きません。したがって、AWS はルートアカウントに対してアクセスキーを作成しないように常におすすめしています。アクセスキーを与えると利用者がアカウント全体を廃止するような強力な権限を得てしまいます。ルートアカウントにアクセスキーを作成するかわりに、利用者は個別の AWS Identity and Access Management（IAM）ユーザーを作成して利用することができます。さらに、最小権限の考え方に従い、それぞれの IAM ユーザーに対してタスクを実行するのに必要な権限のみを許可します。複数の IAM ユーザーの権限を簡単に管理するために、同じ権限を持つユーザーを IAM グループにまとめる方法も使えます。 ルートアカウントは常に多要素認証（MFA）で保護するべきです。このセキュリティに関する追加の保護は許可されていないログインからアカウントを保護することに役立ちます。多要素認証とは、認証に複数の要素を使うことで、パスワードのような知識認証要素と、MFA デバイスのような所有物認証要素を同時に使うことです。 AWS はバーチャルとハードウェアの 両方のMFA 用のデバイス、さらに U2F セキュリティキーを多要素認証用としてサポートしています。 AWS アカウントに対するアクセスを許可するときの考え方 ユーザーに AWS マネジメントコンソールやコマンドラインインターフェース（CLI）にアクセスを許可するには２つの選択肢があります。１つ目は、IAM サービスによって管理されるユーザー名とパスワードでログインする ID を作ることです。もう１つは、IDフェデレーションを利用して、既に企業の中に存在する認証情報を使って AWS コンソールや CLI にログインさせることです。それぞれのアプローチには異なるユースケースがあります。フェデレーションは、既に集中管理されたディレクトリがあるか、現在の制約である5000人以上の IAM […]