本番用パイプラインを構築する

本番ワークフローには、それを支える信頼性の高いパイプラインが必要です。パイプラインの構築時にこのドキュメントで示す原則に従うと、保守が容易になり、SLA 違反につながる前に問題を検出できます。ここで紹介する指針の一部は、パイプラインで何が重要かについて知識を共有しやすくするためにも役立ちます。これは、開発から長期的な保守まで、パイプラインのライフサイクルのすべての段階で重要です。

このドキュメントは、パイプラインの開発者と保守担当者の両方に役立ちます。開発者にとっては、構築したパイプラインをそのまま本番環境に導入する場合、構築を開始する前に役立ちます。また、概念実証用のパイプラインを本番用パイプラインに移行する際にも利用できます。保守担当者にとっては、以下の項目を満たすことが保守フェーズに入るための前提条件となります。

パイプラインの定義と期待される条件

本番用パイプラインの構築を開始する前に、期待される条件について明確な答えを出せるとは限りませんが、できるだけ早い段階から意識しておくことが重要です。パイプラインの定義と期待される条件は、確定するたびにドキュメントに記録することを強く推奨します。

期待される条件は、本番用パイプラインの設計と設定における次のような側面に影響します。

• パイプラインの設計とアーキテクチャに関する意思決定。
• スケジュールの設定方法（パイプラインのビルド頻度を制御する主要な方法であるため）。
• 必要な検証と監視。
• パイプラインが保守フェーズにあるときの問題の優先順位付け。

チームで検討すべき重要な質問には、次のようなものがあります。

• パイプラインの範囲は具体的にどこまでですか？ どこから始まり、どこで終わりますか？どこでほかのパイプラインにデータを渡すべきですか？
  • パイプラインの一部がほかのパイプラインやユースケースと重複する場合は、その重複部分を独立したパイプラインとして扱うことを検討します。
• パイプラインの更新頻度に関する要件は何ですか？
  • または、毎日特定の時刻までにデータを更新する必要がありますか？
  • 週末もパイプラインを実行すべきですか？
  • データが古く、重大な問題となるのはどの時点ですか？
  • 更新頻度とサポートについて、どのような条件が期待されますか？
  • 注意してください。簡単に聞こえますが、この領域はパイプラインの保守チームが最も困難に直面しがちなところです。ここで明確に定義しておかないと、保守担当者として作業の優先順位を付けたり、適切な修正を行ったりすることが難しくなります。
• エンドツーエンドの伝播遅延について、どのような条件が期待されますか？ つまり、データが Foundry に到着した瞬間からパイプラインの出力が更新されるまで、データがパイプラインを流れるのにどれだけの時間がかかるべきですか？
• データを取得するすべての外部ソースについて、それぞれの連絡先は誰ですか？ 外部ソースには、Data Connection の同期や、このパイプラインにデータを渡す別の上流 Foundry パイプラインが含まれます。
• データの正しさについて、どのような機能上の保証がありますか？ パイプラインで必ず条件を満たす必要がある重要な列や主要な検証はありますか？
  • 注： 保証が満たされない場合にどうするべきかを決めておくことが重要です。検証に失敗した場合、エンドユーザーにデータが届かないようにすべきですか？それとも、パイプラインの更新を妨げずにアラートを発報すべきですか？ほかの最新データがパイプラインを流れるようにするため、後者を選びたい場合もあるのではないでしょうか？この2つの状況では、実装が異なります。保証を早い段階から記録するには、まずドキュメントにまとめるとよいでしょう。
• 決定した期待条件は両立しますか？ 複雑なシステムは、規模が大きくなるほど障害が発生しやすくなります。一般に、アラートの発報後には、予期しないパイプラインの障害であれ、上流ソースからのデータの欠落であれ、根本的な問題に対処するための十分な時間を確保する必要があります。
  • 例1： 期待されるパイプラインの更新頻度と関連付けて、伝播遅延を考えることが重要です。期待される更新頻度が2時間ごとで、パイプラインのビルドに1.5時間かかる場合、SLA の遵守が難しくなる可能性があります。
  • 例2： ワークフローで1時間ごとの更新が必要なのに、上流のデータソースが1日2回しかデータを提供しない場合です。この場合、1時間ごとの更新は実現できません。

本番用パイプラインの原則

本番用パイプラインを適切に構築するための重要な原則は、「自分が保守を担当しないことを想定して構築する」 と要約できます。

