Enterprise Cloud Service Public Preview on AWS - Enterprise Security 編についてまとめて和訳してみた②-1

はじめに

今回は、2020年6月12日に Vinay Wagh 氏と Abhinav Garg 氏によって投稿されました「 Enterprise Cloud Service Public Preview on AWS 」で紹介されている Enterprise Security の1つである「 Customer-managed VPC 」に関する内容を翻訳し、まとめてみました。

本記事のリンクは下記参照。
■リンク
Customer-managed VPC
Enterprise Cloud Service Public Preview on AWS

エンタープライズセキュリティ

今回の AWS 上での Databricks のエンタープライズクラウドサービスにおけるエンタープライズセキュリティの主な内容は以下の4つです。
今回は、この5つの内の「②顧客管理VPC」の VPC の構成について、紹介したいと思います。

■エンタープライズセキュリティ
①Data Lake の真のポテンシャルを妨げないセキュリティ
②顧客管理VPC
③セキュアなクラスター接続
④Notebook の為の顧客管理キー
⑤IAM 証明パススルー

顧客管理VPC

概要

ワークスペースクラスタは Databricks がユーザの AWS アカウント内に作成、および構成する単一の AWS VPC(仮想プライベートクラウド)内に作成されます。ユーザは顧客管理 VPC と呼ばれる VPC を、 Databricks ワークスペースに作成でき、インフラストラクチャの制御、ユーザの所属する組織が求めるクラウドセキュリティとガバナンススタンダードに準拠することができます。

顧客管理 VPC は、以下の様な場合に最適なソリューションです。

  • PaaS プロバイダが AWS アカウント上に VPC を作成できないよう、情報セキュリティポリシが存在
  • 社内の情報セキュリティチームやクラウドエンジニアリングチームによって、十分に文書化された方法で VPC を構成し、セキュリティを確保した上で新しいVPCを作成する承認プロセスが存在

以下のメリットが挙げられます。

  • 低い特権レベル
    • 自分のAWSアカウントをより制御可能
    • クロスアカウント IAM ロール役割を介して多くの権限をDatabricksに付与する必要はありません。たとえば、VPCを作成するためのアクセス許可は必要ありません。この制限された権限のセットにより、プラットフォームスタックでDatabricksを使用するための承認を簡単に得ることができます。
  • 簡素化されたネットワーク操作
    • ネットワークスペースの使用効率が向上
    • オプションで、CIDR/16 と比較して、ワークスペースの小さいサブネットを構成
    • 他のソリューションで必要になる可能性のある複雑な VPC ピアリング構成は不要
  • VPCの統合
    • 複数のDatabricksワークスペースで単一のデータプレーンVPCを共有可能
  • 発信接続の制限
    • データプレーンは Databricks ランタイムワーカからの発信接続を制限しない
    • お客様が管理する VPC を使用するよう構成されているワークスペースの場合、下りファイアウォールまたはプロキシアプライアンスを使用して、送信トラフィックを許可された内部、外部データソースのリストに制限可能 image.png

自分の VPC を利用するためのワークスペースの構成

VPC にワークスペースを構築するには、以下を実行する必要があります。

  1. VPC 要件に従い VPC を作成
  2. マルチワークスペースAPIを使用してワークスペースを作成するときに、VPC ネットワーク構成を Databricks に登録
  3. カスタマ管理 VPC を構成する(オプション)を参照

登録時に、VPC ID、サブネットID、セキュリティグループIDを提供する必要があります。

VPC の要件

Databricks ワークスペースをホストするには、以下の項目の要件を満たす必要があります。

VPC のサイジング

1つの AWS アカウントで、1つの VPC を複数のワークスペースと共有できますが、ワークスペース間でサブネット、セキュリティグループの再利用はできません。それに応じて VPC とサブネットのサイズの設定が必要となります。
Databricks はノードごとに管理トラフィック用と Apache Spark アプリケーション用に2つの IP アドレスを割り当てます。
各サブネットのインスタンスの総数は、使用可能な IP アドレスの数の半分に相当します。

DNS

VPC で DNS ホスト名と DNS 解決が有効になっている必要があります

サブネット

Databricks は、ワークスペースごとに最低2つのサブネットにアクセスできる必要があります。
各サブネットは異なるアベイラビリティーゾーンにおき、ネットワーク構成の作成 API 呼び出しでは、アベイラビリティーゾーンごとに複数の Databricks ワークスペースサブネットの指定はできません。
ネットワーク設定の一部として、アベイラビリティーゾーンごとに複数のサブネットを設定できますが、Databricks ワークスペースのアベイラビリティーゾーンごとに1つのサブネットしか選択できません。
各サブネットは/17と/25 の間にネットマスクを持っている必要があります。

