Amazon Web Services ブログ

re:Invent 2016 では AWS Step Functions を開始しました。お客様はすぐにサービスを利用して、多段階ワークフローのコア要素として使用しました。現在、機械学習トレーニング、レポート生成、注文処理、IT オートメーション、およびその他の多くの多段階プロセスを調整するサーバーレスワークフローを構築しているお客様もいらっしゃいます。これらのワークフローは最大 1 年間実行でき、チェックポイント、一時的な障害の再試行、監査目的での詳細状態の追跡を含むワークフローモデルを中心に構築されます。 使用状況とフィードバックから、お客様方がコアな Step Functions モデルを非常に好んでいることがわかります。お客様は、宣言仕様と、ワークフローを簡単に構築、テスト、スケーリングできることを気に入っています。実際、お客様は Step Functions が非常にお気に入りのため、IoT データの取り込み、ストリーミングデータ処理、モバイルアプリケーションバックエンドなどの大容量で短期間のユースケースに使用したいと考えています。 新しい高速ワークフロー 本日、既存の標準ワークフローのオプションとして高速ワークフローを開始しました。高速ワークフローは同じ宣言仕様モデル (Amazon States Language) を使用しますが、これらの大容量で短期間のユースケース向けに設計されています。知っておくべきことは、次のとおりです。 トリガー – AWS サービスの長いリストに関連付けられたイベントと読み取り/書き込み API 呼び出しを使用して、高速ワークフローの実行をトリガーできます。 実行モデル – 高速ワークフローは 1 回以上実行モデルを使用し、失敗したステップを自動的に再試行することはありませんが、エラー処理で説明されているように、再試行とキャッチを使用できます。ステップはチェックポイントとして表示されないため、ステップごとのステータス情報は利用できません。成功と失敗は CloudWatch Logs に記録され、ログ記録レベルを完全に制御できます。 ワークフロー段階 – 高速ワークフローは、アクティビティタスクを除き、標準ワークフローと同じサービス統合の多くをサポートします。AWS Batch、AWS Glue、Amazon SageMaker などの長期実行サービスを開始できます。とても待ち遠しいことでしょう。 期間 – 高速ワークフローは、実際の経過時間で最大 5 分間実行できます。他の高速ワークフローまたは標準ワークフローを呼び出すことはできますが、とても待ちきれないでしょう。また、標準ワークフローから高速ワークフローを呼び出して、アプリケーションのニーズを満たすために両方のタイプを構成することもできます。 イベント料金 – 高速ワークフローは、1 秒あたり 100,000 […]

Amazon Athena は、標準 SQL を使用して Amazon S3 のデータを簡単に分析できるインタラクティブなクエリサービスです。Athena はサーバーレスであるため、インフラストラクチャの管理は不要であり、実行したクエリにのみ課金されます。この投稿では、現在プレビュー中である2つの新しい機能、Apache Hive Metastore への接続と、ユーザー定義関数の使用について詳しく説明しています。これらは本日から使い始めることができます。 Athena を自分の Apache Hive Metastore に接続する Hive Metastore を、自分のビッグデータ環境に共通のメタデータカタログとして使っているお客様が複数いらっしゃいます。このようなお客様は、Amazon EC2 や Amazon EMR クラスター上で Apache Spark、Presto、Apache Hive を実行していて、共通カタログとして Hive Metastore を自身でホストしています。またAWS は、完全に管理されたカタログで、 Hive メタストアをドロップインで置き換える AWS Glue Data Catalog も提供しています。この記事がリリースされた時点で、Athena の Data Catalog に加えて Hive メタストアも利用できます。Athena によって、既存の Data Catalog に加えて複数の Hive メタストアに接続できます。 ご自身でホストしている Hive […]

