Amazon Web Services ブログ

Category: Compute

AWS Lambda がサポートするイベントソースに Amazon Simple Queue Service を追加

Amazon Simple Queue Service (SQS) を使って AWS Lambda 関数をトリガーできるようになりました。これは私が個人的に 4 年以上前から楽しみにしてきた、重要な機能を提供する特別なアップデートです。皆さん、試用を待ち望んでいることでしょうから、昔話に興味のない方は下記を飛ばしてもらって結構です。 SQS は当社が立ち上げた初めてのサービスで、14 年前の 2004 年、AWS より公開されました。ご参考に、2004 年当時と言えば、商用ハードドライブは最大でも約 60 GB、PHP 5 が現れ、Facebook がちょうど開始したところ、テレビ番組のフレンズはシリーズが終了、Gmail はまだ珍しく、そして私はまだ高校生でした。振り返ってみると、今日の AWS を生み出した理念、つまり完全な管理体制、ネットワークにアクセス可能で、プリペイドで契約維持料なしといった方針は、SQS 開発の初期段階であった当時にも少し垣間見ることができます。現在、SQS は数多くの顧客が非常に大規模に使用しているサービスの中でも最も人気が高く、多くのアプリケーションの基本構成部分の 1 つとなっています。 これに対して、AWS Lambda は 2014 年に開催された AWS re:Invent (私はその日の参加者でした) にてリリースした比較的新しいサービスです。Lambda は、サーバーのプロビジョニングや管理を行わずにコードを実行できるコンピューティングサービスであり、2014 年にサーバーレスの革命を起こしたのです。Web およびモバイルバックエンドから IT ポリシーエンジン、データ処理パイプラインまで、幅広いユースケースに即座に採用されました。現在、Lambda は Node.js、Java、Go、C#、Python のランタイムをサポートしているので、既存のコードベースの変更を最小限に抑え、新しいコードベースを柔軟に構築できます。さらにこの過去 4 年間で、Lambda の機能やイベントソースを多数追加したため、さらに迅速な仕事ができるようになりました。Lambda に SQS のサポートを追加することで、ポーリングサービスの実行や、SQS から SNS […]

Read More

Amazon QuickSightのプライベートVPC内のデータアクセスの設定方法について

はじめに 今回の記事では、先日一般公開された「Amazon QuickSightのプライベートVPC内のデータアクセス」の設定方法をご紹介します。この設定を行うことによって、Amazon QuckSight(以下、QuickSight)からプライベートサブネット内のAmazon RDS(以下、RDS)のデータベース、Amazon EC2内のデータベースへのアクセス、また AWS Direct Connect(以下、Direct Connect)を経由したオンプレミスのデータベースにアクセスして分析ダッシュボード、レポートを作成することが可能です。 なお本稿の情報は、2018年6月22日時点の以下のAWS公式ドキュメントをベースにしておりますが、最新の情報は設定前にご確認ください。 Amazon QuickSight: Amazon VPCを操作する 接続構成イメージ 以下で説明する手順を実行すると以下のようなイメージで構成されます。VPC内にあるプライベートサブネットの中にQuickSightアクセス用のセキュリティグループを定義することで、アタッチされるENI(Elastic Network Interface)経由でQuickSightが同一VPC内のデータベース(本例ではRDS)のあるプライベートサブネットに接続することが可能です。 図1. 構成イメージ(プライベートVPC内接続) また上記のように、QuickSightアクセス用のセキュリティグループを構成することで、オンプレミス環境にあるデータベースに対しても、Direct Connect経由でアクセス可能(オンプレミスデータベースへのルーティングが可能である前提)になります。 図2. 構成メージ(オンプレミスへの接続)   設定手順概要 1.QuickSight用のセキュリティグループ作成 AWSのマネージメントコンソールから「VPC → セキュリティグループ」を選択し、「セキュリティグループの作成」ボタンを押し、QuickSight用ENIのセキュリティグループを作成します。 図3. QuickSightアクセス用のセキュリティグループ作成   2.作成したQuickSightアクセス用のセキュリティグループのインバウンドルール設定 ここで前の手順で作成したQuickSightアクセス用のセキュリティグループの「インバウンドルール」を設定します。何故、インバウンドルールを設定するかというと以下のドキュメントの引用のように、QuickSight用のENI(ネットワークインターフェイス)にアタッチされているセキュリティグループの通信はステートフルではないため、本例のRDSからの戻りの通信に対する受信ルールを追加する必要があるのです。 引用:Amazon QuickSight: Amazon VPCを操作する 「ただし、Amazon QuickSight ネットワークインターフェイスにアタッチされているセキュリティグループはステートフルではありません。つまり、送信先ホストからの戻りトラフィックは自動的に許可されません。この場合、ネットワークインターフェイスセキュリティグループに Egress ルールを追加しても機能しません。したがって、明示的に承認するために、受信ルールをセキュリティグループに追加する必要があります。」 図4. QuickSightアクセス用のセキュリティグループ設定上のポイント よって、以下の様にQuickSight用のセキュリティグループのインバウンドルールを以下の様に設定します。 図5. QuickSightアクセス用のセキュリティグループのインバウンドルールの設定例   3.RDSのセキュリティグループの設定 次にRDSのセキュリティグループにQuickSightのセキュリティグループ経由のアクセスを許可する設定を行います。 AWSのマネージメントコンソールから「RDS → インスタンス」を選択し、該当のインスタンス名のリンクをクリックして、インスタンス詳細画面を表示します。 […]

