さて、おまたせ致しました。
本日より、JJUGで発表したGrizzlyについて
紹介したいと思います。
まず、Grizzlyって聞いたことありますか?
「GrizzlyはGlassFishコミュニティの中のサブプロジェクトの1つで
JavaのNew I/Oを使って記述された汎用的なネットワークサーバエンジンです。」
Project Grizzly :
https://grizzly.dev.java.net/
Project Grizzlyによって開発された成果物(ネットワークサーバエンジン)は
GlassFishとは独立して単体で使用することができます。
また、Grizzlyは独自の進化を遂げていっています。
現在、Grizzlyの最新バージョンは1.7.3.1です。
今回紹介するGrizzlyは少しバージョンが古いのですが、
GlassFish v2.x系にバンドルされているGrizzly 1.0.x(1.0.19)について
紹介します。
●Grizzly誕生の背景
まず、Grizzlyのできあがった背景について説明します。
Grizzlyは元々GlassFishのHTTPをハンドリングするHTTPサーバを
開発するプロジェクトとして開始しました。
それまでのSunのアプリケーションサーバは、TomcatのCoyoteを
内部で使用していたのですが、GlassFishではCoyoteを使用せずに
JavaのNew I/Oを使用して実現するHTTPサーバとして実験的に
作成を開始しました。
(Grizzly1.0.19でもHTMLの解析等で一部apacheのAPIを使用してます)
そして開発を進めて行くに従い、Grizzlyの潜在能力の高さが判明してき、
HTTPだけではなく、他のプロトコルも扱うことのできる汎用的な
ネットワークサーバエンジンになりえることが分かってきました。
その結果、現在ではHTTP以外にTCP,UDPといった下位のレイヤー
プロトコルを始めとし、TLS,FTPやSIP等といったマルチプロトコルに
対応するハイパフォーマンスなネットワークサーバエンジンになっています。
ですので、仮に開発者が新たに独自のネットワークサーバを構築する
必要がでてきた場合、GrizzlyのAPIを一部拡張して実装して頂くことで
ハイパフォーマンスな独自ネットワークサーバを構築することも可能になっています。
例えば、GrizzlyのHTTPサーバエンジン以外の使用例として
独自のsyslogサーバを構築することも可能になります。
Grizzlyの背景とできることは上で説明しましたが、何故今ここで
Grizzlyという新しいネットワークサーバエンジン(フレームワーク)が
登場したのでしょうか。以下ではWebサーバの実装における過去の歴史と
Grizzlyが登場した理由を説明します。
●Web サーバの実装における歴史
Webサーバは古くはCERN,NCSA等といった所で作成されていましたが、
Apacheでhttpdが作成された後はApacheにシェアを奪われていきました。
こういった古いWebサーバや初期のApache httpdはプロセス起動型のサーバ
の実装になっていました。
このプロセス起動型のサーバではHTTPクライアントであるブラウザからリクエストがくる度に
httpdのプロセスを起動しリクエスト数が多くなると子プロセスをfork()して
処理を行っていました。
当時のWebサーバは今程リクエスト数も多くなく、FastCGI等も無いこの時代には
サーバサイドで実行するプログラム(Perl,C等のCGI)もfork()して子プロセスで
実行していました。
しかし、プロセスのfork()はシステム(OS)に対して多大な負担を掛けます。
そこで登場したのがマルチスレッド型のサーバです。
マルチスレッド型のサーバでは単一のプロセス内でリクエスト毎にスレッドを起動し、
各スレッドでHTTPの処理を行うことで、子プロセスを起動するよりシステムに対する
負担は大幅に軽減するようになります。
この頃になり、マルチスレッドサーバ上でサーバサイドで実行する
プログラムとしてServletが脚光を浴びました。
しかし、実際のWebサーバの実装は上に説明した程簡単ではありません。
上記の図中にスレッドの起動プログラム例を記載していますが、
Webサーバのように大量のリクエストを扱うようなプログラムの
場合、accept()の処理は負荷はあまり掛からないのですが、
スレッドの起動はaccept()の処理に比べ非常に負荷が高くなって
しまいます。
この状況ではパフォーマンスにボトルネックが生じます。
そこで、スレッドの起動に関する問題を軽減する為に、実際のWebサーバ
ではaccept()処理とスレッドの処理を分離し、間に接続キューを
設けることでaccept()の処理を素早く受け流すことができるように
なります。(SunのWeb ServerはC++で上記のように実装)
そして、実際にHTTPの処理を行うワーカスレッドが接続キューから
コネクションを取得し、HTTPの処理を行うようになります。
他のサーバの実装を細かく見たことはありませんが、恐らく現在の
Webサーバの実装は似たような実装になっているのではないかと
思います。
●マルチスレッドサーバの問題 (Blocking I/O型サーバ)
ソケット通信を行うプログラムを実装する場合、accept()や
I/Oのread(),write()等を使用しますが、これらのメソッドは処理を
ブロックします。
例えば、ServerSocket#accept()メソッドはクライアントが接続するまで
待ち状態になり、クライアントからの接続があって初めてメソッドの処理を
終了します。
複数のクライアントからの接続を処理できるようにする為には、
サンプルのようにスレッドを生成し実際の処理は別スレッドで行うように
実装します。
このような実装の場合、接続してくるクライアントの数が増えれば増える程、
大量のスレッドが生成されることになります。
そして、スレッドが大量に生成される場合、大量のメモリが必要になってきます。
下記のグラフではJavaでスレッド数を増やしていった場合に実際に必要な
スレッドのスタックサイズを現していますが、これによると
10,000スレッドを同時に生成した場合、約10Gバイトのメモリが必要になっています。
また、2万スレッドになると約20Gバイトのメモリが必要になっていることがわかります。
このように、単純にスレッドを増やしていくモデルのサーバはアクセス数が増えれば増える程
大量のメモリを消費していくことがわかります。
●C10K問題を解決できるサーバ (Non Blocking I/O型サーバ)
GlassFish(Grizzly)は上記の問題を解決するためにNon Blocking I/Oを使用して
実装が施されています。
Non Blocking I/Oを使用するとスレッドの作成数を減らすことができます。
実際には、Java NIOではServerSocketChannel#accept()メソッドでaccept処理
を行いますが、この処理はブロックしません。
仮にこのメソッドが呼び出された時にクライアントからの接続がない場合は、
すぐにnullを返します。
ServerSocket#accept()メソッドのように処理をブロックしないので、
クライアントのリクエスト毎に新たなスレッドを生成する必要もなくなります。
言い換えると、ServerSocketChannel#accept()を呼び出した元のスレッドで
引き続き処理を続けることができるようになります。
※ つまり複数のリクエストを処理するために、接続毎に新規スレッドを
生成しなくてもよいようになります。
Grizzlyの開発者の1人である
Jean-Francoisは次のように述べています。
「Grizzlyではたった30スレッドで10,000の接続を捌くことができます。」
This strategy prevent one thread per request, and enable Grizzly to server more that 10 000
concurrent users with only 30 threads.
●Asynchronus Request Processing(ARP)
さて、GrizzlyはJava New I/Oで実装されているだけでもすごいのですが
さらに、ARPも実装されています。
ARPはComeのアプリケーションや、ビジネスプロセスの処理にとても
時間が掛かるような場合、つまり長時間接続を保持しなければならない
アプリケーションの動作も実現できるように実装されています。
APRも又1つの接続辺り1スレッドを消費しないように実装されているため、
今までのマルチスレッドサーバ、Synchronus Request Processingに比べ
Comet等のアプリケーションを実行する環境としても最適です。
●まとめ
Grizzlyは汎用的なネットワークサーバエンジンです。
独自にサーバを構築する際はGrizzlyのフレームワークを再利用することで
ハイパフォーマンスな独自サーバを構築することが可能になります。
GrizzlyはJava NIOで実装されARPに対応しているのでComet等の
アプリケーションの実行環境としても最適です、そしてパフォーマンスも良いのです。
GlassFish(Grizzly)を使用して新しい先進的なアプリケーションを作成してください。
最後に、今回はGrizzlyの概要について紹介しました。
GlassFish(Grizzly)が何故パフォーマンスがよいのかの概要を掴んでいただけたのでは
ないかと思います。
次回は、さらに深くGrizzlyの内部の実装を知りたい方、もしくはJava NIOで実装された
サーバに興味のある方を対象に、Grizzlyのソースコード(Grizzly 1.0.19)の見方を紹介します。
皆様、GWは如何御過ごしでしたか?
今、サンフランシスコではJavaOne 2008が開催中ですが、
私は、今年は日本でゆっくりとGWを過ごささせていただきました。(^_^)
JJUGのイベントが終わり、それまでとても忙しい日々を送っていたのでGW中はゆっくり休みたい!!、
緑が見れる所に行きたい!!と考えたのですが、結局ガソリン代も高騰するこのご時世に、
車で石川まで行ってきました。(^_^;)
でも、深夜出発して高速の割引つかったり、帰りも輪島から長野まで下道を使ったりと
遠出ながらもかなり貧乏旅行してきました。(^_^;)
さすがに往復1,300Kmは車の運転好きな私もさすがにちょっと疲れましたぁ。。。
旅程:
飛騨→白川郷(世界遺産)→金沢兼六園→輪島の朝市

