プロダクションパイプラインの構築

プロダクションワークフローは、信頼性の高いパイプラインを必要とします。このドキュメントで説明する原則に従ってパイプラインを構築することで、保守が容易になり、SLA 違反が発生する前に問題を把握できるようになります。また、パイプラインの重要なポイントに関する知識を共有しやすくなります。これは、パイプラインのライフサイクル全体、開発から長期間の保守まで、すべての段階で重要です。

このドキュメントは、パイプライン開発者とパイプライン保守者の両方に役立ちます。開発者の場合、プロダクションに直接移行するパイプラインを構築する前に役立ちます。同様に、このドキュメントは、プルーフオブコンセプトパイプラインがプロダクションパイプラインに変換される際にも使用できます。パイプライン保守者にとっては、以下の要素が保守モードに入る前提条件となります。

パイプラインの定義と期待値

プロダクションパイプラインの構築を開始する前に、期待値に関して確定的な答えを持っていることは常に可能ではありませんが、できるだけ早い段階でそれらを意識しておくことが価値があります。パイプラインの定義と期待値を確立する際に、それらを文書化することを強くお勧めします。

期待値は、プロダクションパイプラインの設計とセットアップのいくつかの側面に影響を与えます。これには以下が含まれます。

• パイプラインの設計とアーキテクチャの決定。
• スケジュールの設定方法（これがパイプラインの構築頻度を制御する主要な方法であるため）。
• 必要な検証と監視。
• パイプラインが保守モードにあるときに問題をどのように優先するか。

チームで対処すべき重要な質問は以下の通りです。

• パイプラインの範囲は正確に何ですか？ それはどこから始まり、どこで終わりますか？ どこで他のパイプラインにフィードすべきですか？
  • パイプラインの一部が別のパイプラインやユースケースと重複している場合は、重複する部分を独自のパイプラインとして扱うことを検討してください。
• パイプラインの再読み込みレートに対する要求は何ですか？
  • または、データが特定の時刻までに再読み込みされる必要がありますか？
  • パイプラインは週末に実行する必要がありますか？
  • データがいつ重大な遅れがあると見なされますか？
  • 再読み込みレートとサポートに関する期待は何ですか？
  • 注意 — これは簡単に聞こえますが、パイプライン保守チームが最も困難を感じるのはこの分野です。ここで明確な定義がなければ、パイプラインの保守者として作業を優先するのが難しくなりますし、適切な修正を行うこともできません。
• エンドツーエンドの伝播遅延に対する期待は何ですか？ 言い換えれば、データが Foundry に着陸する瞬間から、パイプラインの出力が更新されるまでの間に、データがパイプラインを通過するのにどれくらいの時間がかかるべきですか？
• 各外部ソースから取得する際の連絡先は誰ですか？ 外部ソースは、Data Connection の同期や、パイプラインにフィードする別の上流の Foundry パイプラインです。
• データの正確さに関する機能保証は何ですか？ パイプラインにとって重要な列や、検証が必ず真でなければならないキーはありますか？
  • 注意： 保証が破られた場合の結果を決定することが重要です。失敗した検証がエンドユーザーにデータを届けるのを防ぐべきですか、それともパイプラインの更新を防がずにアラートを発行すべきですか？他の最新のデータをパイプラインを通して流すために、後者の方法を選ぶことができます。これら2つの異なる状況の実装は異なります。ドキュメントは、早い段階で保証を追跡するための適切な場所です。
• 決定された期待値は互換性がありますか？ 複雑なシステムが成長するにつれて、障害が発生しやすくなります。一般的には、アラートが発生した後に十分な時間を確保して、予期しないパイプラインの障害や上流ソースからのデータ欠落などの根本的な問題に対処できるようにします。
  • 例 1： 伝播遅延を、予想されるパイプラインの再読み込みレートと関連付けて考えることが重要です。再読み込みレートが 2 時間ごとで、パイプラインの構築に 1.5 時間かかる場合、SLA に従うことが難しくなるかもしれません。
  • 例 2： ワークフローが 1 時間ごとの再読み込みレートを必要としているが、上流のデータソースが 1 日に 2 回しかデータを提供しない場合。これは、1 時間ごとの再読み込みを達成できないことを意味します。

プロダクションパイプラインの原則

成功するプロダクションパイプラインの設定のための主要な原則は、「自分がそれを維持するために存在しないという考えで構築する」 ということができます。

