ただのにっき。

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

15ページ目 (40ページ中)

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

今日、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に本気な人たちが通報してくれてるはずなので、特にすることもない。仕方ないのでぼんやりと飲みに行くことにした(汗)

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

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

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

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

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

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

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

どうでもいいことだけど、ひさびさに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″]

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

まぁ、物理的な距離を考えると、そんなことはあり得ないけど、先日借りた、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の領域にファイルシステムを構築するのに時間がかかるのが…ちょっとなぁ。再起動がかかった後、(ファイルシステム作ってて)立ち上がってくるのに時間かかるのが実に微妙。うーむ。

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