Amazon Web Services ブログ

Category: Events

Amazon Connect – よりスマートになり、サードパーティーツールとの統合が向上

2017 年の Amazon Connect のローンチ以来、何千社ものお客様がクラウドで独自にコンタクトセンターを構築しておられます。Amazon Connect は、非技術系のお客様によるインタラクションフローの設計、エージェントの管理、およびパフォーマンスメトリクスの追跡を容易にします。 たとえば、ヨーロッパで Best Western ホテルの部屋を電話で予約した場合、その通話は Amazon Connect によって管理されます。イギリスでは、郵便局が、アイデアから本稼働開始までわずか 3 週間で完了しました。フランスでは、ビジネスプロセスアウトソーシングの世界的リーダーである WebHelp が、わずか 72 時間で数千台のワークステーションとリモートエージェントをアクティブ化しました。 Amazon Connect について最後にブログを投稿して以来、チームは継続的にお客様からのフィードバックを聞いています。本日、Amazon Connect をよりスマートにし、サードパーティのツールとの統合を強化する新しい機能セットを発表できることをうれしく思います。 機械学習 (ML) を使用して、Amazon Connect が、会話をリアルタイムで分析し、コンタクトセンターのエージェントが必要とする関連情報を見つけ、顧客の声で顧客を認証することで、よりスマートにしてます。2 番目の機能セットにより、Amazon Connect はサードパーティのツールやサービスとの統合が容易になり、統合化された顧客プロファイル情報をコンタクトセンターエージェントに提示し、タスクの管理を容易にします。 それでは、詳細を一つずつ見ていきましょう。 Contact Lens Real Time Contact Lens for Amazon Connect は、機械学習 (ML) 機能のセットです。これを使うと、コンタクトセンターのスーパーバイザーは、顧客との会話の感情、傾向、コンプライアンスをよりよく理解することができます。re:Invent 2019 で初めて発表され、2020 年 7 月から 利用可能になりました。エージェントを効果的にトレーニングし、成功したインタラクションを複製し、企業と製品に関する重要なフィードバックを特定することができます。 本日から、顧客が不満を表明するなど、ライブ通話中のカスタマーエクスペリエンスに関するリアルタイムの洞察を得ることができます。カスタマーエクスペリエンスの分析とライブコールのアラートは、Amazon Connect のリアルタイムメトリクスダッシュボードで配信されます。スーパーバイザーは、重要なコールをいつリッスンするかを特定し、チャットを介してエージェントにガイダンスを提供したり、エージェントにコールを転送して支援を求めたりすることが容易になります。 […]

Read More

AWS Panorama Appliance: コンピュータービジョンアプリケーションをエッジへ

本日 AWS re:Invent で、AWS Panorama Appliance のプレビューを行いました。また、AWS Panorama SDK が近日公開される予定であることも発表いたしました。これにより、組織はコンピュータビジョンをオンプレミスのカメラに取り込み、高精度で低レイテンシーな自動予測を行うことができます。 過去数十年にわたり、コンピュータビジョンは、学者によって議論されるトピックから、世界中の企業で使用されるツールへと変化してきました。この成長を実現するうえで、クラウドが重要であり、これまで不可能だったサービスやインフラストラクチャ機能が急増しています。 お客様は、製造ライン上の部品の検査、危険な場所での作業員のヘルメットの着用の確認、小売店での顧客トラフィックの分析など、物理的なシステムに関するさまざまな課題に直面しています。お客様は、多くの場合、問題やインシデントが発生した後に、ライブビデオフィードを手動で監視したり、録画した映像を確認したりして、これらの問題を解決しています。こうしたソリューションは、手作業でエラーが発生しやすく、拡張が困難です。 コンピュータビジョンは、クラウドで実行されているモデルを使用して、こうした検査タスクを実行するためにますます使用されています。それでも、レイテンシーの要件や断続的な接続により、クラウドへのラウンドトリップを実現できないため、クラウドのみに依存することが最適ではない場合があります。 本日の発表内容 これからは、Amazon SageMaker を使用してコンピュータービジョンモデルを開発し、それを Panorama Appliance にデプロイして、複数のネットワークと IP カメラからのビデオフィードでそのモデルを実行させることができるようになります。Panorama Appliance と関連するコンソールがプレビュー中です。 近日公開予定の Panorama SDK は、サードパーティデバイス製造元が Panorama 対応デバイスを構築するために使用できるソフトウェア開発キット (SDK) です。Panorama SDK は柔軟性が高く、設置面積が小さく、ハードウェアベンダーがさまざまなフォームファクタやセンサで新しいデバイスを簡単に構築できます。したがって、工業用地、低照度シナリオ、屋外など、さまざまな業界や環境のユースケースを満たすことができます。 アプライアンスの開梱 このブログを書くことができるように、AWS re:Invent の数週間前に Jeff に Panorama Appliance が送られました。これは、Jeff のオフィスに設置されたデバイスの写真です。 Panorama Applianceをセットアップするには、コンソールに移動し、[Get Started] をクリックします。 コンソールには、Panorama Appliance でコンピュータビジョンモデルを実行するための 3 ステップのガイドが表示されます。このブログでは、Panorama Appliance のセットアップに役立つステップ […]

