過去のブログを掘り起こして、当時分からずじまいだったことをAIニイの力を借りて解決していくシリーズの2回目。
第2回目は、2012年2月11日の内容です。懐かしいね。
そうでもないねー。
OpenFlowという技術への言及と、WordPressを2台のVPSに分散しようとして失敗した話。ひとつずつ片付けていくのだ。
OpenFlowの話
OpenFlowについて当時の自分なりの解釈がこれ
「ナビを見たら○○インターまで渋滞らしい、この時間帯はしばらく混むから、次のインターで降りて○○までは下道で行かない？ 」
「そうだね、そのまま下道で行って、○○インターから入れば一番早いんじゃないかな？」
「いいね、そうしよう。」
再調査した感じ、まぁだいたい合ってたぽい。
OpenFlowというのはSDN（Software Defined Networking）を実現するためのプロトコルで、ネットワーク機器の頭脳部分（コントロールプレーン）とデータの転送部分（データプレーン）を分離するというものだ。
従来のルーターやスイッチは「自分で考えて自分で転送する」という自律分散型だった。OpenFlowはそれを「考える係」と「転送する係」に分けて、考える係をソフトウェアで一元管理しようということのようだ。
カーナビの例えで言うと、従来型は各ドライバーが自分でルートを考えていたのが、OpenFlowでは交通管制センターが全車両のルートを一括で最適化する感じ。
その後OpenFlowというかSDN自体はクラウド基盤やデータセンターでわりと当たり前の技術になったとのこと。
AWSやGCPのネットワーク仮想化の裏側にもこういう思想が入っているようやね。14年たった今ではクラウドの裏側で普通に動いている技術になってたわ。
WordPressのDNSラウンドロビンの話
2台のVPSにWordPressを分散しようとして、記事の番号がずれてしまい企画倒れになった話。知識がなかったとはいえ、えらい大変なことやってたな。でもその勢いというかエネルギーはすごいどん。
なんで記事番号がずれるのか。
WordPressの記事IDはMySQLのAUTO_INCREMENTで管理されている。2台のデータベースが独立して動いているので、1台目で記事を書いたら1台目のIDが採番され、2台目で書いたら2台目のIDが採番される。
つまり同じIDの記事が2台に別々の内容で存在するという悲しみが生まれる。
VPS1: 記事ID=100 → 「Linuxメモ」
VPS2: 記事ID=100 → 「プラグイン追加した」
DNSラウンドロビンはリクエストを2台に振り分けるだけで、データベースの中身は同期してくれない。そりゃそうだ。
WordPressを冗長化しようとすると、データベースのレプリケーションやセッション管理や画像ファイルの共有など、考えることが山積みになる。「WordPressはDNSラウンドロビンには向いてない」というのはそういうことだ。
確かこの当時から何年後かにDBを冗長化する記事を書いてプチバズりしたのだった。
正直冗長化するならフロントじゃなかね〜？
「三度の企画倒れ」とか書いていたが、これは構造的に無理な話だったのだ。