Drupalのインフラ運用にかかるコスト

この記事は Dries Buytaert 氏の公式ブログ「dri.es」の翻訳記事です。Driesブログの記事一覧よりすべての翻訳記事をご覧いただけます。

昨日、多くのエコシステムにまたがるオープンソースインフラがいかに脆弱で資金不足に陥っているかについて書きました。

Drupalも例外ではありません。

多くのオープンソースプロジェクトと同様に、Drupalは何百万人もの人々が依存しているにもかかわらず、直接費用を払っている人がほとんどいないインフラの上で動いています。

Drupalのインフラにかかるコストは、サーバー・帯域幅・CDN・ソフトウェア・人件費を含めて年間約300万ドルです。

資金は、AWSとOSU Open Source Labからの寄付インフラ、Drupal認定パートナープログラムを通じた企業会員費、Tag1からの現物提供、そしてDrupalConの収益・寄付・Drupal.org上のスポンサーシップの組み合わせで賄われています。

昨年、Drupal AssociationのボードメンバーであるTiffany Farrissと、CTOのTim Lehnenがプロジェクトのインフラコストを分析しました。その試算によると、Drupal 8以降のサイト向けインフラのコストは、アクティブなウェブサイト1件あたり年間約10ドルにのぼります。

しかしDrupal Associationが実際に支出できているのは、1サイトあたり年間約7.50ドルにすぎません。そのうち約3ドルはDrupalConと認定パートナープログラムから来ています。残りの4.50ドルは現物支援——つまり寄付されたホスティング・Tag1のインフラパートナーシップ・ボランティアによる貢献——で賄っています。使えるのはそれだけです。

1サイトあたり不足している2.50ドルは、技術的負債として積み重なっています。特定のアップグレードが先送りされ、レガシーシステムが必要以上に長く残り続け、インフラの進捗がなぜ遅いのかとコミュニティが首をかしげる場面が生まれます。

現在何とか賄えている7.50ドルさえも、実は脆弱な構造の上に成り立っています。DrupalConの収益はイベントへの参加者数に左右されます。広告収益はトラフィックに依存します。Tag1の現物提供は、一企業の継続的な善意に頼っています。AWSとOSUから提供されているインフラはいつなくなってもおかしくありません。そうなれば資金のギャップはさらに広がり、インフラ対応が一層先送りされ、いつかは実際に問題が生じるかもしれません。

新しい資金調達モデルの話に入る前に、まずDrupal Associationがインフラコストを削減できるかどうかを問い直す必要があります。1サイトあたり年間10ドルは高く聞こえるかもしれません。このインフラをすべて自前で運用すべきなのか、それともGitHubやGitLabのようなホスティングプラットフォームにもっと頼るべきなのか。インフラの一部が必要以上に複雑になっていないか。

これらは問うべき正しい問いです。私は支出と収入の両面から取り組む必要があると考えています。何にお金を使っているかを徹底的に見直しつつ、善意への依存度を下げる資金調達モデルを構築していく。実際のところ、インフラに関する意思決定はすべてを同時に最適化することはほとんどありません。コスト・スピード・柔軟性・コントロールの間でトレードオフが生じるものです。

企業による支援（コーポレートパトロネージ）も検討に値します。資金力のある単一スポンサーがいれば、コミュニティの資金調達では難しいかたちでDrupalのインフラを支えることができます。支援者を得るかインフラが危機に陥るかという二択であれば、支援者を選ぶべきです。素早く実行でき、技術的な変更も不要で、サイトオーナーとの社会的な契約にも触れません。

しかし、企業支援は脆弱性を別の形に替えるだけです。イベント参加者数やAWSのクラウドクレジットへの依存から脱却しても、今度は一企業の継続的な善意とプロジェクトへの戦略的な関心に依存することになります。その企業の優先事項が変われば、元の問題に逆戻りです。またこの規模のインフラを支援するスポンサーは、それに見合った見返りを求めるでしょう。それは通常、Drupal.orgへのより大きな影響力と、ある程度の支配権を意味します。

ほとんどのインフラシステムは、利用と費用負担を結びつけています。クラウドプラットフォームはコンピューティング量に応じて課金します。道路は運転する人が払う税金で整備されます。Drupalのインフラには、そのいずれの仕組みもありません。何百万ものサイトがDrupal.orgのサービスに依存していながら、そのサービスを運用するコストと利用者が切り離されたままです。

利用量に連動した資金調達モデルは企業支援のいくつかの問題を回避できますが、独自のトレードオフも伴います。オープンソースの文化は匿名アクセスを前提としています。アカウントも不要、何も聞かれることなく、どのパッケージもダウンロードできる。利用量ベースのモデルを導入するには、この規範を変える必要があります。最もシンプルな形としては、パッケージのダウンロードや自動更新通知の受信にDrupal.org APIキーを必要とする、という方法が考えられます。

APIキーの要求は商用APIでは標準的な慣行ですが、オープンソースでは感覚が異なります。キー自体が永久に無料だとしても、サイトオーナーにDrupal.orgへの自己申告を求めることは文化的な転換点になります。また、こうした仕組みをDrupal Coreに組み込むには変更が必要であり、インストール済みの環境に普及するまでには何年もかかる可能性があります。もしこの方向に進むなら、資金の危機が来てから取り組み始めるのでは遅すぎます。本当の危機が訪れた時点でも、解決策はまだ数年先にあるということになるからです。

まだ具体的な仕組みを提案できる段階にはいません。しかし、今こそこの議論を始めるべきです。まだ時間的な余裕があり、落ち着いて正しい判断を下せる今のうちに。そうしなければ、同じ決断を後になって、より大きなプレッシャーの下で、選択肢も信頼も少ない状態で行うことになります。

草稿を査読してくれたTiffany Farriss、Tim Lehnen、Gábor Hojtsy、Lauri Timmaneeに感謝します。

By Dries Buytaert

PS: LinkedInでも議論が続いています。

この記事は「What it costs to run Drupal's infrastructure」(投稿日：2026-03-10)の翻訳記事です。