フレクトのクラウドblog re:newal

http://blog.flect.co.jp/cloud/からさらに引っ越しています

フレクトが行くAWS re:Invent 2019 (12/4)

みなさんこんにちは。技術開発室の岡田です。

現在ラスベガスで絶賛開催中のAWS re:invent2019に参加しています。 昨日のキーノートでは怒涛の新サービス発表がありましたね。 特に私の担当している機械学習関連では、SageMakerの新サービスが多く発表され、スーパーエキサイティングな1日になりました。 興奮醒めやらぬ状況ではありますが、この発表をうけて新たに追加されたセッションも含め、本日までに参加できた機械学習関連のセッションについて、ご報告したいと思います。 (ちょっと専門用語が多めになります。)

ちなみに、今日も朝ごはんと昼ご飯は提供されました。😊

キーノート振り返り

f:id:Wok:20191205053101j:plain

昨日のキーノートでは、レイヤごとに次の新サービス・機能が発表されました。

  • Framework

    • TensorFlow: 20%高速化(MASK R-CNN)
    • PyTorch: 22%高速化(同上)
    • mxnet: 22%高速化(同上)
  • SageMaker

    • SageMaker Studio IDE: 以下のものを含むMLのための統合開発環境
    • SageMaker Notebooks: 起動の高速化や、コンテナ管理と連動できるように拡張したNotebook
    • SageMaker Experiments: 実験ごとのパラメータや設定を管理
    • SageMaker Debugger: トレーニング中に発生した問題をリアルタイムに特定
    • SageMaker Autopilot: トレーニングに最適なパラメータを探索
    • SageMaker Monitor: 運用中のモデルの精度をモニタリング
  • Service

    • Amazon Kendra:検索
    • Amazon Fraud Detector: 不正検知
    • Amazon Cloud Guru: コードレビュー
    • Contact Lens:コールセンタ向け

これらに関連して追加されたセッションのうち、本日までに次のものに参加することができました。

  • Optimizing Your Machine Learning Models on Amazon SageMaker
  • The new Amazon SageMaker Model Monitor: Address concept drift & model quality
  • Intro to Amazon SageMaker Debugger: Get insights into ML model training
  • Introducing Amazon SageMaker Studio, the first full IDE for ML

また、関連して次のものもセッションに参加しました。

  • Leadership session: Machine learning

Optimizing Your Machine Learning Models on Amazon SageMaker

機械学習モデルをトレーニングするときのパラメータをSageMaker Autopilotを用いて自動でチューニングして、よりよいモデルを作成するワークショップです。

パラメータチューニングの方法にはグリッドサーチやランダムサーチを使うことが多いですが、SageMaker Autopilotはガウス過程回帰とベイズ最適化を用いてパラメータを探索します。また、ここでチューニングできるパラメータは一般的なハイパーパラメータに加え、機械学習アルゴリズム自体も自動で選択してくれます。さらに、Feature Engineeringも実施してくれるようです(!?)。探索の結果いくつかの候補を出してくれるので、(一般的には)もっともよいメトリックのモデルを選択する、ということになります。

ただ、やはり会場ではパラメータチューニングに伴って発生する料金についての質問が出ていました。パラメータチューニングするためには何度もトレーニングを実施する必要があり、大量の計算リソースを必要としますので、当然の懸念だと思います。そして回答も至極当然の回答で、探索(トレーニング)にかかった時間だけそのインスタンスの料金を払うことになるよ、とのことでした。大きなモデルに使うと結構な料金がかかってしまうのではないかという不安はありますね。ただ、グリッドサーチよりも少ないイテレーションでより良いパラメータを見つけてくれる期待はあるので、グリッドサーチをやる前提であるのであれば、代わりにこちらを使った方が安上がりになる可能性もあります。また、あまり機械学習に詳しくない人にとっては、ほぼ全自動でモデルの性能を向上させることができるという点は見逃せません。このため結構使われるのではないかと思います。とても期待のできる機能だと思いました。

このワークショップで用いたノートブックは下記のgithub上にあります。 実行する際には使用したリソースの料金が発生しますのでご留意ください。

なお、このノートブックのLab2を実行すると、Autopilotで作成したパラメータの候補の一覧を中間生成物のノートブックで見ることができます。残念ながらワークショップで利用した環境のものはすでに消されてしまったようで詳細確認できなくなってしまいましたが、記憶だとFeature Importanceなど使ってしっかりFEしてたような気がします。いや、すごい。

The new Amazon SageMaker Model Monitor: Address concept drift & model quality

SageMaker Model Monitorのセッションです。

concept driftは、ざっくり説明すると、モデル作成中に想定した世界が時間の流れとともに変化し、モデルが現実世界に対応できなくなることです。一般的には、上記のAutopilotのようなことを行い、モデル作成の際に与えられたデータを用いて、そこで(汎化性能も含た)最高の性能を出せるようにチューニングします。しかし、時間とともに取得できるデータのばらつきが変わるため、徐々に性能が劣化していきます。例えば、温暖化の影響を受けて天候が変わるとか。最近の日本の気候もだいぶ変わったように思いますよね。このため、モデルは作成時点が最も精度が高く、徐々に劣化していくといわれたりします。

Model Monitorはこの劣化度合いをモニタリングして、一定の条件に至るとアラートを上げる機能とのことです。ただ、今回の説明を聞く限り、この劣化を検知するための条件は、(Model Monitorがリコメンドしてくれるようですが、最終的には)モデル開発者が決める必要があるようです。下図のBaseline statistics and constraintsのところですね。このため、ちょっと機械学習の知識がないと敷居が高いのではないかという印象でした。Autopilotで自動でモデルチューニングした後にこの条件を作成し、その良しあしを判断ができるのかが気になるところです。 f:id:Wok:20191205184705j:plain