Read More
AWS Amplify Admin UIのご紹介

新機能 – AWS Amplify Admin UI: アプリケーションのバックエンド開発を支援し、クラウドの経験を必要としない管理ツール

この記事は、New AWS Amplify Admin UI Helps You Develop App Backends, No Cloud Experience Requiredを翻訳したものです。 2018年にAWS Amplifyをリリースしてから、ウェブのフロントエンドとモバイルアプリケーションの開発者の開発とクラウド環境へのデプロイを支援してきました。時代の最先端を行き、顧客にイノベーションを提供するためにもプロダクトは機能を素早く届ける必要があります。しかし、クラウド、AWSの基本的な操作に慣れていない場合は、開発者・非開発者に関わらず学習やトレーニングが必要となります。この学習コストは、設計や実装、意思判断などプロセス全体の速度の低下を招きます。 本日、AWS AmplifyはチームメンバーがAWSアカウントを必要とせずにAWSの利用を可能とする新機能Admin UIをリリースしました(AWSアカウントは、最初のデプロイでのみ必要となります)。 Admin UIは、データベーステーブルのモデリング、認可認証機能の追加、アプリケーションのコンテンツ・管理者・管理者グループの管理を行うシンプルで強力なツールを提供します。また、アプリケーションのユーザーや、ユーザーによって作成されたコンテンツの管理を行う機能も提供します。Admin UIは、バックエンドやインフラストラクチャではなくデータモデルに焦点を当てています。全てのバックエンドのリソースは、チームのリポジトリで管理可能なInfrastructure as Code(IaC)のテンプレートを生成します。また、このリソースはAWS Amplifyの継続的デプロイのワークフローと統合されており、異なる環境(environment)ごとに管理が可能となっています。 新機能: AWS Amplify Admin UIを使った例のご紹介 あなたは、地元にあるレストランのウェブサイトを開発しているフロントエンド開発者であると想像してみてください。レストランのオーナーは、日替わりメニューを掲載できるようなウェブサイトで、毎日ウェブサイト上のコンテンツを簡単に更新したいと考えています。 この要求を満たすシステムの実装方法は多くあります。例えば、サーバーを構築し、CMSをインストールし、レストランのオーナーが日替わりメニューの更新を行うための機能を実装することができます。しかし、この要求を満たすためだけにサーバーを構築するのは、過剰に設備投資を行うことになります。他の実装方法として、サーバーレスのサービスを使用して自分でCMSを構築することもできますが、開発が複雑になり、より多くの時間が開発をするのに必要となります。 AWS Amplifyの新機能Admin UIを活用することで、既存のAWSのマネージドサービスを活用しながらバックエンドを素早く構築することができます。また、アプリケーションのユーザーとコンテンツの管理を行う機能も提供します。 Admin UIを利用するために、最初にAWS Console内のAWS Amplifyの管理画面にてアプリケーションのバックエンド(backend)を作成してください。これにより、AWS Amplifyはstagingと呼ばれるバックエンドの環境(environment)を作成します。バックエンドの作成が完了したら、早速Admin UIを開いてみましょう。AWSの利用経験がなく、AWSアカウントを持っていない開発者を招待したい場合は、この段階でAdmin UIへのアクセス権限を付与することができます。今回の例では、あなた一人で全ての開発を行う想定とし、管理者の追加は行わないこととします。 Admin UIでは、アプリケーションの開発者がバックエンドを構成するために必要な開発ツールと、コンテンツの管理者がアプリケーションのコンテンツを管理するための機能が含まれています。 Admin UIのサイドバー(下記の画像参照)にて、アプリケーションの設定を行うための様々なオプションを確認することができます。 レストランのウェブサイト構築を行う最初のステップとして、日替わりメニューのためのデータモデルを作成してみましょう。次の3ステップを実行してみましょう Dataタブに移動 Menuという名前でデータモデルを作成 必要なデータ項目を追加して保存とデプロイ データモデルを保存とデプロイを行うと、メニュー項目を保存するAmazon DynamoDBのテーブルやGraphQLのAPIを提供するAWS AppSyncなどのリソースがAWS上に自動で作成されます。 デプロイの完了には数分程度かかります。 モデルがデプロイされたら、次にウェブサイトのフロントエンドを構築してみましょう。今回は、AWS […]

