Cloud Scheduler を使用した Compute Engine での信頼性の高いタスクのスケジューリング

Compute Engine インスタンスのネットワークなどの分散型システムでは、オートスケーリングやネットワークのパーティショニングによって個々のインスタンスを使用できなくなる場合があるため、タスクを確実にスケジューリングすることは困難です。

Cloud Scheduler をスケジューリングに使用し、Cloud Pub/Sub を分散メッセージングに使用することで、一連の Compute Engine インスタンス全体にタスクを確実にスケジューリングするアプリケーションを作成できます。他のサービスまたはクラウド全体で、複雑なワークフローのスケジューリングとオーケストレーションを行う必要がある場合は、代わりに Cloud Composer の使用を検討してください。

この記事は、以下の 3 つのパートに分かれています。

Compute Engine でタスクを確実にスケジュールする方法

Cron は、Unix システムで反復タスクをスケジューリングするための標準ツールです。作成するシステムの複雑さが増し、分散型になっていくと、cron を実行している 1 台のコンピュータでさえ、重大な障害点になる可能性があります。このインスタンスはオートスケーリングで停止する可能性があり、ネットワーク セグメントは、通信する必要のあるシステムから分割される可能性があります。

Cloud Scheduler は、イベントをスケジュールできるフルマネージド エンタープライズ クラスのサービスを提供します。ジョブをスケジュールした後、Cloud Scheduler は構成済みのイベント ハンドラを呼び出します。イベント ハンドラは、App Engine サービス、HTTP エンドポイント、または Cloud Pub/Sub サブスクリプションです。

Cloud Scheduler イベントへの応答として Compute Engine インスタンスでタスクを実行するには、Cloud Scheduler イベントをこれらのインスタンスにリレーする必要があります。これを行う 1 つの方法は、Compute Engine インスタンスで実行される HTTP エンドポイントを呼び出すことです。または、Cloud Pub/Sub を使用して Cloud Scheduler から Compute Engine インスタンスにメッセージを渡すこともできます。このサンプルは、2 番目の設計パターンを示しています。

次の図は、この設計パターンの構造を簡単に示しています。

アーキテクチャの概要図

この実装では、Cloud Scheduler でイベントをスケジュールし、Cloud Pub/Sub を使用してそれらのイベントを Compute Engine インスタンスに送信します。

Compute Engine インスタンス上のユーティリティ サービスは Cloud Pub/Sub トピックにサブスクライブし、それらのトピックからプルダウンするイベントへの応答で cron ジョブを実行します。このユーティリティは標準スクリプトを実行します。つまり、このサンプルでは、それらを使用するために現在の cron スクリプトを変更する必要はありません。

Cloud Pub/Sub を使用して Compute Engine でコマンドを実行しているロジックからタスク スケジューリング ロジックを分離することで、Cloud Scheduler 構成を更新せずに、必要に応じて cron スクリプトを更新できます。Compute Engine インスタンスのユーティリティ サービスを更新せずに、タスク スケジュールを変更することもできます。

割り当て

通常、cron ジョブは数が少なく、時間、週、または日単位で実行されるため、この設計パターンでは 1 分間に数十、1 日に数千のリクエストを許可する Cloud Scheduler 割り当てを超過することはできません。超過する場合、アプリケーション コードから直接タスクのタイミングを管理する方法など、他の適用パターンを検討してください。

料金

これらのリソースを他のアプリケーションに使用していない場合は、GCP の無料枠でこの設計パターンのサンプル実装を無料で試すことができます。無料の割り当てがプロジェクト内の他のアプリケーションで使用されている場合、コストは Compute Engine、Cloud Scheduler、Cloud Pub/Sub リソースの合計使用量によって決まります。

Cloud Scheduler の料金は、スケジュールしたジョブの数に応じて支払います。Compute Engine の料金は、使用したインスタンスのタイプと期間に応じて支払います。Cloud Pub/Sub の料金は、送信したデータの量に応じて支払います。

たとえば、次のセクションのサンプル実装を 1 時間実行した後、その GCP リソースを削除すると、費用はおよそ 1 セントになります。この見積もりの費用内訳と、独自のユースケースでの費用計算方法については、料金計算ツールを参照してください。

設計パターンのサンプル実装

この設計パターンのサンプル実装であるサンプル: Compute Engine での信頼性の高いタスクのスケジューリングは、GitHub で入手できます。

