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

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

タグ:bluemix

以前に express-ipfilter ライブラリを使って、Node.js アプリの IP アドレスフィルタリングを行うサンプルを紹介しました:
http://dotnsf.blog.jp/archives/1066182158.html

↑ここで紹介したサンプルは一応動くものですが、アプリケーションを IBM Cloud の Cloud Foundry アプリとしてデプロイすると( IP アドレスフィルタリングが)正しく動かないことがわかりました。原因は Cloud Foundry 内のルーティングで x-forwarded-for ヘッダの情報が変わってしまい、正しい IP アドレスを取得できなくなってしまうようでした。

IBM Cloud の Cloud Foundry 環境でもこの IP アドレスフィルタリングを有効にするには、フィルタリングを行う前に Express() の use メソッドを使って、
app.use( 'trust proxy', true );

を呼び出してからフィルタリングを行う必要があります。

(解説)
http://expressjs.com/ja/api.html



 

IBM Cloud から提供されているコグニティブエンジン IBM Watson を使って、
 1. MNIST の手書き数字サンプルデータを学習させて、
 2. 実際に手書き数字データを送信して、認識させる
という、「学習」と「問い合わせ」のコグニティブエンジン一連の作業を再現させてみます(した)。


今回紹介する一連の作業では、IBM Cloud の以下のサービスを連動させて使います:
 ・IBM Watson Studio
 ・IBM Machine Learning
 ・IBM Cloud Storage
 ・SDK for Node.js ランタイム(上記2のサンプルをクラウド上で稼働させる場合)

以下で紹介する手順は IBM Cloud の無料版であるライトアカウントを使っても同様に動かすことができるようにしているので、興味ある方は是非挑戦してみてください。


1. MNIST の手書き数字サンプルデータを学習させる

人工知能とか機械学習とかを勉強していると、そのチュートリアルとして "MNIST" (Modified National Institute of Standards and Technology)を目にする機会があると思っています。機械学習のサンプルとして手書きで描かれた数字の画像データと、そのラベル(何の数字を描いた画像なのか、の答)が大量にサンプルデータとして公開されており、機械学習を説明する際の様々な場面で使われています:
2018050800


今回、この MNIST データを IBM Watson StudioIBM Watson Machine Learning を使って学習させ、かつ問い合わせ用の REST API を用意します。

・・・と、偉そうに書いていますが、この部分の手順については私の尊敬する大先輩・石田剛さんが Qiita 上でわかりやすく紹介していただいています。今回の学習部分についてはこの内容をそっくりそのまま使わせていただくことにします(石田さん、了承ありがとうございます):
Watson Studioのディープラーニング機能(DLaaS)を使ってみた 

2018050801

↑この作業で MNIST の手書き画像を IBM Watson Machine Learning を使って学習させ、その問い合わせ API を REST API で作成する、という所までが完了します。


2. 手書き数字データを送信して、認識させる

マウスやタッチ操作で画面に手書き数字を描き、その内容を 1. の作業で用意した REST API にポストして何の数字と認識するか、を確認できるようなアプリケーションを作成します。

・・・というか、しました(笑):
2018050804


PC またはスマホでこちらのサイトにアクセスすると体験できるようにしています:
https://dotnsf-fingerwrite-mnist.us-east.mybluemix.net/


フロントエンドはもともと以前に「イラツイ」という手描きイラスト付きツイートサービスを作った際のものを丸パク応用し、問い合わせ API を呼び出すバックエンド部分はデプロイしたモデルの Implementation タブ内にある JavaScript の Code Snippets を参考に作りました。この Code Snippents は各種言語のサンプル(アクセストークンを取得してエンドポイントにリクエストするサンプル)が用意されていて、とても便利です:
2018050809


アプリケーションの使い方はマウスまたは指でキャンパス部分に数字を描いて、"fingerwrite" ボタンを押すと、その描いた数字データを上記 1. で作成した REST API を使って識別し、最も可能性が高い、と判断された数値とその確率が表示される、というものです:
2018050805


PC 画面の場合に限りますが、デバッグコンソールを表示した状態で上記を実行すると、可能性が最も高いと思われた結果だけでなく、全ての数値ごとの確率を確認することもできます:
2018050806

↑常に「2」の確率が高くなってる気がする。。原因は学習の調整不足だろうか??それともデータを渡すフロントエンド側??(2018/May/09 ピクセル毎のデータを取り出すロジックに不具合があったので、修正しました)


