トップ ソフト 雑記 日記 リンク

2020年4月12日日曜日

マイキーID作成・登録準備ソフトがインストールできない(解決済)

結論:作業用ディレクトリを指定するTMP・TEMP環境変数を元に戻せ

マイナンバーカード、使ってますか?
ていうか使うところがe-taxしかない。

いや、せっかく国が用意してくれた認証基盤ですし、使えるところが増えてくれば便利にはなると思うのですが、利用者が少ないものを使えるようにする予算はないということで、全て不況が悪いのです。

さて、マイナンバーカードがポイントカードになるというマイナポイントというサービスができました。
これを使うためには登録が必要とのことで、わたしも準備をしてみたのですが、インストーラーが途中で止まってしまって進まなくなります。

ここで止まる。

全くエラーなどは出ず、プログレスバーが100%まで進んだところから反応がなくなります。
タスクマネージャーを見ても暴走しているわけでは無く、全く負荷は掛かっていない。
キャンセルボタンを押しても反応しない。
タスクマネージャーから強制終了する必要があります。

InstallShieldを使っているので、どこかにログは出ていないか探してみたり、コマンドラインからログを出力するオプションを指定してみたり、圧縮されているexeファイルを分解して中のインストーラーを取り出して調べてみたりしたのですが原因が分からず、問い合わせ窓口に投げてみました。

まあ、Windowsを更新しろとか、ウイルスチェックを外せとか一般的な回答だったのですが、うちは素のWindows10環境だったので充分テストされている環境だろうと、一応言うとおりにしてみたものの全く効果はありませんでした。

ダメだったよーと返事を返しつつ、こっちでも他に調べてみた結果などを付けて「ただの素人では無い、分かっている人間」感を出してみたのですが、メールが行って返ってくるのに1ヶ月掛かり、3ヶ月(計6通)で解決に辿り着きました。

解決方法は最初に書いたとおり、どうやらインストーラーが展開する作業用ディレクトリと、実際に実行されるディレクトリが違うようで、これはインストーラースクリプトの不具合だよなぁと。
システムドライブが小さい、SSDを劣化させたくない、など色々な理由で作業用ディレクトリを変更している玄人はいると思います。今まであまりインストーラーで転けるという現象に出会ったことが無かったので、思わぬところでつまずいた感がありました。

この記事が誰かのお役に立てば、という思いで残しておきます。


2020年1月10日金曜日

zabbixの設定画面で、大量のグラフ項目を表示する

わたしは普段システムの監視にzabbixを使っているのですが、ずっと不満点がありました。

ディスカバリで生成される大量のグラフ項目のせいで、目的のグラフが見つけられないという問題です。


zabbixの管理画面では、アイテムやトリガーなどは絞り込み検索ができるのですが、グラフだけは絞り込みができず、表示される最大件数の1000件を超えてしまうことがありました。

この1000件制限を緩和したく調べてみたところ、データベースのconfigテーブルのsearch_limitカラムに記録されていました。


パフォーマンス的な理由で制限が掛けられているのだと思いますが、わたしのところでは増やしても問題は感じませんでした。

これWebUIから変更できないんですよね。
アカウントの設定画面にあった「ページあたりの表示行数」を増やしても、1ページの表示件数が増えるだけで1000件制限は変わらず最大ページ番号が縮むだけでした。

2019年12月9日月曜日

換気、足りてますか?

わたしは季節に関係なく頭が痛くなったりする事があるのですが、そういうときは大抵乾燥が酷いときだったりします。部屋にぶら下がっている湿度計を見ると50%を下回っていて、慌てて加湿機を動かします。

冬場になると、 加湿をしても効果が無いときがあり、他になにがあるだろうかと考えたところ、換気が足りていないのではないかというのを思い出しました。
しかし、息苦しいとか頭がクラクラするとかいうのは感じたことがありません。実際にどのくらい換気が足りていないのか、測ってみないことには分からないということで、arduinoとCO2センサーを組み合わせて測ってみました。

使った部品は、arduino unoと、CO2センサー「MH-Z14A」、気温湿度気圧センサー「BME280」です。



結線とソースコードはググったら出てくるでしょう。
CO2センサーはMH-Z19が欲しかったのですが、Amazonでもどこも海外発送ばかりで、到着まで2週間掛かるということだったので、国内のAmazon倉庫から発送できると書かれていたMH-Z14Aにしました。

arduinoのEthernetライブラリを使って自宅のサーバに計測値を投げてファイルに保存し、zabbixからファイルを読み取るという仕組みにしています。2000ppmをトリガーにして、Slackへ通知を送信。
少しはまった部分としては、計測値を投げる処理を1分に一回にすると、なぜか処理が止まってしまうため、30秒に一回にしています。keepaliveあたりのなにかなのか、調べ切れていません。


