Amazon Web Services ブログ

チャットボットにウェブ UI をデプロイする

お客様は、Amazon Lex をお使いになり非常に優れたチャットボットを構築しました。Amazon Lex コンソールをご使用になりチャットボットをテストしました。これでチャットボットを皆様のウェブサイトにデプロイ出来るようになります。 お客様が独自のボットユーザーインターフェース (UI) を構築することは可能ですが、荷が重いと感じられるかもしれません。様々なデバイスとブラウザに対するサポート、承認、音声録音などを扱う必要があります。以前に既に実行されているはずだと考え、上手く再使用できるソリューションが見つかるかもしれません。 Amazon Lex チャットボット UI チャットボット UI と呼ばれる Amazon Lex ウェブ UI のサンプルは、 Amazon Lex チヤットボットにフル機能のウェブクライアントを提供する関連する重要部分にすでに対応しています。この機能を迅速に活用して時間を最小限に抑えることで、お使いになられているチャットボットを搭載したアプリケーションの価値を見出すことができます。 フルページのチヤットボット UIとして稼働させることができます。: あるいは、チャットボットウィジェットとしてサイトに組み込むこともできます。: チャットボット UI は、以下の機能をサポートしています。: フルスクリーンまたは組み込み可能なウィジェットモードを備えた、モバイルに対応する UI 音声とテキストを完全にサポートし、二者間をシームレスに切り替えることができる 自動消音検出、トランスクリプション、オーディオの録音および再生、Amazon Lex レスポンスの再生を中断する機能などの音声機能 テキストと音声の両方をサポートするレスポンスカード ホスティングサイトからチャットボット UI とプログラムを介して対話する機能 複数のデプロイメントのオプション デプロイメントと統合のオプション チャットボット UI のデプロイメントと統合には4つのオプションがあります。 AWS CloudFormation の使用 AWS Mobile Hub の使用 事前に構築されている配布ライブラリの使用 事前にパッケージ化された Vue コンポーネントの使用 […]

Read More

AWS Deep Learning AMI に TensorFlow 1.5 と新しい Model Serving 機能が追加されました

AWS Deep Learning AMI は、機械学習を迅速かつ簡単に開始する支援となります。AMI には、機械学習の実践者の多様なニーズに応えるさまざまなプレビルドのオプションが含まれています。ディープラーニングのフレームワークの最新バージョンをご希望の方には、Deep Learning AMI は、別々の Conda ベースの仮想環境にインストールされたプレビルドのピップバイナリを提供します。高度なフレームワーク機能をテストしたり、フレームワークのソースコードを調整したりするのをお求めの方のために、ソースコード付きの Deep Learning AMI では、ソースからフレームワークのカスタムインストールを提供します。これらはしばしば、ストックバイナリでは利用できない高度な最適化でビルドされます。 Volta GPU での TensorFlow によるより速いトレーニング ソースコード付き AMI には、TensorFlow 1.5.0-rc1 が付属します。このプレリリースバージョンの TensorFlow は、EC2 P3 インスタンスに電力を供給する V100 Volta GPU を利用する NVidia CUDA 9 および cuDNN 7 ドライバをサポートします。当社のテストでは、ResNet-50 ベンチマークを合成 ImageNet データで fp-16 モードで p3.8xlarge インスタンスでトレーニングすると、TensorFlow 1.4.1 でのトレーニングよりも 1.8 倍高速になりました。これはプレリリースバージョンであるため、本番環境で使用する前にテストしてください。 Ubuntu と Amazon Linux […]

Read More

AWS DeepLens Lambda 関数と最新 Model Optimizer を深く知り尽くす

AWS DeepLens 向けに最新 Model Optimizer をリリースしました。これは皆さんのディープラーニングモデルを DeepLens GPU 上で効率的に実行できるよう最適化するもので、Python のコード一行のみで実行可能です。Model Optimizer は AWS DeepLens ソフトウェアバージョン 1.2.0 で利用できます。 AWS DeepLens は推論のために GPU にアクセスする際、Cl-DNN (Compute Library for Deep Neural Networks) を使用します。そのため、AWS DeepLens 上でモデルを実行するには、Cl-DNN 形式に変換しなくてはなりません。Model Optimizer はモデルのサイズにもよりますが、次のコード 1 行で、この変換を実行します。所要時間は 2-10 秒間です。 mo.optimize(model_name,input_width,input_height) このコードを自身の Lambda 関数に含めることで、Model Optimizer にアクセスできるようになります。Lambda 推論関数を使用することにより、AWS DeepLens からデプロイしたばかりのモデルにアクセスできるようになります。この投稿では、Lambda 推論関数の作成方法について説明するとともに、皆さんの要件に合わせてカスタマイズできるテンプレートをご紹介します。 Lambda の推論はプリプロセス、推論、ポストプロセスの 3 つの関数を実行します。 Lambda 推論関数を作成するには、AWS Lambda コンソールを使用し、以下のステップに従ってください […]

