Above & Beyond

日々のアウトプット記録

NGINX MeetUp Tokyo #2

02/12(火) は「NGINX MeetUp Tokyo #2」に参加してきました。

nginx-mj.connpass.com

f:id:kabukawa:20190210100817p:plain

会場は サイオステクノロジー さん。

f:id:kabukawa:20190212163407j:plain:w600 f:id:kabukawa:20190212163400j:plain:w215f:id:kabukawa:20190212164836j:plain:w385


目次


NGINX MeetUp Tokyo とは

グループの概要から引用します。

日本のNGINXユーザー、また関心をお持ちの方に向けてNGINX, Inc. CTO / Igor Sysoevを 招きNGINX最新情報をお届けします

NGINXとは

nginxというのは何か?公式サイトから引用すると

nginx [engine x] is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server, originally written by Igor Sysoev.
nginx [engine x]は、元々Igor Sysoevによって書かれた、HTTPおよびリバースプロキシサーバー、メールプロキシサーバー、および一般的なTCP / UDPプロキシサーバーです。

nginx.org

ソースとドキュメンテーションは2条項BSD風ライセンスの下で配布されています。

2月7日には東京オフィスも解説されました。日本でのサポートも更に手厚くなりそうですね!

www.nginx.co.jp


何故参加したか

元々以前の仕事で少しだけ使っていたこともあり、興味があったというのもありますが、 直接的にはJapan Container Days でブースを出されていて、そのつながりでイベントを知って参加することになりました。


タイムテーブル

時間 内容
16:30~ 受付
17:00~17:05 オープニング
17:05~17:50 セッション1 NGINX update

① NGINX OSS と Unit
 講師:NGINX, Inc. CTO / Igor Sysoev
 *逐次通訳付き

② NGINX Plus
 講師:NGINX K.K. テクニカルソリューションアーキテクト 鈴木孝彰
17:50~18:15 セッション2 NGINX Unit デモ

 講師:NGINX K.K. テクニカルソリューションアーキテクト 田辺茂也
18:15~18:30 ライトニングトーク (5分×3名 15分)
18:30~19:15 懇親会

内容

少し緊張した感じの中で始まりました。

f:id:kabukawa:20190212170043j:plain:w400

ただ、こういうMeetupの存在や内容について知ってもらうことでコミュニティの輪も広がると思いますので、次回参加するときはもう少しツイートなどもしていきたいなと思いました。

参加者へのノベルティの数々。

f:id:kabukawa:20190212163217j:plain:w600 f:id:kabukawa:20190212165056j:plain:w385f:id:kabukawa:20190212163253j:plain:w215


NGINX update

NGINXの Igor Sysoev さんは、創設者でありCTO。


NGINX OSS と Unit

NGINX, Inc. CTO / Igor Sysoev さん

[資料は公開されたら追記します]

f:id:kabukawa:20190212170437j:plain:w300

個人メモ:

新しいプロジェクトNGINX Unit

  • 開発を開始しているがかなり前が、本格的に開発し始めたのは2年前

アプリを実行できるプラットフォーム

  • PythonPHP、Go、PerlRuby、Node.jsの6言語サポート。Javaはもうすぐ
  • LinuxFreeBSDMacOSSolarisで動作。
  • コンフィグレーションファイルは存在しない。JSONのRESTFulAPIで行う。
  • ダイナミックに再設定可能。全体だけでなく部分的な変更も可能。

NGINX Unitの履歴

  • 2017/9月に最初のβバージョン公開
  • 2018年4月に正式版公開
  • 2019年2月に1.7.1を公開
  • オープンソースでApache2.0ライセンス

アーキテクチャ

f:id:kabukawa:20190213092946j:plain:w500

  • NGINX Unitのプロセスは main、controller、router に分かれている。

Controllerプロセス

  • RESTFul API経由でコンフィグレーションを取り扱う
  • 設定のコピーを読み込んで起動する
  • セキュリティ的な理由で

    • コンフィグレーションファイルは利用を推奨しない
    • 再起動時の設定用に用意されているもの
    • 空の状態からRESTFul API経由で更新していくことを推奨。
    • RESTFul API経由で設定が更新されると上書きされる
    • 非特権ユーザーで起動
    • UNIX ドメインソケットからしか接続できない
  • JSONで設定

    • JSONは便利だがコメントを入れられないなど不便なところもある
    • なので、別のDSLで書いて、それをJSONに変換するなどの工夫をしたほうが良い
  • curlなどのコマンドからRESTFul APIを呼び出してコンフィグレーションを反映/確認などを行うことができる

