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

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

シンガポールにはオーストラリアより東京の方が近かった。

まぁ、物理的な距離を考えると、そんなことはあり得ないけど、先日借りた、DigitalOceanのシンガポールリージョンにあるVPSから、PHPのソースコードをダウンロードしてみた。PHPのソースは世界中のサーバでホスティングされているし、容量もめちゃくyちゃ大きいわけでもないし、そんなに小さいわけでもないので、試してみるにはイイ感じということで。

ダウンロードさせてもらったのは、以下の3つのサーバ。本来なら、何回か試してみるべきなんだろうけど1回だけ試してみた(ので、たまたま、向こうのサーバの負荷が高かったりしたら影響を受けてるな)で、wgetで表示される、平均スループットも書いておきますよ、と。

  • jp2.php.net(snotch)@日本:4.46M/s
  • at1.php.net(Goodie Domain Service)@オーストラリア:261K/s
  • us1.php.net(NEXCESS.NET)@アメリカ:2.74M/s

うーむ、シンガポールからはオーストラリアは遠いんだなぁ、と思ったが、結局は海底ケーブルがどれだけ這っているかってところに依存してるから、物理的な距離はあんまり関係ないんだろうな。いやはや。

てか、Googleはオーストラリアでドメイン管理事業やってるのかっ!と思ったら、Googleじゃなくて、Goodieだった(汗)

あ、facebookが落ちてる。

あ、facebookが落ちてるなぁ。意外とfacebookのsorry page見るのは初めてかも。いろんなサイトに貼ってある、facebookのボタン(…うちのサイトのfabookボタンが妙な感じだ…)も軒並みアレな感じ。facebook、大規模な攻撃でも受けたのかな。

facebookが落ちている。

facebookが落ちている。

ap-northeast-1bが復活してる

もう見飽き始めている、AWSのマネジメントコンソールを今日も眺めていたら、しばらく消えていたはずの「ap-northeast-1b」ってAZが復活しているのが見えた。まぁ、さすがにap-northeast-1aとap-northeast-1cって構成も不自然だしなぁ。

ま、きっと、東京リージョンは3AZ体制で運用するんだろうな。

aws-cliで東京のS3バケットにファイルをアップロードしようとするとエラーが出る件

ECで動いている、CentOS6のマシンにaws-cliをインストールして、

aws s3 mv (とあるファイル) s3://xxxxx/xxxx/

とかやろうとすると、なんかエラー出た(汗)なんとなくこんなエラー。

