Amazon Transcribe Medicalについて調べてみた

この記事は株式会社ナレッジコミュニケーションが運営する Amazon AI by ナレコム Advent Calendar 2019 の6日目にあたる記事になります。

はじめに

今回のメインテーマについて触れる前にAmazon Transcriveについておさらいします。

Amazon Transcribeは自動音声認識 (ASR) サービスです。
Amazon Transcribe APIを使用すればS3に保存されたオーディオファイルから音声を文字起こしし、テキストファイルを返したりといったことも実装できます。
またAmazon Transcribeを使用すれば文字起こしのストリーミングをリアルタイムで受け取ることも可能です。
そして2019年11月には日本語も対応しました!待ち望んでいた方も多いのではないでしょうか。

料金体系も非常にシンプルで秒単位の課金になります。
例えば東京リージョンの価格は1 秒あたり 0.0004USD のレートで月ごとに課金されます。
30分のビデオを文字起こししたとしても100円かからない程度です。お得ですね。
※15 秒未満のリクエストについては 15 秒分の料金が発生します。

Amazon Transcrive Medical リリース!

Amazon Transcrive MedicalはAmazon Transcribeの新しい認識機能で医療分野で活躍するサービスです。
電子医療記録 (EHR) システム(※1)の標準化が進んできたこともあり、医者と患者の会話などを記録することが重要になってきました。
Amazon Transcrive Medicalはそういったニーズに応えた臨床メモなどを記録することに特化したサービスです。
※1 
異なる医療機関・健康関連組織で別々に管理されている個々人の健康・医療情報を地域/国レベルで集約・統合して共同利用する仕組みのこと。

特長

医療業界ではあまり一般的ではない専門用語が数多くありますが、Amazon Transcrive Medicalはそういった単語もカバーします。
また従来の文字起こしサービスの課題であった「点」「丸」「カンマ」「ピリオド」などを言う必要もないのも特徴です。
さらにAmazon Transcrive MedicalはHIPPA(※2)適格の対象です。
MT Samples から匿名化された実際の医療記録をサンプルとして使用できるのでぜひ試してみてください。
※2 
1996 年に制定された米国における医療保険の相互運用性と説明責任に関する法令

提供リージョン

2019年12月現在Amazon Transcribe Medical は米国東部 (バージニア北部) と米国西部 (オレゴン)リージョンで利用できます。

最後に

AWSが提供するAIサービスはAmazon Transcrive Medicalのように業界に特化したサービスもちらほら提供され始めましたね。
cloudは使えないといった業界は今後どんどん縮小していくのでは、と感じさせる興味深いアップデートでした。


AIが自動的にコードレビューする「Amazon CodeGuru」

AWS re:invent 2019の基調講演にて、新サービス「Amazon CodeGuru」が発表されました。

Amazon CodeGuruとは

機械学習で自動的にコードレビューを行うことができる、プログラミングに関わるほぼすべての企業やデベロッパーにとって嬉しいサービスです。Amazonが自社プロダクトのために行ってきた数十万の開発プロジェクトとGitHubの10,000を超えるオープンソースソフトプロジェクトをもとにして開発されました。

AWSのベストプラクティスに則っていない部分やリソースリーク、潜在的な同時実行の競合状態、CPUサイクルの浪費などのコードの問題、脆弱性などの「問題がある(ありそうな)」ソースの場所を教えてくれます。
CodeGuruには、CodeGuru Review」と「CodeGuru Profiler」の2つの機能があります。

「CodeGuru Review」とは

「CodeGuru Review」はベストプラクティスから逸脱している部分やページングの欠落、バッチ操作のエラー処理など、本番に影響がある可能性のある部分を検出する手助けをしてくれます。
公式ウェブサイトには「夜に目を覚ましてしまう様なコードを見つける」とあります (プログラミングをしている人なら経験があると思います)。プルリクエストしてコードレビューを依頼するなどの対策をしても、ちょっとしたミスでサービスに大きな影響があるバグが発生してしまわないかという恐れは常に抱えているものです。コードレビューをいつでも24時間365日利用できるというのは、開発者にとってこの上ないほど心強いサービスです。

「CodeGuru Profiler」とは

