クーポン券発行システムの設計

X社は，全国に約400店のファミリーレストランを展開している。X社の会員向けWebサイトでは，割引料金で商品を注文できるクーポン券を発行しており，会員数は1,000万人を超える。このため，会員の利便性の向上や店舗での注文受付業務の効率向上のために，会員のスマートフォン宛てにクーポン券を発行することになった。

スマートフォン宛てにクーポン券を発行する新しいシステム（以下，新システムという）は，スマートフォン向けアプリケーションソフトウェア（以下，スマホアプリという）とサーバ側のWebアプリケーションソフトウェア（以下，WebアプリといW）から構成され，Webアプリの開発は情報システム部門のY君が担当することになった。

新システムの利用イメージ

X社の会員は，事前に自分のスマートフォンにX社のスマホアプリをダウンロードし，インストールしておく。会員がクーポン券を利用する際は，スマホアプリに会員IDとパスワードを入力してログインする。ログインが完了すると，おすすめ商品と利用可能なクーポン券の一覧が表示される。会員が利用したいクーポン券を選択すると，QRコードを含むクーポン券画面が表示される。X社店舗の注文スタッフがQRコードを注文受付端末で読み取ると，割引料金での注文ができる。

Webアプリの処理方式の調査

Y君がWebアプリの実現方式を検討したところ，X社のWebサイトで利用しているブロッキングI/O型のWebサーバソフトウェア（以下，サーバソフトという）では，スマホアプリからの同時アクセス数が増えると対応できないことが分かった。

ブロッキングI/O型のサーバソフトでは，ネットワークアクセスやファイルアクセスなどのI/O処理を行う場合，CPUは低速なI/O処理の完了を待って次の処理を実行する。例えば，表1に示すQRコードを作成するために必要なWebアプリの処理（以下，QRコード作成処理という）の場合，全体の処理時間のa%がI/O処理の完了待ち時間となる。

このため，ブロッキングI/O型のサーバソフトでは，複数のスマホアプリにサービスを提供するために，プロセスやスレッドを複数生成している。しかし，プロセスやスレッドの数が増えると，プロセスやスレッドの切替え処理であるbスイッチがボトルネックとなり，CPUやメモリを追加してもスマホアプリからの同時アクセスへの対応は困難となる。

そこでY君は，多数のスマホアプリからのアクセスを効率よく処理できるノンブロッキングI/O型のサーバソフトの利用を検討した。ノンブロッキングI/O型のサーバソフトでは，一つのプロセスやスレッドの中で，CPUはI/O処理の完了を待たずに，実行可能なほかの処理を実行する。その結果，Webサーバは複数のプロセスやスレッドを生成する必要がなく，スマホアプリへも効率的にサービスを提供できる。

リアクタパターンの調査

ノンブロッキングI/O型のサーバソフトで，Webアプリを動作させるためには，非同期処理の考え方に基づいたソフトウェア設計が必要である。そこで，Y君は，ノンブロッキングI/O型の処理を実現するデザインパターンの一つであるリアクタパターンについて調査した。図1にY君が調査したリアクタパターンの処理の流れを示す。

I/O処理の処理結果を利用する処理をハンドラとして定義する。次に，I/O処理の完了待ちを依頼したいメイン処理が，①I/O処理完了後に実行するハンドラ名を引数に"（ア）ハンドラの登録"を行うと，リアクタは"（イ）ハンドラを取得"する。次に，メイン処理がリアクタに"（ウ）イベントのハンドル依頼"を行うと，リアクタはデマルチプレクサに"（エ）イベント待ち"を指示する。デマルチプレクサは複数のI/O処理の完了を一括して監視し，"（オ）I/O処理の完了"を検知した場合には，対応する"（カ）イベント"をリアクタに発行する。イベントを受け取ったリアクタは"（キ）ハンドラを実行"する。メイン処理は，イベントのハンドル依頼を行った後は，I/O処理の完了を待たずにほかの処理を実行できる。

リアクタパターンを適用する場合は，遅いI/O処理の次に実行される処理をハンドラとして分割するのがよい。しかし，リアクタパターンに基づき設計されたプログラムは，②保守性が下がるおそれがある。

QRコード作成処理の設計

Y君は，リアクタパターンを用いて，スマホアプリからのアクセスに対する応答時間が最小になるように，QRコード作成処理を設計した。図2にY君が設計したQRコード作成処理の流れを示す。

その後Y君は，新システムのWebアプリの開発を完了させ，X社の会員はスマートフォンを通じてクーポン券を利用することが可能となった。