まだプログラマーですが何か？

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

2017/02

Amazon で商品を検索したり、その商品へのリンクを作成する作業を自動化するには Amazon Product Advertising API を使います。その際にアクセスキーとシークレットアクセスキーが必要になります。　これらの取得方法を紹介します。

前提として、AWS のアカウントが必要です。こちらから作成しておきましょう：
https://aws.amazon.com/jp/


API のアクセスキーとシークレットキーを取得するには、まず AWS にログインし、名前の部分をクリックして「セキュリティ認証情報」を選択します：
2017020801


AWS Identity and Access Management ユーザーがうんたらかんたら・・・というメッセージが表示されますが、今は無視して×をクリック：
2017020802


「セキュリティ認証情報」のページで、「アクセスキー（アクセスキーIDとシークレットアクセスキー）」と書かれた箇所をクリック＆展開して、「新しいアクセスキーの作成」ボタンをクリックします（同時には２つまでのアクセスキーを所持できるらしいです）：
2017020803


アクセスキーが作成されます。その中身を表示すると、アクセスキーID ＆シークレットアクセスキーがそれぞれ表示されます。　これで目的の情報が取得できました。なおシークレットアクセスキーはこの１回しか表示されません。確認する唯一の機会です。忘れてしまった場合は１つ前の画面で一度削除して、再度アクセスキーを作成し、その際に確認する必要があるので注意してください：
2017020804


この API の使い方については公式ドキュメントを参照してください：
https://affiliate.amazon.co.jp/gp/advertising/api/detail/main.html


この情報や API を使ってアフィリエイトを行おうとすると、別途アソシエイト ID も合わせて取得する必要がありますが、その取得方法についてはこちらを参照ください：
Amazon アソシエイト ID の取得手順


タグ ：
#key
#amazon
#aws
#product
#advertising
#api
#affiliate

とある REST API を使っていて気付いたこと／考えさせられたことをまとめてみました。明快な結論や提案があるわけではなく、グダグダに感じられる内容かもしれないので、あらかじめご了承ください。


そのとある REST API を使ったウェブアプリケーションを作って運用している中で、おかしな挙動に気付くことがありました。以前は問題なく動いていたのに、あるタイミングで実行すると期待通りに動かない、という「まあまあよくある」ケースです。自分のケースでは動かないというよりも、タイムアウトを起こすような挙動になっていました。ただ REST API そのものが止まっている様子はない、というケースでした。

自分のソースコードでは一応エラーハンドリングはしていたつもりでしたが、REST API がエラーを起こしている様子もなく、原因究明に時間を要するものでした。結論としては自分のアプリケーションコードを見ていてもよく分からず、REST API のユニットテストのようなツールを動かした結果気付くことがありました。

それがこちら：
20170207


・・・わかるでしょうか？ REST API を実行したレスポンス本文が Response Body に、ステータスコードが Response Code に記述されています。これによるとレスポンス本文は
{
  "status": "ERROR",
  "statusInfo": "daily-transaction-limit-exceeded"
}

となっていて、"daily-transaction-limit-exceeded" が原因のエラーが発生している、という内容でした。この API には Daily Transaction Limit（１日で使える回数の上限）が決められていて、その上限に達したのでもう実行できない、という内容です。これに関してはそういう条件で使っている API なので、なるほど、エラーの原因はわかりました。

問題はこの REST API を実行したステータスコードが 200 になっている点です。HTTP ステータスコードの分類とその意味についてはウィキペディアなどを参照していただきたいのですが、簡単にいうとこんな感じで分類されています：
コード意味考えられる原因など
2xx（200番台）成功 -
4xx（400番台）クライアントエラー認証が必要、アクセス権がない、URLが間違っている、タイムアウト、、、
5xx（500番台）サーバーエラーアプリケーションエラー、不正なゲートウェイが利用されている、、、


200 番台は成功。400 番台と 500 番台がエラーで、それぞれクライアント側のエラーなのか、サーバー側のエラーなのかを分類しています。

で、今回のケースですが、実行結果はエラーなのに 200 番のステータスコードが返されているのでした。自分のプログラムコードの中では「200 が返ってきたら成功」と決めつけて実装していたため、このようなケースに対処できていなかったのでした。


ここまでが実際に目の当たりにしたエラーとその原因でした。以下はこの件に関して自分が考えたことです。


自分を弁護する意味で「えー、でもそれっておかしくない？　エラーなんだからスタータスコードは 400 番台なり 500 番台で返ってくるべきでは？」という考えもないわけではありません。ただ今回のケースではこれも難しいような、つまり 200 番のステータスコードがあながち間違ってはいないような気もしています。

その理由として、まず「これはクライアントエラーなのか？それともサーバーエラーなのか？どちらかに分類できるのか？」という問題です。これに関してはどちらとも言えるし、どちらとも言えないと思っています。

