投稿者: 管理人 (14ページ目 (40ページ中))

AWSの「秋のEC2再起動祭り」の背景はXenの脆弱性対応らしい

2014年10月2日 / 管理人 / 0件のコメント

先日から、EC2のインスタンスの再起動祭りが行われていて、きっとアレはXenのパッチに伴う再起動だろうと言われていたが、やはり、Xenの脆弱性対応だったらしい。

EC2メンテナンスについての続報＠Amazon Web Services ブログより

本日は先週末(2014/9/27から)に実施した、再起動を伴うEC2のメンテナンスについての続報や背景をお知らせします。

これはXen Security Advisory (XSA108)に関する全てのセキュリティリスクから皆様を守るために実施され、AWSは昨日(米国時間9/30)遅くすべての対象EC2(全体の10%未満)のメンテナンス作業を完了しました。

で、今回の再起動祭りの原因となった脆弱性についてはこちらに情報があったけど、何を書いてるのかまったくわからないので、今回の脆弱性に関するニュース記事を眺めてみた。

The Xen Vulnerability That Rebooted the Public Cloud@eWeekより

The impact of the flaw is that an attacker could potentially crash the underlying host server and potentially read data from other virtual machines on the system. So, the problem for public cloud providers, for example, is that the flaw could have enabled an attacker to potentially get access to other resources and data on the cloud. Needless to say, that would have been catastrophic for any public cloud provider, especially the world’s largest.

適当に訳してみると、「今回修正されたXenの脆弱性を突くことによって、物理サーバーをクラッシュさせたり、他の仮想サーバ(適当な訳注:きっと同じ物理サーバの上で動いてる仮想サーバだろうな)のデータを読んだりすることが、潜在的にできるようになってしまう。

パブリッククラウドにおいては、攻撃者がクラウド上の他人のリソースやデータにアクセスできることになってしまう。パブリッククラウドを提供する事業者、特に世界最大級の事業者にとっては、壊滅的な事態に陥ってしまうことは言うまでもない」…って感じだろうか(誤訳してたらごめんなさい)

ただまぁ、今回の脆弱性はIntelのVT-xやAMD-Vを使った、HVM (Hardware-assited VM:ハードウェア支援仮想化。完全仮想化とか言われてる方式か)で仮想化されたサーバにのみ影響があるようで、従来のPV(ParaVirtualisation:準仮想化)では影響を受けないらしい。

再起動祭りをやったのはAWSだけかと思いきや、個人的には縁のないRackspaceやIBM Softlayerあたりも再起動祭りをやってたらしい。いやはや、ハイパーバイザのバグとなるとさすがに影響が大きいな。

追記：そういえば、LinodeってXenを使ってたような気がするんだけど、どうなったんだろう(遠い目)

HDDの故障率とか

2014年9月24日 / 管理人 / 0件のコメント

Gigazineが「HDD約3万5000台を運用した実績からSeagate製品の圧倒的壊れっぷりが明らかに」って記事で紹介してたのが、Backblazeというオンラインストレージ屋さんのブログ。で、そのエントリーのタイトルは「Hard Drive Reliability Update – Sep 2014」。

HDDベンダーごとに故障率を出している、インフォグラフィックスが掲載されていた。…ご丁寧に、このタグで、このイメージをシェアできるよって書いてあったので、素直に貼るとこんな感じ。

いやー、Seagateさんの故障率の高さが目立つなぁという感じですが、Seagateといえば、ファームウェアのバグの問題が世間を賑わせたわけですが、その頃のモデル(Barracuda.11シリーズ)を使ってたら故障率は高いだろうと思って調べてみたら、SeagateのラインナップのBarracuda.12シリーズでも故障率高いから、うーんという感じ。

じゃぁ、BackblazeはSeagateだけ数多く使っててHGSTとか数が少なければ、故障率も正しくは出てこないよね！と思ったら、別の記事「What Hard Drive Should I Buy?」によれば、Backblazeで使っているHDDはSeagateとHitachiでそれぞれ12,000台ずつって感じだから、特にSeageteが数多いわけでも、HGSTが少ないわけでもないらしい。

