Category: Compute

ブロックチェーンの利用には、数多くの潜在的な利点があります。ブロックチェーンとは、検証可能かつ変更不能な方法でトランザクションを記録できる分散型データ構造です。ユースケースに応じ、コスト削減、速度や効率性の改善、企業コンプライアンスの強化、回復力やスケーラビリティの向上を実現できる可能性があります。 ブロックチェーンを早期に取り入れた人々は、金融、ヘルスケア、電子政府、非営利組織などの分野で、その革新的な使い道を発見しているところです。ブロックチェーンは、当初は仮想通貨 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 […]

本日（訳注：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で動作するサービスを発見して接続することができます。

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

これまで、大量の構造化されていないか、半分構造化されているコンテンツからの値の抽出は困難で、機械学習 (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 […]

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

こんにちは、マーケティングの鬼形です。 先日 (2018/4/11) 開催致しました AWS Black Belt Online Seminar「Amazon EC2」の資料を公開いたしました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

この記事は、Ned T. Sahin 博士 (Brain Power LLC およびハーバード大学)、Runpeng Liu (Brain Power LLC および MIT)、Joseph Salisbury 博士 (Brain Power LLC) と Lillian Bu (Brain Power LLC および MIT) によるゲストブログです。 広告からゲーム、そして教材に及ぶコンテンツの作成者は通常、事後アンケートやテスト、またはクリックスルーやバウンスなどのユーザーアクションによってコンテンツが成功したかどうかを判断します。これらの手法では、コンテンツの作成者が測定したいもの、つまりコンテンツの知覚価値が、客観的、遅発的、略式、事後、および/または相対的な代用物になりがちです。このようなメトリクスは、視聴者がその場で示すボディーランゲージに含まれる可能性がある視聴者の経時的な注意、エンゲージメント、そして快楽に関する継続的で意味のあるデータを見逃します。しかし、ボディーランゲージを数値化する、またはしばしば圧倒的な量になるビデオのデータセット内のパターンや重要なジェスチャーを単一のメトリックに要約するための系統的な手法はありません。 私たちは、落ち着きのない動き (fidgeting) や、その他の身体の動作を行動バイオマーカーとして数値的に要約するために、「Fidgetology」と親しみをこめて呼ばれる手法を発明しました。私たちは当初、自閉症および/または ADHD を持つ子供の拡張現実感システムを使用した後での症状の改善における新しい臨床的評価指標として、これらの子供たちの臨床試験ビデオを分析するために Brain Power (www.Brain-Power.com) で Fidgetology を発明しました。このブログ記事では、より一般化されたアーキテクチャと、目的に応じてすぐに試してみることができるサンプルコードをご提供します。これは、例えばあなたのコンテンツを閲覧している人のビデオなどで身体の動作を自動的に分析するために、アマゾンから新しくリリースされた人工知能製品を使用します。この手法は、映画、広告、テレビ番組、ビデオゲーム、政治運動、スピーチ、オンラインコース、または教室での授業など、様々なコンテンツタイプに応用できます。 この手法を使用することで、視聴者のビデオをストリームまたはアップロードして、視聴者の動作のレベルとパターンのわかりやすい数学的プロットとシングルイメージのサマリーを即座に取得することができます。これらの動作は、注意、焦点、エンゲージメント、不安、または快楽などの要因を推定するために役立ちます。また、これらの要因を確認して分離したり、ユニークなユースケースおよび/または個々のユーザーのためにカスタマイズしたりするために、高度な AWS Lambda 関数や機械学習モデルを追加することもお勧めします。 仕組み システムアーキテクチャダイアグラム Kinesis Video Streams インジェスチョン ビデオストリームを作成するクライアントウェブアプリケーションは、ユーザーが 1) 事前に録画されたビデオをアップロードする、および/または 2) ウェブカムフィードを […]

Amazon Redshift は、システムの履歴を STL ログテーブルに記録するデータウェアハウスサービスです。STL ログテーブルは、ログ使用状況とディスクの空き容量に応じて、2 〜 5 日間だけログ履歴を保持し、ディスクスペースを管理します。 Amazon Redshift は、監査データ用に一部の STL テーブルを Amazon S3 に自動ロギングする機能を備えています。含まれるログは、主にデータベースセキュリティとクエリの実行に関係するものです。これらの監査ログの使用については、前回の記事　「Analyze Database Audit Logs for Security and Compliance Using Amazon Redshift Spectrum」　で説明しました。 監査ログに含まれていない STL テーブルのデータからシステムデータを保持する場合は、通常、すべてのシステムテーブルに対してレプリカテーブルを作成する必要があります。次に、各レプリカテーブルに対し、システムテーブルからのデータを定期的にレプリカにロードします。STL テーブルのレプリカテーブルを管理することで、STL テーブルの履歴データに対して診断クエリを実行できます。その後、クエリの実行時間、クエリプラン、およびディスクスピルのパターンから詳細な情報を導き出し、より良いクラスターサイズを決定します。ただし、定期的な間隔で STL テーブルのライブデータでレプリカテーブルを更新するには、Cron や AWS Data Pipeline などのスケジューラが必要です。また、これらのテーブルは 1 つのクラスターに固有であり、クラスターが終了した後はアクセスできません。これは、アドホッククエリ実行が決められた期間だけ続く一時的な Amazon Redshift クラスターに、特に当てはまります。 このブログ記事では、複数の Amazon Redshift クラスターのシステムテーブルを Amazon S3 バケットにエクスポートするソリューションを紹介します。このソリューションはサーバーレスで、5 分ごとの間隔でスケジュールを設定できます。ここで使用する AWS CloudFormation […]