f:id:kabukawa:20190213093710j:plain:w500

  • ストレージへの反映(SSL認証鍵)もREST API経由で更新

Routerプロセス

  • ほとんどのアプリケーションの処理を行う
  • アプリケーションワーカープロセスにリクエストを転送したりクライアントとの接続をしたりする
  • 非特権ユーザーで処理を行う
  • いくつかのワーカースレッドを持っている
  • それぞれのスレッドがepoll/kqueueインターフェースを持っているの
  • 複数の処理を同時に処理を行うことができる

なぜこのようなアーキテクチャにしたか?

NGINXでは

  • NGINXでは共有ストレージを処理(キャッシュ)しなければならない
  • 共有メモリで処理していたが、この形で処理をするのは安全ではない
  • 例えば一つの共有メモリがログアクセスをしていて問題が起きた場合、他のプロセスが止まってしまう
  • このようなケースで信頼できるソリューションがないので、注意深くプログラミングをしなければならなくなってしまう。
  • マルチスレッドにすることでスレッドセーフにできる。
  • 2000年代の初めではLinuxBSD系ではスレッドに対するサポートが弱かったが今は違う。
  • 今はNGINXでもマルチスレッドでオフロードできるが、NGINX Unitとは少し違う。

NGINX Unitでは

  • NGINXのコンフィグレーションプロセスは1つのコンフィグレーションしか対応できない
  • NGINXのワーカープロセスはコンフィグレーションが変更されたときに古いものを削除して置き換える
  • NGINX Unitの方は複数のコンフィグレーションに対応している
  • 構成変更をした場合、更新前と後のものを認識している
  • Routerの中では複数のバージョンが存在し、それらはリクエストごとに別のものとして存在
  • 古いものは処理が終わるまではそれが使われるが、次からは新しい世代のコンフィグレーションで対応する
  • バインドされているリクエストが無くなった時点でそのバージョンが削除される
  • こうすることでメモリを有効利用できるようになる

アーキテクチャを変えた理由

  • NGINXは17年前に開発が始まったが、その頃は頻繁なコンフィグレーションの更新は想定されていなかった。
  • 今はクラウド環境では頻繁な更新が当たり前になってきたので、それに対応する必要がある。
  • それぞれの設定のたびにワーカープロセスが増えるのでメモリ使用量も増えてしまう。
  • NGINX Unitのやり方を適用することでメモリの利用効率を改善できる。

mainプロセス

  • どのポートもListenしない。
  • 特権ユーザーで起動
  • 非特権ユーザーでも起動は可能だが、ControllerやRouterのプロセスで起動/再起動するので特権ユーザーで起草する必要がある
  • リスナーソケットにBINDするためにも特権が必要
  • 一般ユーザーが見えないログファイルの作成などにも特権が必要
  • ログ作成はmainプロセスが担う
  • Controllerが443ポートをBINDしなければならないときRouterからmainにリクエストが転送され、処理される。
  • Logも同様

Applicationプロセス

  • Dropin置換で使用する場合アプリケーションの変更は不要
  • GoとNode.jsではちょっと変更が必要
    • Go
      • import "nginx/unit" して http.ListenAndServe() の代わりに unit.ListenAndServe0 を使う必要がある
    • Node.js
      • http = require ("http") の代わりに http = require ("unit-http") を使う必要がある
    • Unit固有のモジュールはフォールバックHTTP処理を提供するため、GoおよびNode.jsアプリケーションはUnitなしでスタンドアロンで実行可能

NGINX Unitのユニークなところ

  • 違うバージョンの言語も使う(共存する)ことができる
  • コンフィグレーションでバージョンを指定して別々の言語バージョンのまま動かすことができる
  • Controllerのコンフィグレーションでバージョン指定をできる。
  • バージョン指定がない場合は、NGINX Unitが最新バージョンを判断して使用する。

  • mainプロセスがアプリケーションを実行するときに必要なバージョンを見つけて起動する

  • アプリケーションをアップグレードするときに便利な機能。
  • データ転送にUNIX domainソケットペア、共有メモリセグメントを使う。
  • 共有メモリの使い方はNGINXとはちょっと異なる。
  • 安全上の理由で共有メモリの数を増やせない時に複雑な動きになる

