鳩舎

レースしない

白金動物園として ISUCON 9 に出場し、優勝しました

感無量です。

やったことは GitHub 上ですべて公開されています。

github.com

いつものことですが、メンバーが何をしていたのか細かいことまでは知りません。

自分の記憶

  • [10:23:27] 862fe59 : Fix initialize MySQL file
    • MySQL のイニシャライズ実行ファイルのユーザーを root に変更。各位の手元で動かすときに楽させるため。
    • メンバーの手元の MySQL がどういう設定になっているのかは大体知ってるし。
  • [10:27:33] 2c68bf1 : Change database user
    • 同上事情。こちらはアプリ側。
  • [10:40:53] edd3254 : ええかげんにせえよマジで
    • app.rb で直したが、 MYSQL_USER が databaseMYSQL_DATABASE が user に渡されている問題を解決したコミット。くだらんところに罠埋めやがってええかげんにせえよ。という気持ちでコミットした。
  • [10:56:43] 0787d83 : :tada: ローカルで bx rackup と localhost:9292 で楽しく開発!
    • SPA なのにアプリが静的ファイルやマルチパスで index.html を返さない問題を解決して手元起動できるように。
    • のちに反している index.html が 0 byte なことに気づく。本物はサーバー上の /var/www/html にあって、それは後で sorah が引っ張ってきてくれた
  • [11:13:47] 98709c6 : Use our payment service
    • ペイメントサービスの URL をチームのものをデフォルト採用するように変更
    • この辺で完全にローカル開発 ready になる。同時刻少し前にペイメントサービスの CORS の問題を発見し出題チームへ連絡。コミット時には修正されていた。迅速な対応ありがとうございました。
  • [11:51:27] 8f05d4d : Static station master
    • station マスターをコードとしてダンプ
  • [11:53:45] 83aa96b : Fix stations
    • メモリから返す station が仕様と齟齬が出ていたため修正
  • [12:11:35] d15c54b : Dump master tables
    • 他マスタテーブルをコード化。Ruby の pretty print 形式でダンプした。
  • [12:22:22] 4a62d4b : Dump with marshal
    • ↑ダンプでは Date オブジェクトなどの問題があったため、 Marshal ダンプに形式変更。Marshal を信じろ。
  • [12:48:50] a730657 : Ignore direnv and log file
    • 普通に開発中邪魔なファイルを ignore した
  • [13:16:41] f618e86 : Get by memory
    • マスタテーブルから引いてるデータ取得をメモリ取得に
  • [13:24:19] edc16b8 : Get by mem 2
    • 同上
  • [13:24:20] 203c941 : Get by mem 3
    • 同上
  • [13:27:10] 8d1ea1d : Fix first seat
    • 同上の最中に発生したバグの解決
  • [13:28:07] 3a4cf40 : Fix nil bug
    • 同上の最中に発生したバグの解決
  • [13:44:02] 0b98982 : Get by mem 4
    • メモリからとってくる
  • [14:17:33] 3d467e5 : Allowed?
    • この辺からアプリケーション特有の問題の解決へ乗り出し始める
    • これはまず初手で、○△☓と残席数を表示する箇所が、フロント UI で『高負荷時は出ないときもあります』と宣言していたことによって試した変更
    • 『高負荷時とは?』『ISUCON 中は高負荷では?????』という安易な発想により(計算したくないし)全部固定で返すようにしようとする。
    • 結果は一行後わかる。
  • [14:20:08] 307fb0a : Fix fake avail
    • ダメでした。
  • [14:38:01] 114c047 : Cache seat available
    • でもやっぱ残席数がネックで遅いのでキャッシュして解決しようとする。実際、ここのチェックで問題でるほどチケット売れたチームいないんじゃないか?
  • [14:46:39] e57f0b9 : Long cache
    • キャッシュ戦略が通ったので調子こいてキャッシュの残存期間を伸ばす。30秒。怒られるだろうな〜って半笑いで入れたら通る。真顔になる(残席数チェックがずっと同数なのはチケットが売れていない = 負荷がさばけていない証左である)。
  • [14:47:07] 43d3ac4 : long avail days
    • Available days をデフォルトの10日から20日に増やしてみる。
  • [14:51:11] d5d5898 : Back to days
    • 即下げる。秒で怒られた。ひーん。
  • [15:28:22] e13716e : Good bye train master
    • Train Master テーブルへのアクセスを潰していく。Train Master は行数も多く、ここにアクセスしなければしないだけ、MySQL のメモリが空くことを狙っていた。事実、再起動後にスコアが上がったので戦略は正しかった模様。
  • [15:42:25] c22d034 : Change avail seats query
    • 残席数計算が必要のないテーブルをジョインしまくる謎の実装になっていたので削りに削った。あと、reservation に dep_id と arrival_id が入ったのでジョインの必要性が上がったというのもある。
    • これはそこそこ効いたっぽい。UNION でテンポラリテーブル作るのがな〜と言って、別立てのクエリ複数回にするかを悩むものの、キャッシュもされてるしネックじゃないからほっとけということでほっとく。
  • [15:56:41] d37fd2d : Seat resevation and date train info
    • seat_reservations に date と train_class と train_name を入れる。これで reservations とジョインしなくても大体発1で引けるようになる。インサートコストよりセレクトコストが重い。
  • [15:58:05] 5302b53 : Add placeholder
  • [16:10:07] bdb9986 : Unjoin resevertion
    • ↑のパッチで目指した通り。SELECT FOR UPDATE のロック範囲を絞りたいという狙いもあった。
  • [16:44:22] dac871d : Fix seat_reservations select
    • 予約時、 seat_reservations への N+1 クエリがバチボコ出るので1本化する狙い。実際問題うまく行ったし、効果も高かった。何十本と出ていたクエリが1本になると効果が高い。
  • [16:54:17] 92d3255 : Good bye seat master
    • ↑などの効果もあって、 seat master へのアクセスがどんどん必要なくなってきた。当然に大きなテーブルなので読まずにいれば MySQL のメモリが空く。当然アクセスやめる。
  • [17:09:25] dc767ed : Fix error
    • ↑↑のパッチがバグってたので直した。
  • [17:23:35] cbeff5f : Remove seat master
    • 最後まで seat master へのアクセスがちらほら残ってたのを潰しきった。
    • 貢献できたこととしてはこれが最後。

