バグの間抜けな倒しかた

プログラムを書いていると、間抜けなバグをいくらでも仕込むことができる。たとえば一文字だけのTypoだったり、ifの括弧のつけわすれであったり、エラー処理をひとつ忘れていたり、もしくはその言語特有の間抜けなバグというものもあるだろう。そういったバグは往々にしてコードレビューはテストを掻い潜ってしまう。製品や本番のコードに残ったままリリースされ、とてもヘンなデータが入ったり障害が起きたりしたときにだけ発露する。今回のはなしもそのエラー処理をひとつ忘れてリリースしてしまったことがきっかけではあるのだが、むしろバグの見つけ方が間抜けであったことをここに書いて今後の反省の材料としたい。

riak_cs#985 はそんなバグのひとつで、エラー処理をひとつ忘れて Riak CS のコネクションプールが漏れていたという話だ。再現条件としては、ユーザに関するAPI(一覧GETなど)を叩いたり、 Authorization ヘッダなしで存在しないバケットを GET すると、コネクションがプールからひとつ漏れていく。コネクションプールが枯れてしまうと全てのAPIリクエストが503だか何だかのエラーしか返らなくなってしまって、まあ要はサービスが落ちるわけだ。これの原因が分からなくて、2日ほどうんうんと唸っていた *1

僕が非常に間抜けな見つけかたをしたのは後者の再現条件だ。 Riak には /ping という簡単な動作確認用のAPIがある。これをGETでたたくと、 "OK" という2文字がBodyに入ったレスポンスが返ってくるので、RiakのプロセスがすくなくともHTTPのレベルで生きていることはわかる。同様に、 Riak CS には /riak-cs/ping というAPIがあって、これを叩くと生きているかどうかがわかる。 #985 が問題になっているときに焦ってしまって、思いつく限りのAPIを適当に叩きまくっていたのだけど、そのなかに /ping というAPIがあると仕様を間違って理解していて、その実装は riak_cs_wm_ping.erlだと思っていた。これがコネクションを使っているし、あまりテストもないし、これが怪しいんじゃないかと疑っていた。これだと認証ヘッダがつかないので、ふつうのAPIアクセスとは違った挙動になる…ことを期待していたわけではなく、八方塞がって s3curl ではなく curl を使って叩いていた。ほんとうは /riak-cs/* のAPIも認証ヘッダが必要なのだけど、頭が混乱していたわけだ。
それで、

$ curl http://localhost:8080/ping

というコマンドを叩くとコネクションが漏れることを発見した。これがきっかけで問題箇所を特定できた(特定したのは僕ではない)のだけど、これは riak_cs_wm_ping.erl のコードを使っていなくて、 riak_cs_wm_objects.erl という全く別のAPIを叩いていたのである。どれくらい的外れかというと、この手の死活監視ならふつうは200が返ってくるのが相場だが、ステータスコードは404が返ってきてそういうXMLが表示されるくらい的外れだ。そして404が返っていても、リークを見つけて興奮していたのでそれにしばらく気付かなかったくらいボケていた。
ぼくの仮説の設定は全くの検討外れで、今回は運良くたまたま原因となるところにリーチできたわけだ。

ぼくはわりと性急な性格なので、勤務時間中は給料をもらっていると考えると効率を上げるために焦る傾向があるようで、デスクトップは片付けないし、かなりの数のメールをタイトルだけ読んでArchiveする。同様にドキュメントやコードを読むときは要点だけを知りたいので、細かい所はわりと飛ばしてよむ癖がある。それが今回は幸いしたわけだが、お前は本当にそれでよかったのかと問いたい。

じゃあバグの体系的な倒しかた、とかバグを仕込みにくい開発やプログラミング言語とは、という話になるのだけど、再発予防とか水平展開とか一般論に陥りがちで難しい。まあ QuickCheck でテストを書けという話ではある。

*1:まあ2日で見つかるんだからいいじゃないかという気もする

Riak 2.0がリリースされていた

