Disaggregationが巻き起こしたネットワーク業界再編についての考察

ここ1年で、ネットワーク業界のビジネスモデルが急速に変わりつつあるのを感じます。特に今月は動きが激しかったので記録のために私の分析(妄想)経過を文章にしてまとめておくことにします。

AT&T, VerisonがSDN/NFVに軸足を移す

• SDxCentral | Trusted News and Resources for SDx, SDN, NFV

AT&TがDomain2.0を発表したのに続いて、Verizonも正式に White Boxによるネットワークのソフトウェア化やNFV化を公式に認めました。それに時期を合わせる形でメキシコの携帯事業者の買収と15%の設備投資削減を発表しています。

噂情報をつなぎ合わせて考察すると、以下のような状況が想像されます。

• Juniperはホワイトボックス推進派(Contrail擁護?)と既存ビジネス推進派(ハードウェアビジネス擁護)の二つがせめぎ合っていた
• Verizon(Juniperの大口顧客)から、今後のネットワーク設計について White Box を前提にすることの通告を受ける
• 前CEOは既存ビジネス推進派だったが、既存ビジネスを守りきることに失敗したため解任された
• (予想)今後はホワイトボックス推進派が会社の運営権を握り、Juniperはソフトウェアを主体としたビジネスに大きく舵を切る

既にクラウドの主要ベンダはネットワーク機器の Disaggregation を実施済み

AWS, Google, Facebook などの主要なクラウドベンダが発信している情報を読み解くと、各社は既存のネットワークベンダの機器を使うことがサービスの阻害要因になっていることを以前から認識していてハードウェアとソフトウェアの分離(Disaggregation)を進めていたことが分かります。

阻害要因のポイントとしては、

• 膨大なEast-Westトラフィックを処理するためには従来のNorth-South重視の設計では不可能で over-subscription freeで通信ができるだけの帯域が必要
• over-subscription freeを前提にすると、既存ベンダの機器ではコストが合わない。既存ベンダのネットワーク機器は、長らくMooreの法則に従わず、値段も高止まりしていた
• 既存ベンダの強みと言われてきた巨大なシャーシ型のネットワーク機器を導入すると、機器障害時の停止リスクが上昇してしまう。クラウドネイティブのアプリは分散環境が前提で動作するとはいえ、一度に沢山のノードが停止するリスクは大きすぎるためネットワーク設計として巨大シャーシを使うのは不適切
• 既存ベンダのネットワーク機器は、ソフトウェアによる自動化への対応が殆ど進まず、長らくサイロ化を引き起こしていた。また、中身がブラックボックスであることで発生する障害対応コストの上昇もクラウド事業者にとっては欠点となる。このような状況はソフトウェアエンジニアの矜持である「あらゆるものをソフトウェアで自動化する」に反しており、AWS, Googleã‚„Facebookなどイノベーションを最大の価値と理解している企業には受け入れがたいものになる

主要クラウド事業者が用いた解決策は、以下のような感じです。

• Introducing data center fabric, the next-generation Facebook data center network - Facebook Code
• (SPOT301) AWS Innovation at Scale | AWS re:Invent 2014
• Google Cloud Platform Blog: Enter the Andromeda zone - Google Cloud Platform’s latest networking stack

• Microsoftã‚„Facebookは、既に BGP LSDC構成による IP Fabricを導入して膨大なEast-Westトラフィックに耐える運用を実現している
• マルチテナントを構成する場合のネットワークアーキテクチャは MAC-in-IP 的な overlay が既にAWSなど主要クラウド事業者では採用されている。overlayは転送性能(オーバーヘッド)の点では課題があるものの、安定して運用できることやスケールアウトできる利点があるため現時点で選択できる最良のアーキテクチャと考えられる
• 巨大シャーシを使わずボックス型のスイッチを使う場合の欠点は管理するべきノード数の上昇により運用コストが上がることだが、ネットワーク機器をサーバとまったく同じ仕掛け(chef, puppet, ansibleç­‰)やトポロジ管理の仕組みをソフトウェアとして作り込むことで管理コストを大幅に削減できる

既存ハードウェアベンダの今後の商売について考える

主要クラウド事業者はハードウェアの調達方法をODMに切り替え済みのため、既存ネットワーク機器ベンダにとってはクラウド事業者が主要な収益源になる可能性は低くなると予想されます。そうなると、既存ベンダは必然的に企業向けの商売にシフトせざるを得ないですが、こちらについても新規開発についてはクラウドに巻き取られていくことが予想されます。

サーバの世界で起こった出来事(IBMのx86サーバ事業撤退やHP分社化など)のアナロジーをネットワーク業界に当てはめると、既存ネットワーク機器ベンダが生き残るためには分社化してソフトウェア事業を主体としたOSSのサポートサービスやライセンスサービスに移行する必要があるのかもしれません。