他やったことは残りの二人のエントリに詳しいはずなので、二人のエントリを待つといいです。

ISUCON と白金動物園

正直、優勝できたことが嬉しすぎてよくわからない。コミットを見返してみると本当に飛び道具めいたことは全然してなくて、ただただ愚直に、効きそうなことをじわじわと進めていった。残席数全部固定で返そうとしたやつが少し飛び道具だったけど、当然のように失敗した。

白金動物園としてチームを組んで、もう6年になる。6年間、成長し続けてきたかと言われれば自信がない。正直、会社経営者としての成長の方が多くあり、エンジニアとして強くなっていったのかでいえば少し腕が落ちたんじゃないかという危惧すらある。ISUCON 5で準優勝した時、1時間で Go 製 HTTP プロキシを書かされたが、あれを今やれるかと問われればかなり難しい。

予選前に id:mirakui が出ないかもしれないと言い始めた時、強い落胆と失望。そして安心があった。落胆や失望は『そうやってこの戦いへ背を向けるのか』というリーダーへの恨み言であり、安心は『彼がそう言ってくれるなら、あの恐怖の戦場へ向かわずに済む』という安堵だった。ISUCON は怖い。あくまでゲームでありコンテストだとわかっていても、スコアが出て、かつ業務らしく見せかけてくるアプリケーションを高速化するという設定が、自分のエンジニアとしての性能を明確に測られている気持ちにさせる。ISUCON で負けることで『お前はもうエンジニアではない』と誰かに言われているような気持ちになってしまうのではないか。あるいは、負けたことを言い訳にして『エンジニアとしては引退ですかね〜』などと心にもない言い訳を披露するハメになるのではないかと怯えていた。