なお、この 2. のサンプルアプリは Node.js のソースコードを公開しているので、興味ある方は自分でも同様のサイトを作成してみてください:
https://github.com/dotnsf/fingerwrite-mnist

2018050807


このソースコードから動かす場合、事前に settings.js ファイルを編集しておく必要があります:
2018050808


まず上の3つ、 exports.wml_url, exports.wml_username, exports.wml_password の3つの変数の値は 1. で MNIST データを学習した際に使った IBM Watson Machine Learning サービスのサービス資格情報を確認して、その中の url, username, password の値をそれぞれコピー&ペーストしてください(最初の exports.wml_url だけはおそらくデフォルトで url の値になっていると思います。異なっていた場合のみ編集してください):
2018050803


また一番下の exports.ws_endpoint の値は同様に 1. で使った IBM Watson Studio の Web サービスのエンドポイント(学習モデルをデプロイした時に作成した Web サービス画面の Implementation タブから確認できる Scoring End-point の値)をそのまま指定します:
2018050802


ここまでの準備ができた上でアプリケーションを実行します。ローカル環境で動かす場合は普通に npm install して node app で起動します:
$ npm install
$ node app

IBM Cloud (の SDK for Node.js)を使って動かす場合は、cf ツールbx ツールを使って、そのまま cf push で公開されます:
$ cf push (appname)


今回紹介した方法では IBM Watson Studio と IBM Watson Machine Learning を使って画像データを学習させ、その学習結果に対して REST API で問い合わせをする、という機械学習の一連の流れを体験できます。また学習データ(とモデリング)を変更することで、異なる内容の学習をさせる応用もできますし、学習した内容に問い合わせを行う API も自動生成されるので、フロントエンドの開発も非常に楽でした。
 

 は IBM CloudantApache CouchDB と API 互換のある NoSQL データベースです。JavaScript で操作することができます。npm を使ってサーバーサイドで動かすこともできますが、ブラウザから JavaScript ライブラリをロードして、個々のブラウザ内で使うことも可能です。

特にこれをブラウザから使う場合、マスターデータはクラウドの IBM Cloudant で保持しつつ、必要なデータをユーザーのブラウザと同期して、ほぼすべての処理をローカルブラウザ内で完結させる(=時間のかかるDBアクセスをローカルDBだけを対象に行えばよくなるので、アプリケーションとしての安定性やパフォーマンス向上も期待できる)、ということが可能になります。とても強力な同期機能を持ったデータベースエンジンと言えます。
2018040900


この「同期」を具体的にどうやるか、という内容が今回のブログエントリです。


今回の説明では、サーバー側の DB を IBM Cloudant で用意することにします。IBM Cloud のライトアカウントを作成すると容量 1GB まで使えるライトプランの DBaaS が無料で用意できます。

で、この Cloudant DB をブラウザに同期・・・するわけですが、IBM Cloudant を使う場合はその前に1つ設定が必要です。標準状態の IBM Cloudant はクロスオリジンからのアクセスを許可していません。そのため、標準設定のままウェブブラウザから同期をとろうとするとクロスオリジンアクセスになってしまい、エラーとなってしまいます。したがってクロスオリジンアクセスを許可するよう、設定を変更する必要があります。詳しくはこちらにも記載していますが、curl コマンドと IBM Cloudant の API を使って IBM Cloudant の CORS アクセスを有効にするための設定を行います:
$ curl -i -u 'db_username:db_password' -XPUT 'https://db_username.cloudant.com/_api/v2/user/config/cors' -H 'Content-type: application/json' -d '{"enable_cors":true,"allow_credentials":true,"origins":["*"]}'

↑db_username, db_password は IBM Cloudant のインスタンスにアクセスするためのユーザー名およびパスワードです。


次にブラウザ内の JavaScript で DB の同期を行います。普通に「データベースそのものの同期をとる」のであれば話は単純で、以下のようなコードを記述するだけです:
  :
  :
<html>
<head>
<script src="https://cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var localDB = new PouchDB( 'testdb' );
var remoteDB = new PouchDB( 'https://db_username:db_password@db_username.cloudant.com/testdb' );

remoteDB.sync( localDB, {
live: true, retry: true });
: :

