Drupal 保守サービスおよび Drupal 7 のサポート終了について

2022/02 現在の状況

Drupal セキュリティーチームは 2022 年 02 月 25 日に発表されたパブリックサービスアナウンスメントを通して、コミュニティーによる Drupal 7 のサポート期間をさらに 1 年延長し、2023 年 11 月までとすることを発表しました。これに伴い Drupal 7 のサポート終了後にコミュニティー公認のベンダーが提供する予定だった Drupal 7 Extended Support は保留となりました。

以下は Drupal 7 Extended Support の詳細が明らかになる前の 2019 年 3 月 に執筆されたものですのでご了承ください。

本記事に関連するDrupalシステムの保守サービスについてはこちらをご覧ください。

現状のサポートの内容とは？

オープンソース・商用問わず、ソフトウェアにはしばしばバグやセキュリティー問題が発見されます。ここでいうサポートとは、そのような不具合や問題に対して Drupal コミュニティーとして提供する修正のことを指します。

Drupal コミュニティーは、常にその時点での最新バージョンの Drupal コアと、その一つ前のバージョンのコアをサポートしてきました。現時点では Drupal 8 と Drupal 7 がこれに当たります。修正パッチは、マイナーバージョン内で後方互換性があり、厳格な統合テストをクリアしたものがコミュニティーにより提供されています。またコミュニティーは最新バージョンのコアに積極的に新しい機能を追加していきます。

EOL（end-of-life の略）とは、このようなコミュニティーによる開発や修正のサポートが終了する、ということを意味します。

コミュニティーサポートの範囲

Drupal コア

コアの開発は、コミュニティーが定めたプロセスに従って行われており、これは公式サイトで詳細が説明されています。変更を追加する上で幾つものチェックポイントがあり（https://www.drupal.org/contribute/core/maintainers） 、最終的に変更を適用できるメンバーも限られています。また先にも言及したテストをパスする必要があるなど、幾重もの厳しいチェックをクリアした変更のみがコアに組み込まれます。

セキュリティー問題に関しては、Drupal セキュリティーチームが問題の発見者やコアのメインテイナー（開発／保守担当者）と連携して修正パッチを作成し、決められた勧告の手続きに従って公開されます。（https://www.drupal.org/drupal-security-team/security-advisory-process-and-permissions-policy）

拡張モジュール

ご存じない方も多いのですが、コアには含まれない Drupal の拡張モジュールやテーマは、実は上記のプロセスを経てコミュニティーによって開発・サポートされているものではありません。拡張モジュールやテーマは、一般的に個人または少数のグループが自分の必要に応じて作成したものを配布しています。ポピュラーな拡張モジュールのなかには、その機能に依存するシステムを運用している企業がスポンサーとして付いていたり、コミュニティーメンバーの寄付によりメインテイナーが業務として開発・保守を行っているものもあります。

コミュニティーによりサポートされていないとはいえ、それが直接セキュリティーの甘さにつながるわけでは決してありません。拡張モジュールにセキュリティー問題が発見された際に、そのモジュールがセキュリティー勧告カバレージに含まれている場合、コアと同様にセキュリティーチームとの連携のもとでセキュリティーパッチが作成・公開されます。なお、セキュリティー勧告カバレージは、各拡張モジュールのメインテイナーが任意で適用するもので、これは拡張モジュールのプロジェクトページにシールドアイコンがあるか否かによって確認できます（https://annai.co.jp/drupal/beginner/module#toc---7）。

なお、勧告のプロセスに則ってセキュリティーパッチが公開されるのは、正式リリースされているバージョンのみです。アルファ、ベータ、リリース候補（RC）及び開発中のバージョンに関しては公式な勧告が発表されないので注意が必要です。

LTS の扱い

コアが EOL に達した後は、拡張モジュールと同じようにプロジェクトページ（https://www.drupal.org/project/d6lts）とそれに対応するレポジトリが設けられます。また、現状でサポートされているコアにセキュリティー問題が発見された場合、セキュリティーチームと LTS （long-term-support の略）提供ベンダーが D6 への影響を調査し、必要に応じて対応します。