だが出たかった。勝ちたかった。このチームで勝つことに価値があった。

スコアが発表されていく時の気持ちをまだ覚えている。3位のスコアを見て上位陣は全員 FAIL したのか!と怯え、2位のスコアを見て FAIL を確信し、1位のスコアを見て自分たちの最終計測より高くて『あ、関係ないわ』となってヤケを起こしかけた。白金動物園と名を呼ばれた瞬間、会場の全員を無視してメンバーに抱きついた。冗談やギャグのように思えるかもしれないが、あの20秒の間、会場にいる全ての人間がどうでも良かった。目の前にいる id:mirakuiid:sora_h の2人にだけ用事があった。2人もまた、会場を無視して互いの方を向いて腕を広げていた。

終了後、いくつかのチームに『白金動物園に勝ちたかった』『打倒白金動物園でした』みたいなことを言われた。正直、自分たちに耳目が集まっているなんて一切考えていなかったし、ぶっちゃけ本戦出場率50%のチームに用事もないだろうと思っていた。いままで他の優勝者や入賞者へやっかみや憧れがあって、自分たちはまだまだ弱いチームだとしか思えていなかったから、本戦後2次会で、メンバーの2人や戦ってくれたみんなに対してありがとうの気持ちがめちゃくちゃあって、何言われても楽しくて誇らしくて、これが優勝チームの気持ちか……とリーダーと声を潜めて少し笑った。

自身のエンジニアとしての成長に自信が足りなくても、チームとしての成長ならば 100% 保証できる。俺たちは強くなった。焦りが減り、無謀さを捨て、勇気を得て、信頼を作り上げた。6年前、チームを組もうと声をかけてくれたことに感謝したいし、切磋琢磨の場をつくり続けてくれた id:941 さんや歴代出題者たち、始まりを立ち上げてくれた古き強豪たち、すべてのみなさんへの感謝しか無い。

毎年おこなわれているのを眺めながら『まぁでももうちょっと技術力付けてからチャレンジかな……』と思っているみんなにはぜひ参加して欲しい。できれば、3人で。人生で何よりも信頼できるチームメンバーを得られたことは、僕の誇りだし、憧れるしかなかった古強者たちと肩を並べられる場所にくるまで成長する必要を感じられたのも、ISUCON という大会のおかげだ。

今年の優勝チームは Ruby だったらしいぞ、ってんでちょっと盛り上がってるけど、それすら僕個人にとってはフレーバーでしかない。ただ、使い慣れた言語で勝つ、という強いプライドとポリシーを保ちきれたことには、誇らしい気持ちがある。

次の ISUCON はめでたくも10年目ということで、大きな節目の年になる。来年どうなるかはまだわからないけれど、ぜひ参加したい。ウチは毎度奇数年しか本戦いけてないチームだから、もしかしたら予選落ちとかしてみんなから総ツッコミくらうかもしれないけど……w

なんだかまとまらないブログになってしまったけど、正直な気持ちをダンプしたらこうなったので、読みにくさは許して欲しい。

みんなありがとう。また相手をしてくれると嬉しい。

勝負だ!かかってこい!

Mac の常にスクロールバーを出す設定は最高

エンジニアが『このデザインは最高!』とか褒めてるサービスもどんどんぶっ壊れるし最高の気持ちになれる。とりあえずエン転職さんははてブに出してる広告直したほうがいいです。肝心の社名が切れてます。

f:id:rosylilly:20151130163928p:plain

さあ、今すぐ有効にしよう!

f:id:rosylilly:20151130164058p:plain

(こういうの気を使ってるサイトはきちんと表示されるのでえらいなーと思うこともできます)

ISUCON5 で準優勝しました