Riak2.0セキュリティ機能の強化内容について調査しました

みんなでやるRiak Advent Calendar 2013 クリスマスイブのネタとして投稿します。

• みんなでやるRiak Advent Calendar 2013 - Qiita

次期バージョンのRiak(Riak2.x)では、CRDT、Strong Consistency、Yokozuna Searchなど、様々な機能強化が予定されています。今回の投稿では、Riak2.0で拡張が予定されているセキュリティ機能についてまとめます。

情報源

• Add Security to Riak · Issue #355 · basho/riak · GitHub
  • security機能 開発の様子
• Riak HTTP security session example · GitHub
  • 具体的な使い方の例

出来ること

• Authentication
  • IPv4ソースアドレス(CIDR)による認証
  • Password認証
  • PAM認証
  • LDAP認証
    • PAM認証が出来ればLDAP認証は出来るので、無くても何とかなる
• Authorization
  • ユーザ単位でput,getをどのbucketで許可するかを設定できる

分かったこと

• まだ色々と実装が完了していない
  • riak-admin security delete-source が無いなど

使い方の例

securityの設定方法は、riak-adminコマンドのsecond level command に "security"が増えたので、こちらを用いることで設定できます。

• ユーザ名'testuser'を追加し、全ユーザからの127.0.0.1/32 からのアクセスを許可する

$ dev/dev1/bin/riak-admin security add-user testuser
$ dev/dev1/bin/riak-admin security add-source all 127.0.0.1/32 trust

• ユーザ名'sean'を追加し、パスワード'justopenasocket'でのアクセスを許可する

$ dev/dev1/bin/riak-admin security add-user sean password=justopenasocket
$ dev/dev1/bin/riak-admin security add-source sean 0.0.0.0/0 password

• PAM認証を許可する

$ dev/dev1/bin/riak-admin security add-source all 192.168.1.0/24 trust
$ dev/dev1/bin/riak-admin security add-source all 0.0.0.0/0 pam service=riak

• Usage of security second level command

sogabe@sherco:~/src-github/riak$ dev/dev1/bin/riak-admin security
Usage: riak-admin security <command>

The following commands modify users and security ACLs for Riak:

    add-user <username> [options]
    add-source all|<users> <CIDR> <source> [options]
    grant <permissions> ON ANY|<type> [bucket] TO <users>
    revoke <permissions> ON ANY|<type> [bucket] FROM <users>
    print-users
    print-sources
    print-user <user>

• ユーザ'testuser'に バケット名'mybucket'に対して get のアクセス権を与える

$ dev/dev1/bin/riak-admin security grant riak_kv.get ON mybucket TO testuser

• ユーザ'sean'にバケット名'mybucket'に対して get,put のアクセス権を与える

$ dev/dev1/bin/riak-admin security grant riak_kv.get,riak_kv.put ON mybucket TO sean

• ワイルドカード表記を用いて、'myapp_*'バケットのアクセス件を与える

$ dev/dev1/bin/riak-admin security grant riak_kv.put ON myapp_* to testuser
(現時点では未だ動作せず)

• security 設定情報の一覧を表示する(print)

sogabe@sherco:~/src-github/riak$ dev/dev1/bin/riak-admin security print-users
+--------------------+--------------------+----------------------------------------+------------------------------+
|      username      |       roles        |                password                |           options            |
+--------------------+--------------------+----------------------------------------+------------------------------+
|        sean        |                    |c57e004ee67d6260863b1050e58d93405f5900fd|              []              |
|      testuser      |                    |                                        |              []              |
+--------------------+--------------------+----------------------------------------+------------------------------+
sogabe@sherco:~/src-github/riak$ dev/dev1/bin/riak-admin security print-sources
+--------------------+--------------+----------+--------------------+
|       users        |     cidr     |  source  |      options       |
+--------------------+--------------+----------+--------------------+
|        all         | 127.0.0.1/32 |  trust   |         []         |
|        all         |192.168.1.0/24|  trust   |         []         |
|        sean        |  0.0.0.0/0   | password |         []         |
|        all         |  0.0.0.0/0   |   pam    |[{"service","riak"}]|
+--------------------+--------------+----------+--------------------+

• security ユーザ毎の設定情報を表示する(print-user)

sogabe@sherco:~/src-github/riak$ dev/dev1/bin/riak-admin security print-user testuser

Inherited permissions

+--------------------+----------+----------+----------------------------------------+
|        role        |   type   |  bucket  |                 grants                 |
+--------------------+----------+----------+----------------------------------------+

Applied permissions

