3.7.1. 非同期実行（共通編）¶
目次
3.7.1.1. Overview¶
3.7.1.1.1. 処理方式概要¶
3.7.1.1.2. 処理方式イメージ¶
本ガイドラインで紹介する非同期実行方式のイメージを示す。
上記イメージでは、アプリケーションサーバはフロントサーバとバックサーバに分けた構成としている。 フロントサーバには予約受付を行うアプリケーションを配置し、バックサーバには主処理を行うアプリケーションを配置する。
クラウド環境では、リクエスト数の増減やインスタンスの状態に応じてリソースのオートスケーリングが可能だが、 データベースなどのオートスケーリング不可なリソースがボトルネックとなり、性能問題となる恐れがある。 本方式では、予約受付処理と主処理とをキューサービスを介し非同期に実行させる事で、 主処理で長時間を要しても、クライアントへのレスポンスに影響が出ないようにしている。
| 項番 | 説明 |
|---|---|
(1)
|
フロント側アプリケーションは、クライアントからのリクエストを受け付ける。
|
(2)
|
フロント側アプリケーションは、キューサービスに主処理の実行要求メッセージを送信し、クライアントにレスポンスを返却する。
|
(3)
|
バック側アプリケーションは、キューサービスから主処理の実行要求メッセージを受信し、フロント側アプリケーションとは非同期に主処理を実行する。
|
(4)
|
バック側アプリケーションは、通知サービスに処理完了通知を依頼する。
|
(5)
|
通知サービスは、クライアントに処理完了通知を送信する。
|
3.7.1.1.3. フロントサーバの処理方式¶
フロントサーバの処理方式について説明する。フロントサーバでは、バックサーバへの処理要求メッセージを送信する。
3.7.1.1.3.1. メッセージ送信¶
3.7.1.1.3.2. メッセージに持たせる情報¶
送信するメッセージに持たせる情報を以下に例示する。
主処理に必要となる情報
チケット予約の主処理を行うにあたり必要となる、予約チケット情報、航路情報、ユーザ情報などの業務的な情報。
メッセージの識別子
メッセージを一意に特定できるメッセージID。処理のトレーサビリティを確保する為に利用する。 採用するメッセージングサービスにて一意なIDが採番される場合(例:Amazon SQSのSQSMessageIDなど)は、そちらを利用すると良い。
Note
メッセージ送信の失敗時に、前回送信と同一のメッセージIDでリトライ送信を行いたいなど、 メッセージングサービスにて採番されたIDでは実現できない要件がある場合は、 アプリケーションにて独自に採番する方式を検討されたい。
3.7.1.1.3.3. メッセージ送信に関連するエラー処理¶
- メッセージ送信後の処理で業務エラーが発生した場合
- メッセージ送信後の処理でシステムエラーが発生した場合
- メッセージ送信先のキューに異常が発生した場合
Note
フロントサーバとバックサーバのデータ整合性を保つための対処法としては、戻し更新処理の実装や、運用対処によるデータ修正などが考えられる。
3.7.1.1.4. バックサーバの処理方式¶
バックサーバの処理方式について説明する。バックサーバでは、フロントサーバからの処理要求メッセージの受信、要求に基づく主処理およびクライアントへの処理完了通知を行う。
3.7.1.1.4.1. メッセージ受信¶
Warning
Amazon Web Serviceが提供するAmazon SQSの標準キューのように、メッセージングサービスによっては順序性を担保していない。厳密な順序性が求められる場合は注意されたい。
3.7.1.1.4.2. メッセージのトレース¶
メッセージのトレーサビリティ向上のために、各ログにリクエスト単位で一意なメッセージID等をTrackIDとして出力させることを推奨する。 TrackIDは、logbackのMDCを利用してログ出力する事ができる。TrackIDの利用方については、Macchinetta Server Framework for Java (1.x) Development Guideline ログの出力内容 を参照されたい。
3.7.1.1.4.3. 処理完了通知¶
Note
非同期処理の内容によっては、処理完了をユーザに通知するのではなく、ユーザが能動的に処理結果確認画面にアクセスして確認する方式も考えられる。実行する処理内容を考慮し、完了通知の要否を検討されたい。
3.7.1.1.4.4. バックサーバのエラー処理¶
- メッセージ受信処理でシステムエラーが発生した場合
- メッセージ受信後の主処理で業務エラーが発生した場合
- メッセージ受信後の主処理でシステムエラーが発生した場合
- クライアントへの処理完了通知処理にてシステムエラーが発生した場合
Warning
本来フロントサーバで行っていた業務処理のうち、高負荷が想定される処理をバックサーバに切り出す場合について、 フロントサーバ、バックサーバの両方でデータ更新が行われていると、エラー発生時にデータの不整合が発生する。 必要に応じて戻し処理や運用対処でのデータ修正等を検討されたい。また、採用するクラウドベンダーがメッセージのトランザクション機能を提供している場合もある為、併せて検討されたい。
3.7.1.2. How to use¶
3.7.1.2.1. メッセージングサービスの利用¶
クラウドベンダーが提供するメッセージングサービスを利用し、非同期処理を実装する。
3.7.1.2.1.1. Amazon Web Service¶
クラウドベンダーとしてAWSを使用する場合の非同期処理の実装例については、 非同期処理の実装（共通編） を参照されたい。