HTTPサーバー

- IBM i 専用の先進のHTTPサーバーを実装 -

Alaska とはAutoWebを支える IBM iのために開発されたHTTPサーバーです。
Web上でも5250エミュレータのセッションを維持するための
特別な機能があります。

AutoWebをご利用になる上でAlaskaを特に意識する必要はありませんが
製品の特質をより理解して頂くにはAlaskaを知って頂くことも大切です。
AlaskaはAutoWebを支える重要なアーキテクチャーのひとつです。

最速のパフォーマンスを実現

- Webはパフォーマンスが命です -

HTTPサーバー:IBM Apache は伝統的なTCP/IPサーバーであるのに対し
AlaskaはIBMが将来のTCP/IPサーバーの理想型として推奨するメッセージ配布型です。

IBM Apacheの動作原理

Apacheはクライアントからの要求の読み取りや書き出し(送信)も
すべて親スレッドが行います。
数百からのクライアントからの要求があっても応答して応えるのは
ただひとつの親スレッドです。
数多くのクライアントと通信しているのは親スレッドだけです。
だから親スレッドだけに負荷が集中してしまい多くのユーザーの要求を
処理することができずパフォーマンスが低下してしまいます。
Apacheを使用している製品がパフォーマンスが悪いのは
この処理構造が原因です。

※Apacheとは

Apacheとは1995年に開発されたJavaベースのフリー(無料)のオープン・ソース・プロジェクトとして共同開発して
リリースされたWebサーバーのソフトウェアであり IBM ApacheはこのApache2.0をIBM i用にPORTING(移植)されたものです。
IBM も初めはIBM HTTP Serverとしてスタートしましたが後にApache を移植して2000年に IBM Apacheとしましたが
このころはPTFなしではほとんど動作しませんでした。

Apache はなぜ障害に弱いのか ?

Apacheは次にどの子スレッドに処理をさせるのかは
子スレッドが待ち行列に自分のIDを投入しておいて
親スレッドがこれを順番に引き出すというPULL-DOWN方式によって決定されます。

ところがある子スレッドがトラブると子スレッドは待ち行列に
自分の順番を入れることができません。
そうなると親スレッドはいつまでたっても次の利用可能な
子スレッドを引くことができません。
こうしてHTTPサーバー全体が凍結してしまいます。
解消するには全体を再起動するしかなくなります。

このようにひとつの子スレッドのトラブルが全体の停止に繋がってしまいます。
かつてのWindows95もCPUのタイムを子スレッドに分割していたため
ひとつのアプリがトラブるとWindows全体を再起動するしかありませんでした。
同じことがApaceでも起こるのです。

いかにApacheが脆弱であるかお分かりでしょう。

Alaskaの動作原理

ALASKA動作原理図

Alaskaの親スレッドはクライアントからの着信要求を受け取るだけです。
各クライアント相手の入出力処理はすべてそれぞれの子スレッドが
直接対話して行います。
親スレッドにはほとんど負担はなくそれぞれの子スレッドに処理が
分散されて同時並行で通信が行われます。
つまり理想的な負荷分散が行われているのです。
だからパフォーマンスに優れたサーバーとなります。

※Alaskaとは

Alsakaは㈱オフィスクアトロが開発した独自のHTTPサーバーです。
初めはApache2.0と同じ構造で2001年にリリースされましたが2006年に将来を見据えてVer4.0でメッセージ配布型の
Webサーバーとして全面的に改訂されました。
以降、対話式仮想環境やクロス・ブラウザ対応やスマート・コネクションを搭載して今日に至っています。

銀行の窓口とHTTPサーバー

HTTPサーバーの処理はよく銀行の窓口の処理に例えられます。
従来型のApacheの場合は後ろに多くの銀行員が待機しているのに
お客さまの応対をしているのはたった一人の窓口の担当員だけです。
お客さまへの入出納を行うのはこの一人の担当だけです。
後ろに控えている銀行員は手が空いているのに窓口だけが
忙しいので結局はどのお客さまも待たされたままになります。

これに対してメッセージ配布型は今、多くの銀行で行われているような
受付カードを取る方法とよく似ています。
受付窓口では受付カードによってお客さまを受け付けるだけです。
その後は手が空いている銀行員が誰でもお客さまと応対します。
実際の銀行とちがうところはすべての控えの銀行員がすべての処理を行うところです。
このように同時並行処理が可能なことによって
お客さまを待たせることなく全体の処理をスムースに行うことができます。
これがApacheとAlaskaのちがいです。

パフォーマンス・チューニングについて

AlaskaおよびAutoWebは不定期でソースのパフォーマンス・テストを行っています。
これはパフォーマンスを低下させるロジックが含まれていないかどうか
ボトル・ネックになっているロジックはどこかのソース・コードを不定期でつねに調べるためです。
少しでも軽く速くなるようチューニングが行われます。
Webはパフォーマンスが命です。
正しく動作するだけでなく速く動作することも求められるのです。

堅牢な実務型設計

IBM Apacheでは障害が発生するとHTTPサーバー全体を終了して
再起動させなければなりません。
これはサブ・システム QINTERを再起動させるのと同じことであり
他の業務も停止してしまいます。

Alaskaはメッセージ配布型なので障害のある子スレッドだけのキャンセルだけで済みます。
さらに子スレッドをキャンセルすると親スレッドはそれを検知して
新しい子スレッドを生成します。

またクライアント要求が過度に集中した場合も子スレッド数が
自動的に必要な数だけを増やして要求に応えるよう設計されています。

このような堅牢な設計におかげでお客さまは安心して運用することができます。

スマート・コネクションによるセッション管理(仮想対話式環境)

5250環境をWebでも再現するためにスマート・コネクションと呼ばれる
独自の通信手段を組込みました。
スマート・コネクションは子スレッドのJOB番号でクライアントと
子スレッドを仮想的に結合しています。

送受信が完了すると通信は直ちに切断されます。
通常は通信は切断されたままです。
ですから通信環境の悪い状況でも問題は発生しません。
しかし再接続すると元のJOB番号の子スレッドと再接続して通信が再開します。
あたかも通信が持続しているかのような処理になりQTEMPや*LDAも
生かすことができます。
クライアントが終了すると対応する子スレッド自身も終了して
後からの成りすましも防いでいます。
5250対話式環境を仮想化するこの技術は仮想対話式環境と呼ばれて
これまでの5250エミュレータと全く同じ環境をWebでも再現
することができるようになりました。

複数セッション対応

現在の市販のブラウザのほとんどはタブ・ブラウザですが
通信のためのSocket識別子はひとつしかありません。
これは多くの人々が電話するのに電話回線が一本しかないのと同じことです。
従って他の市販の製品では複数のセッションを同時に使うことはできません。
しかしAlaskaならスマート・コネクションのおかげで通信は切断されていますので
Socket識別子がひとつであることも何の問題にもなりません。
どのような数の複数のセッションも同時に接続が可能になります。
このように複数セッションが使えるのはAutoWebだけです。

タブ・ブラウザ