読者です 読者をやめる 読者になる 読者になる

オープンソースのブロックチェーンHyperledger Fabricのv1.0をUbunts16.04にインストール

オープンソースのブロックチェーンHyperledger Fabricのv1.0αがリリースされていたのでインストールして触ってみる。
当初のリリーススケジュールどおりではありますが、3月にV1.0は無理じゃないかと思っていたら何とか出てきたので結構凄いですね。中の人たちお疲れ様です。

ちなみに以前のバージョン0.5以前の手順は以下
garapon.hatenablog.com

ちょっと前からですがVagrantが使われなくなったりと構築方法もだいぶ変わっていますね。
対象のマシンはProxy環境下にあるWindows上のVirtualBoxに構築されているまっさらなUbunts16.04でやってみます。

手順

Getting Setup — hyperledger-fabricdocs master documentation

本家サイトの上記手順に従ってやっていきます。

事前準備

Go - most recent version
Docker - v1.13 or higher
Docker Compose - v1.8 or higher
Node.js & npm - node v6.9.5 and npm v3.10.10
xcode - only required for OS X users
nvm

を入れなさいと書いてあるので順次入れていきましょう。
なにはともあれPorxyの設定

set http_proxy=http://proxy:port
set https_proxy=http://proxy:port

やれやれですね。

Golangのインストール

sudo apt-get -y install golang

DockerおよびDocker Composeのインストール

sudo apt-get -y install docker.io docker.compose
sudo usermod -aG docker gara

docker-composeの最新版

curl -L --proxy http://proxy:port "https://github.com/docker/compose/releases/download/1.8.1/docker-compose-$(uname -s)-$(uname -m)" > docker-compose
sudo mv docker-compose /usr/bin/
sudo chmod +x /usr/bin/docker-compose

なお、 curl は プロキシの設定が --proxy http://proxy:port なので気をつけましょう。

nvmのインストール(というかnodeを入れたいだけ)

途中でGitにプロキシを通すのを忘れずに

sudo apt-get -y install build-essential libssl-dev
git 
git config --global http.proxy  http://proxy:port
git config --global https.proxy  http://proxy:port
curl  -o- --proxy http://proxy:port https://raw.githubusercontent.com/creationix/nvm/v0.25.2/install.sh | bash

インストールが終わるとClose and reopen your terminal to start using nvmといわれるので再接続。
本来の手順的には

nvm install v6.9.5

でnodeをインストールするんだけど、うまくいかなかったのでnvmコマンドをつかうのはやめて、nコマンドを入れて

sudo n 6.9.5

でインストールしました。
nコマンドのインストールは以下参照
garapon.hatenablog.com

さて、これで事前準備が完了。
いつも思うけど、事前準備が一番めんどくさいよね。。。まあそんなもんか

作業ディレクトリの作成とサンプルのDL

mkdir hackfest
cd hackfest
curl -L https://raw.githubusercontent.com/hyperledger/fabric/master/examples/sfhackfest/sfhackfest.tar.gz -o sfhackfest.tar.gz 2> /dev/null;  tar -xvf sfhackfest.tar.gz

Dokcerの起動!!!

Dockerあげる前にこれまたproxy設定。
/etc/default/dockerに

export http_proxy="http://proxy.example.com:3128/"

的な感じでProxyを追加して

sudo service docker restart

これやってから

docker-compose -f docker-compose-gettingstarted.yml build
docker-compose -f docker-compose-gettingstarted.yml up -d

起動確認!