Read More

予知保全を可能にするシンプルでコスト効率性に優れた Amazon Monitron

本日、Amazon Monitron を発表しました。Amazon Monitron は状態モニタリングサービスで、潜在的な障害の検出、および開発中の誤りの追跡により、予知保全を実施し、予期しないダウンタイムを低減できます。 実話:数ヶ月前、私は新しい洗濯機を購入しました。配達業者が地下室にそれを設置した時に、最近製品は数年も持たなく、信頼できなくなっていることについて雑談しました。彼が去ろうした時に、私は老朽化してメンテナンスが不十分な給湯器を指さし、数週間後にこれを新しいものと交換することを伝えました。信じがたいことに、次の日それが壊れました。どうぞ、笑ってください。事前に計画していないので当然のことです。 この出来事には苛立ちましたが、生産ラインや倉庫などの産業環境で機械の予期せぬ故障による時間やコストの巨大な損失に比べれば、何てことありません。砂粒が原因で予定外の停止が起こることもあります。事は最悪の形で、最悪の時に起こる可能性が高い、そして結果として、深刻なビジネスへの影響をもたらすということを、マーフィーの法則から学びました。 故障を回避するために、信頼性マネージャやメンテナンス技術者が次の 3 つの戦略を組み合わせることがよくあります。 故障まで実行 :確実に動作しなくなるまで、メンテナンスをせずに機器を操作させる。修理の完了後、機器を稼働状態に戻す。ただし、機器の状態は不明で、故障は制御不能です。 計画的保守 : 状態に関係なく、事前定義された保守作業が定期的または計量の基準で実行される。計画的なメンテナンス活動の有効性は、メンテナンスの指示や計画するサイクルの良し悪しに依存します。機器のメンテナンスが過剰だったり、あるいは不十分だったりする場合に、不必要なコストが発生したり、故障が発生したりする危険性があります。 状態基準保全 : 監視対象コンポーネントの状態が定義済みのしきい値を超えたときにメンテナンスを完了させる。耐性、振動、温度などの物理的特性を監視することは、より適切な戦略です。これにより、メンテナンスの必要性やメンテナンスコストを低減できます。 予知保全 : コンポーネントの状態を監視し、潜在的な障害を検出し、障害の発生を追跡する。メンテナンスは、将来予想される障害発生の前に、且つメンテナンスの総コストが最も効率の高いときに計画します。 状態基準保全と予知保全では、重要な機器にセンサーを設置する必要があります。これらのセンサは、温度や振動などの物理量を測定し、取得します。その変化は、潜在的な故障または悪化状態の先行指標となります。 ご想像のとおり、このようなメンテナンスシステムの構築と導入には、特注のハードウェア、ソフトウェア、インフラストラクチャ、プロセスなどが必要で、長期的かつ複雑でコストのかかるプロジェクトになる可能性があります。お客様から支援を求められ、この事業に取り組みました。 Amazon Monitron のご紹介 Amazon Monitron は、簡単に利用ができて、費用対効果の高い監視サービスで、施設内の機器の状態を監視し、予知保全プログラムを実施します。 Amazon Monitron の設定はとても簡単です。まず、 Monitron センサーをインストールします。これで、ベアリング、ギアボックス、モーター、ポンプ、コンプレッサ、ファンなどの回転機械から振動と温度データを取得します。センサーは、Bluetooth Low Energy (BLE) 技術を使用して、振動と温度の測定値を近くの Monitron ゲートウェイに毎時送信します。センサーを少なくとも 3 年間稼働させることができます。 Monitron ゲートウェイ自体は WiFi ネットワークに接続され、センサーデータを AWS に送信します。データは格納され、機械学習と ISO 20816 振動関連規格を使用して分析されます。 通信頻度が低いため、最大 20 個のセンサーを 1 […]

