Amazon Web Services ブログ

【登壇報告】Virtual NAB 2020セミナー

毎年 4 月に開催される 全米放送協会 NAB (National Association of Broadcasters) が主催する世界最大の放送機器展 NAB Show ですが、今年は COVID-19 感染拡大の影響を鑑み Las Vegas での開催は中止、いくつかのデジタルイベントを実施することになりました。AWS は NAB Show で公開する準備を進めていた内容を下記のオンラインセミナーで紹介させていただきました。 4/21 (火)に US では AWS 主催のイベント「AWS NAB News & Update」を開催しました。 動画は こちら 資料は こちら です。 日本でも 4/22 (水)に伊藤忠ケーブルシステム様のバーチャルイベント「Virtual NAB 2020 セミナー」において、「NAB 出展概要とテクノロジーハイライト」というタイトルで、ソリューションアーキテクトの小林が登壇させていただきました。それらの内容について Blog で報告させていただきます。 Virtual NAB 当日の資料は こちら です アジェンダ: 1. AWS はメディアのための場所 […]

Read More

AWS 認定試験の作成

2019 年 9 月現在、AWS 認定の取得者は 24 万人を超えました。すでに認定を取得された方の中には、AWS 認定試験とその設問がどのように作られているか疑問に思ったことがある方もいらっしゃるかもしれません。今回は AWS の AWS 認定テクニカルアーキテクトの 1 人として、試験開発プロセスの裏側をご紹介したいと思います。 驚かれるかもしれませんが、AWS 認定チームの誰一人として試験問題を作っている人間はいません。また、どのような設問を出題するかを決めることさえありません。これらは AWS の従業員と AWS の製品やサービスの使用経験を持つ顧客などで構成される AWS 内容領域専門家 (Subject Matter Experts: SME) たちのボランティアにより行われています。SME は自身の時間を割いて試験内容や設問の作成とレビューを行い、特定の役割や技術分野におけるコンピテンシーレベルの設定を支援してくれています。ソリューションアーキテクト、開発者、システムオペレーター、データベース管理者や、それぞれの認定試験に関する分野に合致した専門知識を有するその他の方々に支えられています。 現在提供している 12 の AWS 認定は、AWS のサービスを使用する個人の職務や技術的な専門知識を広範囲にカバーしています。そのため、新しい AWS 認定試験の作成は、対応する分野の職務経験がある SME を探すところからはじまります。 AWS 認定データベース – 専門知識認定の新設にあたっては、DynamoDB、RDS、Aurora、Neptune、Quantum Ledger の使用経験があるデータベースエンジニアやプログラマーを募集しました。年単位で長期にわたって関わる SME チームには、顧客、パートナー、AWS の従業員が混在し、関連性を保ちつつ多様な経験が認定に反映されるようにしました。   試験開発プロセス AWS では、の堅牢なプロセスに従って試験開発を行っています(以下を参照)。このプロセスのさまざまなステップの一部は、SME の参加によって支えられています。 ジョブタスク分析 (JTA) JTA […]

Read More