HTTPSConnectionPool(host='(バケット名).s3.amazonaws.com’, port=443): Max retries exceeded with url

で、よーく見ると、ホスト名がおかしい。東京リージョンならエンドポイントはs3-ap-northeast-1.amazonaws.comだと思うんだけども。で、仕方ないのでdebugオプションを付けて実行してみたら、実行している途中で、Checking for DNS compatible bucketをやった後、 URI updated toで間違ったエンドポイントに書き換えられてるし…たぶん、これはaws-cliのバグじゃないのかなぁ…と思って探してみたら、githubにそれっぽいissueを見つけた。

Uploading files to S3 from EC2 instances fails on some instance types:
https://github.com/aws/aws-cli/issues/634

うーむ。なんかworkaroundっぽい何かが出てるけども…。ま、URLの書き換えられ方的に、東京リージョンじゃ無くて、US Standardリージョンでバケット作ればアップロード出来そうな気がしたので試してみたら、アップロードできた。どうせ、バックアップデータをs3に置いておくだけなので、ま、US Standardでもいっかという気がしてきた。

[amazonjs asin=”4822237443″ locale=”JP” title=”Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版”]

m1.smallのswap領域にエフェメラルストレージ。

EC2でm1.smallなインスタンスを起動してみた(本当はm3.mediumがいいんだけど、予算が足りない…。m3.smallとか用意してくれないだろうかって無理か)。AmazonLinuxを使ってたら、swapをどうするか心配しなくていいんだろうけど、やはりお金がない状況下なのでCentOS6を選択。

そしたら、swapが存在しない。EBSの上にファイルを作ってswapにしてもいいけど、データの出し入れで課金されるタイプのストレージを使ってたら(ま、たいした金額にはならないような気はするけど)、なかなか切ないことになりそうだけど、インスタンスストアというか、エフェメラルストレージを使ってswap領域を作ることにした。

…とはいえ、インスタンスストアを起動時に割り当てておいて、後は、/etc/rc.d/rc.localに対して、

mkswap /dev/xvdf
swapon /dev/xvdf

を追記しただけなんだけど。そしたら、m1.smallは、エフェメラルストレージとして160GBのHDDのストレージが使えるので、160GBのスワップ領域ができた(汗)なんかでかい。

起動時に/dev/xvdfに対してext4あたりのファイルシステムを作って、そこにファイルを置いて、それをswapに使ってもいいような気がしたのでちょっと試してみた。HDDの160GBの領域にファイルシステムを構築するのに時間がかかるのが…ちょっとなぁ。再起動がかかった後、(ファイルシステム作ってて)立ち上がってくるのに時間かかるのが実に微妙。うーむ。

DigitalOceanのSingaporeリージョンでIPv6

さっき、DigitalOceanから下記のようなメールが来てた。どうやらSingaporeリージョンでIPv6が使えるようになったらしい。手許でIPv6を使える環境というか端末がないので試しようもないんだけど(汗)シンガポールで動かしてるサイトのドメインにAAAAレコードでも設定してみようかな。

Since our launch, IPv6 has been one of the most requested features by our community. Today we are excited to announce that public IPv6 addresses are now available for all Droplets in our Singapore region.

DigitalOceanでNTPサーバを参照できない件。

DigitalOceanでVPSを起動してセットアップしているものの…なんかNTPサーバに時刻を参照しにいけてない様な気がするけど、ntp.pool.orgで公開されている、シンガポール国内のものと思しき、特定のNTPサーバにはアクセスできているという不思議な感じはなんだろう。

…と思って調べてみたら、DigitalOceanのサポートコミュニティのページにこんな記事(「Droplet in Singapore can’t sync NTP server.」)があった。どうやら、DigitalOceanのシンガポールのデータセンターでは、NTP reflection攻撃を食らっているらしく、とりあえず、NTPのパケットをブロックしているらしい。解決に向けて作業しているけど、いつまでに解決するというメドが立たないらしい。で、これはシンガポールのデータセンターだけの現象で、もし、どうしても時間を同期しなきゃいけないようなら他のリージョンにインスタンスを立ててくれって…ことらしい。

書き込まれたのが5月末くらいで6月の中旬でもまだNTPを使ったDDoSか…ま、タチが悪い。

EBSのVolumeTypeにSSD登場。

EC2でインスタンスを起動しようとしたら、VolumeTypeのところが「Maginetic」「General Purpose(SSD)」「Provisioned IOPS(SSD)」に拡張されていることに気がついた。例の如く、日本語のドキュメントは間に合っていない雰囲気だけど、英語のドキュメントは用意されている。→「Amazon EBS Product Details」を開いて、英語に切り替えると、それぞれのVolumeTypeの詳細が表示された。

端的には、SSD-backedなEBSが使えるようなったらしい。で、これまでのstandardのEBSはMagneticと改称された(ま、SSDじゃないってことはHDDなんだろう)。んで、そのIOPSは、Magneticが平均すると100IOPSくらいで、General Purpose(SSD)が使う容量の3倍のIOPSらしい。つまり、20GB使うと、60IOPS。Magneticより少ないじゃないか…と思いがちだけど、30分の間、3000IOPSまでバーストすることができるらしい。うーむ。30分ってどういうことだろう。3000IOPSが30分続くと制限される(制限されて、使っている容量の3倍のIOPSになるのかな)ってことかな、と勝手に理解しておこうかと思うけど、…なんか違うような気もするな(汗)

んで、料金体系を眺めると、東京リージョンで、「General Purpose(SSD)」が$0.12/GBで、「Maginetic」が$0.080/GB。だいたいSSDの方が1.5倍くらいの値段か。ただ、これに加えて、「Maginetic」の方はI/O requestの課金が加わるが、「General Purpose(SSD)」にはそれがないっぽい(「Provisioned IOPS(SSD)」にはありそうだけど)これまでのEBSのbillを見る限り、割とI/O requestの課金で課金されている雰囲気なので、GB単価で1.5倍の価格差はあれども、意外とと「General Purpose(SSD)」がお得なのかもしれない。

ま、LinodeやDigital OeceanがSSDを積んで、それなりに安いVPSをリリースしているので、業界のリーダーのAWSとしては無視できないってことなんだろうか。

追記:
AWSのブログに、「General Purpose(SSD)」のIOPSに関する解説を見つけた。うーむ、難しい。。。

【AWS発表】新しいSSDベースのElastic Block Storage
http://aws.typepad.com/aws_japan/2014/06/new-ssd-backed-elastic-block-storage.html

GooglePlayでアプリを更新しようとすると「容量不足」

近頃、Androidのアプリの更新頻度が上がってる気がするのは気のせいか。ま、アップデートってのはユーザの関心を引きつけるいい機会なので、大してバグフィックスしなくてもアップデートをかけてみるのはありだろうな。特に、アップデートするからってGoogleから課金されるわけでもないし。

そんなわけで、ぱらぱら出てくるアップデートを適用しようとしたら、「容量不足」って怒られた。本体内のメモリ(いわゆる、機器メモリー)が埋まってしまっているらしい。うーむ。で、どのアプリがどれくらいのストレージを使っているか調べてみたら、Chromeが185MBとか…。私のXperiaの機器メモリーは2GBしかないから、結局、Chromeで10%近くが埋まっていることになる。

とりあえず、ブラウザのキャッシュなどが溜まってることが疑われたので、設定からプライバシーを開いて、キャッシュなどをごそっと消してみたけど、ストレージが空かない。うーむ。で、Google Playで表示されているChromeのアップデートは30MB近く。Androidのアプリは差分更新とかしないから、ダウンロードするサイズ=アプリのサイズのはずだ。で、そのapkを機器メモリーに展開したら185MBにもなるもんだろうか。

一旦、キャッシュと一緒にcookieなども消しちゃったのでChromeに消えちゃまずい情報は残っていない。そこで、一旦、Chromeをアンインストールしようと思ったけど、アンインストールはできないのでアップデートを削除してみた。その後、もう一回、アップデートを適用し直して見たら、機器メモリーの使用サイズが70MBちょっとになった。

Androidのアプリアップデートの仕組みに明るくないけど、要らなくなったapkとか、保存してあるんだろうか。ま、とりあえず、機器メモリーの無駄遣いは解消できたっぽい。

[amazonjs asin=”B012SXM6XU” locale=”JP” title=”エイスース SIMフリースマートフォン ZenFone 2 Laser(Qualcomm Snapdragon 410/メモリ 2GB)16GB ホワイト ZE500KL-WH16″]

MariaDB 10.0系がいつの間にかGAに

ふと、MariaDBのWebサイトを見てみたら、2014年3月31日にリリースされた、Ver 10.0.10からGA(Stable)でリリースされていた。うーむ、ぜんぜん気付いていなかった。そして、そのバグフィックス版であるVer.10.0.11が2014年5月12日にリリースされているではないか。

ま、これまではMariaDB 5.5を使っていたけれど、これからはMariaDB10.0を使うことにしてみようか。とりあえず、WordPress向けのデータベースとして、簡単に使ってみようと思う。

What is MariaDB 10.0?
https://mariadb.com/kb/en/what-is-mariadb-100/

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