次世代Webコンテナ Undertowについて

Copyright(c)2014 NTT Corp. All Rights Reserved. 1
次世代 Web コンテナ
Undertow について
田邊義真(NTT OSSセンタ )
2014-06-25
JJUG ナイトセミナー「 WildFly 8ローンチ記念」

前提
●
動作確認環境
– WildFly 8.1.0.Final
●
Undertow 1.0.15.Final
●
standalone モード
– Fedora 20
– OpenJDK 8
●
記述方法
– CLI 利用箇所は [CLI] と記述します
– ターミナルは [Terminal] と記述します
●
検証内容
– 手元環境での簡易な負荷試験を実施

アジェンダ
Undertowとは
アーキテクチャ概要
設定ポイント
Undertowいろいろ

Undertow とは

WildFly の Web/Servlet コンテナ
Undertow は
WildFly から導入された
Web/Servlet コンテナです

Web/Servlet コンテナの歩み
●
JBoss Web(AS7以前 )
– http://jbossweb.jboss.org
– Tomcat ベース
●
パフォーマンス強化
●
クラスタリングは別実装
●
その他いろいろとカスタマイズされている
●
Undertow(WildFly から )
– http://undertow.io
– スクラッチ
●
初コミットは 2012/07 。当初は Texugo という名称
●
基盤は XNIO(NIO ラッパフレームワーク )
– http://xnio.jboss.org/

Undertow が生まれた背景
●
なぜ新しい Web サーバが必要なのか
– Web の発展と共に Web サーバへ求められる機能が増加している
( これからも増え続ける ) 。
– 様々なユースケースに対応できる、柔軟性の高いサーバが欲しい
●
抽象化、使いやすさとカスタマイズ性を両立するために、 XNIO を採用
した。 XNIO は NIO のラッパーで、冗長さの排除とダイレクト I/O と
OS とを統合する API といった低レイヤ I/O 層を提供するが、それ以上
は踏み込まない。また、後方互換性にも優れている。
– Undertow FAQ より
●
http://undertow.io/documentation/faq.html
– また、全体的にクラウド上での利用を強く意識しているように感
じます

特徴 1. 軽量
●
コア jar のサイズは 1.3MB 程度
●
ヒープサイズ 10MB 以下で起動
– ※ ごくごくシンプルな設定の場合で試行

特徴 2. 組込み可能
●
従来の Web/Servlet コンテナとは違い、必要
なものを組み合わせて使うというアーキテクチ
ャ ( 後述 ) により、アプリケーションに容易に
組み込み可能
– ※ 本資料の主な内容は、 WildFly の 1 サブシステ
ムとしての利用を想定しています

特徴 3. Blocking/Non-blocking API
●
Undertow はブロッキング / ノンブロッキング
API 両方を提供する
●
Servlet や WebSocket など、使う API によっ
てブロッキングとノンブロッキングのどちらで
処理するか自動的に使い分けられる

特徴 4. HTTP Upgrade Support
●
WebSocket 対応とリスンポート削減
– WebSocket(JSR356) 対応に HTTP Upgradeが必要
– EJB や JMS 等、独自プロトコルを利用するものを HTTP
Upgrade 経由で接続することで、リスンポートが削減された。
– 1 筐体 /VM インスタンスに複数サーバが実行される PaaS 環境に
有効
$ ss anp | grep <as7pid>
tcp LISTEN 127.0.0.1:8080 < http
tcp LISTEN 127.0.0.1:4447 < remoting
tcp LISTEN 127.0.0.1:5445 < messaging
tcp LISTEN 127.0.0.1:9990 < managementhttp
tcp LISTEN 127.0.0.1:9999 < managementnative
$ ss anp | grep <wildflypid>
tcp LISTEN 127.0.0.1:8080
tcp LISTEN 127.0.0.1:9990
※ 出力内容は抜粋しています

アーキテクチャ概要

Undertow の構成要素
●
XNIO Worker
●
リスナ
●
ハンドラ

