2018-06-24

GCP のプリエンプティブインスタンスで深層学習

深層学習ぼちぼち勉強してます。手元にGPU環境がないので、クラウド GPUをなにか使おうと調べたところ。GCP のプリエンプティブインスタンスがオトクなようです。
GPU のプリエンプティブインスタンスなら、V100 の GPU が使えて一時間あたり0.75ドル程度です。

プリエンプティブインスタンスは次のような特徴があります。
プリエンプティブ VM インスタンス | Compute Engine ドキュメント | Google Cloud より引用

Compute Engine は、システムイベントにより、いつでもプリエンプティブインスタンスを終了できます。Compute Engine がシステムイベントによってプリエンプティブインスタンスを終了する可能性は通常は低いですが、そのときの状況に応じて、日々ゾーンごとに異なります。

Compute Engine は、24 時間実行した後で、必ずプリエンプティブインスタンスを終了します。

プリエンプティブインスタンスは有限の Compute Engine リソースなので、常に利用できるわけではありません。

プリエンプティブインスタンスは、ライブマイグレーションを行ったり、メンテナンスイベントがあるときに自動的に再起動するよう設定することはでません。

上記の制限により、プリエンプティブインスタンスはサービスレベル契約の対象となりません（また、明確さのために Google Compute Engine SLA から除外されています）。

重要な点は、最長で24時間、突然終了することがある、自動的な再起動はできないという点です。
深層学習でちょっと試す分には、最長24時間というのは消し忘れでお金を沢山請求されることもなく利点とも言えるかもしれません。

こういう遊びをしている人もいるようです。
「プリエンプティブルVMをずっと起動してみた」という話をした #LT駆動 26 | そんなこと覚えてない

じっさいに構成してみたところ以下のような感じでした。
ページ下部でプリエンプティブインスタンスをオンにします
f:id:ororog:20180624221913p:plain

CPU1, メモリ6.5GB, V100 で1時間あたり 0.754ドルでした。
f:id:ororog:20180624221947p:plain
次は環境構築してなにか遊んでみます。

2018-02-19

Riot API を使った League of Legends ウェブアプリを公開するまで

League of Legends のウェブアプリを作ったので、その手順を書いてみます。

Riot APIについて

Riot Developer Portal
こちらからサインインすることで、だれでも開発用の API を使うことができます
f:id:ororog:20180213212841p:plain
しかし、開発用の API は次のような制限があります。

リクエストに制限がある (20 requests every 1 seconds, 100 requests every 2 minutes)
有効期限(一日)がある
開発用 API を使ったサービスを公開してはいけない

このため、開発用 API ではサービスを公開できません。Riot に申請する必要があります。

API の種類

前述の開発用 API (development API) の他に、Personal API と Production API があります。それぞれ次のような特徴があります。

Personal API

リクエストの制限は開発用 API と同じ
有効期限がない
申請が通るまで早い(2, 3日？)
アプリケーションが無くても申請可能
Personal API を使ったサービスを公開してはいけない

Production API

制限が大幅に緩和される (RATE Limiting)
有効期限がない
申請が通るまで早くて2週間程度必要(体験談)
申請にはアプリケーション URL が必要

個人で楽しむには Personal API でいいのですが、公開するにはやはり Production API が必要です。以下では、Production API を公開するまでの道のりを紹介します。

申請の準備

開発用APIでアプリを作る

どの程度のアプリで申請が通るのかわかりませんが、まずはアプリを作りましょう。開発用 API を使うと毎日更新が必要なことだけ注意しましょう。
開発効率をあげるために、Personal APIをとりあえず申請するのもありです。API を更新する手間が減ります。

ポリシーを理解する

GENERAL POLICIES を熟読しましょう。日本語はたぶんないです。日本 Riot が仕事してくれることを期待しましょう。違法なことはしない、APIキーをもらさない等が書いてあります。

申請する

いよいよ申請です。右上の REGISTER PROJECT から申請します。
f:id:ororog:20180219215621p:plain
次に、PRODUCTION APPLICATION を選択します。規約に同意し、アプリケーションを登録します。以下は、必要な項目です。

Project Name

いい名前を付けましょう

Project Description

プロジェクトの説明をします。こちら、たぶん日本語は不可です。
アプリのチェックする人が読むものなので、説明はなるべく詳細に書きます。
必要なら使い方も書いたほうが良いと思います。私は説明が足りず理解できなかったのか、アプリが完成していないとしてリジェクトされてしまいました。

Project Group

謎です。最初から値が入っているのでそのままにしました。

Project URL

実際に動いているアプリの URL を指定します。

登録時に、riot.txt をアップロードして、Riot からアクセスできるようにする必要があります。

結果を待つ

Pending

まずは承認待ち状態です。私は２週間ぐらいで最初の返信が来ました。

Approved