9月に入ってから、Riak 2.0がリリースされた。昨年の今頃から動き始めて、1年かけてようやっとリリースにこぎつけた。あちこちで繰り返されているが、ここでも新しい機能をちょっとずつ試していきたいと思う。マーケティング的には華々しく4つくらいの新機能が宣伝されているが、ここでは地味でマニアックなことから。とりあえず思いつくものをここから。

  • Erlang/OTPをR16に更新(ようやく)
  • Cuttlefish: 設定フォーマットの簡単化
  • Bucket Types: Bucket名前空間の追加
  • Strong Consistency: レプリケーションの強い整合性
  • Riak Search 2.0: Solrを組み込んだ高機能な分散インデックス
  • Security: 認証認可と通信路の暗号化
  • Java Client 2.0: 進化したJavaクライアントとか、ほかにもいろいろ

進化とか書いてしまってカッコイイな。と思ったら、hiroeさんがQiitaに注意点をまとめていたのでとりあえずそのリンクを貼ってお茶を濁しておこう。

日本でも新機能をバンバン使っていろいろやろうとしているのでなんか追加の記事を書くかもしれない。

システム系論文輪読会で話してきた #pfisystemreading

先週の金曜日に、PFIで開催されたシステム系論文輪読会で話してきた。いい加減に積んであるものが多すぎて、こういった機会に便乗して自分を追い込まないと何もできないからである。


第2回 システム系論文輪読会 - connpass

僕が読んで解説したのは Peter Bailis et al., "Coordination-Avoiding Database Systems" VLDB 2015, to appear である。この論文がどれだけすごいものであるかという話についてはぼくのレジュメを参照いただくとして…この論文は神林さんに教えてもらったのだけど、VLDBやBailisのグループは要チェックだということを再確認した。この論文、なかに分散システムの証明が書いてあったりするのだけど、21回も続いている分散合意本読書会で鍛えた証明の読解力で割とスラスラとノリを理解できたので感動した。というわけで合意本を読めば…

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

といいたいところであるが、この本は一人で読み進めることは素人には不可能なのでなかなかキビシイ。ちなみに、わりとついてきた地力を使えば、CAP定理の証明 [1] くらいであれば、サクサクと読めるようになったりはする。

話を戻すと、この論文の内容はともかくとして、この論文がどうすごいのかを書いておこう、と思ったけど上のGistにだいたい書いてあった。クラウドとか分散KVSとか言ってるひとたち、この論文読まないとだめだよ。あとサーベイとしても非常によくできていて(各方面の歴史たちが共著者になっているので、歴史的に漏れがほとんどない)、参考文献リストの長さに顔が青くなること必至である。

まあ、流れでいうと、NoSQL的にトランザクションとかACIDとかレプリケーションをそこそこで割り切って作ったデータベースのよいところと、RDBMSとか2PCとかデータの整合性をキッチリキッチリやってきた流れがここで融合しているのがすごいのである。市場にも「トランザクションできるNoSQLだぜー」とか高速なRDBMSだぜーみたいな話は死ぬほどあるのだけど、どれもこれまでのデータベースの研究と製品の歴史を無視したマーケティングなので無視したらよい。製品にして使ったところでどこかでハマるのが原理的にわかっているので(ハマらないことが証明された設計になっているのであれば、それは論文にして出した方がマーケティングとしても効果が高い)。MongoDBやMySQLのようなタイプのレプリケーションをやっていると、ネットワーク分断、耐障害性、スケーラビリティのどこかで問題が出てくるし、CassandraやRiakのような設計でレプリケーションをやっているとスケーラビリティや耐障害性が十分であっても、整合性に限界があったりアプリケーション的なユースケースが限られたりする。

これはひとつのパラダイムでいろいろなデータベースの問題を解いて全てのユースケースをカバーできないということの証左であるわけだが、このCoordination Avoidingなデータベースでは、ひとつのデータベースで、ユースケース毎に理論的な限界をギリギリまで詰められることを証明した。具体的には、整合性を保ちつつスケーラビリティや分断耐性を追うためのユースケース分析をして、それをうまく使い分ける提案をしたわけだ。I-Confluenceの概念とその証明でだんだんテンションは上がって、TPC-Cのアクセスパターン分析でこの論文は最高に盛り上がる。

