Author: AWS Japan

2019年、多くの注目を集めたAWS DeepRacerリーグはre:Invent 2019でいよいよ最終章へ突入しました。 各地のAWS Summitやバーチャル リーグで勝ち抜いたレーサーたちがラスベガスに集結し、さらにre:Inventで開催される３つのレースで構成されたコンペティション[Championship Cup」で厳しい競争を勝ち抜いたのちに世界一が決まります。ファイナリストとしてクオリファイされたのは世界各国から64名。そのうち日本からは8名が参戦しています。 簡単に世界一になるまでの流れを説明します。 まず、世界一になるためにはre:Invent 2019の中で開催される3回のコンペティションで勝たなければなりません。さらに、使用するコースもこれまでと異なる形状のものとなり、難易度が各段に上がっています。 初戦は「The Qualifying 64 Group racing」 MGM Grand Arenaで6面のトラックを使って行われる初戦では、64名を4つのグループに分け最速タイムを競います。 一人4分の持ち時間のレースを4回行い、合計16分走ります。その中で最も速いラップタイムが記録となります。なぜ4回も？これには理由があります。限られた時間内で多数のレースを展開するには複数トラックが必要になりますが、物理的なトラックにはそれぞれ微妙な「くせ」があります。ほんの少し傾斜していたり、Wifiの状態が異なっていたり、条件は全く同一というわけにはいきません。より公平な評価が可能なレース環境とするためこのような形がとられているのです。 そして、各グループの上位4位、16名が次のステージに進みます。 2戦目は「Bracket of 16 racing」 これまでのレースはシンプルに全参加者でタイムを競う形式をとっていましたが、このBracket of 16 racingでは、「対戦相手」のいるトーナメント形式をとります。ぶっちぎりの速さでなくてもよく、ただ対戦相手より0.01秒でも速ければ勝ちです。 トーナメントで3回勝てば決勝戦へと進むことができます。決勝に進むのは3名です。 そして最後の決戦となる「The final 3 showdown」 re:Invent Day4のKeynote直前に開催されるこのレースは、会場をVenetianに移して行われます。 このレースはWerner Vogelsのキーノートの直前に実施され、結果はKeynote内で発表されます。まさにこの1年の戦いの最終決戦にふさわしい大舞台が用意されたと言えるでしょう。これまでのレースと異なり、一人当たりの持ち時間はたったの90秒。この短い時間の中で有効ラップであり、なおかつ速いタイムが求められます。 そして12月3日、初戦の「The Qualifying 64 Group racing」が行われ、 日本から参加された3名の方がみごと「Bracket of 16 racing」に進出されました！ ・グループB：Sola@DNP こと 瀧下 初香さん (9.056秒 グループ1位） ・グループC：nero-DNPds こと相場 武友さん（9.955秒　グループ4位） ・グループD：Fumiaki […]

本日、AWS ECS Cluster Auto Scalingを発表します。この機能は、スケールアウトを高速化し信頼性を向上させる、クラスター内の空きキャパシティ管理の提供と、スケールイン時に終了されるインスタンスの自動管理を提供し、クラスターの自動スケーリングをより使いやすいものにします。 ECS Cluster Auto Scalingを有効にするには、Capacity Providerと呼ばれる新たな項目を設定する必要があります。1つのCapacity Providerは1つのEC2 Auto Scaling Groupに関連づきます。あるAuto Scaling GroupにECS Capacity Providerを関連付け、ECSクラスターにCapacity Providerを追加すると、ECSの次の2つの新機能を用いてクラスターを自動スケールできるようになります。 管理されたスケーリング。Capacity Provider Reservationという新しいメトリックに対応するスケーリングポリシーが自動的に生成され、Auto Scaling Groupにアタッチされます。 管理されたインスタンス保護。スケールイン時にコンテナーからインスタンス終了を把握できるようになります。 これらの新機能により、ECSクラスターのスケールイン・スケールアウト時の制御が可能になります。 Capacity Provier Reservation Capacity Provider Reservationと呼ばれる新しいメトリックを導入します。クラスター内のすべてのECSワークロード、つまり既存のもの、新規のもの、変更になるもの、これらすべてが必要とする、クラスターリソースの割合(パーセンテージ)が計測されます。このメトリックはCPUやメモリ使用率を用いるよりも確度の高い、素早いスケールアウトを実現するために用いられ、またクラスター内の空きキャパシティを把握することもできるようになります。また、インスタンスを新規起動せず追加のコンテナーを素早く起動できるか、といった判断も可能になります。 管理されたインスタンス保護 インスタンス保護機能により、スケールインに際してどのインスタンスを削除できるかをECSに知らせることができます。これにより稼働中のコンテナーの中断を最小限に抑えられるようになります。運用コストの最適化、またECSで稼働するコンテナーワークロードの可用性向上に役立つ機能です。 ユーザーの利点 これまで、自動スケールするコンテナーワークロードを運用していたユーザーは、多くの場合、メトリックベースのスケーリングを使っていました。メトリックの例にはCPU使用率やメモリ使用率といったものがあり、この変化に基づいてクラスターインスタンスを追加、あるいは削除するべきかを判断するスケーリングポリシーを定義していました。 単一のワークロード、もしくは穏やかに負荷が上昇するワークロード群であれば、この方式でもうまくいく場合が多かったと考えます。しかし同一クラスター上で複数種類のワークロードを稼働させるケース、また急激な負荷上昇が見込まれるワークロードに対しては、スケーリングの問題が頻発していました。理想的には、その時点のクラスターサイズで収容しきれないようなワークロードの増加に対しては、クラスターサイズをスケールアウトさせるようなスケーリングポリシーが必要です。 既存のメトリクスがコンテナー全体を対象にしたものではなく、またその時点で使用中のリソースのみを表現するものである以上、スケールアウトが緩慢に、また不安定になってしまうことは避けられませんでした。加えて、クラスター内のどこでコンテナが稼働しているのかをスケーリングポリシーが把握できないため、スケールインに際して不用意にコンテナーを終了させてしまう場合もありました。この問題はコンテナーワークロードの可用性を低下させる要因になっていました。コンテナーインスタンスの追加台数の準備、追加のスクリプト開発、あるいは手動運用などでの回避は、すべて運用コストの増大を招いていたと言えます。 スケールしてみよう！ この機能をよく理解するには手を動かしてみるのが一番だと思います。 Amazon ECS Cluster Auto Scalingは、マネジメントコンソール、AWS CLI, Amazon ECS APIのいずれからも操作可能です。この例ではAWS CLIを用い、ターミナルからクラスターを作成する流れを見ていきます。 まず2つのファイルを作成します。ひとつ目はdemo-launchconfig.jsonで、EC2 Auto Scaling Groupに起動するAmazon Elastic […]

こちらはAWS Professional Service の IoT Global Specialty Practice に所属するシニアデータアーキテクト Asim Kumar Sasmal、IoT SiteWiseのシニアプロダクトマネージャーSaras Kaulによる投稿になります。 [この投稿を読む前に、シリーズのパート1とパート2を読んでください。] このシリーズのパート1で、AWS IoT SiteWiseを使用して、安全で費用対効果の高い信頼できる方法で産業アセットをモデル化し、産業現場からデータを取り込む方法を学びました。 このシリーズのパート2では、AWS IoT SiteWiseの新機能であるSiteWise Monitorを使用して、アセットの主要な測定値とメトリクスを監視し、必要に応じてニアリアルタイムで必要なアクションを実行する方法を学習しました。 パート3（この投稿）では、次の方法を学習します。 モデル化された機器データをAWS IoT SiteWiseからリアルタイムでストリーミングして、AWS IoT Coreのルールエンジンを介してカスタムアプリケーションで使用する 状態のモニタリングを有効にし、AWS IoT Eventsを使用してニアリアルタイムで通知またはアラートを送信する Amazon QuickSightを使用してヒストリカルデータに関するビジネスインテリジェンス（BI）レポートを有効にする AWS IoT SiteWiseは現在プレビュー中です。プレビュー中は、AWS IoT SiteWiseの使用に対して料金は発生せず、サービスは変更される可能性があります。 AWS IoT Events について AWS IoT EventsはIoTセンサーやアプリケーションからのイベントを簡単に検出して応答できるフルマネージドサービスです。これにより、機器またはデバイスのフリートを監視して、運用上の障害や変更を監視できます。また、このようなイベントが発生したときにアクションをトリガーできます。詳細については、AW​​S IoT Eventsコンソールの使用開始を参照してください。 Amazon QuickSight について Amazon QuickSightは、以下のことに使用できる高速なビジネス分析サービスです。 可視化の構築 アドホック分析の実行 セルフサービス方式でデータからビジネスの洞察をすばやく取得 […]

こちらはAWS Professional Service の IoT Global Specialty Practice に所属するシニアデータアーキテクト Asim Kumar Sasmal、IoT SiteWiseのシニアプロダクトマネージャーSourav Chakrabortyによる投稿になります。 [この投稿を読む前に、シリーズのパート1を読んでください。] このシリーズのパート1で、AWS IoT SiteWiseを使用して、安全で費用対効果の高い信頼できる方法で産業アセットをモデル化し、産業現場からデータを取り込む方法を学びました。 パート2（この投稿）では、次の方法を学びます。 AWS IoT SiteWiseの新機能であるSiteWise Monitorを使用してアセットの主要な運用パラメータとパフォーマンスメトリクスを監視し、必要に応じてニアリアルタイムで必要なアクションを実行する パート3で、あなたは次の方法を学びます : モデル化された機器データをAWS IoT SiteWiseからリアルタイムでストリーミングして、AWS IoT Coreのルールエンジンを介してカスタムアプリケーションで使用する 状態のモニタリングを有効にし、AWS IoT Eventsを使用してニアリアルタイムで通知またはアラートを送信する Amazon QuickSightを使用してヒストリカルデータに関するビジネスインテリジェンス（BI）レポートを有効にする AWS IoT SiteWiseは現在プレビュー中です。プレビュー中は、AWS IoT SiteWiseの使用に対して料金は発生せず、サービスは変更される可能性があります。 SiteWise Monitorについて SiteWise Monitorは、AW​​S IoT SiteWiseの新機能であり、大規模なプロセスや機器の運用データを表示、監視、共有するために使用できる管理されたウェブアプリケーションを提供します。ウェブポータルへのアクセスは、AWSシングルサインオン（SSO）を使用して、エンタープライズIDによって制御されます。つまり、プロセスエンジニアなどのドメインエキスパートは、AWSアカウントにアクセスしなくても、デスクトップまたはモバイルブラウザからSiteWise Monitor Webアプリケーションにサインインできます。SiteWise Monitorは、ユーザーがプロセスおよび機器のライブデータおよび履歴データをインタラクティブに表示するのに役立ちます。 ソリューションのアーキテクチャ 次の図は、この複数パートに及ぶ投稿で説明されているハイレベルのエンドツーエンドソリューションとソリューションで使用されるAWSサービスを示しています。 ウォークスルー このウォークスルーには2つのセクションがあります。 AWS IoT […]

こちらはIoT SiteWiseのシニアプロダクトマネージャー Saras Kaul、AWS Professional Service の IoT Global Specialty Practice に所属するシニアデータアーキテクト Asim Kumar Sasmal、シニアコンサルタント Mark Gilbertによる投稿になります。 産業に関するお客様は、安全で費用効果が高く、信頼性の高い、次のようなフィールドからクラウドへのソリューションを求めています。 数万のPLCとセンサーを持つ数百の産業現場からすべてのデータを取り込む デバイス、プロセス、および機器の主要な測定値およびメトリクスをニアリアルタイムで可視化 状態監視を有効にし、必要に応じてアクションを実行するために、ニアリアルタイムで通知とアラートを送信 レポートのためヒストリカルデータによるビジネスインテリジェンス（BI）を有効にする この複数パートに及ぶ投稿では、AWS IoTが顧客がこれらの主要な課題を解決するのをどのように支援するかの例を紹介します。 パート1(このブログ)で、あなたは次の方法を学びます : AWS IoT SiteWiseを使用して、産業アセットの仮想表現を作成する 産業現場にしまい込まれたデータを収集し、AWS IoT SiteWiseに取り込む この記事では、データをサブスクライブするためにAWS IoT SiteWise の OPC-UAサーバとしてKepwareのKEPServerEXと、付属のSimulator Driver を利用します。ただし、それ以外の任意のOPC-UAサーバも使用できます。 パート2で、あなたは次の方法を学びます : AWS IoT SiteWiseの新機能であるSiteWise Monitorを使用してアセットの主要な運用パラメータとパフォーマンスメトリクスを監視し、必要に応じてニアリアルタイムで必要なアクションを実行する パート3で、あなたは次の方法を学びます : モデル化された機器データをAWS IoT SiteWiseからリアルタイムでストリーミングして、AWS IoT Coreのルールエンジンを介してカスタムアプリケーションで使用する 状態のモニタリングを有効にし、AWS IoT Eventsを使用してニアリアルタイムで通知またはアラートを送信する […]

本日、グラフニューラルネットワークを簡単に実装できるオープンソースのライブラリ Deep Graph Library が Amazon SageMaker で使用できる機能が発表されました。 近年では、手書き文字・画像・動画などの複雑なデータから、精巧なパターンを抽出できる優れた能力によって、深層学習が世の中を席巻しています。しかしながら、このようなカテゴリーに分類されないデータは多く存在しており、こうしたデータはグラフを使うことでより適切に表現可能な場合があります。直感的にも、畳み込みニューラルネットワークや回帰型ニューラルネットワークのような従来のニューラルネットワークは、このようなデータに対して適切ではないことがわかりますし、新たなアプローチが必要と言えます。 グラフニューラルネットワークとは グラフニューラルネットワーク(GNN)は最近開発された機械学習に関連した技術の中で最もわくわくするものの一つで、これらの参考文献を読むことで、まずは概要を理解できます。 GNNは次のようなデータセットに対する予測モデルを作成するために使用されます。 ソーシャルネットワーク: 人同士の関係性を示すグラフ 推薦システム: カスタマーと商品の関係性を示すグラフ 化学構造解析: 化合物が原子やそれらの結合としてモデル化されているグラフ サイバーセキュリティ: ソースとデスティネーション IP アドレスの関係性を示すグラフ 多くの場合、これらのデータセットは非常に大きく、その一部にしかレベル付けがなされていません。例えば、詐欺行為の検出を目的として、特定の人物が詐欺を働く確率を予測するために、詐欺を過去に働いたことがある既知の人物との関係性を解析するシナリオを考えます。これは、グラフの一部のみが詐欺師または善良な人物としてラベルづけされている半教師あり学習のタスクになります。そして、人手でラベル付けした大規模なデータセットを用意して、データを「linearize」し、従来の機械学習アルゴリズムを適用するよりも良いソリューションであると言えます。 このような問題へ取り組むにあたって、それぞれの業界知識 (小売、金融、化学など) 、コンピュータサイエンスの知識 (Python, 深層学習, オープンソースのツール) 、IT インフラの知識 (モデルのトレーニング、デプロイ、スケールリングの方法) が必要になります。全てのスキルを習得できる方はごく少数でしかないため、Deep Graph LibraryやAmazon SageMakerのようなツールが必要とされています。 Deep Graph Libraryの紹介 Github上で2018年 12月にリリースされたDeep Graph Library (DGL) とは、研究者や科学者が自分たちのデータセットを対象に、GNNのすばやい開発・学習・評価を補助してくれるPythonのオープンソースライブラリです。 DGLは PyTorch や Apache MXNet のようなポピュラーなディープラーニングフレームワークの上で動作するようになっています。これらのフレームワークに関する知識がある場合は、初心者でも安心な実装例を通して簡単に使い始めることができます。GTC 2019 で開催されたワークショップの資料も非常に参考になります。実装例を試したあと、DGL で実装された最先端のモデルをここから試すことも可能です。例えば、Graph Convolution Network (GCN) と CORA […]

エンタープライズのお客様では、業務に必要な古い Windows Server アプリケーションがあり、サポートされている新しいバージョンの Windows Server に移行できない状態に陥ることがよくあります。 お客様は、これらの古いアプリケーションを移行できない多くの理由をお持ちです。アプリケーションは Windows Server の特定のバージョンに依存しているか、そのアプリケーションに関する専門知識がなかったり、インストールメディアやソースコードが失われた状態になっているのかもしれません。 2020 年 1 月 14 日に、Windows Server 2008 および 2008 R2 のサポートは終了(EOS: End of Support)します。 これらのサポートされていないバージョンの Windows Server でのみ実行できるアプリケーションがあると、セキュリティ更新プログラムが無償提供されなくなり、セキュリティとコンプライアンスのリスクに対して脆弱になるため問題があります。 またこのようなアプリケーションは、大幅な改修グなしでクラウドに移行することも困難です。 EOS を迎えたバージョンの Windows Server でのみ実行される古いアプリケーションがある場合、延長サポートが検討される事があります。 ただし、OS のアップグレードと言う避けられないことを遅らせているだけであり、お客様は古いアプリケーションを将来にわたって保証する長期的なソリューションが必要だと語っています。 長期的な解決策 これ等の問題を支援するために、2019 年 12 月 2 日（米国時間）、 AWS End-of-Support Migration Program (EMP) for Windows Server プログラムを発表します 。 […]

本日のAWS re:Invent 2019にて、AWS Fargate Spotを発表します。Fargate SpotはAWS Fargateの新しい機能です。中断に強いAmazon Elastic Container Service (Amazon ECS)タスクに最適であり、Fargate価格から最大70%割引で提供します。 もしEC2スポットインスタンスを知っていれば、同様のコンセプトで理解できます。Fargate Spotは、AWSクラウドの空きキャパシティを活用してタスクを実行します。Fargate Spotが空きキャパシティを確保できるかぎり、ユーザーは指定したタスクを起動することができます。AWSにキャパシティが必要になったとき、Fargate Spotで稼働するタスクは2分前の通知とともに中断されることになります。Fargate Spot用のキャパシティが使用できなくなると、Fargateは稼働中の通常のタスクを保持しながら、Fargate Spotで稼働するタスクをスケールダウンします。 タスクが中断される可能性があるという特性から、中断が許容できないワークロードをFargate Spotで稼働させるべきではありません。一方で中断耐性のあるワークロードに対しては、コスト最適化に大きく貢献します。 Fargate Spotは特に画像のレンダリング、モンテカルロシミュレーション、ゲノム解析といった並列度の高いワークロードに適しています。また高可用性を求められるウェブサイトやAPIサーバーのように、ECSサービスの一部となるタスクに対してもFargate Spotを適用することができます。 クラスター定義を作成・更新する際、常時稼働させるべき最低限のタスク数を指定し、さらに性能向上を狙いとするタスクをコスト効率の良いFargate Spot上で稼働するように構成することができるようになります。サービス定義のService Auto Scalingを利用することで、Fargate Spot用のキャパシティが使用可能になり次第、リクエストを満たすようにスケジューラーがタスクを起動し、Fargate Spot用のキャパシティが使用できなくなると、前述の通り先に指定した常時稼働タスクを保持しながら、Fargate Spotで稼働するタスクがスケールダウンする、という動作を実現することもできます。 AWS Fargate Spotの開始方法を見ていきましょう。 まずECSマネジメントコンソールより、新規のECSクラスターを作成します。Fargate起動タイプを選択するため、ここでは”Networking only”を選択し、ウィザードを進めます。 クラスターが作成されたらば、”Capacity Providers”タブからキャパシティプロバイダーを追加します。デフォルトではFARGATEとFARGATE_SPOTの2種類のキャパシティプロバイダーが用意されています。 キャパシティプロバイダーとしてFARGATE_SPOTを用いるのに、まずデフォルトのプロバイダーをFARGATE_SPOTに変更します。”Update Cluster”ボタンをクリックし、次の画面で”Add provider”をクリックしてFARGATE_SPOTを追加し、Updateボタンを押します。 続いて、これまでのようにタスクを起動します。事前に設定済みのタスク定義から、10のタスクを指定し、また”VPC and security groups”セクションでVPC関連の必要情報をセットしたのちに”Run Task”をクリックします。 起動された10個のタスクは、通常のFargate環境ではなくFargate Spot環境が選択されています。あるタスクをクリックしてみると、実際にキャパシティプロバイダーとしてFARGATE_SPOTが使用されたことがわかります。 ここまで、Fargate Spotの開始方法を紹介してきました。ぜひお手元でも試してみてください。 数週間前にCompute Savings Plansをリリースしました。FargateはCompute Savings Plansの一部に含まれます。さらにここでFargate Spotが登場したことより、費用の大幅な効率化とともに、様々な種類のアプリケーションへの一層の活用が期待できます。いま、Fargateを使うのにまたとないチャンスが訪れていると言えるでしょう。 […]

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、プロダクトマーケティング シニアエバンジェリストの亀田です。re:Invent 2019 2日目（12月3日）が終了しました。本日はAndy JassyのKeynoteがあり、非常に多くのサービスが発表されました。re:Invent2019らしい一日でした。 またJapan Nightもおこなわれ会場は大きく盛り上がりました。弊社代表取締役社長の長崎による始球式 （ストライクチャレンジ中） 司会を務めさせていただくのもなんと4年目となりました。今年は会場も広く音量も適切で安心しました。 それでは早速本日のまとめです。 Amazon Kendraが発表されました 機械学習を活用した非常に正確で使いやすい新しいエンタープライズ検索サービスです。自然言語を使用したより直感的な検索方法を提供し、より正確な回答を返すので、エンドユーザーは会社全体に広がる膨大な量のコンテンツに保存されている情報を見つけることができます。ユーザーは、「産休はどれくらいですか」などの質問をすることができます。「14週間」、そしておそらく関連するであろう「VPNの設定方法」などの具体的な回答が得られます。プロセスを説明するドキュメントから特定の文章を抽出します。Kendraを使用すると、マニュアル、調査レポート、FAQ、HRドキュメント、カスタマーサービスガイドなどのコンテンツから正確な検索精度を提供できます。Kendraのプレビューには、SharePoint Online、Amazon S3、およびデータベース用の組み込みコネクタが用意されていますが、Kendra APIを使用して他のデータソースからデータを取り込むこともできます。将来的に、Kendraは、Box、Dropbox、Salesforce、OneDriveなどの他の一般的なデータソース用追加のコネクタを提供を予定しています。 Amazon Managed Apache Cassandra Serviceをプレビューリリースしました Apache Cassandra互換のデータベースサービスであり、使用する同じCassandraアプリケーションコード、Apache 2.0ライセンスのドライバー、およびツールを使用してAWSクラウドでCassandraワークロードを実行することができます。テーブルは、実質的に無制限のスループットとストレージで、実際の要求トラフィックに基づいて自動的に拡大縮小できます。Amazon Managed Cassandra Serviceは、あらゆる規模で一貫した1桁ミリ秒のパフォーマンスを提供します。テーブルはデフォルトで暗号化され、データは耐久性と高可用性のために複数のAWSアベイラビリティーゾーンに複製されます。 Amazon EC2 M6g, C6g, and R6gがリリースされました 次世代のArmベースのAWS Graviton2プロセッサを搭載し最大40％の価格/パフォーマンスの向上を実現します。64ビットArm Neoverseコアを使用する新しいAWS Graviton2プロセッサと、AWSが設計した高度な7ナノメートル製造技術を使用して構築されたカスタムシリコンを使用しています。AWS Graviton2プロセッサは、第7世代のパフォーマンス、4倍の計算コア、コアあたり2倍のプライベートキャッシュ、5倍の高速メモリなど、第一世代のAWS Gravitonプロセッサに比べていくつかのパフォーマンス最適化を提供します。コアあたり2倍の浮動小数点パフォーマンス。さらに、完全に暗号化された常時オンのDDR4メモリを備え、セキュリティをさらに強化し、コアごとの暗号化パフォーマンスを50％高速化します。 Amazon EKSでAWS Fargateがリリースされ、サーバレスのKubernetesポッドが実行できるようになりました Amazon Elastic Kubernetes Service（EKS）は、AWSでKubernetesを簡単に実行できるマネージドサービスです。AWS Fargateは、Amazon EKSクラスターの一部としてKubernetesポッドとして実行されるコンテナに、オンデマンドで適切なサイズの計算能力を提供します。Fargateを使用して、Kubernetesポッドは、要求された計算能力だけで実行され、各ポッドは他のポッドとリソースを共有することなく、独自のVM分離環境で実行されます。実行したポッドに対してのみ料金を支払うことで、追加の作業なしでアプリの使用率とコスト効率を改善します。 Amazon Elasticsearch ServiceのUltraWarmがプレビューリリースされました Amazon […]

2019年12月3日、機械学習（ML）学習時に起こる複雑な問題を自動的に識別する Amazon SageMaker の新しい機能、Amazon SageMaker Debugger を発表できて非常にうれしく思います。 機械学習モデルの構築と学習は、サイエンスと工芸の融合です（魔術と言う人もいます）。データセットの収集から準備、さまざまなアルゴリズムの実験、最適なトレーニングパラメーター（恐ろしいハイパーパラメーター）の探索まで、機械学習を実行する人は高性能のモデルを提供するために多くのハードルをクリアする必要があります。これがまさに、機械学習ワークフローを簡素化し高速化する、モジュール式のフルマネージドサービス Amazon SageMaker を構築する理由なのです。