社内の新しい試みとして、自社専用のサーバー(オンプレミスサーバー)を立ち上げることになりました。
システムを作る上で一番の課題は、「複数の人が同時にアクセスしても、パンクせずにスムーズに処理できること」です。
そこで今回は、「Webサーバー ── APIアプリケーション ── ジョブキュー ── ワーカー」という4つの仕組みを連携させる構成(アーキテクチャ)を採用しました。
本記事では、サーバーがユーザーからデータを受け取って、分析を行い、結果を返すまでの裏側の流れを分かりやすく解説します。
システムを支える4つの「登場人物」
このシステムでは、役割の異なる4つの機能がチームを組んで連携しています。
- Webサーバー(受付係):
ユーザーからのアクセスを最初に受け取る窓口です。多数のユーザーが一斉にリクエストを送ってきても、行列を作ることなくスムーズに受付を行う能力を持っています。 - APIアプリケーション(ホール責任者):
届いたリクエストの中身を整理し、システム全体をコントロールする司令塔です。ここでは時間のかかる重い処理は行わず、即座に「受付番号」を発行して、仕事を次のステージへと回します。 - ジョブキューシステム(注文伝票のトレイ):
発行されたタスクを順番通りにストックしておくトレイです。超高速で動作し、APIアプリケーションとバックグラウンドワーカーを仲介する役割を果たします。 - バックグラウンドワーカー(作業員):
トレイに溜まったタスクを順番に取り出し、時間のかかる計算やAI解析などを行う作業員です。今回はこの作業員を複数人同時に配置し、並行して作業を行えるようにしています。
データ受信から分析、結果送信まで
ユーザー側がサーバーにデータを送ってから、解析結果をユーザー側に返すまで、システム内部では以下のような連携が行われています。
1. Webサーバーがリクエストをキャッチ
ユーザーからリクエストが送られると、まず窓口となる Webサーバー が受け取ります。このWebサーバーは多数のユーザーが一斉にリクエストを送ってきても、アクセスをブロックすることなく同時並行で漏らさずキャッチします。
2. APIアプリケーションが受付番号を発行し、キューへ送る
リクエストはAPIアプリケーションに渡されます。リクエストを受け取ったAPIアプリケーションは、時間のかかる解析処理を始めることはしません。 まず受付番号となる「ジョブID」を発行し、ユーザーのブラウザへ「このIDで受け付けました」とレスポンスを返します。これと同時に、入力データと条件をセットにした「仕事の依頼書」を作成し、ジョブキューシステム のトレイへ送ります。
3. 複数のワーカーが並行処理
裏側では、いつでも動けるように待機している複数の バックグラウンドワーカー が、ジョブキューのトレイに依頼書が届くのを常に監視しています。 今回はワーカープロセスを複数同時に起動させているため、トレイに依頼書が入った瞬間、空いているワーカーたちがすかさず仕事を取り出し、負荷の高い解析処理をフルスピードで並行実行します。
4. ユーザーからの問い合わせに結果を返す
バックグラウンドワーカーは解析処理が終わると、その結果データを再びジョブキュー に書き込みます。 一方、最初に「受付番号」をもらって待機していたブラウザ側は、数秒おきに「私の番号の処理は終わりましたか?」とAPIアプリケーションへ定期的な問い合わせを行っています。APIアプリケーションがジョブキューを見て「完了しています」と確認できたら、最終的な分析結果をブラウザに返却し、画面に結果が表示されます。
おわりに
今回は、サーバー構築とアーキテクチャに焦点を当ててご紹介しました。
ハードウェアの持つ力を活かす構成のおかけで、非常に打たれ強くスケーラブルな解析サーバーを立てることができたと感じています。
また、クラウドに任せず、サーバーを「自分たちでもつ」からこそ、トラブルへの対応力や運用のノウハウが身につきました。
しかし、実運用において決して忘れてはならないのが「セキュリティ」です。 本記事では構築フェーズの話に留めましたが、実際に社内の業務データや機密情報を含むファイルを扱う以上、「アクセス権限の厳格化」「通信の暗号化」「キューシステムやデータストアの保護」、そして「ミドルウェアの脆弱性対策」など、強固なセキュリティ対策を必ずセットで講じる必要があります。
今後も、構築や運用を進めていく中で気づいたことや学びがあれば、また記事にまとめて共有して行ければと思います。
