ただつらつらと日記が書かれていくようです。

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

さくらインターネットに東京リージョン

…いや、実にどうでもいいことなんだけど、さくらインターネットのWebを見てたら、こんなニュースリリースが出てまして。

さくらインターネット、「さくらの専用サーバ」東京リージョン提供開始

インターネットデータセンター事業を運営するさくらインターネット株式会社(本社:大阪市中央区、代表取締役社長:田中 邦裕)は、2014年10月1日より、最速10分納品の高性能専用サーバサービス「さくらの専用サーバ」において、東京リージョンの提供を開始いたします。

「リージョン」というのは、AWSやニフティクラウドみたいなクラウドベンダーがデーターセンターの所在地をもやっとさせつつも、この辺ってことを示すために使われている便利なキーワードであるような気がしてて、どうもクラウドベンダーが使いがちなワードかなぁとも思うわけです。

そんなわけで、さくらインターネットがニュースリリースで「東京リージョン」というキーワードを使っていたので、うっかりと、”さくらのクラウド”もとうとう東京進出かーと思っていたら、従来型の専用サーバのサービスを「東京リージョン」で提供するってニュースらしく。まぁ、シンプルな勘違いってコトでごめんなさいってことではあるんですけど、さくらのクラウドも石狩以外のリージョンで提供しないのかなぁと楽しみにしていることではあるんですが…いやはや。

DellのVenue8では、Chromeが遅いらしい(体感値…汗)

社内でDellのAndroidタブレット「Venue8」を使っている人がいたのだが、どうやら、GoogleのChromeの動きがモタモタするらしい。ちょっと触ってみたが、タブの切り替えや、別アプリを起動している状態からChromeへの復帰とかのシーンで、なんか頑張ってそうだけど画面的には動きがなくて残念な状況になってしまう。

で、どうしたもんだかと相談されたので、すんなりとChromeはそのうちアップデートが行われるでしょうけど、それまでは特に手の打ちようもないので、素直にFirefoxにしましょうということで、GooglePlayからFirefoxをダウンロードしてインストールしてあげたら、(Chrome比で)かなり快調に動くようになったそうだ。

…しかし、手持ちのARMなAndroid端末(各種、Snapdragonとか、Exynosとか)では、Chromeがそんなにもたつくような状況は起こらないので、x86なAndroidならでは(DellのVenue8はIntel Atom搭載)の症状だろうか。まぁVenue8は1GBしかメモリを積んでいないので、そのせいかもしれないけど…でも、めちゃくちゃメモリが少ないって感じでもないけどなぁ。。。そういえば、Dellだけでなく、Asusあたりも7インチや8インチあたりのタブレットにAtomを搭載しているので、Asusのプロダクトでも同様の症状が起こるのか気にならないでもないけれど手許にない(汗)

…DellのFirmware(素のkitkatにDellが味付けしたもの)のせいだとすると…これは切ない事象かもしれない(遠い目)

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

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

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

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

これはXen Security Advisory (XSA­108)に関する全てのセキュリティリスクから皆様を守るために実施され、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の故障率とか

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

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

Hard Drive Failure Rates by Model

いやー、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のデスクトップアプリがなくなった。

ちょうど一年前くらいに「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のカメラ

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

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

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

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

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

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

LinodeとかDigitalOceanとか。

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はメールで送られてくるんだったか)感じはなかなかドキドキしないでもないけど。

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

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

今日、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追加

ちょっと検証しようと思うことがあって、久方ぶりに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」

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

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

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

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

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

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

«過去の 投稿 新しい 投稿 »