【EC開発体験記-スケーラビリティ-】 信頼性とジレンマ

前記事で、トランザクション処理は厳密にしないといいながら、でも「これはこれで問題だ」と書いた。厳密にしないとエンバグになることは前述した通りだし、結果的にデータの信頼性が損なわれるので問題と書いた。しかし、あながちそうでもないらしい。ここによると、エラーデータについては無視すべきという、一見暴論のような考えが述べられている。エラー処理を厳密にするのはデータの信頼性確保と同義と考えるとトランザクション処理も同様に考えることができると思うので混同して説明する。（私の頭の中ではエラー処理とトランザクション処理を混同していいことになっている）
抜粋すると、

いかに注意深くエラー処理を設計したとしても，広大かつ多様なデータを扱ううちには，誰も考え得なかったような驚くべきデータに出くわすことがある。

それはそうだ。そして、

言わば「狂ったデータ」に対して逐一丁寧な対処を行っていくのは，果たして賢い方法であると言えるだろうか？ Pike らは， Sawzall が扱うような種類のデータに限って言えば，そのような「狂ったデータ」を無視してやるだけでシステムの安定性を確保することができると主張する。

これはデータの信頼性の考え方とは全く逆の発想のように思える。言い方をかえると、スケーラビリティを確保するには信頼性を犠牲にしてもしかたがないといったような乱暴な話に聞こえる。トランザクション処理にしても、下手したらパフォーマンスに大きく影響してしまうので、無ければそれに越したことはないが、それを犠牲にするなんて聞いたことがない。

ミッションクリティカルな基幹システムにおいては厳重にチェックされた矛盾のないトランザクションだけがデータベースに格納される。そうしないと様々な部分で弊害が出てシステムが動かなくなる。「狂ったデータ」はデータベースに存在してはならず、入り口のところで逐一丁寧な対処を行っていく必要がある。（基幹システムとは企業の中核を担うビジネスの基本部分をシステム化したものである。システムで処理できなくなると業務が止まるのでミッションクリティカルなシステムとも言われる。）

一方は入力を厳しくして正しいデータだけを管理する方法、他方は狂ったデータも管理するが無視する方法。要は、どうすればスケーラビリティのあるシステムを構築できるか。これがポイントになる。例えば、ミッションクリティカルなシステムであっても、数百件/日、多くて千件/日の受注件数しかなく、蓄積されるデータ量が数G未満であれば、メインフレームを使わなくても構築/運用できる。Java、Tomcatでもいいし、PHPやPerl、Rubyでも、MySQLと組み合わせればそこそこ動くシステムを作ることは可能である。そこそこ動くとは、トラブルがあっても運用でなんとかカバーできるという意味である。（そんなもの、ミッションクリティカルと呼べるか！というIBMの偉い方からツッコミが入りそうだが、クリティカルな業務をなんとか運用できるわけだからOKだ）しかし、千件を超える受注件数であったり、データ量が多かったりすると難易度は非常に高くなる。実際に運用を経験すると分かるが、システムの小さな不安定要素が運用に大きな負荷となって圧し掛かることになる。

ECの受注業務は、単純な定型業務と思われがちだがそんなことはない。バッチがコケたり、通信エラーが発生したり、毎日のように新しいトラブルが発生している。混乱の原因は大体は見当がつく。そう、「狂ったデータ」である。トラブルが発生したとしても、時間内に受注確定作業を完了させて取引先に送信しないと、お客様の希望日に商品が届かなくなってしまうので、逐一丁寧な対処を行い、臨機応変に対応しなければならない。これを解決できないと「狂ったデータ」が蓄積されて、翌日の業務にも支障が出る。さらには「解決数＜蓄積数」となった時点で、問題が発散してシステムはダウンする。最悪の場合はサイトクローズだ。安定して動いているように見えるシステムでも、マニュアルによる「待ったなし」の対応をどれだけ現場がやっているか、これが運用の実態なのだ。このように、なかなかシステムは安定しない。安定させるには地味な努力と時間が必要である。なので、否定の１６は確かに参考にすべきではない。

１６．入力は寛大に受け付け、出力は厳しくせよ（参考にすべきでないより）

ところが、「狂ったデータ」を無視せよという話は、Sawzall が扱うような種類のデータに限ってとはいうものの、システムの安定性を確保することができるという。
「狂ったデータ」を無視せよとは、入力を寛大に受け付けよという意味にもなる。これは限定的とはいえ、非常に興味のある話である。特に興味があるのは、Googleのクローン技術と言われるHadoopやhbaseだ。この記事も参考になる。

私がスケーラブルなシステムに興味があるのは今の実装技術に限界を感じているからだ。私が担当しているECシステムは作ってまだ半年しか経たないのに多量のデータが原因でパフォーマンス劣化を引き起こしているし、これから担当するシステムも同様な問題を抱えて困っている。なんとかならないものか。ムーアの法則がサチッてきて今後もハードウェアによる解決が望めない。そう考えると並列技術しかないが、googleを見るとそれを解決しているように思える。そこに、ミッションクリティカルなシステムをスケーラブルにするヒントがあるかもしれない。そういう意味で、Reflexが参照するデータソースはHadoopでキマリ。Reflex＋Hadoopにより、大規模なミッションクリティカルサービスを構築できる可能性が出てきたのは嬉しい限りだ。

よく考えてみれば、この分野はIBMの独壇場だった。大規模なミッションクリティカルシステムを構築できるのはIBMだけ、というのが殺し文句だったはず。いま、この分野で尖がったテクノロジーが見当たらないのは真に残念である。ぜひ今後もこの分野の第一人者であってほしいものだ。（MapReduceはGoogle論文にあるらしいけど、IBM論文ネタとしても最高だよなあ。・誰か書いてる人いるのかなあ）

まあ間違いなく言えるのは、トランザクション処理は厳密にしない、とか、「狂ったデータ」を無視せよとか、一昔前であれば稚拙といわれただろう、ということ。