【バグ編】Divide by Zero(ゼロ除算)とは、見つかると周囲の視線が痛くなるエラーである|#エンジニアあるある システム開発現場・実録IT用語辞典

【バグ編】Divide by Zero(ゼロ除算)とは、見つかると周囲の視線が痛くなるエラーである

お疲れさまです。先週まで、朝から晩まで、試験とか、検証とかいう言葉に該当する作業を延々と行っていたMWです。試験を開始したばかりの初期のころは、すぐにバグが見つかるので張り合いもありますが、終盤になってくるとそう簡単にはバグが見つからず、さりとてバグがゼロになったとも思えず、テスト仕様書にないさまざまなシチュエーションを考えては空振りを繰り返すので、心が萎えがちになります。

システムはバグがゼロになるまでテストをするというのが理想です。もちろん、ある程度の規模があるシステムを100%完璧な状態にするのは到底不可能ですが、限られた時間の中でできる限りゼロに近づけようという努力は、毎回気が滅入るくらいに行うようにしています。そこをサボると、リリース後に自分が痛い目を見ることになるので……。

#エンジニアあるある 実録IT用語辞典【バグ編】INDEX

「Divide by Zero(ゼロ除算)」とは

プログラムを利用して数値を0で割ろうとすると発生することがあるエラー。エラーにならずに、NaN(Not a Number)を返す言語もある。

割り算を行う箇所では0除算は必ず考慮しておくのが常識とされているので、システム障害が発生してエラーの原因を探りこれが見つかったりすると、周囲の視線が痛いことになったりするので、ちゃんと制御を入れておくことがオススメされるもの。

「考慮に値しない確率」とは

10の何十乗とか百乗分の1のような、限りなくゼロに近い確率のこと。

どの程度の確率まで考慮する必要があるかは、それが発生した際に起こる被害の大きさと、それに対応するためにかかるコストと、その設計を行う際のエンジニアの気分によって決められる。

以前見かけた例として、ユーザがログインする際に前回ログイン日時が、ちょうど1年前の同じ時間、同じ分、同じ秒だった場合に正常にログインできないという事象(どう見てもバグ)がある。ただ、発生する確率が極めて低いうえ、1秒でもズレた時間に再度ログインすればちゃんと処理されるので、気にしなくていいかという結論に至った。

ハードウエアのトラブルなどでは、例えばHDDが1本飛んだだけでシステムが全停止になったり、RAIDを組んでおいたHDDが2つとも同時にお亡くなりになったりする場合についてまで考慮すべきかは、そのシステムが止まった時に発生するダメージなどによって変わると思われる。

人命にかかわる医療関係の機器や、証券やFXのような巨額のマネーが飛び交うようなサイト、数十万人に影響が出る交通機関のシステムなどは、どこまでも不慮の事象が発生する可能性を消していかなければならないので、設計していて頭が痛くなりそうな気もする。

「試験」とは

開発現場で試験という言葉を使用すると、情報処理技術者試験等の資格試験を連想される場合もあるが、大抵は単体試験や結合試験といった、ソフトウエアの試験を指すもの。

試験はシステムに存在するバグを洗い出し、精度を上げることを目的に行われる。これをちゃんと行わずに、微妙なバグを内包した状態でリリースしてしまうと、後で痛い目に遭うことがあるもの。

特にユーザの入力によって簡単に発生したり、閾値チェックを一回りすれば見つかったりする、「そのバグは試験で見つけられないとおかしい」系のバグを残しておくと、会議室に呼び出されて偉い人から小一時間ほど説教されるとか、世間さまから指を指されて笑われる等の、激しく心が萎える事態に陥ることがあるので、危険である。

昔はちゃんとした試験を通過したシステムであればバグはないはずとかいう、プログラマの常識から若干外れた認識でシステムが取り扱われていたが、最近は開発者以外の間にもバグのないシステムは存在しないという認識が広まりつつあるお陰で、バグ数とテスト工数のトレードオフを考慮して、ある程度のバグが残るのは仕方ないという認識の下で行う試験も存在する。例えば個人情報や決済等が絡まない、GoogleのようなWEBサービスでは、その傾向が強く見られる。

