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

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

2014年08月

たまにはマンホールネタを・・・

先日、長島鋳物株式会社様の久喜事業所の工場見学をする機会がありました。普段は写真を撮るばかりのマンホール蓋の、そのデザインから色付けまでの製造過程、および性能テストの様子を拝見させていただきました。貴重な機会をありがとうございました。またこの工場見学を企画いただいた関係者の皆さん、お疲れ様でした。

工場内でも多くの写真を取りましたが、公開NGなものが多く、ここでの紹介は控えることにします。ただ写真ではなく、その中で説明いただいたことを1つだけ紹介させていただきます。


マンホール蓋には、通称「親子蓋」と呼ばれる形状のものがあります。例えばこんな感じのものです:
2014082600
参照元: http://manholemap.juge.me/page.jsp?id=1192002

親子蓋とは親蓋の中に子蓋が埋め込まれている形状のものです。街中でもたまに見かける機会があり、これ自体は特別に珍しいわけではありません。ただ2つの疑問点があります。

まず「何故2つ必要なのか?」という疑問があります。そもそも大きい蓋と小さい蓋に分ける理由があるのか?「大は小を兼ねる」的な発想で、大きい蓋だけでは何か不都合があるのか?

そしてもう1つは「何故同心円の形状ではなく、ある方向に偏った2つの円なのか?」という疑問です。同じ中心の、2重丸の方がキレイだし、デザインも楽なのではないかと思うのですが、どうして小さい蓋は(上の写真では)上方向に寄せられているのでしょうか?





それらの答は今回の工場見学を通じて知ることができました。

まず大きい蓋と小さい蓋に分けられている理由ですが、小さい蓋は人間が出入りするためのもので、大きい蓋は機械を中に入れる際のものなのだそうです。「人間も大きい蓋を空けて出入りすればいい」とも思うのですが、空けた穴に取り付ける器具など、小さい穴のサイズが想定されているものもあるため、人間が出入りする際にはあくまで小さい穴を使うことになるようです(ちなみに人間用の穴は直径60cmという規格があり、周辺機器(っていうのか?)もその規格にそって作られているようです)。一方、この規格に合わないような大きな機械を中に入れることが必要になることもあるのですが、その場合のために大きい蓋が用意されている、とのことでした。

そしてもう1つの謎ですが、これは実際に使う段階を考えればすぐ分かることでした。

マンホールの蓋を開けると、その下へ進むためのはしごが筒の内側に用意されています。
2014082601

親子蓋が同心円で2重丸の様になっている場合、子蓋だけを空けた時に穴の位置よりも更に外側にはしごが設置されていることになるため、穴に入って足を引っ掛けたり、はしごを掴むまでが結構大変な作業になることが分かります。
2014082602

一方、上記画像のようにある方向に偏った位置に子蓋があると、そこを空けた時にスムーズにはしごが掴める位置に穴が空くことになります。
2014082603

広い意味で「安全のため」に、親子蓋の蓋は同心円上ではなく、わざと偏った位置に作られている、ということでした。



 

IBM Bluemix の "Cloundant" サービスを試しに使ってみました。


まず Cloudant について説明します。Cloudant は JSON ドキュメントデータベースである Apache CouchDB をベースとする DBaaS サービスを提供しているマサチューセッツ州の企業です(2014年3月にIBM による買収が発表されました)。

このサービスが Could Foundry ベースの PaaS である IBM Bluemix のサービスの1つとして提供されている、ということになります。利用する側の観点で言えば「IBM Bluemix 内で使える Apache CouchDB」ということになります。価格等は後述します。


では実際に IBM Bluemix から Cloudant サービスを使う手順を紹介します。IBM Bluemix にログインし、ダッシュボードなどの画面から "ADD SERVICE" をクリックします:
2014081601


サービス一覧の "Data Management" カテゴリの中に "Cloudant NoSQL DB" を見つけることができます。これをクリックします:
2014081602


"Cloundant NoSQL DB" の説明が表示されます。この時点で特定のアプリケーションサーバーに紐付けるのであれば APP からアプリケーションを選択します(試しに使うだけなら特定のアプリケーションへの紐付けは不要です)。そして "CREATE" ボタンをクリックすると Cloudant サービスが生成されます:
2014081603


ちなみに、上記画面の下の方までスクロールするとサービス価格についての説明があります。データ1GBあたり 105円(1ドル?)ですが、2GB までは無料枠内で使えるようです。加えて API の実行回数についても無料枠と有料枠が設定されているようです。今回は無料枠内でしか使わないつもりです:
2014081604


Cloudant サービスが生成されるとダッシュボード内にこのようなパネルが追加されているはずです。この "Show Credentials" と書かれた箇所をクリックすると、Cloudant サーバーへアクセスするための Credentials 情報が表示されます(下図参照):
2014081605