実は 402 番のステータスコードは "Payment Required" 、つまり（お金を払わないといけないんだけど）払ってないエラー、と定義されています。が、実際には定義だけで実装されていない、つまり将来のための定義とされているのでした。また厳密には支払い契約を結んで使っているわけではなく、「この条件で１日○○回使える」というルールの下で利用しているだけなので、402 番に（クライアントエラーに）該当するエラーであるとは考えにくいのです。

※本来の意味とは違いますが、「権限がない」に該当するのではないかと言われると、まあ・・・　という考え方もあるとは思います。ただそれをクライアントエラーとして返してもクライアント側はどうにもできないので、やはり 400 番台エラーには該当しないと思います。

ではサーバーエラーなのか？というと、これも該当しないと思います。プログラミングにミスがあったわけではなく、「実行したら、『実行できない』という結果が返ってきた」のは、正しく実行された（結果が期待通りではなかった）とも言えます。そう考えると、そもそも今回の件は REST API レベルではエラーですらないとも言えます。


そう考えると、今のように API を組み合わせてアプリケーションを作ることが珍しくない環境においては、200 番のステータスコードが返ってきてもエラーの可能性を疑ってコーディングする必要があるのかも、と思うようになりました。このケースであれば実装側が工夫すれば（というか、そもそもちゃんと色んなケースを想定してエラーハンドリングしていれば）防げるものです。

そういう意味でもいい反省の機会でした。　でも今後は同様のケースを想定した「成功でもエラーでもないステータス」が出て来る可能性もありますよね。。


タグ ：
#http
#status
#code
#rest
#api
#error

普段は IBM Bluemix の関連で IBM Watson の API を紹介する機会があります（このブログでも何度か扱っています）。これらの多くは Watson Cognitive と呼ばれる言語や画像などを対象にした認識／分類を行うタイプのエンジンです。

一方で、Cognitive 以外の Watson もあります。その１つが Watson Analytics と呼ばれるもので、これは「データ分析」を目的としたエンジンです。現在では API というよりも、クラウド上のツールとしてその機能が提供されています：

http://www.ibm.com/software/jp/cmp/watsonanalytics/
2017020100


この Watson Analytics ツールは、誰でも申し込みから 30 日間は無料で使うことができます。というわけで自分も申し込んで、どんなものなのかを試しに使ってみました。

まず上記ページの「無料トライアルを試す」から申し込みを行います。しばらくすると以下のようなメールが送られてくるので、「ログインする」をクリックして、申込み時に指定したメールアドレスとパスワードで Watson Analytics サービスにログインしてください：
2017020201


Watson Analytics サービスにログインした直後はこのような画面になります：
2017020201



さて、今回このサービスを試用するにあたって、どんなデータで何を試すかを考えました。そこまでアナリティクスに詳しいわけでもなく、そこまで詳しい人を対象に紹介するつもりもないので、自分の守備範囲の中で試すことにします。　というわけで、以前にこのブログで紹介したことと同様のことを Watson Analytics サービスで挑戦してみることにします：

dashDB の R Studio を使ってデータの相関関係を調べる
http://dotnsf.blog.jp/archives/1047597688.html


ここで紹介しているのはセンサーとみなしたラズベリーパイから３種類（CPU 温度、CPU 負荷率、サインカーブを描く値）のデータを１秒おきに取り出したものです（取得済み）。そしてこの３つのデータの相関関係有無を調べてみることにします。同ブログエントリ内でも紹介されていますが、取得済みのデータは CSV で公開しているので、同じものをそのまま使うことにします。ここからダウンロードしておいてください：
https://raw.githubusercontent.com/dotnsf/RPDATA/master/RPDATA.csv


なお、この CSV ファイルをそのままエクセルで開くと、最初の方はこんな感じになります。１行目はヘッダでデータは２行目以降。B列が CPUTEMP（CPU温度）、C列がCPULOAD（CPU負荷率）、そしてD列がSINE（サインカーブを描く値）になっています。A列のIDはユニーク文字列ですが、今回は使いません：

2017020211


ちなみに CPUTEMP と CPULOAD を折れ線グラフにするとこんな感じ。途中でわざと負荷をかけたので、山が１つ出来ていることが見てとれます：

2017020212


一方、同じ期間中の CPULOAD と SINE とを比較したのがこちら。SINE は CPU の負荷とは無関係に、一定のリズムでサインカーブを描いていることがわかると思います：
2017020213


ここまで見た上で意識していただきたいのは以下のことです：
・ CPUTEMP が上がると CPULOAD も上がり、CPUTEMP が下がると CPULOAD も下がる
・ SINE にはそういった相関関係が CPUTEMP にも CPULOAD にもない
・ いまグラフの形を見たからそういうことに気付くことができた
・ また CPUTEMP は CPU 温度で CPULOAD は CPU 負荷率だった。つまりどちらも CPU に関連するセンサー値だった。そこまで理解した上でこの数値やグラフを見ているから、これらには関係があるように推測できた