Read More

水門は開いた – EC2 インスタンスのネットワーク帯域幅が増大

2016 年の中頃、Elastic Network Adapter (ENA) を使用するために AMI と現世代の EC2 インスタンスを構成するようお勧めしましたが、皆さんはきちんと宿題をこなしましたか。ENA の特徴は高スループット低レーテンシであること、その一方でホストプロセッサの負荷を最小限に留めることなどが挙げられます。複数の vCPU 環境で適切に機能するようデザインされ、複数の送信および受信キューを使ってインテリジェントにパケットのルーティングを行います。 今日、私たちは水門を開けて (帯域幅の制限を取り払って)、すべての AWS リーションでより多くの帯域幅をご利用いただけるようになりました。仕様は以下のとおりです (それぞれの事例で実際の帯域幅はインスタンスのタイプとサイズによって異なります): EC2 – S3 間 – Amazon Simple Storage Service (S3) との送受信通信量は、帯域幅で最大 25 Gbps ご利用いただけます。これまで、この通信量の帯域幅は上限が 5 Gbps に設定されていました。これは S3 にある大規模なデータにアクセスする、またはバックアップおよびリストアに S3 を使用するアプリケーションに有益です。 EC2 – EC2 間 – 同一リージョン内で、同一または異なるアベイラビリティーゾーンにある EC2 同士の通信では、ここで解説したようにプライベート IPv4 または IPv6 アドレスを使用することにより、シングルフロー通信の場合最大 5 Gbps、マルチフロー通信の場合最大 25 Gbps […]

Read More

ユニシスメインフレームからAWSへの5ステップでの移行