しかし原理の解説やTPC-Cの分析と実験は非常に興味深いのだけど、実装や設計の話がほとんどなくて、これじゃあちょっと再現とか実装してテストしてみるというわけにはいかなそうなのが難点である。きっとベンチャーを立ち上げるのだろう。

個人的には、この論文の実装が世にでるか出ないかのタイミングで「ひとつの用途にひとつのデータストア」の時代が終わるのではないかと予想している。今でも、AWSに入ってる各種データストアや、Orchestrate.ioなどが登場しており、データベースを個別にデプロイして使い分けるのではなく、複数のユースケースをなるべくシンプルなサービスにまとめて使い分けるという形が主流になっていくのではないか。手前味噌であるが、Riak も2.0のリリースでその第一歩を踏み出している

  • [1] Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.

退路を断つ

ベルセルクのドルドレイ攻略戦で、鷹の団が川を背にして陣をとるシーンがある。グリフィスはそこで「後ろは川だ!退路はない!ここで踏ん張って勝つぞ」といった趣旨の発言で味方に発破をかけて大軍に勝つというシーンがある。人間が自分で何かを達成したいときも、似たような考え方をしてモチベーションを整えていく方法がある。大学受験に失敗して浪人をするとき、就職活動がうまくいかなくて留年するとき、卒業のための最後の2単位をとろうとするとき、などなど。一旦これで成功体験を得てしまうと、次の挑戦でも同様に自分を追い込んでからが勝負になりがちだが、良い子はマネをしてはいけない。

ベルセルク (7) (Jets comics (542))

ベルセルク (7) (Jets comics (542))

いくつか理由がある。

グリフィスは勝つ見込みがあって勝負をかけた

何を言ってるか分からないと思うが、ドルドレイ攻略戦ではグリフィスは寡軍を更に分割して、別働隊を出している。鷹の団の本隊が押され気味になったときに要塞内の守兵を戦功を餌に誘き出して、守りがほとんどいないドルドレイ要塞は別働隊が簡単に占拠してしまったのだ。また、中世の戦闘では大将の強さが軍隊の強さを決める側面があるが、敵の大将のボスコーン将軍をガッツが倒してしまうのである。漫画の主人公が負けるわけはないのだから、グリフィスはそこも計算していたことだろう。漫画のキャラクターが漫画の外の事情を考慮することは一般にご都合主義と呼ばれるが、ベルセルクという漫画はグリフィスをそういう物理的制約の外側にいる神秘的なキャラクターとして漫画内で上手く描いている。そうやってお膳立てを全部整えた上で「退路はない」と煽るのである。つまり計算づくなわけだ。

ちなみにこの退路を断つ戦略は、私が知る限り「項羽と劉邦」で韓信が中盤で用いている(確か楚との一連の戦いの中で)。おそらくはどこかの古典に載っている戦術だと思われる。どうしてこれが成功するのかという戦史上の分析はリデル・ハートの「戦略論」にタップリと書かれているのでお楽しみ頂きたい。

翻って、自分がそういったことを考えるときに勝つ見込みは十分にあるだろうか?火事場の馬鹿力という言葉を信じすぎていないだろうか?自分が普段できないこと、していないことを計算や予測に入れてはいけない。もし入れるなら、火事場になって突然腰が抜けて動けなくなるリスクも計算に入れなければならない。

そんなことを考えた時点で本人は十分に真剣だ

鷹の団の士気が低かったとはいわないが、この方法はあくまで「大将が兵士たちのモチベーションを高めるため」に用意した状況である。自分が自分のモチベーションを高める、という風に自分を客体的に扱ってコントロールすることに使えるかもしれない。しかし、私の理解だとそれは必要以上にモチベーションを高めてしまい、思考を停止させる。そのような方法は持続的ではないし、人間はそんなに強くない。

他にも敵を誘き出すすためという目的もあったが、個人での内面のメンタル維持であれば、その状況を外から観測することはできないので敵はおびき出されないし、外部の状況が何か変化することはないから、好転することもない。

