カテゴリー: 社内SE

会社に古い富士通製のサーバ「PRIMERGY TX150 S7」がある。

スペックは以下。

CPU : XEON X3430(4コア 4スレッド)
メモリ : 4GB
ストレージ : HDD RAID1 500GB

これを以下にする。

CPU : XEON X3470(4コア 8スレッド)
メモリ : 16GB
ストレージ : SSD RAID1 1TB

下の画像がサーバのサイドパネルを開いたところである。ネジ外しも不要で緑の箇所を動かせば、各ユニットが外れる設計となっており、作業はとてもやりやすい。

CPUファンとクーラー。CPUファンはメモリやRaidカードまで冷やすようになっている。外すときはファンの電源ケーブルに注意するくらいでこれも簡単。

CPUクーラーを外すときにRaidカードが邪魔なので外す。

CPUクーラーを外したところ。

ヤフオクで買ったXEON X3470。X3480にしたかったのだが、自腹なのでヤフオクで2000円と安かったX3470。アルミホイルに包まれて送られてきた。

CPU換装。とりあえず、CPUだけ変えて動作確認。問題なし。

次はメモリ。メモリは結局16GBではなく8GBとなった。スペック表には「4GB DDR3 1333 UDIMM」対応と書いている。UDIMMが何なのかわからないが、サーバ用のRDIMMじゃないから、多分PC用のメモリでも動くのね！と喜んで、PC用の4GB DDR3 1333の新品4枚を5000円ぐらいで購入。動かず。今更DDR3の4GB 1333なんてPCでも使わないので、動かなかった時点でゴミ決定。まさに無駄。

新品を買うお金がなくなったので、ヤフオクで「4GB × 4 ECC Registered DDR3 1066」を2000円ぐらいで買う。写真を撮らなかったがこれも動かず、またもゴミ確定。メモリが悪いのか、相性なのかわからないが、とりあえず出品者は最高評価にしておいた。

ちなみにこのメモリを1枚づつ挿して、動作確認していた際に電源を落とさずにメモリを引っこ抜く失態。突然電源が落ち、何かショートしたかと思ったが起動して一安心。

困ったので、今ついているメモリと同じ型番のメモリをヤフオクで探し「2GB × 2 ECC Registered DDR3 1066」を送料込みの500円で買う。ネコポスで届くが、出品者は利益あるのかなど色々不安。問題なく動く。当然出品者は最高評価。

2スロット余っているので、できればもう2枚つけて12GBにしたいが、仕様書に「UDIMM×4、1066 RDIMM×4もしくは1333 RDIMM×6まで搭載可能」とあるので、4枚しか刺さらないと思い諦めた。この時点でヤフオクの到着待ち２回発生で4回ぐらいサーバを開いて汗だくで自腹切りまくりなので「もういいや」状態。

ここから先は写真を撮るのを忘れたので文章だけになるが、このサーバー、フロントパネルを外してHDDマウンタの取ってを引っ張ると、HDDを簡単に引っこ抜ける。素晴らしいが、3.5インチのみ対応。なので、今回買った2.5インチSSDはそもそもこのサーバのマウンタが付かない。2.5->3.5インチ変換マウンタをかませてみたが無理。

とりあえず、2.5インチSSDをSATAソケットに差し込む。軽いので宙ぶらりんだが何とかいけそう。なので、今回ゴミになったメモリの入っていたケースをSSDの下にテープで貼って高さを出すと宙ぶらりんも解消した。とりあえずこれで良いや。

誤算はハードウェアRaid1にしたかったのだが、どうもWindowsかRedhatからしかRaidカードが制御できないっぽい。仕方ないのでUbuntuのインストール時にソフトウェアRaidにした。10年選手のHDD500GBはハードウェアRaidが動いているっぽいので、バックアップ用としてマウント。

サーバは、Ubuntu + samba 4でADサーバに生まれ変わり。オフィスに30人しかいない小売の中小企業が使うには充分でしょう。Ubuntuに感謝。Redhatはもうシラネ。

現在、2023年10月1日から始まるインボイス制度対応に向けて、当社でも絶賛システム改修中である。当社ではPOSから出すレシートと営業部が取引先に出す請求書が社内システムの修正対象だ。それ以外は経理が導入しているパッケージシステムで対応可能である。また、今回の修正ではインボイス制度の後にくる、2024年の電子帳簿法対応も合わせて行っている。

