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

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

タグ:idcf

IDC フロンティア様が運営する IDCF クラウドが(今の形になって)1周年を迎えました。おめでとうございます!
IDCF クラウド1周年記念キャンペーン!
2015112700


私自身は(当時はノアクラウドとか呼ばれてたと思うけど・・・まだ残ってるよね?)以前から IDC フロンティア様のクラウド利用させていただいていたので「1周年」という感覚はあまりないのですが、代名詞※にもなった「ワンコイン(=月額500円)」でありながら一級品のネットワークバックボーンを備えたこの IDCF クラウドが個人のウェブサービス運用では手放せないくらい便利で、使わせていただいています。

「500円 クラウド」で検索すると、広告を抜いたトップは IDCF クラウドになってます。

なお、以前に私が別クラウドを使っていて、IDCF クラウドに乗り換えた時の様子は当時のブログエントリにしているので、そちらも参照ください:
IDCFクラウドに乗り換えました


で、この「ワンコイン」のインスタンスは、IDCF クラウド的には light.S1 と呼ばれるマシンタイプのものです。スペックは 0.8GHz の vCPU 1つ、メモリ 1GB(ここまで200円/月)、ディスク 15GB(300円/月)、これをCentOS などの無料 OS で運用すると 200 + 300 = 500円/月 というものです:
2015112701
2015112702


実際にインターネットに公開するサービスを作ろうとすると、パブリック IP アドレスが必要になります。パブリック IP アドレスは1つに付き 500円/月 ですが、アカウントに対して最初の1つ目(ソースアドレス)は無料で提供されます。なので1インスタンス月額500円運用が可能になります:
2015112703


さて、では2台目のインスタンスを同じスペックで作るとどうでしょう。インスタンス自体は 500円/月ですが、2つ目以降のパブリック IP アドレスは 500 円/月です。つまり2台目以降は1台につき 1000 円/月かかる、ということになります。。。

月500円くらいケチケチすんな! という声が聞こえてきそうですが、でも割合で言えば 500 か 1000 かは倍違います。3台目、4台目となった時にそれなりの差が出てきてしまいます。また IDCF 以外でも IP アドレス付きで1インスタンス500円前後で提供している所はあるので、比較した際に価格的な差も生じてしまいます。

そんな理由で愛する IDCF クラウドが不利になるのは納得できない!

というわけで、2台目以降の light.S1 インスタンスを 500 円で使ってみました(IDC フロンティア様が期待しているのはそういう使い方じゃないかも・・・)。

まずサーバー用途でなく、クローラー用途など、「外部からアクセスして利用するわけではない用途」のインスタンスであれば、そもそもパブリック IP アドレスを付与する必要はありません(あると直接ログインできて何かと便利だけど)。外部に公開する IP アドレスが不要な使い方であれば、プライベート IP アドレスだけで運用すれば月額 500 円です。

次にサーバー用途の場合、こちらが本題です。端的に言えば「ポートフォワーディングでなんとかする」という考え方です。2つ目以降のパブリック IP アドレスに料金がかかるならそこは使わず、1つ目の IP アドレスをうまい具合に流用して2台目以降のインスタンスでも使っちゃおう、というやり方です。多くの人にとっては今更感のある方法かもしれませんが、貴重な無料クーポンを効率よく使う IDCF といえばワンコインクラウド、を実践するための知恵です。

具体的にはこんな感じです。まず現状、light.S1 の仮想マシンが2台あるとします:
2015112704


この2台をそれぞれこんな感じで使えるようにしたい、とします:
1台目(dotnsf-neppico)2台目(dotnsf-misc)
目的接続ポート番号目的接続ポート番号
SSH22SSH10022
HTTP80HTTP1880
MySQL3306MQTT1883