Credentials 情報を確認している画面です。username や password などもありますが、とりあえずすぐ使うので "url" をメモしておきましょう。そしてサービス名(下図だと "Cloudant NoSQL DB-9c")が書かれた箇所をクリックしてサーバーの情報を表示します:
2014081606


Cloudant サービスについても説明が表示されている画面です。この右上に "LAUNCH" と書かれたボタンがあり、ここをクリックしてサーバーコンソールに接続します:
2014081607


別ウィンドウが起動して、Clondant のサーバーコンソールが表示されている画面です。ここでデータベースや複製、アカウントなどの情報を参照したり、実際にドキュメントを読み書きできます。画面ではデータベースタブが選択されていますが、まだデータベースを作成していないので "Add database" ボタンをクリックして最初のデータベースを作成しておきます:
2014081608


データベース名を指定します。ここでは "dotnsfdb" と指定しています:
2014081608a


"dotnsfdb" が作成されたので、Database タブ内の画面が変わりました(まだデータはありません)。画面内の "Create your first document" ボタンをクリックして最初のドキュメントを作成しておきます:
2014081609


中身はこんな感じにしました。 "value" キーに "こんにちは、Cloudant" という日本語の値を追加して、"Save" ボタンをクリックします:
2014081611


保存されました。"Return _all_docs" ボタンで一覧画面に戻ります:
2014081612


dotnsfdb の一覧画面に戻りました。先程作成したドキュメントが表示されています。"_id" の値(この例では"c82b7fb996a83c0bdaead3f75bd44a34")を確認しておきます:
2014081613


このドキュメントを API 経由で呼び出してみます。Credentials 情報から取得した URL を使って、以下の URL にアクセスします:
 (https で始まる "url" の値)/(作成したデータベース名)/(_id の値)

"url" の値にはユーザー名とパスワードも含まれているはずなので、後はデータベース名と _id 値を指定して GET すれば、いま作成したドキュメントの値が取得できるはずです:
2014081615


当たり前ですが、ちゃんと CouchDB の API で目的のドキュメントの情報が取得できました。日本語情報も問題なさそうです。





 

ServersMan@VPS を使い始めて3ヶ月とちょっと。安さが魅力のこの VPS サービスを実際に使ってみた上で気付いた勘所というか、感想をまとめてみます。


【ServersMan@VPSとは】
DTI(Dream Train Internet) が運営する VPS(Virtual Private Server) のサービス。1サーバーあたり月額467円から提供されている。最安のエントリーサービスの場合はメモリ1GB+ディスク50GB。この2倍と4倍のサービスも用意されていて、価格もほぼ2倍と4倍。

クラウドの開発環境や小規模ウェブサービスなど、スケールメリットの必要性が少ないケースではクラウドよりも VPS のコストパフォーマンスが上回る。そんな VPS の中でも特に安い部類のサービスだと思います。root での SSH や、ウェブインターフェースからのサーバー管理も可能です。また初めからスワップ領域(エントリーサービスの場合は1GB)が提供されている点も Good です。


【3ヶ月使った印象】
「普通に使える」という印象です。ちなみに OS は CentOS 6.4 64bit を使ってます。

エントリーサービスで契約しているため、メモリは1GBで運用していて、それがもう少しあればいいなあ、と思うことはありますが、絶対的に足りないわけでもありません。ディスク50GBは全然余裕。パフォーマンスも特別に遅いとは思いません。

むしろインターネットでどこからでも SSH アクセスできるホストが月500円足らずで使えてしまう、というコストパフォーマンスに驚いてます。いい時代です。


【契約したらやっておいた方がいいこと】
会員情報の「メンテナンス情報」と「障害アナウンス」はメールで受け取れるように設定しておくべきです。
2014081301

ServersMan@VPS はそれなりの頻度でメンテナンスがあり、その期間中はサーバーが停止します(アクセスできません)。このメンテナンスのタイミングを事前に知るには、会員サービスで「メンテナンス情報をメールで受け取る」ように設定しておく必要があるのです(単に契約しただけだとこの設定はされていないので、サーバーがメンテナンスに入るタイミングを知ることができません)。

同様に、「障害のアナウンス」もメールで知ることができますが、これも会員サービスで「障害アナウンスをメールで受け取る」ように設定する必要があります。

これをやっておかないと、知らない間にメンテナンスが行われ、その間は「なぜかサーバーにアクセスできない。調べてみたら止まってる」ように見えてしまいます。一方、メンテナンスのタイミングが事前に分かっていれば、アプリケーションサービス内でユーザーに告知することもできるようになるし、運用側としても事前に準備できます。

というわけで、ServersMan@VPS を使うならメンテナンス情報はメールで受け取るように設定することが必須だと思われます。むしろ標準でここまでやってくれてもいいと思うくらい必須。



 

