パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

マイナンバーカード管理システム障害の原因が判明」記事へのコメント

  • by Anonymous Coward on 2016年05月03日 8時01分 (#3006918)

    ずいぶんと複雑なシステムなんですね。

    • by Anonymous Coward on 2016年05月03日 8時40分 (#3006932)

      複雑というよりは、「今どきのOSや開発環境では考えられない」問題のような。

      前者は「デッドロック」に類されるトラブルでしょうが、お互いに同じ資源を奪い合っているのであればともかく、外部デバイスとのインターフェイス処理と内部的な処理でそれが発生するとは考えにくいですし、もしそうであるとしたら、「お前らテストしてないだろ」って言われても仕方のないくらい、根本部分のバグのような気がします。よく言われる「枯れていない」(=十分にフィールドテストされていない)環境で発生するトラブルと思われます。

      後者は「不正ポインタ参照」に類されるトラブルと思われますが、こちらも十分にテストされた高水準言語を使用していれば、最初から避けられたトラブルのような気がします。

      親コメント
      • by Anonymous Coward on 2016年05月03日 11時06分 (#3006989)

        日経BPの絵をちょっと見たけど、確かにあまり普通のWebエンジニアにはお目にかからないものかも

        中継サーバのレイヤー構成の中に耐タンパ層ってのがある。で、その中にドライバーという箱の絵もある。
        つまり、暗号化・複合化処理っていうのはICカードの耐タンパ処理の(理論処理の)ことらしい。
        なんでこれがデバイスドライバーなのかというと、それはつまりICカードメーカがソフトウェアライブラリは(リバースエンジニアリングされるから)出してくれないからだろう。
        自分はIAサーバの物理ハードのデバイスドライバは書いたことないのでどれくらいの難易度なのかわからんが、すくなくともコピペすれば出来上がるものではなさそうだ。
        ま、実際やれば色々苦労はあるんじゃないか。

        この辺からどんどん想像になっていくけど、
        そのデバイスドライバの割り込み処理が変で、割り込み入るとうまく動かないらしいね。
        じゃぁ、CPU監視の割り込みを止めりゃいいんじゃないのか?毎日使えないよりましだろ?とは思うが。

        なにより問題なのは時間がかかってることだよなぁ。そしてその原因が問題解決以外のところに時間使ったのが原因じゃねえのかよ?
        ってところがなぁ。日本の技術力は落ちたなぁ。

        親コメント
        • by Anonymous Coward on 2016年05月03日 15時43分 (#3007064)

          日本の技術力は落ちたなぁ。

          ネットワークサービス、特に公的機関の提供物に関しては元々高い技術力のイメージはないなあ。
          洗練されたものを一発で作るよりも、泥臭く工数を掛けて実用に耐えうるように作っていく感じ。

          親コメント
        • by Anonymous Coward

          レイヤーの図は何かおかしいし、CPU監視は、ただのウォッチドッグタイマーじゃないかなぁ?
          Windows Serverのwatchdogの挙動は良く知りませんが、メモリディスクの退避などのためにカーネルパニックしない設定もできるはず。

          でも、ウォッチドッグタイマーとなると、因果関係が逆になるので、CPUを弄っても意味無いはず…。

        • by Anonymous Coward

          皮肉で書いているんだと思う

        • by Anonymous Coward

          日本の技術力は落ちたなぁ。

          そりゃ、これだけ社会全体で冷遇してきたんだから、優秀な人が来ないし。

      • by Anonymous Coward

        後者はマルチスレッド間のリソース共有という、超基本ができてなかったという問題に見える。
        高水準言語でもロック機構使わずに回避は無理。
        前者はわからないな。encrypt/decrypt deviceがDisable Interruptかけずに割り込まれて固まったようにも聞こえるけど、やっぱ記事からだけじゃわからん。

        • by Anonymous Coward on 2016年05月03日 9時25分 (#3006945)

          報道資料「カード管理システムの中継サーバに生じた障害原因の特定と対応について」 [j-lis.go.jp](PDF)から抜粋

          原因2
          (説明)通常、業務アプリケーションがデータ処理を開始する際に、メモリ内に作業領域を確保してから処理を行う。ところが、業務アプリケーションがデータ処理を開始する前にWindowsからタイムアウトの通知を受け取った場合、終了処理が実行され、メモリ内に作業領域を確保していないにも関わらず存在しない作業領域を解放しようとして、業務アプリケーションが異常終了する

          #3006932 [it.srad.jp]が指摘するように不正ポインタ参照でしょうね。
          ただ、終了時に開放リソースのnullチェックしてなかったってだけと思えるような説明だけども。

          親コメント
          • タイムアウトの通知を受けるよりも過去に、作業領域を確保するだけで済みそうな。
            ケチるような場面でもないだろうし。

            それと、常識的に考えて、データ処理とタイムアウト通知受けが別のスレッドで動く事は無い。

            親コメント
          • バッドノウハウを指摘されただけのようにも見える。
            タイムアウトが来たらアプリは使用不能になる→どうせアプリ止めなきゃならないなら、不正処理例外で殺せば良いんじゃ?
            ってパターンもあるかも?
            一見トンでもないやり方に見えるが、リソース節減には有効だったりするし。

            --
            -- Buy It When You Found It --
            親コメント
          • by Anonymous Coward

            ぬるぽっ!

            今時スレッドセーフ意識しないで組むとか有り得ないw
            「数(人月)だけ間に合わせ」てシステム組んだんだろうなぁ。
            そして、個々のスキルは考慮外と。

            炎上するフラグしか見えない…

            • by Anonymous Coward

              ガッ

              #「ぬるぽっ!」って題名のマンガないのかねぇ

          • by Anonymous Coward

            そのPDFによると、コーナーケースのようですね。

            >①タイムアウト通知とタイマリセットが同時に発生した場合、Windowsの仕様上、タイマリセットが行われない場合がある。
            >②この場合、タイムアウト通知が保持されたままとなり、アプリケーションがデータ処理開始前にタイムアウト通知を受け取る。

            nullチェックだけで防げたかというと、どうでしょう。終了処理とタイムアウト通知が運悪く重なると、タイミングによってはnullチェックも突破しそうなような…。いや、でも、図のように終了処理の後までタイムアウト通知を保持するのかなぁ?

            • ソースコード実物を見ないと分かりませんが、この説明はおそらく図のほうが正しく(実挙動に近く)、文章の方が不正確です。

              「タイマリセット」に使っているのは、多分このAPIでしょう。
              https://msdn.microsoft.com/ja-jp/library/cc410876.aspx [microsoft.com]

              KillTimer 関数は、既にメッセージキューに入っている メッセージを削除しません。

              とあります。これはWindows罠仕様の一つです。
              「タイマリセットが行われない場合がある」ではなく、KillTimer関数が呼ばれるまでの間にタイムアウトすると、タイムアウトのメッセージが削除されない事による現象です。

              これ、もう一つ罠があって、『中継処理の完了』メッセージを受け取る前のタイミングで何か別の処理が走りだしてビジーになっていて、『中継処理の完了』メッセージが保留されていると、その間にタイムアウトする可能性があるって事なんですね。
              ですので、この問題が発生するタイミングは「同時に発生」どころか、数秒(数分)に渡る可能性があります。
              (遅延がひどいと2度も3度もタイムアウトを受け取ります。タイマはリピートするので)

              レアなケースではなく、運用環境では頻繁に起きるものと考える必要があります。(そして実際起きた)

              親コメント
              • by Anonymous Coward

                情報ありがとうございます。けれど、SetTimerを使ってリピートさせる必要は無いような…。

                How to make SetTimer() only send one WM_TIMER message?
                http://stackoverflow.com/questions/29135417/how-to-make-settimer-only-... [stackoverflow.com]
                > SetTimer() creates a periodic timer only. The only way to make it a one-shot timer is to kill the timer on the first WM_TIMER message, as you are already doing.
                > Otherwise, change your timer logic so you can use CreateWaitableTimer() or timeSetEvent() instead, both of which can create a true one-sho

              • by Anonymous Coward

                NTTコムかぁ。。
                あそこ、Webシステム開発ですらネット禁止だったりするからリファレンス確認という超基本すら出来なかったかも。

                まあ、それ以前にタイマーに依存した仕組みで作る発想がどうかと思うが、イベント駆動思想無いとこだしなあ。。。

              • by Anonymous Coward

                うーん、これってWindows側から見れば当然の仕様で、別に罠でもなんでもなく、
                GUIアプリでの利用を想定したSetTimer()を使うこと自体がおかしいように見えます。

                ウィンドウメッセージはアプリ側で主体的に受け取りにいかないといけないものなんだから、
                メッセージの発信から受け取りまでにタイムラグが発生するのは当然。
                そのタイムラグによって同期エラーが発生するのは不思議でもなんでもなく、設計段階で当然考慮すべきものに思えます。

                そもそも、アプリ側で主体的に受け取りに行く必要がある(=メッセージループを回してメッセージをチェックするコードを書く必要がある)と

              • by Anonymous Coward

                さすがにSetTimerのタイマーなんて使うわけないでしょー。おもちゃじゃないんだから。
                WaitForSingleObjectとかのタイムアウトだと思いますよ。

              • by Anonymous Coward

                今時のアプリ開発はフレームワーク使って、ウィンドウメッセージを明示的に取りに行くコードは
                書かないと思うんですけどね。

                それが問題だって話ならわかるんですけどね・・・

              • by Anonymous Coward

                と、思ったら、「タイマリセット」と書いてある...。うそでしょ..。
                SetEventのことを言っていると思いたい。

              • by Anonymous Coward

                確実に処理しないといけない部分に、ウィンドウメッセージを使って処理要求をしていること自体もおかしいと思います。
                関数呼び出しやイベント待ちの受け渡しとは違って、ウィンドウメッセージは失敗する可能性がありますから。
                キューイングされるメッセージの最大数とか想像してみましょう。

      • by Anonymous Coward

        # 複数雑なところがあるシステムだって皮肉なのでは。。。

      • by Anonymous Coward

        複雑というよりは、「今どきのOSや開発環境では考えられない」問題のような。

        うん、単純に組んでいればこんなこと起きないかなと。なので随分と複雑だと思いました。

    • by Anonymous Coward on 2016年05月03日 9時09分 (#3006941)

      マイナンバー中枢システムはNTTコムなど「大手5社連合」が異例の落札、114億円で
      http://itpro.nikkeibp.co.jp/article/NEWS/20140331/547394/ [nikkeibp.co.jp]

      > NTTコミュニケーションズを代表とし、ほかにNTTデータと富士通、NEC、日立製作所が参加するコンソーシアムが落札した。

      開発も複雑そう。

      親コメント
      • by Anonymous Coward

        規模の割に開発期間が短いから
        単一ベンダーだと人が手配できず、5社連合になったんじゃ?

        国会での審議状況や法令を見ても、スケジュール的に突貫工事になるのは明らかだったんだし、
        品質がイマイチなのも当初から分かり切っていたのでは?

        少なくとも、政府とお役所のメンツは守ってやったんだから、
        ベンダーがどうこう言われるのは筋違いだと思います。

        • 消費税軽減税率の議論が盛んだった当時は「一年半足らずで情報システムが対応できると思っているなんて、日本の(IT)企業は随分買いかぶられているなあ」と思った。
          政府が日本企業のレベルを正しく認識するのはいつの話だろうか。
          親コメント
        • by Anonymous Coward

          結論としては、日本色々とダメ、って感じ。
          上の方がダメなのに、トップダウンアプローチはミリ。

        • by Anonymous Coward

          規模はわからんがフロントとバックエンドで最低300億ぐらいかなあと思っていたんだが、
          値切って随契とかえらく安い予算しかなかったのな

      • by Anonymous Coward

        つまり日本のシステム開発は駄目という事ですね。

      • by Anonymous Coward

        おなじみの大手各社だが、どこにもいい印象がないや

    • by Anonymous Coward

      騒がしくなってきたので素人が反論できそうにないそれらしい理由を挙げてみただけ。

※ただしPHPを除く -- あるAdmin

処理中...