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

地獄の数週間

前回このサイトの復活をアップしたのが2024.2.11だった。約1ヶ月の間、どこをどうすれば良いのか、皆目検討もつかないままに時間だけが過ぎていった。ハマりの一番嫌なケースである。今までリバースプロキシ構成にチャレンジしてみたいと思っていたこともあり、閲覧の方は特に大きくハマることなく構築できた。しかし・・・、管理モードになってコンテンツの追加や修正を行う時に、所々機能しない。機能しないどころかアクセスすらできない状況にもなった。その1では深みにハマるのを恐れて、一旦閲覧までで纏めた。そうは言いながらも、この不具合についてはChat GPT を使いながら状況に応じて一つづつ潰していけば良いと考えていた。が、これは甘かった。深みにハマると途中で状況を整理して、総括的な観点から再整理するタイムが必要だった。この繰り返しで、何とか管理モードでも動くようになった。とりあえず、ここにその概要をまとめておきたい。

諸悪の根源

リバースプロキシ構成にすると、実際にウェブサーバにアクセスするクライアント、それをインターネットから受けるフロントエンド、そしてその奥に設置してあるウェブサーバとしてバックエンドの大きく3段構成になっている。ここまでは、その1でも紹介した。従って、バックエンドをインターネットからアクセスできるようにするには、フロントエンドで双方向に流れる情報を必要に応じてそれぞれのアクセスに見合うようヘッダー情報とテキストベースの情報を変換すれば良い。原理は単純で、クライアントからの閲覧は問題なく出来るようになっていた。

同じようにバックエンドに管理者モードでログインして、コンテンツの管理を実施する場合、原理は同じだから大量の情報から一つ一つ書き換えていけば良く、Chat GPT の力を借りて時間が解決する問題と軽く考えていた。が、しかし、、書き換える情報の通過が確認出来ない上にクライアントからは別のサイトにアクセスを試行してくる。可怪しい・・・。Chat GPT に色々聞いてみるが、何しろ状況を説明するのが困難で何がどう可怪しいのか、それが分からないから困っている現実がある。ここで無駄に時間を費やすことになる。GPT とあれこれやりとりをしながら分かってきたことは、WordPress はURL を決めるのに、ヘッダー情報だけでなく、PHP やJavaScript を使っていること。流石はGPT、WordPress のソースを読んでるな、ということが感じて取れる。凄い・・・。という訳で、PHP はサーバサイド動き、多分結果を文字ベースで流してくるからフロントエンドでの対処が可能と思料できる。問題は、クライアントサイドで動くJavaScript である。スクリプトがバックエンドからクライアントに送られて、クライアントで処理した結果でフロントエンドにアクセスすることになる。つまり、フロントエンドの知らないところで追加することになり、図に表すとこんな感じになる。可怪しな動きをしている原因の当たりがついた。諸悪の根源はここか・・・。ここに辿り着くのに2~3週間を費やした。時間と気持ちの余裕と想像力がないと、辿り着けない。多分、閲覧の方はルールに従った洗練されたスクリプトになっているが、管理者モードの方はまだまだ発展途上ということなんだろう。ハマる沼という雰囲気がプンプンしてくる。

対策

さて、原因が分かったので、あとは対策だ。そもそも、変な動きをした時に、どこの情報が悪さをしているのか、それをまずは見つけなければならない。管理者モードでログインして、可怪しい動きは分かる。問題は、どこが引き起こしているのか。現象を追いかける必要がある。ただ動きが可怪しい状況だけを追っても、精神的に追い詰められるだけなので、まずは見える化をしないといけない。