で、この1月の記事では、こんな結論を出している。

We are focusing on 4TB drives for new pods. For these, our current favorite is the Seagate Desktop HDD.15 (ST4000DM000). We’ll have to keep an eye on them, though. Historically, Seagate drives have performed well at first, and then had higher failure rates later.

Our other favorite is the Western Digital 3TB Red (WD30EFRX).

まぁ、WesternDigitalのRedシリーズも使うけど、Seagateも長く使うと故障率上がるものの、最初は性能いいしなぁということらしい。RAID等で保護されていれば故障した際にはHDD交換すれば済むけど、堅牢だけど、遅いHDDを並べても性能がでるわけでもないしなぁ。

そんなHGSTの3.5インチHDD事業は東芝に買収されたことを思い出すと、Toshibaの故障率の推移はどうなっていくのか、ちょっと興味深い。今後もbackblazeにはHDDの故障レポートを公開して欲しいな、と。

Amazon Cloud Driveのデスクトップアプリがなくなった。

2014年9月11日 / 管理人 / 0件のコメント

ちょうど一年前くらいに「Amazon Cloud Driveが直らない…」って記事を書いて、Amazon Cloud Driveのデスクトップアプリを改善して欲しいなぁ…なんてことを書いて、しばらくほったらかしにしてて、ふと新しいバージョン出てるかなと思って調べてみたら、こうなっていた。

Cloud Driveデスクトップアプリについて：

Cloud DriveデスクトップアプリをAmazon.co.jpからインストールすることはできなくなりました。すでにコンピュータへインストールされている場合は、引き続き、ファイル、写真およびビデオをCloud Driveにアップロードできます。Cloud Driveデスクトップアプリをアンインストールすると、再度インストールすることはできません。ウェブサイト上のCloud Driveで、ファイル、写真およびビデオをアップロードしてください。

まぁ、ブラウザを使ってアップロードできるんだから、そっちでやってくれということか。まぁ、最近、Webサイトもリニューアルしたみたいだしな。Amazonとしては、Webサイトに訪問してもらって、うっかりついで買いしてもらった方がメリットあるだろうし。

というわけで、まともに動かなかったAmazon Cloud Driveのデスクトップアプリはアンインストールすることになるだろうなぁと…。

LGのG2のカメラ

2014年9月10日 / 管理人 / 0件のコメント

ドコモがオンラインショップで叩き売りしてたLGのG2…ドコモの型番だとL-01Fなんだけど、このカメラアプリがちょっとなぁ。

まぁ、夏の暑い日にズボンのポケット入れたまま歩いて、ポケットから引っ張り出して写真を撮ろうとしたら「高熱のためカメラが起動できません」みたいなメッセージが出てきてカメラが使えないのは120歩譲って許す(とはいえ、XperiaでもGalaxyでも、似たようなことしてたはずだけど、そんなメッセージを見たこともなければ、壊れたこともないんだけど、まぁ、保護機能だから壊れてからじゃ遅いと言われりゃ、そのとおり)

普通にカメラアプリで写真を撮って、カメラアプリ内のサムネイルまで作成されるのに、後から、その写真を探しても記録されてないってのは何とかならないのかなぁ…。

ふと、可能性として思いついたのは…。高解像度で撮って、さっさとカメラアプリを閉じちゃうから、写真データをストレージに書き込んでるうちに、アプリが落ちちゃってるのかもしれないけど、もしそうなら、それってどうにかなんないのかな(汗)

…とりあえず、切り分けか…

追記:
やはり、カメラアプリからストレージに写真が記録されなくなってしまうと、再起動かけないと記録できる状態に戻らないような雰囲気。そして、再起動かけると、撮った後、ぱぱっとカメラアプリからホームに戻っても写真は記録されてた。もしかすると、メインメモリの空き状況の影響とかあるんだろうか。うーむ