この記事はAstadia社のレガシーモダナイゼーションサービスのバイスプレジデントである Craig Marbleによるものです。 ユニシスメインフレームをお持ちの場合は、あなたはビジネスのバックボーンとして機能している信頼性の高いプラットフォームとアプリケーションポートフォリオの構築に投資していると思います。しかし、今日の技術環境は、ユニシス、メインフレームが提供できるよりも低コストで、より柔軟性と俊敏性を必要としています。 Amazon Web Services(AWS)のコンサルティングパートナーであるAstadiaでは、ユニシスメインフレームのアプリケーションワークロードを実行するための現代的で柔軟性のある選択としてAWSを利用しており、ユニシスメインフレームのアプリケーションとデータへの過去の投資を活用していることがわかりました。 慎重に計画、管理、実行すると、ユニシスメインフレームワークロードをAWSに移行することの利点は数多くあります。 Pay-as-you-goモデルのコスト削減に加えて、ユニシスメインフレームアプリケーションセットがAWSに完全に移行されると、実証済みのビジネスロジックを最新のテクノロジーと統合して、データ分析やモバイル対応を可能にし、新しい市場、顧客、パートナーにビジネスを拡大します。これを念頭に置いて、ユニシスメインフレームアプリケーションをクラウドに移行することは、贅沢と言うより必要にせまられてということのようです。 この記事では、ユニシスメインフレームアプリケーションをAWSに移行するのに役立つ5つのステップを紹介します。 元のアプリケーションのソースコードとデータを再利用し、最新のAWSサービスに移行することをお勧めします。 ユニシスメインフレームの移行を可能にするツールは、既存のコードをそのまま維持することができますが、一部のコンポーネントを置き換えてデータストレージを再考する必要があります。 このような最小限の変更のアプローチは、手作業の書き換えやパッケージの置き換えに比べてプロジェクトのコストとリスクを削減し、20年または30年の投資を活用しながら新しい市場を活用するための新技術との統合のメリットを享受します。ひとたび移行されると、アプリケーションは、既存のスタッフが現代化を進めるのに十分な特性をもつようになります。また価値ある知識野蓄積を新しいデベロッパーに伝えています。 ステップ1:ディスカバー まず、環境内のすべてのアプリケーション、言語、データベース、ネットワーク、プラットフォーム、およびプロセスをカタログ化して分析する必要があります。アプリケーション間のとすべての連携ポイントと、外部連携ポイントを文書化します。できるだけ多くの自動分析を使用し、すべてを一元的なリポジトリにまとめます。 Astadiaは、Micro Focus Enterprise Analyzerなどの商用分析ツールと独自に開発したパーサーを組み合わせて、従来のコードを迅速かつ効率的に分析します。この分析出力は、Astadia Code変換エンジンに供給される移行ルールを確立するために使用されます。これらのルールは、プロジェクト全体を通じて更新され、洗練されます。 ステップ2:デザイン すべてのソースコード、データ構造、および最終形の要件を分析した後、ソリューション設計をするときが来ました。設計には、以下の詳細を含める必要があります。 AWSインスタンスの詳細:インスタンスタイプについて言うと、汎用Tインスタンスは、開発、テスト、または統合環境に向いていますが、汎用Mインスタンスは本番環境、本番前環境、およびパフォーマンスが要求される環境に向いています。 トランザクション負荷:一般的な非機能要件ですが、1秒あたりのトランザクション数が多いなどのパフォーマンス要件、または迅速な応答時間は、メインフレームのワークロードの実行にとって重要な場合が多いです。このことはネットワーク、ストレージ、コンピューティングの設計とサイズ設定を慎重に行う必要があるということです。 バッチ要件:バッチアプリを動かすほとんどすべてのユニシスメインフレームは、通常I/O集約型で、ストレージやデータストアからのレイテンシーが非常に短い事が要求されます。これは分散システムの課題であるため、バッチインフラストラクチャは早期に設計してテストする必要があります。 プログラミング言語の変換と置換:移行対象先でサポートされていない言語や使用できない言語は、ツールで変換したり、新しい機能に置き換えることができます。 外部システムとの統合:ユニシスメインフレームは、一般的にサテライトやパートナーシステムのバックエンドまたは記録システム(SOR)であり、移行後にはプロトコル、インターフェイス、レイテンシー、帯域幅などの統合を維持する必要があります。 サードパーティのソフトウェア要件:各ISV(Independent Software Vendor)はAWS上で機能的に同等のソフトウェアを利用できる場合もあれば、そうでない場合もあるため、特定の移行パスの定義が必要です。 将来要件の計画:ビジネス、IT戦略、優先順位は、特に将来のパフォーマンスと統合機能に関わるため、アーキテクチャの決定を左右します。 ソースコードには、Sperry MAPPER、Burroughs LINC、COBOL、またはECLが含まれます。データストアには、DMS(ネットワーク接続)、DMSII(階層型)、またはRDMS(リレーショナル型)が含まれます。 このデザインがUnisys ClearPath Libraマッピングを探す方法は次のとおりです。 図2 – Unisys Libra(Burroughs)メインフレーム移行アーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。   同様のマッピングは、TIP、MASM、BIS(Mapper)、ECLを含むUnisys ClearPath Doradoシステムでも実行できます。 図2のアーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。 OpenMCSは、移行されたコードをサポートするUnisys COMSの必要なトランザクション処理機能を提供するAstadiaのメッセージ制御システムです。このメインフレームクラウドフレームワークは、コンピュートリソースとしてAmazon Elastic Compute Cloud(Amazon EC2)上で動作します。 ほとんどの場合、ユニシスメインフレームの階層型およびフラットファイルのデータ構造は、Amazon Relational Database Service(Amazon […]

Read More

【開催報告】Gaming Tech Night #2 re:Born(再始動)

こんにちは。ゲームソリューションアーキテクトの吉田です。 昨日1/24(水)に第2回となるGaming Tech Nightを開催し、多くのゲーム開発者、インフラエンジニアの方々にご参加いただきました。Gaming Tech Nightは過去2016年に開催された、ゲームに特化した技術情報をお届けすることを目的としたAWS主催のイベントでしたが、今年からは定期開催イベントとして新しく生まれ変わりました。記念すべき再開1回目となる今回は、re:Born(再始動)というタイトルでサーバレスやCI/CDなど複数のテーマで計4セッションをお届けしました。   サーバレスアーキテクチャ入門 ~ Game Server Services 丹羽様 Game Server Services株式会社 代表取締役社長CEOの丹羽様より、サーバレスアーキテクチャについてご講演いただきました。入門というタイトルですが、サーバレスの定義から実装に関する注意点、実際に丹羽様が構築・運用する中で習得されたノウハウなどが詰まった内容の濃いセッションでした。これからサーバレスをはじめる方だけでなく、すでに構築・運用されている方々にも非常に参考になるポイントが多かったのではないかと思います。登壇資料はGS2 Blogで公開されています。   AWSにおけるモバイルゲーム向けAPIサーバの実装2018 ~ ソリューションアーキテクト 畑 ソリューションアーキテクトの畑より、モバイルゲームを対象としたAWSにおけるAPIサーバ実装について解説しました。典型的な実装パターンである3層Webアプリケーションパターンをはじめ、API Gateway+Lambda+DynamoDBを利用したサーバーレスアーキテクチャ、アプリケーション上で実装されたAWS SDKを通じて各AWSサービスのAPIに直接アクセスする2-Tierアーキテクチャなどの実装ポイントをご紹介しました。また、現在Public Preview中であるAWS AppSyncによる実装パターンにも触れました。API用のクエリ言語であるGraphQLは、クライアント〜サーバ間で共有される型が利用できたり、クライアント側からサーバのレスポンスデータの形式を指定できたりとモバイルゲームでも応用できる多くの利点があります。AWS AppSyncはマネージドなGraphQLのサービスであり、ゲーム開発者の方にもインフラを意識することなくご利用いただけます。ぜひPreviewにご参加ください。 Serverless backendformobilegame and_aws-appsync_gamingtechnight-2 from Amazon Web Services Japan   AWS上で実現するゲーム開発CI/CDパイプライン ~ ソリューションアーキテクト 森 ソリューションアーキテクトの森からは、AWSのCode系サービスを利用したゲーム開発におけるCI/CDパイプラインの実装例の解説とデモを披露しました。ソースコードをCodeCommitにpushし、CodeBuildによるビルド、CodeDeployによるステージング環境へのデプロイ、そしてステージングでのテスト完了後に再度CodeDeployを使って本番環境にという一連の流れをCodePipelineを自動化することが可能です。特にコードのビルドについては、ビルド用で常にインスタンスを確保されているお客様も多いと思いますが、CodeBuildはビルド実行時間のみの課金となりますので、コストが削減できるケースも多いと思います。ぜひゲーム開発のCI/CDにおいてもAWSのマネージドサービスをご活用ください。 Gaming cicd-pipeline gaming-technight-2 from Amazon Web Services Japan   AWSを最大限活用したロングヒット戦略 ~ Amazon […]

Read More

AWS Glue がScala をサポートしました

私たちは、AWS Glue の ETL(Extract、Transform、Load)を実行するためのスクリプトにおけるScalaのサポートを発表することに興奮しています。Scala が好きな人達は強力な武器を1つ手に入れることになり喜んでくれるでしょう。AWS Glue では Apache Spark をデータ加工のエンジンとして使用していますが、Scala は Apache Spark のネイティブな言語です。 洗練された言語としての機能が使える以外にも、Glue のスクリプトをScala で書くことはPython で書くことに比べて2つの利点があります。まずは、Python とApache Spark のScala ランタイム(JVM)の間でデータを移す必要がないので、Scala は大量のデータ移動を伴う加工整形処理がより高速です。サードパーティのライブラリで独自の変換を作成したり関数を呼び出すことができます。 次に、Scala はJava と互換性があるように設計されているため、外部Java クラスライブラリの関数をScala から呼び出すことが簡単です。 そのため、Scala のコンパイル結果は Java と同じバイトコードになりますしデータ構造を変換する必要もありません。 これらの利点を説明するために、GitHubアーカイブから入手可能なGitHub パブリックタイムラインの最近のサンプルを分析する例を説明します。このサイトはGitHubサービスへのパブリックリクエストのアーカイブで、コミットとフォークから、イシューとコメントまで35種類以上のイベントタイプを記録しています。 この記事は、タイムラインのネガティブなイシューを特定するScala スクリプト作成の方法を紹介します。このスクリプトではタイムラインサンプルのイシュー イベントを引き出し、Stanford CoreNLPライブラリのセンチメント推定機能を使用してタイトルを分析し、最もネガティブなイシューを浮き彫りにしています。 入門 スクリプトを作成する前に、AWS Glue Crawler を使ってデータ構造と特性を理解します。また、開発エンドポイントとZeppelin ノートブックをセットアップすることで、データをインタラクティブに探索してスクリプトを作成することもできます。 データをクロールする この例で使われているデータセットは、GitHub アーカイブからAmazon S3 のサンプルデータセットバケットにダウンロードされています。場所は以下の通りです: s3://aws-glue-datasets-<region>/examples/scala-blog/githubarchive/data/ <region>をあなたの作業中のリージョンに置き換えて最適なフォルダを選択してください。例えばap-northeast-1 などです。AWS Glue Developer Guide […]

Read More

高い可用性を持つ IBM Db2 データベースをAWS上に構築する

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。 従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。 注:このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。(訳注:こちらにエディションの違いの詳細があります) この記事のステップを進めていくと、2つのアベイラビリティゾーン(AZ)にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。 事前準備のステップ このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。 同一リージョンの2つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。 VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。 最初にAmazon S3 […]

Read More

東京リージョンに新たにアベイラビリティゾーンを追加

本日 東京リージョンにて、新たにアベイラビリティゾーンを追加しました。東京リージョンは、追加のアベイラビリティゾーンを合わせ、4つのアベイラビリティゾーンになりました。 AWSは、世界中に18の物理的なリージョンと51のアベイラビリティゾーンがあります。本日追加されたアベイラビリティゾーンは、シンガポールリージョンに続き52番目となり、東京リージョンでAWSのクラウドコンピューティングをご利用の10万以上のお客さまにご利用いただけます。 アベイラビリティゾーンは、自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。各アベイラビリティゾーンは、独立した電源、空調、物理的なセキュリティを備え、広帯域でハイスピードの光回線のバックボーンに接続されています。AWSのお客さまは、アプリケーションを複数のアベイラビリティゾーンを利用することで高い耐障害性を実現することができます。また、100以上の Amazon CloudFront エッジロケーションにより遅延を最小化しつつ、ウェブサイト、アプリケーションおよびコンテンツの配信が可能となります。 すでに東京リージョンをお使いのお客さまは、追加されたアベイラビリティゾーンにおいて、東京リージョンで利用可能なすべてのサービスを利用できます。

Read More

NNPACK ライブラリを使用した Apache MXNet の高速化

Apache MXNet は、ディープラーニングネットワークをビルドし、トレーニングし、再利用するために開発者が利用できるオープンソースライブラリです。このブログ投稿では、NNPACK ライブラリを使用して推論を高速化する方法を説明します。確かに、GPU 推論が利用できない場合、NNPACK を Apache MXNet に追加することは、インスタンスからより大きなパフォーマンスを引き出すための簡単なオプションかもしれません。常にそうですが、「かかる労力は異なる場合があり」、常に自分自身でテストを実行する必要があります。 開始する前に、トレーニングと推論の基礎の一部を確認していきましょう。 トレーニング トレーニングとは、ニューラルネットワークがデータセット内の各サンプルに対して正しいラベルを正しく予測する方法を学習するステップです。1 回に 1 個のバッチ (通常 32〜256 サンプル) ずつ、データセットがネットワークに送出され、バックプロパゲーションアルゴリズムを利用して、重みづけを調整することにより、エラー数の合計が最小限に抑えられます。 完全なデータセットを調べることをエポックと呼びます。大規模ネットワークは、可能な限り高い精度を達成するために、何百ものエポックに対してトレーニングする場合があります。これには数日から数週間かかることもあります。強力な並列処理能力を備えた GPU を使用することで、最も強力な CPU に比べてさえも、トレーニング時間を大幅に短縮することができます。 推論 推論とは、実際にトレーニングされたネットワークを使用して新しいデータサンプルを予測するステップです。Amazon Rekognition のように単一の画像内のオブジェクトを識別しようとする場合など、一度に 1 つのサンプルを予測することや複数のユーザーからの要求を処理するときに、複数のサンプルを同時に予測することなどが可能です。 もちろん、GPU は推論でも同様に効率的です。しかし、多くのシステムは、コスト、消費電力、またはフォームファクタの制約のために GPU に対応できません。したがって、CPU ベースの推論では、高速で実行できることが依然として重要なトピックになっています。ここでは NNPACK ライブラリが Apache MXNet で CPU 推論を高速化するのに役立つため、NNPACK ライブラリが、が採用されます。 NNPACK ライブラリ NNPACK は、GitHub で利用できるオープンソースライブラリです。どのように役立つのでしょうか?コンボリューションニュートラルネットワークについてお読みいただいていることでしょう。これらのネットワークは、コンボリューションとプーリングを適用して入力画像内の機能を検出する複数のレイヤーからビルドされています。 この投稿では実際の理論には触れませんが、NNPACK が高度に最適化される方法でこれらのオペレーション (および行列の乗算のような他のオペレーション) を実施しているとだけ申しておきましょう。基礎理論にご興味があるようでしたら、この Reddit の投稿で著者が述べた研究論文を参照してください。 NNPACK […]

Read More