2014年5月29日木曜日

コンテナ型(?)仮想化

Google は 週に20億のコンテナを起動
http://www.publickey1.jp/blog/14/google20.html

などの話題もあり、一気に盛り上がりそうだなーと思う。
(他の環境ではGoogleの真似はできないだろうしする必要もないだろうけど)

ここで、さらりと振り返っておく。

まず Google さまの Containers At Scale に書かれているのは lmctfy
Docker を統合、LXC をおきかえるもの、と。
セキュリティまわりのふんふんで AppArmor を利用するのは LXC と同じ(?)なのかな。

Docker とはなんぞや?
語弊ありでさらっとかくと LXC をラクに使うためのもの。ただ、もう LXC 依存はない。
コンテナ型仮想化「Docker 0.9」リリース。LXCに依存しなくなり、安定性向上など http://www.publickey1.jp/blog/14/docker_09lxc.html

LXC とはなんぞや?
LXC http://ja.wikipedia.org/wiki/LXC
その名のとおり、Linux カーネルでのみ利用可能なOSレベル仮想化のソフトウェア。

LXC みたいなの Linux 以外にないの?
プラットフォーム仮想化 をみると、Solaris Container, FreeBSD Jail, Virtuozzo, OpenVZ などなど。

Solaris Container についてはやはりオラクル様の資料をみるとよいと思う。
http://www.oracle.com/technetwork/jp/ondemand/os-vm/ord-1111-solariscontainerbasic-251086-ja.pdf

Oracle Solaris Containers
Solaris 10 から利用できるので、9年経ってる。

FreeBSD Jail は FreeBSD 4.0 から利用できていたので、14年。と言っても、あまり機能は充実してなかったかな・・。
ezjail がでてきたのは結構後なのでやはり利用するツールの充実は大事だな。

NTT/Verio が魔改造 Jail を使っていたはずだけど、どんなものだったんだろう。
http://news.mynavi.jp/articles/2008/06/03/bsdcan1/

なんとなく、仮想化界隈は動きが激しかったり積み重なっているものが多い気がするので、早くからウォッチしているひとは良いけど、さてこれからみてみようと思うと面食らう気がするな。。仮想化界隈というよりLinuxの動きが激しいのか。

2014年5月26日月曜日

Uターン

自分を固定化するイベント(家かうとか、結婚するとか)をこなしていないのでそういやUターンしようと思えばこなしているひとよりはるかに容易なんだよなぁ、とふと思った。 

とくにする意志も理由もないけど、
選択肢として調べておくかな。いつなにがあるかわからんし。

2014年5月25日日曜日

アカウントを削除

ちょっと前から、使わなくなったあるいはほぼ使わなくなっているアカウントを削除している。

これまでは「まー、削除せずこのままにしておくかー」と思って放置していた。


消したおもなアカウントは以下

かなり前に使っていた某社フリーメール
某フィードリーダー
ドメイン移管して使わなくなった側のレジストラ
CD買った特典の無償ダウンロードでアカウント作成が必要だった音楽サイト
某SNS
某SNSに買われた画像共有サイト
位置情報共有する某サービス
某決済サービス
P2Pな無料通話、チャット、ビデオチャットなサービス

消せないでいるのが以下。停止もできなそう。

ゲームのダウンロード販売プラットフォーム * 2 (2つとも洋ゲーなやーつ)


削除するのが以外とめんどくさい場合や事実上できない場合がたまにあるので、なるべく利用するサービス増やさないようにしよう。「ちょっと使ってみるか」と思ったのは何ヶ月後かに見なおすのがよい。

2014年5月23日金曜日

こころがけ

自分がなにかのサービスを利用していて困って問い合わせをするとする。

その場合
・(必要であれば)これまでの背景
・なにがしたいのか
・なにがおきているのか
・どうなるとよいのか
・(必要であれば)いつまでに困っているのを解消したいのか

・・などなどをこれまで初回で伝えるようにしていたと思う。急ぎであればあるほどなおさら。
ただ「なにがしたいのか」だけだと、その(裏にある)内容をちゃんと汲み取ってもらうまでのオーバーヘッドがかかり、お互い負荷になる。

そう思うと、むしろ別の言語でやりとりをするというのはいいのかもしれない。日本語による「甘え」というか。
別な言語であればこれで伝わってるかな??と思い、よりしっかりと内容を考えると思うし。
以前 GHE の問い合わせをしていたときはそうだったかも。

2014年5月18日日曜日

英語があまりできずにいたツケを解消する

仕事柄必要である環境なので(むしろここしばらく何年か、そのような環境を望んでいたのだけど)いよいよ解消するとき。気負いなくサクッと出張行けないとね、というのもあり。
今の状態としては
・ワイ、ドキュメント読んだり動画のヒアリングはそこそこできる(つもり)ンゴ
・思ってることが面白いくらい書けなくて時間がかかるンゴ・・・出力が弱いンゴ・・・
という。

「これ英語ドキュメントしかないんですねー。。」という愚痴(?)のようなのを聞くことがない環境であるのは自分にとっては嬉しい。
メールでバシバシ流れてるので参考にできそうな文はいただきまくれるし。

なんとなく触れる機会があれば身につくんじゃね?みたいな考えではいたけど、短かいスパンでちゃんと伸びてる感を確認しつつ、さほど時間かけないほうがむしろいいんじゃないのかと思う。