LinodeとかDigitalOceanとか。

2014年9月5日 / 管理人 / 0件のコメント

Linodeのリージョンが東京にあることに気づいて、早速、アカウント作ってインスタンスを立ててみた。

Linode TokyoはどうやらKDDIのデータセンターにあるらしく、同じくKDDI系のCloud Coreのインスタンスにping打ってみたら2msくらいで返ってきた(笑)あと、千葉のフレッツ網からのpingも20msくらいでネットワーク的にはかなり快適。DigitalOceanの西海岸だと太平洋越えで100ms超えるし、同じくDigitalOceanのシンガポールも100ms超えてたことを考えると意外と悪くないかも。メモリーは1GBしかないけど、ストレージはSSDだし。

しかしまぁ、AWSとかGoogleのクラウドが細かくネットワークセキュリティに配慮した仕組みを備えている一方、LinodeやDigitalOceanみたいな、安い系のVPS屋さんの「細かいことは気にしない」系のインスタンスは、何個もインスタンスたてると大変かも知れないけど、ちょっと1小インスタンス立ててWordPressでも運用してみようかなみたいな用途には悪くないかもしれない。とりあえずVPCみたいな仕組みは大掛かり過ぎるし、インスタンスでiptablesも使えるわけだし。

インスタンスが起動したら、とりあえずsshでルートログインさせる(rootパスワードを起動時にwebから入力させるのがLinodeで、DigitalOceanはメールで送られてくるんだったか)感じはなかなかドキドキしないでもないけど。

もし、初期ログインの後、ユーザーが適切に設定を変えられるのであれば、最初の導入時だけ雑なる感じになってしまうのもしょうがない…のかな(遠い目)

スマホ向けの動画をエンコードした。

2014年9月1日 / 管理人 / 0件のコメント

今日、iPhone5で撮影したムービーファイルをもらったが、フルHDで撮影してあったので長さが90秒しかないにも関わらず、ファイルサイズが200MBあった(汗)その動画を撮影した人には、一緒に写っている人にシェアして欲しいと言われたけれど、このサイズで配布する必然性がほぼない(かつ、もらってもちょっと迷惑か)ような気がしたのでffmpegでサイズを小さくしてムービーのファイルサイズを縮小することにした。

とりあえず、普通にflvに変換してflowplayerを使ってWebで見られる状態にすることは出来たけど、PCでWebサイトを見てるときに動画を再生できるだけじゃなくて、スマホに動画をダウンロードしてネットワークに接続してなくても動画を再生したいというニーズがでてきて「スマホで見られる」mp4を作る必要がでてきたので試行錯誤してみた。

やったこと的には、mp4のプロファイルをbaselineにしてレベルを3.1にしてみた。一応、このレベルだと映像のビットレートがまぁまぁ高くても問題なさそうな気がするけど、ドコモのメディアプレーヤーではエラーが出て再生できなかった(汗)ので、ちょびちょびビットレートを下げていって、640×360って解像度の700k/sでエンコードしたら、ちょっと古いAndroidとかiPhone4でも再生できるmp4を作ることができた。

ちょうど、以下のようなコマンドでmp4を作った。

ffmpeg -i xxxxx.MOV -vcodec libx264 -ar 44100 -b:v 700k -aspect 16:9 -s 640×360 -profile:v baseline -level 3.1 xxxxxx.mp4

DigitalOceanでdroplet作ったらSwap追加

2014年8月29日 / 管理人 / 0件のコメント

ちょっと検証しようと思うことがあって、久方ぶりにDigitalOceanでDropletを作ってみた。しかも、なぜだか分からないけど、CentOSのクリーンインストールをしてみることにした。で、初期設定からごそごそやってて、ふと思い出したのが、DigitalOceanでCentOSでDropletを立てた場合(他のUbuntuとかでも同じだと思うけど)、Swapが設定されていないということ。