とはいえ、concept driftの話はFLECTが扱っている案件でも話題になりますので期待したい機能です。

Intro to Amazon SageMaker Debugger: Get insights into ML model training

SageMaker Debuggerのセッションです。

大規模なモデルを作成した経験をお持ちの方であればお分かりになると思いますが、モデルのトレーニングにはかなりの時間がかかります。なので、トレーニングを開始したら数日放置しておくということもあると思います。そして数日後にトレーニングが完了したモデルを確認すると期待したほどの精度向上がなく落ち込むと。このような悲劇を回避するためにTensorflowであれば、TensorBoardを用いたりCallbackをうまく使って通知を上げたりするのが一般的かと思います。ただ、これを行うためにはモデル開発のコードを修正する必要があり、かなり神経を使います。Sage Maker Debuggerはコード変更することなくトレーニング時の異常をリアルタイムに検知、報告してくれる機能とのことです。

f:id:Wok:20191205192023j:plainレーニング中に作成されるデータ(おそらくチェックポイント)をS3に保管しし、逐一それを解析する処理を起動するという感じでしょうか。 確かに、デバッグコードをモデル開発のコードに直接書くと見通しが悪くなったりしがちなので、そういう意味で地味にありがたい機能だと思います。

Introducing Amazon SageMaker Studio, the first full IDE for ML

SageMaker Studioのセッションです。

SageMaker Studioは、今回発表のあった各種機能を取り込んだ機械学習モデルの統合開発環境となります。

図のような繰り返し開発を行うときに活躍します。 f:id:Wok:20191205185115j:plain 左の箱のBuildフェーズはNoteBooksを使ってAutopilotでチューニング、Debuggerでデバッグしながら中央の箱と行ったり来たりのイテレーションを行う。このイテレーションはExperimentsで管理され、最終的にはソリューションとして最適なモデルをデプロイできる。デプロイした後はMonitorでコンセプトドリフトを監視して問題があれば再度モデルを作り直す。という流れになるかと思います。

こう考えると、さすが機械学習開発プロセスを熟知しているAWSの統合環境だなと思いました。 おそらくここまで機械学習のモデル開発の流れに合わせて機能を組み込んだ開発環境は見たことがないので、今回のSageMaker Studioの発表で開発プロセスが一段レベルアップした感じです。 今後、Google, MSといった他社の出方が気になります。

Leadership session: Machine learning

本セッションはキーノートの直後に実施されたものです。基本はキーノートの発表に沿ったものが説明されましたが、キーノートでは語られなかっ た情報もありました。

一つ目がDeep Java Library(DJL)です。

Java開発者にend-endの機械学習開発APIを提供するようです。 従来AWSのForecasting teamでは、データサイエンティストチームがPythonを用いて作成したモデルを、Javaで開発しているML Infraチームが数週間かけてリファクタリングして使っていたのだそうです。多くのエンタプライズサービスはJavaで書かれているのだから、このコストはいろんな開発現場で発生しているはず。そこでDJLを使って初めからJavaで作成しておくことで、このコストを削減するということのようだ。 実際に、AWSのForecasting TeamはDJLを使うことで開発期間を30%削減できるようになったそうです。 f:id:Wok:20191205201741j:plain

確かにPython,特にJupyterNotebookで作成するコードはそのまま使えないことは、私もよく経験することなので、なるほどなとは思いました。

二つ目はSQL for MLです。 下図の例では、Amazon Aurora Amazon SageMaker, Amazon Comprehendと連携して、リアルタイムで推論結果を返します。 f:id:Wok:20191205193559j:plain まぁ、そういう流れになるだろうなという範疇ではあります。個人的にはSQLがあまり得意ではないので、DBという形すら取らずに、すべて自然言語でDBからAIからすべてのデータソースをクエリできるようにしてほしい。

さいごに

以上が私が参加した機械学習のセッションのご報告となります。 FLECTは明日が最後の参加日となります。そして、明日はキーノートがあります。また何か大きな発表があったら、さすがに体力が持たないかも。 どこかの会社様は数十人体制で来てるとのこと。大当たりでしたねー。今回のような大幅アップデートを4人で捌くのは正直きつい。 来年は偉い人にお願いして増員してもらうかな。そして私は来年も来たいなー。 ということで最終日。頑張って楽しんできます!では、おやすみなさい。(こちらは午前3時。)

フレクトが行くAWS re:Invent 2019 (12/3)

みなさん初めまして、CI事業部のウエダです。 今回が初のre:invent参加となります。

業務ではAWSは絶賛利用中で、日々AWSの新しい機能を学びそれを業務に反映し良いサイクルを回すことを心がけております。

海外のイベントともあり戸惑うことはありますがre:invent中は刺激的な毎日を過ごしております。

初めての朝食

f:id:flect-ueda:20191204160641j:plain

美味しそうな料理で迷いますが、連日の食事のボリュームで胃がもたれ気味だったのでコーヒーとマフィンだけの軽い食事で済ませました。

怒涛の新サービスラッシュ

1日目の発表に物足りなさを感じていた身としては嬉しい悲鳴です。

現地から社内へSlackで現地の状況を共有しているのですが、最初から最後まで休まるところがなかったです。

個人的には業務に直接関係のある、インスタンスタイプの追加、Amazon EKS on AWS Fargate、Amazon S3 Access Points、Amazon CodeGuru辺りが気になりました。 f:id:flect-ueda:20191204152455j:plain

早く情報を収集して使いこなせるようにならないと思いきや、幸いなことに、新サービス用のセッションが追加されました。 スケジュールの組み直しで大忙しです。