AWSのコストを削減する9の方法 第二回

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン シニアエバンジェリストの亀田です。 前回こちらのブログ記事でAWSのコストを削減する方法をお届けしました。今回は第2回としてその4からその6までをお届けします。 #1 未使用状態のAmazon EC2やAmazon RDS インスタンスへの支払いを止める #2 未使用状態の Amazon Redshift クラスターへの支払いを止める #3 Amazon S3 Intelligent-Tieringを有効にする #4 Amazon DynamoDB にはオンデマンドのキャパシティーモードを利用する #5 十分に活用されていないEC2 インスタンスへの支払いを止める #6 十分に活用されていないネットワークリソースを削除する #7 EC2 スポットインスタンス を利用する #8 Compute Savings Plans を利用する #9 リザーブドインスタンスを利用する #4 Amazon DynamoDB には オンデマンドのキャパシティーモードを使う DynamoDBのキャパシティーモードが「プロビジョンド」であり、アプリケーショントラフィックの予測と制御が困難な場合や、ワークロードが短時間に急増したりテーブルの平均使用率がピークをかなり下回っている場合においては、使用していないキャパシティーに対して、不必要に支払いが発生している可能性があります。キャパシティーモードが「オンデマンド」の場合は、DynamoDB の柔軟な請求オプションで、キャパシティーのプランニングを実施することなく毎秒数千件のリクエストを処理できます。アプリケーションがテーブルに対して実行するデータの読み書きについて、リクエストごとに料金が発生します。 DynamoDB がワークロードの増減に即時に対応するため、アプリケーションの実行により予想される読み込みと書き込みのスループットを指定する必要はありません。DynamoDB の使用量が増加され続けているのであれば、オンデマンドのキャパシティを設定することをお勧めします。実装には数分かかります。 コスト削減額はアプリケーションがDynamoDBのテーブルで実行する読み取りと書き込みの数によって異なります。未使用のテーブルやワークロードの予測が困難な場合においてコスト削減額を試算するためには、短期間においてオンデマンドのキャパシティーモードに切り替え、プロビジョンドとコストを比較することをお勧めします。テーブルがオンデマンドのキャパシティーで構成されると即座にコスト削減が開始されます。プロビジョンドとオンデマンドのキャパシティーモードは24 時間に 1 回切り替えることができます。 開始するには、既存の DynamoDB テーブルまたは新しいテーブルに対してオンデマンドのキャパシティーモードを設定できます。 #5 十分に活用されていないEC2インスタンスへの支払いを止める メモリを大量に消費しないワークロードをEC2インスタンス上で実行をしていて、 CPU使用率が 40% 未満の場合、過剰にプロビジョニングされたインスタンスに対して料金を支払っている可能性があります。Cost Explorerのリソース最適化の推奨事項を使用することで、過剰にプロビジョニングされた […]

Read More

cqlsh を使用して Amazon MCS にデータをロードする

Cassandra Query Language Shell (cqlsh) は、CQL コマンドの実行や、テーブルの作成や変更などのデータベース管理タスクの実行に使用できるオープンソースのコマンドラインシェルです。cqlsh を使用して、CSV ファイルから Amazon MCS テーブルにデータをロードすることにより、Cassandra と互換性があり、スケーラブルで可用性の高いマネージド型データベースである Amazon Managed Apache Cassandra Service (MCS) の使用を開始できます。詳細については、Amazon Managed Apache Cassandra Service とは何ですか? を参照してください。 この投稿では、cqlsh COPY コマンドを使用することによって、cqlsh を使用し、Amazon MCS テーブルにデータをロードする方法について説明します。また、データを準備するためのベストプラクティスと、COPY コマンドのパラメータを使用してデータ転送のパフォーマンスを調整する方法についても説明します。最後に、この投稿では、Amazon MCS テーブルの読み取り/書き込みスループット設定を構成して、データロードプロセスを最適化する方法について説明します。 前提条件 開始する前に、Amazon MCS キースペースおよびテーブル用の AWS アカウントが必要です。プログラムによって接続し、cqlsh を正しくセットアップしていることを確認してください。手順については、プログラムによる Amazon Managed Apache Cassandra Service への接続を参照してください。 この投稿のサンプルを実行するには、データを含む CSV ファイルが必要です。この投稿では、その CSV ファイルを export_keyspace_table.csv と呼んでいますが、別の名前に置き換えることができます。CSV […]

Read More

PyTorch のオープンソースモデルサーバー、TorchServe を発表

PyTorch は、ディープラーニングで最も人気のあるオープンソースライブラリの 1 つです。開発者と研究者は、モデルの構築とトレーニングにおいて享受できる柔軟性を特に重宝しています。しかし、これはストーリーの半分にすぎず、本番環境でのモデルのデプロイと管理は、機械学習プロセスの最も困難な部分であることが多々あります。オーダーメイドの予測 API の構築、それらのスケーリング、保護などがその厄介な部分です。 モデルのデプロイプロセスを簡略化する 1 つの方法は、モデルサーバー、つまり、本番環境で機械学習予測を行うために特別に設計された既製のウェブアプリケーションを使用することです。モデルサーバーを使用すると、1 つまたは複数のモデルを簡単に読み込むことができ、スケーラブルなウェブサーバーに基づく予測 API が自動的に作成されます。また、予測リクエストに対して前処理と後処理のコードを実行することもできます。最後に忘れてならないのが、モデルサーバーは、ログ記録、モニタリング、セキュリティなどの生産に不可欠な機能も提供している点です。一般的なモデルサーバーには、TensorFlow Serving と Multi Model Server があります。 今日、TorchServe を発表できることをとても嬉しく思います。これは、カスタムコードを記述することなく、トレーニングされた PyTorch モデルを大規模かつ簡単にデプロイできる PyTorch のモデルサービングライブラリです。 TorchServe のご紹介 TorchServe は AWS と Facebook 間のコラボレーションであり、PyTorch オープンソースプロジェクトの一部として利用できます。プロジェクトの開始方法に興味がある場合は、Github で初期の RFC を読むことができます。 TorchServe を使用すると、PyTorch ユーザーは、カスタムコードを記述することなく、モデルをより迅速に本番環境に導入できるようになります。低レイテンシーの予測 API の提供に加えて、TorchServe は、オブジェクト検出やテキスト分類などの最も一般的なアプリケーションのデフォルトハンドラーも埋め込んでいます。さらに、TorchServe には、アプリケーション統合のためのマルチモデルの提供、A/B テストのモデルバージョン管理、モニタリング指標、RESTful エンドポイントが含まれます。ご想像のとおり、TorchServe は、Amazon SageMaker、コンテナサービス、Amazon Elastic Compute Cloud (EC2) などの機械学習環境をサポートしています。 一部のお客様はすでに TorchServe のメリットを享受しています。 […]