+----------+----------+----------------------------------------+
|   type   |  bucket  |                 grants                 |
+----------+----------+----------------------------------------+
| mybucket |    *     |              riak_kv.get               |
+----------+----------+----------------------------------------+
sogabe@sherco:~/src-github/riak$ dev/dev1/bin/riak-admin security print-user sean

Inherited permissions

+--------------------+----------+----------+----------------------------------------+
|        role        |   type   |  bucket  |                 grants                 |
+--------------------+----------+----------+----------------------------------------+

Applied permissions

+----------+----------+----------------------------------------+
|   type   |  bucket  |                 grants                 |
+----------+----------+----------------------------------------+
| mybucket |    *     |        riak_kv.put, riak_kv.get        |
+----------+----------+----------------------------------------+

試してみる

2013年12月現在、riak2.0は開発中なので github の developブランチを用いてテストをします。

riakのソースコードをダウンロードし、ビルドする

$ git clone https://github.com/basho/riak
$ cd riak
$ make stagedevrel

riak securityの設定

2013年12月現在、developブランチでは security機能を有効にするためのコードが入っていないので、手動でコードを修正してテストをします。
下記の例では、riak.conf に "security = on"と記述することでsecurity機能を有効にできるようになります。
尚、riak2.0からはコンフィグファイルが Erlang由来のものではなく cuttlefish と呼ばれるパーサを使うことになったので、下記のように cuttlefish 用の schemaファイルに必要な設定を追加します。

$ vi deps/riak_core/priv/riak_core.schema
(下記を追加)
%%
%% XXX security
%%
{mapping, "security", "riak_core.security", [
  {default, off},
  {datatype, {enum, [on, off]}}
]}.
{ translation,
  "riak_core.security",
  fun(Conf) ->
    Setting = cuttlefish:conf_get("security", Conf),
    case Setting of
      on -> true;
      off -> false;
      _Default -> false
    end
  end
}.

$ make stagedevrel
 (ビルドする)

$ vi dev/dev1/etc/riak.conf
...
(SSLの cert, key を設定する)
## Default cert location for https can be overridden
## with the ssl config variable, for example:
ssl.certfile = ./etc/cert.pem

## Default key location for https can be overridden
## with the ssl config variable, for example:
ssl.keyfile = ./etc/key.pem

...
(https を有効にして、代わりにhttpを無効にする)
listener.https.internal = 127.0.0.1:10018
...
#listener.http.internal = 127.0.0.1:10018

...
(セキュリティ機能を有効にする)
security = on

$ ulimit -n 4096
$ dev/dev1/bin/riak start

curlを用いた Authentication / Authorizationのテスト

$ curl -k -i https://localhost:10018/riak/test/doc
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Riak"
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:08:15 GMT
Content-Type: text/html
Content-Length: 159

<html><head><title>401 Unauthorized</title></head><body><h1>Unauthorized</h1>Unauthorized<p><hr><address>mochiweb+webmachine web server</address></body></html>

$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Riak"
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:08:15 GMT
Content-Type: text/html
Content-Length: 159

<html><head><title>401 Unauthorized</title></head><body><h1>Unauthorized</h1>Unauthorized<p><hr><address>mochiweb+webmachine web server</address></body></html>

$ dev/dev1/bin/riak-admin security add-user andrew
$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Riak"
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:09:51 GMT
Content-Type: text/html
Content-Length: 159

<html><head><title>401 Unauthorized</title></head><body><h1>Unauthorized</h1>Unauthorized<p><hr><address>mochiweb+webmachine web server</address></body></html>

$ dev/dev1/bin/riak-admin security add-source andrew 127.0.0.1/32 trust
$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc
HTTP/1.1 403 Forbidden
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:11:03 GMT
Content-Type: text/plain
Content-Length: 154

Permission denied: User 'andrew' does not have'riak_kv.get' on {<<"default">>,
                                                                <<"test">>}
$ dev/dev1/bin/riak-admin security grant riak_kv.get ON default test TO andrew
$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc
HTTP/1.1 404 Object Not Found
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:12:17 GMT
Content-Type: text/plain
Content-Length: 10

not found

$ curl -k -i --user andrew:foo https://localhost:10018/riak/test2/doc
HTTP/1.1 403 Forbidden
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:13:04 GMT
Content-Type: text/plain
Content-Length: 155

Permission denied: User 'andrew' does not have'riak_kv.get' on {<<"default">>,
                                                                <<"test2">>}

$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc -d "hello world"
HTTP/1.1 403 Forbidden
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:13:54 GMT
Content-Type: text/plain
Content-Length: 154

Permission denied: User 'andrew' does not have'riak_kv.put' on {<<"default">>,
                                                                <<"test">>}

$ dev/dev1/bin/riak-admin security grant riak_kv.put ON default test TO andrew
$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc -d "hello world"
HTTP/1.1 204 No Content
Vary: Accept-Encoding
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:14:56 GMT
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