修正点はざっと以下だ。

1. 交付した請求書（レシート）は保存して検索できるようにする。
2. 登録番号や日付など法律の記載事項を請求書（レシート）に載せる。
3. 返品などがあった場合は、返還適格請求書を発行する。
4. 交付した請求書を修正した場合は、「修正した適格請求書」を発行する。

２と３は正直、たいした問題はない。現行のレシートや請求書のフォーマットを少し変えるだけの話だ。

問題は４の「修正した適格請求書」である。システム的なポイントは以下2点である。

• 修正前と修正後の適格請求書は両方保存しなければならない。
• 法律要件の記載事項以外の箇所、たとえば、単純な誤字修正（請求書の「請」の字を「正」と間違えたなど）であっても「修正した適格請求書」扱いとなる。

つまり、今後は、何か間違いを修正する場合は、元の請求書のレコードはそのまま保管しつつ、新しいレコードを修正データとして追加する必要がある。

これが当社のシステム上、非常に厄介であるし、恐らく多くの企業システムでも厄介になっていると思う。

これまでは何か間違っていたら、システム内のレコードを修正し、請求書やレシートを出し直せば、訂正された請求書が出てきていた。ものすごくシンプルで、誰もがわかりやすかった。

今後は、元のレコードと修正したレコードとに分かれるので、肌感的に分かりにくくなってしまうし、例えば、「今月の請求額」などの統計を取る際も、これまでのシンプルに全レコードを合計という形ではなく、修正前のレコードか修正後のレコードか、などを分けて考える必要が出てくる。

始めはもっとシンプルに考えていたのだが、インボイスコールセンターや国税局電話相談センターなど国税局に問い合わせをしていく中で上記が明らかになった。

この修正の何が最悪というと、この複雑な仕組みを作っても、誰も得しないことである。国税局も「修正後の適格請求書」があれば徴税は充分であり、企業側も「修正後の適格請求書」以外は使うことがない。要は、「修正前の適格請求書」を苦労して保存しておくようにしても、誰もそんなもの見ないし必要もないのである。

必要のないもののために、ものすごい労力を要することになる。特に小売りのレシートで「修正された適格請求書」なんて誰が必要とするのだろうか。元データを修正し「適格請求書」を再発行するのでも、国も企業も個人も誰も困らないのである。

恐らく、法律要件違反だとしても、「修正された適格請求書」の発行をしない、もしくは、要件には従わないと割り切る会社も多い気がする。

ただ、当社の場合、誰もコンプライアンス違反のリスクを負いたくないので、国税局の回答に従うことにした。

輪をかけて最悪なのは、営業部である。営業部は（意味不明だが）システムで生成した請求書をコピーし、エクセルや手書きで請求書を書き直している。（なぜかは不明だが）社印を押す必要がある、（なぜかは不明だが）お客様のフォーマットに合わせる必要がある、などの理由を述べられ、「お客様がそう言っている。」との伝家の宝刀に誰も逆らえず、（完全に不合理で意味不明だが）社内の力関係の都合もあり、営業部の要望は飲まざるを得ない。

これらの手作りの請求書もシステム上に保存することになり、改修箇所が当初の想定より大幅に膨らむこととなった。

せめて法令で修正前の請求書は保存しなくて良いとしてくれたら、みんな幸せになれたのにと思う。

開発用にさくらインターネットの一番安いVPSプラン(512M)を使っていたのだが、メモリが少なすぎてubuntu 22.04にアップグレードできない。仕方ないのでOracle cloudの無料枠でVM.Standard.E2.1.Microを立ち上げてそちらに移行することにした。が、実際に移行してみるととても重い。

■ UnixBenchの結果　
　さくら 512M => 1674.1
　OCI VM.Standard.E2.1.Micro => 504

1/3の性能しかない・・・。さくらは1CPU/メモリ512MB、OCIは2CPU/メモリ1GBなのに、1/3の性能しかない・・・。CPUの処理速度、メモリアクセス速度、ディスクアクセス速度、全てがさくらより遅い。