Read More

Amazon Redshift で列レベルのアクセス制御を行い、よりきめ細かなデータセキュリティを実現する

Amazon Redshift は低コストで迅速な分析情報を提供する、大変人気の高いクラウドデータウェアハウスです。Amazon Redshift にはすぐに利用できるセキュリティとコンプライアンスが付属しており、規制の厳しい業界のお客様でもミッションクリティカルなワークロードを自信を持って実行できます。セキュリティ機能には、データをインプレース形式およびオープン形式で簡単に分析できる機能が組み合わさっているだけでなく、コンピューティングとストレージの回復性や使いやすさも備えているため、数万人ものお客様に Amazon Redshift をご利用いただいています。 個人を特定できる情報 (PII) または機密性の高い個人情報 (SPI) として一般的に分類される機密データを、Amazon Redshift に保存している組織は多くあり、こうしたデータへ組織内の異なる人物からのアクセス制限を行っています。たとえば、人事、財務、販売、データサイエンス、マーケティングのどの部門も、顧客データを表示するために必要なアクセス権をすべて持っている場合もありますが、個人を特定できる情報 (PII) や支払カード業界 (PCI) などの機密データには財務部門しかアクセスできないようになっている必要があります。 以前は、ビューまたは AWS Lake Formation (Amazon Redshift Spectrum にある) を使ってそのようなシナリオを管理していましたが、ビューや Amazon Redshift Spectrum の作成や管理には余分なオーバーヘッドがかかります。ビューベースのアプローチは拡張が難しく、セキュリティ管理が手薄となる可能性があります。Amazon Redshift の列レベルのアクセス制御は、Amazon Redshift のデータを列レベルでアクセス制御する新機能です。列レベルの GRANT ステートメントや REVOKE ステートメントを使用することで、データベースオブジェクトを管理するように、セキュリティとコンプライアンスのニーズを満たすことができます。 この投稿では、テーブル、ビュー、マテリアライズドビューで Amazon Redshift の列レベルのアクセス制御を設定する方法をご紹介します。 ユースケース こちらに、顧客の人口統計データと口座残高データを格納する 2 つのテーブルがあります。財務部門はすべての顧客データを表示できますが、顧客名、電話番号、国籍などの顧客の人口統計データは PII データと見なされ、アクセスを制限する必要があるため、営業部門は市場セグメントと口座残高データのみを表示および更新できます。このユースケースは、PII データを保護するための列レベルのアクセス制御の良い例です。以下は、2 つのテーブルのシンプルなエンティティ関係図です。 前提条件 このブログにある図を試す前に、次の前提条件をご確認ください。 Amazon […]

Read More

AWS DMS を使用した移行からのロールバック