Amazonのお客様は、私たちがビジネスをどのように構築し、運営しているかについてもっと知りたいとよく言っています。小売業では、Amazon Fulfillment Centerを視察し、倉庫の整理方法を確認します。法人のお客様は、しばしば当社のリーダーシップ原則について質問し、時には彼ら自身の使用のためにそれらを採用します（そしてそれから適応させます）。私は定期的に彼らを私たちのエグゼクティブ・ブリーフィング・センター（EBC）にお迎えし、長期的な成功の一環として失敗を受け入れる、考え方や、私たちの技術革新の軽いチャーなどについて話をしています。 私たちのビジネスを取り巻く同じ好奇心が開発文化を取り囲んでいます。Amazon.com、AWS、その他のビジネスの根底にあるハードウェアおよびソフトウェアシステムをどのように設計、構築、測定、実行、スケーリングするかをよく聞かれます。 新しいビルダーズライブラリー 今日、Amazon Builders’ Libraryを発表できてうれしいです。システムの構築および実行方法を正確に説明する詳細な記事のコレクションを開始します。各記事は、ビジネスのその部分で深い専門知識を持つシニアテクニカルリーダーによって書かれています。 このライブラリは、私たちの仕事の根底にある理論と実践に直接アクセスできるように設計されています。学生、開発者、開発マネージャー、アーキテクト、およびCTOはすべて、このコンテンツが役立つと感じるでしょう。これは、「店舗で販売されていない」学校で教えられていないコンテンツです！ ライブラリはカテゴリ別に整理されています。 アーキテクチャ –セキュリティ、耐久性、高可用性、パフォーマンスの最適化を支援するクラウドサービスを設計する際に行う設計上の決定。 Software Delivery＆Operations –新しいソフトウェアをクラウドにリリースし、その後ヘルスと高可用性を維持するプロセス。 ライブラリ内で、この投稿を書いている間に2つの記事を簡単に見て、多くのことを学びました！ 乗り越えられないキューバックログの回避 –プリンシパルエンジニアのDavid Yanacekは、メッセージキューの内外を調査し、発生する可能性のある障害モードの多くを含む利点とリスクを調査します。彼は、キューを使用してAWS LambdaとAWS IoT Coreを強化する方法について説明し、レスポンシブを維持し、「言葉で言えば」「魔法のリソースの分離」を実装するために使用される高度な戦略について説明します。Davidは、複数のキューの使用、シャッフルシャーディング、遅延キュー、バックプレッシャーなどを含む、復元力のある非同期マルチテナントシステムについても解説しています。 分散システムの課題 –シニアプリンシパルエンジニアのJacob Gabrielson は、分散システムが失敗する多くの方法について説明します。3つの異なるタイプ（オフライン、ソフトリアルタイム、およびハードリアルタイム）のシステムを定義した後、彼はBizarroとの類推を使用して、なぜハードリアルタイムシステムが（再び、彼の言葉で）「率直に言って」パックマンに基づいた例を使い、要求/応答通信を追加し、成功または失敗する可能性のあるすべての方法を列挙します。彼は、テストケースの数を減らす方法について議論し、分散システムのテストに伴う他の多くの問題についても話しました。 これらは2つの記事にすぎません。コレクション全体をチェックアウトしてください。 Welcome 私たちは、より多くのコンテンツを持っています。そして我々はまた、あなたの話に興味を持っています。この投稿に関するフィードバックをお気軽にお寄せください。ご連絡いたします。 – Jeff;

AWS より、Amazon SageMaker Operators for Kubernetes をご紹介いたします。この新機能を使用すると、開発者およびデータサイエンティストは、Amazon SageMaker における 機械学習 (ML) モデルのトレーニング、チューニング、デプロイを、Kubernetes を介して簡単に行うことができます。Kubernetes クラスターに Amazon SageMaker Operators をインストールすると、Kubernetes API や “kubectl” といったコマンドラインの Kubernetes ツールをネイティブに使用して Amazon SageMaker ジョブを作成することが可能です。 多くの AWS のお客様が、Amazon Elastic Kubernetes Service (EKS) といったマネージドサービスがよく使用されるコンテナ化アプリケーションをデプロイおよび管理するために、オープンソースの汎用コンテナオーケストレーションシステムである Kubernetes を使用しています。これにより、データサイエンティストおよび開発者は、反復可能な ML パイプラインのセットアップ、トレーニングや推論のワークロードに対する制御能力の向上などが可能です。しかし ML ワークロードをサポートするには、カスタムコードの記述による基盤となる ML インフラストラクチャの最適化、高可用性と高信頼性の確保、データサイエンスに対する生産性向上ツールの提供、しかるべきセキュリティ要件および規制要件への準拠が依然必要です。例えば、Kubernetes ユーザーがトレーニングや推論に GPU を使用する際、Kubernetes による GPU ワークロードのスケジューリングとスケーリングの設定を変更して、使用率、スループット、可用性を向上させる必要が出てくるケースが多々あります。また、Kubernetes ユーザーはトレーニング済みモデルを本番環境にデプロイして推論を実行する際に、複数のアベイラビリティーゾーンに存在する Auto Scaling クラスターのセットアップおよび最適化に余計な時間を取られてしまいます。 Amazon SageMaker […]