今年も @mirakui@sora_h と一緒に ISUCON5 に出場して、準優勝しました。

やったこと

時間は投入した時間。

  • 12:00 : API リクエストを送る先の services が DB に入ってるけど大した数でもない(7つ)ので、全部アプリケーションにハードコードした。
    • これはのちにリクエストにプロキシを挟む時にコード変更だけでよくなったので地味に効いた。なお、これによる高速化はあんまりしなかった(そりゃそうだ)。
  • 13:16 : API リクエストへのパラメータを保存している subscriptions の保管先を DB から Redis へ変更。
    • DB 問い合わせへの高速化というより、 JSON 形式から MessagePack 形式での保存になったことの方が重要な気がしてる
    • ま、これも大した効果は出てない。
    • initialize でバグったら話にならないから、それを回避するように気を使った
    • これはのちに API レスポンスを Redis でのキャッシュする際にすでに Redis への接続と Redis の initialize の準備が終わっていた。という点で効果を発揮することになる。
  • 14:21 : API リクエストの結果を Redis へキャッシュするように
    • 一部、キャッシュ期限がながいと問題を起こすので Expires は後に修正される。
    • Last-Modified にここで気づけていればといまだ悔やんでいる。ちくしょう。くやしい。
  • この後、API リクエストへの並列化などを sorah がやるのだが、どうしても Too Many Request が起こり続けるのでリクエストの交通整理をする Proxy が必要だという話になる。そのまま二人がこっちをむいて『え、出来ないの?』みたいなツラをするので『できらぁ!』と touch proxy.go して開発開始。
  • 16:36 : API Proxy の初版完成
    • 接続先を自由に変えられるように準備をしておいた
    • mirakui の手間を減らすため、 Makefile で依存パッケージやビルドをうまいことできるようにしておく。
      • 地味に make build をちゃんと作っておくというのは効果が出る。
      • インフラエンジニアに優しいコードを書こう
    • 高速に稼働するかどうかは大体自信があったし、俺の Proxy よりその先の API の方が絶対遅いから俺の Proxy はボトルネックにならねぇ!と自分に言い聞かせた。
    • なお、 GOMAXPROCS を入れ忘れたことに後で気付いて慌てて直す模様。
  • 17:15 : まだ TMR が出る。条件を調べるのは俺はやってなくて、 Go のコード見なおしたりしてたんだけど、どうやら Token が同じものを同時にリクエスト送るとダメらしい。その辺どうしようかという話になったので Proxy 側で吸収するから安心しろと声をかけると sorah が『ヤッター!』と声に出して喜んだのがかわいかった。
  • 17:37 : ということで約束を守るべく上記条件を守る仕様を 20 分ちょいで実装。バグなく投入できてお父さん安心しました。
    • この辺でもう疲れきって頭ほとんど動いてない。
    • 『多分行けると思うけど、俺もう mutex は手癖で書いてるからよく考えてない』と mirakui にはこぼしたのだが、実際、 ISUCON4 の時に『俺は並列処理が死ぬほど苦手なんだよ!』と運営部屋で泣き言漏らしてからはちゃんと勉強したし、それこそ手癖で Mutex 周りを書ける程度にはなっていてよかった。
    • なお、綺麗にバグなく投入できた模様。
  • 17:50 : 手元で行う最終計測。再起動試験はふたりにまかせていたのでこの辺では俺は Proxy のコードを読みなおしながら『Mutex ちゃんと動いていてかわいいなあ』とか思ってた。

いいインフラエンジニアが二人いるとコードを書くだけの機械になれて最高

二人は config の変更や小さいパッチが多いので直接 master にコミットしているのだが、俺のパッチは大抵の場合でかい(上を見てもらえれば分かる通り)ので、概ね PR にして出している。 GitHub 上で revert 出来るようにするためで、こういう焦っている状況で自分が git のコマンドを間違えないなんてことはまずないだろうという自分への不信から、そうやってる。