AWS Database Migration Service (DMS) を使用してデータベースを新しいシステムに移行する場合、新しいシステムが想定どおりに機能しない場合に備えてフォールバック戦略を立てることが賢明です。概要として、移行からロールバックするためには、4 つの基本的な戦略があります。すなわち、基本的なフォールバック、フォールフォワード、デュアル書き込み、双方向レプリケーションです。特定の状況に応じて、これらの戦略の 1 つまたは複数を用いることができる場合があります。 この投稿では、各戦略を定義し、その戦略が適切であると思われる状況の概要を説明します。一般的には、データベースシステムの整合性を維持しながら、最小限の労力とコストを必要とする戦略または戦略の組み合わせをデプロイすべきです。 基本的なフォールバック ソース A からターゲット B に移行する場合の最も簡単なフォールバック戦略は、アプリケーションを元のソース A に戻すことです。この戦略は、あまり生じないかもしれませんが、以下の状況では合理的です。 読み取り専用システムを移行していて、新しいターゲットが新しいトランザクションを取得していない。 システムは「バッチ」タイプのシステムであり、新しいターゲットにまだトランザクションを適用していない。 古いシステムにロールバックした後は、新しいシステムでトランザクションを使用する必要がいない。(一部のロギングシステムはこのパターンである場合があります。) ロールバックの前または後に、新しいシステムで使用されたトランザクションを元のシステムに再生成またはコピーすることができる。(ロギングシステムまたは挿入のみのシステムは、このパターンである場合があります。) 元のシステムにロールバックした後、新しいシステムにトランザクションを適用する必要はない。 カットオーバーの前に、DMS タスクはデータを A から B にレプリケートします。B に「フリップ」されるアプリケーションは、引き続き A とインタラクションします。次の図は、このアーキテクチャを示しています。 カットオーバー時にレプリケーションタスクが停止し、アプリケーションがフリップされて B とインタラクションします。次の図は、この変更を示しています。 ロールバックが必要な場合、アプリケーションはフリップされて A に戻ります。B のカットオーバー後に発生した変更は、無視され、または失われます。下図を参照してください。 デュアル書き込み 場合によっては、移行の一環として、デュアル書き込み戦略が使用されます。たとえば、データベース A をデータベース B に移行する場合の状況を考えてみます。デュアル書き込み戦略では、両方のデータベースにトランザクションを同時に書き込むことができるようにアプリケーションコードを変更します。デュアル書き込み戦略の採用は、アプリケーションへの (通常は重要な) 変更を伴うため、より複雑で時間のかかるフォールバックアプローチの 1 つです。ただし、ターゲットデータベース B への書き込みを停止するだけなので、デュアル書き込み構成からのフォールバックは簡単です。次の状況では、デュアル書き込み戦略が適切な場合があります。 データが (おそらく顧客ごとに) 分割されており、アプリケーションの移行に段階的なアプローチを採用している。このシナリオでは、DMS を使用して新しいターゲットをハイドレートし、ソースと同期させます。カットオーバーでは通常、デュアル書き込み機能を有効にし、DMS […]

Read More

AWS Storage ソリューションを使用した Discover でのデジタル変革

