あきネット

フリーソフトウェアやオープンソースをはじめ、コンピューターやインターネットに関するTIPSや話題を扱います

北のまちから南のまちへと素敵な何かを届けます。
それは、六花かもしれないし、ナナカマドの実かもしれないし、雪の下キャベツかもしれません。

【にほんブログ村】の調子がおかしい件


常態化していますよね、もう。
そもそも、「障害」が発生していなくとも、動作が重いですし。


障害によって原因は色々異なりますが、基本的には現在のブログ村のシステムが老朽化してしまって安定性・正確性を欠いているのが原因です。


「原因は色々」とかいわれても、ど素人は言われても解らないからって思うでしょうけど、やっぱり、それをぼやかして言わないのはどうでしょうか。なぜ言えないのかって。


私の感覚としては、2011年の震災のときに原発のことも含め、ちゃんと言っちゃう民主党政権みたいなほうが良いんですけど。


・現システムがすでに14年経過して老朽化してしまっている


とたびたび「老朽化」って書いてありますが、


「老朽化」っていうと物理的な老朽化を想像すると思うのですが、
ハードウェアが老朽化したならばリプレイスすれば(買い替えれば)いいわけですし。
そうじゃなくて、旧規格のハードウェア使っているから、いろいろ設計し直さなきゃいけないんですよ、って話かもしれないけど、それもよくわからないですし、


いや、「老朽」というのは、ものの喩えで、実際に朽ちているわけではなくて、


ながいあいだ、
例えば、同じプログラムを改良するために継ぎ接ぎして、性能が落ちたり、潜在的なバグを内包していたり、
ってことなんではないかなあと思うのです。


プログラムのコードってだけのことではなくてもちろん、システム全体の設計とか、サーバ同士のやりとりとか連携とかいう面で、昔の設計をズルズルと付け焼き刃的な更新をしてきたっていうことだと思うのです。


もしかすると、サーバも八王子の村内(社内)に置いてきたのかもしれないですけど、それは私は知らない。


邪推ですけど、Amazon Web Services (AWS)にサーバを移行する心づもりなのではないでしょうか、と、ほんとに邪推。
根拠は、ドメイン運用やblogmura IDで既に AWS 使っているから。



サーバの社内運用のメリットデメリット

サーバを社内に置くべきかどうか、っていう問題(議論)があります。


まず、スタートアップ(ベンチャー)の事業だと、最初は小規模で、初期費用を抑えてリスクを減らそうと考える。
すると、Google Cloud Platform (GCP)とか、 AWS とか、「さくらのクラウド」とかにして、従量料金は割高だけれど、導入費用は少なくて、必要に応じて容易に拡張していける。


ええ、昔は「クラウド」なんてサービスは、なかった。
だから、自社内にサーバ置いても珍しくはないです。
ほかの選択手段として、「さくらインターネット」みたいなところに専用サーバを借りるか、サーバを置かせてもらう(コロケーション)。
「クラウド」みたいな、概念的なサーバ単位が実際のハードウェアと異なり、必要に応じて性能を上げたり下げたり、っていうのはなかったので、ハードウェア自体が固定実体。


そんな時代の名残がおそらく、にほんブログ村にある。


いまでも、事業として確実にやっていけるようになり、規模が大きくなっていたら、GCPやAWSのようなのを使わずに自社に置いたほうがメリットのほうが大きいという話になってきています。
コストもそうだし、メンテナンスのやりやすさもですね。
例えば、大手SNSとか、ネット配信とかにしても、自社内サーバに引っ越しました! ってところが出てきています。


ただ、にほんブログ村の規模は、そんな巨大なところではなくて、売上規模も桁がいくつも届かないレベルではないのかなあと、いう気がします。
そうなると、自社サーバよりも、GCPやAWS、さくらとかに外出ししたほうが、確実なんだろうなあというのが、順当な判断だと考えられます。
また、災害耐性からみても、GCPやAWSのように、いっそ国外に置く選択肢があるほうが確実です。
それに比べれば、かりに八王子に置いたら、立川断層帯がお怒りになったら終わる可能性があります。
さくらの石狩データセンターですら、北電大停電でかなり苦労したわけですし。
東京なんか正直に言って災害に対してきわめて脆弱だと私はみていますし、ましてや豊洲市場なんか(以下略)


ほんと、いまは、有名なサービスでも、GCPやAWS使っていて普通です。某ソーシャルゲーム業者がゲームサーバにAWS使っていたりとか。
さらにいえば、ウェブサイトも、Cloud Flare みたいなCDN(コンテンツ配信ネットワーク)を利用していても普通です。角川の誰かが世迷い言を言ってデマで煽ったりしましたが😁 実際にはCDNは普通です。


blogmura.jp. 60 IN A 54.230.108.164
164.108.230.54.in-addr.arpa. 86413 IN PTR server-54-230-108-164.nrt53.r.cloudfront.net.



ほら、AWSのCDNでしょ😁



さて、

この秋からは皆さまには見えないシステムの裏側で順次、安定性や正確性が高い新システムに置き換えを開始いたします。

※すでにデータベースなどかなりの部分が水面下では切り替わり始めています


段階的に切り替えてトラブルを減らすというのはかまわないのですが、
切り替えがうまくいかずにサーバ間連携がおかしくなったりしていることって、起こっていませんかね?


ぼーっと眺めていたんですが、


$ drill blogmura.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 37196
;; flags: qr rd ra ; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; blogmura.com. IN A


;; ANSWER SECTION:
blogmura.com. 600 IN A 124.35.211.3
blogmura.com. 600 IN A 124.35.211.16


って、IPアドレス2個振って負荷分散をしているんでしょうし、立派だと思うんですけど、なんかあって連携がうまくいかなかったときにそこから綻ぶんですよねー


難しいなー(他人事?


先日のメールの話

blogmura.com. 600 IN MX 10 mosgw00.biglobe.ne.jp.
mosgw00.biglobe.ne.jp. 10800 IN A 133.205.22.98


@blogmura.com の受信サーバはBIGLOBE(NEC)なんですよね。


けれど、送信がBIGLOBEではなくて、 mx11.blogmura.com [124.35.211.60] から出ていたんですよ。


担当者はなんか、SPF を誤解しているのかな。それとも設定追加の失念かな。



多少詳しい人でないとチンプンカンプンニントモカントモニンニンな話でごめんなさい。