名推理が出た。
主キー（primary key）を"master key" だと思い込んじゃったんじゃないだろうか？ https://t.co/QOOvJoM9H8
— エスペラ (@proten2199) 2022年10月16日
ひょっとしてお主、主キーのことを「マスターキー」と読んどるんじゃないかね？ https://t.co/YSGCjNaobK
— あんだー@湯呑み (@dashi1211) 2022年10月16日
まとめにはそもそもの発端が無い。
最初はマイナンバーカードへの懸念だったはず。
これもこないだ知り合いと話したんだけど、システムとしては国民ごとにユニークな番号（マイナンバー）を割り振って、その番号を通知した時点で完成してるハズなんだけど、そのシステムの充実は放っておいて「カード」の携帯と機能集約に注力してるのはメチャクチャ怪しいんだよね挙動が。
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月13日
暴走のきっかけはコレのはず。
そこで「カード」というハードウェアを国民の身体（すなわち生活し、行動する主体）への携行を余儀なくさせる、そう追い込むというのはかなーり不気味な政策なんですよね
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月13日
で、発端のリプがこれ。
電子署名とかに使う公開鍵暗号の秘密鍵の保持するコンテナからですね。すべてが電子化する時代の実印の機能。実印使う権利を個人が保持するのに必要。
— はくさい (@white_vegetable) 2022年10月14日
パスワード付きの実印で、さらに、落としても、更新時も新たな秘密鍵を生成するのでセキュア。
で、リプライに対する引用リツイートがこれ。
で、なぜかその「秘密鍵のコンテナ」に、キー値であるマイナンバーが記載されてるんだぜ。ご説、すべて破綻します https://t.co/UHOhZXp7zH
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月14日
そしてこうつながる。失敬だな。
名前やアイコンが野菜だからって脳まで野菜にするなよ
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月14日
まだ続く。この罵倒意味がわからない。上のリプライからこう来るつながりがわからん。罵倒できるポイントが無いのに罵倒するとか狂人じゃん。
本当にまじでこんなレベルのがね……もうね……
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月14日
まだ続く。「落とす」か？公開鍵。なんか勘違いしてねえか？
落としてセキュアなのは公開鍵だもんね（公開鍵暗号方式の話をしてるなら）。 https://t.co/ZOgzJTb6eb
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月14日
秘密鍵も何も鍵は秘密なもんだし、わざわざ秘密鍵というワードを使うからには公開鍵暗号方式のことである可能性が高いけどもそこで「秘密鍵を生成」がもう謎だし、とにかくそのセキュア？なカードに肝心のマイナンバーが記載されてる時点で終わってるじゃんって話をね、皆さんしてるんですけどねい… https://t.co/ALauYIh9Ue
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月14日
だから「マイナンバー」自体がカードに記載されてなくて、QRコードでもICチップでもいいけど本人確認用の符号、物理的なキーとしての機能だけを持たせるんだったら運用として分からなくもない、でもそういう設計してないでしょという話をね、これ昨日もしたね、はーもう
— こなたま（CV:渡辺久美子） (@MyoyoShinnyo) 2022年10月14日
まあ普通はこうなる。
一連の呟きを拝見させていただいたのですが、主張のロジックが私にはどうも理解できませんでした。「キー値であるマイナンバー」←ここです。私はマイナンバーカードを用いた具体的な認証フローは知りませんが、安全と評価されている公開鍵暗号系の鍵長の知見がある人ならば、細かい認証フローを知らな
— SilveryBlue (@sbmarilth) 2022年10月14日
くても、カード上に印字されている数値かキー値であるというような発想はそもそもしないと感じました。
— SilveryBlue (@sbmarilth) 2022年10月14日
上では鍵長の話だけしましたが、公開鍵暗号系における秘密鍵，公開鍵の意味を理解されている場合も、カード上の数値かキー値であるというような発想はしないと思います。
— SilveryBlue (@sbmarilth) 2022年10月14日
お前は中井かっていうくらい「キー値」連呼してたけど、この手のシステムでRDB直接晒すような造りの物なんて無いのに、マイナンバー一つで根こそぎ引っこ抜けると思っている時点で、どうしようもなくわかってない。 https://t.co/tfJovYLS8s
— ꧁🐶꧂ (@shigeo_t) 2022年10月16日
![お得な５個セット！！[三基商事]ミキプルーン エキストラクト](https://m.media-amazon.com/images/I/51EER5LDzAL._SL500_.jpg "お得な５個セット！！[三基商事]ミキプルーン エキストラクト")
今考えると、貴一連呼するのは柳沢慎吾だな。本人が連呼するわけがない。
主キーをマイナンバーシステム全部を開くことができる魔法の鍵だと思った理由はコレじゃないかと。
と思ったけど、元は公開鍵・秘密鍵からこういう話に急に飛んだので、日本語→何かの言語に翻訳→日本語という翻訳を介したやりとりかもしれない。翻訳エンジンによっては、鍵もキーも同じに見える可能性がある。日本語で技術的な話をしている時は、鍵は暗号系の話、キーはDB系の話ってわかるけど。 https://t.co/ctPo7njKFJ
— ꧁🐶꧂ (@shigeo_t) 2022年10月17日
これでマイナンバーカードの話していたのに、いつの間にかマイナンバーのRDBの話(単一のそんなものはシステムを分散させているので存在しない)をしている変な人について、一定の解が出た。。
公開鍵、秘密鍵の話振られても券面にマイナンバー書いてあるじゃないか脆弱性ガーになるわけが。普通は公開鍵、秘密鍵の話振られたら、暗号化方式とか鍵長とかICチップの耐タンパ性とかそういう話をするんだが。某システムでDES使う時に、古い雑誌に載ってたDESのソースコード使った話する？
あと、マイナンバーに関連するシステムにメインフレームが入っていたら構造型DB(IBMのIMSとか)を使っているかもしれないってことは想像もしてないだろうな。流石に業務やデータの特性的にKey Value(NoSQLとか)やドキュメント型DB(MongoDBとか)は使ってないと思うけど。
ここからが本題。昔話をする。本題までが長すぎる。
ある日、親会社の課長に呼ばれて水道橋のある古い雑居ビルに行くことになった。下記のプロジェクトから逃亡したあと、
千葉ニュータウンに飛ばされて通勤片道3時間で死にそうなので3か月で逃亡したあとの話。
記事では通勤定期に触れていないからわかんないけど、オレが千葉ニュー通いの時は基本的に週4だったので通勤定期買わない方が安かった。確か1か月定期だと月に23回行かないと切符に負ける設定だったはず。週4は20日に大きく満たない。
— ꧁🐶꧂ (@shigeo_t) 2022年10月1日
https://t.co/lFLEKHmHNj
課長曰く「1帳票出すのに23分掛かる。いくらなんでも遅すぎる。なんとかしてくれ。」「あと、アプリの改造は無しな。」
アプリの製造はウチのアプリ開発部門、SEはウチなんだけど実質ウチの子会社が担当というプロジェクトだった。当然データベース担当も子会社の奴。ただ、そいつはデータベースの専門家を名乗っていて、オレより3～5歳位若い奴だった。しかも、もう他のサイトに行ってる。
使われているのはOracle 7か8、多分7だったと思う。そして、サーバはWindows NT4.0サーバ。
その頃UNIXマシンばかり触ってたので、うっわ、これがNTかよって思ったけど、遅いのはOSやWindows NT用サーバ機が原因ではなかった。サーバOSとして考えたら操作性は最悪だったけど。
タイトル通り、主キーしか無かったｗ。データベースの専門家は何の専門家だったんだろう。帳票作成もとんでもなく遅かったけど、オンラインアプリも遅いってことが分かり、全体的にチューニングすることにした。
一旦脱線するけど、このお客さん夕方5時過ぎるとほぼ毎日職場の流しで魚を焼き始め酒盛りする楽しい職場だった。水道橋でドーム近くなのに。オレらも誘われたけど、毎日応じるわけにも行かず腹減らしながら残業してた。魚焼くっていっても乾物じゃなく生サンマとか生イカとか生サバである。まあたまには干物も焼いてたけど。
話を戻す。オレはこういう経験している程度にはOracle知ってた。
最初に見たのはOracleに割り振っているメモリ。デフォルト値だったｗ。サーバの搭載メモリに合わせてギリギリまでアップ。
次はデータの物理的な配置。これは、ディスクの本数が少ないのであまり分けられないけど、これも物理I/Oが分散するように再配置。国際問題になりそうだった時はUNIXマシンでrawディスク使ってたけど、NTではどうもできなさそう(できたかもしれないけど、今みたいにネットですぐに情報検索できなくて時間切れ)なので、NTFS上に置いたまま。
まあ、ここまでは1日でできた。問題はそれでもそんなには改善していない。件の帳票作成が23分から12分ちょっとになった程度である。実務的に遅いという意味では五十歩百歩である。しかも、ちょうど。何か数字を言われたら「ちょうど～？」って聞き返すのが磁石永沢の持ちネタなので是非覚えて帰って頂きたい。使い方としては、
「日本の人口は1億2千人だよ」
「ちょうど～？」
です。絶対に丁度じゃない数字を振られた時に使う。
次にインデックスの作成状況を見た。無い。ほとんど無い。つまりタイトル通りである。クソ遅い理由がよく分かった。
「アプリの改造は無しな。」という条件付きなので、どういうSQLを出しているのかCOBOLだったかCだったかのアプリを見せてもらい、どんなSELECT文かを書き出す。それでSELECTのWHERE句に合わせてINDEXを作成して性能を見る。またANALYZEして統計情報を集める。
さらにバッチ処理では素でSQL発行している奴もあるので、そこにはヒントも追加する。この「アプリの改造は無しな。」はアプリ部隊に追加作業を出したくない(=追加費用0)っていう意味なので、オレがバッチファイルを直す分にはOK。
こうして、オンライン処理も速くなり、件の帳票も1分程度まで短くなった。なお、1分程度の内訳だが3秒がデータベースアクセスで、残りがCrystal Reportsの生成だった。
Crystal Reports部分のチューニングまで言われなくてよかった。実務上、1分ならまあいいかって感じだったし。Crystal ReportsがSAPに買われたのは知らんかった。
結局、件の帳票については22分のDBアクセスを3秒まで短縮できたことになる。
この「データベースの専門家」とは、この後も何度も対戦して全部勝ったけど、オレは別にデータベースの専門家ではない。
- 某総研でデータウェアハウス用のデータベースの選定を行うにあたり、自社の直属じゃない上司に呼ばれて行ってOracleのチューニング。「データベースの専門家」は親会社の誇るDBMSを担当、あと知らない人が(会ってない)Red Brickを担当。Oracleが選定された。
- 同じく某今は亡き損保会社からオレが受注した案件で、「データベースの専門家」をデータベース担当者として付けられたけど、性能測定したら全然ダメだったので休日に夜間作業して全部作り直した。やったことはメモリチューニングとI/Oの分散。
- 同じく某今は亡き損保会社からオレが受注した後続案件で、それぞれ別のサブシステムの構築を担当し、オレと部下の人は1日で終わって仙台の牛タン食って翌日残作業片付けて帰ったけど、そいつらは3日経ってもサーバ立ち上がらず。だって、そいつらスクリプト流してはタバコ吸いに行って戻ってきたらエラーで落ちててそれ直してまたタバコみたいな感じで作業。データセンタなので喫煙所遠いｗ。オレも当時は喫煙者だったけど、面倒だから1回しか行かなかった(場所教えてもらっただけ)。
オレたちは横浜の開発環境で環境構築したものをDDSに吸い上げて持ち込み、本番環境に落とし込んで開発環境と本番環境の違いだけを修正した。そいつらも同じ手順できるはずだったんだけど、なぜかクリーンインストールで失敗連続を選んでた。
みたいな。なんか他にもあった気がするけどまあいいか。