どのような組織でも直面する最大の課題の 1 つは、デジタル変革の概念に対する取組みです。組織やその従業員にとってそれが何を意味するのかを定義することさえ、困難な作業となり得ます。多くの組織にとって、その変革には、クラウドジャーニーと、他の新しい (またはやや新しい) テクノロジーの調査の開始が伴います。Discover で学んだことの 1 つは、ジャーニーの「デジタル」の部分にとらわれ過ぎて、「変革」の側面を見失ってしまわないようにしなければならないということです。最終的な目標は、テクノロジーそれ自体のために、新しいテクノロジーをもたらすことではありません。目標とするのは、顧客との約束をより効果的に実現する組織の能力を変革するテクノロジーです (顧客が社内か社外かにかかわらず)。 Discover のリーダーシップチームが分析とデータサイエンスの取り組みに注力し始めたことは、その顧客の約束を念頭に置いてのことでした。財務分野でビジネスを行うということは、長期にわたって、分析とデータサイエンスに極めて優れていなければならなかったということを意味します。私たちは何年にもわたって分析を活用して、詐欺の検出、意思決定、マーケティングなどに関する競争上の優位性を獲得してきました。その結果、これらすべての関連するビジネスユニットを中心に、個別の分析に関するプラクティスが生まれました。それらのほとんどすべてにおいて、要件、スキルレベル、好まれるツールはさまざまでした。Discover には最先端の研究を行う非常に才能のある人々がたくさんいます。リーダーシップチームの観点から見ると、これらの人々とチームをまとめることで、分析作業全体の改善が促進されることは当然のことのように思われました。技術的な観点からは、これらの人々とチームをまとめ上げる方法を見出すことには困難がありました。 このブログ投稿では、私たちが開発した Air9 と呼ばれるプラットフォームであるソリューションについて詳しく説明します。この困難を解決する際に、最初に合意した設計原則の 1 つは、多様性に強みがあるということでした。これには、チームとその経験の多様性だけでなく、さまざまなアプローチやツールも含まれます。この確立された分析コミュニティに、データサイエンスに対するフリーサイズのアプローチを持ち込むつもりはありませんでした。これにより、すべてのユーザー、ツール、およびデータを単一のプラットフォームに一元化するという単純な計画が導き出されました。これは、最終的に Air9 となるプラットフォームです。 このブログ投稿をさらに読み進める前に、同じコンテンツの多くをカバーする AWS re:Invent 2019 での Discover のプレゼンテーションのこの動画をチェックしてください。 適切なストレージソリューションを選択する Air9 プラットフォームの構築に向けたジャーニーでは、多くのデータサイエンスツールがコンテナ化に当然に用いられていたので、Kubernetes は自然に調和しました。専用のコンテナとポッドを備えることで、分離されたワークロードが可能になりました。この分離により、ユーザーはカスタムパッケージをインストールし、共有コンピューティングクラスターのようなマルチテナント環境で管理するのが難しい環境を調整できました。Amazon EC2 Auto Scaling を活用することで、需要に応じて、当社のコンピューティング機能を拡大および縮小することが可能になりました。 一元化されたデータサイエンスプラットフォームへのクリーンなアプローチのように見えたものは、ストレージレイヤーの設計を開始したときにすぐに問題に直面しました。当社の分析チームは、非常に大きなデータセットを持っています。データサイエンティストをご存知であれば、データウェアハウスに対して調査を行うのではなく、ローカルのデータセットの使用を非常に好むことをご存知でしょう。クラウドデータウェアハウスには大規模なデータセットがいくつかありましたが、データサイエンティストには個々の作業を行うためのローカルストレージが必要でした。また、チーム間 (およびチーム全体) でデータを共有するためのメカニズムも必要でした。このストレージレイヤーは、回復力があり、時間の経過に伴う大きな成長をサポートできる必要がありました。 Discover のテクノロジー組織は常に、新しいソリューションに対する「自分で構築できる」アプローチを好む傾向にあり、ビルダーとしてこれらの課題を楽しんでいます。チームは、データサイエンスプラットフォームのストレージレイヤーとして、オープンソースの分散ストレージソリューションの活用に乗り出しました。ビルドを好む傾向にある組織の重要な特徴の 1 つは、迅速に失敗し、アイデアを反復し、機能していないアイデアから次に進むタイミングを知る能力を有していることです。シャードキー、I/O パターン、成長予測、リカバリポイントの目標についての話し合いを余儀なくさせるいくつかの大きな頭痛の種を抱えつつ、社内の分散ストレージシステムに数週間を費やした後でも、大きく進捗しているようには見えませんでした。その間に、当社は、プラットフォームの初歩的な実装を提供し、ベータユーザーからかなりの量のデータがストレージソリューションに入力され始めました。この時点までのすべての課題を踏まえると、チームは、ソリューションが実現可能で持続可能であるかどうかについて不確かでした。最終的には、他の保管オプションを探すことを決定し、以下のコストチャートがとどめとなりました。 図 1: 請求に問題があります 通常、データサイエンスプラットフォームは、計算集約型の環境です。独自のストレージプラットフォームの運用に関連するコストがコンピューティングコストを超えるのを目にしたとき、何かがおかしいことがわかりました (図 1)。結局、過剰なコストは分散ストレージのレプリケーションファクターに起因するものでしたが、コストを削減する (レプリケーションファクターを削減する) トレードオフは、当社が満足できるものではありませんでした。 当社は、Amazon EC2 のスケーラビリティを活用してこのプラットフォームのコンピューティング側で成功を収めてきたので、ストレージ向けの AWS マネージドサービスを見直しました。Amazon […]

Read More

New – Amazon AppFlow のご紹介