多くの場合、提供されるのは修正パッチのみで、パッチが適用されたコード自体は提供されません。そのため、相応の技術を有する開発者が修正パッチを適用する必要があります。

コミュニティーサポート終了後の Drupal 7 の安全性

コミュニティーサポートが終了した後（すなわち EOL 後）に Drupal 7 のサイトを安全に運営するのが難しくなるのでは、と懸念する方も多いことと思います。2022 年 2 月現在では Drupal 7 は EOL に達していないため、Drupal 7 LTS サービスは提供されていません（Drupal 7 向けには 'Long-Term Support' ではなく 'Extended Support' (ES) という名前で提供される予定です）。そのため参考として Drupal 6 EOL 後にどのような対応がなされているかを以下で見ていきたいと思います。

Drupal 6 LTS の現状

Drupal 6 の頃から Drupal をプラットフォームとして用い、大規模なシステムを開発するケースが非常に多くなってきました。Drupal のメジャーバージョンアップデートには大きな変更が付き物だったという経緯もあり、次のメジャーバージョンへのアップデートが難しくなるケースも増えてきました。 これに対応して、Drupal コミュニティーでは Drupal 6 に対する LTS（Long-Term Support ＝長期サポート）サービスを用意しました。これはセキュリティーチームにより厳選されたベンダーが、拡張モジュールと同じプロセスを通じて Drupal 6 および拡張モジュールのセキュリティーアップデートを作成・公開するというかたちで提供されます。D6 LTS はベースがオープンソースプロジェクトであることに変わりは無いので、全てのセキュリティーパッチは一般公開されます。

現時点で D6 LTS を提供しているベンダーは MyDropWizard と Tag1 Consulting の二社になります。前者はコアおよび拡張モジュールに対応しており、サイトの複雑さに応じて Basic / Standard / Enterprise の 3 種類のプランから選択することが可能です（注：当社はいずれの会社ともアフィリエイト等の関係は一切持っていません）。Enterprise プランの場合、セキュリティーアップデートの適用だけでなく、それに関連するバグの対応なども柔軟に行ってくれるとのことで、特に複雑なサイトを運営されているオーナーには嬉しいプランではないかと思います。

特筆すべき点は、D6 EOL から約３年が経つなかで、堅実に 100 以上のリリースが提供されてきただけではなく、2019 年 1 月の PHP 5.6 の EOL に伴ってコアと拡張モジュールを PHP 7.2 互換にするための変更も適用されたことです。今後は PHP 7.x が年１回のアップデートとなるため（https://secure.php.net/supported-versions.php）、セキュリティー修正だけではなく、プログラミング言語自体のアップデートへの追従もほぼ必須になります。Drupal という枠を超え、システムを包括的に捉えて依存ライブラリの EOL にも対応する LTS 提供ベンダーの姿勢は、非常に心強いものがあります。

Drupal 7 LTS/ES は提供されるのか。またその提供期間は

2019 年中に、LTS 提供ベンダーの選定などが行われる予定です。私達の知る限りでは、現時点において D6 LTS でも実績と経験が豊富な MyDropWizard が Drupal 7 LTS/ES 提供の意思表明を行っています（https://www.mydropwizard.com/blog/drupal-7-long-term-support-after-official-support-ends）。

Drupal 7 EOL の後、LTS/ES がどの程度の期間提供されるのか、というのもまた気になるところです。MyDropWizard のD6 LTS に限定すると、現時点では 2020 年 2 月までとのことで、D6 EOL から 4 年間にわたり提供されることになります。また、ビジネス的に持続可能であればその後も提供していく可能性があることが示唆されています。

Drupal 7 は Drupal プロジェクトの歴史上 最もインストール数が多いバージョンであり、先述の通りしばしば大規模開発に用いられ、また世界中で多くの政府機関・教育機関や大企業が導入してきた実績があります。D7 LTS/ES について決定している事実はまだありませんが、最低でも D6 と同等のクオリティと期間で LTS/ES が提供されるだろうと私達は見込んでいます。

Drupal 7 LTS か、Drupal 8/9 へのアップグレードか