要は1台目は一般的な LAMP サーバーで MySQL まで外部に公開。SSH もデフォルトの 22 番ポートで公開する、というものにします。一方2台目はちょっと目的が異なり、流行りの Node-RED 環境を用意しようとしています。外部に公開するポートは Node-RED サーバーのデフォルトである 1880 と、MQTT ブローカーの 1883、そしてこのサーバーにも SSH でアクセスできるようにしたいのですが、デフォルトの 22 番ポートだと1台目の SSH と衝突してしまうので、2台目の SSH には 10022 番を割り当てるものとしています。

実際には2台目のマシンで MySQL を動かして公開したり、1台目のマシンに別の HTTP を動かしたりすることもできますが、いずれのケースでもポート番号だけは衝突しないようにする必要があります(そしてその結果、デフォルト設定とは違う値を設定する必要が出てきます)。

この内容を IP アドレスの設定に反映させます。まずはファイアウォールの設定で開ける必要のある全ポート番号(上記例では 22(ssh), 80(http), 1880(http), 1883(mqtt), 3306(mysql), 10022(ssh) の6つ)を通すよう設定しておきます:
2015112705


次にポートフォワードの設定です。先程ファイアウォール設定で開けた各ポート毎に振り分け先を指定してあげます。その際、パブリックポートには開けたポート番号を、プライベートポートには実際に動いているポート番号を指定します。多くの場合は同じ数字(実際に動いているポート番号)を指定しますが、今回の例だと2台目の SSH だけは実際には 22 番ポートで動いている SSH に、ファイアウォールで開けた 10022 番ポートから繋がるよう設定する必要があります。そのため、パブリックポートを 10022 に、プライベートポートを 22 に指定しています:
2015112706


これで1つのパブリック IP アドレスを2台のマシンで共有する形で割り振ることができました。なお、実際に2台目のマシンに SSH でログインする場合は、ポート番号に 10022 を指定して接続する必要があります(デフォルトの 22 番だと1台目のマシンに繋がります):
2015112707


これで「2台目以降も 500 円の IDCF クラウド」になりました。

これからも遠慮無く使わせていただきます。よろしくおねがいします。

最近は多くのクラウド業者が IoTMQTT との連携をアピールしています。IBM を含めて各社が「いかに簡単に IoT データを扱う/応用することができるか」を競っている感じです。

この点で IBM の強みの1つが Node-RED フローエディタだと思っています。Bluemix に統合されたこの GUI エディタは MQTT サーバー(ブローカー)との接続を簡単に行い、データを集め、保存する仕組みを簡単に提供することができます。MQTT ブローカー/クライアントの Mosquitto といい、この Node-RED といい、IoT にもオープンソース製品が多くの場面で使われるようになってきて、更なる広まりを見せているように感じます:
2015082602


IBM の場合、この Node-RED をうまく Bluemix に合わせてカスタマイズして提供しており、Bluemix 内ではすぐに使えるようになっており、また Bluemix の各サービスと簡単に組み合わせて使えるような形で提供されています。


ただ Node-RED そのものはオープンソースで提供されているものです。他のクラウドインスタンスやオンプレミスサーバー環境でも(Bluemix 用の拡張がされていない素のエディションを)動かすことが可能です。つまり IBM 以外の業者のクラウド環境内で Node-RED を使った IoT アプリ開発環境を構築することだってできるわけです。


というわけで、今回のブログエントリでは SoftLayer や AWS、IDCF、オンプレミスなどの(クラウド)サーバー環境内で Node-RED を使って IoT アプリ開発環境を構築する手順を紹介します。


まず最初に Bluemix と IBM IoT Foundation を使った場合の IoT アプリ開発環境のシステムトポロジーを確認しておきます。必要になるサーバーとしては各種センサーデバイスからの情報を集約する MQTT ブローカーと、Node-RED が稼働する Node.js アプリケーションサーバーです。Bluemix 環境の場合、前者は IBM IoT Foundation が提供する quickstart サーバーを無料で使うことができます(つまり構築不要です)。後者は Bluemix のボイラープレートを使うことで Node-RED が動く状態まで含めて簡単に構築できてしまいます。なお収集したデータを保存しようとすると別途データベースサーバーを用意する必要がありますが、Bluemix であればデータベースも簡単に追加してバインドすることが可能です(今回はデータベースを使わない環境を前提とします):
2015082601