そのため、通常の試験では発見するのが難しいバグ、例えばサーバがダウンして待機系に処理が移る瞬間だけ異常な動作が起こるとか、通常に運用していれば問題ないが連続497日稼動させると不具合が生じるといった内容の場合は、「仕方ないよね」と言ってくれる優しい現場もこの世には存在するようだ。

「DIFF」とは

差分という意味で使われることが多い。

Linuxを使用していると、「diff ファイル名1 ファイル名2」と書くだけで、2つのファイルの間で差分がある箇所を確認することができる。手作業で何かを直したあと、このDIFFを見ると、自分が触った行だけが確認できるので、作業漏れやミスがないかチェックする用途で使用できる。

筆者のようなミスの多いエンジニアは、作業後にDIFFを見ておかないと恐ろしいほど高確率でミスを発生させてしまったりする。 

「スペルチェック」とは

WordやExcelなどのオフィスソフトや一部のIDEに搭載されている、誤字を検出してくれる機能。

Officeや辞書ソフト等のチェック機能は、残念なことに一般的な言葉に対してだけ正しく機能する場合が多い。そのため、ライブラリの名前とか最近新しく生まれた用語などが大量に盛り込まれた文書を扱っていると、正しい言葉を使っているのに大量にチェックを付けられることがあるもの。

特に、ソースを本文に貼り付けたメールをOutlookで送信したりすると、ほとんどの記述が片っ端から誤字扱いされるという悲しい現象に出合ったりする。

あまりにチェックされる項目が多過ぎて、本当の誤字を見過ごしてしまうことも多い、エンジニア的には扱い方が難しいもの。

【コラム】遅延しやすい My○QLもどうかと思ったが、私のほうが悪かった

随分と昔のことになりますが、レプリケーション遅延発生時に登録ボタンを連打されるとデータがダブってINSERTされる、というバグを出してしまったがために、しばらくの間、重複データを手動で監視・削除するという悲しい作業に従事するハメに陥ったことがあります。

遅延しやすい My○QLもどうかと思いましたが、INSERTした次の画面でスレーブに確認に行くような作りにした私のほうがもっと悪いので、何も言えませんでした。

1つのサービスを複数台のサーバで運営するのが当たり前になってきて、DBもセッションもレプリケーションしてるとか、それを10台以上のサーバで実現するといった構成が、それほど珍しくない世の中になってきました。そういったシステムの上できちんと動くロジックを考えるのは、単純な一台のサーバで動くシステムよりも、少しだけ面倒です。

「レプリケーション」とは

複数のハードウエア間で同じ情報を整合性を持ちつつ取り扱うこと。

レプリケーションを使用すると、複数台のDBサーバをアプリケーション側ではそれほど意識することなく(少しは意識しないと筆者のような状況に陥るので注意)取り扱うことができる。

複数のDBサーバを使うと、台数の分だけ負荷を分散することができたり、もし一台で運営しているDBサーバがお亡くなりになったりしたら、管理者の胃に穴が空くような復旧作業が発生すること請け合いなのに対して、複数台でデータを共有していれば、もう一台のほうにある程度完全なデータが入っているから、新規にDBサーバを立て直すだけでいけるかもといった余裕を持った気持ちで障害対応に当たることができるかもしれない(INSERTされてから情報がほかのサーバに伝播する前に壊れたら、さすがにその分のデータは戻らないが)といったメリットがある。

ただし、各DB間で整合性を取るということは、INSERTやUPDATEが発生したら、必ずその情報をレプリケーションしているすべてのサーバに伝えなければならないということになる。その場合、もし複数のDBで同時にINSERTが発生したらどうしようとか、1つのサーバにデータがINSERTされた直後に、別のDBサーバにその情報の問い合わせが来たらどうしようとか、考えていると頭が痛くなるようなことを解決しなければならない。