SageMaker、RedShiftのサービスが劇的に増えたので、そろそろ本腰を入れて機械学習とBigDataに力を入れないと、、、 f:id:flect-ueda:20191204162051j:plain こうして見ると改めて今回のSageMakerのサービスの充実具合が分かりますね

説明がひと段落したタイミングでバンド生演奏でこれまでの説明内容に沿った曲が流れ最後に歌詞が表示される演出はよかったですね。 f:id:flect-ueda:20191204152500j:plain 発表の内容によっては演出過剰でシラけてしまうリスクがありますが、今回発表のあったサービスはどれも期待以上のものなので、会場の盛り上がりがすごかったです。

帰国したら、既存のシステム構成をまた見直さないと、、、

ワークショップに参加

セッションだとどうしても受け身になりがちなので、せっかくチャンスなのでジャンルは問わず様々なレベルのワークショップに参加しています。

やはりワークショップだと実際に手を動かすので記憶に残りやすいですね。

気になる費用や、面倒臭いVPCなどの下準備は専用のアカウントを発行してくれるのですぐに課題に取りかかることができ有意義な時間を過ごせました。

最高レベルの400番台のものも参加し、時間が厳しいのでタイムアウトとなってしまいましたが、何をやっているかは理解できていたので日々の実務の成果が確認でき感慨深かったです。

とはいえ言語の壁が難しいですね。今の私のレベルでは聞きとるところまでで精一杯です。

こちらの意図を言葉で表せないないのがもどかしいです。精進しなけば、、、

AWS DeepComposerの実機をGET

Midnight Madnessで発表のあったDeepComposerです。 サービス発表時に現場の盛り上がりを目の当たりにしただけに、なんとかワークショップに参加して無事実機を手に入れることができました。 f:id:flect-ueda:20191204162515j:plain 自分の拙いピアノ演奏した曲を簡単な操作でJazz調、Rock調のちゃんとした曲になるのは興味深かったです。

ワークショップの後、別会場で実機を受け取るのですが、みんな気になるのか、その箱の中は何かと複数の人から聞かれました。

SalesforceブースでAWSのTrailheadを実施

f:id:flect-ueda:20191204160406j:plain スタンプラリーで2つ以上集めるともれなくグッズをもらえるということでやってみました。

先日のdreamforceで発表のあったAWSのトレイルと実施してコーディのぬいぐるみをGETしました。

まだこれからどんな発表があるか分かりませんが、残る期間も楽しんで挑戦したいと思います。

Heroku のアドオン「Sqreen」で簡単にWAF!

こんにちは。エンジニアのヤス・コバヤシです。

Heroku Advent Calendar 2019 5日目を担当させていただきます!

qiita.com

Webアプリケーションを開発するにあたって気をつけなければいけないのはセキュリティ対策ですよね。

OWASPトップ10とかブルートフォース攻撃(総当たり攻撃)とかアカウント乗っ取りとか、脆弱性を悪用した攻撃にどう対処していくかは悩みどころです。

いくらWEB APIREST APIの仕様に沿ってガチガチにガードしたと言っても、それはその攻撃自体をWebアプリケーションの中で受け止めてチェックすることになるので、フレームワークやライブラリに脆弱性があったらひとたまりもありません。

ですのでWebアプリケーションに届く前にガードする必要があるわけですね。

それが皆さんご存知のWAF(ウェブアプリケーションファイアウォール)になります。

ところでこのWAFですが、AWS には AWS WAF 、Azure には Azure Web アプリケーション ファイアウォールと言うものがありますが。。。

HerokuにはWAFがあるの?

あります!

それが「Sqreen」です。 elements.heroku.com

と言う事で今回は Heroku のAddOn「Sqreen」のご紹介をしたいと思います。

「Sqreen」ってどんな感じ?

構築する前に「これはどんなアドオンなの?どんな機能があるの?」と気になる事かと思います。

画面をお見せしながらご紹介しますね。

f:id:yasuyuki-kobayashi-flect:20191203165038p:plain
Monitoring画面

「Sqreen」はリアルタイムで攻撃をブロックし、セキュリティ状況を可視化してくれます。 これがメイン画面とも言えるMonitoring画面です。

f:id:yasuyuki-kobayashi-flect:20191203165325p:plain
Settings画面

設定画面では攻撃があった時にどんなHttp Statusで返すかと言う設定ができたり、IPアドレスによるガードや受け入れを設定できるブラックリストホワイトリストの設定もできたり、

f:id:yasuyuki-kobayashi-flect:20191203170055p:plain
Integrarion画面

攻撃があったりした時に通知する先も設定できて、先日Heroku NewRelic APMを始めよう!でお伝えしたNewRelicやSlackへの通知、WebhookでPOST先を指定する事もできます。

f:id:yasuyuki-kobayashi-flect:20191203170720p:plain
Alertモード画面

もちろんメールでの送信も可能。

また緊急度(高/中/低)によって通知も「直ちに」「1日のダイジェスト」「1週間のダイジェスト」と設定できます。

このように「Sqreen」はフレキシブルに設定できるので、アプリケーション運用時には頻繁にSqreenコンソールに確認に行かなくても良いし、大したことのないセキュリティアラートで深夜に起こされる、呼び出される事もないです(笑)。

f:id:yasuyuki-kobayashi-flect:20191203171739p:plain
WAFルール画面

そしてWAFですが、デフォルトで50ものルールがすでに設置されています。

「Sqreen」を構築しただけですぐにWAFが機能するのは嬉しいですね。

もちろん御自身のルールを追加する事も可能ですし、既存のルールをどのように扱うか(”何もしない”とかも)をコントロール可能です。

f:id:yasuyuki-kobayashi-flect:20191203171649p:plain
WAF画面

またいくつかのルールに引っかかるようなアクセスをしたIPは「15分間遮断する」と言った、攻撃者を諦めさせる嬉しい機能も!