おかげでコードレビューをする機会があるので、二人が詳しくなにをやってたか俺はわかってないけど二人は大体俺が何やってたか知ってる状況にある。これはいいことで、書かれたアプリケーションの内部をわかってるインフラエンジニアは、うまくリソースを使うために適切なインスタンスにアプリケーションを配置してくれる。いやー、こうして書いてみると俺ほんとに二人に依存してるだけだな。無能かよ。

ただまぁ、今回自分のパッチを revert するようなことになることはなかった、というか、基本『あ、やっぱさっきのなしで!』と手戻りすることがなかったと思う。この辺の『妥当なことを妥当にやり続ける』というのが出来るようになったのは明らかに出題してからなので、みんな ISUCON で勝ちたかったら ISUCON の出題者やる方がいい。特にベンチマーカー実装者は Mutex を無意識で書けるようになるぞ!

HTTP/2 について

多分 h2 だったと思うんだけど、何で書かれてるかわかってない。3つか4つ、 Go のライブラリを試したのだが、古いのもあたらしいのも動かなかったので途中で諦めた。

libcurl + nghttp2 だと動いた、 node-http2 がいけるみたいな話なので、 h2 説が濃厚かな。 h2 に対応してる h2-12 に対応してる Jxck さんの http2 でもダメだったから、やっぱ h2 だと思う。

他、いろいろ試そうと奮闘していたのだが途中で手元から API サーバーに繋がらなくなって諦めた。どうやら俺のおかげで何度か API サーバーが死んでいたらしいとあとで聞かされたが、しったことか思わせぶりなことする奴が悪い(冗談です、ごめんなさい)。

まとめ

Proxy を書いていた1時間のうち 30 分程度は HTTP/2 のライブラリをいろいろ試すのに時間を食われていて非常に悔しい。一個試してダメだった瞬間にもう考えるの辞めればよかった。思わせぶりな女子に貢ぐみたいな感じになっていた。

また、俺がやっていたこと以外は 昼メシ物語 とか読むといい。 mirakui はよく働くしいいリーダーやでほんま。お前らにはやらん。

sora_h と今年は喧嘩してないって mirakui が書いてたけど本当で、 mirakui が俺と sora_h の『喧嘩』と『言い合い』の違いがわかるようになったの、あきらかに ISUCON4 の準備中なのでやっぱり出題しといてよかったな!

で、寝坊してタクシー飛び乗ったんですけど、寝不足の頭で役に立たないくらいなら寝坊しても寝たほうがいいと思います(結果がマシだったから言えること)。

ということで、お疲れ様でした。出題チームには感謝しかない。嘘です。悔しいです。悔しい。悔しい。クソッ。来年は優勝したさすぎる……。

あわせて読みたい

(個人用途において)ほぼ最強に近いスクリーンキャプチャ / スクリーンキャスト環境

スクリーンキャプチャやそれらを共有するツールはいろいろ出ては消えの状態で、どれを使うのがいいのかという話になると難しいかと思います。

スクリーンキャプチャを撮りたい状況には概ね3くらいあって

  1. 単純にファイルとして保存したい
  2. チームメンバーや友人等に共有したい(URL もしくはファイル送信)
  3. スライド作成時などで、スクリーンキャプチャをスライドに貼り付けたい

こんな感じ。全部に応えるツールというのはなかなか難しいのだが、どれか1つずつに効くツールはあっても、コレに加えてスクリーンキャストまで面倒みてくれるものとなると中々難しい。

ということで僕はこんな感じで環境を作りました。

Monosnap + Amazon S3 + Fastly

Monosnap というのはこのツール

Monosnap

Monosnap

  • Farminers Limited
  • グラフィック&デザイン
  • 無料

こいつ、何が優秀かというとこういうことが出来る。

http://img.aduca.org/screen-capture/2015-10-04_02-37-16.gif