$ docker ps
CONTAINER ID        IMAGE                                                          COMMAND                  CREATED             STATUS              PORTS                                            NAMES
397d7b0a4376        sfhackfest22017/fabric-peer:x86_64-0.7.0-snapshot-c7b3fe0      "sh -c './channel_tes"   23 seconds ago      Up 22 seconds                                                        cli
8a3ed98c6d08        sfhackfest22017/fabric-peer:x86_64-0.7.0-snapshot-c7b3fe0      "peer node start --pe"   23 seconds ago      Up 22 seconds       0.0.0.0:8056->7051/tcp                           peer2
5f180d32588c        sfhackfest22017/fabric-peer:x86_64-0.7.0-snapshot-c7b3fe0      "peer node start --pe"   24 seconds ago      Up 23 seconds       0.0.0.0:8055->7051/tcp                           peer1
7b39214c0e7a        sfhackfest22017/fabric-peer:x86_64-0.7.0-snapshot-c7b3fe0      "peer node start --pe"   24 seconds ago      Up 23 seconds       0.0.0.0:8051->7051/tcp, 0.0.0.0:8053->7053/tcp   peer0
baeab3a755de        sfhackfest22017/fabric-orderer:x86_64-0.7.0-snapshot-c7b3fe0   "orderer"                28 seconds ago      Up 25 seconds       0.0.0.0:8050->7050/tcp                           orderer
2e7bf4172c7f        sfhackfest22017/fabric-ca:x86_64-0.7.0-snapshot-6294c57        "sh -c 'sleep 10; fab"   28 seconds ago      Up 26 seconds       0.0.0.0:8054->7054/tcp                           ca

6個動いてますね。

つないで確認して見る

$ docker exec -it cli bash
root@397d7b0a4376:/opt/gopath/src/github.com/hyperledger/fabric/peer# cat results.txt
SUCCESSFUL CHANNEL CREATION
SUCCESSFUL JOIN CHANNEL on PEER0
SUCCESSFUL JOIN CHANNEL on PEER1
SUCCESSFUL JOIN CHANNEL on PEER2

全部成功ですね。
ジェネシスBlockも出来ています。

これでインストールは終わり。
あとは本家手順に従ってサンプルを動かすも良し、以前のバージョンのChainCodeを動かすも良し。やり放題です。

おれおれ証明書でHTTPS

数年に1回思い出したくて思い出せないシリーズ

秘密鍵作成
cd /etc/httpd/conf
openssl genrsa -aes128 1024 > server.key

公開鍵作成
openssl req -new -key server.key > server.csr
CommonNameのところに証明したいアドレスを入力

証明書作成
openssl x509 -in server.csr -days 36500 -req -signkey server.key > server.crt

パスフレーズを消す
openssl rsa -in server.key > server.key

アパッチに設定
/etc/httpd/conf.d/ssl.conf
の
<VirtualHost _default_:443>
のなかに
  SSLCertificateFile /etc/httpd/conf/server.crt
  SSLCertificateKeyFile /etc/httpd/conf/server.key

非Pageプールのメモリリーク調査

いつでもリモート接続できるようにPCは24時間起動しているのですが、最近どうも非ページが増える。
日々仕事が終わるとログオフしているのですが、だんだんとメモリを圧迫するようになります。消費量を見ているとメモリリークしているような動き
圧迫するといってもメモリは16Gつんでいるので微々たる物なのですが、なんか気になるのでどのドライバが悪いか調べてみた。

環境構築

まず、非ページを調査するには通常のツールでは調査が出来ないので以下のWidowsKitをインストールしましょう。
https://developer.microsoft.com/en-us/windows/hardware/windows-driver-kit

そうすると「C:\Program Files (x86)\Windows Kits\8.1\Tools\x86」の下に「poolmon.exe」がインストールされます。
早速起動して「P」で非ページに切り替え、「B」をおしてバイトでソートして状態を見ます。
メモリリークの調査なので、スナップショットを取りながら時間経過に合わせて変化を見ていきます。