Read More

新機能 – キャパシティに関わらずパフォーマンスをプロビジョニングできる Amazon EBS gp3 ボリューム

Amazon Elastic Block Store (EBS) は、あらゆる規模のスループット集約型のワークロードとトランザクションを集中的に使用するワークロードの両方で Amazon EC2 インスタンスとともに使用するために設計された、使いやすく高性能なブロックストレージサービスです。既存の汎用ソリッドステートドライブ (SSD) gp2 ボリュームを使用すると、ストレージキャパシティーに応じてパフォーマンスをスケールできます。より大きなストレージボリュームのサイズをプロビジョニングすることで、アプリケーションの 1 秒あたりの入力/出力オペレーション (IOPS) とスループットを向上させることができます。 ただし、MySQL、Cassandra、Hadoop クラスターなどの一部のアプリケーションは、高パフォーマンスを必要としますが、高キャパシティーストレージは必要としません。お客様は、必要以上のストレージボリュームに料金を支払うことなく、このようなタイプのアプリケーションのパフォーマンス要件を満たすことを望んでいます。 本日は、ストレージキャパシティーに関係なくパフォーマンスをプロビジョニングでき、既存の gp2 ボリュームタイプよりも 20% 低い価格で提供される、新しいタイプの SSD EBS ボリュームである gp3 について説明したいと思います。 新しい gp3 ボリュームタイプ EBS では、お客様はアプリケーション固有のニーズに基づいて複数のボリュームタイプから選択できます。非常に低価格な SSD パフォーマンスを提供するために、当社は 2014 年に汎用 SSD gp2 ボリュームを導入しました。gp2 は、仮想デスクトップ、SQLServer や OracleDB などの中規模データベース、開発およびテスト環境など、お客様が使用する多くのアプリケーションのパフォーマンスとスループットの要件を満たすための簡単でコスト効率の高い方法を提供します。 とはいえ、一部のお客様はさらに高いパフォーマンスを必要としています。gp2 の背後にある基本的な考え方は、キャパシティーが大きいほど IOPS も高速になるというものです。そのため、お客様は希望以上のストレージキャパシティーをプロビジョニングすることになってしまう可能性があります。gp2 は低価格ですが、お客様は不要なストレージに料金を支払うことになります。 新しい gp3 は、EBS ボリュームタイプの 7 つ目のバリエーションです。これにより、お客様は必要なリソースの分だけを支払い、追加のブロックストレージキャパシティーをプロビジョニングすることなく、IOPS […]

Read More

新登場 – アプリケーションのエラーと修正の特定に役立つ Amazon DevOps Guru