「CodeGuru Review」が本番運用に影響があるコードを見つけるサービスであるのに対して、「CodeGuru Profiler」はコスト削減を目的としたサービスです。

CPUを大量に使う処理や再実行などによる過剰なコンピューティングリソースの使用を検出し、AWS上でコスト効率よく稼働するプログラムを作成するサポートをしてくれます。ゲーム会社などアプリケーション開発の経験値が高い企業であればこれを十分に考慮したうえでコーディングするノウハウが蓄積されていますが、そのような知識を持っている技術者がいなくてもコスト削減のためのコードチェックを行うことができます。「コストが下がる」ケースの多くは同時に処理速度も早くなる可能性が十分にあり、多くの開発現場で役立つサービスです。

早速「CodeGuru Review」を使ってみた

CodeCommitで Source > Repositories > Settings > Amazon CodeGuru Reviewer で設定を有効にするだけで利用可能です。

以後、Pull Requestを実行すると自動的に CodeGuru Review も実行され、特に何もなかった場合は Pull requests > Activity に以下のように表示されます。なお、あえてバグを作ってチェックしてみましたがバグ自体のチェックは行われないようです。(IDEでチェックできるので、あえてチェックしていないのかもしれません)

逆に本番に影響ある可能性があるコードについては以下のように表示されます。どのプログラムのどの行でどんな問題があるかを教えてくれます。

「利用料金」は

「CodeGuru Review」は1か月にスキャンされるコード100行あたり0.75ドル
「CodeGuru Profiler」はサンプリング時間あたり0.005ドル/月(ただし、1アプリケーションプロファイルで36,000サンプル時間は無料)
となっています。

例えば、200行のプルリクエストに対して「CodeGuru Review」を利用すれば 20.75ドル=1.5ドルとなります。1つのプロジェクトで1ヶ月10プルリクエストあり、プルリクエストあたり平均300行だとすると、10回3(00行)*0.75=22.5ドルとなります。
プルリクエストとコードレビューに要する時間を考慮すると、この金額は驚異的です。

「CodeGuru Profiler」はプログラムを実行するEC2、ECS、EKS、Fargate上のCPU使用率とレイテンシー特性をサンプリングしてくれます。1インスタンスで利用した場合は1アプリケーション1インスタンス24時間*30日=720サンプル時間となり、3.6ドルとなります。台数及びアプリケーションが増えるとコストも増えますが、過剰な処理が行われている部分を見つけてくれるので、安定稼働するまでは有効するといった利用方法も可能と思われます。

どんな言語が使えるの

2019年12月現在、Javaのみ対応となっています。「より多くの言語をサポートする予定」となっているので、機械学習と相性が良いPythonの対応が楽しみです。


Amazon Comprehend を利用した口コミの感情分析

はじめに

今回は AWS の提供する自然言語処理(NLP)サービス Amazon Comprehend を利用して文章の感情分析を行います。
弊社の運営する スクール検索口コミサイト の口コミを利用して感情分析を行い、弊社の口コミサイトの現状を確認してみようと思います。

Amazon Comprehend とは

AWS の提供する自然言語処理(NLP)サービスです。文章を入力として与えることで、エンティティやキーフレーズ、主要言語の検出ができたり、感情分析や構文分析、トピックモデリングができます。
また、AutoMLを利用することで、自然言語処理の専門知識なしでカスタムモデルが作成でき、文章を独自のカテゴリに分類したり、特定の用語や名詞ベースでのエンティティ抽出が行えます。
https://aws.amazon.com/jp/comprehend/
こちらでは、AWS Comprehend の利用例が記述されています。
※英語のため、Google のページ翻訳を用いて読むことをお勧めします。
2019年11月7日に日本語対応となったためご紹介いたします。

今回やること

弊社の運営する、スクール検索口コミサイトの口コミ感情分析を行います。
運営する口コミサイトが現状どのような場として利用されているのか、口コミの感情から傾向を読み取ろうと考え、検証に至りました。

データの準備

解析したい文書を1行ごとにテキストファイルに追加します.
口コミサイトより、約4万6千件の口コミを入手し、各口コミを1行ごとに追加しました。
※1行当たり5120バイトまでという制限があります。