初期状態 (非ページ377K)

 Memory:16703856K Avail:10192424K  PageFlts: 45698   InRam Krnl:15512K P:1333648K
 Commit:7214488K Limit:33405852K Peak:7517640K            Pool N:386452K P:1340480K
 System pool information
 Tag  Type     Allocs            Frees            Diff   Bytes       Per Alloc

 Cont Nonp        299 (   0)         0 (   0)      299 119050528 (     0) 398162
 File Nonp   21722082 (2024)  21619437 (1973)   102645 34309552 ( 17136)    334
 Ntfx Nonp     159171 (  57)     58352 (   0)   100819 33510608 ( 20064)    332
 MmCa Nonp     311617 (  62)    217467 (  11)    94150 24031792 ( 13056)    255
 SASC Nonp     384095 (  65)    285364 (  21)    98731 22115744 (  9856)    224
 NDam Nonp   10178797 (  62)  10171261 (  62)     7536 21542208 (     0)   285
 FMsl Nonp     153875 (   0)     52316 (   0)   101559 19499328 (     0)    19
 SAds Nonp      93946 (   0)     23333 (   0)    70613 11298080 (     0)    16
 SAHC Nonp     573641 (   4)    513005 (   4)    60636 10671936 (     0)    17
 Pool Nonp         21 (   0)        15 (   0)        6 6481488 (     0) 108024
 MmSd Nonp      46292 (   0)      6783 (   0)    39509 5057152 (     0)    128
 IWA1 Nonp          2 (   0)         0 (   0)        2 4276224 (     0) 213811
 IPRT Nonp       9482 (   0)      6753 (   0)     2729 4230912 (     0)   1550
 FSro Nonp      63606 (   0)     14218 (   0)    49388 3951040 (     0)     80
 CcSc Nonp     414102 (   1)    407959 (   1)     6143 3243504 (     0)    528
 Even Nonp    3772437 (  23)   3747492 (  27)    24945 3203072 (  -512)    128

ある程度時間がたってから再度見る(非ページ 585K)

 Memory:16703856K Avail:11056936K  PageFlts: 16348   InRam Krnl:15276K P:1370544K
 Commit:5581508K Limit:33405852K Peak:7517640K            Pool N:599476K P:1386248K
 System pool information
 Tag  Type     Allocs            Frees            Diff   Bytes       Per Alloc

 NDam Nonp   36289071 (5044)  36197666 (5026)    91405 235410352 ( 54512)   2575
 File Nonp   98943505 ( 330)  98864305 ( 350)    79200 26339936 ( -6720)    332
 Ntfx Nonp     456363 (   3)    379195 (   0)    77168 25332768 (  1056)    328
 MmCa Nonp     972089 (   4)    900970 (   5)    71119 18144160 (  -256)    255
 SASC Nonp     946229 (   4)    870851 (   1)    75378 16884672 (   672)    224
 FMsl Nonp     455619 (   3)    378491 (   0)    77128 14808576 (   576)    192
 Pool Nonp         34 (   0)        28 (   0)        6 12772944 (     0) 2128824
 SAHC Nonp    2474859 (  36)   2438128 (  36)    36731 6464656 (     0)    176
 SAds Nonp     262415 (   3)    223364 (   0)    39051 6248160 (   480)    160
 NDCM Nonp   23741528 (  14)  23731739 (2186)     9789 4862656 (-340032)    496
 IWA1 Nonp          2 (   0)         0 (   0)        2 4276224 (     0) 2138112
 FSro Nonp     110027 (   0)     59384 (   0)    50643 4051440 (     0)     80
 ViMm Nonp    3437661 (   0)   3432804 (   0)     4857 2947104 (     0)    606
 MmCi Nonp       9156 (   0)      3507 (   0)     5649 2755296 (     0)    487
 Even Nonp   15897548 ( 163)  15876868 ( 156)    20680 2657088 (   896)    128
 CcSc Nonp    1687317 (   1)   1682468 (   6)     4849 2560272 ( -2640)    528
 Thre Nonp     225296 (   1)    223367 (   4)     1929 2494576 ( -3888)   1293
 Mm   Nonp     905203 (   0)    905193 (   0)       10 2021920 (     0) 202192
 VoSm Nonp       1530 (   0)      1498 (   0)       32 1908320 (     0)  59635
 IWBX Nonp          3 (   0)         0 (   0)        3 1852560 (     0) 617520

行見てみるとだんだんとNDamが増えており怪しい。

ドライバーの調査