社のトレーニングで受けることも可能なんだけど、次回まで待たないといけないのであんまアテにしないでおく。

高専卒でいわゆる「英語が苦手な高専生」な時だったのでそのままできずにいたし、受験英語なんぞ全く知らずじまいにいて早10何年。
母校では、いつからか海外語学研修みたいなのがあるみたいなので今はそうでもないんだろうな。

最近使ってて自分にとって良い本はこれ。




文法弱いから「なるほどねー」と思うことがとても多くて複雑な気分である。
話す機会はどうにかして作らないとなーと思案中。

よくありがち(?)なのが「〜〜訛りはわかりにくいよねー」的な発言。これは避けたい。相手のを気にしてもしょうがないし、自分のを気にしてもしょうがない。自分のは改善したほうがいいとは思う。
あとは、メンタルブロックのようなものが大きいのかもしれない。


Redis の中の人のエントリは以外だったな。

 (翻訳)英語は私にとって15年にわたって悩みの種です 
 http://ymotongpoo.hatenablog.com/entry/2013/09/04/180103


2014年5月14日水曜日

EBS backed と instance store backed など

instance store backed での利用は今どきあまりないと思うし

http://aws.typepad.com/sajp/2014/04/trainingfaqbest10.html

をみるに、EBS backed は 2009年後半頃からある。ので、、4年半くらい経っているけども、自分の場合は instance store backed で利用することが多かったため(~2012年くらい)、それこそメモ的に。

ルートデバイスのストレージ を見よう。
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device

EBS backed の場合には
・起動が速い
・サイズ制限1TiB
・stopでき、データ保持される (EBSだからね..)
・(stopして)インスタンスタイプなど変更可能

なのでEBS backedを使わない理由はないように思える。
(instance store backed で10GiBのイメージが強かったので1TiB使えるのは知らなかった。。1TiBで使いたいケースはどんな場合だろう。)

また、
ステータスチェックに失敗したインスタンスのトラブルシューティング
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/TroubleshootingInstances.html

のとおりEBS backed ならばインスタンス障害時にいったんインスタンスを停止してから再開できる。instance store backed だと停止できないので、別インスタンス作ってサヨナラ。これは、メンテナンス時にも効いてくる。

Amazon EC2 のメンテナンスのヘルプページ
https://aws.amazon.com/jp/maintenance-help/
EBS-backed AMI: EBS-backed AMI を使用している場合、インスタンスを停止してから再開することで簡単に再起動できます。このとき、インスタンスのローカルインスタンスストアに保存されて いたデータはすべて失われますので、必要なデータはインスタンスを停止する前にバックアップしておきます。(以下略
Instance store-backed AMI: Instance store-backed AMI を使用している場合、AMI を再バンドルして新しいインスタンスを起動する必要があります。このとき、インスタンスのローカルインスタンスストアに保存されていたデータはすべて失わ れ、インスタンスの内部 IP アドレスも変わります(Amazon VPC 内で実行している場合を除く)。

EBS backedでも当然ながらinstance storeに大事なものおいてたらstopしたらそこだけは助からないから下記スライドをみてどう使うかを決めておくのが吉。


ルートデバイスでなく、
インスタンスについてくる instance store は EBS とどう使う分ける?というのはここらへんを見ると良い。

[AWSマイスターシリーズ] Instance Store & Elastic Block Store
http://www.slideshare.net/AmazonWebServicesJapan/aws-instance-store-e

EC2のストレージどう使う? -Instance Storageを理解して高速IOを上手に活用!-
http://www.slideshare.net/imaifactory/ephemeral-ssd

いつからかPIOPSやらEBS-Optimizedなどもあるのでなかなか奥深い。
前は「1本だけだとバーストで数百IOPSかー」という印象だったのだけど。

Q: Amazon EBS ボリュームには、どのようなパフォーマンスが期待できますか?
http://aws.amazon.com/jp/ec2/faqs/#What_kind_of_performance_can_I_expect_from_Amazon_EBS_volumes
(snip)
スタンダードボリュームは、I/O 要件が中程度またはバースト性のあるアプリケーション用のストレージに適しています。このボリュームの平均パフォーマンスは約 100 IOPS であり、ベストエフォートで最大数百 IOPS のバーストも可能です。スタンダードボリュームは、ブートボリュームとしての使用にも適しており、バースト可能であることからインスタンス起動時間が短縮されます。
(snip)


ほか
ストレージ
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Storage.html

Amazon EC2 インスタンスストア
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/InstanceStorage.html

2014年5月10日土曜日

なんとかとクラウドはつかいよう

前みた記事をまた見ていて。

2010年の記事だけども、当時ですでにこんな具合というのが今思っても凄いなと。
Playfish's Social Gaming Architecture - 50 Million Monthly Users and Growing

今みても得るものがあると思う。

その前年にはこんな話題もあったねぇ。。EA に買われましたな。
急成長するソーシャルゲーム大手「Zynga」「Playfish」に買収観測―ゲーム界の巨人EA

2014年5月5日月曜日

Nexus 7 (2013) 手放した

使用時間を振り返ってみると、さほど活用してない、できてないと判断。
このままうちで死蔵するのはもったいなかろう、ということで買い取りしてもらった。

購入時の6割くらいの値で買い取ってもらった。
状態はかなり良いので、次の所有者の元ではこれでもかと活用していただきたい。