データを S3 にアップロード

Amazon Comprehend は日本語対応したものの、まだ東京リージョンでは扱えないため、連携する S3 バケットを Amazon Comprehend で利用できるリージョンで作成する必要があります。
以下に Amazon Comprehend が対応しているリージョンを示します。
対応リージョン
欧州(ロンドン)
欧州(アイルランド)
アジアパシフィック(シンガポール)
アジアパシフィック(シドニー)
欧州(フランクフルト)
米国東部(バージニア北部)
米国東部(オハイオ)
カナダ(中部)
米国西部(オレゴン)
※2019/11/27時点
・s3 バケットを対応リージョンで作成します。

・作成したバケットの任意の場所に、文章データをアップロードします。

Amazon Comprehend で 感情分析

・s3 バケットを作成したリージョンにいることを確認し、Amazon Comprehend を開きます。

・Launch Amazon Comprehend クリックします。

・サイドバーから Analysis jobs を選択し、Create job をクリックします。

・Name : 任意のジョブ名を付けます。
・Analysis type : 分析に利用するタイプを選択します。今回は感情分析をおこなうため、Sentiment を選択します。
・Language : 解析する文章の言語を指定します。

・Data source : 利用するデータソースを選択します。
・S3 location : 入力データの保存先を指定します。
・Input format : 入力データのフォーマットを選択します。今回は1ファイルの各行に文章を保存したため、 One document per line を選択します。

・S3 location : 以下に出力先 s3 パスを入力します。

・作成した s3 バケットへの入力、出力を許可するロールを選択してください。

・Create job をクリックします。

・ジョブを作成したら、Status が Completed になるまで待ちます。
・6722465文字のデータに対して、7分ほどで解析は終了しました。

実行が完了したら、ジョブから解析結果の保存先パスが確認できます。

・解析結果は以下の形式で保存されています。
SentimentScore には文書がその感情である確度を示すスコアが入ります。

[crayon-5f0b067d63b16653345952/]

解析結果

口コミサイトの口コミ感情分析を行った結果は以下のようになりました。

まず一番、多いのが NEUTRAL でした。
次に多いのが、NEGATIVE でした。
この結果から、弊社の運営する口コミサイトでは基本中性的な口コミばかりだが、ネガティブな口コミも比較的多くみられることがわかりました。

料金

今回の検証にかかった料金を以下に示します。
・感情分析の利用料金

※1ユニット = 100文字
・今回利用したユニット数
6722465文字 / 100 = 約67224ユニット
・利用料金
67224 * 0.0001USD = 6.7724 USD

おわりに

今回は、Amazon Comprehend を利用して口コミの感情分析を行ってみました。
約4万6千件ものデータをたった7分、しかも700円ほどで解析できてしまいかなり驚きました。
会社やイベント等のアンケートやレビューを安く、早く、簡単に分析したい。
そんな場合は、ぜひ Amazon Comprehend を利用してみてはいかがでしょうか。


Amazon Braket 破壊的なフルマネージド型量子コンピュータサービス

量子コンピュータはガートナーの「2019年の戦略的テクノロジ・トレンドのトップ10」にも選定されているサービスで、
そう遠くない未来にビジネスでの実利用が可能になると言われています。
そんなサービスが、早くもAWSのフルマネージドサービスとしてリリースされました。

初めて量子コンピュータを調べたときには、まず宇宙(量子)の話から始まり哲学の話にも進み・・・と非常に焦ったことを覚えています。
数年後に無料体験できるサービス上でマックスカット問題のシミュレーションを動かし、大きな可能性を感じました。

量子コンピュータとは

「量子力学の原理」を利用して計算する次世代コンピュータです。
スーパーコンピュータを超えるものだとする記事も見られますが、正確には特定の処理に特化したスペシャリストのようなコンピュータで、超並列処理が得意という特性を持っています。

n 量子ビットがあれば、2nの状態を同時に計算出来るので、「組合せ最適化問題(様々な条件下での最適な組み合わせを選ぶ)」のような多くの組み合わせから、条件に合わせて最適なものを選ぶような演算に向いていると言われています。
量子コンピュータはハードウェアからして従来のコンピュータと異なります。