本日、完全マネージド型運用サービスの Amazon DevOps Guru を発表します。Amazon DevOps Guru は、運用上の問題を自動的に検出して修正を推奨することで、デベロッパーやオペレーターがアプリケーションの可用性を容易に向上させることができるようにするサービスです。DevOps Guru は、Amazon.com とアマゾン ウェブ サービス (AWS) の長年にわたるオペレーショナルエクセレンスを習得した機械学習を適用し、アプリケーションメトリクス、ログ、イベントなどのデータを自動的に収集および分析し、通常の運用パターンから逸脱した動作を特定します。 動作が運用上の問題またはリスクとして特定されると、DevOps Guru はデベロッパーとオペレーターに問題の詳細を通知し、問題の範囲と原因の可能性を迅速に把握できるようにします。DevOps Guru では問題を解決するためのインテリジェントな推奨事項が提供されるため、解決までにかかる時間を節約できます。DevOps Guru では、ハードウェアやソフトウェアをデプロイする必要はなく、分析されたデータに対してのみ課金されます。前払いコストやコミットメントは発生しません。 分散された/複雑なアーキテクチャとオペレーショナルエクセレンス アプリケーションの分散化と複雑化が進むにつれ、オペレーターはアプリケーションの可用性を維持し、運用上の問題の検出、デバッグ、および解決に費やす時間と労力を削減するために、より自動化されたプラクティスを必要とします。例えば、設定ミス、不均衡なコンテナクラスター、またはリソースの枯渇などによるアプリケーションのダウンタイムは、企業にとって大きな収益損失につながる可能性があります。 多くの場合、企業は、メトリクス、ログ記録、トレース、イベントなどの複数のモニタリングツールをデプロイおよび管理し、それらをさまざまな場所に保存して分析するといった、デベロッパーの作業にかかる時間に投資する必要があります。また、デベロッパーやオペレーターは、ロードバランサーでのエラーのスパイクやアプリケーションのリクエストレートの異常な低下などの問題を警告するために、カスタムアラームの開発と保守に時間を費やしています。問題が発生すると、オペレーターは同じ問題に関連する複数のアラートを受け取り、アラートを組み合わせて、すぐに対応しなければならないアラートに優先順位を付けます。 DevOps Guru の仕組み DevOps Guru の機械学習モデルは、過去 20 年にわたって、AWS の専門知識を活用して世界最大の電子商取引ビジネス向けに高可用性アプリケーションを実行しています。DevOps Guru は、運用上の問題を自動的に検出し、考えられる原因を詳述し、修復アクションを推奨します。DevOps Guru は、Amazon CloudWatch、AWS Config、AWS CloudTrail、AWS CloudFormation、AWS X-Ray をサポートする複数のソースにまたがるデータを統合することにより、運用データを検索および可視化する単一のコンソールエクスペリエンスをお客様に提供し、複数のツールを使用する必要がなくなります。 DevOps Guru の開始方法 DevOps Guru のアクティブ化は簡単で、AWS マネジメントコンソールにアクセスして [Enable (有効)] をクリックだけです。DevOps Guru […]

Read More

プレビュー開始 – より優れたスループットを提供する、さらに大規模で高速な io2 Block Express EBS ボリューム

Amazon Elastic Block Store (EBS) ボリュームは、2008 年の発売以来、EC2 の必要不可欠なコンポーネントです。現在、特定のユースケースに対応し、指定されたパフォーマンスが得られるように設計された 6 種類の HDD ボリュームおよび SSD ボリュームから選択できます。 今年初めに、以前の io1 ボリュームよりも 100 倍高い耐久性と 10 倍の IOPS/GiB を備えた io2 ボリュームを発売しました。io2 ボリュームは、ハイパフォーマンスでビジネスクリティカルなワークロードなど、I/O 負荷が高くレイテンシーの影響を受けやすいアプリケーションに最適です。 さらに進化 本日から、さらに優れたパフォーマンスを提供する io2 Block Express ボリュームのプレビューを開始します! このボリュームは、AWS Nitro System の一部として実装された高度な通信プロトコルを活用した新しい EBS Block Express アーキテクチャに基づいて構築され、最大 256 K IOPS と 4000 MBps のスループット、最大 64 TiB のボリュームサイズを実現します。すべてミリ秒未満で、低分散 I/O レイテンシーです。スループットは、プロビジョンド IOPS ごとに […]

Read More

AWS Lambda の新機能 – コンテナイメージのサポート