もちろんこのスクリーンキャストそのものも Monosnap で撮ってる。Monosnap 自身が Gif に変換してくれるし、なかなか綺麗だから気に入ってる。

このファイルハンドルとアップロードボタンのおかげで、上記の3つの需要はすべて満たせる。LINE で送るときや Slack に貼る時はファイルハンドルでドロップすればいいし(Keynote でも)、URL が欲しければアップロードすればよい。

で、こいつは S3 へのアップロードに対応しているというのがミソ。

http://img.aduca.org/screen-capture/2015-10-04_02-39-53.png

こんな感じで設定しておけば、スクリーンキャプチャとってアップロードボタン一発で S3 上に配置して URL を出してくれる。

しかも、上記サンプルのように適当にぼかしをいれるとか、赤枠でかこって強調するとかのちょっとした編集にも対応している。

ただ、 S3 はそんなに早くないので(といっても今回のような用途に使う限りにおいて困ることというのはそんなにない)、できればちょっと早く配信したいなーという時は、 Fastly で S3 を Origin にして CDN にしてしまえばよい。

ホスティングするコストについては多少お金がかかってしまうので、みんながやるかというと怪しいけど、そんなにお金かからないし、おすすめだと思います。

ISUCON5 予選でアニメ見た

今年は参加者側として ISUCON5 に出てきました。チームは白金動物園。いつもの(@sora_h, @mirakui)メンツです。

何やってたかについては大体 sorahのエントリ に書いてあるので割愛。というか前頭葉破壊されて覚えてないです。

真剣な与太話

  • 9:30 チームビルディングと称して アイカツ! #152 を見る
  • 10:00 チームビルディングの一環でリアルタイムでプリパラ #64 を見て、前頭葉を破壊される
  • 10:30 チームビルディング、そして緊張を解くために ゆるゆり なちゅやちゅみ!+ +2 を見る

これを見てなにやってるんだと思われたかもしれませんが、あくまで僕に限った話(二人はどうだったか知らない)をすると、これは本当に助かった。

開始前の9:00時点だと、リラックスしてるつもりだったけど『前回の問題作ったヤツが予選敗退とか笑えない冗談だろ』みたいな感じで、めちゃめちゃプレッシャーを感じていた。本当にもう怖いから予選出るのやっぱ辞めますとかいいたかったぐらい。

でも、まぁ、そんなこと言ってる場合でもないから、ぐっと腹に力入れて臨んでいたんだけど、予選の開始が一時間伸びたことで、アニメ見始めることになった。当日の空気感については以下のツイートの通り。基本開始前はただのアニメ見てる人だった。

で、こういうアニメ視聴のおかげで『単純に ISUCON 楽しいしやるかー』という精神状況で予選に臨めたのは本当によかった。ようするにリラックスできたしアニメ見ておくのはよかったねという話です。

実際、今回の ISUCON で脳が焼けつくほどヒリヒリはしたのだが、あんまり焦りはしてなかった。焦って適当なコード書くよりは、きちんと一発で動くコードを書こう、みたいなスタンスで、実際にあしあと機能を Redis に載せ替えたりしたんだけど、それについても一発マージで綺麗に動いたので本当に良かった(なお、後に仕様の確認漏れが発覚するもよう)。

まとめ

ISUCON5 本戦会場でアニメ流してるチームがいたら多分僕らですから、一緒にアニメみましょう。

VOD で配信されてるアニメ検索するページ作った

TL;DR

https://anime-search.herokuapp.com/

捗る

動機

各社の一覧ページ、わざわざ五十音順でページ分けされたりしていて厳しみがあるので、一括で検索するページが欲しかった。

あとインクリメンタルサーチしたい。

内容

現在はバンダイチャンネルと D アニメストアの作品だけ検索出来る。他のサービスはクローラー書くのがめんどくさくてやらなかった。

だれかやってくれるなら https://github.com/rosylilly/anix ここに PR ください。 Provider::Crawler::HogeCrawler で実装してくれると嬉しい。