セキュアなクラスタ接続のための追加要件

Databricks ワークスペースにセキュアクラスタ接続(パブリック IP または NPIP と呼ばれる)を使用する場合:

  • サブネットはプライベートであること
  • サブネットは、NAT ゲートウェイとインターネットゲートウェイ、またはその他の同様の顧客管理アプライアンスインフラストラクチャを使用して、パブリックネットワークへのアウトバウンドアクセスができること
  • NAT ゲートウェイは、クワッドゼロ(0.0.0.0.0/0)トラフィックをインターネットゲートウェイ、または他の顧客管理アプライアンスインフラストラクチャにルーティングする独自のサブネットにセットアップすること

サブネットルートテーブル

ワークスペースのサブネットルートテーブルは、適切なネットワークデバイスをターゲットとするクワッドゼロ(0.0.0.0.0/0)のトラフィックが必要です。

  • 安全なクラスタ接続の場合:クワッドゼロトラフィックは NAT ゲートウェイをターゲットにすること
  • 安全なクラスタ接続がないワークスペースの場合:クワッドゼロのトラフィックは、インターネットゲートウェイを直接ターゲットにすること

セキュリティグループ

Databricksは、少なくとも1つの AWS セキュリティグループにアクセスでき、5つ以下のセキュリティグループにアクセスできる必要があります。新しいセキュリティグループを作成せずとも既存のセキュリティグループを再利用することができます。

セキュリティグループは以下の設定が必要です。

  • 出口(アウトバウンド):全て許可
  • 入口(インバウンド):全てのワークスペースに下記のルールが必要(これらは個別のルールでも、1つのルールに結合することも可能)
    • トラフィックソースが同じセキュリティグループを使用する場合、全ポートで TCP を許可
    • トラフィックソースが同じセキュリティグループを使用する場合、全ポートで UDP を許可

安全なクラスター接続を使用していない場合でも、下記の設定は必要です。

  • ポート22および5557で Databricks コントロールプレーン IP アドレスからのすべての TCP を許可
    • ワークスペースデータプレーン(VPC)リージョンus-west-2とus-west-1:
      • 52.27.216.188/32:コントロールプレーン NAT インスタンス
      • 52.35.116.98/32:レガシー NAT インスタンス
      • 52.88.31.94/32:レガシー NAT インスタンス
    • ワークスペースデータプレーン(VPC)リージョンus-east-1:
      • 54.156.226.103/32:コントロールプレーンNATインスタンス
    • ワークスペースデータプレーン(VPC)リージョンus-east-2:
      • 18.221.200.169/32:コントロールプレーンNATインスタンス

サブネットレベルのネットワーク ACL

サブネットレベルのネットワーク ACL は、トラフィックへの入出力を拒否しないでください。Databricks は、ワークスペース作成中に次のルールを検証します。

  • 0.0.0.0/0 ソースからは全て許可
  • 0.0.0.0/0 へ全て許可

ファイアウォールアプライアンスインフラストラクチャ(セキュアなクラスタ接続限定)

セキュアなクラスタ接続を使用している場合は、イグレスファイアウォール、またはプロキシアプライアンスを使用してほとんどのトラフィックをブロックする必要がありますが、Databricks が接続する必要のある URL は許可する必要があります。

  • ファイアウォール、またはプロキシアプライアンスが Databricks ワークスペース VPC と同じ VPC にある場合は、トラフィックをルーティングし、次の接続を許可するように設定
  • ファイアウォール、またはプロキシアプライアンスが別の VPC またはオンプレミスネットワークにある場合、最初に 0.0.0.0.0/0 をその VPC またはネットワークにルーティングし、プロキシアプライアンスが以下の接続を許可するように設定

許可する設定内容:

  • Databricks Webアプリケーション
  • Databricks セキュアクラスター接続(SCC)リレー
  • AWS S3 グローバルURL
  • AWS S3 リージョンURL(任意で設定)
  • AWS STS グローバルURL
  • AWS STS リージョナルURL
  • AWS Kinesis リージョナルURL
  • テーブルメタストア RDS リージョナルURL(データプレーンリージョン別)

おわりに

Customer-managed VPC に関する内容の翻訳は以上です。
詳細な内容については、本記事をご参照ください。


Amazon Cloudwatch Anomaly Detection を使用したアラーム設定

こんにちは。
ナレッジコミュニケーション 繁松です。

最近、Amazon Web Services ブログで無人販売冷蔵庫プログラムの記事を拝見したのですが
処理のほとんどをLambdaで行い、何を購入したかの判断には機械学習の技術でカメラで撮影した画像から検出させ、機械学習のモデル作成にはAmazon SageMakerを使用しており、
冷蔵庫×クラウド&機械学習 というとても面白い内容となっていました。