サンプルには次の 2 つのコンポーネントが含まれています。

  • Cloud Scheduler および Cloud Pub/Sub の構成手順。

  • Compute Engine で実行されるユーティリティ。このユーティリティは Cloud Pub/Sub トピックをモニタリングします。新しいメッセージを検出すると、サーバー上で対応するコマンドをローカルで実行します。

サンプルに含まれている readme ファイルには、サンプルの詳細情報と、GCP でサンプルコードを実行する方法の説明があります。

スケジュールに沿ってインスタンスを開始および停止する特定のケースについては、Cloud Scheduler を使用した Compute インスタンスのスケジュール設定を参照してください。

設計パターンとサンプルでのビルド

このサンプルには、Cloud Scheduler を使用して、Compute Engine 用の信頼性のあるスケジューリング ソリューションを実装する 1 つの方法を示しています。これは、Compute Engine インスタンスでコマンドを実行するロジックからスケジューリング ロジックを分離することで、スケジューリング ロジックを更新しなくてもタスクのロケーションや実行を変更できるという点で、便利な設計パターンと言えます。

次の図は、このサンプルでのメッセージのフローを示しています。所定のトピックをサブスクライブするインスタンスを指定することで、cron ジョブが単一のインスタンスまたは複数のインスタンスのどちらで実行されるのかを制御できます。

詳細なアーキテクチャの図

このアーキテクチャのもう 1 つの利点は、どのように cron ジョブがインスタンスにルーティングされるかを制御できるということです。

Cloud Pub/Sub のトピック A および C に示されているように、さまざまな cron メッセージを異なるサーバーセットに送信できます。トピック A のタスクは単一のサブスクライバに送信される一方、複数のサーバーがトピック C にサブスクライブします。この方法を使用して、ウェブサーバーでコマンドの 1 つのセットを実行し、他のサーバーで別のセットを実行できます。

さらに、複数あるサーバーのいずれか 1 台のサーバーでコマンドを実行することもできます。これは、トピック B で示されています。この場合、複数のサーバーが単一のサブスクリプションを共有します。トピック B にパブリッシュされるメッセージは最初のサーバーで処理され、そのメッセージと対応するコマンドがそのサーバーでのみ実行されるように要求します。このアプローチを使用して、単一のサーバーでのみ実行する必要のある夜間データ解析を実行できます。

次のステップ

サンプルを修正して、独自のアプリケーション用のモデルとして使用できます。作業を開始するときには、以下を参考にしてください。

  • Cloud Scheduler 構成を更新して、独自の cron メッセージを指定します。cron ジョブの作成と構成で説明されているように、cron ジョブを直接更新できます。

  • logger_sample_task.py ではなく、実際のスクリプトが実行されるように test_executor.py を更新するか、独自の Executor ユーティリティを作成します。

  • 手動でユーティリティを Compute Engine で起動してフォアグラウンド プロセスとして実行する代わりに、システムまたはサードパーティ ツール(たとえば systemdSupervisor)によってデーモンとして自動的に起動できます。

  • Cloud Scheduler と Cloud Pub/Sub では、どちらも厳密な「正確に 1 回」の配信は保証されていません。可能性は低いものの、メッセージが重複して配信される可能性があります。特定のタスクを複数回実行することで望ましくない結果が生じる場合、Zookeeper などの分散型永続ロッキング ツールを使用して、タスクが単一のインスタンスによって確実に 1 回のみ実行されるようにしてください。

  • 複数のタスクをスケジューリングするときは、cron のベスト プラクティスに沿って、タスクが次回実行されるまでに、タスクが処理を完了できるように、各タスクの間隔を十分に取ってスケジューリングします。

  • Compute Engine インスタンスの実行がすべてのタスクに必要かどうかを確認してください。または、Cloud Pub / Sub メッセージに応答して Cloud Functions をトリガーします。Cloud Functions は Cloud API を呼び出せても、シェル スクリプトを直接実行することはできません。シェル スクリプトを実行する必要がある場合は、Compute Engine API を呼び出して、スクリプトを実行するための一時的な Compute Engine インスタンスを作成します。これらのインスタンスは、タスクが終了すると自動的にシャットダウンします。これにより、最小限のコストで、イベント時刻のすぐ後にタスクを完了するように、柔軟に対応できます。

Google Cloud Platform のその他の機能を試す。チュートリアルをご覧ください。

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...