※画像は「Amazon Braket – Get Started with Quantum Computing」から引用

量子コンピュータは万能か

量子コンピュータは、前述の通り特定の処理に特化したコンピュータです。
そのため、量子コンピュータの活用に向いている処理であるかどうかを見極める必要があります。
今後、量子コンピュータの利用が一般的になるにつれて、Python等で利用できるライブラリが増え、現時点では不得手な処理に対しても適用できるようになる可能性が高いと思われます。

量子コンピュータでしか出来ないことはあるのか

YesでありNoです。量子コンピュータ以外のコンピューティングリソースのスペックが飛躍的に上がっています。
加えて、「総当り」から「当たりをつける」ような組み合わせ問題の解決方法の開発が進んでおり、
従来ではスーパーコンピュータでも難しく量子コンピュータでしか出来ないと言われていた演算も出来るようになってきています。

Amazon Braketの何がすごいのか

ハードウェアを所有する必要がないという点はもちろんですが、
プログラミングスキルや専用知識が必要だった量子コンピュータを、jupyter notebook 形式のインターフェースでフルマネージド型のサービスとして扱うことができる点が大きいです。
従来であれば、数ある量子プログラミング言語から目的にあった言語を覚え、量子コンピュータの実行環境を準備するという莫大なコスト と工数をかけなければ利用できなかった量子コンピュータを簡単に利用することが出来ます。
ハードルが高かった量子コンピュータを一般的に利用できるようになることで、利用できる範囲が飛躍的に増え、更に利用シーンが増えていくと思われます。

参考記事

「量子コンピューターの “よくある誤解” Top10」


Amazon Forecast を利用して、お店の商品の売り上げ予測をする。

はじめに

今回は、kaggle の Store Item Demand Forecasting Challenge のデータを使用して、お店の商品の売り上げ予測を Amazon Forecast で行います。

・Store Item Demand Forecasting Challenge
https://www.kaggle.com/c/demand-forecasting-kernels-only
このデータセットには2013/1/1~2017/12/31日までの毎日の売り上げが、各店の各商品ごとに用意されています。
店舗は10店、商品は50品用意されています。
以下、データの初め5行になります。

Amazon Forecast とは

Amazon Forecast とは、機械学習を使用して精度の高い予測を行うフルマネージド型のサービスで、履歴のあるデータセットであれば、どのような時系列データからでも予測結果を生成できます。

今回利用するデータ

今回はStore Item Demand Forecasting Challengeの train データから以下のデータを抽出し、学習テストデータとして利用します。

学習データ
・store 1 の item 1
・2013/1/1~2017/10/31 までの毎日の売り上げ

テストデータ
・store 1 の item 1
・2017/11/1~2017/12/31 までの毎日の売り上げ

実践

・awsコンソールから forecast を開きます。

データセットグループの作成

・Create dataset group をクリックし、データセットグループの作成をします。

・データセットグループの設定を行います。
-Dataset group name : 任意のデータセットグループ名を入力します。
-Forecasting domain : データセットドメインの設定。今回は小売り予測のため Retail を選択します。
データセットドメインの詳細はこちらを参照してください。

データセットの設定

・データセットの設定を行います。
-Dataset name : 任意のデータセット名を入力します。
-Frequency of your data : 時系列データの区切りを選択します。今回のデータは日にち区切りなので 1day を選択します。

・Data schema : データの保存形式に合わせてスキーマを設定。データドメインごとに必要な情報が変わるので、先ほどのドメインからデータセットタイプを参照してください。

データセットのインポート設定

・データセットのインポート設定を行います。
-Dataset import name : データセットインポート時の名前を入力します。
-Timestamp format : 入力データに合わせてタイムスタンプを設定します。
-IAM Role : 読み込みを行う、対象のs3バケットへの権限を付与したIAMロールを指定します。
-Data location : s3 に保存している、入力ファイル(csv)パスを入力します。

予測子の作成

・Target time series data のステータスが Activeになったら、Predictor training の Start をクリックし、予測子の作成をします。
※他にも、item metadata data や Related time series data といったデータをインポートできます。データセットドメインごとに、各データに推奨される項目があり、推奨項目を入力することで精度があがるとされています。今回はインポートしません。