飛騨

白川郷

金沢の兼六園

輪島の朝市
PS.
JJUGで話をしたGrizzlyの詳細については、ブログで少しずつ
まとめていきたいと思いますので、暫く御待ちください。
さて、4/30にJJUGのCCCで発表することは以前にも
御伝えしましたが、発表する内容が固まってきました。
JJUG Cross Community Conference
今回は開発者向けのイベントですので、開発者に
対するメッセージが出せればと思い新たに資料を
書きおこしました。
ですので、今まで聞いて頂いた方も是非御都合があえば
御越し頂ければと思います。
概要を紹介しますと、タイトルが
「GlassFishで一歩進んだ開発をしてみませんか」ですので
一応ざっとどのようなアプリケーションを作成、動かすことが
できるのかについて紹介したいと思います。(約10分程)
#この前半部分は、今まで聞いたことのある方は重複する
#内容になるかと思います。
前半が終わった後残りは、Grizzly祭りにしようと思っています。
対象として聞いて頂きたい方は、下記のような方に聞いて
頂ければ幸いです。
● Cometのアプリケーションをかんたんに作成したい方
● C10K(クライアント1万)問題について知りたい方
● Java NIOのnon-blocking I/Oについて知りたい方
● 何故GlassFish/Grizzlyの実装が先進的か知りたい方
● GlassFishのHTTPのハンドリング部分を詳しく聞きたい方
● Java New I/Oでサーバプログラムを記述する方が参考にされる場合
一歩進んだ開発ということでは、
Cometのサーバ側のアプリケーションをかんたんに
POJOで実装できるようになる、Grizzletについても紹介
したいと思っております。
また、若干こじつけですが、Grizzlyの実装から
Java New I/Oでサーバプログラムを実装する際の注意点の紹介と
いかにしてGrizzlyが対応しているのかについても若干紹介します。
PS.
今回来て頂く方は、Grizzlyのソースコードをどこから見て行けば
よいのか指針が得られるのではないかと思います。
また今回、アプリケーションサーバの管理系については一切
説明いたしません。
管理者の方は今回対象としておりませんが、
仮にGrizzlyのソースコードから原因究明等を
将来的に行いたい、もしくは内部実装を知りたいという方は
是非、御越しいただければと思います。
GlassFishダウンロード
先日、GlassFishのwikiサイトの翻訳プロジェクト開始に
ついてアナウンスさせて頂きましたが、
現在、色々な準備を行っています。
日本語でディスカッション可能なメーリングリストとして
discuss_ja@glassfish.dev.java.netが存在します。
この翻訳プロジェクトで上記のメーリングリストを
使用することに致しました。
今日は、discuss_ja@glassfish.dev.java.netのメーリング
リストへ参加する為の手順について紹介します。
手順が多くてすいません。(^_^;)
手順1: java.netアカウントの登録
手順2: ユーザ名とメールアドレスの登録
手順3:登録メールの確認
手順4:パスワードの登録
手順5:ログイン状態の確認
手順6:メーリングリストのページへ移動
手順7:discuss_ja@glassfish.dev.java.netの購読
手順8:購読の確認1
手順9:購読の確認2
手順10:空メールの送信
手順11:メーリングリスト購読完了
手順1: java.netアカウントの登録
まず、はじめにjava.netのアカウントを作成して
頂く必要があります。java.netのアカウントは
下記のURLにアクセスして作成します。
https://www.dev.java.net/servlets/Login?cookieCheck=on
上記のURLにアクセスすると下記の画面が表示されます。
ここで、「アカウントの登録」のリンクを押下してください。
手順2: ユーザ名とメールアドレスの登録
「アカウントの登録」リンクを押下すると下記の画面が表示されます。
ここで、「ユーザ名」と現在御使いの「メールアドレス」を記入して
「登録」ボタンを押下してください。
手順3:登録メールの確認
「登録」ボタンを押下すると、入力したメールアドレスに対して
下記のようなメールが送信されます。
メール中に記載されているURLにアクセスして下さい。
手順4:パスワードの登録
メールに記載されているURLにアクセスすると下記の画面が表示されます。
ここに、アカウントに対する「パスワード」を入力して「パスワードの変更」ボタンを
押下してください。
※ 文字化けは無視してください。(^_^;)
手順5:ログイン状態の確認
「パスワードの変更」ボタンを押下すると、java.netに自動的にログインされます。
画面右上に、作成したアカウントでログインされているか確認してください。
「例:Logged in yosshi2008」
手順6:メーリングリストのページへ移動
java.netにログインされた状態で、GlassFishのサイトへ移動してください。
https://glassfish.dev.java.net
移動した後、画面右のメニュー中より「Mailing Lists」のリンクを押下して
下さい。すると下記の画面が表示されます。
手順7:discuss_ja@glassfish.dev.java.netの購読
メーリングリストのサイトへアクセスした後、ブラウザをスクロールして、
discuss_ja@glassfish.dev.java.netを見つけてください。
メーリングリストを見つけた後、「購読」ボタンを押下してください。
※ この「購読」ボタンはjava.netにログインした状態でなければ表示されません。
「購読」ボタンが表示されない場合は、java.netへログインした後に
アクセスしてください。
手順8:購読の確認1
「購読」ボタンを押下すると下記の画面が表示されます。
「購読のリクエストが送信されました。」というメッセージが表示されています。
手順9:購読の確認2
java.netで登録したメールアドレスに対してメッセージが送信されていますので、
メールの内容を確認してください。
内容を確認すると、下記のメールアドレス宛に空メールを送ってくださいと
記載されています。
空メールの送信先:
discuss_ja-sc.aaaaaaaaaa.bbbbbbbbbb-******=****.****@glassfish.dev.java.net
手順10:空メールの送信
メールに記載されている、アドレスに対して空メールを送信してください。
手順11:メーリングリスト購読完了
空メールを送信すると下記のようなWELCOMEメッセージが返信されます。
メッセージを受信すると購読手続きが正常に完了していますので、
後は、discuss_ja@glassfish.dev.java.netで日本語コミュニュケーションが
可能となります。
Participation Ageの到来です!!
是非皆様も御参加ください。
GlassFish日本語ディスカッションメーリングリストへようこそ!!
先週、金曜日はSun Business .Next 2008が六本木ミッドタウンで
開催されました。その時の写真の一部を紹介します。
私は、山口さん、片貝さんとコミュニティトラックで発表させて
頂きましたが、とても多くの方に御参加頂きました。
雨の中、ご来場いただきました方、ありがとうございました!!
金曜日はコミュニティトラックということで、GlassFishコミュニティ
について話をしたので、技術的なことは話をしませんでしたが、
4/30に開催される
JJUGのクロスコミュニティカンファレンス2008Spring
では、今までよりも技術的な話をしたいと思っております。
今、考えているのはGrizzlyの辺りとかCometの辺りをしゃべりたいと思ってます。
何故、GlassFish上でCometのアプリケーションを動かすとよいのか等々。。
あまり現時点で詳しく書けませんが、開発者向けのイベントですので、
開発者の方々に向けたメッセージが御送りできればよいなと思ってます。
そういえば、
技術評論社さんにもJJUGイベントの御紹介を頂きました。
昨日、ホットトピックセミナーがありましたが、その前に
片貝さんと一緒に日本Sunへ出張中の”ねこびーん”とDukeの
コラボ写真を撮ってきました!!
この"ねこびーん"仙台の
monyakata さんの御好意で
作成していただいたようで現在、用賀オフィスに長期出張中とのことです!!
片貝さんからの御紹介は←こちら
ほんとうにかわいぃですね!!
昨日のホットトピックセミナーも大変御好評を頂きました。
以前からJRubyについて話をして欲しいという要望があったのですが、
今回は
野澤さんから
JRuby on GlassFishの話をして頂きました。
野澤さんの説明はとても分かり易くGlassFishのgemを使い簡単にアプリケーションを
動作させたり、エンタープライズ環境のRubyの実行環境としてGlassFishが最適だという
話等いろいろして頂きました。
個人的な感想ですが、昨年に比べJRuby on GlassFishの開発携帯も随分改善されており
よりGlassFish上でRubyアプリケーションを動かし易くなっているように思いました。
また、
岩片さんによるOpenSSOのセミナーもとても面白くて、
大変御好評を頂いていました。
デモでも紹介していた日立の静脈認証モジュールは岩片さんがご自身で作成して
いるので、開発ポイント等も詳しく教えていただけました。
岩片さんはセミナー終了後も御客様から質問を受け付けていて、シングルサインオンの
技術もかなり注目されているんだと実感しました。
昨日のセミナーの様子は岡崎さんの
ストリーミング配信から
見て頂くことも可能ですので、是非御興味のある方は見てください。
Java Web Startとアプリケーションクライアントコンテナの技術を
使う技術に関する日本語資料がSDCにアップデートされています。
SDC SQUARE
GlassFish アプリケーションサーバーでの Java Web Start テクノロジおよびアプリケーションクライアント:パート 1
私もセミナー等で下記の資料を使って紹介するのですが、上記の資料は
詳しく説明がされています。
簡単に内容を紹介すると、SwingのAPI等を使用して記述された
リッチクライアントアプリケーションに、軽量なクライアント上で動作する
アプリケーションクライアントコンテナを一緒に配布するため、
アプリケーションサーバ上のリソース(EJB,JDBC等)に対してRMI/IIOPで
簡単にアクセスできるようになる技術です。
アプリケーションサーバ上のリソースを使用することによって、
アプリケーションサーバの負荷分散の機能等を使えるようになるため、
今までのクライアントーサーバの2層モデルに比べサーバの増加等が
(高負荷による)しやすくなったりします。
また、Java Web Startでリッチクライアントを配布する為、アプリケーションの
配布コスト(修正時における再配布コスト)が大幅に軽減されます。
Javaでリッチクライアントのアプリケーションを作成されている方は、
是非、この資料を御確認ください。