Read More

トヨタ・リサーチ・インスティテュート、AWS の深層学習により安全性が高い自動運転車を世界規模で急速展開

社会は自動運転技術を搭載した車両から数多くの恩恵を受けます。トヨタ・リサーチ・インスティテュート (TRI) が最優先事項の一つに掲げているのが、進化した最新の人工知能 (AI) を活用してより安全で、利用しやすく、環境にも優しい車両を生産することです。TRI はその目標達成に役立てるためアマゾン ウェブ サービス (AWS) の深層学習に着目しました。 TRI は、Amazon EC2 P3 インスタンスを利用することで、以前使用していた P2 インスタンスと比較して訓練時間が 4 倍も速くなり、訓練時間が数日から数時間に短縮されました。これにより、モデル車を素早く最適化した上で短期間でトレーニングを再度行い、テストカーやシミュレーション環境に展開してさらにテストすることができます。また、AWS の「pay-as-you-go」モデルと組み合わせて、P2 インスタンスに対して P3 インスタンスのパフォーマンスを大幅に向上させたことで、TRI の運用コストを削減しました。 自動運転のための深層学習モデルの作成 TRI は、その自動運転技術のため単一技術のスタックを開発し、2 つのモードを用意しました。保護者 (Guardian) モードと運転手 (Chauffeur) モードです。保護者モードでは、ドライバーは常に車輪と路面状態に気を配る必要がありますが、運転中の社内外の環境を絶えず監視することで衝突危機を認識した時に必要なタイミングで介入を行います。運転手モードも同じ技術を使用しますが、車両は常に制御されており、厳密に乗客を乗せられる乗用車です。 自律型車両を開発および展開するには、膨大な量のデータ、高性能コンピューティング能力、高度な深層学習技術を結集、格納、管理する能力と、車両内でリアルタイムに処理する能力が求められます。 TRI は PyTorch の深層学習フレームワークを利用することで深層学習コンピュータビジョンモデルを作成し、両運転モードで自動的に監視および制御を行えるようにしました。TRI には、深層学習モデルで使用するデータを収集するため、カメラ、レーダー、LIDAR (3D 空間でオブジェクト表現を生成するための制御およびナビゲーションに使用される技術) などのさまざまなタイプのデータ収集センサーが装備されたテストカーを数多く保有しています。テストカーは、様々な運航設計領域 (Operational Design Domains、ODD) を駆け抜け、車両 1 台につき 1 日合計テラバイト単位のデータを収集して記録します。このデータは、分析、機械学習の再学習モデルやシミュレーションのため、素早く検索、準備および利用可能な状態にする必要があります。 TRI は、正確なトレーニングモデルには、数兆マイルの試験走行が必要だと考えています。1 億台以上のトヨタ車が路上を走行している今日、ドライバーは様々な運転状況を経験します。車両のテストを補完するため、TRI はシミュレーションを用いてさまざまな希少条件やシナリオをモデル化します。シミュレーションでは、暴風雨、吹雪、日中・夜間の異なる時間帯のギラツキや、さまざまな路面状態や周囲の状況といった厳しい状況で、機会学習モデルがどのように反応するかをテストするフォトリアルデータストリームを生成します。 TRI は、新しいテストデータが利用できるようになると、研究アイデアを間髪入れずに模索し、モデルを素早くトレーニングして、更新版をテストカーに搭載し、テストを再実行できるようにします。 […]

