【ニコニコ動画】 障害が起きるのは仕方がないと思うんだ

なんでかっていうと、ソフトウェアの問題ならともかくハードウェアなんでしょう?「障害を予期して」なんて昨日は書いちゃったけど、ハードウェアだったらまぁ無理。本当は二重化してなきゃいけないんだけど、資金の都合で出来ないんだったらもう仕方がない。障害が起きるという前提で、そこからどうするかが求められるわけですよね。ええ。 一番大事なのは素早い復旧。初動の問題については川上さんも言及されてるけど、復旧に掛かった時間を考えると初動が1時間早かったら問題にならなかったかって言うと別にそういうわけではなさそう。 次に、障害情報に関する告知。これは戀塚さん関連のまとめにもあるけどちょっと遅すぎ。別に恋塚さんが動いたから解決したわけではないのだろうけど、でも印象としてはそうなっちゃってる。その間に右往左往したユーザーにとって見れば「運営は修正する気がない!」。何時間も動けなかったんだったら仕方がないけど、既に復旧作業を始めていたにもかかわらず「作業始めるのが遅い」と思われていたんだとしたらそれは何というか本当に勿体ない。現場のエンジニアの人たちのことを考えると心が痛い。広報もっと頑張れよ。 最後にプレミアムの扱い。夏野さんの発言は放っておくとしても、プレミアム回線にだけ障害が起きた場合、一般回線を空けてそこにプレミアム回線を振り分ける…という仕組みはできないもんなのだろうか。ただの混雑とは種類が違う作業になるんだろうけど、想定しておくべきなんじゃないのかな。

何が悔しいのかというと。

他の人はどうか知らないけど、僕の認識では「ドワンゴ」「ニワンゴ」というのは技術屋の集まりで、基本的にあらゆることを技術的アプローチで解決していって素晴らしいサービスを作り上げたと思ってるんだけど、その技術屋集団が起こりうる障害に対して諦めるしかない、と思っているところ。現場はそうは思ってないかも知れないし忸怩たる思いかも知れないけれども、現状ある解決策に対する資金面での判断は「無理」なわけで、逆に言えば資金に適う解決策がないってこと。それが何か悔しい。 技術で障害を回避するのが不可能だったとしてもその後のアプローチを技術的に改善することは出来たはずで、結構そういうところの技術ってあるはずなのに出来なかったってことは、単に「やらなかった」ってことなのかなぁという。そういう技術屋が負けた感を勝手に感じていて、それが悔しいというか、残念というか。 いや、それでも何とかしてくれると僕は信じてる。 むしろ、3ヶ月後くらいに同種の障害が起きて欲しいなとも思ってたりしてw そこで見事な対応がなされたら、技術者としてはもの凄いカタルシスを感じるよ。

参考

続きを読む

【tips】 PEAR::Cache_Liteのディレクトリ構造を深くする

レンタルサーバではmemcachedなどを使用することが出来ないので、何らかのファイルキャッシュを使うことが多いと思うんですが、いくつかのサービスではPEAR::Cache_Liteを導入しています。 Cache_Lite 規模が大きくなるとI/Oがネックになるので、ファイルキャッシュはいずれ問題になってくるのですが、小規模なサービスであればこれで十分。 で、導入自体は極めて簡単なんですけど、気になったのはディレクトリ。UNIX系サーバでは1ディレクトリにおけるファイル数は10,000くらいなので、サービスを継続しているといずれキャッシュが作れなくなってしまう。でもCache_Liteの設定(インスタンス生成時にオプションを配列で渡す)ではディレクトリを渡すだけ。今は大丈夫だけど念のためディレクトリを構造化したいな… と思ったら、ちゃんとその設定がありました。 マニュアルは細かく読まないとダメだね。

続きを読む

PDO::FETCH_CLASSとgetter/setterのマジックメソッド

「食わず嫌い」とはアレなものでして、長いことPDOでfetchといえばFETCH_ASSOCと思ってたんですが、なんだよ、FETCH_CLASS超便利じゃん、と言うことに気付いたのでいくつか試行錯誤してみるなど。 まぁ便利さ言うならちゃんとO/Rマッパー使えこの野郎という話ですけど、設定が面倒なときもあってついあれなので…FETCH_CLASSとマジックメソッド使ってみたかった的なアレでひとつ。

続きを読む

未定義の特殊文字の実体参照が含まれるXMLファイルを無理矢理パースする

RSSを始めとするXMLで使用できるる特殊文字の実体参照は、以下の5つだけです。 (何の定義も与えられていない場合)

  • &lt; → <
  • &gt; → >
  • &amp; → &
  • &apos; → '
  • &quot; → "
これ以外の特殊文字の実体参照(例えば&times → &timesや、∞ → &infin;)が含まれている場合、パース時にパースエラーとなって読み込めないことがあります。ブラウザで表示しようとしてもそこで途切れてしまったり、返り値がfalseになったり(例えばSimpleXML)。動作としてはそれで正しいのですが、
  1. RSSを配信しているのが自分ではない
  2. 何らかの処理のために無理矢理読み込んでパースしたい
と言うときがあります。 本来であれば、パース処理の方に手を加えるべきなのでしょうが、面倒なので次のような過程を踏んでみました。

続きを読む

【メモ】さくらインターネットでSymfonyを使う

フレームワークを使わない管理から、俺俺フレームワークもどきに移行しかけていたのですが、そもそもフレームワークを設計する技量など無く便利な部分だけを抜き書きしただけ(autoload周りとか)だったので、これ以上カオスな状態にするのは止めようとフレームワーク導入を決定。導入するのは何にするかほんの少し考えたけど、CakePHPとZendFrameworkもよぎりましたが、CakePHPは複数プロジェクトを管理できないっぽかったし、ZendFrameworkは全然わかんないし、そもそもどれも解ってるとは言い難いので、仕事で使ってて少しはなじみがあるSymfonyを入れてみました(ただし、入れたのは1.4系。仕事で使ってるのは1.0系)。 インストールはここを参考にして、PEAR経由で。 さくらインターネットでsymfonyをインストール | ueblog

続きを読む

O/Rマッパーを覚えた

なんかもう、プログラムにさわり始めて何年よ、と思うと、毎度毎度「常識」にぶちあたるのが悲しいやら情けないやらなのだけど、それでも、「誰でも意志があれば学べて誰にでも公平に存在するのがプログラミング」とも感じるし、半ばやけくそ気味ではあるけれども、少し前向きには考えられる自分もいたりする。 やはり自分に足りないものは「流儀の習得」で、それはテストケースを殆ど書かない、テストプログラムも自己流のシステム化されてない作りなんてとこでまだ残ってて、きちんと学ぶべきだなぁと思いながら日々の業務に流されてるわけで、その辺ジレンマって言うかなんというか。少しは改善しつつあるのだけど。 以前書いたコードをいつか恥ずかしく思わなくなったりすることがあるのかしら?とか考えるのだけど、現在の無知ぶりからすると、例えそれがあったとしても遠い遠い未来なような気がするなぁ。コードや書籍を多く読んで身につけていくしかないね。(幸いコード読むのは楽しくて苦にならない) 情けなくはあるけど、常に余地があるのはちょっとだけ嬉しい。 それがプログラミングかも。なんつて。おこがましいけど。

続きを読む