Que-Go を使用したバックグラウンドジョブ

最終更新日 2023年06月14日(水)

Web サーバーは、できるだけ迅速にユーザーに対応することに重点を置く必要があります。ユーザーのエクスペリエンスを遅くする可能性がある重要な作業はすべて、Web プロセスの外部で非同期的に実行するべきです。

ワーカーキューは一般に、この目標を達成するために使用されます。ワーカーキューのアーキテクチャパターンについての詳細は、「Worker dyno、バックグラウンドジョブおよびキューイング​」の記事を参照してください。ここでは、Que-Go​ と Heroku Postgres​ を使用したサンプルの Go アプリケーションを使用してこのパターンを示します。

この記事では、Heroku CLI​ と Go ツールチェーン​がインストールされていることを前提としています。

Que-Go は Que​ Ruby ライブラリと互換性があるため、2 つの言語の間でキューとジョブを共有できます。

はじめに

以下の手順に従って、Heroku アカウントにサンプルアプリケーションのコピーを作成します。

ダッシュボードから行う場合

  1. Deploy to 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​ を返すと、数ミリ秒後に、キューに入れられたリクエストをワーカーが選択し、それを “処理する” ことを確認できます。