しかたないので、無料枠で2台目を立ち上げ、そこにDBを移動することにした。各VMに2枚目のNICを追加して、そこにローカルネットワークを構築するイメージでいたのだが、どうもOCIは違うらしい。

考えても仕方ないので、1台目と同じようにインスタンスを作成し、 Networkingの設定の場所で
　=> 1台目で使ったものと同じVNICを選択
　=> Assign a public IPv4 addressをチェック
　=> Show advanced optionsを選択
　=> Private IP addressに適当なIPアドレスを指定（10.0.0.20など）
としたところ、1台目のVMから10.0.0.20宛てで接続可能であった。（ちょっと不思議だが、割り当てたpublic IPからも接続可能である。）

ただし、2台間で特定の通信をするにはIngress ruleにルールを追加する必要があった。今回はmariaDB(mysql)だったので、sorceに10.0.0.0/16を指定して、宛先Port3306で登録したところ通信できるようになった。

ちなみに、それでも重かったため、1台目のサーバで以下を行ったところ、大分使える範囲まで落ち着いた。

・swapの追加 (OCIのubuntuのイメージにはswapがない。)
・nginxやopnelitespeedのワーカー数を増やす。（処理が遅いので少ないワーカーではさばけなくなる。）
・ 使ってないサービスの停止

残念ながら、無料は無料です・・・。

少し古い話で恐縮だが、2020年3月から翌2021年9月にかけて、NECが提供する「ActSecureクラウドメールセキュリティサービス」を会社のメールのセキュリティとして使っていたので、その時の話をしたい。

もともとシマンテックのクラウドメールセキュリティを使っていたのだが、シマンテックが買収され、シマンテックの日本法人（と本社）が混乱、システムの年契約が更新できない事態が続いていた。

システム自体は未契約の状態のまま使えていたが、会社としては「サービス突然停止によるメールセキュリティ対策がされなくなる事態」を重視し、別のクラウドメールセキュリティサービスとして、上記のNECのサービスを利用することを決めた。

費用はシマンテックが年間25万ぐらいだったのに対し、NECは年間30万＋初期費用5万と少し高いぐらいである。

実際に切り替えてわかったことは、日本のITの酷さだった。

シマンテックのサービスはWEB上でかゆいところ以上にいろいろ手が届く。メールの総量、スパムの率、誰が誰にメールをしたか、誰から誰にメールが来たか、メールサーバのログを調べる必要ほぼなくなり、しかもきれいなグラフィックで表示してくれる。誤検知で隔離されたメールも管理者のクリック一つで再配送できる。検索機能も豊富だ。

対してNECのサービスは、ログインして表示される画面は８０年代かという酷さで、ログインしても対象のメールアドレスの追加ができるくらいで、ほとんど何もできない。誤検知だった場合の配慮もない。

このメールサービスを使う会社は、メールサーバを自前で持っていると思われるし、当社も自前でメールサーバを構築している。NECのサービスでやってくれることは、自前のメールサーバにセキュリティ機能を組み込めばほぼ同じことが出来る。

結局、1年ほど使って「この程度のサービスなら自前で組み込むから良い」となり、契約を打ち切った。社内からの問い合わせに対し、シマンテックのサービスならすぐ回答できたり対応できるものが、NECのサービスでは出来ない、もしくは、自分でメールサーバの大量のログと格闘しなければいけなくなったのが痛く、費用対効果が非常に薄いとの結論に至った。

それと関連は不明だが、このＮＥＣのサービスに切り替えた直後から大量のスパムが社内のいろいろなメールアドレスに届くようになった。関係ないかもしれないが、タイミングがあまりに近いため、それも契約解除の判断の遠因になった。

社内に英語ができる人間が多いため、海外のIT系サービスも検討の遡上に上がる。その際、国内のIT系のサービスのあまりの酷さに気が付き、うんざりすることがある。本件もその１つであった。

WindowsでCURLが使えると知り、早速dos窓で「curl –version」とコマンドを打ったところ、”curl : リモート名を解決できませんでした。・・・”のエラーが出た。

curlが認識できなく、curl.exeなら認識できるらしい。「curl.exe –version」とコマンドを打ったところ素直にバージョンが表示された。

環境依存かもしれないが参考まで。