その他の機能

「Sqreen」はWAFだけの機能じゃないです。

f:id:yasuyuki-kobayashi-flect:20191203173927p:plain
Protections

「クリックジャッキング」「クロスサイトスクリプティング」「MIME Sniffing」と言ったクライアント側のセキュリティ保護対策、そして自身のアプリケーションの脆弱性までチェックして教えてくれます。

Webアプリケーションの中も外もしっかり保護してくれる、もう至れり尽くせりですね。

そしてWebアプリケーションに「Sqreen」を搭載した成果が!

「で、このSqreenってやつは本当にガードしてくれるの?」と半信半疑な方もいらっしゃるのではないでしょうか。

我々が構築したWebアプリケーションに「Sqreen」を搭載したんですが、

f:id:yasuyuki-kobayashi-flect:20191204112759p:plain
インシデント画面
なんとウクライナ(またはウクライナ経由)の攻撃を見事にガードしてくれました!!

「Sqreen」は攻撃者の位置をIPアドレスから逆探知もしてくれるんですよ。

すごくないですか。

構築方法は?

皆さんいかがでしたか? 「Sqreen」なかなかの高機能でしょ。 プランは無料からもありますのでこれをアドオンしない理由はありませんよね。

さて最後に「Sqreen」の構築方法ですが、

f:id:yasuyuki-kobayashi-flect:20191204093758p:plain
AddOn
アドオンしただけではすぐには動きません。 Webアプリケーションを守るために「Sqreen」を関連づける(dynoの中で「Sqreen」監視プログラムを動かし「Sqreen」本体に認識させる)ことが必要です。

この設定方法に関しては皆さん様々な言語でWebアプリケーションを構築していると思いますので、私が説明するよりこちらをご覧ください。

devcenter.heroku.com

英語ですけどブラウザの翻訳機能(最近はかなりいい感じに翻訳してくれるようになりましたよね)を使えば簡単に読んで理解できますよ。

それではみなさん、「Sqreen」を搭載して"ハッピーHerokuライフ"をお過ごしください!

フレクトが行くAWS re:Invent 2019 (12/2)

f:id:Wok:20191203190754j:plainみなさんこんにちは。技術開発室の岡田です。

現在、ラスベガスではAWS re:invent2019が開催されていますね! 今回のre:inventには、弊社から西中、上田、尾野、岡田の4名のエンジニアが、昨日よりラスベガス入りをして参加しております。

前回までの私の投稿は機械学習に関連する記事ばかりでしたが、 今回は私もre:Invent 2019に参加していますのでこの様子をご報告しようかと思います。 本投稿では、本格的にセッションが開始される12/2の様子をご報告します。 なお、上田もAWS re:invent2019に関するブログを投稿予定ですので、そちらも併せてご覧いただけますとありがたいです。

さて、少し振り返ると、昨日の夜にはMidnight Madnessというパーティがあり、その中で新製品が発表されるという驚きの展開がありました。 はたして、Keynoteがある本日はどうだったでしょうか。参加報告として、大まかに時系列に沿って報告をしたいと思います。

セッション開始の日は朝食が出ない

いきなり技術的な話じゃなくてごめんなさい。ですが、今回はこの調子で進めます。 出発前、前回の参加者やWeb上の話によるとイベント開催中の朝食と昼食はイベント会場内で準備されるとのことでした。 このため、朝食の準備は特に考えず会場に向かったのですが、食事を食べる場所は特に案内されておりませんでした。 どうも今回はセッション開始の日は朝食が出ないようです。そして、食事が出る場合は公式のページにしっかりと記載されていますね。 完全に情報収集不足でした。12/2はランチは出ますが朝食は出ないようです。 f:id:Wok:20191203171159p:plain

https://reinvent.awsevents.com/schedule

ということで、会場の一つであるベネチアンホテルの中にあったショップで軽食を購入して凌ぐことにしました。 後述しますが、このre:inventというイベントの恐ろしいところは、その会場の大きさです。 戦いきるためには適切にエネルギーの補充がかなり重要となりますので、ここで食事が取れてよかったです。

写真は、順番待ちしていた私を元気よく呼んでくれている店員さんの図。 f:id:Wok:20191203190754j:plain

会場間の移動は40分、会場内の移動はプラス20分

前提知識として知っておいていただきたいのが、re:inventのイベント開催エリアの大きさです。全体像はこちらのURLで示されています。 https://reinvent.awsevents.com/around/campus_overview/

googleマップで距離を測ってみると端から端までで3Kmくらいあります。人間の歩行速度は大体時速4Kmといわれていますので、40分くらいの行程です。 実際参加者3人がそれぞれ歩いて時間を計ってみましたが、やはり全員40分くらいかかっていましたのでそのくらいだと思っておけばいいと思います。 そして、各会場はホテルなのですが、中にカジノが併設されているホテルでとにかくでかい。単純に地図上の大きさだけでもでかいとわかると思いますが、 そのうえ建物内の壁やフロアの概念があるから実際の移動距離はもっと多くなります。とにかく移動が大変。 MGMというホテルでは、入り口から一番遠いと思われる会場まで歩いて20分ほどかかりました。 (実際にその会場でのセッションに参加しました。)

Finding a needle in a haystack: Use AI to transform content management

一つ目のセッションとしてこちらに参加しました。 本セッションでは、非構造化データをSagemakerの機能を用いて構造化できる情報として変換し、それを他の処理に利用することで業務効率を向上させる、という話がなされました。 彼らが提案する参照実装はこちらです。 f:id:Wok:20191203190927j:plain S3に入れた非構造化データをlambdaを経由してAmazon Textract、Amazon Transcribe、Amazon Translateで標準化し、Amazon Comprehendで分析して、検索エンジンに利用したり、グラフDBにして関連性を定義したり、その他機械学習に用いたりするという形になっています。