二酸化炭素濃度は、自然界でだいたい400ppm、よく換気されている部屋で1000ppm以下、2000ppmからは換気が必要だそうです。
実際「建築物における衛生的環境の確保に関する法律」でも1000ppm以下にすることが求められています。

実際に測ってみて分かったこととしては、意外と簡単に2000ppmに達するということです。
私が普段作業をしている部屋は、 14畳ほどの広さのリビング・ダイニング・キッチン一室。古い建物で、外の風が強いときなどはドアの下から風が入ってきて寒いぐらいなのですが、穏やかな天気の時は意外と密封度は高いらしいです。

冬場は、この部屋で小型のガスファンヒーターをつけています。6畳用だったか、8畳用だったか忘れてしまいましたが、能力からすると不足気味の機械なのですが、2時間ぐらいで400ppmから2000ppmぐらいまで上がります。

冒頭で頭がクラクラしないなんて書きましたが、もっと高い濃度で発生するもので、それより前に作業の能力などにも影響が出てくるそうです。
よく見かける注意書きも、死亡事故なんていうぐらいだから「うっ、苦しい」みたいなことになるレベルを想定してしまいますが、じわじわと身体を蝕んで気が付いたときには手遅れということにならないよう、早め早めの換気が必要ですね。


1月30日 追記
arduino用ユニバーサル基板を買ってきて、組み立ててみました。
EthernetシールドのLAN端子がかなり大きくて、基板を切る必要がありましたが、これでブレッドボードと違って蹴飛ばしても配線が外れる心配が無くなりました。






2019年3月3日日曜日

システム稼働状況ページを作った

Service status osa-p.net を作った話。

元々、zabbixでシステムの状況はモニタリングしているのだが、それを外部に公開する仕組みを用意していなかった。zabbixのページをそのまま公開したくなかったので、必要な情報だけ抽出して表示できる仕組みが欲しかった。


SNSでつぶやいてみると

UptimeRobotというサービスを紹介してもらえた。

早速設定してみたところ、格好良い稼働状況ページが出来上がったのだが、うちのシステム上、ウェブサーバとデータベースが分離しており、データベースを使う処理は動かないが、ウェブサーバだけで完結する処理は動くという状況があり得て、その表示がしにくいなと感じた。

そこで、やはり自前で処理を作るかと、ついでに使ったことのなかったVueも試しに取り入れてみた。普段仕事でもまだまだjQueryを使うことが多く、また思い付いたサービスを個人で作るときにも早く公開したくて慣れているjQueryを使ってしまうことが多い。今回は急ぐものでもなかったので、サンプル程度しか動かしたことのなかったVueを使ってみた。といっても、やはりサンプルの継ぎはぎではあるのだけど。

処理自体は問題無くできて、さて公開するかというところで問題があった。
稼働状況ページは、自分が管理しているシステムの中で動かしてしまうと、一緒に落ちたときに肝心の状況が見えなくなってしまうので、公開ページは別のサービスで動かしたかった。まず最初に選んだのがS3で、ここでは静的サイトを公開する情報も整っていたので簡単に設定して公開。あとはネームサーバとして使っているCloudflareでCNAMEを張ってやれば動くだろうと考えていた。

実際に公開してみたところ、httpでは繋がるのだが、httpsでは接続ができなかった。S3の公開では、「https://S3ドメイン/バケット名/」だとhttpsが使えるのだが「https://バケット名.s3ドメイン」ではhttpsが使えない。Cloudflare側でHTTP Proxyを有効にしていたら、オリジンサーバーがhttpでも使えたような記憶があったのだけど、どうも上手く行かないので間にCloudFrontを挟んでhttpsでも繋がるようになった。

しかし別の問題が発生した。ページの作りとしては、zabbixから出力したSLAの情報をS3に5分毎にアップロードし、静的ページ側でそれを読み込んで表示する。CloudFrontは読み込んだ情報をキャッシュしてしまうので、いつまでも古い情報が表示されてしまうのだ。もちろんCloudFrontの設定にも用意されているので、TTLの設定を5分にしてみたり、クエリが付いていたらキャッシュしない設定にしたり、キャッシュをクリアしてみたりしたのだが、どうにも解消できなかった。

結局Netlifyで静的ページ部分を配信しつつ、データはS3から読み込むという仕組みで解決した。このやり方ならGitHub Pagesでも大丈夫だろうが、最初すべてをGitHub Pagesで配信しようと考えてしまい、5分毎にコミットとプッシュをしたら怒られそうだなと思って頭の中からGitHubを使うことを取り除いてしまっていた。