Read More

AWS Systems Manager Parameter Store を使用して最新の Amazon Linux AMI IDを取得する

最新の Amazon Linux AMI を取得するシンプルな方法が必要ですか? AWS Systems Manager Parameter Store はすでに最新の Windows AMI を取得できます。今回、最新の Linux AMI も取得できるよう機能が拡張されました。各 Amazon Linux AMI は、固有の 公開パラメータストア名前空間 を持ちます。AMIの名前空間をクエリすることで、指定したリージョンのイメージIDを得ることができます。

Read More

AWS Step FunctionsとAWS Lambdaを使って複数のETLジョブの統合を行う

抽出、変換、ロード(Extract, Transform, Load, ETL)操作は、現在のエンタープライズデータレイクのバックボーンにひとまとまりとして形成されています。rawデータを役に立つデータセットへ変換し、最終的には、洞察可能な状態に変換します。ETLジョブは通常1つまたは1つ以上のデータソースからデートを読み、様々な種類の変換を適用し、結果を利用準備できているターゲットに書き込みます。ETLジョブのソースとターゲットはリレーショナルデータベースであるAmazon RDS(Amazon Relational Database) もしくはオンプレミス、データウェアハウスとしてAmazon Redshift 、オブジェクトストレージとしてAmazon Simple Storage Service(Amazon S3) のバケットなどがあります。Amazon S3は、AWSでデータレイクを構築するという状況において特に一般的です。 AWSは、ETLジョブの作成とデプロイを支援するAWS Glueを提供しています。AWS Glueは抽出・変換・ロードを行うフルマネージドなサービスであり、お客様が簡単に自分のデータとして準備、ロードできるものとなります。他のAWSサービスでもETLジョブを実装、デプロイすることも可能です。 AWS Database Migration Service(AWS DMS)、Amazon EMR(ステップAPIの利用)、さらにAmazon Athenaも含まれます。   ETLジョブワークフロー統合へのチャレンジ 多様なETLテクノロジーを含むETLワークフローをどのように統合できるでしょうか? AWS Glue、AWS DMS、Amazon EMRなどのサービスは、Amazon CloudWatch Eventsをサポートしており、ETLジョブを連動させることができます。 Amazon S3は、中心に置かれたデータレークストアでもあり、CloudWatch Eventsをサポートしています。しかし、CloudWatchイベントのみに依存するということは、ETLワークフローの視覚的表現が1つもないことを意味します。また、全体的なETLワークフローの実行ステータスを追跡し、エラー・シナリオを処理することは困難になります。 本ブログでは、AWS Step FunctionsとAWS Lambdaを使用して、任意の複雑なETLワークフローでさまざまなテクノロジを含む複数のETLジョブを編成する方法を説明します。

Read More

AWS Lambda、Amazon Kinesis、Amazon Athena を使用したブロックチェーン分析ソリューションの構築