そして、これの実際の例として、資本家向けに会社の安全度を分析する会社がやっているメール分析処理を取り上げて、その内容と効果が説明されました。 f:id:Wok:20191203190202p:plain S3上のメールのContent部分をAmazon SageMakerを用いてノイズ除去を行い、Attachments部分からテキストを抽出する。その結果をAmazon Comprehendで処理することで必要な情報を抽出しています。 このような処理を行うことにより、従来行っていたメール分析の時間を60%短縮できたそうです。

私も機械学習を主に担当しているため、AIにより作成された100%確実とは言い切れない情報をどのように活用していくのかは興味がある内容でしたのでとても参考になるセッションでした。

セッション開始の日でも昼食は出る。

昼食はしっかりと準備されていました。大きな会場でビュッフェ形式で食べるか、バッグに詰められた昼食セットをもらって任意の場所で食べるかを選べました。 私は、温かいご飯がべたかったのでビュッフェ形式で食べました。豆のスープがとてもおいしかったです。デザートもあって満足満足。 f:id:Wok:20191203191309j:plain f:id:Wok:20191203192228j:plain

腹ごなしに40分歩く

昼食をとったのがベネチアンホテルで、次のセッション会場がMGMだったため、イベント開催エリアの端と端になります。 シャトルバスも出てはいるのですが、ちょうど時間も空いていましたので、歩いてみることにしました。 予想通り40分かかりましたが、途中にはM&M'sのお店があったり、 Hersheyのお店があったりで、甘いもの好きにはなかなか目を楽しませてもらえる通りになっています。 昼間に大通り(Stripと呼ばれるらしい)を歩いている限りは特に危険な感じもなかったです。(自己責任でお願いします。)

Get started with AWS DeepRacer

二つ目は、DeepRacerのワークショップに参加しました。 前回のre:inventなど、他のイベントでもこのワークショップは開催されてきていますが、今回新たにGrageという機能が追加されました。 Grageでは主に次のことができるようになります。

一つ目のセンサーの種類ですが、従来一つのカメラがついていましたが、二つのカメラを搭載し、ステレオカメラとして使って深度を図ることができるようになります。また、より高精度に深度を計測できるようにLIDARをアドオンすることができます。LIDARは可視光で距離などを図る技術だったかと思います。(全然専門じゃないので違ってたらごめんなさい。一応Wikiを載せておく。LIDAR - Wikipedia) 二つ目のニューラルネットワークの構成は、従来DeepRacerで使われているCNN*1のレイヤ数を変えるというもの。増やせば精度向上が期待できるが、トレーニング、推論の時間が延びてしまうというデメリットがある。

今回のワークショップでは、上記のGrageの設定や他の設定については、トレーニング時間が短くなるものを選択してモデルを作成してみるというものでした。ベースラインのモデルとして簡単に作れることがわかるようになります。ここまでできれば、先ほどのパラメータをチューニングしてさらなる高みを目指すことができそうです。今回使われたリソースは下記のgithubに上がっていますので興味のある方はのぞいてみると良いかと思います。なお、トレーニングにはAWSのアカウントが必要で、使用したリソースに対する料金も発生するのでその点はご留意ください。

github.com

The Quadに参加

今回のre:inventでは、ExpoとThe Quadの二つの展示会場があります。 今回はDeepRacerのワークショップ会場に近いほうのThe Quadを見てきました。 Smart家電の専用ブースができていたり、RoboMakerのブースがあったり、情報技術をハードウェアと連動させる技術が多くみられたように見える。 f:id:Wok:20191203193630j:plainf:id:Wok:20191203193550j:plain f:id:Wok:20191203193729j:plain

ちょうどこのタイミングでWelcome Receptionが行われていたので、料理とお酒が提供されていました。わたしはマカロンなどを頂きました。おいしい。

f:id:Wok:20191203193811j:plain f:id:Wok:20191203193837j:plain

ML in retail: Solutions that add intelligence to your business

三つ目のセッションにMachine Lerningをretail業界に導入する勧めのセッションを聞いてきました。 大きく次の2点をデモを交えながら説明していました。

  • 需給未来予測によるプロセスの効率化(プロセス改善)
  • パーソナライゼーション、推薦システムによるユーザ体験の向上 f:id:Wok:20191203195755j:plain

この内容自体は理にかなっているとは思いますが、ずいぶん前から言われてきたことで、あまり目新しいことはないなという印象を受けてしまいました。 上記を実現するためのGUI&AIのデモを見せてもらえたのが目新しいところかもしれませんが、一つ目のセッションのように具体的な事例をあげての説明よりはだいぶ説得力に欠けていたかな。

シャトルバスは渋滞にはまるリスクがある

キーノートを聴講するために、昼食をとった場所ベネチアンホテルに戻ります。さすがに40分歩く体力がなかったのでシャトルバスに乗りました。 しかし、シャトルバスが通る道は結構渋滞するらしくかなり時間がかかってしまいました。多分歩いたのと同じくらい時間がかかっていると思います。 結局キーノート開始のギリギリ25分前についてぎりぎり間に合いましたが、かなりはらはらしました。 f:id:Wok:20191203193947j:plain 渋滞のリスクを考えて、余裕を持ってシャトルバスを利用したほうがよいですね。

Monday night live

キーノートとliveが組み合わさったセッションです。 開始時間はキーノートの時間であり、その前からライブは開始されていたようです。 25分前にベネチアンホテルに到着したのち、会場までやはり10分くらいかかったので、15分前にようやく会場入りすることができました。 大きなホールが会場になっており、巨大な壁面ディスプレイ5~6枚が連なっているステージになります。 ライブ自体はその端のほうでやっており、聴講者は会場に到着した順番に逆の端から席に座るシステムだったので、最後のほうに到着した結果バンドの真ん前が席になりました。 とってもかっこいいバンドだったのですごいラッキーでした。(名前知りたい。後で調べよう。) f:id:Wok:20191203194008j:plain