PPV = Pay per View なものを除外しつつ検索するのが主眼なので、 Without PPV のオプションがある。

ちなみにこれのおかげでバンダイチャンネルの見放題作品数は886作品、Dアニメストアは1295作品だというのがわかった。400作品くらい多く見れるDアニメストアは優良サービスですね。

練習がてら React を使ってるんだけど、この使い方が正しいのかわからない。あんまり複雑なことしてないから多分これで正しいんだと思う。

まとめ

D アニメストア契約してアニメ見ましょう。

アニメ視聴に主眼を置いた VOD サービスの比較と解説

2015-04-30 版。俺が使ってるあのサービスがねえぞどうなってんだという方はコメントでサービス名を書いていただけますと僕が金を払いに行きますのでよろしくお願いします。

TL;DR

コスト及び物量重視なら d アニメストア。コメント見たかったらニコニコ。いろんなデバイスで見たかったら Hulu いいけどそんなに数ないよ。

VOD サービス

自分がお金払って契約した(している)ものは以下

  • Hulu
    • 長いこと契約してる
    • 異常としかいいようがないくらいいろんなデバイスのクライアントある
      • Panasonic だと TV にアプリ入ってたりするし謎の開発力
    • PS4 / PS3 にもアプリがあるし、ログインも簡単
      • PS4 でパスワード打たなくてもログインできるのめちゃ便利
  • U-NEXT
    • UQ-WiMAX 契約したあとに朝から『U-NEXT 契約しませんか』って電話かかってきて『あぁうん、どうぞ、お好きに』って答えたら契約してた
    • 最初にもらったポイントでガルパン一気見したことしか覚えてない
    • エロ動画が結構あってサムネだけみたんだけど見放題の中に入ってなくて個別課金だったから見てない
  • バンダイチャンネル
    • いつもお世話になっております
    • 連続再生機能が優秀で、流しっぱなしにするのにこれほどいいクライアントはない
    • 他人のマイリストみたいなのが見れて『ほのぼの系ならこれ』みたいな作品集がわかりやすい指標で便利
    • 個別課金も結構あるので、なんでも見れる訳じゃないけど、適当な作品を流し見したいという用途には向いてる
  • ニコニコチャンネル
    • にぎやか
    • はい
  • d アニメストア

あとは他にも契約したやつとかあるかもしれんけど覚えてないんで勘弁してください。

基本的に視聴環境は PC(Mac) で、サブディスプレイに流しっぱなしにする用途として考えてください。もしくは電車乗ってる時に見る iPhone

Hulu

洋画が見たくて契約してるようなもんなので、あんまり他と比べるのものなぁと思いつつも、結構いい。

視聴時間を同期できるので、電車の中で半分みた映画を PC で続きから見るというような使い方もできる。

結構コンテンツの入れ替わりが激しくて、2週間くらいでアニメが増えたり減ったりする。これはドラマ類も同様。特に公開終了期間は目立つか形で出ていないので留意しておいたほうがいい。

うちで動画を再生するデバイスといえば Mac / iPhone / iPad / PS4 が主なので、これらすべてにまともなクライアント(純正)がある Hulu はやっぱ便利。洋画も最近は吹き替え版を置いてくれるようになったりしているので、字幕版しかなくて興味を失っていた人はもう一度見てみると良いです。

U-NEXT

そんなにちゃんと使ってない。ポイントでガルパン一気見したという記憶しかないサービス。

区分として『見放題』『個別課金』『ポイント可』というくくりがある。詳細は、

  • 見放題 : 有料契約会員なら特に何も支払わず見れる。ちなみに有料契約会員は月何ポイントかもらえるっぽい。
  • 個別課金 : 個別に支払う奴。一話100円とかそんなの。ポイントで支払うことが出来ない。エロとかはこの区分。
  • ポイント可 : ↑のポイントが使えるタイプ。アニメとかはコレが多い。