■記事URL
https://aws.amazon.com/jp/blogs/news/smart-cooler/

 

本日は前回の続きで「Amazon Cloudwatch Anomaly Detection」を使ったアラームの設定と、実際に設定したアラームの発報状況について書きます。
ナレコムAIサイトを運用しているインスタンスに対し、CPU使用率のアラームの設定を行いました。

ほとんど通常のCloudWatchアラームの設定手順と同じで簡単に設定できます。

1.アラームの作成

CloudWatchから[アラームの作成]をクリック

2.メトリクスの選択

対象のメトリクスを選択し、[グラフ化したメトリクス]タブに移動
数式>異常検出>バンドの計算 を選択

するとAnomaly Detectionが設定されたメトリクスが表示されるので[メトリクスの設定]をクリック

3.メトリクスと条件の指定

しきい値の種類:異常検出
アラートの条件:バンドより大きい

今回はCPU使用率が異常検出の値よりも大きくなったときに発報させます。

異常検出のしきい値:10

様子見で異常検出のしきい値は10で設定します。
数字が大きくなれば、異常とみなす値の幅も広がります。

4.アクションの設定

アラーム状態とOK状態に通知が来るよう設定を行います。

5.アラーム名

アラーム名を入力したら、[アラームの作成]をクリックして完了です。

アラームの発報状況とメトリクス

7月14日6時0分 ~ 7月17日11時0分 の発報件数は12回。
異常検出のしきい値の幅が小さすぎたのか、思ったよりも多い発報だったので、しきい値の調整を行います。
青丸をつけているところが異常検出のしきい値の範囲内に収まるように調整してみます。
実際のグラフです。

異常検出のしきい値:10→15
変更後のグラフを確認すると、通知の必要のなさそうなアラーム発報の対象箇所が減りました。

アラームの発報を確認しながら異常検出しきい値の目安をきめていくのが良さそうですね。
メールを確認したところ、急なCPU上昇の場合は事前に通知が来ていることがわかりました。

AutoScalingと組み合わせるとより安定した運用が可能になりそうですね。


Amazon Cloudwatch Anomaly Detectionとは

こんにちは。
ナレッジコミュニケーション 繁松です。

本日は機械学習初心者でも簡単に導入、設定ができるAmazon Cloudwatchの異常値検知機能
「Amazon Cloudwatch Anomaly Detection」とはなにか、料金は、設定方法などについて書きます。

CloudWatch Anomaly Detectionとは

Cloudwatchメトリクス上の異常値を自動検出ができる機能です。

Cloudwatchアラームの閾値を設定する際に、どの閾値で設定するのが適正か悩ましいですよね。
平日と休日、日中と深夜、セール時期など閾値の設定は動的に行う必要があります。
そんな時にアラームをより効果的に使用するのに役立つ機能がCloudWatch Anomaly Detectionとなります。
CloudWatchの12000以上の内部モデルを持ち、機械学習により異常値(アノマリー)を自動検出できます。

実際のグラフです。

異常検出を設定したグラフでは、予期される値の範囲が予想値としてグレーで表示され、
グレーの範囲を超える場合は異常値として赤線で表示されます。

料金

標準解像度異常検出 アラームあたり 0.30USD

となっています。
標準解像度メトリクスで Amazon CloudWatch Anomaly Detectionを有効にし、5つのメトリクスにアラームを設定した場合の月額料金は、以下のように計算されます。

5つの標準解像度の異常検出アラーム = 標準解像度異常検出アラームあたり 0.30 USD * 5 つのアラーム = 月あたり 1.50 USD
CloudWatch の月額料金 = 1.50 USD/1 か月

CloudWatch Anomaly Detectionの設定方法

設定方法はとても簡単です!!!

  1. Cloudwatchメトリクスから設定したいメトリクスを選択します。
  2. Anomaly Detectionをオン!!

これだけです。

実際に弊社が運営する技術ブログサイト(本サイトです)で確認してみたいと思います。
今回はCPU使用率に設定してみます。

メトリクスを選択し、波線の箇所をクリック。

これだけで、機械学習で予測した予想値と異常値が確認できます!

トレーニングから取り除きたい期間がある場合は、モデルの編集から除外する期間を指定します。

次回、アラートの設定手順と、実際のアラート発報状況について記載していきます。


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-5fc3246f3a49c114636594/]

解析結果

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

まず一番、多いのが 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 コンピテンシー認定のナレコムが導入から活用方法までサポートします。お気軽にご相談ください。

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