$ curl -k -i --user andrew:foo https://localhost:10018/riak/test2/doc -d "hello world"
HTTP/1.1 403 Forbidden
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:15:49 GMT
Content-Type: text/plain
Content-Length: 155

Permission denied: User 'andrew' does not have'riak_kv.put' on {<<"default">>,
                                                                <<"test2">>}
$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc
HTTP/1.1 200 OK
X-Riak-Vclock: a85hYGBgzGDKBVIcR4M2cgetf/4qgymRMY+V4UOpyhm+LAA=
Vary: Accept-Encoding
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Link: </riak/test>; rel="up"
Last-Modified: Tue, 17 Dec 2013 07:14:56 GMT
ETag: "59NlprW7hUCSUVKznH6VKM"
Date: Tue, 17 Dec 2013 07:16:29 GMT
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

hello world

$ dev/dev1/bin/riak-admin security revoke riak_kv.get,riak_kv.put ON default test FROM andrew
$ curl -k -i --user andrew:foo https://localhost:10018/riak/test/doc
HTTP/1.1 403 Forbidden
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:19:20 GMT
Content-Type: text/plain
Content-Length: 154

Permission denied: User 'andrew' does not have'riak_kv.get' on {<<"default">>,
                                                                <<"test">>}

$ curl -k -i --user andrew:foo -XPUT https://localhost:10018/riak/test/doc -d "hello world"
HTTP/1.1 403 Forbidden
Server: MochiWeb/1.1 WebMachine/1.10.5 (jokes are better explained)
Date: Tue, 17 Dec 2013 07:18:52 GMT
Content-Type: text/plain
Content-Length: 154

Permission denied: User 'andrew' does not have'riak_kv.put' on {<<"default">>,
                                                                <<"test">>}

OpenStack Swiftの代わりにRiak-CSを使ってみる

OpenStackではオブジェクトストレージサービスとしてSwiftが使えますが、APIレイヤで差し換え可能なコンポーネントとしてSwiftStackやRiak-CSなどがあります。今回の記事では、分散オブジェクトストレージ Riak-CS をOpenStackと組み合わせる方法についてまとめてみます。

Riak-CSで出来ること

Riak-CSは Basho Technologies社が開発したAmazon S3のAPIを持つ分散オブジェクトストレージのソフトウェアで、2013年3月にオープンソース化されました。Riak-CSは分散データベース Riak の上で動作するアーキテクチャを取っているため、Riakの特長である高いAvailabilityやScalabilityが実現されています。
Swiftでは飽き足らない人やRiakが大好きな人は、是非この記事を参考に OpenStack のオブジェクトストレージを Riak-CS にしてお楽しみください。

情報源

Riak Documentation

Riak-CSが対応している認証方式

Riak-CSをOpenStack KeyStoneと連係させる際に利用できる認証方式は以下の2つがあります。

• Access Key / Secret Key を用いた認証 (AWS互換API)
• Access Tokenを用いた認証 (Swift互換API)

Riak-CSが対応している Swift互換API

Riak-CSで利用できる Swift互換APIは以下の通りです。

• List Containers(lists all buckets for authenticated user)
• List Objects
• Create Container
• Delete Container
• Get Object
• Create or Update Object
• Delete Object

インストール方法

本記事では、ソースコードからビルドする形でのインストール方法を解説します。keystoneについては、devstackを用いてインストールします。

riak, riak-cs及びstanchionのソースコードをダウンロードする

$ git clone https://github.com/basho/riak
$ git clone https://github.com/basho/riak_cs
$ git clone https://github.com/basho/stanchion

riakをビルドする

$ cd riak
$ git branch -b 1.4.2 refs/tags/1.4.2
$ make stagedevrel
$ cd ..

riak-csをビルドする

$ cd riak_cs
$ git branch -b 1.4.3 refs/tags/1.4.3
$ make stagedevrel
$ cd ..

stanchionをビルドする

$ cd stanchion
$ git branch -b 1.4.3 refs/tags/1.4.3
$ make devrel
$ cd ..

riakの設定をriak-cs向けに修正し、riakプロセスを起動する

$ cd riak
$ vi dev/dev1/etc/app.conf

(riak_kv storage_backend の箇所をコメントし、下記を追加)
{add_paths, ["/home/foobar/src-github/riak-swift-test/riak_cs/dev/dev1/lib/riak_cs/ebin"]},
{storage_backend, riak_cs_kv_multi_backend},
{multi_backend_prefix_list, [{<<"0b:">>, be_blocks}]},
{multi_backend_default, be_default},
{multi_backend, [
  {be_default, riak_kv_eleveldb_backend, [
    {max_open_files, 50},
      {data_root, "./data/leveldb"}
  ]},
    {be_blocks, riak_kv_bitcask_backend, [
      {data_root, "./data/bitcask"}
  ]}
]},