XNIO Worker
●
IO スレッド ( リスナ ) とタスク ( 処理 ) のスレ
ッドプールを管理

リスナ
●
リクエストの受け付け、 HttpServerExchange という
リクエスト / レスポンス情報を持つインスタンスへの変
換、クライアントへのレスポンスを担う
●
HTTP, HTTPS, AJPが組込まれている
– 今後 SPDY もサポートされる予定
●
IO スレッドと紐付いている
●
処理はタスクのスレッドにディスパッチする
●
利用 API によってタスク中の I/O 処理が切り替わる
– Servlet: ブロッキング
– WebSocket, Async Servlet:ノンブロッキング

ハンドラ
●
処理を行う単位
●
複数のハンドラを登録し、チェーンさせること
で全体としての処理を形成する

ハンドラチェーン
出典 : Entering Undertow Web server
http://www.javacodegeeks.com/2014/01/entering-undertow-web-server.html

コード片からイメージをつかむ
●
組込み Undertow のコード例 ( ビルダ API)
– “Hello World” を返すだけの http サーバ
Undertow server = Undertow.builder()
  .addHttpListener(8080, "localhost")
  .setHandler(new HttpHandler() {
    @Override
    public void handleRequest(HttpServerExchange ex) throws Exception {
      ex.getResponseHeaders().put(CONTENT_TYPE, "text/plain");
      ex.getResponseSender().send("Hello World");
    }
  }).build();
server.start();

●
  .addHttpListener(8080, "localhost") < HTTP リスナのバインディング
    @Override
    }
  }).build();
server.start();

●
  .setHandler(new HttpHandler() { < ハンドラ ( 処理内容 )
    @Override
    }
  }).build();
server.start();

●
  .addHttpListener(8080, "localhost") < HTTP リスナ
    @Override
    }
  }).build();
server.start();
リクエスト / レスポンス情報

●
    @Override
    }
  }).build();
server.start(); < ビルド情報をもとにサーバ起動

●
ハンドラチェーンの例
public interface HttpHandler {
  void handleRequest(HttpServerExchange exchange) throws Exception;
}
public clss MyHandler implements HttpHandler {
  private final HttpHandler next; < 次のハンドラ。コンストラクタで設定
  @Override
    // 何らかの処理
    next.handleRequest(ex); < 次のハンドラの処理を実行
  }
}

ハンドラの集合
●
Undertow はハンドラの集合であり、一般的な
コンテナのイメージとは違います
●
WildFly の中で Undertow を使う場
合、 Web/Servlet コンテナとして動作するの
に必要なハンドラが適切に設定されて起動され
るため、普段は意識する必要はありません

設定ポイント

設定ポイント ... の前に

その前に ... 設定方法
●
AS7 からシンプルに
– AS6 以前
●
設定ファイル : 各所に分散
●
設定方法 : 基本的に xml 直接編集
– AS7 から
●
設定ファイル : 一箇所 (standalone*.xml) に集約
●
設定方法 : インターフェースが強化されました
●
設定方法あれこれ
– CLI
– Web コンソール
– 設定ファイル (standalone*.xml) 直接編集

設定方法 1. CLI
●
慣れてきたら CLI がおすすめ
– 慣れるまで少々練習を要するかも ( 個人の感想 )
●
タブ補完が利く
●
スクリプト化して再利用がしやすい
[Terminal]
$ cd <WILDFLY_HOME>/bin
$ ./standalone.sh < WildFly の起動
$ ./jbosscli.sh c < CLI の起動
[CLI]
[standalone@localhost:9990 /] < プロンプトが変わる
※ 以降ではプロンプトは省略いたします

設定方法 1. CLI
[CLI]
ls l / < 管理リソース一覧をルート※から表示
ATTRIBUTE                VALUE       TYPE
[...]
releaseversion          8.1.0.Final STRING
[...]
CHILD                MINOCCURS MAXOCCURS
coreservice         n/a        n/a
deployment           n/a        n/a
deploymentoverlay   n/a        n/a
extension            n/a        n/a
interface            n/a        n/a
path                 n/a        n/a
socketbindinggroup n/a        n/a
subsystem            n/a        n/a
systemproperty      n/a        n/a
※ 管理リソースはツリー構造になっています

