基盤：jp1のファイルの整理のついでに、ライトセールのインスタンスのリストらを行いたいと思います。まず、現状はこのようです。
基盤：ネームサーバのns0fは7月のはじめに、DeleGate動態保存サーバのaw1は7月の末にdg9へ、それぞれバトンタッチしました。
基盤：それでも未だに、どちらのHTTPサーバにも日に100件前後のアクセスがあるのが興味深いところです。
開発：DNSレコードがロボットの脳裏に焼き付いちゃってるんですかね。
基盤：初代ネームサーバだったns0のDNSサーバfにも、未だに一日に30件前後の検索が来ています。
基盤：会計はひたすら明朗。
基盤：$5 x 8 / 30 ≒ $1.3/day で固定しています。
基盤：5リージョン別にみるとこう。
基盤：サービス別にみるとこうなります。
開発：$5は税別だったんですね。そりゃそうか。
基盤：ということで、負荷によらず課金は全く一定。aw1 と ns0f を切ることで、ストレートに月当たり $5 x 2 ぶんの削減になります。
社長：現在どういう負荷状況ですか？
基盤：最も活動している ns1 で4％以下です。連続的に持続できるのが10%までですが、まだ半分余裕があります。
基盤：DeleGateの動態保存サイトは 1% 未満です。これは、$3.5インスタンスでも良いかもしれません。
基盤：一番活動のないムンバイ支局はほぼ0%です。
経理：これこそ $3.5 機で良いのでは。
開発：時々実験用に負荷を掛けることがあって、その時に使い物にならないと困ります。
基盤：ただ、インドではなくて、ソウルとかシンガポールあたりのほうが面白いかもしれません。
社長：WebSurkitとかでサーバ側にも負荷の掛かるサービスを始めたいですね。
基盤：ということで、aw1 と ns0f の消灯を行いたいと思います。
開発：最初のライトセール機だっただけに、寂しい気はしますね。
経理：とっとと捨てましょう。
基盤：では、インスタンスを削除。
基盤：静的IPの削除も忘れずに…と。終了しました。
経理：1日100円でクラウドサーバの夢が実現しましたね。しかも6台並列。
開発：なんとなくダンボール箱だけだと殺風景ですね。
社長：何か面白い詰合せのインスタンスを作るのも良いかもですね。
基盤：Ubuntu 20.04 がサポートされてますね。
基盤：あるいはやはりWordPress専用機とか。
開発：xso の WordPress をこっちに移転するとか。
基盤：xso はストレージ 250GB 使えますからねえ。現在既に、98GB使ってますし。 ライトセールでは160GBでも$40しちゃうんですよ。
社長：動画とか貼り付けまくってますしね。やはり、its-more.jp はもう xso に縛り付けですかね。
経理：それですと長期まとめ払いにするのが良いかと。
社長：いや、以前やろうと思ったのですが、解約しようとしているExchange Onlineオプションとのまとめ払いになってしまうんです。で、Exchange Online オプションを解約しようとしたのですが、やり方がわからず… 放置してしまいました。どうもリセラーが途中にはいると面倒臭いことになりますね。
開発：なぜに Exchangeでしたっけ？
社長：結局 Gmail になったわけですけどね。Gmail のブラウザだと電子署名機能がなんかダメなので Outlookでやろうか、ならExchangeだなという事だったように思います。結局 Gmail に独自ドメインを作って、そこのメールアドレスで電子証明書を取って、macOS の Mail で Gmailを読んで署名する今の方法になったわけです。なので、Exchange はインフラが Gmail に決まった時点ですぐに解約すべきでした。
経理：何ヶ月も無駄にエアExchange代、月500円が流出してたんですね…
基盤：そういえばGSuitesがなんとやらに改名して、課金体系が変わりましたよね。確か、ドメイン名とメール使うだけなら安く済むようになったような。毎月1360 x 2 はちょっと重いかなと思います。
社長：それも要検討ですね。
経理：あ、これですね。
開発：一つを現在のStandard からStarterに変更すると 680円/月浮くわけですね。
基盤：同じ2720円払うなら、Standard x 2じゃなくて、2040円で5TBの Business Plus + 680円の Starter にするのがお得ですよね。
社長：といいますか、今の契約では 1TB だったように思うのですが。
基盤：このあたりの経緯は6/1のブログにかかれてますね。
-- 2020-1029 SatoxITS
Exchange Online解約
社長：xso にメールで問い合わせたら、Exchange Online の解約はメールで申し込んむんだそうです。
基盤：ブラウザから出来ない理由が全くわからないですね。
社長：ふつう、このアクションの所に解約ボタンが表示されると思いますよね。
開発：実はこのハイフンの部分はクリッカブルだったりして。
社長：早速メールしたら速攻で解約できました。04:06に解約方法を問い合わせメールしたら、09:06に回答メール。まあ朝イチですね。解約の受付けは営業時間内、10:00からです。10:08に削除申請メールを送って、14:03に削除完了メール。この件は人間が作業していることを考えると、まずまずのレスポンスと思います。
基盤：無人で出来ない理由が全くわからないですね。そもそも、なぜExchangeの解約方法を文書として公開していないのか。
開発：雇用対策では。
基盤：経営姿勢とか。
社長：というわけで、純レンタルサーバのぶんを12ヶ月まとめ払いします。
経理：一月1078円。これまで毎月、サーバーぶん1430円、Exchange 473円、合わせて1903円請求されてましたから、825円/月の削減です。これまで6ヶ月分払ってしまったので、4950円損失したとも言えます。
社長：これで思い出したのですが、以前まとめ払いにしようとした時にはあのクソビルダーがサーバとセットになっちゃってて、あれは解約時期に縛りがあって、解約できなかったんですね。
基盤：このレンタルサーバ単体は、特にまとめ払いにすれば、コスパが良いと思います。とりあえずドメインとったら、ウェブサーバ立てて、メールもやり取りできる。SSHでログインしてプログラム開発もできる。ストレージ250GB付き。サーバ定期バックアップ付き。月1000円。良心的と言って良いくらいです。
開発：長期運用するサーバは最初にまとめ払いにしてしまう。各種オプションは月払いで何時でも切れるようにするのが正解ってことですね。
社長：まあ、セットにしてあっても、メール経由でならサーバだけまとめ払いにできたのかも知れません。
基盤：ブラウザから出来ない理由が全くわからないですね。技術的な理由が。
開発：できなくしてある理由なら理解できなくもないですけどね。
カウンターゴミ掃除
基盤：jp1のゴミカウンター込みのバックアップが終わってます。所要11時間超。以下、現状です。
基盤：削除します…
基盤：削除完了しました。所要4分弱。
開発：意外とあっというまでしたね。
社長：うんうん、これでしばらく大丈夫。
全く新しいカウンターの設計
基盤：いずれ異常カウンタファイル生成の原因の調査と対策をお願いしたいです。
基盤：そもそも1回だけのヒットでも1ファイル256バイトだけどファイルシステム上は４KB。中間ノードのディレクトリに各256B。これもなんとかしたいですね。
社長：やはり、ハッシュテーブルというか、dbm にするんでしょうかね・・・
開発：各URLのカウンター256バイトがびっちりつまったブロックと、URLへをそこへのインデックスに変換するテーブルですね。カウンターブロックのほうは、200万URLで 2M x 0.25KB ですから0.5KMBつまり500MBの単一ファイルに収まることになります。
開発：マッピングテーブルのほうは、URLをcrc32してハッシュのインデックスにしてやるのが良いかもしれません。1000万エントリとして、10Mエントリ、各エントリはCRC32+インデックス＋アルファで8バイトとすると、80MBのファイルに収まることになります。これはランダムアクセス性が高いので、RAMが1GBのライトセール機には小さいことが重要です。
基盤：同時に複製を作らないとバックアップが不整合になるでしょうね。1ファイル壊れたら全部アウトです。
開発：まあそのへんが嫌だったのがこういう実装にした理由の一つだったと思います。排他制御も結構イヤだし。dbm/ndbmの互換性がっていうのもイヤでした。dbmにすると中身を観察するのが面倒でしたし。
社長：カウンターブロックのほうにURLを入れて、マッピングテーブルが壊れた時に再構築できると良いですね。
開発：可変長は難しいですね。URLのCRC32にならまだなんとか。
社長：CRC32からURLへの逆変換は？
開発：1URLの平均を64Bとすると、カウンターブロックの1/4ですね。200万URLなら128MB。ただ、マッピングテーブルのファイルが8Bでは足りなくなるので、これを16Bにすると、1000万エントリで160MBとなります。
社長：つまり200万URLを想定しても、ハッシュのマッピングファイルが 160MB、カウンターブロックファイルが500MB、URL逆引き用が160MB、合わせて1GBには収まるということですね。
開発：今度作るならGoで作ると思いますが、dbm的な既存のライブラリを使うとしても、そのくらいが目安かと思います。
社長：カウントアップはスプールして順次加算でも良いかもですね。
開発：まあ、最高で毎秒10回程度、100ms間隔程度のアクセスを想定すれば、この排他制御がネックになることは無いと思いますが。ロックがフリーズしたら嫌だなってくらいです。
基盤：分散したライトセール機の間のカウンターの共有もしたいですね。
開発：これは各サイトごとのカウンターを作って、他のサイトのカウターと合算すれば良いと思います。1GB程度ならまあ、時々全体転送しても良いですし 、100KB x 1万のブロックぐらいに分割して、変化のあったブロックだけ転送するとかでも良いかなと思います。完全に同時に共有は難しいですが。
社長：現在くらいのアクセス頻度なら、１リクエストごとにカウンターアップデートメッセージをブロードキャストするのでも十分でしょうね。HTTPでもWebSocketででも。後で精算することを考えたらUDPでも良いかも知れません。
基盤：1GBくらいのファイルで、常に複数リアルタイムミラーするような汎用のものがあると良いように思います。
開発：ここのところウェブ系の作業だけしてましたが、そっち方向のプログラムが書きたくなってきました。
Azureは今
基盤：そういえば、Azureはどうしましょう。
経理：ディスクの保管のためだけに毎月600円かかっているようですが…
基盤：久々にコスト分析・・・お、過去12回ぶんの請求書表示機能というのが付きましたね。
開発：なんでしたっけこれ。
基盤：・・・30GiBのPremium SSDですね。
経理：30ギガの保管に毎月600円・・・
基盤：一応、仮想マシンのスイッチを入れればすぐに使えるようにワンセット保管してあったんですね・・・
基盤：で、これはOS用の最小ディスクなんです。
開発：HDDにクローンして差し替えたりできないですかね。
基盤：まあ、新しいVMを作って転送すれば良いと思いますが。
社長：HDDだといくら位になりますかね。
基盤：プライシング・・・32GiBだと、Premium SSD が 537円、Standard SSD が268円、Standard HDDが172円ですね。
経理：HDDにしましょう。
基盤：性能的には・・・Standard の SSD と HDD は同等ですね。500 IOPS （！）、60MB/秒。
開発：500 IOPS ！片道1msの世界ですね。
基盤：でも、RAMのバッファによく使うのが入ってればまあ問題ないかなと。
社長：じゃあそれで作ってみましょう。
基盤：作るのは割と簡単なんですよね… HDDで。あー、RAMが最小の0.5GBじゃきつかったですね。1GBで。おーっと、VMを選び直したらしれっとSSDに戻ってます。HDDで。作成。・・・できました。これで月当たり、VMがノンストップ稼働でも1100円、HDDは固定で172円のはずです。
基盤：SSHでログイン・・・まあ、普通に動きますね。ちょっとディスクを調査。
基盤：もういっぱつ。
開発：まあ、キャッシュに入ってれば無問題という事ですね。Goをインストールしましょう。sudo apt install golang ... あれ？あそうか、apt update。普通にさくさく動いてる感じですね。apt upgrade。
社長：ところでAzureのVMって、自動的にスリープするってできるんですかね？
開発：どうなんでしょうね。apt install golang ... 終了。全くストレスないです。hello.go ...
基盤：極めてまともですね。
開発：ライトセールで比較。
基盤：同等ですね。
開発：まあAzureとは関係ないですが、GShell をテスト。
基盤：無問題。
社長：うーむ… CPUをヘビーに回し続けるようなサービスをする場合、ライトセールはきついですが、Azureならライトセール2機ぶんでイケるということですね。まあEC2と比較する必要はあると思いますが。
基盤：ただAzureの場合、通信の課金がよくわかりません。CPUをバリバリ回して、入出力は少ないみたいなサービスなら良いかなと思います。
開発：ブラウザのビルドとか、社内のVMで何時間も回すと結構電気代食いますよね。まあ最低でも4コア、RAM 8GBはないときついですが。
社長：Azureに1台飼っておくのも良いかもですね。
開発：カウンター＋統計サーバにするとか。
基盤：思い出のaz2はどうしましょう。
社長：即、破棄しましょう。
-- 2020-1029 SatoxITS