つまり、人間の目でグラフの形を見比べた上で、なんとなく「形が似ている」と気づけたわけです。また「同じ CPU に関する値だったと分かっていたから、それらには関係があるだろう、と推測できた、ということです。

では同じことを目で判断せずに、加えて事前に同じ CPU の情報であることを知らない Watson が、数値データの羅列を与えただけで気付くことができるでしょうか？　ということを今回の調査テーマとしてみることにします。


改めて、この CSV ファイルを Watson Analytics にロードします。新規データとして追加するので "+ New data" と書かれた箇所をクリックします：
2017020201


Watson Analytics には標準でサンプルデータが用意されているのでそれを使うことも出来る上、Box や OneDrive、Twitter などのソーシャルサービスから条件を指定してデータを取り出すことも可能になっています。今回は手元にある CSV ファイルを元にデータを生成したいので、"Local file" タブを選択します：
2017020202


このような画面になったら「Browse」をクリックして、先程ダウンロードした RPDATA.csv ファイルを指定します：
2017020203


こんな感じの画面になって RPDATA.csv ファイルがアップロード候補に加えられている状態になりました。このまま「Import」をクリックしてアップロードします：
2017020204


元の画面に戻りますが、いまアップロードした RPDATA.csv が分析データとして追加されていることが分かります。この画面では "Processing..." と表示されています。これはアップロードは完了しているのですが、分析するための処理を行っている途中であることを意味しています。このままもうしばらく待ちます：
2017020205


下図のような状態になると分析処理も完了したことになります。このアイコンをクリックして、実際の分析結果を確認してみます：
2017020206


（RPDATA に対して）どんな分析をするのか、という選択画面が表示されます。上述したように、今回は値の相関関係を調べたいので、"What drives SINE?"（何が SINE に影響しているのか？）を選びます。SINE との影響だけを調べたいわけではないのですが、この "SINE" の部分を切り替えて調べることができるので、今回はこの観点で各種データの影響要素を調べることにします：
2017020207


"What drives SINE?" をクリックすると、しばらく画面構成の処理で時間がかかるのですが、ロードが完了するとこのような画面になるはずです。結論として、"SINE" に関しては "No key drivers were found."（特に影響要素は存在しない）と表示されています。まあ答をわかっている立場からすると当然の結果なのですが、解析結果としても同じ結論になっていることが分かります：
2017020208


もともとの目的にもよるのですが、例えばこのセンサーモジュールの故障やエラー、利用不可になる予防保全をしたい場合などは CPU 利用率があまり高くない状態をキープしていてほしいものです。センサーが PC などと直結していれば、その PC からセンサーの CPU 状態を把握できることもありますが、そうでないケースも珍しくありません。そうなると「センサーの CPU 状態を直接モニタリングする」ことは簡単ではないことになります。これをどうにかできないでしょうか？

では今度はこの "SINE" を "CPULOAD（CPU 負荷率）" に変更して、CPULOAD に影響を与えている要素があるかどうかを調べてみましょう。画面左下の "SINE" と書かれた箇所をクリックし、"CPULOAD" を選択します：
2017020209


同様にして少し処理時間で待つことになりますが、画面のロードが完了するとこんな結果になりました。"CPULOAD" は "CPUTEMP" の影響を受けている、という解析結果が表示されています！
2017020210


もともとは CPU 負荷率の状態をなんとか調べることができないか、という課題があったわけですが、今回の結果によって、このセンサーモジュールでは CPU 温度と CPU 負荷率との間に相関関係があることが統計的にもわかったことになります。そして CPU の温度は直接外部から測定することもできるものなので、CPU の温度を測定していれば、CPU の負荷が高くなっているのかどうかを判断することができる、という可能性がでてきたことになるわけです！


くどいようですが、我々のように事前にグラフの形を見比べたわけではなく、またこれらがどちらも CPU に関する値である、という情報が事前に与えられたわけでもない中での自動解析結果であることを考慮すると、「ここまで簡単に分かっちゃうのか・・」という印象でした。

今回のデータは ID を除けば３種類しかなく、人間の目や脳でもわかりやすいものでした。ただこれが数１０種類ものデータを含むもので、その中から存在するかどうかもわからない相関関係を見つけ出すというのはなかなか大変なんだろうなあ・・・と思うのですが、このツールはその作業負担を大幅に軽減できるものだと思います。


というわけで、このような IBM Watson Analytics サービスが無料で試せるというのはなかなかすごいのではないかと思っています。皆様も興味があれば是非試していただいて、手元にある数値データを使って簡単に解析できるという体験をしていただきたいです。



タグ ：
#ibm
#watson
#analytics

このページのトップヘ