というような感じ。正直あんまりおすすめしない。

地味に芸の細かいところとして、ページ中にならんだサムネイルの製作委員会名などがページ下部のコピーライトに出ていて面白い。

バンダイチャンネル

最近 iPhone 向けアプリが公式から出た。便利になって嬉しい。けど、 iPad 非対応なのが悲しい。なんとかなってほしい。

また、ログインするとほかデバイスのログインが切れるのも難点。昔のニコニコ感がある。なんとかなってほしい。

画質は大抵の場合さほど問題になるようなことがないが、 480p だと少しつらい時があるので 1080p 要らないから 720p が全体標準になったらいいなーって思ってる。なんとかなってほしい。

と、まぁなんとかなってほしいばかり言ったけど、基本的には文句なく使えるいいサービス。 d アニメストアに出会うまでは最高だと思っていました。 iPad 向けクライアントはないけど、 Safari で見れるので正直そんなこまんないよ(連続再生で困るくらい)。

前述したとおり、他人のマイリストを見れるので、自分でアニメ探しするのが面倒な人はそこから探すと、似た趣向のアニメを探せて便利だと思います。

ニコニコチャンネル

  • 月額 : 540円(正確にはプレミアム会員費用なのだが、これを契約しておかないとまともな画質で見れないので前提条件とする)
  • PC: Flash / iPhone: App

にぎやかで大変よろしい。

基本的には最新話をみんなでわいわい見るためのサービス、なのだが、 Torneニコニコ実況連携があるので、ガヤガヤ感だけ楽しみたいなら Torne だけで事足りたりする。SF やパロディが多い作品は解説付きで見れると楽しいのであえてニコニコで見るという選択肢もありだが、どうしてもコメントに引きずられて先入観が入りがちなのが難点。

ほかサービスと比べ圧倒的(興味がなくても気づくレベル)の画質の悪さが難点。ただし、それを補って余りあるほどの付加価値なので、ほかサービスとの併用をおすすめしたい。

まぁこんくらい褒めておけばいいだろ

d アニメストア

なんか声優から作品を探せたりするらしい。まだしっかりつかってないので分からないが、結構古いのもあってよろしい。

連続再生時、毎度画質の選択が出てしまうのが難点。できればそのまま遷移するようになってほしいな…… BGV としての利用にはあまり向かない。しっかりアニメ見たい人向け。

HD 画質対応とのことだが、配信しているデータがすべて HD に対応しているわけではないのか、「すごくきれい」までしか選べないものがいくつか。これはちょっと残念。

安くたくさんみたいだけの人向きだと思います。当たり前だけど DoCoMo のケータイ払いもできるみたいなので、学生さんとかはここを選ぶのが一番だと思います。

録画について

Nasne があるので録画しているものもある。プリキュアとかどこも配信してないんで録画でみてます。ほんときららちゃんは最高やな。

ただ、大量に録画するとなるとストレージを追加していかないといけないし、 NAS サーバーの保守なんて家でやる気起きないし、ストレージ追加していくのもコストかかるし、増やせば増やすだけ継続的に保守コストがあがっていくので一切やる気がない。アニメを見たいのであって RAID を組みたい訳ではない。

電車内で暇だから『アニメでも見て時間潰すか』と思いついた時に家から持ちだしていないと見れない、みたいなことになるので、基本的あまり活用していません。自宅に固定 IP 引いてリモートプレイ対応させて……とか、もしくは PT-3 などを買って録画サーバーを……とかやればいいのでしょうが、アニメを見たいのであって ffmpeg をいじりたいわけじゃない、というので却下。

端的に言えばらくするために金を払っているという感じです。

まとめ

全アニメ HD 再生可能及び作品数で上記にあげたもののすべてを網羅している、かつ最新アニメを順次放映後もしくは放映開始と同時に視聴可能になる、というようなサービスがあれば月3万まで出す用意があるので各位よろしくお願いします。