また、データの追加・改変が行われてから、その情報がほかのサーバに伝播するまでには多少のタイムラグが発生する。DBMSの作りによっては大量の処理要求が発生すると、INSERTの情報を全体に伝播するのに1分以上かかっちゃいましたというような、いろんな問題を併発させそうな現象を起こしてくれることもあるので、注意が必要なもの。

「遅延」とは

1つの処理が完了するよりも速いペースで新しい要求が発生し続けることで、キューに処理がたまり、命令してから処理が完了するまでに、普段とは比べ物にならないくらい長く時間がかかってしまうような現象。主に高負荷やネットワークの帯域不足などによって発生する。

某・腹話術師さんの芸で、「システムが、遅れて、動いているよ」と言ってもらった感じと言えば分かりやすいだろうか(きっと分かりづらいだろう)。

一部のエンジニアは、遅延が発生している際に当該アプリケーションの状況を調べると、「わーい、プロセスが500個も立ち上がってる」とか「凄い。ロードが100まで行ってる。3桁とか久々に見た」といった言葉をなぜか非常に高いテンションで、かつちょっとうれしそうな声で口にしたりすることがある。こういったトラブル発生時に、どうしてテンションが高まるのかは不明である。

遭遇する代表的な遅延の例として、メール遅延がある。スパム業者の人々が頑張り過ぎて、サーバが取り扱える以上のペースでメールをバラまいたりすると発生する。メールのユーザから見てもスパムは厄介なものだが、メールサーバの管理者はもっと厄介だと思っているかもしれない。

#エンジニアあるある 実録IT用語辞典 【注目のキーワード】

あわせて読みたい

注意!!

この連載記事には必ずしも正しいとは限らない内容が含まれています。この記事を信じたことによって発生した障害に対して、筆者及び株式会社マイナビは一切の責任を負いません。ご容赦ください。

※この記事は2007/11/23〜2009/08/28に連載された内容を再構成しています

著者プロフィール:MW(えむだぶりゅー)

Java、PHP、C、C++、Perl、Python、Ruby、Oracle、MySQL、PostgreSQL関連の業務経験がある、典型的な広く浅い役に立たない系のウェブ(時々クライアント)アプリのエンジニア。 週に1日休みがあれば、ほか6日間は終電帰りでも全然へーきな体力と、バグが出ても笑って誤魔化す責任感の無さを武器に、今日も修羅場った開発現場の風景を横目で見ながら、適当に仕事をこなす日々を送る。
著書「それほど間違ってないプログラマ用語辞典」(発行:毎日コミュニケーションズ)

併せて読みたい記事
賛成! あたらしい生き方。マイナビ転職

豊富な転職・求人情報と転職ノウハウであなたの転職活動を支援する【マイナビ転職】。マイナビ転職は正社員の求人を中心に“日本最大級”常時 約8,000件以上の全国各地の豊富な求人情報をご紹介する転職・求人サイトです。毎週火・金更新であなたの希望の職種や勤務地、業種などの条件から検索することができます。職務経歴書や転職希望条件を匿名で登録するとあなたに興味を持った企業からスカウトされるサービスや、転職活動に役立つ職務経歴書サンプルや転職Q&A、会員登録をすると専門アドバイザーによる履歴書の添削、面接攻略など充実した転職支援サービスを利用できる転職サイトです。

「知っトク」メール

基本のノウハウだけでなく、市場動向も踏まえた「今、知っておきたい」転職情報を読めるメールマガジンです。毎週月曜日配信です。

新着求人メール

新着求人の中から、あなたの希望条件に合った求人やお勧め情報をお届けします。
毎週2回、更新日(火曜日・金曜日)に配信です。

キーワードから記事を探す

検索フォーム

人気コンテンツランキング
転職成功ガイド