設定方法 2. Webコンソール
●
GUI(Web ブラウザ ) 上の操作のため直感的
– おおまかに何が設定できるのかを確認するときにも
おすすめ
●
ただし、設定できない項目もある
– CLI は全ての項目が設定可能
[Terminal]
$ cd <WILDFLY_HOME>/bin
$ ./adduser.sh < 管理ユーザ (Management User)を作成しておく
$ ./standalone.sh < WildFly の起動
ブラウザで以下 URI にアクセス
http://localhost:9990

設定方法 2. Webコンソール

設定方法 3. standalone*.xml 直接編集
●
非推奨
●
タイポやコピペミスによる設定不備が起きがち
●
何をしたか記録に残らない
– CLI, Webコンソールで行った設定は以下に記録
●
<WILDFLY_HOME>/standalone/configuration/standalone_xml_history
●
デフォルト値で設定されている項目はほとんど
表示されない
●
CLI での管理リソースのデータ構造と xml スキ
ーマは完全一致していない

設定方法 3. standalone*.xml 直接編集
●
とはいうものの、全体の構成をつかむために眺
めておくのも有用です
server
├ extensions
├ management
├ profile
├ interfaces
└ socketbindinggroup
※ その他、必要に応じて path や deployments 属性が追加される

気を取り直して設定ポイント

io サブシステム

●
Undertow は /subsystem=io に依存
– リスナ ( 後述 ) が下記 2 項目を参照しており、性能
面での実質的なチューニングポイントになる可能性
が高い
●
Workers
●
Buffer Pool

●
Workers( 緑字はチューニング検討項目 )
– Stack size: スレッドのスタックサイズ。デフォルト 0(= 指
定しない )
– Task keepalive: 同一クライアントからのリクエストに対す
るコネクションを何秒維持するか。デフォルト 60 秒
– IO threads: リクエストを受け付けるスレッドの数
– Task max threads: IOスレッドからディスパッチされるタ
スクスレッドの最大数
– Task core threads: タスクスレッドの最小数 ( デフォルト
2)
●
無効なパラメータの可能性あり。 xml スキーマ中に存在しない = 永
続化されない , XNIO中で無視されている ?

●
IO threads
– リクエストを受け付けるスレッドの数。ノンブロッ
キングな処理を行う
– デフォルト : 利用可能 CPU 数 *2

●
Task max threads
– IO スレッドからディスパッチされるタスクスレッ
ドの最大数。 Servlet などはブロッキングされる
– デフォルト : 利用可能 CPU 数 *16

●
IO threadsと Task max threads
– チューニングではこの 2 オプションがキー
– サーブレットを使った簡易な検証では、 Task max
threads の変更に効果がみられました
●
実際にタスク ( ブロッキング処理含む ) を実行するスレッ
ドなので、 CPU リソースに見合った数を用意するべきと
考えます
– IO threadsで実行する処理はノンブロッキングで
あることも考えると、 IO threadsは相当な高負荷
である場合チューニングを検討するといったパラメ
ータかもしれません

●
Buffer Pool(以下デフォルト値 )
– Buffer Size: 16KB
●
バッファサイズ。一般的に 1 回の write() 呼び出しで送
られるサイズが 16KB なのでこの値は最適
– Buffer Per Slice: 20
●
バッファの分割数。大きなバッファを分割して操作し、
バッファ全体を処理する際のオーバヘッドを回避しま
す。
– Direct Buffers: true
●
バッファをダイレクトバッファとして利用するか
※ 上記デフォルト値は利用可能なヒープサイズが 128MB 以上の時の値です。

undertow サブシステム
●
/subsystem=undertow
– buffer-cache
– server
– servlet-container
– configuration
– error-page

●
Buffer Cache
– 静的ファイルなどのキャッシュに利用
– 全体の容量は以下
●
buffer-size * buffers-per-region * max-regions
– 以下、デフォルト値
●
buffer-size: 1024
●
buffers-per-region: 1024
●
max-regions: 10