ブロックチェーンの利用には、数多くの潜在的な利点があります。ブロックチェーンとは、検証可能かつ変更不能な方法でトランザクションを記録できる分散型データ構造です。ユースケースに応じ、コスト削減、速度や効率性の改善、企業コンプライアンスの強化、回復力やスケーラビリティの向上を実現できる可能性があります。 ブロックチェーンを早期に取り入れた人々は、金融、ヘルスケア、電子政府、非営利組織などの分野で、その革新的な使い道を発見しているところです。ブロックチェーンは、当初は仮想通貨 Bitcoin を支える主要テクノロジーとして開発されたものでした。 ブロックチェーンの使い道については、その設計から実に多くの機会が生じています。基本的には、幾千ものノードで構成されることが多い、大規模な分散型システムです。ブロックチェーンにおいては、ユーザーのアクティビティ、イベント、例外、その他の状態変化を見抜くことが困難な場合があります。しかし、AWS 分析サービスでは、ブロックチェーンアプリケーションを分析できるようにするとともに、その分野に関する重要な情報を提供します。 ウォークスルー この記事では、以下を実現する方法について説明します。 AWS Blockchain Templates を利用した Ethereum ブロックチェーンのデプロイ スマートコントラクトのデプロイ AWS Lambda、Amazon Kinesis、Amazon Athena に基づいたコントラクトの、サーバーレス分析パイプラインの構築 この Ethereum のデプロイやブロックチェーン分析は、幅広いブロックチェーンシナリオでの用途に、容易に適合させることができます。 前提条件 この記事は前提として、AWS と Ethereum に精通しているユーザーを対象としています。次のドキュメントでは、この記事で説明する手順を実行する際に役立つ背景知識を提供しています。 An introduction to Ethereum Deploying a smart contract to Ethereum An Introduction to Solidity Smart Contracts 加えて、このブログ記事からさらに多くを学ぶには、Amazon Kinesis、AWS Lambda、Amazon QuickSight、Amazon Athena にも精通していると便利です。詳細は、下記を参照してください。 Writing SQL on Streaming Data […]

Read More

Amazon ECSとKubernetesの統合サービスディスカバリー

本日(訳注:2018年5月31日)から、Amazon Elastic Container Service(Amazon ECS)およびKubernetesによって管理されるサービスの統合サービスディスカバリーを活用することができます。私たちは最近、Amazon Route 53 Auto Naming(オートネーミング)APIを使用してサービス名のレジストリを作成および管理することにより、コンテナ化されたサービスの発見と相互接続を容易にするECSサービスディスカバリーを導入しました。サービス名は、一連のDNSレコードセットに自動的にマップされます。これにより、コード内でサービスを名前(backend.example.comなど)で参照可能となり、実行時にサービスのエンドポイントを名前で解決するためのDNSクエリを記述することができます。 私たちは、Kubernetesユーザーにもオートネーミング APIが活用できるようにするため、オートネーミング APIをKubernetesもサポートするように拡張しました。この統合によって、オートネーミング APIによって管理されるサービスレジストリにKubernetesのサービスとイングレスを自動的に複製できるようになりました。 Kubernetesクラスタの外部にあるクライアントから、フレンドリーなサービス名を使用してこれらのサービスエンドポイントを簡単に解決できます。この統合を可能にするために、私たちはKubernetesインキュベータープロジェクトであるExternal DNSにコントリビュートしました。 これにより、Amazon ECSで実行されるサービスから、Route 53へのシンプルなDNSクエリを作成することで、Kubernetesで動作するサービスを発見して接続することができます。

Read More

Amazon Athena、AWS Glue、Amazon QuickSight を使って Amazon Connect のレコードを分析する

昨年、当社はあらゆるビジネスがより低コストでより良い顧客サービスを提供できるようにするためのクラウドベースのコンタクトセンターサービス Amazon Connect をリリースしました。このサービスは、Amazon のカスタマーサービスアソシエイトに与えるのと同じ技術に基づいて構築されています。このシステムを使用して、従業員は発送や注文情報を問い合わせる顧客と、何百万件の会話を行います。これは AWS のサービスとして利用できますので、コンタクトセンターのエージェントがわずか数分で電話をかけたり受けたりできるようになります。一切のハードウェアのプロビジョニングが不要です。 ドキュメントに記載されているように、AWS クラウドにコンタクトセンターを構築することにはいくつかの利点があります。さらに、顧客は幅広い AWS のサービスを利用して、Amazon Connect の機能を拡張することもできます。このブログ記事では、Amazon Connect が公開した豊富なデータセットから分析する方法を中心に説明します。Amazon Connect データストリームを利用して、エンドツーエンドのワークフローを作成し、必要に応じてカスタマイズ可能な分析ソリューションを提供します。

