botをつくるときはやはり公式のフレームワーク、Boltがやはり便利ですよね。したジョブを作って実行するにはやはり便利ですよね。コンテナ実行できるので開発や動作検証もしやすいですし。Runは相性が悪い!?世の中にこんなに便利なものがあったら、やっぱり組み合わせて使いたくなりますよね。便利なものには思わぬ副作用があり、見事にハマって1週間苦しんだ体験を残しておこうと思います。hiring!何が起きたか?とにかく実行が遅い。なく耐えられないくらい遅い(なお、手元のPCでは速い。botを使ってワークフローを作成し、Bigqueryの権限申請のワークフローを作成しました。申請フォームの内容に応じて、botがgcloudコマンドを実行をする仕組みです。今回作成したワークフローしかしこのシェルコマンドの実行部分がとにかく遅い。Run上だと5分以上かかるということが起きました。allocated」を指定しましょう。processing」ではダメです。processing」では、リクエスト処理中のみCPUの割り当てが行われます。関数を用いて一旦応答しなければなりません。関数を呼んだ時点でリクエスト処理が終了し、CPUの割り当てが行われず、動作が遅かったのです。Runのその特性を知らないと、謎としか思えなかった現象を最後に供養したいと思います。笑って読んであげてください。RunのCPUの割り当ての問題なので、ローカルではもちろん再現しません。Runにデプロイしなければなりませんでした。ちなみに私はこの件で1日50回デプロイしてました。ackより前に呼ぶと速いデバッグの結果、ackより前にそのコマンドを実行すると、通常の速度で処理されるということがわかりました。ackを呼ぶと、遅いプロセスが起動されるのかと思い、ackの実装を読み始めました(もちろんただレスポンスを返してるだけなので迷宮入りしました)。実行すると、前回の内容が実行される前述の通り、1回目のワークフローを実行した時に、そのコマンド結果が全く返ってきません。結果が返る前に2回目のワークフローを実行すると、先に1回目のコマンドの結果が出力され、2回目のコマンド結果を待つ、という現象が起きました。これは、2回目のワークフローを開始するとコンテナのリクエストが処理され始めるので、そのコンテナへCPUの割り当てが開始され、止まっていた1回目のコマンドが実行される、というのが現象の説明になります。Runの特性だとこのあたりから確信し始めました。まで残り4日となりました。9注目記事はてなブログをはじめよう!m3techさんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。