Zenn
Open3

定期実行のBatchを作成する際の観点・注意点などについて

AWS Batch
設計
batch
定期実行
まさぴょんまさぴょん

定期実行バッチを作成・運用する際に留意すべき主なポイントを整理📝

1. スケジュール・実行計画

  • 実行頻度や時間帯の検討：業務上の要求やシステム負荷を考慮し、最適な実行タイミングを決定する。
  • ピーク時間帯の回避：システム全体の負荷が高い時間を避けることで、他システムへの影響やバッチ処理自体の遅延を回避する。
  • 運用カレンダーの考慮：休日や定期メンテナンス時間を考慮し、一部バッチを実行しない日を設定するなどの柔軟性を確保する。

2. エラーハンドリング・リカバリ

  • エラー検知と通知：処理中のエラーを即座に検知し、アラートメールやSlack通知などで運用担当者に知らせる仕組みを用意する。
  • 再実行の容易性：中断やエラー発生時、問題箇所から再開できるようなチェックポイント機能やステート管理を設計に取り入れる。
  • リトライ戦略：通信エラーや一時的なリソース不足など、一時的エラーを考慮し、適切な回数・間隔で再試行する。

3. ログ・モニタリング

  • 詳細なログ出力：入力パラメータ、処理件数、処理結果などを細かく記録し、トラブルシューティングを容易にする。
  • ログローテーションと保存期間：ログが肥大化しないようにローテーションを行い、法律や監査要件に応じて適切な保存期間を設定する。
  • 外部監視ツールとの連携：Zabbix、Prometheus、DataDogなどのツールを活用して、バッチのパフォーマンスや正常性を継続的に監視する。

4. パフォーマンス・リソース管理

  • 適切なリソース割り当て：CPU、メモリ、I/O など、バッチに必要なリソースを確保しつつ、他の重要プロセスへ影響を与えないように配慮する。
  • スケールアウト・スケールアップ：処理量拡大に備え、インフラのスケールアウト（並列化）やスケールアップ（高性能環境への移行）を検討する。
  • 計測とチューニング：定期的なパフォーマンス計測を行い、ボトルネック特定と改善を継続する。

5. セキュリティ・アクセス管理

  • 認証・認可設定：バッチがアクセスするリソースやDBへの接続は、最小権限で運用する。
  • 機密情報の保護：パスワードやAPIキーなどの秘密情報は、安全なVaultや環境変数管理ツールなどで安全に保持する。
  • 通信経路の暗号化：外部API連携などがある場合はHTTPSなどの安全な通信手段を用いて機密性を確保する。

6. 外部依存関係

  • 外部APIや他システムへの依存：相手側メンテナンス時間やレスポンス遅延が処理に影響しないよう考慮する。
  • リトライ・待機ロジック：外部サービスが一時的にダウンした際、一定時間後の再試行やフォールバックを行う。
  • バージョン管理と変更検知：外部システムの仕様変更に対応するため、定期的な仕様確認やバージョン管理を行う。

7. テスト・検証環境

  • 本番環境と同様の検証環境：可能な限り本番と同等の環境でテストを行い、問題発生を事前に検知する。
  • 定期的な試験実行：定期的にテストバッチを実行し、本番環境でのトラブル発生を未然に防ぐ。
  • 障害シナリオの事前テスト：ネットワーク切断、ディスクフル、APIダウンなど想定可能な障害をテストケースに組み込み、リカバリ手順を確認する。

比較表 (Markdown形式)

観点 内容 目的 具体的対策例
スケジュール・実行計画 実行頻度・時間帯、運用カレンダーの考慮 バランスの良い稼働、業務影響の最小化 ピーク回避、休日停止、時間帯分散など
エラーハンドリング・リカバリ エラー検知、再実行性、リトライ戦略 障害対応容易化、安定稼働 アラート通知、チェックポイント実装
ログ・モニタリング 詳細ログ出力、監視ツール連携 トラブルシュートの容易化、可観測性向上 詳細ログ、外部監視連携、ローテーション
パフォーマンス・リソース管理 リソース割り当て、計測・チューニング 処理効率向上、拡張性確保 スケール戦略、定期計測・チューニング
セキュリティ・アクセス管理 最小権限、秘密情報保護、通信暗号化 セキュリティ強化、機密性確保 Vault活用、HTTPS通信、認可設定
外部依存関係 他システム・API依存、再試行・待機 外部要因の影響軽減、安定性確保 リトライロジック、仕様変更追従
テスト・検証環境 本番同等環境、定期的試験、障害シナリオテスト 品質保証、事前問題発見 同等環境構築、定期テスト、障害訓練
まさぴょんまさぴょん

Lambda & EventBridgeで作成する定期実行Batch処理📝

Lambda & EventBridgeで作成する定期実行Batch処理のデメリットは、15分間だけという実行時間の制限だが、そもそも処理Logicの実態を、Lambdaから呼び出すAPIに持たせればタイムアウトを気にする必要はない！

まさぴょんまさぴょん

定期実行バッチを作成・運用する際に留意すべき主なポイントを整理📝 by Felo

定期実行のバッチ処理を作成する際には、いくつかの重要な点や観点を考慮する必要があります。以下に、主な考慮点を整理します。

考慮すべき観点

  1. 処理の要件定義

    • バッチ処理の目的や要件を明確にすることが重要です。具体的には、処理するデータの種類、量、頻度、実行時間などを定義します。

  2. エラーハンドリング

    • エラーが発生した場合の対応策を事前に考えておく必要があります。エラーログの出力、リトライ機能、ロールバック機能などを実装し、問題発生時に迅速に対応できるようにします。

  3. パフォーマンスの最適化

    • 大量のデータを効率的に処理するために、処理の並列化やバッチサイズの調整を行います。また、I/O待ちのオーバーヘッドを減らすために、データをまとめて処理することが推奨されます。

  4. スケジューリング

    • バッチ処理の実行タイミングを適切に設定します。業務のピーク時間を避け、システムリソースが空いている時間帯に実行することで、他の業務に影響を与えないようにします。

  5. 監視とログ管理

    • バッチ処理の実行状況を監視し、ログを適切に管理することで、問題の早期発見と対応が可能になります。重要なイベントやエラーについては、通知を設定することも考慮します。

  6. 保守性の確保

    • システムの運用が長期にわたることを考慮し、保守性を高める設計を行います。コードの可読性やドキュメントの整備、依存関係の管理などが含まれます。

  7. テストの実施

    • バッチ処理の実装後には、十分なテストを行い、期待通りに動作することを確認します。特に、異常系のテストを重視することが重要です。

整理した表

以下は、上記の考慮点をMarkdownのテーブル形式で整理したものです。

| 観点               | 説明                                                                 |
|--------------------|----------------------------------------------------------------------|
| 処理の要件定義     | バッチ処理の目的、データの種類、量、頻度、実行時間を明確にする。     |
| エラーハンドリング   | エラーログの出力、リトライ機能、ロールバック機能を実装する。         |
| パフォーマンスの最適化 | 処理の並列化やバッチサイズの調整を行い、I/O待ちを減らす。          |
| スケジューリング     | 業務のピーク時間を避け、リソースが空いている時間帯に実行する。       |
| 監視とログ管理      | 実行状況を監視し、重要なイベントやエラーについて通知を設定する。     |
| 保守性の確保        | コードの可読性、ドキュメントの整備、依存関係の管理を行う。           |
| テストの実施        | 異常系を重視した十分なテストを行い、期待通りに動作することを確認する。 |

このように、定期実行のバッチ処理を設計する際には、さまざまな観点を考慮し、適切な対策を講じることが重要です。