サイトによっては、時代やテクノロジー、またマーケットのニーズの変化に対応すべく、LTS よりも Drupal のアップグレードを行うほうが長期的には良いかもしれません。

Drupal 7 からのアップグレードを考慮する場合、Drupal 8 にするか、9 にするかという疑問が生じるかもしれません。Drupal 8 にアップグレードしても、その後短期間で Drupal 9 にアップグレードする必要が生じるのであれば、Drupal 9 の安定版がリリースされるまで待ったほうが良いのではないかとも考えられます。

いつ、どのバージョンにアップグレードすべきか

結論から言うと、ビジネス的観点から Drupal 8 へ近いうちにアップグレードをすることが理にかなっており、また予算的・技術的にそれが可能なウェブサイト／アプリケーションは、おそらく早いうちにアップグレードして差し支えないでしょう。

Drupal 7 まではメジャーバージョンアップグレードのたびに大幅な変更が導入され、それ故サイトのアップグレード作業も大変手間がかかるものでした。しかし、Drupal 8 から適用されたリリース方式のおかげで、 8 から 9 へのアップグレードは Drupal 8 のマイナーアップデートと基本的に変わらなくなり、メジャーアップグレードの負担が減る見込みです。

そもそも Drupal 8 が EOL を迎える主な理由は、依存先の Symfony 3 が EOL に達するためです。つまり、 Drupal を Symfony 4 / 5 互換にする必要があり、その結果として後方互換性が失われるので、メジャーリリースにならざるを得ないという訳です。Drupal プロジェクトリードの Dries Buytaert は、Symfony 3 をベースに書かれた、非推奨扱いになったコードの削除が Drupal 9 へのメジャーアップグレードに含まれる主な変更になるという予想を自身のブログで公表しています（https://dri.es/drupal-7-8-and-9）。

ただし、今の時点で Drupal 8 にアップグレードすることをお薦めできるのは、コア・拡張モジュールならびにカスタムモジュールやテーマを、コアの変更に伴い定期的にアップデートできる場合に限ります。Drupal 8 へのメジャーアップグレード後、定期的なマイナーアップデートを無視して放置した場合、当然 Drupal 9 へのアップデートの際にはサイトが動かなくなってしまいます。また、メインテイナーに放置されている拡張モジュールに依存した機能が存在する場合も同様です。ですので、現時点でのアップグレードは、サイトのコードを定期的にアップデートできるリソースや技術力がない場合はお薦めできません。

Drupal 7 から 9 へのアップグレード

Drupal 9 は、Drupal 7 が EOL に達する約 3 年前の 2020 年の時点でリリースされています。ですので、7 から直接 9 にアップグレードするという方法も考えられます。アップグレードがプロダクトに与える影響をじっくり検討したり、予算の準備に時間を要するのであれば、9 への直接のアップグレードを前提に今から準備を始めるのが良いかもしれません。

まとめ

• Drupal 7 は 2023 年 11 月にコミュニティーサポートが終了し、ベンダーによるサポートへと移行する。これに伴い Drupal 7 コアの新機能の開発は終了し、セキュリティーアップデートのみとなる。
• LTS/ES（長期サポート）サービスは、コミュニテイのセキュリティーチームにより厳選された、コミュニティーからの信頼があり、また相応の知識と経験を持つベンダーにより提供される。前バージョンの LTS/ES の対応が非常に良いので、Drupal 7 LTS/ES でも引き続きクオリティの高い対応が期待される。
• 前バージョンの LTS は開発終了から 4 年間行われることになり、ニーズにより延期も検討中。Drupal 7 は Drupal 6 に比べインストール数が多く 、世界中で多くの政府機関や大企業が導入しているため、最低でも同等のサポートが提供されると考えられる。
• Drupal 8 のマイナーアップデートをタイムリーに適用することができれば、Drupal 8 から Drupal 9 のアップグレードは大きな作業を伴わない。Drupal 7 から Drupal 8 と Drupal 9 のどちらにアップグレードするかは、サイトの複雑度、ビジネスニーズ、予算また技術的なリソースに基づき決定すべき。