これは番外編です
これまでの連載では、構築の中で実際に起きた「罠」や「事件」を中心に書いてきました。今回は少し違う切り口で、このブログ自体がどういうシステム構成で動いているのかを、インフラ屋らしくきちんと解説しておこうと思います。
長年この仕事をやってきて、「システム構成図を描かずに人に説明する」というのは落ち着かないものです。ここまで読んでくれた方の中にも、同業の方がいれば「結局、何がどう繋がっているのか」を知りたいはずです。
全体構成図
まず、ここまでで組み上げたシステムの全体像を1枚にまとめました。
図の右上、太い枠で囲ったところが、このブログの実体であるオリジンサーバーです。そこを中心に、ドメインの管理、リクエストの経路、バックアップ、メール、アクセス解析という5つの役割が、それぞれ別のサービスに分散しています。
なぜこの構成にしたか
レンタルサーバーを起点にした理由
自前でクラウド上にサーバーを構築する選択肢もありましたが、今回は国内のレンタルサーバーを選びました。理由は単純で、WordPressの構築・運用に関する枯れた機能(バックアップ、SSL、簡単インストール等)が最初から揃っていて、AIエージェントが操作できるAPIも用意されていたからです。長年、必要な機能をゼロから構築するのが仕事だった身としては、「既にあるものを組み合わせる」判断は最初は少し物足りなく感じましたが、今回はスピードを優先しました。
ドメインの管理とネームサーバーを分けた理由
ドメイン自体はレンタルサーバー側で取得していますが、実際のDNS管理・SSL・CDNの役割は別のサービス(Cloudflare)に委ねています。これは「所有」と「実際の運用」を分離する考え方です。ドメインの契約自体はサーバー会社に依存していても、通信経路の制御は別の場所に持たせておくことで、将来サーバーを移行する際にも通信経路側の設定を大きく変えずに済みます。この判断は、これまでの連載(第1回)で触れたSSL自動設定の罠にも繋がっている話です。
バックアップを二重にした理由
サーバー会社が標準で提供している自動バックアップだけに頼らず、別のクラウドストレージにも定期的にバックアップを送る構成にしました。同じ会社の中に閉じたバックアップは、その会社自体に何かあった場合に機能しません。「バックアップ先を、本体とは別の管理主体に置く」というのは、長年の運用経験からくる、割と譲れない部分です。
メールとブログ本体を分離した理由
お問い合わせフォームで使うメールは、ブログのサーバーとは別のクラウドサービスで管理しています。ブログのサーバーがメールサーバーの役割まで兼ねると、片方の不具合がもう片方に影響しやすくなります。役割ごとにサービスを分けておくと、何かトラブルが起きたときに「どこで起きているか」の見通しが良くなります。
全部を自分でやらない、という判断
今回の構成で意識したのは、「全部を自分のサーバーの中に抱え込まない」ということです。バックアップも、メールも、アクセス解析も、それぞれ専門のサービスに任せる。これは決して手抜きではなく、餅は餅屋という、長年の運用経験からくる判断です。
もちろん、サービスを分散させると「どこで何が起きているか」を把握する手間は増えます。ですが、1つのサービスにすべてを依存させるリスクよりは、この方が安全だと今回は判断しました。
一つ、公開する情報について気をつけたこと
余談ですが、この構成図を作る過程で、使っているソフトウェアの具体的なバージョン番号を入れてしまっていて、後から気づいて削りました。バージョン番号は、脆弱性情報が出た瞬間に「狙われるかどうか」の判断材料を攻撃者に渡してしまいます。技術ブログとして具体的に書きたい気持ちはありますが、ここは自制するところだと思い直しました。長年インフラをやっていると、こういう「見せたい情報」と「見せてはいけない情報」の線引きは、つい忘れそうになった頃にハッとさせられます。
おわりに
今回は番外編として、システムの全体像を整理しました。次回からは、また実際に手を動かした記録に戻ります。
コメント