コンテンツに移動
アプリケーション開発

ワークフローで構築する 3 つの一般的なサーバーレス パターン

2021年3月5日
https://storage.googleapis.com/gweb-cloudblog-publish/images/appdev.max-2600x2600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2021 年 2 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

2021 年 1 月、Google はワークフロー オーケストレーションと自動化サービスの一般提供を開始しました。同時に、他の Google Cloud プロダクトとのシームレスな統合を実現するコネクタのプレビュー版を加え、ワークフローをアップデートしました。ワークフローとコネクタは、高度なサーバーレス アプリケーションの構築に役立つ一般的なアーキテクチャ パターンの設計に最適です。

ワークフローは、インターネット上で利用できるサーバーレス プロダクトで、Google Cloud APIs と HTTP ベースの API 全体の作業をオーケストレートできます。また、インフラストラクチャの管理が不要で、オペレーションの完了を待つ間の料金は発生しません。ワークフローの主な機能について詳しくは、過去のブログ投稿をご覧ください。

このブログ投稿では、ワークフローの繰り返し実行をスケジュール設定する、結果をポーリングすることで API リクエストの長時間実行に対応する、データベース エントリの配列によって反復処理を行うなど、有用なアーキテクチャ パターンをご紹介します。

ワークフローのスケジュール設定

ユーザー トラフィックが想定の正常な範囲を超えるたびにサポートチームによる介入が必要になる e コマースサイトまたはゲーム アプリケーションを考えてみましょう。この場合、オンライン ユーザーの数が極端に少なければ、障害の可能性が考えられます。また、同時接続ユーザー数が想定の範囲を超えると、スケーラビリティの問題が起こる可能性が高まります。

オンラインの同時接続ユーザー数は、ログイン / ログアウトのトランザクションで更新する分散カウンタにより、Firestore データベースに保存されます。ワークフローでは、カウンタの値を定期的に確認し、値に応じて対応する必要があります。

以下のようなワークフローが考えられます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Scheduled_workflows.max-2000x2000.jpg

5 分ごとにトリガーされるワークフローが、Firestore コネクタを使用して Firestore データベースから現在のユーザー数の値を取得します。また、カウンタの値に加え、前回のワークフローの実行時に保存された、トラフィックの最後の状態(「少ない」、「通常」、「多い」など)も取得します。

ワークフローに組み込まれた switch ステップをカスタム数式と組み合わせて使用することで、現在のカウンタの値と前回のワークフロー実行時に保存された値を比べて、状態が異なるかどうかを判定します。前回と異なる場合は、新しい状態を Firestore データベースに保存して、Pub/Sub コネクタがサポートチーム宛てにメッセージを push し、状態の変化を知らせます。ワークフローは、現在のカウンタの値と最後に記録された状態を確認し、状態が変わった場合のみ通知を送信します。

わずかな手順で、前述のワークフローはすべての実行履歴のトラッキング機能を備えた、信頼性の高いサーバーレス アプリケーションになりました。また、組み込みの Identity and Access Management(IAM)統合により、Firestore や Pub/Sub などの Google Cloud プロダクトが操作しやすくなりました。

前述の例のような Cloud Scheduler を使用したワークフロー実行のスケジュール設定方法について詳しくは、こちらのガイドをご覧ください。

API ポーリングを使用したワークフロー

外部 API を使用して、長時間実行ジョブの実行をリクエストするワークフローを検討しましょう。ジョブの実行リクエストを受け付けた外部 API が返す一意のジョブ ID を、このジョブの実行ステータスのポーリングに使用できます。このジョブの完了には数時間かかる場合があります。また、ワークフローはこのジョブが完了しなければ次のステップに進むことができません。この API にはジョブの完了をワークフローに通知する機能がないため、ワークフローは定期的にジョブのステータスをポーリングする必要があります。

以下に示すワークフローでは、このパターンを実装し、2 分ごとにジョブのステータスを確認しています。なお、ワークフローの料金モデルは実行ステップの数に基づいています。スリープ オペレーションにかかる時間に関する料金は発生しません。ワークフローは最大で 1 年間実行できるため、実行時間が極端に長いジョブも確実に完了できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Workflows_with_API_polling_.max-1900x1900.jpg

実際のシナリオでは、外部 API の認証キーをセキュアなストレージ システムから取得するステップを、このワークフローの始めに追加する必要がある場合があります。キーまたはパスワードのストレージ システムとして Secret Manager を使用し、キー値の取得に Secret Manager コネクタ機能を使用することをおすすめします。

データベース レコードの配列による反復処理

この例では、アプリケーションで 1 日に 1 回、お客様の記録を確認し、請求書の支払い期日が過ぎているお客様に通知メールを送信する必要があります。

以下のワークフローでは、Firestore コネクタを使用して、支払い期日を過ぎたすべてのお客様のエントリを取得するクエリを実行します。ワークフローはこのセットを繰り返し、SendGrid などの外部 Email API を使用して未払い金に関するメール通知をそれぞれのお客様に送信します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Iterating_through_an_array_of_database_rec.max-2000x2000.jpg

前述の例では、ワークフローの機能を使用して配列を処理し、配列の要素ごとにタスクを実行しています(こちらの例をご覧ください)。ワークフローでエラー処理や再試行を指定することで、断続的な障害や特定のエントリにエラーが起こった場合でも、残りのメッセージをお客様に正常に送信できます。

前の例と同様に、Secret Manager を呼び出してメールサービスのアクセスキーを取得するコネクタをワークフローに追加する必要がある場合があります。

ワークフローに備える

実際の基幹業務アプリケーションでは、多くの場合、複数のアーキテクチャ パターンを組み合わせて使用する必要があります。実際のユースケースが前述の例と異なる場合でも、定期的なスケジュール、ポーリング、配列の反復処理のパターンの応用により、さまざまな実装を構成できます。ワークフローは API ベースのサーバーレス アーキテクチャをサポートしているため、ビジネス ロジックを完全に制御しながら、継続的な運用オーバーヘッドを最小化します。一方、Pub/Sub、Firestore、Compute Engine、Secret Manager、Cloud Tasks などの Google Cloud プロダクトへのコネクタを使用すると、ワークフローを環境に統合しやすくなります。

ワークフローが一般提供となったことにより、本番環境の基幹業務アプリケーションに安心してご利用いただけるようになりました。また、API 呼び出しの組み込みのエラー処理により、アプリケーションの信頼性をさらに高めることができます。詳しくは、ワークフローのランディング ページをご覧になるか、Cloud Console から直接お試しください。

-ワークフロー プロダクト マネージャー Filip Knapik

投稿先