Unitでの共有メモリ

  • オンデマンドで作成
  • 共有メモリとそれぞれのワーカープロセスを繋ぐ部分で使われている。
  • 個別部分での接続に使われているので、全体で一つの共有メモリにはなっていない。
  • 共有メモリが信頼できないものかもしれない場合に、通常の共有メモリの使い方だと全体が落ちてしまう。
  • Unitの共有メモリの使い方であれば、その部分だけを落とせばいいので、全体が落ちるようなことは防ぐことができる。

まとめ

NGINX Unitとは


NGINX Plus

NGINX K.K. テクニカルソリューションアーキテクト 鈴木孝彰 さん

www.slideshare.net

f:id:kabukawa:20190212180305j:plain:w300

個人メモ:

NGINX Plus

f:id:kabukawa:20190227010349p:plain:w500

NGINX Plus利用されているソリューション例

f:id:kabukawa:20190227010403p:plain:w500

  • HTTP/2
  • TLS 1.3サポート
  • 0-RTT

利用している環境のデモ

f:id:kabukawa:20190213100031j:plain:w300f:id:kabukawa:20190213100049j:plain:w300

ロードバランシング

  • 最小タイム(Plusのみ)
  • 多段のロードバランスもできるようになっている

f:id:kabukawa:20190227010446p:plain:w500

Stickyセッション(セッション固定)サポート

f:id:kabukawa:20190227010501p:plain:w500

利用している環境のデモ

f:id:kabukawa:20190213100443j:plain:w500

冗長構成サポート

  • アクティブ/スタンバイ

f:id:kabukawa:20190227010522p:plain:w500

ハードウェアからソフトウェアへ

  • F5とかを使っている場合に置き換え候補に

API Gatewayとして利用することも可能

f:id:kabukawa:20190227010547p:plain:w500

Kubernetes環境でもIngressコントローラーとしてNGINXを使える

f:id:kabukawa:20190227010602p:plain:w500

OpenShift環境でも同様に使える

NGINX WAF機能

  • レイヤ7の攻撃保護
  • パフォーマンスが2倍
  • IP reputation

f:id:kabukawa:20190227010620p:plain:w500

  • 各種LinuxなどのOS環境、Dockerlコンテナでも利用可能
  • クラウドの従量課金環境でも利用可能

f:id:kabukawa:20190227010635p:plain:w500


NGINX Unit デモ

NGINX K.K. テクニカルソリューションアーキテクト 田辺茂也 さん

[資料は公開されたら追記します]

f:id:kabukawa:20190212182821j:plain:w300 写真左の方

個人メモ:

Dockerhubにイメージがあるのですぐに試すことができる

hub.docker.com

NGINX Unitに設定を反映したりするデモを実施。

コンテナを起動した時の docker ps

f:id:kabukawa:20190213102010j:plain:w500

設定反映

f:id:kabukawa:20190213102259j:plain:w500

設定反映後

f:id:kabukawa:20190213102415j:plain:w500


LT:Nginx Cache Delete API

Yuki Iwamoto さん

www.slideshare.net

f:id:kabukawa:20190212182943j:plain:w300

  • 部分的なNGINXのキャッシュ削除をしたかったので作った

f:id:kabukawa:20190227011136p:plain

  • NGNIXのキャッシュはMD5ではッシュされたファイル名で保持されているので、それを探して削除すればOKなのでは?

  • Luaを使うといい感じでNGINXの処理を書くことができる

懇親会

腰痛がひどくて早々に退散しましたが、皆さん熱心に講演者や他の参加者の方と話をされていたのが印象的でした。

f:id:kabukawa:20190212184200j:plain:h400


まとめ

NGINXのオリジナルの開発者であり、NGINX社のCTOでもある Igor Sysoev さんの話を聞けたのはとても良かったです。 予定時間をかなりオーバーして話をされていましたが、アーキテクチャの話やNGINX本体との違いなど、とても興味深く聞くことができました。 また、NGINX Unitについても、ちょっと試してみたいなという気持ちになりました。

せっかくの内容だったので、もう少し外部への発信(ツイートなど)も行われるといいのに勿体無いと思ったのも確か。 このブログを読んで、興味を持って参加する人が増えてくれるといいなと思いました。

次回もできれば参加したいな、と思いました。 講演者、スタッフ、参加者の皆様、ありがとうございました!