これを実現するために役立つ具体的なヒントを紹介します。

• コードをバージョン管理し、意味のあるコミットメッセージを記述する： これにより、どのような変更が行われ、いつ、誰によってコミットされたかを追跡しやすくなります。
  • 本番用パイプラインでは、可能であれば Java と Python を推奨します。どちらの言語にも、利用可能なリソースが豊富にあり、強力な開発者コミュニティがあります。SQL は非常に使いやすい一方で、すぐに複雑化することがあり、そのためデバッグが難しくなる場合があります。
• 何よりも読みやすさを優先する： シンプルなパイプラインは保守も容易です。トランスフォームのコードで標準的な手法や既存の解決策を選ぶと、後々の保守負担や開発の複雑さを軽減できます。非標準的なことをどうしても行う必要がある場合は、必ず詳細にドキュメント化してください。
• 可能な限り直線的なパイプラインにする： 全体的なアーキテクチャの観点では、比較的単純で直線的なパイプラインほど保守しやすいものですが、その実現方法を一律に推奨することは困難です。パイプラインの全体構造を意識し、制約の範囲内で読みやすさとシンプルさをできるだけ高めます。パイプラインの本番環境への移行を考え始めたら、構造を整理するために時間をかけることは、通常、十分に価値があります。
• 本番用パイプラインは長期間使われることがよくあります。 そのため、パイプラインを作成する人と、長期にわたって保守や管理を担当する人が異なる可能性は高くなります。次にパイプラインの開発や保守を引き継ぐ人が、コードを読んでパイプラインの設定を理解できる必要があることを念頭に置いてください。
• 簡潔なドキュメントを維持する：
  • ロジックのドキュメント： 一般に、ロジック自体についてのドキュメントは、コードコメントに記述することを推奨します。
  • パイプライン全体のドキュメント（パイプラインで繰り返し発生する問題の記録を含む）：これも、パイプラインに近く、直感的にわかる場所に保管すべきです。たとえば、そのパイプラインが属するプロジェクト内が適しています。開発者や保守担当者が簡単に見つけられるようにすべきです。
  • 留意点：ドキュメントが多すぎると、読みにくくなり、有用性が下がることもあります。簡潔に記述し、重要な情報を記録します。あまり頻繁に参照しない、非常に長く詳細なパイプライン情報を記録する必要がある場合は、別のドキュメントに保管することを検討します。

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

開発

パイプラインを本番環境に移行したら、パイプラインにさらなる変更を加えるための開発プロセスを確立し、パイプライン開発者に確実に周知することが重要です。これにより、パイプラインで予期しない停止が発生するのを防ぎます。

そのため、次のドキュメントを読むことを推奨します。

• 開発のベストプラクティス： 本番環境のパイプラインは、少なくとも読みやすく、保守しやすく、master ブランチがロックされている必要があります。ただし、開発環境の設定をより堅牢にするために、このドキュメントの詳しいアドバイスを読むことを推奨します。
• ブランチとパイプラインのリリースプロセス： パイプラインの開発段階で、ブランチとパイプラインのリリースプロセスをまだ使用していない場合は、本番環境への移行時に導入することを推奨します。このドキュメントでは、使用できるプロセスの例を紹介しています。

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

これに関連して、早い段階でスケジュールを設定しておくと、パイプラインのさまざまな部分のビルドを手動でトリガーすることを考えずに開発を進められます。スケジュールが整理されていないと、変更がパイプライン全体に自動的に伝播しないため、開発が妨げられ、進行が遅くなることがあります。

パイプラインを本番環境に移行する際には、スケジュールを見直して再構成することも推奨します。開発中に使用したスケジュールは、適切でなくなっている場合や、アンチパターンを含んでいる場合があるためです。この手順は、保守モードに移行する前に実施する必要があります。

ベストプラクティスに沿ってスケジュールを設定または見直すには、スケジュールのベストプラクティスのドキュメント に沿って進めます。

早い段階で監視を開始する

パイプラインが定期的に実行されるようになったら、すぐにその動作の監視を開始することが望ましいです。これにより、技術的負債の蓄積を防ぎ、パイプラインでデータが満たすべき条件が現実的かどうかを確認できます。期限やチームの対応能力を考慮すると、すぐに監視を開始できるとは限りませんが、可能な場合は開始することを推奨します。

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