Drupal 導入前に必ず考えたい「保守」のこと

Drupal は非常に生産性の高い CMS・フレームワークです。しかし、コアのセキュリティー更新、コントリビュートモジュールの完成度や互換性、各種ライブラリのアップデートなど、気をつけなければならないポイントがいくつかあります。

Drupal コアのメジャーおよびマイナーアップデートは事前に決定されたスケジュールに基づき行われます。またバグフィックスや脆弱性対応などパッチレベルのアップデートに対しては、それぞれ月次のリリースウィンドウ（公開予定期間）が定められています。詳細については公式ドキュメンテーションを参照してください。

弊社が Drupal の開発を行ってきたなかで、主に保守（メンテナンス）の観点から重要なポイントを紹介したいと思います。弊社の Drupal 保守サービスにご興味をお持ちの方は「KAIZEN Drupal システム保守サービス」ページもご覧ください。

セキュリティー更新を受けるためには定期的にコアのマイナーアップデートが必要

Drupal は バージョン 8 以降セマンティックバージョニングを採用しており、マイナーアップデート（0.1単位のアップデート）が約半年に 1 回行われます。また、かなり重大な問題でない限り、サポートされている２つのマイナーバージョン（最新およびその 1 つ前）にのみセキュリティー更新が行われます。

言い換えると、セキュリティーを担保するためには必ず定期的にマイナーアップデートを適用する必要があるという事です。また、モジュールやカスタムコードの追従に関しては、後述するようにいくつか注意するポイントがあります。

「Drupal 9/10 対応モジュール」は全ての Drupal 9/10 のバージョンに対応しているわけではない

繰り返しになりますが、Drupal 8 以降はセマンティックバージョニングが採用されており、マイナーアップデート（0.1単位のアップデート）で新しい機能が追加されたり、既存の機能が非推奨の扱いになることがあります。特に新しい機能については、コアの内部設計の見直しによりコードの後方互換性がなくなるケースもあります。

モジュールが依存しているコアの機能でこのような後方互換性がない変更があった場合、当然ですがモジュール側でもこれに追従する変更が行われなければ、そのモジュールは新しいコア上で動作しないことになります。

「実際どういう時に困るの？」というのがちょっとわかりにくいと思いますので、実際に発生するケースを以下にご紹介します。少し古い例になりますが、問題・課題の要点はお分かり頂けると思います。

RestUI モジュールの例

RestUI は Rest API のエンドポイントを GUI から管理する機能を提供するモジュールです。このモジュールは Drupal 8.0.x の時点で全てに存在していました。

例えば、Drupa 8.1.10（2016 年 9 月 21 にリリースされた 8.1.x の最終バージョン）と RestUI 8.x-1.11（Drupal 8.1.10 がリリースされた時点の最新バージョン）を使ったサイトを作ったと仮定しましょう。

前述したとおり、8.2.x の最初のセキュリティー更新である Drupal 8.2.3 が 2016 年11 月 16 日にリリースされました。この際、なるべく早急に Drupal 8.2.3 までアップデートする必要があります。

この条件下でコアをアップデートするとどうなるでしょうか？実は RestUI モジュールは正しく動作しなくなります。Drupal 8.1.x では REST API の設定は ymlファイルで管理されていましたが、Drupal 8.2.0 からは Configuration Entity として管理されるようにコアの仕様が変更されています。そして RestUI 8.x-1.11 はこの新しい仕様には対応していないからです。

新しいコアの仕様に対応した RestUI 8.x-1.13 がコアのセキュリティ更新の数日前、2016 年 11 月 10 日にリリースされています。そのため、このケースであればコアと同時に RestUI モジュールをアップデートすればサイトは正常に動作します。しかし、本来の目的であるコアのセキュリティ更新以外にも、予期していなかった作業が発生することになります。また、エンジニアのスキルによってはこの解決方法に辿り着けないかもしれません。

もし、コアのセキュリティー更新が出た時に、対応するモジュールがリリースされていなかったらどうすればいいでしょうか？選択肢としては以下の 4 つが考えられます。

1. セキュリティを優先して RestUI モジュールを無効化してコアをアップデートする
2. 機能を満たすことを優先して、セキュリティアップデートを適用しない
3. 正式にリリース前の RestUI モジュールのパッチを適用し、コアもアップデートすることでセキュリティ要件も機能要件も満たす
4. RestUI モジュールのパッチを自分で作成して、コアもアップデートすることでセキュリティ要件も機能要件も満たす