見える化といっても、構成が少し複雑になっていることから、この図に示すように状況が分かるところに片っ端からツールやコマンドなどを使いながら監視することにした。使い慣れないものもあり、設定や使えるまでに時間を費やしたのも事実である。こんなことやってる場合ではないが、、仕方ない。前の図を見ても分かる通り、このシステム構成ではバックエンドに直接接続するクライアント#2 も設けてある。つまり、Internet からだけでなく、Local Net からも接続できるような仕様に拘った。これは、一見簡単そうに見えるが、実はバックエンドには接続するクライアントがInternet かLocal LAN かの接続の違いを認識させておかねばならない。面倒ではあるが、不具合を切り分けるのにはとても意味がある構成である。こうして動きが可怪しくなった時に、切り分けとそれぞれの監視情報からJavaScript が関与しているかどうかを確認(想像)して、所要のスクリプトを変更する。WordPress は柔軟に手を加えることが前提らしく、PHP にしてもJavaScript にしてもカスタマイズし易い構成になっている。ただし、WordPress の流儀があり、それに従った要領で基本的にスクリプトを書いていくが、変更した箇所の効果がどのように効いているかを確認するには、勘も必要になってくる。勿論、中には流儀に従わないスクリプトもあり、そこは直接スクリプトを追加する。実際に取り掛かると、一箇所の修正が色々なところに波及してしまい、修正した部分が新たな不具合を呼び起こすことも多々あった。これまで動いていたところが、いきなり動作停止になる。モチベーションの上下が半端ない・・・。お手上げ状態な時には、少し状況を整理してスクリプト弄りからフロントエンドで処置することで片付いてしまうことも多々あった。コーヒーブレイクの価値は、ここにある。気を取り直して別の手段で解決させるという発想が必要だと思う。GPT を信用し過ぎるとハマりから抜け出せない、ここは人間の得意とする俯瞰してみることだと再認識した。WordPress は不具合が生じた時にエラーのある箇所を明確に示してはくれないため、想像力を働かせて各種監視データと過去実施した事項を常に照らし合わせて置く必要があるが、一旦リダイレクトループに陥ると直ぐに原因に辿り着けない。こうなるとウェブサーバのアクセスログやエラーログも見ておく必要がある。

振り返って

今回は、元々運営していたこのサーバの復活が目的で、そのタイミングでリバースプロキシという新たな構築にチャレンジした。実は、単純にリバースプロキシでの運用といっても、ドメイン単独での運用、ドメインのサブディレクトリでの運用、サブドメインでの運用と運用形態も様々で、個々に設定の仕方が異なってくる。特に、サブディレクトリでの運用は厄介であり、リダイレクトループに相当悩まされた。新たなドメインやサブドメイン取得による方法と比較してDNS の設定や証明書の取得等の必要は無いが、システム側の設定がより複雑になる。何よりも、自分が今何をしていて、それがシステムの動作にどう関係してくるかを想像し認識しておかねばならない、というグレーなこの一ヶ月だった。これを棚上げしてしまうと、問題点を忘れ、システムのバージョンアップなども伴い環境そのものが変わってしまうので、問題はお蔵入りとなってしまうだろう。それでも良かったかも知れない・・・。ところで、WordPress は管理モードを除けば割と簡単にリバースプロキシで運用できたことから、管理モードについてはSSH でポート転送をかけてLocal Net からアクセスする方策もある。それもあって、どうしても上手くいかない場合を想定してその手を考えていた。Client #2 の仕様に拘っていたのは、そのためでもある。その方が、少し面倒ではあるがセキュリティの強度は上がるだろう。今後、WordPress のバージョンアップに伴い、内部の構成が変わった時には迷わずその道を選択することになると思う。今回の成果から、Internet から接続できない設定に予めしておいて、SSH での接続という裏技もできるだろう・・・多分。こんな発想の方が面白い。

教訓

• リバースプロキシ運用における管理モードでの対応が一通り出来た。様々な要素が関連しているので、良く整理しておく必要がある。
• Chat GPTやメジャーの生成AI はインターネットを学習しているので、特にオープンソースのシステムに詳しい。オープンシステムの方がAI との親和性が高くトラブルの対応は早いかもしれない。これからのトレンドになるだろう。問題なのは、システムの不具合の状況を良く観察してからでないと、Chat GPT に聞いても関係ない回答が帰ってくる。動的解析のセンスが必要である。
• その1 でも言及したが、システムの安定的な運用はありえない。常にバージョンアップで変化しているものを安定的に運用するには、常にバックアップが重要であり、常に運用状態であるホットスタンバイの状況が必須である。それに近い構成なのが、リバースプロキシ構成であり、今後はロードバランサにして自動で業務を複数のサーバに振り分ける構成が有効だが、今回はその基礎的な機能が確保できたことになる。

Youtube ではWordPress の立ち上げは一瞬で完了しているが、たったここまででも自分には長い道のりだった。まだ先は長いが、どこで手を休めるかを個々に判断することも重要である。思ったとおりに事は運ばない。自分だけ時間が止まっている感じだが、常にレジリエンスの発想で、優先順位を念頭に渡り歩く必要性を痛感している。ハマりに一喜一憂している場合ではない。