・予測子の設定を行います。
-Predictor name : 予測に付ける名前を入力します。
-Forecast horizon : どれだけ先まで予測を行うか設定します。
-Forecast frequency : 予測の区切りを設定します。
-Algorithm selection :アルゴリズムの設定をします。今回は、最適な手法を自動で見つけてくれるAutomaticを選択します。
-Forecast dimentions : 通常予測はitem_id毎に行われますが、必須ではないパラメータを入力として与えていた場合、そちらを対象に予測を行えます。
-Country for holidays : 国ごとの祝日を考慮するように設定できます。
-Number of backtest windows: 学習時の検証用データをいくつ切り出すか設定します。
-Backtest window offset : 切り出す検証用データのデータ数を設定します。


・Predictor training が Active になったら、予測子の作成が完了です。

・サイドバーからPredictor をクリックし、予測子の詳細を確認できます。

・予測子を開くと、AutoMLで選ばれたアルゴリズムや、精度の指標となるwQLやRMSEなどを確認できます。

・結果を確認したら、右上の Create a forecast をクリックし、予測を行います。

予測

・予測の設定を行います。
-Forecast name : 予測の名前を入力します。
-Predictor : 利用する予測子を選択します。

予測結果の可視化

・予測が完了すたら、Dash board から Lookup forecast をクリックします。

・予測の表示設定を行います。
-Forecast : 利用する予測を指定します。
-Start date : 表示するデータの開始時間を設定します。
-End date : 表示するデータの終了時間を設定します。
-Choose the keys you want to use to filter your forecasts : 予測結果を表示する item を選択します。

・実行すると以下のように設定した範囲のデータが表示されます。
左側の黒いグラフが学習データ、右の色つきのグラフが予測結果になります。
予測が正確か確認するために、予測結果をダウンロードし、テストデータと比べます。

予測結果のエクスポート

・サイドバーから Forecasts を選択し、作成した予測をクリックします。

・右下の Create forecast export をクリックします。

・エクスポート設定を行います。
-Export name : エクスポートの名前を入力します。
-Generated forecast : エクスポートする予測を選択します。
-IAM Role : 対象のS3への書き込み権限のあるIAMロールを設定します。
-S3 forecast export location : 予測結果を保存する s3 パスを入力します。

・export が Active になったらエクスポート完了です。

・対象の s3 パスに無名のフォルダが作成され、フォルダ内に予測結果が csv 形式で保存されています。

予測結果の比較

p50 の予測結果をテストデータ と比べてみます。
青がテストデータ、オレンジが予測結果となります。
おおむね、特徴はとらえられているかと思います。

上記グラフにp10、p90 を追加したグラフが以下になります。

Amazon Forecast の料金

以下にAmazon forecast の費用を示します。

今回の検証にかかった金額

おわりに

今回は、Amazon forecast を利用して小売り予測をしてみました。
時間、商品番号、売り上げデータのみで、これだけ予測が得られるのには驚きました。
更にパラメータを追加することで精度が上がるようなので、もう少し複雑なデータセットで試してみてもいいかもしれないです。


スポットインスタンスを利用して、SageMakerのモデルトレーニングをしてみた

はじめに

今回は、AWS SageMaker によるモデルトレーニング時にスポットインスタンスが利用できるようになったので、実際に利用し、どれだけコスト削減できるか確認します。
※注意※
本稿は、実際のモデルトレーニング時にスポットインスタンスを利用する方法と、どれだけコスト削減できたかを紹介する記事です。
モデルトレーニング時のスポットインスタンス利用で何が変わるのか、何が利点なのかについては以下の記事でご紹介していますので、参考にしていただけると幸いです。
スポットインスタンスを利用して、SageMaker でのモデル作成コストを最大90%削減する

モデルトレーニング時のスポットインスタンス利用方法

モデルトレーニング時にスポットインスタンスを利用するには、以下の2つの項目を設定することが必須です。
・Enable managed spot training (スポットインスタンスの利用を有効にする)
・Maximum wait time before job terminates optional stopping condition (最大実行時間)
以下、設定方法を説明します。