これと同じ環境を Bluemix を使わずに構築することを考えると、(物理的には1台のマシンでも構いませんが)上記の MQTT ブローカーと Node.js の2サーバーを手動で用意することになります:
2015082602


具体的には MQTT と Node-RED それぞれの環境を用意する必要があります。1台または2台のサーバーを用意し、それぞれのサーバーインスタンスに MQTT ブローカーおよび Node-RED 環境を構築します。それぞれの手順は(CentOS サーバーの場合であれば)以下の記事を参照ください:
ラズベリーパイにオープンソース MQTT の Mosquitto をインストールする (←ラズベリーパイだけでなく CentOS の場合のインストール方法も記載しています)
CentOS に Node-RED をインストールする


まずは MQTT ブローカーを起動しておく必要があります。MQTT ブローカー(Mosquitto サーバー)を導入したマシン上で以下のコマンドを実行するなどして Mosquitto サービスを動かしておきます:
# service mosquitto start

次に Node-RED を導入したサーバーで Node-RED を起動します:
2015082603


起動した Node-RED にブラウザでアクセスします。Node-RED はデフォルトでは 1880 番ポートで起動するので、 http://(Node-RED サーバー):1880/ でアクセスするとフローエディタの画面が開きます:
2015082604


そして下図のような、MQTT インプットと Debug アウトプットを繋げただけのシンプルなフローを記述します:
2015082608


MQTT インプットの属性は以下のようにします。Broker には Mosquitto を導入したサーバーの 1883 番ポートを指定します。Topic はなんでもいいのですが、ここでは "top/001" と指定しています(後で実行するコマンドで指定することになる文字列です)。準備ができたらデプロイして実行状態にします:
2015082605


これで環境は出来上がりました。では正しく動いているかどうかを確認してみましょう。
別途 Mosquitto クライアントを導入したマシン(これも同一マシンでもかまいません)から以下のコマンドを実行して、MQTT ブローカーにメッセージをパブリッシュします:
$ mosquitto_pub -h (MQTT ブローカーサーバー) -t "top/001(上記 Node-RED で指定した Topic 属性と同じ文字列)" -m "Hello."

2015082606


すると、Node-RED 画面の debug タブには -m オプションで指定された文字列が表示されるはずです。つまり MQTT ブローカーの top/001 トピックに送信されたメッセージを、Node-RED から正しく取得することができたことになります:
20150824_nodered



ちゃんと動きました。Node-RED は Bluemix や IBM IoT Foundation がなくても、普通の(?) MQTT 環境の中でも動くことが確認できました。


・・・とはいえ、Bluemix + IBM IoT Foundation 環境で Node-RED を使ったことのある者として言わせていただくと、ここまでの環境を整えないと使えないわけです。また現実的には取得したデータをデータベースに格納しようとすると、Bluemix 環境のように簡単にはいきません。動くか動かないかでいうと動きますが、その準備のためのハードルはまだまだ高いように感じています。

IoT アプリ開発環境を検討する上で IBM Bluemix + IBM IoT Foundation + Node-RED がいかに簡単で便利なのか、を改めて再確認するような実験になったとも感じました。




 

個人的にご縁のある IDCF 様がゴールデンウィークにクラウドを使った面白い企画をやっていました:
抽選でスターバックスギフトカードプレゼント【IDCFからの宿題第2弾】

IDCF 様のクラウド環境を使って、git のサーバーである GitLab 環境を構築してみよう、というものです。GitLab は GitHub のサーバーを自分専用に作るような環境で、特に Community Edition は無料のオープンソースで提供されています。導入も非常に簡単で 22/80 番ポートの開いたサーバーがあれば数分で専用 GitHub が構築できる、というものです。 そして IDCF 様の企画では同環境を IDCF クラウド上に作成して、その活用方法を含めてブログにまとめると抽選でスタバのギフトカードがもらえる、というものです。興味ある方はこの週末にチャレンジしてみましょう!