リラックスした方がパワーは出る

常に退路を用意しておく方がリラックスできる。「逃げちゃダメだ」みたいな有名シーンもあるが、それは本当に退路がどこにもない場合だ。大抵の人生では、退路や他の選択肢は本人が思っている以上に多く用意されている。ダメそうだったら早めに諦めてまた仕切りなおせばいいじゃない。ぼくは高校3年の冬に「えー、キミたちは大学受験まであと13ヶ月ありますが」とかセンター試験の一週間前に「ほんまに大丈夫なん?今年は諦めてまた来年頑張ってもええねんで」とか言われたことがある。冗談めかして言われたわけではなく真剣にだ。それはどうかと思う、というか、それを真に受けつつ真に受けないくらいの余裕をちゃんと用意しておこう。

たまにはスピリチュアルなことを書いてみた。

在宅勤務環境を整備した

2年前に一念発起して組んだマシンがあって、Core i7と32GBものRAMを節操無く積んでいたもののファンの音が気になるとか子供が邪魔をするとか、ディスプレイが小さいとか理由であまり使っていなかった。引越を機会に自分の仕事場がつくれそうなので、これを機会にデスクトップ環境をもう一度整備した。

ディスプレイ

やはりこれが一番大切だろう。必須条件は解像度がいわゆる4Kあること。MacBook Proを使ってRetinaの美しさに慣れてしまった今、これまでの普通の液晶モニタでは何インチあっても意味がない。もともと液晶のサイズそのものではなく、解像度に興味があったので必然だ。本当は海のむこうだと$500とかそういうレベルで変えるらしいのだが、日本に住んでいるのでなんか出てるかなーと思ったらASUSからPB287QIODATAからM4K281XBがそれぞれ出ていた。ぼくは海よりも深い理由からASUSを選んだ。

と、それだけではいけない。なぜならこのディスプレイ、DisplayPort経由じゃないとフル解像度じゃないと表示できないのだそうだ。HDMI規格が悪いのかディスプレイが悪いのかはわからないが、とにかくグラフィックボードも買うことにした。

ビデオカード

@moriyoshit とかいう人によると、LinuxのドライバはGeForceの方がそれなりに動くそうなので、AMD党としては残念だがGTX750あたりを目指して探してみることにする。MacBook Proの最上位モデルはこのボードが入っているそうだからというだけの理由である。もともとゲームはやらないので、そんなに強力な3D性能が必要になるわけでもない。と思っていろいろ探していたが、DisplayPortを持っているボードはELSAだとGTX760からのものしかないらしい。というわけでこれにした。

ELSAにしたのは積極的な理由はないのだが。。。本当はマザーボードと同じメーカーにしたかったのだが、ASRockのZ77 Extreme4という、グラフィックボードを出していないメーカーのマザーボードを使っていたので、逆に、GIGABYTEなどのマザーボードも作っているところはあえて避けてみた。非常に消極的で根拠のないことなのだが。

そういうわけで4Kになった。すばらしい

ちなみに、ドスパラでは、間違った機種をWeb経由で注文しても他社のようにキャンセルはできないので注意。キャンセルの代わりに返品か、同額以上のものに追加で支払って交換してもらおう。

キーボード

人間の両手は、ふつうのキーボードを叩くと両手首が極端に曲がってしまう構造になっている。ふつうのキーボードではもう手首が痛いのでKinesisのエルゴノミクスキーボードを買うことにした。日本だと代理店のエジクン総研から買うのが一番安かった。配達も早かったのでオススメ。この画像のときはまだ全部環境揃ってなかったからMBPで最初に試してたのかな。今はふつうに4Kのディスプレイの前で使っている。

ちなみにこのキーボード、いちおうUS配列を謳ってはいるが、通常のUS配列とは全くの別物で慣れるまでに1週間以上かかると覚悟したほうがよい。仕事で使う場合は、少なくとも3日ほどは練習期間に充てた方がよいだろう。いきなり仕事で使おうとすると、Typoばかりで(自分が)使い物にならないので注意が必要だ。しかし10年以上も使い慣れたものとは全く異なる配列に挑戦するのは、脳の普段使ってない神経をこじ開けていくような気分がしてとても新鮮だった。人間慣れすぎてしまうのもよくない。