トレーンングジョブの作成

・SageMaker のサイドバーからトレーニングジョブを選択し、右上のトレーニングジョブの作成をクリックします。

・任意のジョブ名と、適切なIAMを選択します。

・アルゴリズムの設定を行います。今回私は、組み込みアルゴリズムの ObjectDetection を利用します。

・利用するインスタンスタイプと停止条件を設定します。
ストレージボリュームにはトレーニングジョブのチェックポイントを保存できるだけの容量を確保しましょう。

・入力データやハイパーパラメータは各自設定をお願いします。
・次にチェックポイントの保存先を設定します。
これは、スポットインスタンス中断時にチェックポイントの情報をS3に保存し、スポットインスタンス再開時に参照する設定です。
この設定をしないと、スポットインスタンス中断によってトレーニングジョブが一からやり直しになります。

・モデル保存先を設定します。

・スポットインスタンスの利用を有効にし、最大実行時間を設定します。

・設定は以上になります。トレーニングジョブの作成をクリックし、モデル作成を始めましょう。

トレーニングジョブ作成時にエラーが発生した場合

AWS のサービス制限による、エラーの可能性があります。
2019年9月6日時点で、SageMakerのスポットインスタンスについて、制限緩和を行う項目はありません。
SageMakerのスポットインスタンスの制限緩和を行う手順を別途記事にしましたので、以下の記事を参考に制限緩和をお願いします。
SageMakerのスポットインスタンスを利用したモデルトレーニングに関する制限緩和方法について

結果の確認

実行結果は以下の通りでした。

p3.2xlarge のスポットインスタンスは、オンデマンドインスタンスから見たコスト削減割合が70%のため、実行時間288秒に対する請求が、86秒の請求として処理されます。

※東京リージョンの最大コスト削減率は c4 シリーズを利用する際の、75%となります。

おわりに

今回はスポットインスタンスを利用して、SageMakerのモデルトレーニングを行い、実際にどれだけコスト削減できるか確認しました。
モデルトレーニングに重要な時間制限がない場合は、ぜひスポットインスタンスを利用したモデルトレーニングをしてみてください。

 

SageMakerの導入ならナレコムにおまかせください。

日本のAPNコンサルティングパートナーとしては国内初である、Machine Learning コンピテンシー認定のナレコムが導入から活用方法までサポートします。お気軽にご相談ください。

ソリューションページはこちら

 

 


SageMakerのスポットインスタンスを利用したモデルトレーニングに関する制限緩和方法について

はじめに

2019年9月6日時点では、SageMaker スポットインスタンスを利用したモデルトレーニングに関する制限緩和項目がありません。
そのため今回は、SageMaker のスポットインスタンスを利用したモデルトレーニングに関する制限緩和の方法についてご紹介します。

スポットインスタンスを利用したモデルトレーニング時のインスタンス制限緩和

制限緩和には、リソースタイプとして「SageMaker のトレーニング」を選択したうえで、申請理由の欄に、通常のトレーニングジョブではなく"スポットトレーニングジョブ"の緩和を希望していることを明示する必要があります。
以下手順を説明します。
・SageMaker のコンソール右上のサポートからサポートセンターをクリックします。

・Creat Case をクリックします。

・真ん中のService limit increaseをクリックします。

・SageMaker を選択します。

・以下のように設定します。

・申請理由と通常のトレーニングジョブではなく"スポットトレーニングジョブ"の緩和を希望していることを記入します。

・設定を終えたら、Submit をクリックします。

・以上でで申請は完了となります。
※制限緩和には数日かかる場合があります。

おわりに

今回はSageMakerのスポットインスタンスを利用したモデルトレーニングに関する制限緩和方法についてご紹介しました。
スポットインスタンスに関する項目追加の対応があるまでの参考になると幸いです。

 

SageMakerの導入ならナレコムにおまかせください。

日本のAPNコンサルティングパートナーとしては国内初である、Machine Learning コンピテンシー認定のナレコムが導入から活用方法までサポートします。お気軽にご相談ください。

ソリューションページはこちら

 

 


スポットインスタンスを利用して、SageMaker でのモデル作成コストを最大90%削減する