で、自分はスタバカードにも興味はありますが、ちょっとだけ(?)脱線して、同じ環境を IBM Bluemix 上で作ってみることにしました。 完全な悪ノリです、はい。まあでも仮想マシン起動後の作業は共通ということで・・・ (^^;

なお、GitLab CE(Community Edition) 環境の具体的な構築方法はこちらを参照ください。以下は基本的にこの手順をそのまま実行しています:
Download GitLab Community Edition(CE)


まず GitLab を導入するには SSH でログインできるサーバーが必要です。というわけで Bluemix の OpenStack VM 機能を使って CentOS の仮想マシンを1つ作成します。バージョンは個人的に慣れている 6.5 で。この辺りの手順はこちらを参照ください:
Bluemix 上で OpenStack VM インスタンスを作成する


ちなみに GitLab の推奨環境としては 2CPU + 2GB メモリですが、100 ユーザー程度であれば 1CPU + 1GB メモリ + 1GB スワップメモリでも OK とのこと。Bluemix の仮想マシンは現時点で最小スペックの m1.small でも 1CPU + 2GB メモリ + 2GB スワップメモリなので、前提条件としては充分だと思います:
2015050801


仮想マシンが立ち上がったら Bluemix かどうかを意識する必要はありません。まず SSH でログインし、とりあえず root で yum update しておきます:
# yum update

最初に必要な依存ライブラリをまとめて導入&起動しておきます:
# yum install openssh-server postfix cronie git
# /etc/init.d/postfix start
# chkconfig postfix on
# lokkit -s http -s ssh

次に GitLab 本体をダウンロードしてインストールし、起動します:
# curl -O https://downloads-packages.s3.amazonaws.com/centos-6.6/gitlab-ce-7.10.1~omnibus.2-1.x86_64.rpm
# rpm -ivh gitlab-ce-7.10.1~omnibus.2-1.x86_64.rpm
# vi /etc/gitlab/gitlab.rg (external_url の値を自分自身のIPアドレスに変更)
# gitlab-ctl reconfigure
2015050802


最後にこのサーバーにブラウザでアクセスして、ユーザーID(root) と初期パスワード(5iveL!fe)を指定してログインします:
2015050803


初回ログイン時には初期パスワードを変更するよう指示されます。自分専用のパスワードに変更します:
2015050804


一度、強制ログアウトされるので再度 root ユーザーと新しいパスワードでログインするとウェルカム画面が表示されます。これで GitLab が使える環境が整ったことになります!
2015050805


あとはリポジトリの管理単位となるプロジェクトを作り(10,000個まで作れるらしい)、ユーザーのグループを作って、プロジェクト毎のアクセス権を柔軟に制御することもできます。

新規にユーザーを登録すると、メール認証が必要になります。となるとメールサーバーを用意/設定する必要があります。それが面倒な場合は以下の設定を加えて、ユーザー登録と同時にメール認証が済んだことにすることもできます:
# vi /opt/gitlab/embedded/service/gitlab-rails/app/modules/user.rb

(以下の行を追加)
  default_value_for :confirmed_at, Time.now


この設定後にユーザーを登録すると、同時にメール認証までは終わったことになります。ただその時点ではまだパスワードが設定されていないのでログインできません。管理者がユーザーを登録後に初期パスワードを設定してあげる必要があることに注意してください。

(参考)
ユーザを登録する


また、環境によっては GitLab が使う git ユーザーの ssh アクセスを許可していない可能性もあります。その場合は以下の2つの設定をしておくとアクセス制限を解除できます:
# vi /etc/shadow

git:!!:16569::::::
  ↓
git:*:16569:::::: (パスワードを設定していないユーザーの SSH ログインを許可する)
# vi /etc/ssh/sshd_config

AllowUsers xxxx yyyy git (AllowUsers に半角スペース区切りで git を追加)

# service sshd reload

もちろん github を使っている状況で無理に GitLab 環境に移行する必要はありませんが、ソースコードを自前環境で管理したい場合や、必ずしも公開したくないソースコードを管理したい場合などに GitLab は非常に簡単で便利だと思いました。


リアルタイムに商品の最安値を調べるサービス「ねっぴ」を開発・運営しています:
ねっぴ(http://neppi.co/) 


サービス内のカテゴリを展開したり、検索窓から製品を検索して商品を絞込むと、その商品の販売を取り扱っていそうなウェブサービスを探し、取り扱っていた場合はそのサービス内での最安値を探し、最終的には価格順にソートして「どこで買うと安いか」を表示してくれる(クリックすればそのまま購入ページにいける)、というサービスです:
2015030500


有名な価格比較サイトと同様のサービスと理解いただくのが分かりやすいと思います。ただ上記のようにそのサイトもねっぴでは比較対象の1つと考えていて、必ずしもそのサイトが最安値を提供しているわけではないことがわかります。ねっぴは「その場で」&「リアルタイムに」価格を検索して比較する点が異なります。


サービスの使い方はこちらに簡単なオンラインヘルプを用意しています。ユーザートラッキングなどを目的とはしていないため、面倒なサインアップなど不要で、誰でも利用できます:
「ねっぴ」の使い方


本ブログエントリでは、「ねっぴ」の環境や技術的な内容について紹介します。
参考までに、こちらは以前に某LTでねっぴと試作段階の TweetsMapper について紹介した資料です:
ねっぴ on IDCF


上記資料内でも触れていますが、元々ねっぴは自宅サーバー環境で開発・動作確認等を行い、テスト運用を経て何度かの引越を経験し、現在は IDC フロンティア 様の IDCF クラウドを利用して運用しています。


基本構成としては一般的(?)な Linux + Tomcat + MySQL で、高速化のために一部 memcached を併用しています。 データベースの日次バックアップには Amazon S3 互換の Object Storage を使っています(参考)。 IDCF クラウドのサーバーインスタンスにはスワップメモリ領域が用意されていなくて不安(というか不安定)だったので、Linux の起動時にスワップファイルを作成して利用するようにしました(参考)。 更に IDCF を通じて利用できる Mackerel 監視サーバーを有効化するため、エージェントを導入しています:
2015030502


ここまでの環境を IDCF クラウドの light.S1 サーバー1台(!)でまかなえています。ディスクは ROOT の 15GB のみで追加なし、Mackerel は IDCF を通じて使う場合の特別プランが用意されていて、追加料金なしでもそれなりに使えます。Object Storage とネットワーク I/O は無料枠の範囲内で収まっています。

・・・というわけで、この「ねっぴ」の環境はバックアップや監視まで含めて light.S1 サーバーの月額最低料金である 500 円で実現している(!)、ということになります:
2015030501


うーん、我ながら俺って優秀やりくり上手でいい主夫になれるかもw まあやりくり上手というよりは「無茶」なだけかもしれませんけど。。。

ただこの環境を IDCF の light.S1 サーバー1台で提供している背景についても触れておく必要があります。
もともと IDCF クラウドに移る前は別業者の同価格帯のクラウド(というか VPS)を使っていました。サービスとして公開できていましたが、開発環境をそっくりそのまま公開した感じで、パフォーマンスレベルなどは二の次、という感じでした。開発者視点で考えると、そもそもどのレベルを求めるのか?という話にもなってしまい、現在もそこまでしっかり考えて公開しているわけではないのですが、当時は単に「動いたものをそのまま公開した」というレベルでした。その時点ではバックアップはしていません。監視もシェルスクリプトレベルでした。

このサービスは「リアルタイム価格検索」を行うことと、商品マスターをクローリングするという特性上、ネットワークのバックボーン性能がサービス性能に影響する度合いが大きいという特徴があります。実はここだけで見ると、自宅ネットワーク内のサーバーで運用する、という選択肢もありました。

その頃、当時仕事上で携わっていた業務で IDCF クラウドを使うことになり、light.S1 インスタンスが500円/月で提供されていること、ネットワークバックボーンに関しては非常に高いコストパフォーマンスを発揮してくれることが魅力でした。 


とはいえ移行を考えると、上記のように IDCF クラウドにはスワップメモリがないという問題があったり、当時使っていたクラウドの方がディスク容量を多く提供してくれたり、という比較要素もありました。一方で IDCF クラウド側にも無料枠で提供されている Object Storage や Mackerel といったプラス要素があり、結局は何をどう比較するか、という判断になりました。まあスワップメモリに関してはディスク上にファイルとして用意するという回避手段があること、ディスクは多いほど嬉しいけどサービスを展開する上で困るほど少なかったわけではないことが分かり、そして何よりもサービスの肝になるネットワーク性能が自宅ネットワークをも上回っていた、という違いが決め手でした。 これがディスク容量が問題になるようなケースだと結局月額料金の差になってしまうため違う判断になる可能性もありましたが、このねっぴに関してはほぼ同額の比較になりました。

結局、現時点でこのサービスを運営する先としてコストパフォーマンスでのベストは何か、という最終判断として IDCF クラウドを選んだ、という結論です。


おまけですが FAQ の1つをここに書いておきます。サービス名の「ねっぴ」は「較」の「値比」を無理やり発音した結果です。



 

自分が作って運用しているサービス "Tweets Mapper" を紹介します:
http://tweetsmapper.juge.me/

上記ページにアクセスしていただくと、利用者の現在地を中心としたエリアが地図に表示されます。
そして、その地図画面内において、ツイッターで「位置情報を ON にして」ツイートされたもののうち、
 ・過去3時間以内のものを
 ・近いものから20個
位置情報と併せて表示する、というサービスです。

「地図画面内でのツイート」を検索して表示するので、地図の表示位置や拡大率を変えて、表示エリアが変わるとツイート一覧もその内容に併せてかわります。

この画面例はつい先程、ハワイのホノルル周辺が含まれるよう地図を調整して撮ったものです:
2015022701

また画面上部には現在表示している地図の位置と拡大率を初めから表示するための URL です。例えば上記ページの URL はこちらで、この URL にアクセスすると、地図を調整しなくてもはじめからホノルル周辺で最近ツイートされた内容が表示されます。実際にアクセスすると、ホノルルで日本語ツイートがいかに多いかわかると思います:
http://tweetsmapper.juge.me/?lat=21.283109926822885&lng=202.1684304199951&zoom=15


PC のブラウザでアクセスすると、このように画面が左右2つに別れて表示されますが、スマホの場合は地図とツイートとが別タブで表示されます:
2015022702


コンサートやイベントなど、人が多く集まってツイートが多くされるとわかっている時に、この TweetsMapper が威力を発揮します。後でツイートをまとめたい時に、全員が共通のハッシュタグを付けてくれるとまとめやすいのですが、全員がそうしてくれるとは限りません。その点、この TweetsMapper では「位置情報が ON になっている」ことが条件にはなりますが、ハッシュタグがなくてもそのイベント周辺にいる人のツイートを取得できるので、集計が楽になります。

また、この手の検索はリアルタイム性を追求するのが結構難しいのですが、ちょっと工夫した仕組みを導入することでうまく実現できていると自負しています。実際に見ていると、ほぼリアルタイムに(本当に直前にツイートされたものも)画面に表示できているはずです。 このサービスを実現する上ではサーバー側の通信速度の確保が必要なんですが、IDCF クラウドで非常に高いコストパフォーマンスを提供していただくことで実現できています。



ちなみに、現在のこのサービスでは日本全国に加えて、ハワイ、LA、SF、ラスベガス、NY、ボストン、フロリダ周辺がサービス提供エリアとなっています。理論上は他のエリアを含めることもできますが、予算とその他の関係上(笑)いまはこのエリアに絞って提供していることをご理解ください。

でも、もし他エリアの要望があれば教えてください。一時的な対応も含めてですが、検討します。






 

このページのトップヘ