A SOFT methodology to define robust data platformsの翻訳です。
2022年12月8日
堅牢なデータ・プラットフォームを定義するためのソフトな方法論
堅牢で将来性のあるデータセットアップを決定することは複雑です。SOFTの方法論は、お客様のニーズに合った正しい選択へと導きます。
今日のデータ主導の時代では、ビジネスがイノベーションを促進し、市場で競争できるようにデータプラットフォームを設計することが重要です。堅牢で将来性のあるツールやアーキテクチャを選択するには、純粋に技術的な懸念と、プロジェクトのより広い制約の間でバランスを取る必要があります。こうした制約には、規制、既存の従業員のスキル、人材獲得、合意されたスケジュール、自社の確立されたプロセスに関する課題が含まれる。
最新のデータプラットフォームとは、ビジネスニーズを満たすために、社内システム全体でデータを保存・移動できるようにする技術、構成、実装の詳細のセットです。SOFTの方法論は、スケーラブルで、観測可能で、高速で、信頼できる、将来性のある効果的なデータプラットフォームを定義するための、4つの柱に基づいたアプローチを紹介しています。その目的は、データアーキテクトと意思決定者が、現在の実装と将来のアーキテクチャの両方を異なる基準で評価できるようにすることである。
- スケーラブル：負荷量、ユースケース、開発プラットフォーム、コストの変動に対応するソリューションの能力。
- サービス監視やデータ資産の発見に関するオプションがあるかどうか。
- データ配信、パイプライン開発、問題からの復旧にかかる時間を分析する。
- 信頼できる:**安全で、監査可能で、一貫性のある結果を提供する能力。
このブログの残りの部分では、それぞれの柱を詳細に検証し、それぞれの柱の評価時に対処すべき一連の質問を提供する。
スケーラブル
データ量とユースケースは日々、かつてないスピードで増加している。したがって、現在の一連の要件をサポートし、さまざまな方向に拡張する能力を持つ技術的ソリューションを見つける必要がある。
技術的スケーリング
成長余地のあるソリューションを設計する。現在のニーズを定義し、将来の成長を予測することで、特定のアーキテクチャの限界にいつ突き当たるかを理解することができる。最新のクラウドでは、より大きなサーバーを作成することで、非常に深い垂直スケーリングが可能ですが、高可用性と迅速なフェイルオーバーも重要な考慮事項です。ノード間で負荷を分割する水平スケーリングをサポートするテクノロジーは、通常、ニーズに応じてアップ/ダウンサイジングのためのより多様なオプションを提供しますが、これらは一貫性のトレードオフを引き起こす可能性があります。
生のスケーリングに加えて、自動化オプションとスケーリングにかかる時間も考慮する必要がある。トラフィックのピークが予測される場合には手動で、特定の監視しきい値を超えた場合には自動で、データプラットフォームのサイズをアップ/ダウンできるようにする必要がある。スケールするまでの時間も非常に重要です。最小に抑えることで、より優れた弾力性とリソースの無駄を減らすことができます。
プライマリインスタンスだけでなく、高可用性、読み取り専用のレプリカの可能性、バックアップとリストアプロセスの堅牢性とスピードなどです。
ビジネスケースのスケーリング
したがって、データ・プラットフォーム・ソリューションには、新しいユースケースへの参入障壁の低さと、そのソリューションをサポートする十分な容量の両方が必要である。
ソリューションがより多くのユースケースや新しいテクノロジーをサポートするためには、優れた統合を利用できることが重要です。データ保護に関する規制に準拠するためには、適切で拡張性のあるセキュリティ管理とユースケースの分離が必要です。また、データの島を分離する能力も必要です。
さらにデータを成功させるためには、すでに利用可能なデータセットを探索するためのインターフェースを提供することで、さまざまなユースケースにおけるデータの再利用を促進し、イノベーションを加速させることができる。
人間のスケーリング
どんなに自動化が進んでいても、新しいパイプラインを構築し、テストし、監視するためには、データ・プラットフォームには人間が必要である。データ・ソリューションを選択する際には、現在のチームのスキルや経験、そして企業が事業展開している地域に基づく成長の可能なコストを評価する必要がある。
よく採用されているオープンソースのデータソリューションを選択すれば、より多くの人材が集まり、熱心な開発者が増える。あらかじめ定義された統合や拡張機能を提供するマネージド・ソリューションを利用することで、チームの負担を軽減することができる。
財務スケーリング
スケーラビリティの最後の部分は金銭的なものである。技術的に完全に有効なデータソリューションであっても、財政的に持続可能でなければ採用することはできない。ドル対スケール**比率を理解することは、コストを大幅に上昇させる可能性のあるアーキテクチャの将来的な変更をマッピングすることと同様に、非常に重要である。
コストの微分を計算し、データ量に応じて直線的に（できればそれ以下に）拡張できるソリューションを目指す必要がある。
質問
- この技術を垂直的、水平的に拡大するために、どのような選択肢があるか？
- 新しい技術を追加するのは簡単か？
- データ・セキュリティはどのように管理できるか？
- チームの現在の経験は？
- 人材プールはどのくらいあるか？
- 管理と開発の複雑さは？
- 新しいデータの追加や抽出、他の技術との統合は容易か？
- スケーリングのコストは？データ量に応じて直線的に成長するか？
財務的なスケーラビリティを評価しないリスクは、現在は機能するが、将来のビジネスやユースケースの成功に対応できない完璧なシステムを構築することである。
観測可能
最新のデータ・プラットフォームや新しいストリーミング・データ・パイプラインは "ライブ・システム "であり、監視し、エラーを把握し、修正を迅速に適用することが、成果を上げるための必須条件である。
モニター
ダッシュボードでデータパイプラインの終了ステータスをチェックするだけでは不十分で、簡単に定義できるメソッドが必要だ：
- メトリクスとログの統合
- 集計と関連するKPI（主要業績評価指標）
- アラートしきい値
- 自動通知
人間がスクリーンを見ることに頼るのは、リソースの有効活用とは言えず、拡張性もない。プラットフォームの監視を自動化し、正確な外部監視を可能にするツールを選択することで、企業は管理作業を一元化することができる。
鳥瞰図の再現
新しいパイプラインや新しいテクノロジーが常に追加される中、すべてのデータ資産のインベントリーを把握し、それらが相互にどのように統合されているかを把握するのは難しい。将来を見据えたデータソリューションは、データ資産とその相互リンクの[自動収集、統合、公開を提供する必要がある。
あるデータポイントがどこから来たのかを追跡できることは非常に重要である。どのような変換が行われたのか、そのデータはどこに存在するのか、パイプラインのどの時点でも誰が、あるいは何がそのデータと相互作用できるのかを確認できなければならない。この情報は、セキュリティとプライバシーの要件、特にデータのリネージ、セキュリティ、影響評価、GDPRクエリに準拠するのに役立つ。
データ資産のクエリ可能なグローバルマップを取得することで、データの再利用性に関してさらなる利点がもたらされる。企業内にすでに存在する資産を公開することで、繰り返されるデータ作業を回避し、部門間でのデータの再利用を促進し、より迅速なイノベーションを実現することができる。
履歴の再生とデータのバージョニング
継続的に進化するシステムにおいて、履歴の一部を再生する機能は、ベースラインを作成し、結果を比較する方法を提供する。これらは、新しい開発におけるリグレッションやエラーを検出し、アーキテクチャの変更による影響を評価するのに役立ちます。
新しい "プロッドライク "な開発環境を簡単にスピンオフすることで、より迅速な開発反復、より安全な仮説検証、より正確なテストが可能になります。
データのバージョニング」機能を持つことで、開発段階をまたいでデータ操作の結果を比較することができます。実行統計を含む「メトリクスのバージョニング」を追加することで、パフォーマンス回帰をより適切に（おそらくは自動的に）処理することができます。
質問すること
- 私のデータ・プラットフォームで今何が起きているのか？
- すべてうまくいっていますか？遅れはないか？
- 私の会社にはどのようなデータ資産がありますか？
- 社内でデータはどのように変換されていますか？
- 処理エラーが発生した場合、パイプラインの一部を再生できますか？
- ベースラインに対する変更のパフォーマンスはどうですか？
速い
マイクロバッチからストリーミングに至るまで、データ配信にかかる時間はリアルタイム化の傾向にある。昨日のデータで報告するような古い時代は終わり、新鮮なデータに基づいて、現在ビジネスで何が起きているかをほぼリアルタイムで報告できる必要がある。
開発の時期
パイプラインの開発とテストに何週間もかかるようでは、ほぼリアルタイムでデータを提供しても意味がない。ツールチェーンはセルフサービスでユーザーフレンドリーでなければならない。これを達成するためには、対象となる開発者とそのスキルを特定し、このグループが迅速かつ効果的に、そして楽しく作業できるような一連のテクノロジーを選択することが極めて重要である。ユースケースが定義されたら、問題の複雑さの一部を取り除くことで助けになる既存のソリューションをチェックすることも価値がある。
自動化に時間を投資することで、データパイプラインの展開における摩擦や遅延を減らすことができる。プロトタイプを本番稼動させるためにクリックしまくることに時間を奪われるべきでない。自動化されたチェックとプロモーション・パイプラインが、アーティファクト・ジャーニーのこの部分を引き受けるべきである。
納品までの時間
データ・ストリーミングを可能にするデータ・アーキテクチャを選択することは、将来性のあるパイプラインを構築するための鍵となる。また、バッチからストリーミングへの移行機能を持つことで、ビッグバン・アプローチではなく、反復的な方法で既存のパイプラインを改善することができます。
Time To Deliver(y)**の不可欠な部分は、Time To Executeでもあります。選択したプラットフォームのパフォーマンスは、目標とするレイテンシーの数値に対して評価する必要があります。
復旧までの時間
最後に、データパイプラインに問題が発生した際に、許容できるTime To Recoverのしきい値を定義することが極めて重要である。これを達成するためには、選択したツールチェーンがこの領域で何を提供するかを理解し、テストし、検証する時間を取ることです。特にステートフル・トランスフォーメーションを扱う場合、チェックポイント、ジャストワンス・デリバリー、イベントの再生に関するオプションをナビゲートすることが極めて重要である。特にイベントの再生は、新しい開発を検証し、A/Bテストを実行し、問題のある状況から素早く回復するのに便利である。
質問すること
- ソースとなる事象と関連する洞察との間にどれくらいの遅延があるか？
- そのタスクに対するテクノロジー・パフォーマンスはどの程度か？
- 新しいパイプラインをどれくらいのスピードで作成できるか？
- どれくらいの速さで本番環境に変更を適用できますか?
- クラッシュからの復旧速度は？
信頼できる
データは企業にとって最も価値のある資産であり、信頼できるデータ・プラットフォームを構築することは、すべての利害関係者が質の高い情報を入手できるようにするための鍵である。
セキュリティ
信頼の最初の側面は、セキュリティに関するものである。観測可能のセクションで簡単に述べたように、ツールチェーンは、[どのアクターが特定のデータポイントにアクセスできるか、また、どのような権限を持っているかを定義し、継続的に監視できるようにすべきである。さらに、プラットフォームは、データへの不適切なアクセスをリアルタイムで検出して報告するために、十分なロギングとモニタリング機能を提供すべきである。セキュリティ変更の影響を評価する方法（影響評価）を提供することで、変更を行う前のさらなるレベルのチェックが保証される。
規制は、何がデータの正しい使用法であり、どの属性をマスクまたは削除する必要があるかを定義する。将来性のあるデータ・プラットフォームを構築するためには、データ受信者の役割／特権に応じて異なる難読化処理を適用する機能が必要である。
この記事では、自動化について多く取り上げた。セキュリティに関しては、多くのチェックがコードで実行できる一方で、企業が必要なセキュリティ規制を遵守できるように、人間の評価と承認が必要な手動ゲートを保持したいと思うかもしれない。
ベンダーのエコシステム評価
信頼できる将来性のあるデータプラットフォームを構築するためには、ツールを提供するベンダーやプロジェクト、そしてツールの耐用年数中に新機能を追加して進化し続ける能力に対する信頼が必要である。
したがって、企業やオープンソースプロジェクトを幅広く評価する必要がある。ツールの採用状況、既存のコミュニティや関連する成長パターン、利用可能なサポート方法などを考慮する。これらのトピックを総合すると、現在の技術ソリューションが将来も良い選択肢であるかどうかを理解するのに役立ちます。
データのローカリティとクラウドの選択肢
企業は、データが世界のどこに保存され、操作されるかを定義する必要があるかもしれない。データ・パイプライン全体で一貫したロケーションを使用することを余儀なくされると、利用可能なテクノロジーやベンダーのリストが減少する可能性がある。クラウド、マネージドサービス、マルチクラウド戦略の採用に関する社内ポリシーによって、選択肢はさらに絞り込まれる。
データの正確性
純粋なデータの観点から、「信頼できる」とは、生成された結果が信頼できることを意味する。
結果は新鮮で、正しく、再現性があり、一貫している必要がある：
- 結果は最新かつ正確なデータの表現である。
- KPIと変換は定義に従うべきである。データ変換/KPI は全社的に一度定義されるべきであり、一意な真実の源を提供する。
- ワークフローは同じ入力で再実行され、同じ出力を提供することができる。
- 一貫性がある**：実績はエラーに強く、時間を超えて一貫しているため、利害関係者はタイムリーにデータを受け取ることができるという確信を得ることができる。
質問すること
- どのようにデータを保護できますか？データをマスクしたり、行や列にフィルタを適用することはできますか？
- ツールを提供するベンダーやプロジェクトは信頼できるか？
- 特定のデータセンター／地域でツールを使用できますか？
- フローのどの段階でも、正確にデータの場所を特定できますか？技術的な観点からも、地理的な観点からも？
- データは信頼できますか？データは正しいか、結果は再現可能か、時間通りか、一貫しているか？
- 特定のKPIを会社全体で何回定義しているか？
自組織にSOFTを導入する
次のデータプラットフォームを定義する場合でも、既存のプラットフォームを評価する場合でも、SOFTフレームワークは選択肢を評価するための包括的なガイドラインを提供します。質問のリストを評価のベースラインとして使用することで、さまざまなソリューションを適切に比較し、データニーズに最適なソリューションについて、より多くの情報に基づいた決定を下すことができます。
SOFTフレームワークを使ってみて、ご意見をお聞かせください！
Aivenと私たちのサービスに関する最新ニュースや、オープンソースに関する様々な情報を入手するには、月刊ニュースレターを購読してください！Aivenに関する日々のニュースは、LinkedInとTwitterのフィードでご覧いただけます。
サービスの更新情報を知りたい方は、変更履歴をご覧ください。
まだマネージド・データ・プラットフォームをお探しですか？
見つかりました！