(riak_core 下記の項目を追加)
{default_bucket_props, [{allow_mult, true}]},

$ ulimit -n 4096
$ dev/dev1/bin/riak start
$ cd ..

riak-csの設定を修正し、riak-csプロセスを起動する

$ cd ../riak_cs
$ vi dev/dev1/etc/app.config

(adminアカウントを作成するため、一時的に認証無しの設定にする)
{anonymous_user_creation, true},

(riakのポート設定を変更する)
riak_cs, ...
{riak_pb_port, 10017 } ,

$ dev/dev1/bin/riak-cs start

stanchionプロセスを起動する

$ vi dev/stanchion/etc/app.config

(stanchion riakポートを変更する)
{stanchion,...
{riak_pb_port, 10017 },

admin userを作成する

$ curl -H 'Content-Type: application/json' \
  -X POST http://localhost:8071/riak-cs/user \
  --data '{"email":"[email protected]", "name":"admin user"}'

以下のようなメッセージが返ってくる

{
   "email" : "[email protected]",
   "status" : "enabled",
   "key_id" : "KDGRAVNHTYYF8XNTD7CD",
   "name" : "admin user",
   "id" : "e52d4a6ee043848fceecbfeee10f48076924ef2a758d03d9554ecec05d6d1233",
   "display_name" : "admin",
   "key_secret" : "9IucFpt32qbAltZb_kEWa5N3bD_N9kbSB5mxsg=="
}

riak-cs, stanchionの Admin User Credential設定を上記で作成したものに変更して、anonymous user creation を disable に戻す

$ vi dev/stanchion/etc/app.config
$ dev/stanchion/bin/stanchion restart
$ cd ../riak_cs
$ vi dev/dev1/etc/app.config
$ dev/dev1/bin/riak-cs restart

s3cmdで動作テスト (まずは Riak-CS単体の動作テスト)

$ sudo apt-get install s3cmd
$ vi 00s3.cfg

(00s3.cfg)
[default]
access_key = KDGRAVNHTYYF8XNTD7CD
bucket_location = US
cloudfront_host = cloudfront.amazonaws.com
cloudfront_resource = /2010-07-15/distribution
default_mime_type = binary/octet-stream
delete_removed = False
dry_run = False
enable_multipart = False
encoding = UTF-8
encrypt = False
follow_symlinks = False
force = False
get_continue = False
gpg_command = /usr/local/bin/gpg
gpg_decrypt = %(gpg_command)s -d --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_encrypt = %(gpg_command)s -c --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_passphrase = password
guess_mime_type = True
host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
human_readable_sizes = False
list_md5 = False
log_target_prefix =
preserve_attrs = True
progress_meter = True
proxy_host = localhost
proxy_port = 8071
recursive = False
recv_chunk = 4096
reduced_redundancy = False
secret_key = 9IucFpt32qbAltZb_kEWa5N3bD_N9kbSB5mxsg==
send_chunk = 4096
simpledb_host = sdb.amazonaws.com
skip_existing = False
socket_timeout = 300
urlencoding_mode = normal
use_https = True
verbosity = WARNING

$ s3cmd -c 00s3.cfg ls
$ s3cmd -c 00s3.cfg mb s3://test
$ s3cmd -c 00s3.cfg put LICENSE s3://test/obj1
$ s3cmd -c 00s3.cfg ls s3://test/
$ s3cmd -c 00s3.cfg get s3://test/obj1 -

OpenStack Keystoneのインストール、プロセス起動

$ cd ..
$ git clone https://github.com/openstack-dev/devstack
$ cd devstack
$ cp samples/localrc .
$ vi localrc

(localrcの修正)
(Swift及びKeystoneのみを動作させるため、下記コンフィグを付け足す)
KEYSTONE_BRANCH=stable/havana
SERVICE_TOKEN=$ADMIN_PASSWORD
disable_all_services
enable_service key mysql

$ ./stack.sh
$ source openrc admin admin
$ keystone service-create --name=swift --type="object-store" \
    --description="Swift Service"
$ keystone endpoint-create \
          --region RegionOne \
          --service_id (service id) \
          --publicurl "http://localhost:8071/v1/AUTH_\$(tenant_id)s" \
          --adminurl "http://localhost:8071" \
          --internalurl "http://localhost:8071/v1/AUTH_\$(tenant_id)s"
$ keystone catalog

S3 APIの設定、テスト

$ cd ../riak_cs
$ vi dev/dev1/etc/app.config

(app.config)
- devstackのコンフィグで指定した token を追加

{os_admin_token, "nomoresecrete"},
    (Auth URL を指定する)
{os_auth_url, "http://(host or ip address):35357/v2.0/"},
{rewrite_module, riak_cs_s3_rewrite },
{auth_module, riak_cs_keystone_auth },

$ dev/dev1/bin/riak-cs restart
$ keystone user-create --name testuser --pass test --email [email protected] --tenant-id (demo tenant id) --enabled true
$ keystone role-create --name swiftoperator
$ keystone user-role-add --user-id (user-id) --role-id (role-id) --tenant-id (tenant-id)
$ keystone ec2-credentials-create --user_id (uid) --tenant_id (tenant-id)
$ vi 01s3.cfg
  (access_key, secret_key を ec2-credentials-create で生成されたものに変える)
$ s3cmd -c 01s3.cfg mb s3://bucket2
$ s3cmd -c 01s3.cfg ls
$ echo "ilovechickenilovelivermeowmixmeowmixwilldeliver" > upload.txt
$ s3cmd -c 01s3.cfg put upload.txt s3://bucket2
$ s3cmd -c 01s3.cfg get s3://bucket2/upload.txt download.txt
$ s3cmd -c 01s3.cfg del s3://bucket2/upload.txt
$ s3cmd -c 01s3.cfg rb s3://bucket2

OpenStack(Swift) APIの設定、テスト

$ vi dev/dev1/etc/app.config

(app.config)
{rewrite_module, riak_cs_oos_rewrite },
    (API を Swift API に変更する)

$ dev/dev1/bin/riak-cs restart
$ curl -s -d '{"auth": {"tenantName": "demo", "passwordCredentials": {"username": "testuser", "password": "test"}}}' -H 'Content-type: application/json' http://localhost:5000/v2.0/tokens | json_pp

$ export ID=...
  (token項目の中のidを X-Auth-Tokenとして使う)
$ export URL=...
  (object-store service の serviceCatalogから、publicURLの情報を得る)
$ curl -X PUT -H 'X-Auth-Token: '$ID $URL/bucket1
$ curl -H 'X-Auth-Token: '$ID $URL
$ curl -X PUT --data 'abcdefghi123456789' -H 'X-Auth-Token: '$ID $URL/bucket1/object1

OSSA Explorer 買いました

SCORPA T-RIDEから、OSSA Explorer に乗り換えることにしました。

• http://www.ossamotor.es/EN/models.php?idMoto=339

カテゴリとしては、KTM Freeride350 のような、トライアルっぽい遊び方が楽しめるオフロードバイクといったところです。
今月号のトライアル系雑誌(自然山通信、ストレートオン)に詳細なレポートが載っているので購入を検討されている人は一読をおすすめします。
まだ慣らし運転中なので軽く乗り込んだだけですが、乗った感じは、トライアルの軽快さと取り回しの良さを追及しつつも、しっかりとしたシートが付いているのが素敵です。重量は乾燥重量で80kg前後と、トレール車としてはこの上なく軽いです。T-RIDEと比べると、以下の点が優れています。

• トライアル車並みのタイトターンができる
  • ホイールベースはOSSA TR280iと同一!
• フロントホップ、リアホップも楽々
• 低速でもしっかり粘るエンジン特性
  • T-RIDEが低速苦手なのに比べると別次元な程に乗りやすい

逆に、T-RIDEと比べて劣りそうなところは、

• 広いところをかっ飛ばすのは苦手かも..
• まだ試していないので結論は出せませんが、コンパクトな車体かつキャスターの立ったフロントフォークのため、高速性能は高くないかも。もっとも、私の腕前であればそれほど問題にならないかもしれないです

Freeride350といい、OSSAといい、ヨーロッパのバイクメーカは本当に素晴らしいバイクを作ります。どちらも日本の法律規制では公道を走るのは難しいですが、オフロードで走らすと色々な楽しみ方が広がりそうです。

PaaS, IaaS, プライベートクラウド 利用者の属性を考える

1/28に「mrubyの夕べ」の講演時に、PaaSの利用者について挙手アンケートを取った結果が興味深かったので、想定される利用者の属性を文章にまとめてみます。

• PaaS
  • 参加者の、なんと1/2以上がPaaS利用の経験があるとのこと
  • 主な利用者:
    • お手軽にRailsなどのWebを立ち上げたい個人
    • 低コストで迅速にサービスを立ち上げたいスタートアップ企業
• IaaS
  • 参加者の1/3程度が利用したことあるとのこと。私の予想ではIaaSが最大多数だったので、少々驚きました
  • 主な利用者:
    • PaaSだと割高感が出てきたサービス事業者、または個人
    • 例えば、Heroku は最少構成が無料ですが処理性能を上げていくと(EC2に比べて)割高感が徐々に出てきます。どこかに損益分岐点があるのでしょう
• プライベートクラウド(IaaS, PaaS含む)
  • 挙手アンケートは実施されていないので、割合は不明
  • 主な利用者:
    • IaaSだと割高感が出てきたサービス事業者(Facebookã‚„Twitterなど、自前で専任のエンジニアを確保できる会社)

私の当初の予想では、ベンダロックインを嫌う人がIaaSやプライベートクラウドを利用するのだと思っていたのですが、ベンダロックインを嫌う人は世の中的にはそれ程多くないのかもしれないです。どちらかというと、コストを基準に PaaS/IaaS/プライベートクラウド を決めている人が多いのかもしれないですね。

mrubyの夕べ å‚åŠ ã—ã¾ã—ãŸ

昨日は、1/28(月) 15:00-からの 「mrubyプチハッカソン」と17:00-からの「mrubyの夕べ」に参加してきました。

今回mrubyネタで私も発表する機会を頂きましたが、そちらについては別途会社提供のブログで公開する予定です。本ブログでは、まつもとゆきひろさんのmruby講演内容についてまとめてみます。
私の知る限り、90分の時間をかけてmrubyの詳細についてまつもとさんから説明していただける機会は今回が初めてだと思います。

mrubyのテクニカルな話は今回が初めて

• mruby = embedded-ruby, 又は matsumoto-ruby の略

mrubyにおける組み込みとは

• Cruby: Rubyが主 (rubyに対して C Extension を提供、アプリはRuby)
• mruby: Rubyが従 (必要な箇所のみmrubyで記述)
  • 小さなデバイス、システム、アプリへの組み込み

mrubyに必要なもの

• 組み込みAPI
• 移植性(Portability)
  • POSIX非依存、OS非依存, C99の範囲内で (できるだけ)
  • ただし、Visual Cでも動作するように、C99の制限は緩和ている
• 構成可能性
  • システムに対する最適なカスタムコンフィグレーション
• ソフトリアルタイム
  • 車のABSなどには不向き(ハードリアルタイムは難しい)
  • ゲームへの組み込みレベルのリアルタイム性
    • GCの設計

福岡の人たちが、とてもモチベーションが高かった

• 平成22年度地域イノベーション創出研究開発事業に採択されてmruby開発を進めることになった
  • このプロジェクトが無ければmrubyは生まれていなかったかもしれない

• • compiler + virtual machine : まつもとさん担当
  • class library + α: 九工大担当
  • プロジェクト管理+周辺ツール: 福岡CSK担当
    • 実証実験: 複数の企業担当
• 昨年4月にソースコードをgithub上に公開した

組み込みAPI

• mrb_open()
• mrb_load_string()
• mrb_close()

mruby VM

• 旧称 Rite VM
• 32bit word machine
  • 命令種別 7bit
  • operand A: 9bit
  • operand B: 8bit
  • operand C: 7bit
• register machine
  • オペランドでレジスタ番号を指定
  • なんちゃってレジスタマシン

struct mruby_value

• 構造体渡し
• mrb_float は double
• NaN Boxing
  • double float に情報を押し込む
    • value.h 参照
  • lua JITの影響を受けた

mruby C API

• lua を参考にしている cf. 32bit encoding op code
• CRuby API に似ている
• mrb_stateを取る
• ブロック呼び出しは非推奨
  • できるだけrubyコードで書くことを推奨
  • fiberに将来対応するときなど、大変なことになる

言語としてのlua

• コンパクトさ優先のため、言語としての機能は少ない
• rubyっぽく書けるコンパクトな言語が欲しいというモチベーションがあった

移植性

• C99, BC, gcc
• 動作確認が取れているOS
  • Windows, OS X, Linux, NetBSD(*BSD)
  • iOS, ANdroid, VxWorks, iTron
  • OSレスでも動く
  • Rubyチップ評価ボード(ザイリンクス FPGA でMips互換CPUを実装)

構成可能性

• include/mrbconf.h の設定を変えることで構成変更が出来る
• 主要なオプション
  • MRB_NAN_BOXING, MRB_USE_IV_SEGLIST, MRB_VHASH_INT_SIZE
    • リソース節約できる
  • DISABLE_REGEXP
    • enableしても動きません ;(
  • DISABLE_MATH
  • DISABLE_TIME
  • DISABLE_STRUCT
  • DISABLE_STDIO

リンカオプション

• コンパイラの排除ができる
  • eval, load要らない場合
• コード生成器の排除
• 事前コンパイル
• bin/mrbcを使う
  • test/mrbtest でも使っている

複雑なビルド条件

• 種々のプラットフォーム、コンパイラへの対応が必要
• クロスコンパイルも必要
• rubyコードのコンパイル、リンクも必要
• Ruby/Rake を使ったビルド方式に移行した(2013å¹´1月頃)

mrbgems

• ライブラリの組み込みができる
• 動的にロードする機能は無い、コンパイル時にリンクする
• プラットフォーム非依存
• mrubyソースコード外のコードを指定できる
  • githubを指定することも可能

mgem

• gem install mgem で簡単インストール
• mrbgems を管理できる
• mgem update すれば、リストを更新できる
• 使い方の例
  • mgem add mruby-env
  • mgem config > build_config.rb

ソフトリアルタイム

• GC
  • スループット
    • 実行時間中にGCの占める割合
  • 最大停止時間
    • 最も長い停止時間
    • リアルタイム性の評価指標
    • 組み込みの領域では、スループットよりも最大停止時間を重視することが多い
  • マークアンドスイープGC
    • mark phase と seep phase に分かれる
    • mark phase
    • top level変数を root にする
    • 数珠つなぎにアクセスできるオブジェクトを探索
    • 見つけたオブジェクトをマークする
    • sweep phase
    • 全てのオブジェクトを探索し、死んでいるオブジェクトを改修する
  • 保守的GC
  • Arena
  • インクリメンタルGC
  • 世代別GC
  • インクリメンタル世代別GC

太陽光発電管理システム

• 東芝さんが開発
• 管理スパンが10年単位と長いため、PCより可動部の少ない機器が最適
• mrubyを使ってプロトタイプを実装した

自動機メンテシステム

• 富士電機さんが開発
• 中国の子会社がコードを書いている
• ruby -> rule based compiler -> c言語 に変換して使っている
• メンテナンスシステム(レシート印字)向けにプロトタイプを作成した

ruby対応インテリジェントルータ

• mrubyを搭載したエッジルータ

教育用ボードコンピュータ

• GR-SAKURA に液晶パネルを載せたもの
  • フィジカルコンピューティングができる
  • arduino とピン配置互換

モジュール色々

• mod_mruby
• Nginx
• mruby-uv

サーバ用途でのmruby

• メモリの増大、GCコストの増大
  • mrubyのGCは優秀なので、crubyからmrubyへの置き換え検討の余地がある

クライアントサイド

• mruby to JS converter
  • llvmを使っている
• NaCl (native client)
  • web browser で動かすのに向いている

ロボット

• top levelの制御にmrubyを使う

レゴ マインドストーム

• ETロボコンで使っているチームがある
• メモリが64kBしかないので、ライントレースするだけでも大変
  • メモリの増えたバージョンが最近発売された

MobiRuby

• iOS上で動作する

Games

• ゲームのプログラム内で利用する
  • 今のところ lua が多い
  • mrubyも是非使ってほしい

Gree Tech Talk #2 行ってきました

グリーさん主催の Tech Talk に参加してきました。

• http://techtalk2.labs.gree.jp/

内容は、なんとGitHub Enterprise(GHE) のことだけに絞って熱く語るイベントです。GHEは日本ではマイナーだと思いきや本イベントには軽く300人以上が集まっていました。

発表を聞いた感想

一言で言えば、GHEを導入した会社はGitHubの優れたコラボレーション機能の恩恵を享受できている反面、運用コストが大きくかかっている印象を持ちました。GHE自体のライセンス費用は一人換算だとUSD20 / 月 程度なので高すぎるというわけでもないのですが、GHEを運用するためにはプライベートクラウドを運用する(VMWare)必要があります。つまり、GHEを導入できる会社は、IaaSを低コストで安定運用できる会社に限られると考えられます。
でもそれって、、既にプライベートクラウド(IaaS)を導入済みの、それなりに規模の大きな会社に限られます。。ということになっちゃいますね ;(

GHEアプライアンス欲しいです

それ程大規模な企業ではないけれどGHEを導入したい人たちはどうしたらいいのだろう、というのを妄想してみました。

• GHEアプライアンス(のサービス)を使う

- GHEが予めインストールされたサーバをエンドユーザに提供する
- 基本的な監視機能(ping, ヘルスチェック等)はサービス事業者側が提供してくれるので、アラートが上がったらある程度の切り分けはしてくれる
- ソフトウェアのアップデートは、サービス事業者がおまかせでやってくれる
- GHEを運用する際に踏むであろう地雷情報(?)はサービス事業者に集まってくるので、個々の会社がGHEを運用するより安定度は上がる
- AWS VPCへの接続など、ハイブリッドクラウドに対応するためのオプション機能も用意されている

ハードウェアの絡むビジネスはGitHub社が手掛ける可能性は無いと思うので、国内のSI屋さんやクラウド事業者等がビジネスとして手掛けてくれると嬉しいと思いました。