WikipediaはBoringなコードで動いている、それがレッスンだ

Wikimedia財団での三年間（2022〜2025）が教えてくれたのは、月に約一度地球の半分にサービスを提供するシステムは、カンファレンストークが評価するアーキテクチャ宇宙飛行士的なものではなく、ほとんどが地味なPHP、丁寧なキャッシング、そして運用文化で動いているということだ。この記事は、最も明確な機能例の一つの内側で三年を過ごした者からの、スケールでのBoringなコードへの誠実なラブレターだ。

Wikipediaが運用的に何であるか

Wikipediaは一つのサイトではない。共有コードベース（MediaWiki）で動く何百もの言語版で、重くチューニングされたMySQLフリート、Varnishとカスタムキャッシュ層の前面、複数のグローバルPoPにまたがって提供されている。エンジニアリング組織は外部が推測するより小さい。ドナー資金の財団は予算が厳しく、ボランティアコントリビュータの深いベンチを持ち、二十年以上複合してきた文化を持つ。

五分でアーキテクチャ図を描けるだろう。十年以下では構築できない。

作業がどう感じられたか

不誠実なことを最初に言う：Wikimediaに入る前、私は博物館に入るべきシステムで作業することを期待していた。現実はチューニングがシステムが機能する全理由である、精密にチューニングされた楽器に近かった。コードそれ自体は私が触れた中で最も古くも最も新しくもない。ユニークなのはコードが動く方法についてのすべての決定に焼き付けられた蓄積された運用の知恵だ。

具体的に：

キャッシングはファーストクラスだ。 すべてのフィーチャーは「これはどうキャッシュするか？」から始まる — フォローアップのパフォーマンス懸念としてではなく、ゲートとなる設計の問いとして。フィーチャーがキャッシャビリティを低下させれば、それは設計の会話であり、パフォーマンスチューニングのパスではない。
MySQLはチューニングされた楽器だ。 クエリプランはレビューされる。インデックスは勝ち取られる。「インデックスを追加しよう」は存在しない — インデックスはこのスケールで継続的なコストがあり、会話はそのコストがクエリのボリュームで正当化されるかであって、インデックスがクエリを速くするかではない。より小さな会社では見たことがないレベルの規律だ。
デプロイはリハーサルされる。 トレインプロセス — コードが毎週本番に出荷される方法 — は十年以上洗練されてきた。公開されたドキュメントがある。いつ何が起きるかを全員が知っている。サプライズデプロイはない。
観測性は深く内面化されている。 インシデントが起きたとき、どのダッシュボードを開くか、どのログソースをクエリするか、どのオンコールをページするかの筋肉記憶が年単位で構築された。書き留められている。ドリルされている。新しいエンジニアはリファレンスとしてではなく、儀式として学ぶ。

これら四つのことはいずれもアーキテクチャではない。複合してきた運用習慣だ。それが実際の堀だ。

私が取り組んだこと

自分のフットプリントを誇張したくない。三年間で、パフォーマンス、信頼性、観測性に関する改善に貢献した — ほとんどがバックエンドで、高スループットのPHPとMySQLでの以前の経験がクリーンに移転した領域が多かった。より小さなインフラ隣接の変更を出荷し、個人のオーサーシップを超えるシステムのアーキテクチャレビューに参加し、エンジニアリング組織全体に展開された標準作業に貢献した。

その時代から永遠に持ち続ける二つのパターン：

1. アーキテクチャレビューとしての組織的な糊。 Wikimediaは構造化されたアーキテクチャレビュープロセスを運営している。提案が書かれ、回覧され、議論され、改訂され、最終的に承認される。レビューは遅い — 時に数週間 — そしてその遅さがフィーチャーだ。提案を成熟させ、多くのコントリビュータ（スタッフエンジニアだけでなく）に方向性についての声を与える。より小さな会社で類似の試みがゴム印になるのを見た。Wikimediaでは文化が本物のエンゲージメントを期待していたから機能した。それがほとんどのデザインレビュー文化が欠けているピースだ。

2. ボランティアコントリビュータをファーストクラスのエンジニアとして扱うこと。 Wikimediaのコードベースには、有給スタッフをはるかに超えるボランティアコントリビュータの基盤がある。すべての設計の決定、すべてのAPI変更、すべてのコードパターンが、スタンドアップをしていない人々にも読みやすく歓迎的でなければならない。これはエンジニアリングの決定に対して非常に健全な制約だ。内部専用コードベースの病理のほとんど — 巧みな内輪ジョーク、書かれていない慣習、魔法の抽象 — は聴衆が世界全体のときには生き残らない。

スケールについて教えてくれたこと

入る前は「Wikipediaのスケール」が意味する難しい問題はトラフィックのボリュームだと思っていた。違う。難しい問題はコンテンツを編集する五十万人、二十年分蓄積したコンテンツグラフ自体、そしてフィーチャーを出荷しながらそれらすべてが機能し続けるために必要な運用の規律だ。

トラフィックはVarnishで提供される。その部分は解決されている。

編集体験、コンテンツワークフロー、多言語ルーティング、悪用防止システム、コミュニティツール、非推奨処理、何百のサードパーティツールとのAPIコントラクト — これらがエンジニアリングの注意を消費する問題だ。そしてそれらのどれも Boring-PHPコードベースを捨てることで簡単にならない。コードベースと一緒に蓄積された知恵を失うから、悪化するだろう。

去った理由（そして持っていったもの）

2025年4月にWikimediaを去ったのは、AI支援エンジニアリングとローカルファーストなエージェントシステムについてより実践的な作業をするためだ — 皮肉なことに、 Wikimediaがうまく考えられるよう訓練してくれた退屈な規律の問題の正確な種類だ。エージェントコントロールプレーン（Fulcrum）はアーキテクチャ的に華やかなシステムではない。ステートマシン、ログ、メモリ層、そしてオーケストレーターだ。 Wikipediaのスタックが面白いのと同じ方法で面白くなる：アーキテクチャではなく運用の規律においてだ。

Wikimediaから持ち出した最大のものは、ほとんどの「退屈な」システムは誰かが退屈さを稼いだから退屈だという確信だ。誰かが年単位で面白い部分を返済した。誰かがランブックを書いた。誰かが遅いアーキテクチャレビューのために議論した。

残りのキャリアで一緒に仕事するすべてのエンジニアに一つのアドバイスを渡せるなら： エキサイティングなシステムを疑え。 誰がそのエキサイティングさの代金を払っているかを聞け。大抵、オンコールローテーションで、追いついてくるだろう。