ウェブサイトの復活! (その1)

サイトクラッシュ

このサイトは、ある時に突然閉鎖となった。原因はSSD のクラッシュ。最近はクラウド環境も一般的になり、以外とシステムダウンを忘れがちだが、忘れた頃にやってくる・・、それも突然のシステム障害である。この時は、他にもいくつかサイトを管理している関係から優先順位で復旧が後回しになり、そしてやっとこの時期になった。この復旧のきっかけになったのは、以前にこのサイトを紹介した方から、内容が面白かったとのコメントを戴き、これは不味いということで、動くキッカケとなった。

復旧(Recovery)

ウェブサイトを復旧させるには、バックアップのデータが必要になる。ご存知の方々も多いと思うが、WordPress はWeb サーバとデータベースサーバから構成されている。この2つのサーバのバックアップデータは、プラグインを導入することで自動でコンテンツ及びデータベースを纏めて一つのファイルにする機能がある。更に、指定の時間に自動でバックアッブをとるような設定もできる。何事にも無精な自分には、実にありがたい機能である。今回は、このデータからサイトを復旧(Recovery)する。クラッシュと思われるSSD から、バックアップデータを取り出すことができたのは幸運である。今後は、このデータは別に保存しておくことにしたい(当たり前のことなんだが・・・)。

折角の機会なので、WordPress は最近トレンドのコンテナで組み上げてみた。サイトの障害時の相互の影響を防ぐ、あるいは一つ一つの仮想化マシンがシンプルであるとの観点から、最近ではこの方式を採用している。コンテナ環境への移行については、多少の壁はあるものの、さほど苦労はしなかった(少しは成長している・・・)。コンテナ環境は、一つのコンテナに一つのプロセスを稼働させるのが基本であるので、今回のWordpress 復旧においては、2つのコンテナを作動させるようにして、それを内部のネットワークで接続した。順調に構築できているので、もっと早くに復旧すれば良かったと思いつつ、このサイトのモットーであるハマりは何処に行ったのか・・・、と嬉しい悲鳴である。

Reverse Proxy 構成

折角の再構築なので、様々な障害時でも業務継続が容易な構成に以前より注目していたリバースプロキシ方式に今回はチャレンジしてみた。つまり、Web サイトの基本構成をローカル(Backend) に持ち、それをインターネットのクライアントからフロント(Frontend) を経由してBackend に接続するという構成である。

これが、なぜ業務継続にメリットがあるかというと、Backend に複数のサーバを持っていれば、仮に一つのサーバに障害があっても設定一つで他のサーバに割り振ることができる。つまり、サーバがクラッシュした場合でも、バックアップサーバをBackend に何台か持っておけば業務継続にある程度対応できる。サーバがダウンしたからといって、管理しているこっちまでダウンするリスクを下げることができるのではないかとの期待感が持てる。では、Frontend に障害があった場合についてどうなるかというと、そこはkeepalive を使った二重構成にしておけば良い。Backend のサーバを複数台準備できれば、Frontend にロードバランシング機能を持たせることにより負荷分散にもでき、そうなるとBackend サーバがダウンしても自動で業務を継続できるという素晴らしい構成である。複数台のサーバといっても、コンテナの仮想環境を使えばサーバ構築にはそれほど投資の必要はない。将来が期待できるこの環境を、「Tokky’s Local System Ver.1.0」として、レジリエンス機能を充実させた今後の発展を楽しみにしていきたい。名前倒れに・・なった時は、また弁明の記事をアップすることになるだろう。さて、動作原理も代替把握できたので、早速設定にかかる。

というところまでは割と順調だったが、いざ設定という段階になって全くと言っていいほど動作しない💦。ハマりの始まりである。結局のところ、そうなる・・・。Frontend はどのような働きをして、そもそもそこに流れる情報はどのようなものがあり、それを可視化しないと問題の根本が理解できない。ということで、キャッチの写真にもあるとおり、パケットを逐一監視する羽目になった。何が悪いのか皆目検討がつかない中、頼りのChat GPT を駆使しつつ問題を一つづつ特定し、対処の繰り返し。Frontend とBackend のデータの状況から必要な内容をFrontend で書き換えていく地道な作業だが、Cookie の設定が鍵だったりと様々な問題は容赦なく襲ってくる。こんな過酷なことをなぜする必要があるのかとの自問自答しながらも、この環境には慣れるしか無い。完璧の段階までは中々辿り着けないが、これにも慣れねばならない・・・。概念は素晴らしくても、いざ実装となると個々に目的や環境が違う。それらには都度対応させる必要がある。そこは、中々AI の時代と謂えどもまだ人が介在する必要がある。それでも、何とかWeb サイトの閲覧までは出来るようになった。編集も出来はするものの、一部の機能は動作せず直接Backend にアクセスして当面、回避することとした。完全なる編集機能については、今後の課題としたい(想定内かも・・・)。

問題点

このサイトが現在運用されている環境であり、閲覧については今のところ問題ない。しかしながら、今回は編集機能について課題を残した。一部の機能に不具合があり、特にファイルのアップロードで問題が生じているところまでは突き止めた。更に、特定のファイルの実行にfrontend が他のサーバのポート番号をBackend に振ってしまうという問題も分かってきた。とりあえず、当面は不具合対策としてBackend に直接接続して編集作業を実施しつつ、今後は問題点を追求して、一通り使えるようにしたいと考えている。併せて、バックアップ/負荷分散用サーバも立ち上げ、Frontend をロードバランサにして構築にチャレンジ(Ver.2.0) したい。時々Reverse Proxy の構築はこの通りにすればできるような記事を目にするが、それは特定の環境であって、例えばディレクトリでサーバを分けるような構成では上手くいかないのではないかと感じている。四の五の言わずに、まずは自らが問題解決に努力したい。

教訓

• 以前から注目していたReverse Proxy でのWeb サーバの構築について、あれこれ考えるよりも、まずは手を動かすことが重要である。
• Chat GPTや他の生成型AI を駆使することで構築はかなり早くなった。以前であれば半年以上掛かっていたものも、数日のハマりでここまで来れた。だが、Chat GPT は万能ではないことも今回の教訓である。どう使っていくか、使い方が肝だと思う。
• 今回の構築中にも、インターネットが一時中断した。バックアップルータもあるが、そちらからも接続できなかったので、多分もっと上の方の問題ではなかったかと思う。バックアップ系のシステムはとかく手を抜きがちだが、気づいた時に対処しておいた方が後で大きな被害を受けずに済む。災害対策と同じで、リスク管理の認識を常に持っておく必要がある(これが出来ていない・・・)。

さて、一通りここまでで区切りをつけてYoutube を見ていたら、WordPress を使ったWeb サーバの構築記事に目を留めた。WordPress の立ち上げは一瞬で完了し、コンテンツやデザインについての情報発信の内容が圧倒的に多い。つまり、この数日間の努力は、Youtube では一瞬の価値しかないことに愕然とした。人生こんなものだと・・・、これにも慣れていかねばならない。