開発者がアプリケーションに医療音声テキスト変換機能を追加できるようにする新しい HIPAA 適格の機械学習自動音声認識 (ASR) サービスである Amazon Transcribe Medical を発表いたします。Transcribe Medical は、正確で手頃な価格の医療向け文字起こしを提供し、医療従事者、IT ベンダー、保険会社、製薬会社が、医師、看護師、研究者、請求代理人が医療記録の効率を改善するのを支援するサービスを構築できるようにします。この新しいサービスを使用すると、臨床医のオフィス、研究室、保険請求代理人との電話などで、より少ない労力で、より速く、より正確に、安全に臨床文書を完成させることができます。 ヘルスケアやライフサイエンスでの課題 HITECH (経済的および臨床的健全性のための医療情報技術) 法の実施に従って、医師は電子健康記録 (EHR) システムへの詳細なデータ入力を行う必要があります。ただし、臨床医は、EHR データ入力のメモを書くだけで、既存の医療業務に加えて、平均で 1 日 6 時間の追加勤務となることもあります。このプロセスは医師にとって時間と労力がかかるだけでなく、職場での燃え尽き症候群やストレスの主な要因であり、医師が患者を注意深く診察することを妨げ、結果として患者のケアが不十分になり、来院が急増します。手書きのメモ作成を支援するために医療書記が採用されていますが、このソリューションは高価であり、数千の医療施設に拡張するのが難しく、一部の患者は医療書記の存在を不快に感じ、症状に関する率直な議論につながりません。また、既存のフロントエンド口述ソフトウェアでは、破壊的で非効率的な句読点を明示的に発声するなど、医師がトレーニングを受けるか不自然に話す必要があります。さらに、メモを取ることの負担を軽減するために、多くの医療事業者が医師の音声メモを手動転写サービスに送っていますが、これは 1〜3 営業日かかる場合があります。 加えて、ライフサイエンス業界が精密医療に移行するにつれて、製薬会社は医薬品の有効性や潜在的な副作用を引き起こす可能性に関してリアルワールドエビデンス (RWE) を収集する必要性が高まっています。ただし、RWE は電話での会話に取得されることが多く、その場合は文字起こしする必要があります。 Transcribe Medical は、正確で手頃な価格の使いやすい医療用音声認識サービスを実現することにより、こうした課題に対処するのに役立ちます。 機械学習による医療用文字起こしの改善 Transcribe Medical は、あらゆる音声対応アプリケーションに統合できて、マイクを備えたほぼすべてのデバイスで動作する使いやすいストリーミング API を提供します。このサービスは、プライマリケアのための医療音声を文字起こしするように設計されており、数千の医療提供者に大規模にデプロイして、臨床スタッフと施設に手頃な価格で一貫性のある安全で正確なメモを取る機能を提供できます。自動句読点やインテリジェントな句読点などの追加機能を使用すると、「カンマを追加」や「感嘆符」など、議論の一部として厄介で明示的な句読点コマンドを発声することなく、自然に話すことができます。 さらに、このサービスは、医療用口述筆記と会話文字起こしの両方をサポートしています。 Transcribe Medical は完全マネージド型 ASR サービスであるため、サーバーのプロビジョニングや管理は必要ありません。パブリック API を呼び出して、安全な WebSocket 接続を使ってサービスに音声ストリームを渡すだけです。Transcribe Medical は、テキストストリームをリアルタイムで送り返します。Transcribe Medical を使用するために機械学習の経験は必要ありませんし、このサービスは AWS のHIPAA 適格および BAA […]

本日、世界初の機械学習対応のミュージカルキーボードである AWS DeepComposer を発表します。読み間違えではありません。 機械学習 (ML) には、数学、コンピューターサイエンス、コード、およびインフラストラクチャの知識がかなり必要です。これは非常に重要なことですが、意欲的な ML 開発者の多くは圧倒され、時には (あえて言うと) 退屈に感じさえするでしょう。 誰もが実用的な ML について学び、それを楽しんでいただけるように、ML を搭載したデバイスをいくつか導入しました。AWS re:Invent 2017 では、世界初の深層学習対応カメラである AWS DeepLens を導入し、開発者がコンピュータービジョンの ML について学習できるようにしました。昨年は、AWS DeepRacer を発売しました。これは強化学習によって駆動する完全に自立型の 1/18 スケールのレーシングカーです。今年、当社はそのバー (水準) をババッと引き上げます (駄洒落をお許しください)。 AWS DeepComposer の紹介 AWS DeepComposer は、開発者が事前トレーニング済みのモデルまたは独自のモデルで Generative AI を使用できるように設計された 32 キー、2 オクターブのキーボードです。 デバイスが入手できるようになったときに E メールを受信するリクエストを行うことも、AWS コンソールで仮想キーボードを使うこともできます。 以下はその詳細な説明です。 DeepComposer コンソールにログインし、 短い曲を録音するか、あらかじめ録音された曲を使用し、 お気に入りのジャンルの生成モデルを選択し (事前トレーニング済みまたは独自のもの)、 このモデルを使用して、新しいポリフォニックコンポジションを生成し、 コンソールでコンポジションを再生し、 コンポジションをエクスポートするか、SoundCloud […]

