Nginxの基本的な役割と歴史的背景
今回は、Nginxについて話をしていきたいんですけど、このポッドキャストでもですね、2回目でNginxビルドについて話をしましたが、今回は本体であるNginxについて話をしていけたらなと思っています。
で、Nginxといえば、僕の勝手な理解なんですけど、だいたい設定が簡単な、リバースプロキシとか静的ファイルの高速配信に使うようなウェブサーバーみたいな印象なんですけど、
片杉さん的にはNginxどんなものですかね。
そうですね。そんなに認識はずれてないかなと思っていて、一応、実はメールサーバーの設定とか、あとTCPのプロクシー、HTTPじゃなくてTCPのプロクシーみたいな機能も実はあるんだけど、そんなに使われてなくて、基本的にはHTTPのプロクシーとか、あと静的ファイル配信とかで使われていることが多いですね。
メールサーバーの設定とかも実はできちゃったりするんですね、Nginxで。
実はできるんですけど、自分はやったことないのでよくわかんないです。
ですよね。
あんま使われてないんで。
あんま見たことないので、そういう設定例を。
今回のHTTPの話を基本的にはしていければなって感じですね。
ありがとうございます。ちなみにざっくり片杉さん的にNginxこんなものだよみたいなことを話すとしたらどんな説明になります?簡単に。簡単な説明でいいので。
そうですね。早いHTTPサーバー。
たくさんリクエスト送っても結構耐えられる。便利なHTTPサーバーって感じですかね。
シンプルに言えばいいですね。
そんなNginxなんですけど、内部的には結構特徴的なところとかあったりするんですかね。実装的なお話で言うと。
そうですね。まず歴史から振り返っていければなと思うんですけど、まずPHPとかが主なんですけど、そのPHPって1回リクエスト受けたらその1プロセスがそのレスポンス返すまで受け負うんですよね。
そのプロセスは他のリクエストが来ても受け付けられない、処理できないんですよ。
1プロセスが1リクエストを占有してしまって、1つのサーバーで何プロセスぐらい捌けるかちょっとあれですけど、リソースの制約があるかなと思いつつも。
現実的にはそんなたくさんのプロセスが叶えるわけではないのでっていうような形なんですかね。
そうですね。そのプロセスやっぱり多くしちゃうとメモリーがどうしても足りなくなってくるんですよね。
なので結局PHPみたいなアプリケーションだとプロセス数を増やすしかないんですけど、それは結構限界があります。
それが何が問題、具体的に何が問題かっていうと、正直リクエスト数が少ない段階だったら別にそれでもいいんですよ。
1プロセス1リクエストでも。
けど、C10K問題っていう有名な問題があって、クライアント数が10Kなんで1万超えたあたりからそのアーキテクチャ、1プロセス1リクエストのアーキテクチャだと捌けなくなるっていう問題が知られていて、
昔から広く。
RangeXはそのC10K問題を解決するために生まれたサーバーですっていうのが公式のドキュメントとかにも書いてあるんですよね。
クライアント1万の問題っていうのは、同時接続の1万、1万同時接続くるとその1プロセス1リクエストだと捌かなきゃいけないよねっていうような問題ですかね。
そうですね。厳密にそういうのが決まっているのかよくわかんないんですけど、1万個ぐらいのクライアントが同時にアクセスしてきたら厳しいよねっていう感じだと思います。
だいたいざっくりそのぐらいっていうような。
ざっくりその厳密な話ではないですね。
1万になったから即さま落ちるとか、9000だからいいっていう話ではないってことですね。
ではないですね。ざっくりこんぐらいでしんどいよねっていう。
その問題がそもそもあって、その問題解決するために作られたのがEngineXっていうようなウェブサイト。
Nginxのイベント駆動型アーキテクチャ
そうですね。EngineXは1プロセスが複数のリクエストを同時に受け付けることができるんですね。
これいわゆるイベント駆動って言われていて、リクエストが来たタイミングでどんどん処理をしていくっていうようなアーキテクチャになっている。
なのでEngineXはこれも設定できるんですけど、オートっていう設定にするとプロセスはCPUの数分になるんですね。
なのでそのCPUの数分プロセスが立って、そのプロセスがそれぞれリクエストを受け取ってレスポンスを返すっていうのをやってくれる。
非常にリソースの消費量もかなり少なめでやってくれるっていうのがEngineXの特徴ですね。
サーバーのCPU使ってるやつが4コアとかだったら4プロセス立ち上げてっていうような形ですね。
4プロセスで4つのリクエストしか受け付けられないとかではなくて、同時にどんどん送っちゃって大丈夫。
EngineXが出る前のウェブサーバーとかだったら、基本プロセスだけだったら4つのリクエストを同時に捌けるだけだったけども、
EngineXだったらそういう限りではないってことですね。
そうですね。具体的にどういうメリットが、これによってメリットって大きくて、
例えばさっき言ったPHPを大量のリクエストを受け付けられるようなサーバーを構築したいって結構あるんですよね。要求として。
そういう場合はPHPのサーバーたくさん裏で用意しておいて、EngineXを前端に置いておく。
まずユーザーのリクエストをEngineXで受けます。その後にEngineXが後ろのワークエンドのPHPのサーバーに対してリクエストを送る。
プロクシーしてリクエストを送る。レスポンス返ってきたらEngineXからまた返すっていうふうにやることによって、
EngineXは大量のリクエストを受け付けられる。リソースも低く抑えられるのでサーバー台数少なくできるし、
裏側のPHPのアプリケーションコードは変えずに基本的に捌くことができる。
しかもPHP自体もユーザーにレスポンス返しきるまでPHPのプロセスってつかまれちゃうんですよね。
けど、EngineXにPHPはEngineXから来たリクエストをEngineXに返すことだけに集中すればよくなるから、
基本的にはすぐ返せる。処理が終わったらすぐ返せる。
その後ユーザーが例えば遅い回線だったりとかしてもEngineXが詰まるかもしれないけど、
EngineXが詰まっても全体のリソースには特に影響しないので、その辺はうまいことEngineXがやってくれる。
スケールアップがめちゃくちゃ簡単にできやすいってことなんですかね。
EngineXを全体に置くことで。
スケールアウトかな。
スケールアウトか。
PHPのアプリケーションサーバーの台数を増やすことが簡単になる。
EngineXのサーバー、ウェブサーバーを1台だけ前段に置いておいて、
裏側のアプリケーションサーバーを100だったり200だったり置いたとしても問題がないっていう。
1台だと冗長性がないっていう話はあるんだけど、
でも2,3台とかぐらいでEngineXはさばいてるけど裏側のPHPはすごいたくさんありますみたいな構成は全然珍しくないですね。
そういった形で使うのが一般的な使い方。
プロクシーサーバーとしての使い方としては一般的ですね。
ちなみになんですけど、デメリットみたいなところもあったりするんですかね。
例えば今なんとなく聞いてて思ったのが、1プロセス1リクエストでやってたのって、
時代背景とかもいろいろあるかもしれないんですけど、EngineX前の時代背景もあるかもしれないんですけど、
1リクエストに対するリソースの消費をちゃんとCPUをしっかり使いたいとかそういうこともあったのかもなともなんとなく思って、
EngineXにしたらその1プロセスを占有できないわけじゃないですか、逆に言えば。
そういうデメリットもあったりするのかなと思ったんですけど、そこまでないですか。
例えばNode.jsも同じようなアーキテクチャなんだけど、Node.jsみたいに自分でコードを書いてる場合は、
ブロッキング、処理の中でブロッキングしちゃうと全体がブロッキングされちゃうとかそういう問題はあるんですけど、
EngineXの場合は基本的には設定ファイルを書くので、その設定ファイルを書いてる分には基本的にそういうブロッキングするとかっていうのは基本ないはずなので、
そういうデメリットは基本ないかなという認識ですね。
じゃあまあとりあえずEngineX使っておけばスケールアウトもしやすいし、後々いいよねっていうような。
前段とりあえずEngineX入れておくとスループットが良くなるケースが多いと思いますね。
大体においては。
ほとんどのケースにおいて。
ありがとうございます。ちなみにじゃあ逆にそのEngineXが何ですよね、その前段に立ってるってことは、
別の見方するとさっきのデメリットの話にも繋がっちゃうかもしれないですけど、単一障害点にもなり得るなと若干思うんですよね。
そういった時の何か対策とかってあったりするんですかね。何かあんまりパッと置く自信は思いつかないんですけど。
まあそのEngineX、そもそもサーバー台数が少なかったら、その1台落ちた時にちゃんと耐えられるようにするとか、
あとそのIPアドレス落ちたら、そのIPアドレスDNSから外さないといけないとか、
そういうのはあるんだけど、そういうのってEngineXじゃなくて、EngineXの外側でやらないといけない仕組みだったりするんですよね。
まあ確かに。
エンジンX自体でできることっていうのはあんまりないし、エンジンXって非常に安定しているソフトウェアだし、
しかもかなり利用されてるんですよね。最近は結構減ってきたかなと思ってるんですけど、
例えばAWSのALBって昔は明らかにエンジンXだったんですよね、エラー画面とかが全部。
最近は結構ALBも機能足されてて、エンジンXだと簡単に実装できない機能が結構提供されてるんで、
今は別実装かもしれないんですけど、もともとマネージドエンジンXみたいなサービスだったんですよ、ALBって。
そういったIWSみたいな巨大なエンタープライズが使われるようなサービスのロードバランシングでも使われるようなエンジンXだから、
ほぼほぼ安定してるよねっていう。
ほぼほぼ安定してるし、エンジンX他にも有名どこだったっけ、一番多分有名なのはクラウドフレアで昔、
今は使ってないみたいなんだけど、昔クラウドフレアはエンジンXでクラウドフレアの規模をさばききってたらしいので、
やっぱりエンジンXってそれだけ実績があるソフトウェアなんですよ。
なので基本的によほど変なことしない限りは、そういう変なことは起こらないんじゃないかなと思ってますね。
なるほど。じゃあエンジンXが問題というよりかはエンジンXを管理する側の問題みたいな感じですね。
実運用しようとするといろいろ問題あるんですけど、それは他のソフトウェア使っても一緒だし、
その辺の話も少ししていければと思うんだけどって感じですね。
ありがとうございます。じゃあちょっとエンジンXの内部の詳しいところを見ていけたらなと思うんですけど、
片辻さんが思うこういうとこ結構特徴的だなみたいなところあります?エンジンXで。
Nginxの内部実装：ノンブロッキングI/Oとepoll
この内部実装がイベント駆動って話したんだけど、具体的にどうやってるかっていうと、
一番有名なものというか、知っておきたいのがノンブロッキングIoっていうのと、
あと多重Io、ePolっていうやつなんだけど、その2つを理解していくといいかなと思っていて、
まずノンブロッキングIoなんだけど、普通のIoっていうのはブロッキングIoっていうのになるんですよね。
この辺はLinuxの説明になるんですけど、
そもそもアプリケーションって基本的にファイルに書き込むとかそういうことって本当は一切できないんですよ。
1だす1とか計算はできるんだけど、その計算結果をどっかに書き込むっていうのはアプリケーションからできなくて、
Linuxカーネルしかできないんですよ。ディスプレイに書くとかディスクに書き込むとかそういうのって基本的にはLinuxカーネルしかできないんですね。
OS側の機能として持ってるってことですよね。
OS側がハードウェアを管理しているから、ハードウェアに関わるやつっていうのは基本的にOS側しかできないんですよ。
触れないんですよ。
それだとアプリケーション側は何もできない。何か書き込まないと何もできないじゃないですか。
そうですね。保存できないですよね。単純にデータを。
計算してもその計算結果どっかに書き込まないんだったら意味がないので、
アプリケーション側はOS側にこれを書き込んでくださいとかってお願いするんですよ。
それがシステムコールって呼ばれているものです。
ファイルで書き込みしたい場合はまずオープンっていうシステムコールを使う必要があるんですよ。
その時のフラグっていうのを渡さないといけないんだけど、
そのフラグで特にデフォルトはBlockingIOってやつで、
これはいわゆる一般的な、とりあえずファイル開きます。
そのファイルに対して書き込む時に、例えばディスクが今詰まってるとか、
たくさん書き込みがあって今ディスク詰まってますとかだったら待ちになる。
書き込めるまで待ちますとか読み込めるまで待ちますとかってなる。
これが一般的なIOでBlockingIOって呼ばれているものです。
今誰かがディスクに書き込んでるからちょっと待ってねみたいなことですよね。
ちょっと時間かかって帰ってくるのでちょっと時間がかかるっていう感じですね。
っていうのが一般的なBlockingIOなんですよ。
Non-BlockingIOっていうのはオープンする時にフラグを渡せば使えるんだけど、
これは書き込もうとしたとか読み込もうとした時に、
IOがブロックしてたらエラーが返ってくるっていう。
ブロックしてなかったらIOが読み込めるっていうようなものなんですよね。
Non-BlockingIOだったらブロッキングしないから最高っていう話じゃなくて、
単純に読み込めなかったら即エラーが返ってくるってだけなんですよね。
なるほど。常に書き込めるっていう話ではなくて、
書き込めない状態だったらエラーになって返ってくるから、
結果がすぐ分かるっていうことなんですね。
結果的にブロッキングしないっていうのがNon-BlockingIOなんですよ。
なるほど。Non-BlockingIOという言葉から指す印象と若干違いますね。
Non-BlockingIOって聞くと夢のような仕組みで、
常にこれ使えばいいじゃんって思うかもしれないんだけど、
別に単純に書き込めなかったらエラー返ってくるだけなんで、
別にそんな良いものではないんですよね。
なるほど。失敗するものってことですね。
失敗したときの処理をちゃんと書かないといけない。
もう一個、LinuxだとEPolっていう仕組みがあって、
さっきオープンって話したんだけど、
オープンするとファイルディスクリプターっていうのがもらえるんですよね。
そのファイルディスクリプター経由で読み込みとか書き込みをするんですよ、Linuxって。
そのファイルディスクリプターを複数EPolっていうの渡せて、
どれか一個が書き込みとか読み込み成功したら、
イベントが返ってくるようなAPIがEPolなんですよね。
これをNon-BlockingIOとEPolを組み合わせることによって、
処理が終わったやつをどんどん返していくような処理になっているので、
一つのプロセスが複数のリクエストレスポンスを返せるようになるんですよ。
なるほど。EPolとNon-BlockingIOを組み合わせることによって、
ブロックされてたとしてもできる限り早くファイル書き込みができるっていうことなんですかね。
そうです。今ブロックされていないIOを最優先で処理して、
どんどん返していく。
だからこそリアルタイムできたイベントを処理して返すことができる。
イベント駆動の仕組みを作ることができるっていうことなんですね。
ってことは、エンジンXは内部でNon-BlockingIOとEPolをシステムコールを使ってるってことですよね。
使ってますね。
だから、1プロセス1リクエストではない形が実装できてるってことなんですかね。
できてるんですけど、これってやっぱり難しいじゃないですか。EPolとかNon-BlockingIOの仕組みって。
今説明聞いて、そういうことなんだって理解できましたけど。
実際にそれを使って実装してみましょうとか言われると辛い。
難しそう。EPolとかよく分からないなっていう感じがしますね。
なんで?難しいんですよ。
PHPみたいな1プロセスで1リクエストを捌くような仕組みって何がいいかってやっぱり実装が簡単なことなんですよね。
シンプルですよね。
シンプルで簡単なんで、それってやっぱり偉大なんですよね。
事故になりにくいってことだから。
なるほど。
それってやっぱり偉大なんですよ。
だから、そういう難しい処理はエンジンXに任せて、
PHPとかそのもっと単純な仕組みでアプリケーションを実装するっていう風にやると比較的簡単に実装できる。
ハイパフォーマンスな仕組みが比較的簡単に実装できる。
なるほど。役割の分担をしてるんですね、そこでやっぱり。
アプリケーションは実際の処理を担当するので、できる限りシンプルなアーキテクチャで保ちつつ、
エンジンXの方はちょっと複雑な実装はしてるけど、捌くことに集中するっていう。
そうですね。そこで役割分担することで、
結構簡単、比較的簡単にハイパフォーマンスが出せる仕組みっていうのが作れる。
そういうすごい武器なんですよ、エンジンXっていうのは。
めちゃくちゃ今の説明聞いたら、すごいエンジンXめちゃくちゃいいじゃんって思ったんですけど、
そういう感じになってるんですね、エンジンXの感じというか、
そういう想定で作られてるっていうことなんですね。
だからこそエンジンXってめちゃくちゃ使われてるんですよね。
なるほど。他の点とかあったりするんですか?
Nginxの多機能性と実用的な利用シーン
エンジンXって本当にHDPサーバーとして必要な機能、いろいろ入ってるので本当にたくさん機能があります。
なんでちょっと一つ一つ分解していこうかなと思っていて、
最近エンジンX使うっていうと、多分Docker系で使う人が多いと思うんですよ。
そうですね。僕もエンジンX使うっていうのはDockerの中で使ってますね、エンジンX。
そうなるとHPSとかはあんまり使わないと思うので、
Docker系で使ってる場合って多分静的ファイル配信と、
プロクシーしてアプリケーションにプロクシーするっていう機能が主に一番使われるかなと思っていて、
やっぱりその静的ファイルの配信っていうのもそのPHPとかアプリケーション側でやってしまうと、
さっき言ったアプリケーションがレスポンス回数までつかまれてしまうって問題もあるし、
エンジンXでそのファイル返すだけだったらやっちゃった方が楽。
あと最近のインターネットって、ブラウザーの使用上このヘッダーつけないとダメみたいなのがたくさんあるんですよ。
それはセキュリティ的な。
セキュリティ的にこのヘッダーつけておかないとダメだよねってヘッダーがたくさんあって、
そういうヘッダーも要は全エンドポイントにそれをつけたいってなると、
アプリケーションとかだといちいち処理書かないといけないとかってあるじゃないですか。
ちゃんとコントローラー側にこのヘッダーを返すみたいな設定をいちいち書かないといけない。
エンドポイントに書かないといけないってなるとめんどくさい。
エンジンX使うとここに全体にこのヘッダーつけますとか、
そういう簡単な処理、簡単なヘッダーつけるとかそういう処理だったら書けるのでエンジンXだと。
そういう処理をドッカーとかで使ってるんだったらそういう処理を書くのが一般的かなと思いますね。
そういう処理がアプリケーションを書き換えなくても簡単にできちゃうっていうのがエンジンXの魅力ですかね。
エンジンXのコンフを書き換えればそういった設定が一括でできるので、
入り口を書き換えれば全部のHTTPヘッダーの調整ができるから楽だよねってことですね。
あと静的ファイルもアプリケーション側に来ないしっていう感じで使う人が多いんじゃないかなと思いますね。
ちょっと今までエンジンXの特徴で言うと静的ファイル配信だったりとかリバースプロキシーだったりとかいろいろな役割はありつつも
ちょっと思うのが静的ファイル配信について疑問なのがエンジンXで静的ファイル配信をすると便利だよっていうのは分かるんですよ。
これどっちなんだろうなと思うのがエンジンXがあるからエンジンXの特性として静的ファイル配信が便利だよねになったのか
それとも後からこれ静的ファイル配信エンジンXの方が便利じゃねってなったのかどっちなのかなっていうのがちょっと思ってて
エンジンXがあるからその部分だけ静的ファイル配信で任せればいいやっていうことになってたのか
ちょっとなんか歴史的な経緯の話になっちゃうかもな
歴史的な経緯はそんな知らないですけど当時のことを考えると多分全部できたらいいよねって話だと思いますよ
要はファイルも配信したいしプロキシーもしたいしやりたいことをどんどん詰め込んでいった感じだと思いますね
やってったらそうだったっていう感じなんですかね
そうですねそれで言うと話しとれるけどエンボイっていうプロキシーサーバーも最近は使われてるんですよ
エンボイって本当にプロキシーサーバーの機能しかない
その代わりプロキシーサーバーとしての機能はいろいろあるんだけど
その静的ファイル配信の機能ってないんですよエンボイって
そうなんですねプロキシーのみっていう割り切ったものなんですね
プロキシーのみって静的ファイル配信っていうのはないので
そういうサーバーも最近は出てきてるんだけど
なんかちょっとファイル配信したいとかあると思うんですよね
エンジンXが結構気軽に使える
エンボイとかは結構なんか例えばドッカー上で使うとか
なんかそういうあとそのKubernetes上の仕組みで使うとか
なんかそういうの想定されてるんでそのファイル配信はいらなかったんだと思うんですよ
エンジンXはもう結構昔からあるんでサーバー上にあるファイル配信したいとか
なんかそういういろんな要件をちゃんと叶えるためにそういうのをやったんじゃないかなとは思いますかね
本当にシンプルにアプリケーションの前に立つもの
アプリケーションの前で捌くものっていうような形で設計されたから
静的ファイル配信もサポートしてるよねっていうような形なんですね
ちょっと話しそれたんですけど
他のところとかはどうなんですかね
いろんな機能をサポートしてるっていうエンジンXなんですけど
そうですね例えばエッジジップ圧縮とかもそうだし
エッジジップ圧縮するとだいたい5分の1ぐらいになるんですよ
もちろんものによるんだけど
なのでエッジジップ圧縮できるとレスポンスが5分の1ぐらいになると考えると
絶対エッジジップ圧縮した方がいいじゃないですか
それはそうですよねレータリングが高速になるなら
クライアント側の
レータンシーが縮むんですよねその待機料量が減るからエッジジップ圧縮すると
なので絶対エッジジップ圧縮したいんですよ
例えばエンジンX上でCSSとかJavaScript配信しますってなったときに
そのCSSとかJavaScriptがエッジジップ圧縮されてないとまずいよくないので
そういうのも簡単な設定でエンジンXはエッジジップ圧縮してくれるし
あとそのリクエストそのアプリケーションが作ったレスポンスも
アプリケーションサーバーがエッジジップ圧縮してないんだったら
エッジジップ圧縮エンジンXするってこともできる
そういうエッジジップ圧縮の機能もあるしあとアクセスログ機能もある
そのアクセスがあったときにそのログを全部残すって
アプリケーションでやろうとするとかなりめんどくさいと思うんだけど
エンジンX全体に挟んでおけば全部自動でやってくれるっていう機能もある
レスポンス結果のレスポンスまでアクセスログにちゃんと記録されてるって感じ
そのレスポンスのステータスコードとかそういうの保存したいってなっても
エンジンXだったら簡単にできる
なんかエンジンX単純にアプリケーション
ウェブアプリケーションウェブサーバー作るんだったら
エンジンX使わないといけないんじゃないかなぐらいのものですよね
そう思ってますよ自分はなんでエンジンXはめちゃくちゃ使うし
あとDockerとかが主流になってもやっぱりエンジンX全体に挟んだほうが
Nginxの競合と進化：Envoy、Pingora、FreeNginx
設定とかいろいろかけるんで便利ってことが多いと思いますね
ですよね
さっきの話でもあったエンボイとかもあったかなと思うんですけど
ただエンボイの場合はプロキシサーバーに割り切ってるっていう話だったんで
ちょっと違うのかなと思いつつも
エンジンXの他の手段になり得るツールとかってあったりするんですかね
エンジンXのライバル的な存在で
ライバル的な存在いるんですかね
なんか自分あんまりパッとは思いつかなくて
ですよね僕自身もあんまり思いつかなくて
ただ一応さっきクラウドフレアがエンジンXの話を使ってた話をしたんだけど
今クラウドフレアは実はラストで自前でエンジンXみたいなのを作っていて
それで動いてたりはするのでそういう実装は一応あるはある
あとCDNのFastlyで使われているH2Oっていうやつもソースコード公開されていて
エンジンXに近い機能はいろいろあったりはするんだけど
どちらもあんまりドキュメントがしっかりしてない部分があって
実際の開発者の人が使うっていう想定で
あんまり外部の人が使うことをそんなに想定してないんじゃないかなっていうのが
自分の見たてなんですよね
なるほど
やっぱりちゃんとドキュメントも整備されていて利用実績も多いってなると
やっぱりエンジンXなんじゃないかなと思ってますね
じゃあ結構エンジンX唯一無二というか
自前で作れるような会社は自前で作りつつ
基本的な普通にウェブサーバー運用してるような会社だったら
エンジンX使う他なさそうだなっていう感じですね
他にないわけじゃないけど
やっぱりちゃんとドキュメントが整備されてるとか
実績が多いってなると
エンジンXが一番無難だと自分は思いますね
エンジンXの開発 現状の開発みたいなところはどうなんですかね
OSSとして開発されてるかなと思うんですけど
結構活発だったりするんですかね
そうですね ちょっと前一時期滞った時期があったんですけど
今はもともとGitHubじゃなかったんですよ エンジンXって
リポジトリがホスティングしてる
そもそもGitですらなくて
マーキュリアルっていうGitのライバルのやつをもともと使っていたんですよ
けどちょっと数年前にGitHubに開発が全部移ったんですね
そのタイミングでかなり開発が活発になってきてるっていうのが現状だったりします
なんか変わった理由あるんですかねGitHubに
これ公式では何も言われてないんですけど
これ多分自分の予想だと
フリーエンジンXっていうフォークの存在があると思ってます
エンジンXのフォークで
前のエンジンXビルドの時もちょっと話したと思うんだけど
フリーエンジンXっていうフォークが出てきて
フリーエンジンXがいくつか機能を足し始めたんですよね
そのタイミングでエンジンXも多分やばいと思ったのか
それでGitHubに移してもっと開発を活発にさせようっていう動きをし始めたっていう感じですね
なるほどちょっとライバルがフォークによって
自身のフォークによってライバルが出てきて
少しだけどうなのかわからないですけど焦ってきたから
ちょっと体制として整えて開発を高速化していこうというような
体制になっていったっていうのがありそうなんですかね
自分の勝手な想像ではある
特に公式でそういうことを言ってるわけではないけど
自分が見てる限り時系列的には完全にそうって感じだね
実際でも開発が活発になってきてるっていうようなことなので
そのフリーエンジンXがフォークされて
開発エンジンX本体のほうが活発になったっていうのは
すごい良い話ではありますよねやっぱり
そうですね結構その後から色々自分も期待した機能いくつか足されたんで
結構良いですよその後は
その足された良い機能とかって何かあったりします具体的に
Nginxの機能追加と有料版からの機能降格
そうですね具体的に言うと結構嬉しかったのは
DNSでプロクシーパス先を切り替えるって機能が出てきて
もともとプロクシーパスでプロクシーする先を書いておくと
そこにプロクシーできるですけど設定ファイル上で
プロクシーパスにDNSで解決する必要があるドメインっていうのを書くことができるんだけど
それが実はエンジンXが起動した時に1回解決するだけで
DNS切り替えても切り替わんなかったんですよエンジンXってもともと
なるほどずっと保持してしまうんですね
ずっと保持しちゃって例えばプロクシー先のアプリケーションサーバーとかDNSで管理してますとか
DNS切り替えたらプロクシー先のアプリケーションサーバー切り替わってほしいみたいなのあると思うんだけど
そういうのがエンジンXできなかったんですよ
なるほど
エンジンXをリロードとかリスタートするとDNSのキャッシュ全部吹っ飛ぶんで
リロードが必要だったんですよ今まで
それがもともとエンジンXって有料版もあるんですよ
エンタープライズ版
エンタープライズ版みたいなエンジンXプロだったかな名前は
その有料版もあってその有料版にはもともとDNSでちゃんと切り替えるって機能あったんですよ
けど無料版にはなくてずっと
それがGitHubに移ってから無料版に降りてきたんですよねその設定が
なので結構開発環境とかでも
例えば開発環境とかでもDockerでDNSでコンテナー名書いてきたりするじゃないですか
なのでDocker上のエンジンXでプロクシーパスでDockerのコンテナー名書いてますって時も
結局なんか例えば起動再起動とかあって切り替わっちゃった時に
切り替わらなかったんですよ今まで
ちょっと面倒ですね
開発環境とかでも結構面倒くさい問題が今まであった
だけどそれができるようになりました
それは動的に変わるんですかね具体的に
そうですね
切り替わるタイミング何なんですかね
確かに設定ができるんですよ何秒間キャッシュするみたいな設定ができて
例えば10秒間キャッシュしますとかそういう設定ができるんですよ
エクスパイアの設定ができるんですね
設定できるはず
時間を
なんか毎回そのDNSのキャッシュを取り直すっていう話ですよね
だからその10秒で1回とか
そうですねそれ設定できます今のエンジンXなら
そういう元々は有料機能だったやつがフリーに落ちてきてるみたいなの結構あったりするんですかね
結構ありますねエンジンXは
他にあったりしますか知ってるやつ
他嬉しいやつなんかちょいちょいそういうのあるんですよちょっと今パッと出てこないけど
そのDNSのやつについてはもうずっと何年もずっと言われてきたやつだったので
もう本当に降りてきたときはもう自分はめちゃくちゃ嬉しかったですね
大歓喜ですねじゃあ
これのせいで自分なんか例えばGoでプロクシーサーバー自作したりとかしてきたんで
全部やらなくてよくなったって感じですね
なんとなく思うのがそういうDNS系の今エンタープライズから降りてきた機能とかって
何ですかね結構重要な機能じゃないですかエンジンX使う上で
しかも開発環境においても面倒くさかったことがあったっていう
そもそもの問題がありつつ
なんていうかエンジンXの開発の方針として
有料機能はこういうのがあるで無料はこういうのが使えるみたいないうのが
結構割とはっきり分かりやすくなってるとすごい使いやすいなあとは思いつつも
そういう選挙機器どうなってるんですかね開発の
なんかその辺は自分もよくわかってないんですけど
やっぱりエンジンX使いやすくするために有料版を無料版でも使えるにしますよっていうのは
過去何回かアナウンス出てるはずで実際いくつか降りてきたっていう経緯があるし
あと結構エンジンXのドキュメント見ると
使いたい機能がドンピシャでプロだったりするプロ用だったりするんですよ
そういうのはやっぱりなんかドキュメントは結構どっちも同じところにあったりするんで
ちょっとこれ使いたいのにプロかみたいなのは結構エンジンX使ってるとありましたね
割とあるって感じですね
割とありますね
その時は普通にお金払いってことですね
お金払いってことですね
特に企業で使ってる場合はってことですかね
そうですね
ちょっと個人で実験的に使うときにお金払うっていうのはちょっとあれですけどね
確かに結構サポート込みなんで結構高いやつなんですよ
サポート込みなんですね機能だけ使えるとかそういう話じゃないんですよね
ではないですね
なるほどちょっとなんかハードルは高めですね
結構ハードル高めだと思います
ありがとうございます
なんか動きとしてあれですよね別にフリーエンジンXができたからといって
全て無料機能に落ちてきてるって話でもないですもんね
そういう話じゃなくて要所要所でやっぱり要望が大きかったやつが降りてきたりとか
あと地味に使いやすくなっていて今までエンジンXってプロクシーがHP 1.0だったんですよ
HP 1.0になるとコネクションのキープアライブっていう設定ができなかったりとかするんで
HP 1.1に上書きするっていうのが結構一般的で結構みんなコピペでHP 1.1にするって設定をみんなコピペで使ってたんですよ
それがつい最近エンジンX 1.29.7からかな
ステーブルだと1.30からなんだけど今最新のステーブル版でプロクシーのHPバージョンが1.1がデフォルトになったんですよね
なので今までみんながコピペしてきたような設定がいらなくなってきているっていうところでこういう地味だけど
そういうところでちょっとずつでも開発だったりとか利用しやすくしようっていうのは最近よくあるなと思っていて
なのでちゃんと機能追加とかそういう機能変更とかもちゃんと入れてきてるっていうのが最近のエンジンXですね
なるほどちなみにプロクシーHTTPバージョン1.0と1.1で何が違うんですかね
Nginxのバッファリング、キャッシュ、そしてUNIX哲学
たぶん一番大きい違いはキープアライブですね
1.0だとプロクシーパス先とのTCPコネクションとか毎回切っちゃうんですよ
なので毎回TCPの通信やり直さないといけないんですけどこれ使っておくとキープアライブって設定で常にTCPのコネクション貼れるんで
0.4が良くなるというか0.4が低くなるっていう感じですね
なるほどちょっとだけ早くなるってことですね
ちょっとだけ早くなる
他にもちょっといろいろな機能が入ってるって感じですね1.0と1.1で
1.0と1.1だと1.1でしか使えないHTTPヘッダーとかもあるので基本的にはめんどくさいから1.1に常にするのが正しいというか
今時も1.0使ってる人いないんで1.1にするのが楽です
なるほどエンジンXでHTTP2とか3とかに対応してるんでしたっけ
その辺はOpenSSLをエンジンXでTLSとか使いたい場合はOpenSSLが必要なんですけど
そのOpenSSLのバージョンとかにもよるんですけどHP2とHP3を有効にすることはできますねやろうと思えば
機能としてサポートはしてるんですねエンジンX
サポートはしてるんだけど気を付けてほしいのはプロキシーパスでHP2とかHP3っていうのは指定できないですね
プロキシーとして使うことはできない
プロキシー先でHP2のリクエストを送るっていうのはできない
それはHP1.1か1.0で
ユーザーがエンジンXにリクエストするときの
言うときはHP2とHP3は使える
なるほどちょっと片手落ちというかということですかね
片手落ち
片側だけと言えば片側だけだけど
なるほどちょっとそこのHP2とかHP3とかぶっちゃけどう利用していくのかっていうのが僕自身あんまり分かってないんですけど
なのでエンジンXというか
その辺はちょっとまた別でHP2とかHP3特集みたいなのやりましょうか
やりたいですね
エンジンXの話でもまだ全然話せてないことたくさんあるので
そこだけもうちょっと話して今回終わりにしましょうか
そうですねじゃあ最後に何かありますかね
そうですねまだ言えてないことたくさんあると思っていて
例えばリクエストとかレスポンスのバッファリングっていうのをエンジンXってやってくれるんですよ
リクエストのバッファリング
そうですねさっきもちょっと話したような
例えばPHPがいたらそのPHPがレスポンスを返しましたと
そしたらエンジンXがそのユーザーに返すためにそのレスポンスをバッファリングしておいてユーザーに少しずつ返すっていうこともできるし
例えば
なんでそんなことするんですかね
そうしないとユーザーがユーザーの帯域の問題で受け切れないことがあるじゃないですか
なるほどクライアント側の問題で
クライアント側に速度合わせてバッファリングしてゆっくり返すとかっていうのもやってくれるし
あと例えばユーザーがめちゃくちゃでかいファイルをアップロードしますとかそういうときもリクエストをバッファリングするっていうこともできる
エンジンXでいたら受けとくってことですよねアップロードのファイルを
受けるっていうのもできるし本当にでかかった場合はメモリに乗り切んないので
エンジンX側でファイルを実際に書き込んで大量のすごいでっかいリクエストっていうのを受け切れるような設定っていうのもできる
テンプファイルとして実際に実ファイル出しちゃうってことですよね
実ファイルって書き込んでメモリを使わないようにして書き込みきったらそのレスポンスでまた送るとかっていうのもできるし
あとキャッシュとかもできるんですよ
エンジンXでプロクシー先のところでレスポンス返ってきましたそのレスポンスをキャッシュして次回からはエンジンXが直接返しますみたいな設定もできる
それがあれですよね静的ファイル配信とかで使われる
静的ファイル配信でもそうだしアプリケーションが生成した例えばJSONとかをエンジンX側でキャッシュしておくってこともできる
なるほどでそのキャッシュのエクスパイヤーとかは設定できるってことですね
設定できますね
時間で
そのキャッシュコントロールで返せばその分キャッシュしてくれるとかもできるし
なんでエンジンXでそれキャッシュするようなシステムを作ってエンジンXですごいゴリゴリにキャッシュするみたいなのもできるし
本当にエンジンXがあるといろんなことができるっていうのが強みですねエンジンXの
めちゃくちゃ便利ですよねやっぱり
今ちょっと気になった話聞いてて気になったのがキャッシュをするところなんですけど
いわゆるそういうキャッシュとかをアプリケーション層で実装する場合って
例えばRedisとか使ってキーバリューでキャッシュしておいて
DBから引っ張ってこないでRedisから返すみたいなことをするかなと思うんですけど
エンジンXのキャッシュってどういう実装になってるんですかね
エンジンXのキャッシュはファイルで実際に書き込まれているだけなんだけど
なるほどファイルに書き込んでるんですね
手元のファイルそのまま設定できるんですよキャッシュのパスっていうの
そこに書き込んでいるだけではあって
ただやっぱりアプリケーション側で例えばRedisでキャッシュしてますってなって
結局アプリケーション側でRedisの値取得してきてまた作って返すっていうのは必要じゃないですか
必要ですね
なんでエンジンXでファイルだけポンって保存されていてそのファイルがポンって返ってくるだけだったら
それが最速なんですよ間違いなく
なので本当にアプリケーション側に一切リクエストがいかないので
一番早いのは基本的にエンジンX上でやるってやつだと思いますね
なるほど本当にシンプルなアーキテクチャなんですねエンジンXのキャッシュとかを
ファイルとしてテンポラリーなものが全部書き込まれててっていうような形なんですね
そうですねそれがシンプルかどうかっていうのはちょっと
例えばキャッシュがエクスパイヤーしたときに削除する処理とかもあるんで
エンジンXってキャッシュ使うとキャッシュ管理用の専用のプロセスが立つんですよ
そこでエクスパイヤーしたら削除するとかそういうことも頑張ってやってるんで
単純かっていうとそんな単純じゃ多分ない
マネージャープロセス的なものが立つんですね
キャッシュマネージャープロセスみたいなのが立つんですよ
なので実装自体は多分頑張ってやっている
確かにそれを聞くとめちゃくちゃ大変そうな実装になってそうですねエンジンXの中身は
エンジンXの中身は多分大変なんだけどけど使ってる側からするとすごい使いやすい
あんまり考えることはないですね
なるほどなかなかやっぱ前回の前回何回目だ5回目かな
5回目に話したシステムDのお話でもあったかなと思うんですけど
システムDがめちゃくちゃいろんな機能をサポートしてると
ちょっとUNIX哲学的に合わないよねみたいなそういう話あったかなと思うんですが
エンジンXもいろんな機能サポートしてるじゃないですか
UNIX哲学的に言うと単機能とは言えないかなと
その流度はいろいろあるとは思うんですけど
一つのことにうまくするみたいな話ではエンジンXもないのかなと思うんですけど
HTTPに関してうまくやるっていう形なので
UNIX哲学に反してるとは自分は思ってないし
あとリクエストとレスポンスって他のプロセスに渡すってなると
それだけメモリーコピーが走っちゃうじゃないですか
なのでコピーすればコピーするほどどんどん遅くなってくるんですよ処理としては
オーバーヘッドがかかってくるんですよね
どんどんオーバーヘッドが増えていくし
そうなるとやっぱりエンジンX単体でちゃんとリクエストとか受け取ってレスポンス返すっていうのが
エンジンX単体でできるっていうのはやっぱりレイテンシー考えても非常に重要
なのでやっぱりそこは理由がちゃんとあると思いますね
いいですね
UNIX哲学にも基本的にはHTTPというウェブサーバーというような範囲でおいては
特に違反もしてなさそうだし
妥当だと思いますね
その中でうまくやるっていうことなんですね
今後の展望とまとめ
そうですね
すごいめちゃくちゃエンジンXについてまだ全然多分話してないような
全然まだある機能
そうかなと思いますけどちょっといろんな角度から今後もいろんな話できればなと思うんですけど
ちょっといい時間になったんで最後に何かエンジンXについて言っていきたいことありますか
そうですね今回ちょっとエンジンXの基礎よりというか
実際例えば開発環境で使うときに何で使うんだろうとかそういう疑問に答えられたかなと思っていて
もっと突っ込んださっき言ったHP2とかHP3とかもっとエンジンXの突っ込んだ使い方っていうのは
また別の回でいろいろ話しできればなと思っているので
今後期待ということでよろしくお願いします
ありがとうございますということで今回ここまでにしたいと思います
ヤオヨロズのOSSでは毎回一つのOSSを取り上げて
それについて片付いたエンテコで技術的なところも深掘りしながらお話をしていく番組になっています
今後もその名の通りヤオヨロズのOSSを取り上げていけたらなと思っていますので
ぜひお聞きのプラットフォームでフォローと高評価のほうをお願いします
またこのOSSについても取り上げてほしいなどありましたら
コメントなどで教えていただけると取り上げますのでぜひお願いします
そして感想もぜひお待ちしておりますのでよろしくお願いします
Xなどでつぶやく際にはハッシュタグヤオヨロズのOSSを付けてもらえると非常にうれしいです
それでは今回もありがとうございました
ありがとうございました