おめでとうございます。あなたのアプリを公開しましょう。

Rejected

私は最初にリジェクトされてしましました。アプリケーションのページのメッセージを見ることで、理由を確認できます。
f:id:ororog:20180219220827p:plain
私の場合、アプリケーションが動いていないと指摘を受けました。既に動いているはずなので、以下の情報をメッセージに追加しました。

日本のデータにしか対応していない
使い方の詳細

メッセージを追加して待つこと4日、無事承認されました。

情報源

基本的に英語ですが、困った場合は次のリンクを参考にしてみてください

リジェクトされた時、似たような人がいないか参考にしました。

作成したアプリはこちらです。 Target Bang!
アプリの紹介はまたの機会にさせていただきます。
皆様もアプリを作ってみてください。

2017-12-28

仮想通貨で有り金全部溶かした人の顔BOT

仮想通貨で有り金全部とかした人の顔がみたいー、あびゃ〜

そんな純粋な子のためにボットをつくりました。

twitter.com

動機

仮想通貨暴落したら面白いなーと思ってる自分に気づいてしまったので…

中身

python3 で SqlAlchemy を使って作っています。コードはこちら。
github.com
images 以下にある画像をランダムに表示します。

仮想通貨の価格の取得には CoinMarketCap の API を使用しました。
coinmarketcap.com

登録不要で以下のように基本的な情報はとれたので便利です
https://api.coinmarketcap.com/v1/ticker/?convert=JPY
JPY に変換できるの今気づきました :)

通知のタイミングは、6時間以内に20%下落したらに設定しています。alt coin が多すぎて、下落したことがわかっても何の感想も得られないです。フォローはおすすめしません。

2017-04-16

Rebase and merge 運用で merged な branch 一覧を表示する

script shell

Rebase and merge な運用でもマージ済みブランチを表示、削除するためのスクリプトを書いた。

仕事では github で PR をマージする時、Rebase and merge でマージしている。
Rebase and merge の良し悪しはさておき、Rebase and merge だとコミットのハッシュ値が変わってしまうため、git branch --merged などでマージしたものを表示できないのが不便。マージのたびにブランチを削除すればいいのだけど、ズボラなので気づいたら溜まってしまう。めんどくさいのでスクリプトを書いた。

list-merged-branch/list-merged-branch.sh at master · ororog/list-merged-branch · GitHub

適当な場所において list-meged-branch.sh を実行すればマージ済みのブランチが表示するので、あとは list-merged-branch.sh | xargs git branch -D とかで削除してやればよい。

中でやっていることは、Rebase and merge をしてもコミットの日時は変わらないため、master のログに、ブランチのハッシュ値を除いた部分が含まれているかどうかを見ているだけ。さすがにコミット日時とメッセージまで一致するコミットは無いだろうという考え。
個人的に便利になったのでうれしい。

2017-02-12

Stripe の description と metadata

Stripe

Stripe のオブジェクトの中になんらかのデータを保存したい時がある。たとえば顧客の情報だったり、支払いの補足情報だったり。会社名などを保存しておくと、ダッシュボードから検索できて便利。そんな時にデータを保存するフィールドとして、 description と metadata の２つの選択肢がある。どれを使うべきか？

結論として

metadata を使ったほうがよさそう

それぞれの特徴を列挙すると

description

一部のオブジェクトだけ持っている (customer, invoice item, transfer など)
customer.description はダッシュボードで閲覧できるだけだが、invoice item.description は請求書に表示されるなど、公開範囲がわかりづらい。

description についての細かい説明は API の create のところに書いてある。たとえば、incoiceitem の description は
Stripe API Reference

An arbitrary string which you can attach to the invoice item. The description is displayed in the invoice for easy tracking. This will be unset if you POST an empty value.

と、請求書に表示されることが書いてある。一方で、customer の説明では
Stripe API Reference

An arbitrary string that you can attach to a customer object. It is displayed alongside the customer in the dashboard. This will be unset if you POST an empty value.

と、ダッシュボードがに表示されることが書いてある。

metadata

詳細は Stripe API Reference

更新可能な Stripe のオブジェクトはほとんど metadata を持つことができる (Account, Charge, Customer, Refund, Subscription, and Transfer)
各オブジェクトは20個のキーバリューペアを保存できる
Stripe によって metadata が参照されることはないし、顧客に見られることもない

metadata は顧客に表示されないことが明確で、各オブジェクトによって使われ方が共通である。description はその点ちょっとわかりにくい。これなら何か追加データを保存するのであれば、metadata を使ったほうが良さそう。

おまけ

Stripe API のドキュメントを読み直したら、customer.description の説明が正確になっていた。以前は description may be seen by users だった気がするけど、現在はダッシュボードに表示されると明確に書いてある。Stripe はプログラマに優しいのが良いところ。