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月29日木曜日
2014年5月26日月曜日
Uターン
自分を固定化するイベント(家かうとか、結婚するとか)をこなしていないのでそういやUターンしようと思えばこなしているひとよりはるかに容易なんだよなぁ、とふと思った。
とくにする意志も理由もないけど、
選択肢として調べておくかな。いつなにがあるかわからんし。
とくにする意志も理由もないけど、
選択肢として調べておくかな。いつなにがあるかわからんし。
2014年5月25日日曜日
アカウントを削除
ちょっと前から、使わなくなったあるいはほぼ使わなくなっているアカウントを削除している。
これまでは「まー、削除せずこのままにしておくかー」と思って放置していた。
消したおもなアカウントは以下
かなり前に使っていた某社フリーメール
某フィードリーダー
ドメイン移管して使わなくなった側のレジストラ
CD買った特典の無償ダウンロードでアカウント作成が必要だった音楽サイト
某SNS
某SNSに買われた画像共有サイト
位置情報共有する某サービス
某決済サービス
P2Pな無料通話、チャット、ビデオチャットなサービス
消せないでいるのが以下。停止もできなそう。
ゲームのダウンロード販売プラットフォーム * 2 (2つとも洋ゲーなやーつ)
削除するのが以外とめんどくさい場合や事実上できない場合がたまにあるので、なるべく利用するサービス増やさないようにしよう。「ちょっと使ってみるか」と思ったのは何ヶ月後かに見なおすのがよい。
これまでは「まー、削除せずこのままにしておくかー」と思って放置していた。
消したおもなアカウントは以下
かなり前に使っていた某社フリーメール
某フィードリーダー
ドメイン移管して使わなくなった側のレジストラ
CD買った特典の無償ダウンロードでアカウント作成が必要だった音楽サイト
某SNS
某SNSに買われた画像共有サイト
位置情報共有する某サービス
某決済サービス
P2Pな無料通話、チャット、ビデオチャットなサービス
消せないでいるのが以下。停止もできなそう。
ゲームのダウンロード販売プラットフォーム * 2 (2つとも洋ゲーなやーつ)
削除するのが以外とめんどくさい場合や事実上できない場合がたまにあるので、なるべく利用するサービス増やさないようにしよう。「ちょっと使ってみるか」と思ったのは何ヶ月後かに見なおすのがよい。
2014年5月23日金曜日
こころがけ
自分がなにかのサービスを利用していて困って問い合わせをするとする。
その場合
・(必要であれば)これまでの背景
・なにがしたいのか
・なにがおきているのか
・どうなるとよいのか
・(必要であれば)いつまでに困っているのを解消したいのか
・・などなどをこれまで初回で伝えるようにしていたと思う。急ぎであればあるほどなおさら。
ただ「なにがしたいのか」だけだと、その(裏にある)内容をちゃんと汲み取ってもらうまでのオーバーヘッドがかかり、お互い負荷になる。
そう思うと、むしろ別の言語でやりとりをするというのはいいのかもしれない。日本語による「甘え」というか。
別な言語であればこれで伝わってるかな??と思い、よりしっかりと内容を考えると思うし。
以前 GHE の問い合わせをしていたときはそうだったかも。
その場合
・(必要であれば)これまでの背景
・なにがしたいのか
・なにがおきているのか
・どうなるとよいのか
・(必要であれば)いつまでに困っているのを解消したいのか
・・などなどをこれまで初回で伝えるようにしていたと思う。急ぎであればあるほどなおさら。
ただ「なにがしたいのか」だけだと、その(裏にある)内容をちゃんと汲み取ってもらうまでのオーバーヘッドがかかり、お互い負荷になる。
そう思うと、むしろ別の言語でやりとりをするというのはいいのかもしれない。日本語による「甘え」というか。
別な言語であればこれで伝わってるかな??と思い、よりしっかりと内容を考えると思うし。
以前 GHE の問い合わせをしていたときはそうだったかも。
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
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
2010年の記事だけども、当時ですでにこんな具合というのが今思っても凄いなと。
Playfish's Social Gaming Architecture - 50 Million Monthly Users and Growing
今みても得るものがあると思う。
その前年にはこんな話題もあったねぇ。。EA に買われましたな。
急成長するソーシャルゲーム大手「Zynga」「Playfish」に買収観測―ゲーム界の巨人EA
2014年5月5日月曜日
Nexus 7 (2013) 手放した
使用時間を振り返ってみると、さほど活用してない、できてないと判断。
このままうちで死蔵するのはもったいなかろう、ということで買い取りしてもらった。
購入時の6割くらいの値で買い取ってもらった。
状態はかなり良いので、次の所有者の元ではこれでもかと活用していただきたい。
このままうちで死蔵するのはもったいなかろう、ということで買い取りしてもらった。
購入時の6割くらいの値で買い取ってもらった。
状態はかなり良いので、次の所有者の元ではこれでもかと活用していただきたい。
登録:
投稿 (Atom)