マウス

G700sってかいてある。まあこれはあまり使わないので別に何でもよい。スワイプとかXfceにねーし。

椅子

まだ買ってないが、なんかいいやーつがほしい。

まとめ

ちなみに電話会議とかパワポやるときはふつうにMBP使うよ。さて、これでバリバリとErlangを書く!はず…

Riak CS 1.5 がリリースされました

Riak CS 1.5.0 が米国時間で昨日、リリースされたOSSになってから1年余りになる。このリリースは、1.4系に残っていた多くのバグをなおしつつ、いくつかのAPI追加を行ったものだ。相変わらず運用まわりの地味な機能追加が多い。また、コレは Riak 1.4系の上で動作する最後のRiak CSになるだろう。1系の集大成だと個人的には思う。思えば一年半、遠くにきたもんだ。いろいろ怒られたり、ちょっとだけ売れたり、ちょっと前には Riak CS上で今をときめくトレジャーデータのシステムが動き始めたりと…

なんでこんなことを書いているかというと、このリリースのために割といろいろ頑張ったからですね。こういう風にあちこちで使われている製品のソースコードに、技術的な難しさはほとんどないとはいえかなりの量をコミットしたのは私の人生では初めてのことなので、これはまたちょっと感慨深いのであった。1.3のときにつくった Bucket Policy もそれなりに使われているみたいなのだけど、あれは新機能の追加がほとんどなので、既存の部分をそこまで理解しなくても作れたのでよかった。それに、後に同僚いわく「あんな短いコードでどうして動くのかサッパリわからん」といわしめたゴルフ力もあって、ちょっと一人よがりなところはあったかなーと思う(今もあるけど)。

1.5.0 のみどころその1: Hadoop MapReduceがちゃんと動くようになった

むかし、Riak CSをHiveのデータソースにするという記事を書いたのだけども、いまいち歯切れの悪い記事であった。それは、PUT Copyが実装されていないせいで、Reduce完了後のファイルの移動に必ず失敗していたのだった。MixiではHadoopの方にパッチを当てて使っていたそうだが、さすがに世界中でそうしてくれというわけにもいかず、Javaを書けないのでHadoopにパッチをコントリビュートする力もなかった。で、今回そのPUT Copyを実装したのでHadoopが普通に動くようになったという話でした。


1.5.0 のみどころその2: 削除が速くなった

それまでのRiak CSでも、削除そのものは速いけれども、論理削除はバックグラウンドで動作するGCを待たないといけなかった。このGCが遅くて、シングルスレッドで動いていたり、Riakの新しい効率的なAPIを使っていなかったりでとても遅くて、ファイルの作成と削除があまり多いとディスク使用量が平衡できずに膨らんでいくという問題があったのだけど、とりあえずこのGCを並列動作できるようにして、Riakの新しいAPIを使うように修正していった。だいぶ速くなって、今度はディスクがボトルネックになるようになったのだけど、Riakの削除がこれまた曲者で…ネットワーク分断に耐えるように作るから仕方がないんだけどね。

1.5.0 のみどころその3: 今話題のSparkが普通に動く

http://qiita.com/kuenishi/items/71b3cda9bbd1a0bc4f9e

jets3tを使っているから当たり前なんだけども。