ひとまず大枠の仕組みが完成したので、これを応用して、zabbixに入力したメンテナンス情報を各サービスで表示したり、自動でメンテモードに切り替えたりもできるだろう。今はデータベースを止めるメンテナンスがあるときに、各サービスのcronを止めたり、フラグを立てたりと手動で処理してアクセスが止んだのを確認してから作業したりしているので、この辺りも自動化してしまいたいと考えている。



2019年1月27日日曜日

PostgreSQLのshared_buffers設定とZFSのARCの関係を調べた

いつも個人のプロジェクトではPostgreSQLを使っており、自宅サーバで大きいデータベースを運用しています。最近まではmdadmで組んだRAID-5の上に、ext4でファイルシステムを作って、その中にデータベースのテーブルスペースを置いていました。
しかし、最近ZFSを使い始め、同じようにRAID-Zでファイルシステムを作ってテーブルスペースを置くようになりチューニングを再確認していたのですが、少し気になることが出てきたので調べてみました。

PostgreSQLのshared_buffers設定

PostgreSQLの設定には、shared_buffersというものがあり、搭載されているメモリから共有メモリを確保して、PostgreSQLの各プロセスが利用しています。この値は
1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。 shared_buffersをこれよりも大きな値に設定することが有効なワークロードもあります。 しかし、PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffersにRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。(PostgreSQL日本語ドキュメント 19.4. 資源の消費より)
とあり、あまり大きくしても効果が無いとまで書かれています。
実際にext4でテーブルスペースを管理していた時は、この設定でhtopをみると搭載メモリの利用状況を示すバーの約25%が緑色、約75%が黄色となり、キャッシュが有効に働いていることが確認できました。

ZFSのARC設定

ZFSにはARCと呼ばれるメモリ上のキャッシュ機構を持っています。これは空きメモリから使用され、ディスクから読み出した際にARCにも格納され、同じデータの読み出しが発生した場合はディスクを参照せずここから読み出すことによって高速化を行います。ZFSを開発したSunのエンジニアが、MySQLで使う場合のチューニング指標として
ZFS上でMySQL/InnoDBを利用する場合、利用されるキャッシュにはいくつかの階層が存在します。InnoDB自身がバッファプールを持っていますし、ZFSにはARCがあります。そして、それらのキャッシュは個別に何をキャッシュまたはフラッシュすべきかということを判断するようになっています。そして、それらが同じデータをキャッシュするというような状況が生じてしまうこともあるでしょう。InnoDB内でキャッシュすると、データへたどり着くまでにより短い(そして高速な)コードパスで済むでしょう。そして、InnoDB内でキャッシュミスが生じれば、例えそのデータがARCに存在していたとしてもダーティページのフラッシュが生じてしまうことになります。これは不要な書き込みを生じさせる原因となります。ARCは利用可能なメモリの容量によって(自)動的に縮退・拡張しますが、単にそれを制限する方がより効率的です。我々が実施したテストでは、ZFS内でキャッシュするよりInnoDB内でデータをキャッシュしたほうが7〜200%の性能向上が見込めることを確認しています。(翻訳を紹介している漢(オトコ)のコンピュータ道: 違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング!より)
と紹介されています。このため、データベースでZFSを利用する場合ARCのキャッシュ情報はallではなくmetadataのみをキャッシュするように設定するという紹介をあちこちで見かけます。

鵜呑みにして設定

わたしもこれを読んで同じように設定していたのですが、思った以上にパフォーマンスが上がらず、はてどうしたものかと悩んでいました。そしてふと気が付いたのが、htopで表示されるメモリの使用状況バーは搭載メモリの25%だけが緑でキャッシュが全く使われていない状況でした。つまりメモリの25%しか使っていない状態でした。

ということは、ext4ではOSの標準設定によりキャッシュが働いているからshared_buffersを増やさなくても良いということなのですが、ZFSでキャッシュを最低限にしている場合、shared_buffersを確保した方がいいのではないか?ということです。

そこで、PostgreSQLにおいてZFSを使用する場合、shared_buffersを増やしたときと、ARCのすべてキャッシュするときのベンチマークを取ってみました。