さて、キーノートの内容ですが、今回は Re:Invent Super Computerという名でHPC向けのクラウド環境を提供する発表がなされました。聞いている感触だとHPCを実現するためのインフラの提供という感じです。いくつか課題というか要件というかがある中でそれぞれの施策を提供できるようにAWSが準備しているという説明。例えば、非効率なTCPをEFAに変えることでスループットを向上させることができる。システムをチップに最適化することでスケーラビリティを確保できるようになっている。特定のVM/コンテナにハードウェアを占有させ不要なオーバヘッドをなくすなど。これらをまとめ上げれば、Re:Invent Super ComputerとしてHPCのタスクに十分な性能を持つVM・コンテナが生成できるということではないかと理解した。 f:id:Wok:20191203195940j:plain f:id:Wok:20191203200010j:plain f:id:Wok:20191203200042j:plain

また、環境保護プロジェクトを進めていて、パリ協定を10年前倒しする後押しをするという話もあった。 f:id:Wok:20191203201850j:plain f:id:Wok:20191203201921j:plain

一見すると、高性能なコンピューティングと環境にやさしいコンピューティングは、トレードオフの関係にも見えて、両立は難しそうだなぁと思いましたが、 AWSは、もちろん計算効率を上げて電力消費を削減する方法も考えているとは思いますが、今回大々的に発表したのはそれではなく、環境にやさしい発電方法で環境を守るという大きな視点からの取り組みのことでした。電力消費がーとかいっても、そもそもクリーンに電力を供給できてればいくらでも使っていいじゃないか、ということ(言い過ぎ)。やはりGAFAはスケールが違うなぁ。

以上が、12/2の報告内容です。

次回は、また機械学習の記事に戻るか、もしかしたらもう一回re:inventの内容を報告するかします。 ではまたよろしくお願いします。 (やばい、やばい、早く寝ないと明日のキーノートに寝坊する。ということで、誤字脱字、変な文章ご容赦を。)