ケチったdroplet(汗)を立てているのでメモリが少なく、起動してるプロセスがOOM Killerの餌食になる可能性が少なからず存在しているかなと。まぁ、大したことをやっているわけじゃないのでOOM Killerに落とされたところでどうってことはないけれど、多少のswapで回避できるならそっちが楽かもしれない。

というわけで、DigitalOceanのWebサイトにswapの作り方が載ってたのでメモ。Difficultyがbeginnerになっているけど、dropletを新しくセットアップするタイミングでしかやらないので忘れがち(汗)

How To Add Swap on CentOS 6：
https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-centos-6

Ingressで「Scan FAILED」

2014年8月3日 / 管理人 / 0件のコメント

さぁて夕方になって暑さもひいてきたかな…ということで、スマホを握って外出してIngressを起動したら、近くにあるはずのポータルが見えない。

なんだ？と思って再起動してみるけど、やっぱり見えない(汗)とりあえず、画面のメッセージを眺めてたら、inventryとかareaをscanした後に、「Scan FAILED」って出てる。

しつこく再起動したり、アプリのキャッシュを削除してみたけど、状況変わらず…。Twitterを探してみたら、同じような状況になってる人がいるみたい。ってことは、API側で何かが起こってるのか。

でも、状況を眺めてみると、レゾネーターへの攻撃のお知らせが来てるってことは、ingressユーザー全体に影響が出てるわけではなく、運が悪い人たち(笑)が影響を受けてるようだ。

ということは、ingressの裏側では、ユーザーのIDか何かでシャーディングされたデータベースないし、エンドポイントがあって、その一つで問題が起こってるんじゃないかな。

…と妄想したところで、問題が解消するはずもなく、私よりingressに本気な人たちが通報してくれてるはずなので、特にすることもない。仕方ないのでぼんやりと飲みに行くことにした(汗)

AWSのSQS(Simple Queue Service)はFIFOじゃなかった。

2014年7月23日 / 管理人 / 0件のコメント

ま、タイトルの通りなんだけども…。

Queueというと、IBMのWebSphereMQみたいなものを想定しまいがちなので、そうすると、FIFOを保証してくれるんだよね!?とか思いがち(…てか、自分だけか)だけど、おそらく、S3なんかと同様に、裏側でメッセージのレプリケーションを行って冗長性を確保しているんだろうな、結果的に、FIFOを保証してないらしい。

SQSのFAQにはこんな記載があったので、メモ。

Q: Amazon SQS はメッセージへの「先入れ先出し」（FIFO）アクセスを提供していますか?

いいえ。Amazon SQS は Amazon SQS キュー内のメッセージへの FIFO アクセスを保証していません。その理由は主に Amazon SQS の分散的性質のためです。特定のメッセージ順序付けが必要な場合、それを扱うようアプリケーションを設計する必要があります。

OCNモバイルONEのIPアドレスを逆引きしたら。

2014年7月9日 / 管理人 / 0件のコメント

どうでもいいことだけど、ひさびさにOCNのモバイルONEのSIMカードを指してるAndroidから確認くんでIPアドレスを確認して逆引きしてみたら、「pxxxxxx-omed01.osaka.ocn.ne.jp」になっていた。

いや、あのー、私は千葉にいてスマホをいじっているんだけど、インターネットに抜けているのは大阪なのか。しかしまぁ、無線部分のディレイが大きいから、東京でインターネットにつながってようが、大阪でインターネットにつながってようが、実質的にはあんまり差が無い気はするから、どっちでもいいことか。

OCNモバイルONEって、少し前は東京でインターネットにつながっていたような気がするんだけどなぁ、気のせいかな。いやはや。

[amazonjs asin=”B014GZEPPK” locale=”JP” title=”【Amazon.co.jp限定】 IIJmio SIMカードウェルカムパック microSIM 版フラストレーションフリーパッケージ (FFP) IM-B095″]