Amazon Elastic File System はファイルベースのストレージへの共有アクセスが必要なクラウドネイティブなアプリケーション向けにファイルシステム選択肢の一つとなるよう設計されました。私たちは2016年中頃に EFS の提供を始めて、以降、”Direct Connect 経由のオンプレミス環境からのアクセス”や”保管データの暗号化”など重要な機能をいくつも追加してきました。また、EFS を提供する AWS リージョンの追加も行ってきており、直近では US West (北カリフォルニア) が追加されました。EFS 自体がそうであったように、これらの機能追加はお客様からのフィードバックにより為されたもので、益々拡大するお客様の声に応えたいという私たちの願望を反映しています。 伝送データの暗号化 今日、EFS をより便利なものにするために伝送データの暗号化サポートを追加しました。既にサポートしている保管データの暗号化と共に使用する場合、多層防御セキュリティ ストラテジーによる格納ファイルの保護が実現されます。 伝送データの暗号化の実装をより簡単にするために、EFS マウント ヘルパーもリリースします。このヘルパー(ソースコードと RPM 形式で提供)は、EFS への TLS トンネルの確立を助けてくれるもので、また ID によるファイルシステムのマウントもできるようにするものです。この 2 つの機能はそれぞれ独立しています。ヘルパーを使用して、伝送データの暗号化をしていなくても ID でファイルシステムをマウントできます。ヘルパーは実際の mount コマンドのデフォルトオプションの推奨セットも提供してくれます。 暗号化のセットアップ Amazon Linux インスタンスに EFS マウントヘルパーをインストールするところから始めます。 $ sudo yum install -y amazon-efs-utils 次に、EFS コンソールを開き、ファイルシステム ID を取得します。 そして、その ID […]

Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが Amazon Route 53 の予測可能でフレンドリーな DNS 名で自動的に登録することができるようになります。負荷やコンテナの健全状態に対応してサービスがスケールアップまたはダウンすると、Route 53 のホストゾーンは最新の状態が保たれ、他のサービスが各サービスの状態に基づいてコネクションを行う必要がある場所を発見できるようになります。次のアドレスで、架空のソーシャルネットワークアプリでサービスディスカバリのデモを見ることができます。https://servicediscovery.ranman.com/. サービスディスカバリ マイクロサービスや最新のアーキテクチャへの移行の一部には、障害や変化する負荷に迅速に対応できるダイナミックで、オートスケーリングでき、そして堅牢であるサービスを持つことが必要とされます。皆さんのサービスはおそらく、依存したり利用されるサービスが複雑に関連した依存関係のグラフ構造を持っているでしょう。最新のアーキテクチャのベストプラクティスは、これらのサービスが独自に依存関係を指定できるようにして疎結合にすることですが、ダイナミックな環境では各サービスが自力で自身が接続する先を見つける必要があるため、複雑になってしまう場合があります。 consul、etcd、またはzookeeperなどのサービスディスカバリの従来のアプローチは、すべてこの問題をうまく解決しますが、追加のインフラストラクチャをプロビジョンして管理する必要や、コンテナやインスタンス上にエージェントをインストールする必要があります。これまでは、サービスが互いに発見して接続できるように、独自のサービスディスカバリーシステムを構成して実行するか、すべてのサービスをロードバランサに接続する必要がありました。これからは、ECS コンソール、AWS CLI、または ECS API を使用して、コンテナ化したサービスのサービスディスカバリが可能になります。 Amazon Route 53 サービスレジストリとAuto Naming API の紹介 Amazon ECS サービスディスカバリは、Amazon Route 53 サービスレジストリと Auto Naming API とコミュニケーションすることにより動作します。このブログではこれまでそれらについて触れていないため、ここでは簡単にこれらの Route 53 API の動作について概説したいと思います。最初に、一部の用語について説明します。 名前空間 – 名前空間は、トラフィックを流すドメイン名を指定します (例: internal、local、corp)。これは、サービスが互いに発見できる論理的境界と考えることができます。名前空間は、 aws servicediscovery create-private-dns-namespace コマンドの呼び出しまたはECS コンソールで作成することができます。名前空間は、Route 53 のホストゾーンとほぼ同じです。名前空間にはサービスが含まれます。これは次に取り上げる用語です。 サービス – サービスは「auth」、「timeline」、「worker」などの名前空間にある特定のアプリケーションまたはアプリケーションのセットです。サービスはサービスインスタンスを含みます。 […]