1. で回避できれば良いですが、モジュールの機能によってはそもそもサイト自体が成り立たなくなるケースもありますし、影響が少なかったとしてもユーザーから OK が出ない可能性もあります。そのため、この解決方法を当てにするのは非常にリスクが高いでしょう。

2. も対応としては非常にリスクがあります。サイトの仕様と脆弱性の内容によっては、「早急にパッチを当てなくても問題ない」という判断ができるかもしれませんが、その判断を下すためにも高い技術力とコストが必要になります。また、過去にリリースされた非常に重大な脆弱性にのように「影響範囲が非常に大きく、緊急でパッチを適用せざるを得ない」というような場合も考えられます。

もしパッチが存在すれば 3. は良い選択肢です。Drupal.org の issue をチェックして、パッチがあるか、他のユーザーによってすでテストされているかを確認すると良いでしょう。正常に動いた場合、結果を issue にコメントすればメンテナーや他のユーザーにとってとても有益な情報になります。

Drupal をしっかりと理解しているエンジニアがいれば 4. を選択できるかもしれませんが、小さなモジュールはなんとかなっても、大規模なモジュールのパッチは作ること自体ができないかもしれません。また、大規模なモジュールのコード量は 1 万行を軽く超えます。

このようなリスクをなるべく避けるためには、

• 普段から、不用意にモジュールを導入しない
• アップデートにしっかりと対応できる体制作りおよび開発者の教育を行う
• 仕様変更が見込まれるコアの機能を利用している contrib モジュールの導入は、仕様が固まるまで避ける
• 導入するのであれば、開発が活発かどうか、過去のコアのマイナーアップデートに対する追従は早かったかなどを事前にしっかりと調査する
  • ダウンロード数や利用数が少ない、または最近リリースがないモジュールなどは特に注意
  • 新しいコアへの対応バージョンをかなり前から alpha ã‚„ beta としてリリースしたり、一定期間は古いバージョンもセキュリティー更新をしてくれるモジュールは安心です

などの対策が必要になります。

後述のように Drupal 7 ではコアの機能は基本的に変わらなかったため、コアがアップデートされたことによりモジュールが動作しなくなるということは、基本的にはありませんでした（ただしモジュール間の依存で同様の問題が発生することはありました）。Drupal 8 以降はコアとモジュールの依存でこのような事態が発生する可能性があるということを覚えておきましょう。コア自体の機能がかなり多くなっていますので、コアでできることはなるべくコアのみで実現することで、保守の手間を比較的低く保つことが出来ます。

同じ Drupal のバージョンでもライブラリーのバージョンは変化する

Drupal 7 までは、いったん安定版のコアがリリースされたあとは、次のメジャーリリースまで原則 API や機能追加は行わないという決まりがありました。これは、以下の 2 つの理由をもとに見直されることとなりました：

1. Drupal 8 から Symfony をはじめとする外部ライブラリーへの依存が多くなり、それらのアップデートに Drupal が追従する必要性が生じた
2. 過去のメジャーリリースには毎回数年の時間を要しており、変化の早い環境においてDrupal が取り残されてしまう懸念があった

このような理由からリリースサイクルを見直し、マイナーバージョンでも API 変更や機能追加をするというかたちで方針が転換されました

このようなリリースサイクルやライブラリのバージョンアップは Web アプリケーションフレームワークとしてはごく一般的ですが、CMSとしては珍しいかもしれませんが、ソフトウェアの保守としては珍しいものではありません。

まとめ

Drupal は非常に生産性の高い CMS・フレームワークであり、その機能も同一のメジャーバージョンの中でどんどん進化しています。しかし、長期的にシステムやサイトを保守・運用する場合、様々な要素を考慮してモジュールを導入したり、カスタムコードを書く判断をする必要があります。

社内のエンジニアや開発を依頼している会社が、気軽にモジュールをどんどん追加したりカスタムコードをたくさん書いているのであれば、将来的なの保守性を考慮しているか確認すると良いかもしれません。

弊社の Drupal 保守サービスにご興味をお持ちの方は「KAIZEN Drupal システム保守サービス」ページをご覧ください。