Software as a service (SaaS) アプリケーションはお客様にとってますます重要になり、それを採用するお客様も急速に増えてきています。このソフトウェアの利用方法には多くの利点がありますが、1 つの課題は、データがさまざまな場所に点在していることです。データから有意義な洞察を得るには、それを分析する方法が必要ですが、データが複数のデータアイランドに分散している場合は困難な場合があります。 開発者は膨大な時間をかけてカスタム統合を行い、SaaS アプリケーションと AWS のサービスの間でデータを渡して分析できるようにしています。これには高額の費用がかかり、完了までに数か月を要する場合もあります。データ要件が変更されると、統合に複雑な変更を加える必要があり、費用もかかります。潤沢なエンジニアリングリソースがない企業は、アプリケーションからデータを手動でインポートおよびエクスポートすることになるかもしれません。これは時間がかかり、データ漏洩のリスクがあり、人為的ミスを招く可能性もあります。 本日、この問題を解決する Amazon AppFlow と呼ばれる新しいサービスを発表できることを嬉しく思います。Amazon AppFlow を使用すると、AWS のサービスと、Salesforce、Zendesk、ServiceNow などの SaaS アプリケーション間のデータフローを自動化できます。SaaS アプリケーション管理者、ビジネスアナリスト、および BI スペシャリストは、IT が統合プロジェクトを完了するのに数か月待つことなく、必要な統合のほとんどをすばやく実装できます。 SaaS アプリケーションから AWS のサービスへのデータフローを可能にするだけでなく、AWS のサービスから SaaS アプリケーションへのデータの送信も行えます。AWS ではセキュリティが最優先事項であるため、すべてのデータは転送時に暗号化されます。一部の SaaS アプリケーションは AWS PrivateLink と統合されています。これにより、セキュリティとプライバシーがさらに強化されます。AWS PrivateLink を使用して SaaS アプリケーションと AWS の間でデータの送受信が行われる場合、トラフィックはパブリックインターネットを使用せずに Amazon ネットワークに留まります。SaaS アプリケーションがサポートしている場合、Amazon AppFlow が自動的にこの接続を処理し、プライベートデータの転送を誰にとっても簡単にし、インターネットベースの攻撃による脅威と機密データ漏洩のリスクを最小限に抑えます。 データ転送をスケジュールに従って、ビジネスイベントに応じて、またはオンデマンドで実行するようにスケジュールできます。これにより、データの共有を迅速かつ柔軟に行うことができます。 この新しいサービスの力を示すために、簡単なフローの構築方法を示します。 筆者はイギリスとアイルランドでウェブコミュニティのオーガナイザー向けに Slack ワークスペースを運営しています。Slack は […]

Read More

TorchServe を使用した大規模な推論のための PyTorch モデルをデプロイする

今日ご紹介するサービスの多くは機械学習 (ML) を必要とするものです。オンライン検索や製品のレコメンデーションから音声認識や翻訳まで、これらのサービスには予測を提供するための ML モデルが必要です。ML がさらに多くのサービスで採用されるにつれて、苦労して結果を得て、モデルを迅速かつ確実に本番環境にデプロイすることが困難になります。そして、これらのサービスを利用する人の数が増えるにつれて、モデルが数百万のユーザーに同時に、そして、安全かつ確実に、低レイテンシーで予測を提供できるようにすることには、より大きな困難が伴います。 開発者は、モデル開発にさまざまなオープンソースフレームワークを使用します。ここ数年、PyTorch は、ML を利用したアプリケーションを開発する多くの研究者、開発者、およびデータサイエンティストが選択する深層学習のフレームワークとなっています。PyTorch は、そのシンプルさに加えて、Python 的な方法でモデルを実装およびトレーニングでき、Eager モードと Graph モードをシームレスに切り替える機能があることから好まれています。しかしながら、これまで、PyTorch モデルを本番環境で大規模に提供することについて、簡単かつネイティブにサポートされた方法はありませんでした。 AWS は、PyTorch のオープンソースモデルサービスライブラリである TorchServe の実験的リリースを共有できることを嬉しく思います。 AWS は、Facebook と連携して TorchServe を開発しました。AWS と Facebook は、より広範な PyTorch コミュニティと共に、TorchServe に注力し続けます。クラウドベースの PyTorch プロジェクトが 83% を超えて AWS で行われていることから、PyTorch モデルのデプロイの困難に対処するために TorchServe を立ち上げることができることを幸いに思います。TorchServe を使用すると、PyTorch モデルを TorchScript を使用して Eager モードまたは Graph モードでデプロイし、複数のモデルを同時に提供し、A/B テスト用に本番モデルをバージョン管理し、モデルを動的にロードおよびアンロードし、詳細なログとカスタマイズ可能なメトリクスを監視できます。 TorchServe は使いやすいです。ローカルにデプロイするのに便利な CLI が付属しており、コンテナにパッケージ化して Amazon SageMaker […]

Read More