以下の環境でテストを行いました。
  • Core i7-6700(3.4GHz) Windows 10 Pro上のHyper-Vで実行されるCentOS7
  • カーネル 3.10.0-957.1.3.el7.x86_64
  • CPU割り当て4
  • メモリ 4GB(Hyper-Vの動的メモリは使用しない)
  • ZFS 0.7.12(RPMからインストール)
    zfs set recordsize=128K tank(初期値)
    zfs set compression=off tank(初期値)
    zfs set dedup=off tank(初期値)
  • PostgreSQL 11.1(ソースからビルド)
  • pgbench -i -s 100 bench(1000万件)
  • SELECT pg_database_size('bench'); → 1,576,528,895(データベースサイズは約1.5GB)
  • 設定変更後に再起動。一度pgbench -l -T 60 -c 2 -j 2 -P 10 benchで60秒間のベンチを回して、その後5回分のトランザクション数を記録

テストパターンは以下の4種類です。
  1. 両方鵜呑みにする
    shared_buffers=1GB
    zfs set primarycache=metadata tank
  2. ZFSの言うとおりにデータベースのキャッシュを増やす
    shared_buffers=3GB
    zfs set primarycache=metadata tank
  3. PostgreSQLの言うとおりにファイルシステムのキャッシュを増やす
    shared_buffers=1GB
    zfs inherit primarycache tank(デフォルトがallなので)
  4. 一応両方増やす(サイズ的にshared_buffersが優先になるはず)
    shared_buffers=3GB
    zfs inherit primarycache tank

結果


回数\パターン1234
1656590758773
2552670835822
3613543663644
4586656788794
54766741016987
平均値577627812804
中央値586656788794

ZFSのキャッシュをした方が良いという結果になりました。
パターン2はパターン4と同じになるかと思ったのですが、パターン1よりは性能が良いがパターン3より性能が出ないということで、やはりshared_buffersの設定は増やしすぎても効果が無いようです。
またパターン3とパターン4でも差がないことからshared_buffersを増やすぐらいならARCに回した方が良いという結果になりました。

MySQLでZFSを使うシーンに出会っていないので、今回はPostgreSQLの設定だけですが、やはり実際に測ってみないと分からないものだなと感じました。


ちなみに、ZFSのレコードサイズをデータベースとあわせた方が良いという意見を見かけるので、8Kと16Kを試してみたのですが、

zfs set recordsize=8K tank
回数\パターン1234
1696688681689
2701688690704
3686674631716
4627621639654
5683633678657
平均値679661664684
中央値686674678689

zfs set recordsize=16K tank
回数\パターン1234
1678609682683
2713543682688
3543612604668
4592682680663
5667690689717
平均値639627667684
中央値667612682683

大した有意差が見られず、また128Kの方が成績が良かったことから、うちでも8Kにしていたのを128Kに戻しました。
ARCが効きやすいレコードサイズの設定があるのかと思って検索してみたりしたのですが、それらしいドキュメントは見つけられませんでした。ソースをあたるしかなさそうです。

2018年12月18日火曜日

インターネット蟹工船を読んで

インターネット蟹工船 Advent Calendar 2018、18日目です。

   インターネット蟹工船を読んで
  マクナル星立ゼーポーモ中学校 おさ
 この作品は、まだ人類が母なる惑星、地球にいた頃に書かれたものだ。人類が宇宙に進出し、多くの星々をネットワーク接続するアウターネットになる前の、地球を覆い尽くしていたネットワークでの出来事がオムニバス形式で綴られたものだった。作中では管理者でもない人達が、それぞれ自分たちの価値観で物事を仕切りはじめ、コミュニティが崩壊していく話があった。個人を大切にするという考え方が、自分勝手と誤った解釈になり、共同体に所属する一個人でしかないという前提を忘れさせてしまうのか、そのような動きになる例を道徳の授業で習ったことを思い出した。
 わたしはこの作品を読んで、人類の歴史は繰り返すものなのだと感じた。異なる宗教、星、国、法律、ルール、これらはそれぞれのグループが築いてきた歴史に基づいたものであり、各グループは構成する人員の入れ替わりに合わせて信条が変化してきたものだ。その度に派閥ができ、コミュニティが分かれ、村、国、星、宗教が分かれてきた。人はそれぞれ考え方が微妙に異なり、完全に同じ考えを持つ人間は存在しない。それは同じ条件式と学習結果を与えられたコンピュータだけだろう。
 地球で文明を持ち始めた頃の人類は、各々が役割を分担することで、一人あたりの生活コストを下げ、文化を成長させてきた。人はお互い微妙に異なる考えや価値観を擦り合わせ、許容できる者同士で集まって生活しているのだ。これはネットワークにおいても同じことが言える。アウターネットになった現在でも、サービスは宇宙空間に分散したサーバー上で実行されているし、そのサーバーはエネルギーを得るためにどこか恒星系に所属している。これはアウターネットでの活動も、何らかの制約に縛られるということだ。なんの制約にも縛られたくないという人達もいるようで、アステロイドベルトの公宙域にサーバーを置いている人もいるようだが、警備ロボットなどでかなりの費用が掛かっていると聞いた。この作品でも語られていたように、自由とはコストが掛かるもので、何かを守るためにはお金であったり、人的リソースであったり、とにかく力が必要となる。
 わたしは大金持ちになったら、ぜひ自分のサーバーを打ち上げてみたいと思った。しかし現代では人類の活動範囲が広がってしまい、みんな同じような生活となってしまっているので、きっと共有サーバーで他の人達とアウターネットを使っていくことになるのだろうなと思っている。相手への敬意を忘れず、自分に合う活動領域を見つけたいと感じた。