1.5.0 のみどころその4: バグが沢山なおっている(ぇっ

 
お後がよろしいようで。えっ。
 

それではみなさん、バグの報告やPull Requestをお待ちしています。

遅ればせながら「「特許庁業務・システム最適化計画」の改定について」について

Slashdotでみた56億円返還の件で興味が湧いて調べていたら、 「特許庁業務・システム最適化計画」の改定についてというやつを見つけたので目を通してみた。一度失敗したプロジェクトをどう再出発させるのかということと、実社会に直接影響を与えるこのシステムがどういう風になっていくかに興味があるからだ。

28枚という短い文書だが、短いだけに情報が凝縮されていてとても面白い。リンクされているPDFの文書は、平成25年3月という、一作年度末に書かれたものであることがわかる。この文書は、改定前の失敗とかそういったことには一切触れない。おそらく改定前のものと比べながら読んだら非常に味わい深いものになること請け合いであるが、ここではとりあえず措くこととする。

まず、特許庁の業務は大きく分けて、受付発送、方式審査、実体審査、登録、公報発行、審判の6種類があること、そのために平成2年に世界で初めて電子化されたシステムがあることが語られる。それは電子出願、事務(包袋事務処理システムと審査周辺システム)、検索システムに分けられるという。

で、オフコン2台を含むシステムが、とりあえずのペーパーレス化を実現したものの、個別システムの複雑化が起きていて、相互依存、手続きの遅延、データの重複が特に問題だと。で、それらを改善するためにシステムを10カ年計画で段階的刷新するといっている。

他に興味がわいた点としては、

  • オフコンのオープン化(久しぶりに聞いたわ
  • 多言語翻訳機能などグローバル化、ちゃんとした検索の提供
  • 「音や色といった新たな権利客体を取り扱うことになる」
  • 審査官が照会するDBとユーザーが照会するDBを一元化する、とかいてある
  • 第二期に「ユーザーへの情報提供の迅速化やAPI(Application Programming Interface)の提供の検討を進める。」
  • 「「クレジットカード決済」を利用した料金納付を可能とするシステムを整備する。」
  • 「データセンタ・クラウドの活用」

個人的に最も興味深かった点はP15だ(以下、引用):

  • 業務AP同士の通信を排除し、業務APを疎の関係とすることにより、システム全体の複雑性を低減させ、システム改修時のコスト低減を図る。
  • 個別システムにおいて基盤機能とデータベースを分離した後、個別システム間で共通的な基盤機能を集約化することにより、制度改正・運用変更時の影響箇所数を削減し、システム改修時のコスト低減を図る。
  • 個別システム間でデータベースを論理的に集約化することにより、システム全体として保持する情報量を低減させることで、システム全体のダウンサイジングを実施し、経常経費の削減を図る。

ぼくには、データベースの集約と個別サービスの粗結合化を進めると書いているように読めるのだが、それは不可能なのでシステムの完成図がちょっとイメージできない。P20には「特実出願系共有DB」なる言葉が登場しているので、それのことかもしれない。ときおり登場する「XML」という言葉がさらに不安を助長する。

クライマックスはP22の工程表だ。今日は2014年度だから、特実出願系DBの開発はテスト工程が4ヶ月目に入っていなければならない。果たしてどのようなDBがまさに今テストされているのだろうか。。。

さて、私の個人の感想を書いておきたい。ひとつは、変化に強いシステムを作る思想に欠けているようにみえるところが心配だ。それは政権が朝令暮改になっているから対応するという意味ではなく、これから技術をとりまく時間の流れは速くなっていく一方なのだから、必要に応じてシステムを迅速に変更できるようになっていてほしい。
もうひとつは、P23の経常経費の試算図が最高にいけてないところだ。要は「少しずつコストを圧縮していきます」と書いている。わたしはコスト構造を時代の流れに合わせて変えてほしいと思っていて、もっというと情報システムに払う金はコストではなくて投資になっていくべきだと思っている。つまり、ハードやネットワークのコストは当然下がっていくが、ソフトウェアや運用にかかる金額はもっと上がっていくということだ。一度に全部つくり直そうとして失敗したことに懲りて、「今度はちゃんとやるぞ」という意志を確かに感じるのだが、失った年月は戻らないしコンピュータ技術はその間に大きく進化してしまった。

さて、このシステムは10年かけて更改してしまったらそれでオシマイだろうか?特許のシステムは100年維持されるものにしなければならない。一度作ったら終わりといってたら未来永劫にわたって完成なぞしないのであって、システムの改善を内包するように設計した方がよいのではと…しかしソフトウェア保守費に15億円ってことは保守だけで150人も維持するのかと思うと、保守だけで終わるのかなぁと本当にドキドキする。