はじめに

今回は2019年8月28日に発表された、AWS SageMaker によるモデルトレーニング時のスポットインスタンス利用についてご紹介いたします。
※注意※
本稿はモデルトレーニング時のスポットインスタンス利用についてご紹介する内容です。
実際にスポットインスタンスを利用する手順や利用した結果を見たい方は以下の記事をご覧ください。
スポットインスタンスを利用して、SageMakerのモデルトレーニングをしてみた

SageMakerのモデルトレーニングにスポットインスタンスを利用する。

スポットインスタンスとは

スポットインスタンスとは、AWS クラウド内の使用されていない EC2 リソースを最大90%安く利用できるサービスです。
今まで SageMaker のモデルトレーニング時には、オンデマンドインスタンスと呼ばれるインスタンスが利用されおり、オンデマンドインスタンスでは、いわゆる通常料金の支払いが発生していました。
ですが、今回のアップデートで、スポットインスタンスを利用したモデルトレーニングを行うことが可能になり、いままでモデルトレーニングのインスタンスで発生していた料金を最大90%節約できるようになりました。

スポットインスタンス中断時について

スポットインスタンスは安く使えるという反面、ある一定条件下でインスタンスを中断するという性質があります。
本来であれば、中断に備えていくつかの準備をしておくことが必要です。
ですが、AmazonSageMaker のモデルトレーニングでスポットインスタンスを利用する際は、スポットインスタンス中断時に、トレーニングジョブを中断し、適切なスポットインスタンスを再度取得、モデルトレーニングを再開、続行のプロセスを自動で行います。

どういった場合にスポットインスタンスを利用して、モデルトレーニングを行うのか

スポットインスタンスを利用すれば、料金は安くなり、中断時のプロセスも自動でやってくれて、使わない手はないと思われる方がいるかもしれません。
ですが、1つ注意点があります。それは実行時間です。

スポットインスタンス利用時のモデルトレーニングでは、中断時のプロセスが発生する可能性があります。
このプロセスにより、通常のオンデマンドインスタンスでのトレーンング時間に加えて、指定したインスタンスのリクエスト、中断時のプロセス時間がかかります。

このことから、スポットインスタンスの利用は、モデルトレーニングに重要な時間制限がない場合に限ります。

おわりに

今回はモデルトレーニング時のスポットインスタンス利用についてご紹介しました。
次回は実際にスポットインスタンスを利用したモデルトレーニングを行い、どれだけ節約できるか確認します。
スポットインスタンスを利用して、SageMakerのモデルトレーニングをしてみた

 

SageMakerの導入ならナレコムにおまかせください。

日本のAPNコンサルティングパートナーとしては国内初である、Machine Learning コンピテンシー認定のナレコムが導入から活用方法までサポートします。お気軽にご相談ください。

ソリューションページはこちら

 

 


AWS SystemManagerを使用してCloudWatchを利用する方法(Linux)

こんにちは、kc-dreamです。
今回は、AWSのCloudWatch CustomMetric及びCloudWatch Logsの設定方法についてご紹介していきます。

本記事について

AWS SystemManagerを使用し、CloudWatch Agentをインストールし、各種情報を取得するまでの方法をご紹介します。
※CentOS 7を使用した場合となります。

前提条件

CloudWatch エージェントを使用して Amazon EC2 インスタンスとオンプレミスサーバーからメトリクスとログを収集する

[crayon-5f0b067d64621860977580/]

SystemManager(SSM)がインストールされていなければインストールする
Amazon EC2 Linux インスタンスに SSM エージェント を手動でインストールする

IAMロールの作成

・IAMロールを作成し、対象のEC2にアタッチ
 ・下記2つのPolicyをロールに付与する

[crayon-5f0b067d6462e874988895/]

AmazonEC2RoleforSSMはSSM Agentを実行するために必要になります。

[crayon-5f0b067d6463b639598214/]

SSMのRunCommandを使用してCloudWatch Agentをインストール

1.SSM コンソールよりSystem Managerメニューに移動し、左側メニューからランコマンドを選択
2.右側のオレンジボタン「コマンドを実行」

