さて、選挙も残すところ5日ばかりになりました。5月に選挙がスタートしてから毎日、選挙の集計情報をコツコツと公表してまいりました。
ビジネスも戦争も常に自分の立ち位置を把握するべく数値情報を定期的に把握することは重要です。
そんなことをみなさまに提供できなかとおもい初期のコードをサクッと作った覚えがあります。その後、第2期になり、既存のカテゴリーも競争相手として取得することになり、コードは約2倍の大きさになりました。
少しレガシーで少しマイナーなサーバーを活用した家内制手工業的データー集計システム
アメリカのサーバーより、定期的にデータ収集のためAPIコマンドにてデータを収集し、集計をとります。
その集計結果をもとにALISに掲載できる形式の原稿を作ります。最後にその原稿を自動的にALISに投稿を行い、さらに仕上げとしてtwitterで拡散して完了となります。
いいねとコメント数はそれぞれの記事のIDをベースにさらにALISのサーバーに確認にいきますので記事が増えれば増えるほど時間がかかる仕組みとなっています。
コードについては次回触れようとおもいますが、Pythonで構築しています。
本システムはレガシーなサーバー上に設置されています。ALISの使用している、かっこいいAWSのサーバーレスは使用していません。
理由は主にコスト
AMAZONのAWSで行えば、ALISと同じサーバーに設置することができますので多分いろいろ爆速で行えるのですが、昨年仮想通貨の自動botを設置してAWSの無料枠を使い果たしていしまいました。
儲かりもしないことに無駄な費用を使ってしまった。
(● ˃̶͈̀ロ˂̶͈́)੭ꠥ⁾⁾
今回、使用しているサーバーはGCEと呼ばれるGoogleのサーバー
Google Computer Engine
あまり普段の生活では馴染みがないかと思います。少し地味なところがかっこいいと中2病的には感じています。全然レガシーでなくめちゃんこ最先端ではあります。
このサーバーにLinuxを書き込み昔ながらの方法で運用しています。このあたりは今風ではありません。今は機能ブロックをそれぞれ必要な分だけ買う方法がおしゃれでかつセキュアーなので...
無料枠に惹かれGoogleを選んだのに結局、スピードが遅くて有料課金をして増強するという情弱な運用をしています。
最新のシステムだけあって、運用開始時にCPUやメモリーのサイズが選べます。内部的にはVM(バーチャルマシーン)の性能を一意的に決めているだけでしょう。
最近のシステムでは自分の構築したサーバーのイメージを一旦保存しておき、他のVMマシンにコピーできます。今回も途中でサーバーのパワーが足らずVMのお引越しをしました。
引越しにかかった時間は30分くらい。Linuxサーバーを自作で作って遊んだことがある方からしたら信じられないスピードではないかと思います。それも全部ブラウザ上でポチっただけです。
いま、ビジネス向けのトップのクラウドといえば
Amazon AWS(エーダブルエス)
Microsoft AZURE(アジュール)
の2つでありこの2社で世界の50%のクラウドシェアを持っています。
Amazonは世界にCloud Computingを根付かせた業界リーダーであり、そのあとを頑張って追ったのがMicrosoftです。MicrosoftはOS屋さんだったのが、このクラウドビジネスの頑張りでいい地位を確保できています。
2位が、大きくなるのには、理由があり、どの企業もAmazonに頼りきってしまう体制を嫌い、リスクヘッジをかけて第2位にもインフラをいれるということをやっているわけです。
よくビジネスでは1位、2位がめちゃ大きくて3位以降を引き離す構造をみかけます。スマホは顕著ですね。クラウドの2位の地位を盤石にさせる戦いはビジネスマンにとって熾烈を極める戦いであったことはまちがえありません。
ちなみにマイクロソフトのクラウドビジネスを成功させた男が今のマイクロソフトの社長なわけです。めちゃんこ大きな成果を持ってやってきた天才です。こちらに記事化していますのでぜひご覧ください。
さらにマイクロソフトはブロックチェーン推進派であり、ALISとも仲がいいのでとても好感がもてます。
話は戻りますが、google様は世界一の広告屋さんですが、クラウドではトップをとれていません。世界の天才達はしのぎを削って、日々戦っているわけですね。
定期実行の柔軟さの点で無料のSaaSではなくレガシー的なサーバーを使った一つの理由です。ALISのシステムは1日に1回動作をさせています。時間はこの集計をみて、もう一個記事を書いてから寝ようと思わせたかったので現在は9時くらいに集計結果が出るようにしました。
定期実行は定番の crontabと呼ばれるLinux標準の機能を使用しています。crontabは柔軟性にとんでおり、定期実行の設定の柔軟さに優れいています。1時間に1回とか何時何分に実行などキメの細かい実行ができる点が気に入っています
1行目は毎朝行なっているコメントランキングと有料記事アップデートの作業です。2行目が本記事で取り上げている、総選挙の実行を命令しています。
それぞれ21時15分と11時37分に実行させています。時間自体は世界標準時間で示されているので、9時間足した時間が日本での実行時間となるわけです。
エラーが発生すると僕にメールが届くシステムとなっています。一種の不幸の手紙みたいなものですね。見るとげんなりするわけです。
これはとあるシステム運用でとんでくるエラーメールの例です。
驚愕の事実ですが、メールボックスを確認してみましたが、なんと総選挙統計のシステムでは運用上のエラーは発生していませんでした。
なんて管理人思いのシステムなんでしょう。
実はこれには理由もあって、ALISからのAPI取得でのエラーはあまりおこらないのです。これもALISのサーバーレスのうまいシステム設計のなせる技でしょう。
30分に一回ピンとピークがでているのは実はマイクリプロヒーローズのシステム動作によるものです。今回の総選挙の統計は、20:30-21:30に掛けた広がる台地のような盛り上がりになります。
マイクリのシステムはある事情で多大なるCPUパワーを消費しますが、今回の総選挙は単純な演算(ただの足し算)とAPIでの取得を交互に繰り返すような構造となっております。
そういえばまた脱線しますが、ALISはAWS上でサーバーレスで動いています。それぞれの機能ブロックごとにサービスを購入し、合体ロボのように組み合わせて運用しています。
いま見ているWEBのフロントエンドで使用するデータ自体もAPIで取得され描写につかわれています。SPA(Single Page Application)の構造を取っており、静的なページデータはほとんど用意されいません。ブラウザ上で最終的に構築される設計です。
その点がよくも悪くも人によってバグが発生する原因にもなっていたりします。静的なページ描写ではない功罪でしょう。
僕の環境は相性がよくほとんどバグりません。下書きが消えたこともないので、きっと運営はMAC BOOKとiPhoneをこよなく愛する人々であると思っています。
そろぞろ疲れたので、続きはパート2にしようと思います。次回はプログラミング編の予定。
ではでは。