Couchbase サーバーのデータをバックアップ&リストアする手順を紹介します。なお、以下で紹介する手順はバケットタイプが Couchbase のバケットに対してのみ可能な手順です。

まずバックアップを実行します。バックアップコマンドは /opt/couchbase/bin/cbbackup です:
# /opt/couchbase/bin/cbbackup http://couchbase.test.com:8091 /tmp/default_backup -u Administrator -p password -b default

上記例では couchbase.test.com という Couchbase サーバーのバケット default に対して、管理者名 Administrator 、管理者パスワード password でバックアップを実行し、その結果を /tmp/default_backup/ 以下に出力しています。

実行後、/tmp/default_backup/ 以下にはバックアップ結果のダンプファイルができています。ダンプファイルはクラスタ毎に作成されるので、クラスタ数と同じ数のダンプファイルが出力されているはずです:
/tmp/default_backup/bucket-default/node-couchbase.test.com%3A8091/data-0000.cbb

次にリストアを実行します。リストアコマンドは /opt/couchbase/bin/cbrestore です:
# /opt/couchbase/bin/cbrestore http://Administrator:password@couchbase.test.com:8091 --bucket-source=default --bucket-destination=test

このコマンドでは "default" というバケットから取得したバックアップダンプを(同じく) "test" というバケットに対してリストアする、という処理を指示しています。


Couchbase サーバーの特長の1つに「memcached互換」があります。

(ディスクではなく)メモリを一時キャッシュとして利用する memcached サーバーは比較的遅いリレーショナルデータベースのフロントエンドプロセッサーとして配置することで、部分的/仮想的に高速なデータベースサーバーを実現できます。ただし、あくまでメモリ上にのみ存在させて、ディスクへの読み書きを最小限に減らすことで高速化を実現しているため、そのままサーバーを落とすと中身が無くなり、再度メモリ上に展開して初めて再度利用することができるようになります。

Couchbase はこの memcached と互換性があります。memcached そのもののようにディスクへの退避のないデータストアとして利用することもできますし、データを非同期にディスクへ退避させつつメモリ中心のアクセスで高速化をはかる、という利用方法も選択できます(バケット単位で種類を指定します)。ちなみにデフォルト設定では後者になります。 ただいずれのモードでも単に memcached の挙動を真似ているというだけでなく、互換性があります。

具体的には、memcached は 11211 番ポートに TCP/IP で接続してデータを読み書きすることができますが、全く同じ TCP/IP リクエストで Couchbase サーバーのデータも読み書きできます。

実際に試してみましょう。Couchbase サーバーの環境構築についてはこちらを参照して、予め Couchbase サーバーが稼働している状態を用意しておきます:
CentOS に CouchBase サーバーを導入する

また、この手順では telnet を利用するので、telnet クライアントを用意しておきます。CentOS であれば以下のコマンドでインストールできます:
# yum install telnet

では実際に telnet で Couchbase サーバーに接続します。以下のコマンドの "couchbase.test.com" 部分を Couchbase サーバーのホスト名か IP アドレスに変更して実行してください:
# telnet couchbase.test.com 11211
Trying couchbase.test.com...
Connected to couchbase.test.com (127.0.0.1).
Escape character is '^]'.

上記のように "Escape character is '^]'. " と表示されれば接続できています。あっさり。

試しにこのプロトコルでデータを作成してみます。以下の様なコマンドを実行して、"my-third-document" という ID で、値が "My name is Couchbase." というドキュメントを作成してみます:
set my-third-document 0 0 21 My name is Couchbase.(改行)

memcached では set コマンドでデータを作成します。最初のパラメータは ID、2番目のパラメータは flag ですがここでは0を指定します。3番目のパラメータはデータの有効期限を秒単位で指定しますが、ゼロを指定すると無制限(ずっと残るデータ)になります。4番目のパラメータはデータサイズ、そして最後に実際のデータを入力します。

memcached(Couchbase)内のデータを参照するには get コマンドで ID を指定します:
get my-third-document(改行)
VALUE my-third-document 0 21
My name is Couchbase.
END

"My name is Couchbase." という入力した値が正しく取得できました。Couchbase サーバーに対して、memcached のプロトコルで値の読み書きができることが確認できました。

というわけで、Couchbase は memcached と同じように使えることが分かりました。memcached 用のライブラリの多くがそのまま Couchbase に対しても使えることになるので、これは便利な互換性といえます。

ちなみに、Couchbase サーバーへの telnet 接続を終了するには CTRL + ] を押して、プロンプトで quit を入力です:
(CTRL + ] を入力)
telnet> quit (telnetプロンプトで quit と入力)
# (元のシェルに戻る)







このページのトップヘ