お客様は、Microsoft Windows Server および SQL Server の既存のライセンスを AWS に持ち込み、管理するための簡単な方法を提供するように求めています。本日、新しい、よりシンプルな、Bring-Your-Own-License (BYOL) エクスペリエンスを発表できることを嬉しく思います。 Windows Server または SQL Server インスタンスを起動するとき、お客様は従量課金モデルで AWS のライセンスを使用するか、既存の独自のライセンスを持ち込むことができます。AWS から取得したソフトウェアライセンスを使用する場合、お客様は複雑なライセンス契約条件を管理する必要のない、完全準拠の従量課金ライセンスモデルを取得します。本日発表された新しい BYOL エクスペリエンスにより、既存の Windows Server または SQL Server ライセンスを使用したいお客様は、EC2 で仮想マシンをシームレスに作成できます。その一方で、AWS はライセンスを管理し、お客様が指定したライセンスルールに確実に準拠するのをサポートします。 以前は、独自のサーバーごとのライセンスを持参する場合、キャパシティーを管理し、BYOL に必要な専用ホストを効果的に使用するために、追加の自動化を記述する必要がありました。このプロセスにより、ホストの管理があたかも EC2ではないようになり、AWS が提供するライセンスを使用する際の、シンプルで使いやすいエクスペリエンスとはまったく異なっていました。新しい BYOL エクスペリエンスは、ホストの割り当てやリリースなどの主要なホスト管理タスクを自動化し、ホストキャパシティーを管理し、ホストの Auto Scaling や自動リカバリなどの機能を有効にすることで、お客様のホスト管理エクスペリエンスをシンプルにします。その結果、他の EC2 インスタンスを作成するのと同じ方法で、専用ホスト上に BYOL インスタンスを簡単に作成できます。 ライセンスされたイメージを AWS クラウドに持ち込むための、新しくシンプルになったエクスペリエンスを見ていきましょう。この記事では、Windows Server ライセンスを使用しますが、Windows Server と SQL Server のライセンスを持ち込む場合も同じです。 ライセンス管理のセットアップ ライセンス画像をインポートして、Amazon […]

2017 年、Amazon Transcribe がローンチされました。これは、開発者がアプリケーションに Speech-to-Text 機能を簡単に追加できるようにする自動音声認識サービスです。今日、Amazon Transcribe Medical で医療音声に拡張できることを非常に嬉しく思います。 私が子供の頃、両親は両方とも医師でしたが、秘書が後でタイプしてアーカイブできるように、夜はよくマイクロカセットレコーダーを使って手紙や試験報告書を記録していました。それはかなり前のことでしたが、ウィスコンシン大学とアメリカ医師会による 2017 年の調査によると、米国のプライマリケア医は 1 日 6 時間を電子医療記録 (EHR) システムの医療レポートへの入力に費やしているということです。EHR は現在、医療従事者の標準要件となています。 医師に紙のレポートに戻るべきだと主張する人は誰もいないと思います。デジタルデータを扱う方がはるかに効率的です。それでも、長時間かかるこれらの管理業務を軽減することはできるでしょうか? 浮いた時間を、患者を診たり、病院で多忙な一日を過ごした後の休憩に余分に当てたりした方がいいことに疑いはありません。 Amazon Transcribe Medical の紹介 Amazon Transcribe Medical のおかげで、医師は人間の介入なしに、臨床メモを簡単かつ迅速に口述し、音声を正確なテキストにリアルタイムで変換できるようになりました。臨床医は自然に話すことができ、「点」や「丸」といった句読点を明示的に発声する必要はありません。このテキストは、EHR システムなどのダウンストリームアプリケーション、またはエンティティ抽出のために などの AWS 言語サービスに自動的に送信できます。 完全マネージドサービスの精神で、Transcribe Medical はインフラストラクチャの作業から解放され、実際に使用した分だけ支払うだけで簡単にスケーリングできます。高価なライセンスの初期費用は発生しません! ご想像のとおり、Transcribe Medical も HIPAA に準拠しています。 技術的な観点からは、操作はデバイスのマイクを使用して音声をキャプチャし、一般的な Websocket プロトコルに基づいて PCM 音声をストリーミング API に送信することだけです。この API は、書き起こされたテキスト、および文字レベルのタイムスタンプと句読点などとともに、一連の JSON ブロブで応答します。オプションで、このデータを Amazon Simple Storage […]

