Disaggregationが巻き起こしたネットワーク業界再編についての考察
ここ1年で、ネットワーク業界のビジネスモデルが急速に変わりつつあるのを感じます。特に今月は動きが激しかったので記録のために私の分析(妄想)経過を文章にしてまとめておくことにします。
AT&T, Verisonが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(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
- 具体的な使い方の例
出来ること
分かったこと
- まだ色々と実装が完了していない
- 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
$ 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-CSが対応している認証方式
Riak-CSをOpenStack KeyStoneと連係させる際に利用できる認証方式は以下の2つがあります。
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":"admin@example.jp", "name":"admin user"}'以下のようなメッセージが返ってくる
{
"email" : "admin@example.jp",
"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 testuser@test.com --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 に乗り換えることにしました。
カテゴリとしては、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やプライベートクラウドを利用するのだと思っていたのですが、ベンダロックインを嫌う人は世の中的にはそれ程多くないのかもしれないです。どちらかというと、コストを基準に PaaS/IaaS/プライベートクラウド を決めている人が多いのかもしれないですね。
mrubyの夕べ 参加しました
昨日は、1/28(月) 15:00-からの 「mrubyプチハッカソン」と17:00-からの「mrubyの夕べ」に参加してきました。
今回mrubyネタで私も発表する機会を頂きましたが、そちらについては別途会社提供のブログで公開する予定です。本ブログでは、まつもとゆきひろさんのmruby講演内容についてまとめてみます。
私の知る限り、90分の時間をかけてmrubyの詳細についてまつもとさんから説明していただける機会は今回が初めてだと思います。
mrubyにおける組み込みとは
mrubyに必要なもの
福岡の人たちが、とてもモチベーションが高かった
- 平成22年度地域イノベーション創出研究開発事業に採択されてmruby開発を進めることになった
- このプロジェクトが無ければmrubyは生まれていなかったかもしれない
組み込みAPI
- mrb_open()
- mrb_load_string()
- mrb_close()
mruby VM
struct mruby_value
mruby C API
移植性
構成可能性
複雑なビルド条件
mrbgems
mgem
- gem install mgem で簡単インストール
- mrbgems を管理できる
- mgem update すれば、リストを更新できる
- 使い方の例
- mgem add mruby-env
- mgem config > build_config.rb
ソフトリアルタイム
自動機メンテシステム
ruby対応インテリジェントルータ
- mrubyを搭載したエッジルータ
教育用ボードコンピュータ
- GR-SAKURA に液晶パネルを載せたもの
- フィジカルコンピューティングができる
- arduino とピン配置互換
モジュール色々
- mod_mruby
- Nginx
- mruby-uv
クライアントサイド
- mruby to JS converter
- llvmを使っている
- NaCl (native client)
- web browser で動かすのに向いている
ロボット
- top levelの制御にmrubyを使う
MobiRuby
- iOS上で動作する
Games
- ゲームのプログラム内で利用する
- 今のところ lua が多い
- mrubyも是非使ってほしい
Gree Tech Talk #2 行ってきました
グリーさん主催の Tech Talk に参加してきました。
内容は、なんと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屋さんやクラウド事業者等がビジネスとして手掛けてくれると嬉しいと思いました。
