RPCってあるよね
RPCという言葉がある。リモートプロシージャコールの略。平たく言えば、別のマシンの関数を呼び出す。
もっと平たく言えば、別サーバのプログラム呼び出し。
かっこいいのはいっぱいある。
- XML-RCP
- GRPC
- SOAP
そんなところ。特にHTTPを通じて呼び出すには、WebAPIなんて言い方もしている。時間のかかる処理をRPCで呼び出す時にはいろいろ大変。いい案を考えよう。
第一の案：REST-API
一番シンプルな案が、REST-API。一般的な動的なWebスクリプトって、クライアントがブラウザで、サーバのプログラムを起動してその結果を受け取ってる。それってもうRPCだよねという話。人がみるんじゃんなくて、プログラムがクライアントにあっても全然構わない。まずはREST-APIが一番だ。
ただ、REST-APIはWebアーキテクチャなので、基本は1秒以内に情報が帰ってくることが大前提。ブラウザにしてもプログラムの中から呼び出すHTTPクライアントにしてもタイムアウトが存在する。レスポンスに10秒以上かかるWebはHTTPにあらず。
第二の案：REST-API＋コールバック
時間のかかる処理があったとして、リクエストを投げて処理を依頼するのは、一瞬で終わる。その際に「処理が終わったらこのURLに結果を返してね」とお願いだけする。電話で折り返しをお願いするようなもの。この場合は、HTTP通信のタイムアウトなんて気にしないでいい。
ただ、デメリットがある。ちょっとした処理を依頼するだけの側にも、Webサーバーが必要になる。そんなもん立てるのは簡単だけど、セキュリティのことを考えると、開いているポートは最小限にしたい。あと、コールバックって「コールバックさえ失敗している」ときってすごく把握がしにくい。お互いにサーバーとして通信するのでテストも「せーの」でテストしないといけない。
第三の案：ポーリング
サーバに依頼をする。その際にJOBのIDを受け取る。クライアントはそのJOBのIDをキーに、定期的にサーバに処理が終わったかどうかを問い合わせる。
何度もサーバに問い合わせをしなくちゃいけないというところがダサいのだが、ダサさに目をつむればすごくシンプルだ。
ポーリーングそのものは、REST-APIでよくて、JOBの登録のAPIとJOBの結果受け取りAPIの2つを作るだけ。
ポーリングの究極：S3を使ったポーリング
どうせポーリングでいいなら、処理を依頼する側も処理をする側も両方S3を見ちゃえばいい。
どっちも定点監視しなくちゃいけないんだけど、「外部からの通信を許可しない環境でも使える」というのがメリット。
S3の料金が気になるところだけど、自前で構築する手間を考えるとめちゃくちゃ安い。大半のコストは通信ボリュームに依存するので、「ファイルが存在するかどうかをチェックする」というだけの処理は安い。019-01-12の東京リージョンの価格で、GETリクエスト 1,000 件あたり 0.00037USDという価格なので、めちゃくちゃ安い。
もちろんS3でなくてもいいんだけど、S3が大企業の情シスが許容している数少ないクラウドストレージ。
監視ってcronとか設定しなくちゃいけないんでしょ？面倒じゃないの？
1秒に一回とかみるのなら、プログラムで無限ループで監視すればいい。