タグがわかったらドライバを調査。
タグ名からドライバを探すには強引に「findstr」で文字列検索。力技でいきましょう。
ドライバがあるディレクトリに移動して

C:\>cd C:\Windows\System32\drivers
C:\Windows\System32\drivers>findstr /m /l NDam *.sys
ndis.sys

悪さしているっぽいドライバーが見つかったのでこいつについて調べてみる。
ndis.sysはNetwork Device Interface Specificationフィルタドライバのことで、つまりネットワーク関係のデバイスっぽい。

さらにドライバクエリで見てみる

driverquery /V
モジュール名 表示名                 説明                   ドライバーの  開始モード 状態       ステータス 停止の受理  一時停止の受 ページ プ  コード(バ  BSS(バ リンク日時             パス                                             Init(バイ
============ ====================== ====================== ============= ========== ========== ========== =========== ============ ========== ========== ====== ====================== ================================================ ==========
NDIS         NDIS System Driver     NDIS System Driver     Kernel        Boot       Running    OK         TRUE        FALSE        397,312    348,160    0      2015/10/13 12:30:31    C:\Windows\system32\drivers\ndis.sys             24,576

確かに起動時から読み込まれて今も動いている。

メーカーのHPからネットワーク系ドライバーを落として来てあててみても更新されないしな、、、、うむむむむ
まあ適宜再起動すればよいかな。

APIマネジメント製品あれこれの比較

もう何度目なのかわかりませんがAPIブームが来ています。
APIを提供する側として考えたときにはずすことができないのがAPIマネジメント製品。
APIGatewayとかAPIManagementとか、いろんな呼び方で呼ばれますが、やりたいことはAPI の作成、配布、保守、監視、保護を簡単にというもの。
簡単に言うと
・既存サービスにRESTFulエンドポイントを簡単に作成もしくはプロトコル変換してくれて
・作成したAPIをカタログしてDeveloperに公開し
・そとからのアクセスについてはセキュリティをしっかり保護して
アクセスログや課金情報とかも管理して
・アクセスが増えたらいい感じでスケールする
というようなことをするツールが必要だということです。


主力商品を整理すると私が把握しているのは以下7つ。()は提供企業です。

  1. apigee edge/Google edge(Google)
  2. IBM API Connect(IBM)
  3. Amazon API GatewayAmazon
  4. API Manager(WSO2)
  5. 3Scale(Redhat)
  6. Kong(Mashape)
  7. CA API Management(CA Technologies)

いろんな製品がありますが、管理基盤というだけあって求められる要件が明確なのでほぼ機能面に差異はありません。(ちょっと前までは差異がいろいろあったのですが、各社弱みの部分をM&Aして統合したりして大体どの製品もフルスタックな機能を取り揃えている状態です)
OSSだったり、提供形態がSaaSのみなのか、オンプレ構築可能かといったもが目に見える差異で、重要なのは非機能で差がついてくると考えます。
エンタープライズ企業だったら日本でどれだけサポートが得られるかとかですね。

apigee edge/Google edge(Google)

Apigee
一番メジャーで機能、実績ともに強い製品。
上場後ジェットコースターの株価でどうなることかと思ったらGoogleに買収されてしまった。
世界でも実績が多く、世界でもAT&T、Bechtelとかでかい企業が使っている。日本でもでかい会社で使われており実績が凄い。
数年前に日本法人も出来てサポートも安心。
値段もそれほど高くなくエンタープライズならこれいれとけという製品。懸念点はGoogleに買収されてしまったので今後方針が変わることがあるかもというリスク。

IBM API Connect(IBM)

IBM API Connect
ちょっと前までAPIManagerという製品で2016年にStrongLoopを買収して欠点を補ってAPIConnectとなりました。
IBM Bluemix上にも構築されておりSaaS利用はそちらへという流れ。
実績があるのはオンプレ版だが、DataPower上で稼動するため、ちゃんとした構成を作るとライセンス費だけですごく高い。
すでにIBMマシンをたくさん持っているお金持ち企業向け

Amazon API GatewayAmazon

Amazon API Gateway (API を簡単に作成・管理) | AWS
AWS上にサービスがあったらこれでしょうね。
当たり前ですが、オンプレに入れられない。
オンプレからの切り出しはOSS製品で切り出して、対外からのアクセスはAWS上で裁くというのもあり。

API Manager(WSO2)

WSO2 API Manager - 100% Open Source API Management Platform
OSS製品の中では一番機能充実しており実績もある。Stack Overflowも活性。
OSS製品ではIntegrationとManagementが両方そろっているのはこれだけ。
他のツールが大手に食われている中で、今後プレゼンスを出していけるのかどうかにかかっている。
日本法人などがなく日本国内のサポートは薄いのがエンタープライズから見ると課題。
社内に技術力ある会社が自分でバリバリやるならこれかな。

3Scale(Redhat)

3scale API Management Platform
めでたくRedhatに買収されて対Apigeeに力が入ると思われる。
早速国内でもいろいろやっている。Redhatと一緒にサポートしてもらえるのはなかなか良い。
OpenShiftでは覇権とれなかったけど、今度はどうなるか
レッドハット、3scaleのAPI管理ソリューションを国内販売 - クラウド Watch

Kong(Mashape)

Kong - Open-Source API Management and Microservice Management
SaaS提供はしていない。基本オンプレ構築。
機能が限定的なのでシンプルだがそれを良しと見るかどうか。特にAPI利用者向けの機能が弱い。
2015年に一部機能はOSS化され2017年からEnterprize向け製品を提供開始した。
MashapeがそのAPI管理プラットホームKongをオープンソース化 | TechCrunch Japan
ブリスコラ、API管理ソフト「Kong」のエンタプライズ向け製品を2017年1月から販売開始 - Kong開発の米Mashape社が認定する国内初のパートナー -|株式会社ブリスコラ のプレスリリース

CA API Management(CA Technologies)

API管理:統合 - CA Technologies
いろいろ出しているCAさんはAPIManagementも出してる。
自分的にあまり興味がなくて調べていない。。

まとめ

個人的には大きなエンタープライズならapigeeで自社サービスならWSO2かな

AWS Lambda関数のチューニング

Lambdaは便利ですが、性能チューニングで出来ることは結構限られ実質2つしかありません。
1つ目はリソース追加、2つ目はベストプラクティスに従いアプリを直すこと。

リソースの追加

Lambdaはリソースといってもメモリしかいじるところがありません。
CPUはメモリ量に応じて付与される設計になっているのでCPUを増やしたかったらメモリを増やしましょう。
とはいえメモリは最大1.5Gまでしか付与できず、メモリ1.5G時のCPUが最大になります。

Q: コンピューティングリソースはどのように AWS Lambda に割り当てられるのですか?

AWS Lambda のリソースモデルでは、お客様が関数に必要なメモリ量を指定するとそれに比例した CPU パワーとその他のリソースが割り当てられます。たとえば、256 MB のメモリを指定すると約 2 倍の CPU パワーが Lambda 関数に割り当てられます。128 MB のメモリを指定した場合と比較すると CPU パワーは倍となり、512 MB のメモリを指定した場合と比較すると半分になります。メモリは 128 MB から 1.5 GB まで、64 MB ごとに増加できます。

https://aws.amazon.com/jp/lambda/faqs/#functions

ベストプラクティスにしたがっているか確認する。

リソース的にいじれるのはメモリだけなので、メモリを1.5にしても遅かったら後はアプリを直すしかありません。
アプリを直すとしても大していじるところはなく、以下のベストプラクティスに従い見直すぐらいです。

- Lambda 関数はステートレススタイルで作成し、土台となるコンピューティングインフラストラクチャにコードが依存しないようにします。
- 接続の再利用を活用するために、ハンドラの範囲外で AWS のクライアントとデータベースのクライアントをインスタンス化します。
- Lambda がコードを実行できるように、アップロードした ZIP 内のファイルに対して +rx アクセス許可が設定されていることを確認してください。
- 現在のイベントの処理に直接関係しないスタートアップコードを最小限にすることで、コストを削減しパフォーマンスを改善します。
- 組み込みの CloudWatch モニタリング機能を利用して、Lambda 関数のリクエストのレイテンシーを表示し最適化します。
- もう使用していない古い Lambda 関数を削除します。

http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/best-practices.html

特に「データベースクライアントのインスタンス化の場所」と「直接関係しないスタートアップコードの削減」は効果があるのでこれはやるべきでしょう。
また不要なライブラリの同梱や使用を減らしコードサイズ自体を縮小することも効果があるようですが、一気に半減とかにはならないので覚悟しておきましょう。

そんなこんなでベストプラクティスに従って設計して、メモリも1.5Gで稼動させていたらもう打つ手はありません。
全体のアーキテクチャを考え直しましょう。
便利ですが、ちょっとしためんどくささもあるので使用するポイントは見極めて使いましょう。

BigIntegerの素数生成メソッドprobablePrimeはどの程度素数生成をミスるのか。

BigIntegerにこんなコンストラクタがあります。

public BigInteger(int bitLength,
int certainty,
Random rnd)

ランダムに生成された (おそらく素数である) 正の BigInteger を、指定したビット数で構築します。
確率を指定する必要がない場合は、このコンストラクタではなく probablePrime メソッドを使用することをお勧めします。

パラメータ:
bitLength - 返される BigInteger のビット長
certainty - 呼び出し側が許容しない確率の尺度。新しい BigInteger が素数である確率は、(1 - 1/2^certainty) より大きい。このインストラクタの実行時間はこのパラメータの値に比例する
rnd - 素数度をテストする候補の選択で使用されるランダムビットのソース

「ランダムに生成された (おそらく素数である) 正の BigInteger」
このおそらく素数ってのが気になります。

中で何をやっているのかとソースを追っていくと「isProbablePrime」という関数でミラーラビン素数判定法を使って素数チェックをしていると分かります。
Source for java.math.BigInteger (GNU Classpath 0.95 Documentation)


ミラーラビン素数判定法についてはWikiでも読みましょう。
ミラー–ラビン素数判定法 - Wikipedia


で、実際どれぐらいミスるのかというのですが「素数である確率は、(1 - 1/2^certainty) より大きい」といわれても実感わかないなーとおもったのでやってみたら
certaintyが1の時でも20万回~50万回に1回ぐらいしか失敗しなかった。。

デフォで使うとcertaintyは100なのでほぼほぼ素数といって問題なさそうですね。

Proxy環境下でnodeをインストールする時はnコマンドに注意。

Proxy環境下でUbuntus にnodeをインストールする際にnコマンドを使うと
途中プロキシを使ってくれないことがあるので注意しましょうというお話。

途中のnコマンドのエラーがこんなのがでて、何が原因かぱっとわからず時間がかかってしまった。

$ n stable
cp: '/usr/local/n/versions/node//bin' を stat できません: そのようなファイルやディレクトリはありません
cp: '/usr/local/n/versions/node//lib' を stat できません: そのようなファイルやディレクトリはありません
cp: '/usr/local/n/versions/node//include' を stat できません: そのようなファイルやディレクトリはありません
cp: '/usr/local/n/versions/node//share' を stat できません: そのようなファイルやディレクトリはありません

ぷろきしなんて大嫌いだ!

正しい手順はこちら。

$ sudo apt-get install -y nodejs npm
$ sudo npm -g config set proxy http://proxy:8080
$ sudo npm -g config set https-proxy http://proxy:8080
$ sudo npm cache clean
$ sudo npm install n -g
$ sudo su
# export  http_proxy=http://proxy:8080
# export https_proxy=http://proxy:8080
# n stable
# ln -sf /usr/local/bin/node /usr/bin/node
#node -v
v7.2.1
# npm -v
3.5.2


半年前の自分に助けられるとは。。。。。
garapon.hatenablog.com