●
Server
– Undertow 全体の設定
●
リスナ
●
ホスト
– 設定したハンドラやフィルタをひもづける ( 後述 )

●
Server -> Listener
– リクエストの受け付け、レスポンス処理
CLI でリスナの設定を確認する
---------------------------------------------
[CLI]
cd /subsystem=undertow/server=defaultserver/httplistener=default
:readresource
{
    "outcome" => "success",
    "result" => {
        [...]
        "bufferpool" => "default", (1)
        [...]
        "recordrequeststarttime" => true,
        [...]
        "worker" => "default" (2)
    }
}
(1)(2) ioサブシステムで定義したものを参照

●
Server -> Listener
[Tips]CLI でリスナの設定を変更する
-----------------------------------------------------
[CLI]
:writeattribute(name=recordrequeststarttime,value=true)
{
    "responseheaders" => {
        "operationrequiresreload" => true,
        "processstate" => "reloadrequired"
    }
}
/:reload
リロードが必要なものの場合表示される

●
Server -> Listener
[Tips] 設定項目の内容 ( 型、説明、デフォルト値など ) を確認する
-----------------------------------------------------------------------------------------
[CLI]
:readresourcedescription
{
    "result" => {
        "description" => "http listener",
        "accessconstraints" => [...]
        "attributes" => {
            "recordrequeststarttime" => {
                "type" => BOOLEAN,
                "description" => “If this is true then ...”
            }
        }
    }
}