まず CDN を指定して PouchDB のライブラリをロードします。そして IBM Cloudant のユーザー名(db_username)とパスワード(db_password)を指定して、'testdb' という名前のデータベースインスタンスを remoteDB 変数に代入します。これで IBM Cloudant 上のリモートデータベースを remoteDB から操作できるようになりました。同時にローカルブラウザ内に(同じ名前の)'testdb' という名前のデータベースインスタンスを作って localDB 変数に代入しています(こちらは作成時点では空です)。 この2つのリモート/ローカルデータベースを sync() 関数で同期するように指定しています。これによってこれら2つのデータベースインスタンス変数の内容は自動同期され、一方(例えばブラウザ内の localDB)に変化が起こるともう一方(サーバーの remoteDB)にその変化内容が勝手に反映される、という仕組みが実現できます。

ちなみに sync() 実行時の live:true オプションはリアルタイム同期の指定で、retry:true オプションは一度接続が切れた後に自動的にリトライして接続が戻った時に同期も復活させるための指定です。ここまでは超簡単です。


さて、本来やりたかったのはデータベースをまるごと同期するのではなく、データベースの一部だけを同期する、というものです。上記例だと remoteDB はサーバー側のものなので、全部で数ギガバイトになったりそれ以上になったりすることも想定しないといけないのですが、localDB はブラウザ内で作るものなのであまり大きくなっては困ります。そこで(一般的には部分同期とか Partial Sync とか呼ばれる方法で)特定条件を満たす一部の文書だけを対象にローカルに同期し、ローカルでの変更・追加・削除といった処理をサーバー側のマスターに同期し直す方法を紹介します。

PouchDB にも部分同期機能は存在しています。ただそこで「この条件を満たす文書だけ」を指定する方法がかなり限られていて、現時点では文書 ID を配列で指定する方法しかないように見えます(このフィールドがこの値で・・・みたいなクエリーではできないっぽい)。具体的にはこんな感じ:
  :
  :
<html>
<head>
<script src="https://cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var localDB = new PouchDB( 'testdb' );
var remoteDB = new PouchDB( 'https://db_username:db_password@db_username.cloudant.com/testdb' );

var doc_ids = [ 'xxx', 'yyy', 'zzz' ];  //. 同期対象文書の _id 値配列

remoteDB.sync( localDB, {
doc_ids: doc_ids,
live: true, retry: true }); : :

上記例では 'xxx', 'yyy', 'zzz' という3つの文書ID(Cloudant 内だと文書の _id の値)を指定して、sync() 関数を doc_ids パラメータで配列指定しています。これだけで localDB には指定された3文書だけが同期され、削除を含めた変更があるとリモートにも即時に反映されるようになります。

したがって実装する場合はページロード時の最初に IBM Cloudant に対してクエリー API を実行して同期の対象となる文書(の ID 配列)をまとめて取得し、その ID 配列を指定して PouchDB と部分同期する、という流れになると思っています。この方法なら最初のロード時のネットワーク接続は必須になりますが、どのみちページをロードするにもネットワークは必須だし、同期をとった後はネットワークが切れても平気、というシステム構成が可能になります。


なお、一点だけ注意が必要なことがあります。この方法で部分同期した後に localDB に新たに文書を追加した場合です。部分同期の条件は doc_ids に指定された文書ID配列だったので、ここに含まれない新しい文書を追加してもサーバー側には同期されません。その場合は新たに doc_ids を指定しなおして(新しい文書の ID を追加して)改めて sync() 関数を実行する必要があります:
  :
  :
<html>
<head>
<script src="https://cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var localDB = new PouchDB( 'testdb' );
var remoteDB = new PouchDB( 'https://db_username:db_password@db_username.cloudant.com/testdb' );

var doc_ids = [ 'xxx', 'yyy', 'zzz' ];