3.ターゲットから対象のインスタンスを選択する (IAMロールが正しく割り当てられているインスタンスが表示されます)
4.実行

[crayon-5f0b067d64645334209435/]

対象のインスタンスにログイン

下記コマンドを実行し、設定情報を選択していきます

[crayon-5f0b067d6464f199426388/]

※対象サーバへは、SSMの[セッションマネージャ]を使用し接続することが可能です
(SSMの使用権限が必要)

CloudWatch Agent設定項目

[crayon-5f0b067d64659843860403/]

[crayon-5f0b067d64662395513836/]

[crayon-5f0b067d6466b350163447/]

[crayon-5f0b067d64673534504781/]

[crayon-5f0b067d6467c712121235/]

[crayon-5f0b067d64685805725497/]

[crayon-5f0b067d6468e043099398/]

[crayon-5f0b067d64697756881733/]

[crayon-5f0b067d646a0859429471/]

[crayon-5f0b067d646a9767697592/]

[crayon-5f0b067d646b2962999187/]

[crayon-5f0b067d646bb398336698/]

[crayon-5f0b067d646c4234139345/]

[crayon-5f0b067d646cc816301878/]

[crayon-5f0b067d646d9300533269/]

[crayon-5f0b067d646e2643376769/]

[crayon-5f0b067d646eb037644400/]

[crayon-5f0b067d646f4183930314/]

[crayon-5f0b067d646fd275331757/]

[crayon-5f0b067d64706626352602/]

[crayon-5f0b067d6470e834452135/]

[crayon-5f0b067d64717364282486/]

[crayon-5f0b067d64725329591978/]

[crayon-5f0b067d647af624303082/]

[crayon-5f0b067d647ba307017513/]

[crayon-5f0b067d647c3293107406/]

[crayon-5f0b067d647cb791345000/]

CloudWatch Agentの有効化

[crayon-5f0b067d647d4254984745/]

[crayon-5f0b067d647dd981672494/]

[crayon-5f0b067d647e6158951514/]

AWSコンソールのCloudWatchからCustomMetric及びLogが取得できているかを確認

CloudWatch コンソール

参考URL

collectDが導入されてるか:collectD設定方法
取得するメトリクスの種類:ウィザードを使用してCloudWatchエージェント設定ファイルを作成する


AWS SAM 構文を利用した CloudFormation による Lambda と API Gateway の作成

はじめに

今回は AWS SAM 構文を利用し、 Hello を返す API を作成しました。
AWS SAM 構文を利用すると、シンプルな設定のみでAPIを作成できます。
今回作成するシステムの構成図を以下に示します。

開発環境

・AWS-CLI 1.16.158
・Microsoft Windows 10 Home
※AWS CLI のインストールをしていない場合は、以下を参考にインストール、認証を行ってください。
AWS CLI のインストール
AWS CLI の認証

yaml ファイルの作成

この yaml ファイルに API Gateway と Lambda の設定を書き込みます。
今回使用した yaml ファイルは以下の通りです。

[crayon-5f0b067d65152873411464/]

Pythonコードの作成

ただ、Hello を返すコードを記述しました。

[crayon-5f0b067d6515f037835761/]

各ファイルをパッケージ化し、テンプレートとしてs3にアップロード

以下のコマンドで、各ファイルをパッケージ化し S3 にアップロードします。
このパッケージは、この後 CLoudFormation にデプロイするために利用します。

[crayon-5f0b067d6516a838971186/]

デプロイ

作成したテンプレートを以下のコマンドでデプロイします。
先ほどのコマンドの実行結果からコマンドをコピペします。
--stack-nameには任意のスタック名を入力し、末尾に--capabilities CAPABILITY_IAMを付けて実行します。
--capabilities CAPABILITY_IAMは IAM 関連の処理を行う際に必要になります。

[crayon-5f0b067d65174309200987/]

作成されたAPIの確認

実際に、作成されたAPIをたたくと以下のように Hello と表示されます。

おわりに

今回はAWS SAM 構文を利用して、API を作成しました。
AWS でサーバーレスアプリケーションを構築する際は、CloudFormation の構文を利用するより、SAM 構文のほうがシンプルに書けるので試してみてください。