AWSで運営しているDrupalのサイトが、今年の12月でLTS終了となるので、サーバー移転により対応しました。
利用サーバーの制約により、システム要件が満たせず、アップデートに限界があり、Drupal 10.6.12で運営していますが、2026年12月でLTS終了となります。Drupal 11.x以上のバージョンに対応したサーバーへの移行を行い、Drupal 11.xにアップデートすることでLTSの終了に対応する必要があります。
当初は、サーバーにインストールしている、Drupalの移転を考えていましたが、サーバーでの運用を辞めて、DrupalをMacBookProで動かし、静的ファイルに変更を行い、CDNを使いWebサイトを公開する、『Jamstack』と言われる形に変更して公開しています。
今回は、Jamstack化を行った経緯などについてまとめています。
DrupalやAWS、Jamstackといった技術的な記事になり、Hooked-onには直接関係のないテーマの記事になっていますが、今回の移転作業やJamstack化に1月以上の時間を取られてしまい、Hooked-onの更新が止まっていたので、その経緯をまとめた記事になります。
今回、移転を行った姉妹サイト『Interset』はDrupalで構築しており、Drupalの特徴である、サイト内動線の使いやすさを利用し、記事の逆引き的な要素を持たせています。今後、見ていただいた方の、使いやすいインターフェースの選択種として当サイトとクロスした利用を出来るように進めていきたいと考えています。
- 今回の移転を行ったAWSに構築した姉妹サイト [ Interest ]
- Jamstack化に関する記事 [ Drupal with Jamstack ]
Lightsail + Bitnami + Drupal
AWSのVPSであるLightsailに、Bitnamiが設定の最適化をしたDrupalをインストールしたパッケージを使い、Drupalのサイトを運営していました。これはブループリントと言われる、VPSプランで、OSとCMSがパッケージされたプランになります。『Xserver VPSのOS、アプリイメージのプランでDrupalを選択した形に近いサービスです』
Drupalを動かすためのサーバー設定の最適化をBitnamiが行っているので、サーバー契約その日からDrupalが利用できるプランであり、初めてDrupalを使ってみたい方や、大規模ではないWebサイト構築にDrupalを利用する個人や会社など向けにAWSが用意したプランになります。
非常に手軽にDrupalを利用できるので、私も利用していましたが、一つ問題があり、その問題をクリアする必要があります。その問題とはサーバー設定の最適化をBitnamiが行うことで、PHPやDB、ApacheなどのアップデートはBitnamiが責任持って行います。この運営ポリシーは非常に優れており、親切な設計となっていますが、ユーザーがここに触れることが出来ない設計になっています。『PHPやDB、Apacheなどのユーザーによるアップデート』はプランのサポート対象外となっています。
Drupalのメジャーアップデートを行う際、システム要件がアップデートされると、PHPやDBのバージョンをDrupalのシステム要件に合わせるために、アップデートする必要があります。Bitnamiの設計と運営思想は、既存のLightsailとBitnamiのパッケージプランでシステム要件やDrupalをアップデートするのではなく、Bitnamiがシステム要件に対応しDrupalのメジャーアップデート版をインストールした新しいプランに載せ替えを行うことで対応しています。
この設計思想は、理にかなった、考え方で、既存のシステムを止めずに、新しいシステムを立ち上げ、準備が出来たら切り替えるという、最近のクラウドと仮想サーバーの利点を活かした設計になっています。
実際に、新しいサーバーに、既存サイトを載せ替えるとなると、結構面倒なので、（実作業というより、データ移行の準備や確認方法などを調べ、テストで移行のプロセスを簡単にシュミレーションするなど）つい先送りをしていました。
2026年6月時点で私の環境は以下の形になっています。
既存のLightsailとBitnamiの環境
- PHP 8.2.xまで – Drupal 11.xは8.3.x以上 8.4.x以上を推奨
- MariaDB version 11.x まで – DBはDrupal 11.x移行のシステム要件をクリア
- Drupal 10.xまでのシステム要件に対応 – PHPのバージョンによりDrupal 11.xには非対応
Drupal 10の最新版である Drupal 10.6.12で運営しています。
現状のサーバーでは、Drupal 11.xに対応するにはPHPの必須要件を満たしていないので、PHPをアップデートするか、対応したパッケージに移行する必要があります。先に述べたように現状のLightsailとBitnamiのパッケージではPHPの制約により、Drupal 11.xへのアップデートは出来ません。アップデート用に用意された最新環境であるLightsailとBitnamiのパッケージ『Drupal 11.3.9のプラン』を選択し、移行する必要があります。
ブループリントの終了
ここに来て、LightsailとBitnamiのパッケージに新たな問題が出てきます。その問題とは、LightsailとBitnamiの関係が解消され、これまで、サーバーインフラのメンテナンスやセキュリティ対応をBitnamiが行っていましたが、2026年5月19日以降、Bitnamiのメンテナンスが終了し、サーバーインフラのメンテナンスやセキュリティ対応をユーザーが自己責任で行う必要があります。
この決定は、Drupalに限らず、他のOSとCMSやフレームワークをパッケージングした『ブループリント』と呼ばれるプランをLightsailが辞めてしまい今後のサポートを行わないといった発表となっています。
最新のDrupal環境であるLightsailとBitnamiのパッケージである『Drupal 11.3.9』が用意されていますが、これも2027年5月には、サポート終了になります。このような状況なので、LightsailとBitnamiが用意するパッケージの最新版に移行して対応するという選択種は事実上無くなってしまいます。
代替案として、企業案件などで採用されている、AWSのEC2とRDSにDrupalをインストールして運営を行うというスタイルもあります。メリットとしてはDrupalの機能や性能を本格的に活かすことが可能となりますが、それと引き換えに運営に関わるコストや手間が、個人のブログ向きではなくなり、管理も面倒になってしまうというデメリットがあります。
もう一つの選択種として、Drupalを使用し始めた当初から構想にあった、DrupalをWebに置かず、MacBookProでDrupalを動かして、静的ファイル化（html化）を行い、公開はCDNを使って行う、『Jamstack』というスタイルに変更するという選択種も現実のプランとして選択種に上がります。
- LightsailとBitnamiの最新パッケージDrupal 11.3.9に移行 — 事実上消滅
- Drupalの本格稼働を考え、EC2(Webサーバー)とRDS(AWSの専用高機能DB)への移行。高性能なインフラとなり、規模によってはエンタープライズクラスの対応も可能 —個人のブログ向きではないので断念
- 過去に一度検討した、DrupalをWeb上に持たず、静的化したファイルをCDNを使って公開するJamstack化を念頭に置いた移行 — これを選択
2026年5月19日を過ぎてしまっているので、セキュリティ面などを考え早急に移行を進めます。
Jamstack
Web関係の仕事をされている方で、フロント系エンジニアと言われる、デザインを含めたWebサイトを担当するエンジニアの方の間で、ここ数年のトレンドになっている、Jamstackやヘッドレスという言葉があります。
Jamstack（ジャムスタック）とは、JavaScript、API、Markup（マークアップ）の3つの技術要素を組み合わせてWebサイトを構築するアーキテクチャ手法です。WordPressなどの従来型と違い、あらかじめ生成された静的ページをCDN経由で配信するため、高いセキュリティと超高速な表示速度を実現します。 — Geminiより引用
Jamstackやヘッドレスというと、Next.jsやReactを使いAPIでCMSのデータを取得し、再構築して公開する形が主流であり、今回のようなDrupalを静的ファイル化してCDNで公開する方法は少数派です。
海外では『Static Drupal』と言われています。
Jamstack化のプロセス
- Mac Book ProにOrbstack（ローカルサーバー）、DDEV（コンテナ）、Drupal（CMS : Webサイト構築）、Tome（静的ファイル化）をインストールし、Mac Book 内でWebサイト構築を完結しています。
- AWS LightsailにWebサイトを配置します。（定番であるS3ではない選択）Lightsailは、ApacheとSSH（sFTP）のみを解放しています。（静的ファイル配信用の設定）
- LightsailにPHPやDBをインストールして動かす必要がないので、セキュリティや負荷の軽減につながっています。
- AWSのCloud Front（CDN）を設定します。SSLはACMで設定し、ドメイン管理はRoute53を使います。
- Lightsailは、Cloud FrontのIPのみを許可するIP制限を設定します。このことでS3の特徴である、内部ルーティングによるセキュリティの担保（外部からは見えない設定）と近い設定になっています。
- コンテンツのデプロイは、Macから直接LightsailにsFTPを使いアップロードしています。この作業は、Transmitを使い、『GUIによるコピペ』で行っています。（主流のAWS CLIやGitでのデプロイを未選択）
- sFTPとSSHは鍵認証とIP制限をかけていますので、私のMacBookPro以外からのアクセスは出来ない設定を行っています。記事の更新やサイトの管理は全てMacBookProで行い、公開をsFTPでのみ行うことで『CMS必須のWeb上の管理ツールにログイン』というプロセスに比べセキュリティリスクが低くなっています。
上記のプロセスで、これまで、Web上のDrupalを使い、サイト構築と公開を行っていた形から、MacBookProのDrupalでサイト構築を行い、html化を済ませ、sFTPのコピペでサイトをアップロードし、公開はCDNで行う、非常に簡素化したJamstackのプロセスが完成します。
Jamstackのメリット
- Drupalをローカルに設置することで、セキュリティに関わる管理から解放されます。
- ローカル上でDrupalの複製は容易なので、デザインや設定の実験を好きなだけ行い、最悪壊してしまっても影響がない環境になっています。
- Drupal 11.4.0のアップデートで実際に起きた、環境によっては、サイト表示が壊れてしまうようなエラーが発生しても、ローカルなので公開に影響しません。
- サイトの公開は、AWSのCDNで行い、WAFのオプションもついているので、配信の速度とセキュリティの高さは世界最高レベルとなっています。
- ページ構成が全てhtmlとなっており、オリジンサーバーであるLightsailは実質ファイル置き場としての使用で、プログラムやDBをインストールしていないこと、外部からのアクセスはCDNのみの設定を行うことで、セキュリティ管理や、負荷の管理から解放されています。
『Jamstackのメリット』である、『高速化』と『高いセキュリティ』に加え、ローカル作業の比率が増えたことで、『管理の簡素化』や『リスク軽減』を実現しています。
原点回帰
今回、キャッシュ機能を使い高速化した公開方法であるCDN、大手プラットフォームが管理し最新の脅威をブロックするWAF、コンテンツを配置するサーバーを、公開せず内部ルーティングで処理（サーバーレスという概念）など現代のWebサイトの公開に最適化された技術を選定しJamstackによるWebサイトの公開を実現しています。
2020年代の技術で構成したWebサイト公開プロセスが、結果的に、パソコンでホームページを作成し、FTPソフトで、プロバイダーが付与したホームページスペースにホームページをアップし公開していた1990年代後半のホームページ公開のプロセスと同様になった事が時代は周り原点回帰したと感じています。
- 1990s ホームページビルダー — 2026 Drupal
- 1990s FTPソフト —2026 sFTPソフト
- 1990s プロバイダーのホームページスペース — 2026 AWS CDN
紆余曲折を経て、やっていることが30年前と実は大して変わっていなかった！と気がついた出来事でした。
おわりに
2年前にDrupalの学習とAWSを使ってみたいと考え立ち上げたDrupalのWebサイトですが、AWSのインフラ環境の再編により、プラン変更の必要が生じ、サポート期限が過ぎてしまったことで、突貫で作業を進めています。
AWSのプラン変更や、実装自体は、数時間の作業ですが、初めて行う公開手順の根本的な変更と、インフラの変更なので、実作業より、何を選択して、何をどう使うかという、インフラ環境の選定の精査に時間がかかっています。
Jamstack化とともに、移転の機会にと考えていたデザイン変更や、翻訳のネイティブ化なども同時に進めたので予想外に時間がかかってしまい、サイトの更新が止まってしまいました。
昨今、AIの普及で、セキュリティホールの発見スピードが進むのは良い事ですが、悪用した攻撃ツールも異例のスピードと量産体制が進み、Webサイトを運営するリスクが以前と比べ格段に上がっています。今回行ったJamstack化は、Webサイト運営のリスクを減らす選択種の一つでもあります。
現在の環境は
- Xserverビジネススタンダード — 『WordPress & Drupal』
- AWS — 『Jamstack化したhtml』
以上のような形になっています。
Xserverビジネススタンダードは、パッケージ化されたサービスで、CDNもWAFも標準で搭載されており、IP制限などのセキュリティ対策も簡単に設定できます。運営に関わるセキュリティ管理やパフォーマンス性能の実践はユーザーに委ねられていますが、インフラの基本的な性能の保証とセキュリティ対策は、Xserverが責任を持って管理しています。
そのことでWordPressやDrupalの稼働は、ユーザーサイドで行うアップデートなど基本的な対応をしっかり行なっていればセキュリティ対策やパフォーマンス劣化の対応などに気を取られず安心して運営に専念できます。
AWSの基本的な環境は、エンタープライズクラスのサービスを提供できる、高性能で機能別に特化された各インスタンスが用意されていますを。プロジェクトに関わる必要な機能を選び、専門家が精査し、目的に応じた設定を行い、最適な組み合わせで構築することが前提となっています。
各インスタンスの性能保証や、セキュリティ対策はAWSが責任を持って管理し、動作の保証もしていますが、利用者が、組み合わせを選択し独自の設定をすることが前提のシステムなので、システム全体のセキュリティ対策やパフォーマンス性能の管理は利用者に委ねられています。
サービスが終了してしまう、ブループリントのプランは、Xserverと同様なサービスでしたが、現在、AWSのインスタンスを自身で選択し運営することで、セキュリティやパフォーマンスは自己責任において管理しています。
個人のブログ公開という目的に応じた、最低限必要なシンプルな構成を選ぶことで、管理を単純化しています。
今回作業を行い、感じた事ですが、現行のインフラをスポーツカーやレーシングカーに例えてみます。
- 『Xserver』は『日産のGTR』や『ポルシェ911』のような、自動車メーカーが全てをパッケージしたスポーツカーのようなシステム構成
- 『AWS』はワークス体制で作られた、完全プロ使用の『F1マシン』や『ルマンのLMP1(現在はハイパーカー)』のようなシステム構成
- 『今回構成したAWSを使ったJamstack』は、英国のバックヤードビルダーが作ったハンドメイドのレーシングカーのようなシステム構成
今回行った、DrupalのJamstack化は、ひと昔前の英国のバックヤードビルダーがコスワースのエンジンを買って、レーシングカーをハンドメイドで組み立てているような感覚です。本来Works体制で作るレーシングカーの部品だけ買って自分で作るような感覚で、ちょっとした工夫の楽しみがあります。
1月以上かけた作業となってしまい、記事の更新が完全に止まっていましたが、ぼちぼち再開できればと考えています。WordPressとDrupalを設置している『Xserverの移転』、今回の『AWSの移転』と続き、自分で作成したWebサイトを見直すことで新たな改善点も見えています。
当Webサイトも、今年4月にデザイン変更を行いましたが、過去の記事のレイアウトが古いままだったりしているので、地味な作業ですが、修正に手をつけていきたいと考えています。
記事更新再開以降、週一本の記事更新のペースで進めて来ましたが、少しペースを落とし、既存サイトのブラッシュアップをしっかり行うことを進めようと考えるきっかけになる移転作業でした。