remoteDB.sync( localDB, {
doc_ids: doc_ids, live: true, retry: true }); : : function add( doc ){ //. ドキュメントを追加する処理 localDB.put( doc ).then( function( res ){ //. localDB に文書(doc)追加 doc_ids.push( doc._id ); //. 文書の _id 値を配列に追加 remoteDB.sync( localDB, { //. sync() 再実行 doc_ids: doc_ids, live: true, retry: true }); }).catch( function( err ){ console.log( err ); }); }

例えば上記例では add( doc ) 関数の中で doc に指定されたオブジェクトを localDB に追加する想定で処理を記述していますが、localDB.put() が成功したら doc_ids 配列を更新した上で remoteDB.sync() を再実行して同期条件を変えるようにしています。

現実問題としては追加なのか更新なのか(どちらも put() 関数を使う)、更新だとすると _rev の値も必要になって・・・とか、多少細かい実装が必要になることも事実ですが、一応これだけでローカルDBとその部分同期を使ったアプリの実装はできることになります。

問題は上述したローカルDBに同期したい文書の ID をどうやって調べるかですが、そこはやっぱり一度サーバーにクエリー投げるしかないのかなあ・・・


なお、PouchDB の API Reference はこちらを参照ください:
https://pouchdb.com/api.html


IBM Cloud(Bluemix) から提供されている NoSQL データベースの DBaaS である Cloudant は読み書きのための REST API が公開されています。各種プログラミング言語から HTTP ベースの API を実行してデータを読み書きすることが可能です。

ただ、これらの API には一般的な CORS(Cross-Origin Resource Sharing) の制限がかかっており、ウェブブラウザの JavaScript からは読み書きができないように設定されています。この CORS 制限を無効にする方法が分かったので、ブログで紹介する形で手順等を紹介します。

まず今回ブラウザからアクセスする対象とするデータベースをこちらとします。pouchdb というデータベースで、現在4件のドキュメントが登録されています:
2018040900


このデータベースに簡単にアクセスするため、今回は PouchDB ライブラリを使うことにします。PouchDB は軽量かつ CouchDB(Cloudant) 互換のデータベースです。この PouchDB を CDN(//cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js) からロードして、データベースオブジェクトを作り、その中の全文書を取り出して表示する、という処理を実装すると↓のような感じになります:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>CORS check</title>
<script src="//cdn.jsdelivr.net/pouchdb/5.4.5/pouchdb.min.js"></script>
<script>
var cloudant_db_url = 'https://USERNAME:PASSWORD@USERNAME.cloudant.com/pouchdb';

var db = new PouchDB( cloudant_db_url );

db.allDocs( { include_docs: true } ).then( function( docs ){
  console.log( docs );
}).catch( function( err ){
  console.log( 'error' );
});
</script>
</head>
<body>
</body>
</html>

主な処理内容を簡単に解説します。まず CDN から PouchDB ライブラリをロードし、Cloudant のデータベース URL を指定して、データベースオブジェクトを作ります(上記の USERNAME は Cloudant のユーザー名、PASSWORD は同パスワードです)。そして allDocs() メソッドで全文書を取り出して結果を console.log() でコンソールに表示する、という内容の JavaScript を含む HTML になっています。


この HTML を HTTP サーバー上に配置してウェブブラウザからアクセスします。取得結果はコンソールに表示されるので、あらかじめコンソール画面を表示(FireFox であれば F12 キー)しておきます。その状態でブラウザから同ページにアクセスすると・・・コンソールには「クロスオリジン要求・・」というエラーが表示されます。これはつまり Cloudant 側でクロスオリジンからのアクセスを許可していないため、アクセスは拒絶され、そのエラーが表示されています。これが Cloudant のデフォルトでの挙動です:
2018040901


では Cloudant の CORS アクセス(クロスオリジンからのアクセス)を有効にしてみます。curl コマンドの使えるターミナルから、以下のコマンドを実行します:
$ curl -i -u 'USERNAME:PASSWORD' -XPUT 'https://USERNAME.cloudant.com/_api/v2/user/config/cors' -H 'Content-type: application/json' -d '{"enable_cors":true,"allow_credentials":true,"origins":["*"]}'

このコマンドでは認証用の ID とパスワード、HTTP ヘッダの Content-Type: application/json を指定し、/_api/v2/user/config/cors パスに対して、CORS アクセスを有効にするようデータを POST して実行しています:

2018040902


上記のように {"ok": true} という結果が返ってくればコマンドは成功し、クロスオリジンからのアクセスも許可されています。試しに再度同じ HTML ページを(リロードするなどして)表示すると、今度は allDocs() メソッドが成功し、期待通りに(4件の)データを取得し、コンソールに表示できているはずです:
2018040903


これで Cloudant の API をブラウザ(の JavaScript )からも直接実行する術が確保できました。これでウェブブラウザの HTML から直接 Cloudant を操作したり、ウェブブラウザ内の PouchDB と連携することもできるようになります。



(参考)
How to use CORS with a Cloudant account

CORS


この記事の続きです:
IBM Cloud のブロックチェーンサービスを使う(前編)
IBM Cloud のブロックチェーンサービスを使う(中編)


IBM Cloud から提供されているマネージド・ブロックチェーン・サービスを使う手順を紹介しています。前編ではベータ版で無料(2018/03/27 時点)のサービスインスタンスである Starter Membership Plan の作成手順を紹介し、中編ではこのサービスインスタンスを Hyperledger Composer のカードファイルを使ってセットアップしました。今回の後編ではこのインスタンスに実際にビジネスネットワークをデプロイして動かすまでの手順を紹介します。なおあくまでベータ版であり、今後の仕様変更等により以下の内容は正しい情報ではなくなる可能性もあります。以下の内容は 2018/03/27 時点での情報であることをご了承ください。


【BNA(Business Network Archive)ファイルの準備】
まずはデプロイするビジネスネットワークを用意します。IBM Cloud のブロックチェーンサービスはオープンソースのブロックチェーン基盤である Hyperledger Fabric をベースとしており、関連プロダクトである Hyperledger Composer もサポートしています。ビジネスネットワークは Hyperledger Composer や Hyperledger Composer Playground を使うと BNA(Business Network Archive)ファイルとして比較的簡単に定義することができるので、今回はこの方法を使います。

すでに BNA ファイルをお持ちであれば、そのファイルを使っていただいても構いません。お持ちでない場合は私が github.com で公開しているこちらのコードを使ってください:
https://github.com/dotnsf/bcdev-basickit

↑この公開プロジェクトは名前の通り、bcdev(BlockChain DEVelopment) の BasicKit として開発・公開したものです。Hyperleger Fabric & Hyperledger Composer を使って、ごくシンプルなビジネスネットワークを作り、そのビジネスネットワーク上で動作する API とサンプルアプリケーションが含まれています。簡単に言えば「ブロックチェーン開発の雛形キット」として開発したものです。


上記リポジトリを(Node.js を導入したシステムに)ダウンロードするか git clone して、一連のファイルを手元に用意してください。そしてこの中の /api/bcdev-basickit-network.bna というファイルが Hyperledger Composer 用のビジネスネットワーク定義ファイルになっています。以降の説明はこの bcdev-basickit-network.bna ファイルを前回説明&作成した IBM Cloud のブロックチェーンサービスにデプロイすることを目的に説明します:
2018032601



【BNA(Business Network Archive)ファイルのデプロイ】
まずは中編のおさらいを兼ねて、ここまでに設定した内容と、この bcdev-basickit アプリケーションを動かすために設定する内容を記載しておきます。まずは前回の設定内容がこちら:
項目設定値
作成した管理者向けのカード名admin@fabric-network
上記管理者の公開鍵ファイル~/.identityCredentials/admin-pub.pem
上記管理者の秘密鍵ファイル~/.identityCredentials/admin-priv.pem
接続プロファイル~/mychannel1/connection.json


そして、今回動かそうとしている bcdev-basickit アプリケーションが想定しているブロックチェーン上のビジネスネットワークの設定がこちらです:
項目設定する値
アプリケーションの実行ユーザーのカード名※admin@bcdev-basickit-network
アプリケーションの BNA ファイル./api/bcdev-basickit-network.bna


※Hyperledger Composer に慣れていないとわかりにくいかもしれませんが、/api/settings.js の中でカード名を指定していて、ここで指定したカード名でビジネスネットワークにアクセスできるよう設定されている前提でアプリケーションが作られています。またビジネスネットワークそのものは api/ フォルダの下にある bcdev-basickit-network.bna ファイルで定義されています。このファイルを指定してデプロイします。

では composer コマンドを順次実行して設定していきます。まず最初に admin@fabric-network の管理者でビジネスネットワークアーカイブファイルをデプロイします:
$ composer runtime install --card admin@fabric-network --businessNetworkName bcdev-basickit-network
  (↑空のビジネスネットワークを作成)
$ composer network start --card admin@fabric-network --networkAdmin admin --networkAdminEnrollSecret adminpw --archiveFile ./api/bcdev-basickit-network.bna --file admin@fabric-network.card
  (↑空のビジネスネットワークにユーザー名(admin)と BNA ファイルを指定してデプロイ)

【アクセス用カードファイルの準備とインポート】
ここまでの作業が成功すると、ブロックチェーンサービス上でビジネスネットワークが稼働している状態になります。このままでも使えないことはないのですが、一般的には個別のビジネスネットワークにアクセスするための個別のユーザー(カード)を作って利用します。特にこの bcdev-basickit-network というアプリケーションでは(デフォルト状態では)admin@bcdev-basickit-network というカードでアクセスすることを想定して開発されているので、このカードを作ってインポートします:
$ composer card create -n bcdev-basickit-network -p connection.json -u admin -c ~/.identityCredentials/admin-pub.pem -k ~/.identityCredentials/admin-priv.pem
  (↑このビジネスネットワークにアクセスするためのカード(admin@bcdev-basickit-network)を作成)
$ composer card import -f admin@bcdev-basickit-network.card
  (↑新たに作成したカードをインポート)
$ composer card list
  (↑カードの一覧を表示して、結果に admin@bcdev-basickit-network が含まれることを確認)

カードの一覧に admin@bcdev-basickit-network が含まれていることを確認します:
2018032602


最後に admin@bcdev-basickit-network がビジネスネットワーク上で正しく動いている(アクセスできる)ことを確認します:
$ composer network ping -c admin@bcdev-basickit-network
  (↑admin@bcdev-basickit-network への ping が成功することを確認)

この結果が "Command succeeded" になればデプロイされたビジネスネットワークを使う準備が整ったことになります:
2018032603


【ブロックチェーンアプリケーションの利用】
ここまでの準備が整っていればアプリケーションからビジネスネットワークを利用することができます。今回用意したモジュールには Swagger ベースの API Document が含まれているので、これを動かしてみましょう。

Swagger API Document は api/public/doc フォルダ内にあります。つまり api フォルダ内でアプリケーションを実行するのですが、一部設定項目があります。そのためにまずは一度アプリケーションを実行します:
$ cd api
  (↑ api/ フォルダへ移動)
$ npm install
  (↑ライブラリのインストール)
$ node app
  (↑アプリケーション実行)

実行が成功すると "server starting on XXXX ..." というメッセージが表示されます。この "XXXX" という部分(下図の場合 6017)をメモします:
2018032604


一旦アプリケーションを終了し(Ctrl+C)、api/public/doc/swagger.yaml ファイルをテキストエディタで開きます。そして6行目の host: で始まる行の続きを このシステムの IP アドレス:XXXX という内容に書き換えて保存します:
2018032605


もしこのアプリケーションを手元のシステムではなく IBM Cloud などのパブリッククラウド上のアプリケーションサーバーにデプロイして実行する場合は、この host の値をアプリケーションサーバー名に書き換えて保存してください。

保存後、あらためてアプリケーションを実行し、ウェブブラウザで /doc/ パスにアクセスすると、Swagger Open API ドキュメントの画面が表示されます(Basic URL の値が swagger.yaml で編集した host の値になっていることを確認してください):
2018032606


(注 IBM クラウドの Cloud Foundry ランタイムで実行している場合は、API ドキュメントのスキーマを HTTP から HTTPS に変更してから以下を実行してください)
2018032705



この画面はブロックチェーンサービスと接続された API サーバーのインタラクティブドキュメントになっているので、実際に動かすことが可能です。一例としていくつかの処理を実行してみましょう。まずは管理ユーザーを作成するために POST /api/adminuser と書かれた項目をクリックして展開します。するとこの API に関する説明が表示されると同時に、"Try it out" というボタンが表示され、ここをクリックすると実際に実行することができます:
2018032605a


この API では管理ユーザー(admin)のパスワードを生成します。仮にパスワードを P@ssw0rd とする場合は { "password": "P@ssw0rd" } という JSON を指定します。最後に Execute をクリックします:
2018032607


実行結果や実行内容が画面下部に表示されます。ここで行った処理を curl コマンドで実行する場合のコマンドなども表示されます。以下の例では実行結果として HTTP コード 200 が返り、{ "status": true } という本文が戻されました。API 実行コマンドは成功して、このアプリケーションの管理者をブロックチェーン内に作成することができたようです:
2018032608


では作成したユーザーでログインしてみましょう。API Document 画面の1つ下に POST /api/login という API があり、この API でログイン処理を行うことができます。この項目を選択して展開し、同様に "Try it out" をクリックします:
2018032701


この API では { "id": "ユーザーID", "password": "パスワード" } というフォーマットの JSON でログインパラメータを渡します。最初はわざと間違えてみることにするので、{ "id": "admin", "password": "string" } というパラメータを指定して、"Execute" をクリックしてみます(正しいパスワードは上記で設定した値 "P@ssword" です):
2018032702


この API が実行されて、結果が出力されます。HTTP コードは 401、実行結果本文は { "status": false, "message": "Not valid id/password." } が得られました。一応期待通りの結果といえます:
2018032703


改めて正しい内容でログインしてみます。実行パラメータを { "id": "admin", "password": "P@ssw0rd" } に変更して再び "Execute" をクリックします:
2018032704


今度は成功して、HTTP ステータス 200 が返ってきました:
2018032705


なお、このログインに成功した時の実行結果本文は以下のような JSON になっています:
{
  "status": true,
  "token": "XXXXXXXXXXXXX(トークン文字列)XXXXXXXXX"
}

この token の値がログインに成功した証となるトークンで、他の API 実行時に必要になります(実際のアプリケーションではセッションなどに保管して使うことを想定しています)。例えばユーザーの一覧を取得する API である GET /api/users ではここで取得したトークン文字列をパラメータとして指定する必要があります:
2018032706


わざと何も入力しなかったり、適当な文字列を入力してこの API を実行しても、{ "status": false, "message": "Invalid token" } とだけ返ってきます:
2018032707


一方、先程のログイン時に取得したトークンの値をここに指定してから実行すると、ユーザーの一覧(この時点では admin ユーザーのみ)が取得できることが確認できます:
2018032708


【ブロックチェーンの管理】
こんな感じでブロックチェーンを読み書きできるような REST API を定義するアプリケーションがデプロイ/実行できることが分かりました。実際にはこれ以外にもユーザーを新規に作成したり(POST /api/user)、ユーザーが所有する商品を新規に作成したり(POST /api/item)、その商品の一覧を取得したり(GET /api/items)する API が提供されています。興味があればこれらも使ってみてください。


最後に、何回かブロックチェーンに対してトランザクションを実行した後でブロックチェーンサービス側がどのようになっているかをダッシュボードから確認する方法を紹介します。ダッシュボード画面でチャネルメニューを選択すると、利用中のチャネル一覧が表示されますが、その中の「ブロックの高さ」という数値がブロックチェーン上に記録されているブロックの数を表しています(前回の画面ではここは2でしたので、いくつか積み重なっていることがわかります):
2018032701


該当行をクリックして先に進むと、更に詳細な情報を見ることが出来ます。例えば下図の一番上にあるブロックの ">" をクリックして展開します:
2018032702


「アクション」メニューから「詳細の表示」を選択すると:
2018032703


このブロックで実行された内容や実行結果を確認することもできます。こういった管理機能が初めから提供されていたり、ストレージなどのインフラ環境を意識する必要がなくなることもマネージドサービスのメリットと考えることができます:
2018032704


【感想】
以上、ここまで3回に渡って IBM Cloud のマネージド・ブロックチェーンサービスの使い方を紹介してきました。最後にこのサービスを使ってみた上での感想に触れておきます。

まず、これまで自分は業務内外で Hyperledger Fabric ベースのブロックチェーン環境やアプリケーションを構築・開発・運用してきました。慣れもあって構築作業(正確には「開発用途での構築作業」)そのものはあまり苦にならないレベルの作業になっています。ただ起動や停止、再起動といったプリミティブな作業も含めて、構築したブロックチェーン環境のインフラを管理するのはやはり面倒で、本来の目的(この場合は開発用途)を考えると苦痛を伴うものでした。その点から開放されて、開発やテストに注力できる意味や意義は小さくないと感じています。

また「ブロックチェーン内の各ブロックの様子を確認する」というよくある要望に対する機能もサービス内に標準装備されています(これまではそのための参照アプリを別途用意する必要があった)。これによってデバッグの効率も上がりました。このあたりは「マネージドサービスらしい」機能が提供されていると感じます。

一方で、個別アプリケーションをデプロイするまでの手順についてはもう少し簡略化できるのではないかとも考えます。(2018/03/27 時点での)現状の「空の管理者ユーザーを一度作って、ファイルをダウンロードしたら、ユーザーを消してまた管理者ユーザーを作り直してアップロードし直して・・・」という作業は改善の余地があるようにも感じています。この辺りは時間が解決してくれることを期待します。


改めて、このようなブロックチェーンのマネージドサービスが(ベータ版とはいえ)無料で提供されていることは素晴らしいです。興味ある方は是非使ってみていただきたいです。


このページのトップヘ