今日最も多く使用されている機械学習モデルには 2 つあります。自然言語処理 (NLP) 用の BERT と、画像認識用の Mask R-CNN です。AWS では、この数か月にわたり、これら 2 つの良く使われている先進的なモデルにおいて最短のトレーニング時間を達成するため、基盤となるインフラストラクチャ、ネットワーク、機械学習 (ML) フレームワーク、モデルコーディングなどに、大幅な改良を加えてきました。TensorFlow、MXNet、PyTorch に関しクラウド上でこれまで記録された最短のトレーニング時間を、本日、皆様と共有できることを、心から喜んでおります。お客様は、ご自身の TensorFlow、MXNet、PyTorch のモデルでのトレーニングに、これらのハードウェアとソフトウェアに関する最適化手法を、当社と同じ効率とスピードでご利用になれます。 モデルに対するトレーニング時間は、そのモデルの精度への改良を、素早く繰り返すときの作業性に直接影響します。トレーニング時間を削減しようとするときに最初に考えられる手法とは、GPU インスタンスの大規模なクラスターを通じて、トレイニングジョブを供給するということです。しかしこれでは、効率を高めることは困難です。大量のワーカーを通じてトレーニングジョブを供給しても、しばしば、急速にその効果が薄れてしまうことがあります。インスタンス間の通信におけるオーバーヘッドが、GPU を追加した分のコンピューティングパワーを帳消しにしてしまうからです。 BERT 現在、普及している NLP モデルである BERT、つまり Bidirectional Encoder Representations from Transformers は、当初は、いくつかの一般的な NLP タスクを処理するための最新手法として公開されたものです。 NVIDIA V100 GPU を 8 個使用する単一の Amazon EC2 P3dn.24xlarge インスタンスにおいて、TensorFlow と PyTorch を使いながらこの BERT をゼロからトレーニングするには、およそ 3 日間を要します。当社では、Elastic Fabric Adapter (EFA)を使用しつつ、このモデルを大規模クラスター上で集中させる方法を最適化しながら、P3dn.24xlarge インスタンスへの効率的なスケールアウトを実行し、3 […]

本日より、皆さんは、Amazon Elastic Kubernetes Service を使用して、AWS Fargate の上でKubernetes ポッドを利用できます。Amazon EKS と Fargate は、AWS 上での Kubernetes ベースのアプリケーションの実行をわかりやすいものにします。ポッドを用意して、そのインフラストラクチャを管理する必要がなくなるからです。 AWS Fargate では、コスト最適化され、可用性の高いクラスターを稼働するのに、Kubernetes 運用の専門的な知識は必要ありません。Fargate は、お客様が Amazon EKS クラスターのためにEC2 インスタンスを作成し、管理する必要をなくします。 もはや、クラウド上で Kubernetes アプリケーションを実行するため、EC2 インスタンスのクラスターのパッチング、スケーリング、セキュア化の問題で頭を悩ませる必要はなくなります。Fargate を使えば、リソースを定義し、ポッドレベルでその支払いを行えます。これにより、アプリケーションごとに適切なサイズのリソースを利用することが容易になり、ポッドごとのコストを明確に知ることができます。 このブログの後半では、新しい機能を試してみて、Amazon EKS を Fargate 上で使用し、シンプルな Kubernetes ベースのアプリケーションをデプロイしてみましょう。 クラスターを構築する クラスタのセットアップを行う最も簡単な方法は、EKS の正式な CLI ツールである eksctl を使用することです。以下のコマンドは、ワーカーノードのない、demo-newsblog というクラスターを作成します。 eksctl create cluster –name demo-newsblog –region eu-west-1 –fargate この 1 行のコマンドは、実に多くのことを行います。クラスターを作成するばかりでなく様々な事柄を行いますが、とりわけ、Fargate […]