Read More

Amazon Comprehend と Amazon Relational Database Service を利用してテキスト分析ソリューションを構築する

これまで、大量の構造化されていないか、半分構造化されているコンテンツからの値の抽出は困難で、機械学習 (ML) のバックグラウンドが必要でした。Amazon Comprehend はエントリの障害をなくし、データエンジニアと開発者が豊富で継続的にトレーニングされた、自然言語処理サービスに簡単にアクセスできるようにします。 Amazon Comprehend からの分析を関連するビジネス情報と結合して貴重な傾向分析を構築することにより、完全な分析ソリューションを構築できます。たとえば、ブランド、製品、またはサービスについて取り上げている記事では、どの競合製品が最も頻繁に書かれているのかを理解することができます。顧客は顧客プロファイル情報と顧客のフィードバックのセンチメントも結合して、新製品を発売したときにどのタイプの顧客が特定の反応を見せるのかをより良く理解することもできます。 収集され、S3 に保存されるソーシャルメディアの投稿、ニュース記事や毎日の顧客のフィードバックなどの造化されていないか、半分構造化されているコンテンツの急速な増加により、S3 は分析できるときにもたらされる貴重な洞察の絶好の機会を提供してきました。Amazon Comprehend は Amazon Relational Database Service (RDS) とシームレスに機能します。このブログ投稿において、私たちは自然言語処理モデルの機械学習について学ぶ必要なく、データベースから豊かなテキスト分析ビューを構築する方法を紹介します。 私たちはこのことを Amazon Comprehend を Amazon Aurora-MySQL と AWS Lambda と結合して利用することで行います。これらは、センチメントを判別し、それをデータベースに返して保存するためにデータが挿入されるときに発せられる Aurora の一連のトリガーと統合されます。その後、より迅速な洞察をもたらす上で役立つ、データベースの追加データと結合できます。この同じパターンは、Amazon Translate などの他のアプリケーションレベルの ML サービスを統合して、コンテンツ自体を翻訳するために使用することもできます。 重要 -このパターンを使用しないとき: このパターンは、高速の Insert コール (1 秒間に数十を超える行数の挿入) を伴うワークロードを対象としていません。これらのトリガーは非同期ではないため、アドホック操作にのみお勧めします。Lambda 関数のコールを Insert ステートメントの後に置くことにより、各ステートメントに数十ミリ秒を追加します。トラフィックの多いデータソースの場合は、poll-aggregate-push アプローチを使用して、主たる Insert 書き込みパスから Lambda コールを削除する必要があります。 アーキテクチャ 次のダイアグラムは、このブログで設定するフローを示します。 ダイアグラムの矢印は、次のステップを示します。 MySQL […]

Read More

[AWS Black Belt Online Seminar] Amazon VPC 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日(2018/4/18) 開催された AWS Black Belt Online Seminar「Amazon VPC」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180418 AWS Black Belt Online Seminar Amazon VPC PDF 録画(オンデマンドセミナー) Q1. (自己紹介の質問) Market Place の何が好きか教えていただけるとうれしいです。 A. Network 担当ということで、様々なルータやファイアーウォール製品を時間単位で複数お試しができるので、検証が簡単にできるのが好きなところです。 Q2. 別々の VPC では物理的にネットワークが分離する認識で合っていますか。 A. 別々の VPC は論理的にネットワークが分離されます。 Q3. VPC を分ける単位のベストプラクティスはありますでしょうか。 A. ページ 76,77 でいくつか例をご紹介させていただきました。よりよいベストプラクティスをお探しの場合は是非 Well-Architectedをご参照ください。 Q4. 異なるリージョンのAZを、1つのリージョンから指定することはできますか。 A. リージョンの内部にアベイラビリティゾーン(AZ)が存在するので、指定することはできません。それぞれのリージョンから AZ を選択してください。 Q5. (サブネット作成時の)ネームタグの命名規則について推奨はありますか。 A. 特に推奨はありませんが、わかりやすいように私は […]

Read More