これを実現するための具体的なヒントは以下の通りです。

• コードをバージョン管理し、意味のあるコミットメッセージを書く： これにより、変更がいつ、誰によってコミットされたか、どのような変更が行われたかを把握しやすくなります。
  • プロダクションパイプラインでは、可能であれば Java と Python を推奨します。これらの言語には多くのリソースがあり、開発者コミュニティも充実しています。 SQL は非常にアクセスしやすいですが、すぐに複雑になり、デバッグが難しくなるためです。
• 可読性を最優先に最適化する： シンプルなパイプラインは保守が容易です。変換コードで標準的なソリューションや既存のソリューションを選択することで、保守負担や開発の複雑さが減少します。独自の方法で何かを行う必要がある場合は、十分に文書化してください。
• 可能な限り線形パイプライン： 一般的なアーキテクチャにおいて、保守が容易なパイプラインは、単純で直線的なものですが、そこにたどり着く方法についての推奨事項を出すことは難しいです。パイプラインの全体構造を意識し、制約が許す限り読みやすさとシンプルさを最適化してください。プロダクションにパイプラインを移行しようと考えている場合、パイプラインを解決するために少し時間をかけることが、通常は時間がよく使われることになります。
• プロダクションパイプラインは長期にわたって使用されることが多い。 その結果、パイプラインを作成した人が長期的にパイプラインを保守または管理する人ではない可能性が高いです。パイプライン開発や保守を引き継ぐ次の人が、コードを読んでパイプラインのセットアップを理解できるようにしましょう。
• 簡潔なドキュメントを維持する：
  • ロジックドキュメント： 一般的に、ロジック自体に関するドキュメントは、コードコメントに記載することが推奨されます。
  • 全体的なパイプラインドキュメント（パイプラインの定期的な問題を含む）： これもパイプラインに近い直感的な場所に保管する必要があります。これには、パイプラインが所属するプロジェクトが適しています。パイプライン開発者と保守者にとって見つけやすくする必要があります。
  • 記憶しておくこと：過剰なドキュメント化は、読みにくく、あまり役に立たなくなります。簡潔で重要な情報をドキュメント化してください。長く詳細なパイプライン情報を記録する必要があり、それほど頻繁に参照されない場合は、別のドキュメントに記録しておくことを検討してください。

開発プロセスとインフラストラクチャのセットアップ

開発

パイプラインがプロダクションに移行したら、パイプラインにさらなる貢献をするための開発プロセスが確立され、パイプライン開発者に効果的に伝達されることを確認することが重要です。これにより、パイプラインで予期しない停止が発生しないようになります。

そのため、以下をお読みいただくことをお勧めします。

• 開発のベストプラクティス： 少なくとも、プロダクションパイプラインは読みやすく、保守が容易で、マスターブランチがロックされている必要があります。ただし、開発セットアップをより堅牢にするために、このドキュメントで詳しく述べられているアドバイスをお読みください。
• ブランチングとパイプラインリリースプロセス： パイプラインの開発段階でブランチングとパイプラインリリースプロセスを使用していない場合は、パイプラインをプロダクションに移行する際にこれをお勧めします。このドキュメントでは、使用できる例のプロセスが提供されます。

インフラストラクチャ（スケジュール）

関連する話題として、早期にスケジュールを設定することで、パイプラインのさまざまな部分のビルドを手動でトリガーすることを考えずに開発できます。スケジューリングが乱雑であると、変更がパイプラインを自動的に伝播しないため、開発が妨げられ、作業が遅くなることがあります。

パイプラインをプロダクションに移行する際には、スケジュールを見直し、再構築することも推奨されます。開発中に使用されたスケジュールは、もう意味をなさなくなるかもしれませんし、アンチパターンを含んでいるかもしれません。このステップは、保守モードに移行する前に行う必要があります。

ベストプラクティスに従ってスケジュールを設定するか見直す方法は、スケジューリングのベストプラクティスのドキュメント に従って行うことができます。

早期に監視を開始する

パイプラインが定期的に実行されるようになると、その動作を監視することが望ましいです。これにより、技術的な負債が蓄積されるのを防ぎ、パイプラインの期待値が現実的かどうかを追跡できるようになります。チームの期限やキャパシティによっては、すぐに監視を開始できないことがありますが、可能な場合はそれをお勧めします。

パイプラインの監視方法については、パイプライン監視のベストプラクティスのドキュメントを参照してください。