*1:こちらは専門ですが、以前のブログで書いているのでここでは説明しません。そちらを見てください。[http://cloud.flect.co.jp/entry/2019/07/08/134938

Apexからレポートを実行しCSVで出力する

エンジニアの藤野です。

Salesforceの主要な機能の一つであるレポートは、Apexから実行することもできます。 公式のドキュメントとしては下記のものなどがあります。

この記事では一例として、レポートの実行結果をCSVとして出力するコードを実装し、解説します。

実行環境は下記のとおりです。

使用するレポート

レポートの題材として、Trailheadのレポートの形式設定の「マトリックスレポート」で作成している「Revenue Trend by Type」レポートを使用します。

これは行、列ともにレベル1のグルーピングを行うマトリックスレポートです。

ゴールと出力例

適当なレコードを作成し、「Revenue Trend by Type」レポートを実行しました。

レポート実行結果
レポート実行結果

これに対して、ゴールは下記のCSVを出力することです。 CSVファイル名はレポート名をそのまま使うものとします。 また、詳細は出力しません。

Revenue+Trend+by+Type.csv:

完了予定月,種別,-,Existing Customer - Upgrade,Existing Customer - Replacement,Existing Customer - Downgrade,New Customer,合計
2019/01/01,金額 合計:,0.0,0.0,0.0,0.0,1.0E7,1.0E7
2019/02/01,金額 合計:,0.0,0.0,0.0,2000000.0,0.0,2000000.0
2019/03/01,金額 合計:,880000.0,0.0,0.0,0.0,0.0,880000.0
2019/05/01,金額 合計:,0.0,0.0,5000000.0,0.0,0.0,5000000.0
2019/07/01,金額 合計:,0.0,0.0,0.0,0.0,0.0,0.0
2019/08/01,金額 合計:,0.0,0.0,0.0,100000.0,0.0,100000.0
2019/09/01,金額 合計:,0.0,2.0E7,0.0,0.0,0.0,2.0E7
合計,金額 合計:,880000.0,2.0E7,5000000.0,2100000.0,1.0E7,3.798E7

また、このCSVExcelでそのまま表示できるものとします。

Excelで表示した状態:

CSVをExcelで表示
CSVExcelで表示

続きを読む

Heroku NewRelic APMを始めよう!

こんにちは。エンジニアのオクダです。今回のテーマは「Heroku NewRelic APMを始めよう!」です。

必要最小限の工数でNewRelic APMを利用する方法についてご紹介いたします。

Heroku NewRelic APMとは

まず最初に、Heroku NewRelic APMとは、ということで、 この章では、Heroku NewRelic APMで何ができるか? ということについて説明します。

NewRelicで何ができる

サーバーの監視に必要なことは一通り揃っています。 死活管理も追加できます。その場合、New Relic Syntheticsを利用することになります。 ジョブの状態が分かるので、ジョブの謎の死にも気づける可能性もあります。 モニタリングに必要なスクリプトAPM agentが自動で注入してくれるので、設定は不要となっています。 インフラ監視用のNew Relic Infrastructureもありますが、別途料金が発生します。

Heroku NewRelic APMについて、ご説明

NewRelic APMはアプリケーションパフォーマンス監視ツールであります。HerokuにはNewRelic APMがAdd-onsとして用意されています。 SaaSビジネスにおいて、顧客ごとにactivity, 品質保証(SLA), 業績評価(KPI)を監視したいというニーズがあります。

NewRelic 活用事例

使用した模擬的弊社のサービス実装、について説明します。

実装の経緯

模擬的にシステムを作り、データを再生して流し込み、 NewRelicでどんなことができそうか探索してみました。

模擬的実装

使用した模擬的Architectureです。 f:id:flect170:20191118150949p:plain Google BigQueryからデータをamazon Kinesisに送信

amazon KinesisからAmazon DynamoDBに時間ごとに送信

Amazon DynamoDBで受信したサブスクリプションIDやデバイスIDを保存

ClientはAmazon EC2を使用して、Amazon DynamoDBに保存されたデータを取得します

New Relicでそれぞれの経路のトランザクションを確認します

やりたいこと

顧客ごとの「システム健全度」をレポートします。 例えば、Google BigQueryに蓄積されたデータから、顧客毎のDynamoDBへの書き込み処理にどれくらいの所要時間を擁しているか? 全ての書き込み処理が正常に行われ終了しているか?を確認します。

実現方法

Custom Parameterを活用します。 NewRelicではカスタム属性を設定する事により、遅かったり失敗したりしたリクエストに関連するカスタム属性(顧客ID、デバイスID)を追跡することができます。 例えば、顧客ID毎に応答時間を計測できれば、顧客に対する品質保証を証明できたり、デバイスID毎に応答時間を計測できれば、雇用者の業績評価の指標に利用したりできます。

NewRelic APMの使用方法

ここでは、NewRelic APMのインストール アプリケーションの編集について、説明します。

NewRelic APMのインストール

NewRelic APMのインストール画面です。 f:id:flect170:20191118131842p:plain Heroku Add-onsより、NewRelicを追加すると、Install the agentページに移動します。(今回のプロジェクトはPython) 指示通り、Get your license keyで、ライセンスキーを取得します。 Install the NewRelic agentでnewrelicをインストールします。 Generate the configuration using license keyで、先ほど取得したライセンスキーに置き換えて、newrelic.iniファイルを生成します。

NewRelicのデータって?

NewRelicの世界では「トランザクション」が、送信データの1行に相当します。(以下NRTと表記) Webリクエストなどは自動的に一つのNewRelicトランザクションと認識してくれます。 バックグラウンドジョブでは、明示的にNewRelicトランザクションがどの単位になるのか、定めなければなりません。 background taskを明示的にコードで宣言する必要がある。

Custom Parameterとは

NewRelicトランザクションに任意につけられます 設定方法は 既存のアプリケーションコードに、NewRelicのライブラリをインポートします。

import newrelic.agent

エージェントの初期化で、先ほど作成したnewrelic.iniを読み込みます。

import newrelic.agent

あとは、監視したいところにCustom Parameterのキーと値を追加していくのみです。

    application = newrelic.agent.application()
    with newrelic.agent.BackgroundTask(application, name='put_item', group='Task') as tr:
        tr.start_time = starttime
        tr.add_custom_parameter('Subscriptionid', json_dict['Subscriptionid'])
        tr.add_custom_parameter('Deviceid', json_dict['Deviceid'])
        tr.add_custom_parameter('latitude', json_dict['latitude'])
        tr.add_custom_parameter('longitude', json_dict['longitude'])
        tr.add_custom_parameter('Process', 'DynamoDB')
        tr.add_custom_parameter('Error', json_dict['Error'])

Custom Parameterについて、詳しくはこちら

docs.newrelic.com

監視できない嵌りどころ

Main関数自体を監視対象とすることができません。 Local関数が一つしかない場合は、その関数が監視対象となります。 関数が複数存在する場合、監視対象関数を明示的に修飾しなければなりません。 デコレーションbackground_taskのname引数に関数名、groupはオプション、指定しているとAPMトランザクション画面で同じgroupに所属している関数名別のレスポンス時間を表示したりできます。

NewRelic APMを使用して、実際に計測してみる

ここでは、NewRelic INSIGHTS画面でのパフォーマンス監視 代表的なNRQL構文、について紹介します。

NewRelic INSIGHTS画面でのパフォーマンス監視

f:id:flect170:20191118150842p:plain SELECT文で、パフォーマンス監視対象をINSIGHTS画面に表示しています。

代表的なNewRelicクエリ構文

SELECT文、FROM句、WHERE句、AS句、LIMIT句、SINCE句、他サポートされていますが、 監視ツールなので、UPDATE文等の更新処理が入るクエリ構文はありません。 2つのTABLEをJOINしたくなったりしますが、JOIN句は用意されていません。

代表的な集約関数

Count(*)、average関数、latest関数、uniques関数、他にも、最大、最小、ユニークカウントなどが用意されています。

顧客ごと集計クエリの例です。

SELECT average(duration) FROM Transaction WHERE Process = 'DynamoDB' FACET sid LIMIT 30 SINCE 30 minutes ago TIMESERIES 1 minute

上記のクエリでは、NewRelicトランザクションから顧客ごと、最大30件まで、過去30分間の1分毎のDynamoDBへの書き込み時間の平均値をクエリしています。 これにより、当該顧客で影響が出たのかどうかを集計することができました。

どうでしたか?参考になりましたでしょうか?

Heroku NewRelic APMについて、ご紹介させていただきました。

最後まで、読んでいただき有難うございました。

NewRelicの公式サイトもご覧ください。

newrelic.co.jp

自作アプリをHeroku Add-onsにプロビジョンする方法

こんにちは。エンジニアのオクダです。今回のテーマは「自作アプリをHeroku Add-onsにプロビジョンする方法」です。

皆さん、Heroku Add-onsはよく利用しているが、実際にHeroku Add-onsを作成するとなると、って言うことにならないでしょうか?

そこで、今回は「アドオン開発するぞ、の第一歩としてtestクラスのアドオンを作ってみる」をご紹介します。

その前にHeroku アドオンのリリースステージとは

Heroku アドオンには、リリースステージがあり、α版については、審査なしで無料で作成することができます。

devcenter.heroku.com

そのリリースステージ名がtestになります。

Heroku Add-ons自体は、Heroku以外のhttpsサーバーでも実装可能です。

Heroku CLIでHerokuにログイン

$ heroku login

既に別のアカウントにログインしていて、Herokuにログインできない場合は

$ heroku login --interactive

addons-adminプラグインをインストール

$ heroku plugins:install addons-admin

add-onsのルートディレクトリにマニフェストを作成

$ heroku addons:admin:manifest:generate

Input manifest information below: // と聞いてくるので

? Enter slugname/manifest id: <manifest id>    # 一度決めると変更できない
? Addon name (Name displayed to on addon dashboard): (MyAddon) <Addon name>    # Addon nameを入力
? Choose regions to support
  <space> - select
  <a> - toggle all
  <i> - invert all 
  ↑↓ use arrow keys to navigate
 (Press <space> to select, <a> to toggle all, <i> to invert selection)
❯◯ dublin
 ◯ eu
 ◯ frankfurt
 ◯ oregon
 ◯ sydney
 ◯ tokyo
 ◉ us    # 取り敢えず弊社ではUSを選択
 ◯ virginia
? Would you like to generate the password and sso_salt? (Y/n) <Y>    # Yを入力
? This prompt will create/replace addon-manifest.json. Is that okay with you? (Y/n)  <Y>    # Yを入力
Generating add-on manifest... done
The file addon-manifest.json has been saved!    # と表示されたら成功

Heroku Add-onsマニフェストの要件

生成されたHeroku Add-onsマニフェストは下記のようになっています。

{
  "id": <add-on-id>,    # 後ほどBasic認証のuserNameで使用する。
  "api": {
    "regions": [
      "us"
    ],
    "version": "3",
    "password": <add-on-password>,    # 英数32文字の任意の文字列で自動生成されます。後ほどBasic認証で使用するので、覚えておく。後ほどBasic認証のpasswordで使用する。
    "requires": [],
    "sso_salt": "********************************",    # 英数32文字の任意の文字列で自動生成されます。
    "production": {
      "sso_url": "https://<example>.herokuapp.com/sso/login",
      "base_url": "https://<example>.herokuapp.com/heroku/resources"
    },
    "config_vars": [
      <CONFIG_VARS_URL>
    ],
    "config_vars_prefix": <CONFIG_VARS_PREFIX>
  },
  "name": <add-on>,
  "$base": 156626069365144
}

Heroku Add-onsマニフェストにはproduction.sso_url / base_urlが存在し、実在するURLに編集しなければなりません。

sso_urlとbase_urlの要件は...

  • URLの命名規則

    • sso_urlの命名規則は、URLの最後が/sso/loginで終了する
    • base_urlの命名規則は、URLの最後が/heroku/resourcesで終了する
  • httpsサーバーであること

    • manifestにあるproduction.sso_url / base_urlに実在するURLを指定する
    • これらのURLをhttpsサーバーに実装

sso_url: https://example.com/a/b/sso/login

base_url: https://example.com/c/d/e/heroku/resources

"base_url"は、heroku addonsを作成する際に、有効なアドオンであるか確かめる為に、Basic認証を行うページです。

"sso_url"は、heroku addonsを起動する際に、一番最初に訪れるページです。

更新したaddon-manifest.jsonをHerokuにプッシュする

$ heroku addons:admin:manifest:push

アドオンをホストするWebサーバーを下記のコードのように追加する(Python Flaskの場合)

from flask import Flask, render_template, jsonify, redirect
    ︙
    ︙
def basic_auth():
    userName = <add-on-id>    # 先ほどマニフェストで登録していた、アドオンID
    password = <add-on-password>    # 先ほどマニフェストで登録した、パスワード

    app.config['BASIC_AUTH_USERNAME'] = userName
    app.config['BASIC_AUTH_PASSWORD'] = password
    app.config['BASIC_AUTH_FORCE'] = True

    basic_auth = BasicAuth(app)
    ︙
    ︙
@app.route('/heroku/resources', methods=["GET", "POST"])            # addonの認証はPOSTで行われるため、methodにPOSTを追加
def base():
    basic_auth()
    res = {
        "id": "01234567-89ab-cdef-0123-456789abcdef",            # 何でも良い
        "message": "",                            # 空で良い
        "config": { <CONFIG_VARS_URL>: "https://<example>.herokuapp.com/" }    # キーにaddon-manifest.jsonのconfig_varsを指定してあげる。値はアプリのURL
    }
    return jsonify(res)

@app.route('/sso/login', methods=["GET", "POST"])                # base関数同様、methodにPOSTを追加
def sso():
    basic_auth()
    return redirect('/')    # rootパスにリダイレクト

自作Add-onをHerokuアプリに追加する

$ heroku addons:create <add-on>:test

下記のようなログが出てきたら成功です。

Creating <add-on>:test on ⬢ <app-name>... free
Created <add-on>-<alpha-numeric> as <CONFIG_VARS_URL>    # <CONFIG_VARS_URL>は、addon-manifest.jsonのconfig_varsで宣言しているキー
Use heroku addons:docs <add-on> to view documentation

うまく作成されない時は、これをやってみると詳しいログが取得できます

$ DEBUG=* heroku addons:create <add-on>:test --app <app-name> --wait

どうでしたか?参考になりましたでしょうか?

Herokuを利用している場合、使用する機会があるHeroku Add-ons。そのHeroku Add-onsを、作成する方法をご紹介させていただきました。

最後まで、読んでいただき有難うございました。

Herokuアドオンの公式ドキュメントもご覧ください。

devcenter.heroku.com

devcenter.heroku.com