Nginxの開発の背景
こんにちは、OSSのレキシラジオです。
このポッドキャストは、現役エンジニアであるhentekoが、毎週一つのOSSプロジェクトを取り上げて、
その開発の裏側にある歴史やドラマを紹介していく番組になります。
まず、緊急報告として、先日久しぶりにリアルの会場で行われた新年LT大会で登壇してきました。
ここ数年はですね、ずっとオンラインばかりだったので、めちゃくちゃ緊張したんですけど、やっぱりいいですね、リアルは。
ちょっとしたジョークで会場が笑ってくれたり、うんうんってうなずいてくれる反応がその場で見えると本当に嬉しいものです。
やっぱり発表はリアルに限るなぁと改めて感じました。
さて、そんなことは置いておきつつ、今週のテーマに参りましょう。
今週はWebエンジニアなら誰もがお世話になっているNginxの歴史についてです。
単なるWebサーバーのお話かと思いきや、実は警察沙汰や戦争、そして失踪の違いによる分裂など、かなり万丈な歴史を持っています。
それでは見ていきましょう。
Nginxが開発された2000年代初頭当時のお話をお待ちします。
当時のインターネットはですね、静的なHTMLを表示するだけのWeb 1.0から、動的なコンテンツや常時接続が当たり前のWeb 2.0へと移行する過渡期でした。
一般過程にもですね、インターネットが爆発的に普及して、Webサイトへのアクセス数というのがうなぎの棒になっていたような時代です。
当時ですね、Webサーバーを作るっていうなら、Apacheを使うっていうのが常識的でした。
いわゆるLinux、Apache、MySQL、PHPを組み合わせたランプスタックっていうところが開発の主流だったんですね。
でもここで大きな壁が立ちはだかります。
それが有名なC10系問題、クライアント一万台問題というものです。
大量のアクセスがあるとですね、サーバーがダウンしてしまうというような問題です。
Apacheはその構造上、一つのアクセスに対して一つのOSプロセスを割り当てるような仕組みです。
これ、アクセスが少ないうちはいいんですけど、接続が増えるとプロセスが膨大な数になってしまうというような問題があります。
そうするとですね、CPUがプロセスの切り替えだけで手一杯になったり、
メモリが足りなくなってディスクへのスワップが発生したりして、結果的にサーバーがダウンしてしまうんですよね。
これは、パッチが生まれた頃のUNIX系OSの使用上、仕方ないことでもあったりします。
そこで、この問題に頭を抱えていた一人のエンジニアがいました。
ロシアの大手ポータルサイトランブラーのシステム管理者であったイーゴリシソフさんです。
ちなみにですね、このランブラーというものは日本で言うYahooのような巨大なサイトです。
このランブラーはですね、Apacheで運用されていたんですけど、ピーク時にはダウンが頻発するというような環境になっていました。
そこでですね、イーゴリさんは既存のApacheモジュールの改良やチューニングっていうものをしてみたんですけど、
このままの延長線上では根本的な解決というのが無理だなと考えていました。
そこで彼はですね、業務としてではなくて個人のプロジェクトとして新しいウェブサーバーを作ろうというような決断をします。
これがエンジンXの始まりとなります。
そして2002年ですね、イーゴリさんは個人的な探求心からエンジンXの開発をスタートさせます。
性能と革新
ちなみにこの個人的なプロジェクトだったという点がですね、後に大事件の左になるのでちょっと覚えておいてください。
彼はですね、エンジンXでイベント駆動型非同期ノンブロッキングというようなアーキテクチャを採用しました。
当時の新しいUNIX系OSの機能であるeepolなどをフル活用して、少ないプロセス数で大量の接続をさばけるようにしたというようなところです。
具体的にはですね、エンジンXは起動するとマスタープロセスとワーカープロセスというものを生成します。
マスタープロセスでは設定ファイルの読み込みや検証、ワーカープロセスの管理を担当して、
ワーカープロセスでは実際のネットワーク接続の処理というのを担当します。
実際のワーカープロセス数というのはCPUのコア数に合わせて設定されるようになっているんですけど、
キャッシュ効率の最大化とコンテキストスイッチの最小化ということを行いました。
これによってですね、メモリ消費の劇的な削減と効率化というところに成功しました。
実際にApacheが1万接続を処理するのに数ギガバイトのメモリを使っていたのに対して、
エンジンXは何と数メガから数十メガバイトで安定的に動作するということに成功しました。
そんなエンジンXなんですけど、2004年の10月にですね、オープンソースとして公開されると、
その圧倒的なパフォーマンスによって世界中の開発コミュニティに口コミで広がっていきました。
そしてここでですね、エンジンXが賢かったのはですね、
Apacheを捨ててエンジンXにしようというようなことを言わなかったことです。
当時のインフラ管理者の方たちはですね、
安定しているApacheの設定を捨てるっていうのがなかなか怖かったというところがあります。
そこでエンジンXはリバースプロキシとしての利用というのを推奨しました。
こちらどういうことかというと、
クライアントからの全リクエストをApacheの前に設置したエンジンXで
全て受け付けて画像やHTMLなどの静的ファイルは
エンジンXが高速に配信し、動的な処理や重い処理のみを
エンジンXから後ろにいるApacheにするというような構成です。
いわゆるいのハイブリッド構成ですね。
Apacheが処理すべきリクエスト数が激減したことによってですね、
これによってシステム全体の効率というのが向上しました。
そしてこの構成というのはですね、
2000年代後半のウェブインフラ開発において
ベストプラクティスとして管理することになります。
ビジネス展開と未来
実際にですね、日本で開催されている
インフラの構成を最適化するコンテストであるISCONでもですね、
初期の頃はとりあえずApacheの前代に
エンジンXを置いて静的ファイルを裁かせるというのがですね、
スコアを上げる常識だったくらいでした。
そしてその後もですね、エンジンXはどんどん進化していきます。
2005年にはFastCGIをサポートの強化して、
2007年から2009年にかけてはですね、
キャッシュ機能やロードバランシング機能などのサポートというのが実装されました。
特にこのロードバランサーとしての機能はですね、
当時専用のハードウェアロードバランサーを代替する
コスト効率の良い集団として注目されました。
実際にこの機能のおかげでですね、
2013年以降のDockerコンテナの爆発的普及によってですね、
エンジンXはイングレスコントローラーやサイドカープロキシナとして、
Kubernetesのエコシステムの中心的な客羽料理な存在に現在でもなっています。
そしてまたですね、2011年にはバージョン1.0.0としてリリースされて、
この時点で安定性、機能性、実績のすべてにおいて、
エンタープライズ利用に対応するソフトウェアとして成熟するという形になりました。
そして同年の2011年にはですね、
エンジンXインクとして会社が設立されることになります。
これはですね、エンジンXが世界規模で利用拡大する中でですね、
イコリさん個人の手に負えないほどのサポートリクエストや機能要望というのが
寄せられた結果、持続可能性を確保するために、
アメリカ・サンフランシスコに本社を置く形で設立ということがされました。
ただですね、本社はアメリカとしつつも、
開発拠点はMOSコアに維持される形になりました。
そしてこの会社のビジネスモデルとして、
オープンコアモデルという基本機能はオープンソースとして、
高度な管理機能やサポートは有償版として提供するというような戦力で提供されました。
さてそういった形で順風満帆に見えてエンジンXなんですけど、
ここから蜘蛛行きがどんどん怪しくなっていきます。
まず2019年の3月です。
NGINXの買収と事件
アメリカのF5ネットワークがエンジンXを40億円で買収ということが実施されました。
ただですね、買収されてもエンジンXブランドは維持されて、
イーゴリさんら、創業チームもですね、F5に参加することになって、
オープンソースへの継続的なコミットメントというのは約束される形になりました。
ここまでは成功したスタートアップの話なんですけど、
その年の12月に大事件が起きます。
なんとですね、モスクワのエンジンXオフィスにロシア警察が家宅捜索に入り、
創業者のイーゴリさんたちが拘束尋問されるというような事件です。
理由はですね、彼が以前勤めていたランバーからの刑事酷訴でした。
ランバー側の主張としてはですね、
エンジンXはうちの社員だった時に作ったんだから、
著作権は会社にあるはずだというような主張で刑事酷訴したというものです。
これに対してイーゴリさんはですね、
あれは業務時間外に個人の趣味で作ったものだというような反応、
当たり前の反応をしました。
この事件というのはですね、単なる著作権の争いを超えて、
オープンソースエコシステム全体への攻撃というような受け止められ方をしました。
在籍中に個人的に開発したOSSの権利をですね、
15年後に主張して刑事事件化するというような前例というのは、
世界中の開発者にとっては恐怖的でした。
結局、ランバーの親会社である銀行がこの話に介入して、
酷訴というのは取り下げられる結果となって収束するという形にはなりました。
そしてその後ですね、2022年1月にイーゴリさんは
エンジンXおよびF5からの退社というのを発表します。
理由としてはですね、個人的なプロジェクトに時間を割くためというような形で退社をしています。
プロジェクトのリードというのは更新に委員長されるということになりました。
そしてですね、その直後の2022年2月、皆さんもご存知だと思いますが、
ここからロシアによるウクライナ侵攻というのが始まります。
これによってですね、親会社のF5というのはロシアでの事業停止を行います。
そしてそれに伴ってオフィスの閉鎖というのも決定されました。
その結果ですね、スクワにいた開発者たちはロシアを出てF5に残るか、
ロシアに残ってF5を去るかというような究極の選択を迫られました。
結果としてですね、ロシアに残った元エンジンX開発者の方たちはですね、
AnjiというエンジンXのフォークを立ち上げることになります。
このAnjiはですね、エンジンXの商用版に限定されていた機能の一部をオープンソース版として実装し、
主にロシア国内向けに展開されるというようなプロダクトになっています。
これがエンジンXの最初の大きな分裂になります。
分裂と影響
そして戦争によってですね、本家エンジンXとロシア初のAnjiに分かれたわけなんですけど、分裂はこれだけで終わりませんでした。
2024年2月のことです。
エンジンXの最古産開発者の一人、マキシム・ドゥーニンさんがですね、プロジェクト開発の離脱を宣言し、
新たにフリーエンジンXというものを立ち上げました。原因はF5のマネジメント層との対立です。
きっかけとしてはですね、HTTP3のサポートに関する実験的な行動に見つかったバグの扱い方です。
F5側としてはですね、企業としてコンプライアンスを重視し、実験的機能とはいえ使っているユーザーがいる以上、
CVEを発行してセキュリティ的に警告すべきだというような判断をしていました。
一方でですね、マキシムさんとしてはですね、これは実験的な機能なんだと明記しているので、
バグがあるのが前提だし、これを重大な脆弱性として扱うのは開発ポリシーに反するというような反発ということをしました。
結果ですね、F5が押し切る形でCVEを発行したため、マキシムさんは企業にはコントロールされないということを目的とした
自由なエンジンXであるフリーエンジンXというものを作りました。
エンジンXをフォークする形で派生したというような形です。
そして現在ですね、フリーエンジンXはF5などの企業のコントロールを受けずに、寄付とボランティアによって運営ということがされています。
本家のエンジンXの変更を取り込みつつも、独自のバグ修正や機能改善というものを行っているような状況です。
このようにですね、現在エンジンXの世界は本家エンジンX、アンジ、フリーエンジンXという3つに分かれることになってしまい、
現在もそれぞれで開発が継続されているというような状況が続いています。
さて、いかがだったでしょうか。
手術系問題を解決するために、個人の情熱から生まれたエンジンX。
Apacheを助ける形で普及し、デファクトスタンダードになりましたが、
その後、著作権問題、戦争、そして企業ポリシーとの衝突により、現在3つのプロジェクトに分断されて開発というのが続けられています。
僕らがですね、普段何気なくアクセスしているウェブサイトの裏側には、これだけのドラマがあったんだなというような形ですね。
今後、開発プロジェクトでどのエンジンXを選ぶか考えるときにですね、こういった背景を知っていると、また違った視点で選定というのができるんじゃないかなと個人的には思いました。
さて、今回のお話は以上となります。
もし少しでも今回のお話がためになったなと思ったら、お聞きのプラットフォームでの高評価とフォローの方をお願いいたします。
また、Xなどでハッシュタグ、OSSの歴史ラジオを付けて感想を呟いてもらえると、めちゃくちゃモチベーションになりますので、ぜひよろしくお願いします。
次回はですね、日本人が世界で活躍するプログラミング言語を開発した成功例、Rubyの歴史について見ていけたらなと思います。
それではまた次回お会いしましょう。バイバイ。