●
Server -> Listener
[Tips]CLI の出力をリダイレクトする ( 内容が多く標準出力では見えづらい場合など )
-----------------------------------------------------------------------------------------------------------------------
[CLI]
:readresourcedescription > /tmp/httplistenerdescription
[Terminal]
$ cat /tmp/httplistenerdescription
{
    "result" => {
        "description" => "http listener",
        [...]

●
Servlet Container
– Servlet コンテナ設定
CLI で Servlet コンテナの設定を確認する
----------------------------------------------------------
[CLI]
cd /subsystem=undertow/servletcontainer=default
:readresource
{
    "result" => {
        "allownonstandardwrappers" => false,
        "defaultbuffercache" => "default",
        [...]
        "uselistenerencoding" => false,
        "setting" => {"jsp" => undefined}
    }
}

●
Servlet Container
[Tips] 子要素 (setting -> jsp の設定も見たい場合
------------------------------------------------------------------------
[CLI]
:readresource(recursive=true)
{
    "result" => {
        [...]
        "setting" => {"jsp" => {
            "checkinterval" => 0,
            [...]
        }}
    }
}

●
Servlet Container
[Tips] :read-resource-descriptionも再帰的に確認できる
----------------------------------------------------------------------------------
[CLI]
:readresourcedescription(recursive=true)
{
        [...]
        "children" => {"setting" => {
            "description" => "The servlet container settings",
            "modeldescription" => {
                "jsp" => {
}

アクセスログ
●
デフォルトでは出力されない
[CLI]
:writeattribute(name=recordrequeststarttime,value=true)
cd /subsystem=undertow/server=defaultserver/host=defaulthost/setting
./accesslog:add(prefix=access,pattern="%t,%a,%m,%U,%s,%D")
/:reload
レスポンスタイムを出すのに必要 ( デフォルト false)
[Console]
$ cat <WILDFLY_HOME>/standalone/log/access.log
25/Jun/2014:20:00:00 +0900,127.0.0.1,GET,/,200,12
pettern に設定できる値は以下クラスの javadoc から確認できます。
io.undertow.server.handlers.accesslog.AccessLogHanlder
[Github]http://bit.ly/1jHlGs3

ルートコンテキストの変更
●
任意のアプリケーションを http://<yourdomain>/ でアクセ
スさせるためには以下の 2 ステップが必要
– welcome-content への参照 (File ハンドラ ) を削除
– アプリケーション中に WEB-INF/jboss-web.xml を作成する
[CLI]
cd /subsystem=undertow/server=defaultserver/host=defaulthost
./location="/":remove
[ 以下内容の WEBINF/jbossweb.xml を作成 ]
<?xml version="1.0" encoding="UTF8"?>
<jbossweb>
<contextroot>/</contextroot>
</jbossweb>

Session Cookie
●
WildFlyではグローバルなクッキー設定が可能
– comment
– domain
– http-only
– max-age
– name
– secure
例 : クッキー設定を有効化し、クッキー名の変更と http-only 属性を設定する

[CLI]
cd /subsystem=undertow/servletcontainer=default/setting
./sessioncookie:add(name=MYCOOKIE,httponly=true)
/:reload

Single Sign On
●
1 度の認証処理で複数の Web アプリケーショ
ンの認証を行う
ルート (/) を指定することで、全てのアプリケーションを SSO 対象にする。
“JSESSIONIDSSO” というクッキーを共有することで実現している

[CLI]
cd /subsystem=undertow/server=defaultserver/host=defaulthost/setting
./singlesignon:add(path="/")
/:reload

Persistent Sessions
●
セッションをファイルに永続化
<WILDFLY_HOME>/standalone/data/persistent-web-session に格納する場合
※path を指定しない場合、セッションはメモリに格納される

[CLI]
cd /subsystem=undertow/servletcontainer=default/setting
./persistentsessions:add(path=persistentwebsessions,
relativeto=jboss.server.data.dir)
/:reload
relative-to に組込システムプロパティを指定し、
<WILDFLY_HOME>/standalone/data を起点にしている

組込 Handler と Filter
●
ポータビリティとの兼ね合いを判断して利用
●
Handler: 特定のリクエストパスに対して適用
– file
– reverse-proxy
●
Filter: リクエスト全体に対して適用※
– basic-auth
– connection-limit
– gzip
– response-header
※Handler と組み合わせれば特定パスに適用可 ( 後述 )

File ハンドラ
●
httpd でのエイリアス相当
http://localhost:8080/img/<file-path> で /var/images/<file-path> にアクセス
---------------------------------------------------------------------------------------------------------------------
[CLI]
cd /subsystem=undertow/configuration=handler/file
./images:add(path=/var/images)
cd /subsystem=undertow/server=defaultserver/host=defaulthost/location
./"/img":add(handler=images)
/:reload

Reverse Proxyハンドラ
●
WildFly をリバースプロキシとして利用可能
host に設定した (1)(2) にラウンドロビンで振り分けられる
-----------------------------------------------------------------------------------
[CLI]
cd /subsystem=undertow/configuration=handler/reverseproxy
./myreverseproxy:add
cd ./myreverseproxy
./host=”http://192.168.0.20:8080/myapp”:add < (1)
./host=”ajp://192.168.0.30:8009/myapp”:add < (2)ajp も可
./"/myapp":add(handler=myreverseproxy)
/:reload

Basic Authフィルタ
●
ベーシック認証フィルタ
– 2014-06-25 現在、適切に動作しません
●
https://issues.jboss.org/browse/WFLY-3342
指定した security domainによるベーシック認証フィルタ
-----------------------------------------------------------------------------------
[CLI]
cd /subsystem=undertow/configuration=filter/connectionlimit
./myauth:add(securitydomain=other) < ※other は最初から用意されている
cd /subsystem=undertow/server=defaultserver/host=defaulthost/filterref
./myauth:add
/:reload

Connection Limitフィルタ
●
同時接続数を制限
同時接続数と待ちキュー ( バックログ ) を設定できる
-------------------------------------------------------------------------
[CLI]
cd /subsystem=undertow/configuration=filter/connectionlimit
./myconnectionlimit:add(maxconcurrentrequests=100,queuesize=5)
./myconnectionlimit:add
/:reload
HTTP リクエスト単位で制御したい場合やポータビリティが気になる場合は、
Servlet フィルタや JAX-RS フィルタを作成しましょう
[ 参考 ]
Tomcat や JBoss で HTTP リクエスト単位で並行実行数を制限するサーブレットフィルタ
http://nekop.hatenablog.com/entry/20120424/1335254637

gzip フィルタ
●
リソース gzip 圧縮
predicate で対象を指定する (gzip に限らず、フィルタは全てこの属性を持つ )
-------------------------------------------------------------------------------------------------------------
[CLI]
cd /subsystem=undertow/configuration=filter/gzip
./mygzip:add
./mygzip:add(predicate="pathsuffix['.css'] or pathsuffix['.js']")
/:reload
●
通常 WildFly の前段に設置したリバースプロキシで設定すると思われるので、あまり利
用することはないかも ... 考えられるとしたら以下のようなパターン ?
●
リバースプロキシ -WildFly 間の N/W 帯域を節約したい場合
●
リバースプロキシに CPU をあまり使わせたくない場合
●
WildFly がクライアントから直接リクエストを受ける場合

Response Header フィルタ
●
任意のレスポンスヘッダを追加
[CLI]
cd /subsystem=undertow/configuration=filter/responseheader
./myheader:add(headername=MyHeader,headervalue=MyHeaderValue)
./myheader:add
/:reload

Response Header フィルタ
●
デフォルトで設定されているヘッダを削除
[CLI]
./serverheader:remove
./xpoweredbyheader:remove
/:reload

ハンドラとフィルタの組み合わせ
●
特定のパスにのみ有効なフィルタ
特定パスのみヘッダを設定する例 ( 前述の /img と my-header を利用 )

[CLI]
./"/img"/filterref=myheader:add

その他機能
●
error-page
– 未実装 ? 調査中 ...

Undertow いろいろ

Undertow いろいろ
●
Spring Boot Starter Undertow
– https://github.com/isopov/spring-boot-starter-undertow
– 組込み Web サーバは ...Jetty? Tomcat? Undertow!
●
Hammock
– https://github.com/johnament/hammock
– RESTEasy + Weld + Undertow!
●
undertow-dev メーリングリストにて
– Undertow をリバースプロキシとして使いたい
– などなど
単体でも注目度が高くなってきている

最後に
●
Web はこれからも進化し、企業にとってもます
ます重要なものとなります
●
Undertow はモダン Web に追従するべく作られ
ました。また、従来のアプリケーションに対して
も申し分のないパフォーマンスを発揮するポテン
シャルを持っています。
●
とはいえ開発からまだ 2 年。ぜひ応援を !
– 機能不足やバグ報告があれば要望、さらには PR!
●
微力ながら私もアクセスログにおける機能追加案を投稿し
ました

参考
●
公式サイト
– http://undertow.io/
●
WildFly ドキュメント
– https://docs.jboss.org/author/display/WFLY8/Unde
rtow+(web)+subsystem+configuration
●
WildFly 8 Administration Guide
– http://www.itbuzzpress.com/ebooks/wildfly-8-book.h
tml
●
Dive Into WildFly 8
– 30:15~ からスペックリードによる Undertow の説明
– http://vimeo.com/79890483

参考
●
メーリングリスト
– https://lists.jboss.org/mailman/listinfo/underto
w-dev
●
JIRA
– https://issues.jboss.org/browse/UNDERTOW/

参考
●
Undertow のソースツリーを眺める - nekop の日記
– http://d.hatena.ne.jp/nekop/20131224/1387938098
●
Experiences with migrating from JBoss AS 7 to
WildFly 8.1
– JBoss Web -> Undertowの Tips も載っています
– http://jdevelopment.nl/experiences-migrating-jboss-7-wildfly-
81/
●
JBoss Enterprise Application Platform 6 構築・運用パーフ
ェクトガイド
– JBoss EAP 6 向けですが、 WildFly 利用時でもほとんどの内容
を踏襲できるので、初めて触る方にもおすすめです
– http://gihyo.jp/book/2013/978-4-7741-5794-8

次世代Webコンテナ Undertowについて

More Related Content

次世代Webコンテナ Undertowについて