AWS Lambda では、サーバーについて気にすることなくコードをアップロードして実行できます。多くのお客様に Lambda のこの仕組みをご活用いただいていますが、開発ワークフローのためにコンテナツールに投資した場合は、Lambda でのアプリケーションの構築に同じアプローチを使用することが難しくなります。 この問題に対応するため、Lambda 関数を最大 10 GB のコンテナイメージとしてパッケージ化し、デプロイできるようになりました。これにより、機械学習やデータ集約型のワークロードなど、大きな依存関係に頼る大規模なワークロードを簡単に構築してデプロイできます。ZIP アーカイブとしてパッケージ化された関数と同様に、コンテナイメージとしてデプロイされた関数は、同様の操作のシンプルさ、自動スケーリング、高可用性、多数のサービスとのネイティブ統合による恩恵を受けます。 当社では。サポートされているすべての Lambda ランタイム (Python、Node.js、Java、.NET、Go、Ruby) のベースイメージを提供しているため、コードと依存関係を簡単に追加することができます。Amazon Linux ベースのカスタムランタイム用のベースイメージも用意しており、これを拡張して Lambda ランタイム API を実装する独自のランタイムを含めることができます。 Alpine や Debian Linux をベースにしたイメージなど、独自のベースイメージを任意で Lambda にデプロイできます。Lambda を操作するには、これらのイメージに Lambda ランタイム API を実装する必要があります。独自のベースイメージの構築を容易にするため、当社ではサポートされているすべてのランタイムにランタイム API を実装する Lambda Runtime Interface Clients をリリースしています。これらの実装は、ネイティブのパッケージマネージャーを介して利用できるため、イメージ内で簡単に取得でき、オープンソースライセンスを使用してコミュニティと共有されます。 また、Lambda Runtime Interface Emulator をオープンソースとしてリリースします。これにより、コンテナイメージのローカルテストを実行して、Lambda にデプロイした際に実行されることを確認することができます。Lambda Runtime Interface Emulator は、AWS が提供するすべてのベースイメージに含まれており、任意のイメージでも使用できます。 コンテナイメージは、Lambda Extensions […]

Read More

新機能 – Amazon S3 Replication が複数の宛先バケットのサポートを開始しました

Amazon Simple Storage Service (S3) は、2019 年にローンチされた S3 Same-Region Replication (SRR)、および 2015 年から利用され続けている S3 Cross-Region Replication (CRR) などの数多くのレプリケーションタイプをサポートします。本日、AWS は複数の宛先バケットに対する S3 Replication のサポートを発表します。これにより、S3 Replication は、1 つのソースバケットから複数の宛先バケットにデータをレプリケートできるようになりました。S3 Replication (複数宛先) を使用すると、同じ AWS リージョン内のデータの場合は S3 SRR、異なる AWS リージョンにまたがるデータの場合は S3 CRR を使用してデータをレプリケートでき、これらの組み合わせを使用することもできます。 このローンチまでは、異なる S3 バケットにあるデータの複数のコピーを作成する必要がある場合、S3 イベントを監視し、作成されたオブジェクトを識別して、各宛先バケットにオブジェクトをコピーするための AWS Lambda 関数を使用することによって、独自の S3 Replication サービスを構築しなければなりませんでした。 このローンチによって、複数の宛先全体へのデータのレプリケーションに独自のソリューションを開発する必要がなくなります。S3 Replication (複数宛先) の柔軟性は、用途に応じて異なるストレージクラス、異なる暗号化タイプ、または異なるアカウント全体でデータの複数のコピーを保存するために利用できます。さらに、複数の宛先にレプリケートするときは、CloudWatch メトリクスを使用して各リージョンペアのレプリケーションの進行状況を追跡できます。 S3 Replication (複数宛先) […]

Read More
Amazon ECS Anywhere のご紹介

Amazon ECS Anywhere のご紹介

この記事は、Introducing Amazon ECS Anywhere を翻訳したものです。 2014 年、AWS は EC2 インスタンス上で稼働する様々な規模のコンテナの管理を簡潔にするために Amazon Elastic Container Service (Amazon ECS) を発表しました。Amazon ECS の採用が増えるにつれて、お客様は「Undifferentiated Heavy Lifting」(差別化につながらない重労働) である、コンテナを実行するための EC2 インスタンスの管理を取り除くという新しい問題に対応していました 。そして 2018 年、AWS はコンテナを実行するためのインフラストラクチャの管理が不要なサーバーレスプラットフォームである AWS Fargate を発表しました。 この 2 年間、お客様は Amazon ECS を利用したコンテナのデプロイが、より多くの場所で行える柔軟性を求めていました。AWS リージョンの外部で、他の連携するサービスの近くでアプリケーションを実行するようなユースケースが増えていました。2019 年と 2020 年に、AWS は Amazon ECS のタスクを AWS リージョンの外部で実行可能にするオプションに関する一連の発表を行いました。AWS Outposts は、AWS が所有・管理するハードウェアを利用して、AWS のインフラストラクチャ、サービス、API、そしてツールをお客様のオンプレミス環境に拡張します。AWS Wavelength と AWS Local […]

Read More