エスペラント語でTerpomoってポテトの意味らしい。

2018年12月14日金曜日

マストドン専用って言いたくなかった(分散SNS Advent Calendar 2018)

分散SNS Advent Calendar 2018、14日目です。

分散SNS、2年目ともなると、だいたい概念を理解して、なんとなく使い方の勘所が掴めてきましたよね。去年4月の右往左往していた時期が懐かしいです。分散SNSということで運営の権限を分散させるだけでなく、マストドン以外の実装としてPleroma、Misskey、microblog.pubなんてのも出てきました。実装も分散されているのにお互いが会話ができる、バベルの塔を壊すべく言語を乱した神様もビックリでしょう。今ならバベルの台地も作れそうです。

去年は、Mastodon 2 Advent Calendar 2017マストドンのフォロー状態可視化ツール「フォローリンク」を書きました。マストドンアドベントカレンダーでした。
そう、去年フォローリンクを作ったときはマストドン専用だったのです。せっかく実装が複数あるのに、どうしても注目を集めたということで人口の多いマストドンがさらに注目されてしまうのは仕方がない部分があるかと思います。APIの実装なども先行している部分がありますね。

しかし分散SNSという仕組みがあるのだから、どうせなら特定の実装に依存せず、みんなで使えるようにしたいということで、ActivityPubでデータを取得するようにしてPleromaに対応しました(あ、Misskeyで動作確認してない)。ActivityPubでも、実装によってデータの持ち方が違って、若干揺らぎがあるのが辛いところですが、テキストで入っているかオブジェクトで入っているかなので、扱いに慣れてくると問題なさそうです。

そして今年、もう一つサービスを公開しました。ログ蓄積サービス「notestock」です。何ができるかというと、まあサイトを見てもらうのが手っ取り早いのですが、簡単に書くと日付別にまとめて表示したり、検索ができます。
実はnotestockの前にMastoDaysというサービスを公開していました。特定の日付のマストドンユーザーページを開くツールだったのですが、名前から分かるとおりマストドン専用でした。

実装を意識しないでツールが使えるというのは、なかなか使い心地が良いです。上手く疎結合にしていろいろなツールの選択肢が広がると良いですね。ということで、本当にマストドンでなければいけないツールでない限り、できるだけいろいろな実装に対応していると嬉しいねという話でした。

と、ここまではコミュニティのインフラ的な話だったのですが、もう一つコンテンツ的な部分の話も。
ときどき流れてくるハッシュタグ「マストドン○○」とか「○○マストドン」みたいなやつ。あれが流れてくると、他の実装の人って、参加していいのか迷うというか、参加するにしてもちょっと乗り切れない感じがありますよね。
日本語が、五七五のリズムで刻むと気持ちいい感じがあるので、「マストドン 付いてるタグは 気持ちいい」んでしょうね。あと、ゲーム機は全部ファミコンと言うみたいに、分散SNSを指す言葉としてマストドンが使われてしまっているところもわりと有る気がします。このへん、先ほども書いたように先行プロダクトとして仕方ないのかなぁと思うところもあるのですが。

ということで、分散SNSをハッシュタグに使えばいいんでしょうけど、「ぶんさん えすえぬえす」と10音もあると、なんかまどろっこしい感じになってしまいます。ここは略語としてよく使われる四文字を探し出し「ぶんさん」を使って「分散○○」みたいな感じはどうでしょうか。ただ、この場合は後ろに分散を付ける「○○分散」はちょっと意味が伝わりにくくなる気がします。

ここまで書いて、別に分散SNSを表すハッシュタグを付けなくても、単純に「○○」だけ付ければ良いんじゃないかと気が付いてしまったのですが、たぶんこの辺りって「マストドン(分散SNS)にいる仲間達」みたいな帰属意識から生まれるものなのかなぁと思ったりもしました。

ハッシュタグを付けるときに、少しマストドン以外の存在も思い出して欲しいなという提案と、なんか呼びやすい略称は無いですかね?という問いかけでした。

広告