Que-Go を使用したバックグラウンドジョブ
この記事の英語版に更新があります。ご覧の翻訳には含まれていない変更点があるかもしれません。
最終更新日 2023年06月14日(水)
Table of Contents
Web サーバーは、できるだけ迅速にユーザーに対応することに重点を置く必要があります。ユーザーのエクスペリエンスを遅くする可能性がある重要な作業はすべて、Web プロセスの外部で非同期的に実行するべきです。
ワーカーキューは一般に、この目標を達成するために使用されます。ワーカーキューのアーキテクチャパターンについての詳細は、「Worker dyno、バックグラウンドジョブおよびキューイング」の記事を参照してください。ここでは、Que-Go と Heroku Postgres を使用したサンプルの Go アプリケーションを使用してこのパターンを示します。
この記事では、Heroku CLI と Go ツールチェーンがインストールされていることを前提としています。
Que-Go は Que Ruby ライブラリと互換性があるため、2 つの言語の間でキューとジョブを共有できます。
はじめに
以下の手順に従って、Heroku アカウントにサンプルアプリケーションのコピーを作成します。
ダッシュボードから行う場合
(Heroku ヘデプロイ) をクリックして、Heroku にデプロイします。
CLI から行う場合
Heroku CLI をインストールした後、ターミナルで次の手順に従います。
$ go get -u github.com/heroku-examples/go-queue-example/...
$ cd $GOPATH/src/github.com/heroku-examples/go-queue-example
$ heroku create
$ heroku addons:add heroku-postgresql
$ git push heroku master
$ heroku ps:scale worker=1
アプリケーション概要
このアプリケーションには、次の 2 つのプロセスがあります。
queue-example-web: ワーカーがインデックス処理するためのurl を含む POST された JSON ドキュメントの形式の URL を受け付ける Negroni ベースのアプリケーション。queue-example-worker: インデックス処理する必要があるurl を含むワーカープロセスのジョブ。
これらは独立したプロセスなので、特定のアプリケーションのニーズに基づいて個別にスケーリングできます。Heroku のプロセスモデルへの理解を深めるには、「プロセスモデル」の記事を参照してください。
shared.go には、データベース、データベース接続、および que クライアントの設定に重点を置いているいくつかの共有コードがあります。
Web プロセス
cmd/queue-example-web/main.go は、要求された URL をワーカープロセスが処理するためのキューに入れます。
ワーカープロセス
cmd/queue-example-worker/main.go は、キューから取得されたメッセージを処理する 2 つのワーカー Go ルーチンを実行します。これらのワーカーはデータに対して特別な処理は行わず、受信したデータをログストリームに出力するだけです。これは、長時間実行される処理ロジックが配置される場所です。
共有ロジック
shared.go には、両方によって使用される、いくつかの初期化および設定の共有ロジックが含まれています。
アプリケーションのテスト
ログストリームを観察することによって、この 2 つのプロセスの間の対話を監視できます。
$ heroku logs --tail -a <app name>
別のターミナルで、cURL を使用して “インデックス処理” のための URL を送信します。
$ curl -XPOST "https://<app name>-<random-indentifier>.herokuapp.com/index" -d '{"url": "http://google.com"}'
最初のターミナルに戻ると、次のような出力が表示されています。
2015-06-23T18:29:35.663096+00:00 heroku[router]: at=info method=POST path="/index" host=<app name>-<random-indentifier>.herokuapp.com request_id=84f9d369-7d6e-4313-8f16-9db9bb7ed251 fwd="76.115.27.201" dyno=web.1 connect=19ms service=31ms status=202 bytes=141
2015-06-23T18:29:35.623878+00:00 app[web.1]: [negroni] Started POST /index
2015-06-23T18:29:35.644483+00:00 app[web.1]: [negroni] Completed 202 Accepted in 20.586125ms
2015-06-23T18:29:37.750543+00:00 app[worker.1]: time="2015-06-23T18:29:37Z" level=info msg="Processing IndexRequest! (not really)" IndexRequest={http://google.com}
2015-06-23T18:29:37.753021+00:00 app[worker.1]: 2015/06/23 18:29:37 event=job_worked job_id=1 job_type=IndexRequests
上記では、Web プロセスがリクエストを処理して 202 を返すと、数ミリ秒後に、キューに入れられたリクエストをワーカーが選択し、それを “処理する” ことを確認できます。