View on GitHub

Today I Learned

Software Engineering Blog

4. Choosing Technologies Across The Data Engineering Lifecycle

良いアーキテクチャを実現するために、適切なテクノロジーを選択する方法。

優れたデータテクノロジーを選択する基準は、データプロダクトとビジネス全般に対して付加価値を与えるかどうか。

データテクノロジーを選択する際に考慮すべき事項

テクノロジーの選択は、ユースケース、コスト、構築vs購入、モジュール化のバランスをとることだ。トレードオフを評価し、可逆な決定を目指そう。

4.1 Team Size and Capabilities

多くの役割を担うことを期待された少人数のチームなのか、もしくは専門的な役割を担う人がいるほどの大規模なチームなのか。

小規模なチームや技術力の弱いチームは、可能な限りマネージドツールやSaaSツールを使い、ビジネスに直接価値をもたらす複雑なもんだの解決にフォーカスしたほうが良い。

チームが慣れているテクノロジーやワークフローにこだわることを勧める。

4.2 Speed to Market

高品質のスタンダードとセキュリティを維持しながら、機能やデータをより速く提供できるようなテクノロジーを選択する。早いフィードバックループを構成する。

早く頻繁に価値を提供しよう。チームメンバーが既に知っているツールを使おう。

4.3 Interoperability

相互運用性とは、複数のテクノロジーの統合の容易さ。

モジュール化して設計し、新しいプラクティスや代替手段が利用可能になったら簡単にテクノロジーの入れ替えができるようにしておこう。

4.4 Cost Optimization and Business Value

コストはデータアーキテクチャとテクノロジーを選択するための大きな制約となる。

主要な3つのコスト、「総所得コスト (TCO: Total Cost of Ownership)」、「所有の総機会費用 (TOCO: Total Opportunity Cost of Ownership)」、「FinOps」。

TCO: Total Cost of Ownership

TCOは、利用するプロダクトやサービスの直接的、間接的なコストを含む、プロジェクト全体の総見積もりコスト。

直接費 (直接コスト) : プロジェクトに帰属するコスト。プロジェクトに従事するチームの人件費、AWXの請求書等。

間接費 (間接コスト): プロジェクトに関係なく払う必要があるコスト。オフィス管理費、経理、広報など。

直接費、間接費は別に、費用の計上方法の分類があり、大きく「資本的支出」と「運用維持費」に大別される。

資本的支出 (Capital Expense, CAPEX): 長期的な成長や拡張に関連する投資にかかる費用。

運用維持費 (Operational Expense, OPEX): 日常的な運用や事業継続にかかる費用。

以前はデータプラットフォームサービスのために多額のCAPEXが必要だったが、クラウドの登場により、OPEXで支払うことができるようになった。

クラウドと柔軟な従量課金制のテクノロジーを中心としたOPEXファーストのアプローチを取ることを勧める

TOCO: Total Opportunity Cost of Ownership

TOCOは、テクノロジーやアーキテクチャを選択する際に発生する機会損失のコスト。

97 Things Every Data Engineer Should Know [Book] で説明されている。

データスタックAの選択によって他の選ばれなかったデータスタックと比較して得られるメリット、このデータスタックAをサポートするチーム、トレーニング、メンテナンス、将来的な移行のコストなど。

機会費用を最小化するために、選択の際にしっかり評価することが大事。

FinOps

FinOpsの目標は、システムを監視し、動的に調整するというDevOpsのようなプラクティスを適用することで、財務的な説明責任とビジネス価値を完全に運用することだ。

4.5 Today Versus the Future: Immutable Versus Transitory Technologies

現在の具体的なニーズを大事にするか、急激に進化する未来に焦点を当てるか。答えは、現在に集中しよう。そして、将来起きる予期せぬ出来事や進化に対応できるものを選ぼう。そのために必要なことは、何が変わり、何が変わらないかを理解すること。

不変なテクノロジーと一過性のテクノロジーがある。

不変なテクノロジーは、クラウドを支えるコンポーネントや、これまで試練に耐えてきた言語やパラダイム。例えば、オブジェクトストレージ、ネットワーク、サーバ、セキュリティ、リレーショナル・データベース、C言語など。長く使われてきたテクノロジーは今後も長く使われる (リンディ効果)。

一過性のテクノロジーは、例えば JavaScriptのフロントエンドなど。

Our Advice

2年ごとにツールを評価する。

できる限り、データエンジニアリングライフサイクルに沿う不変なテクノロジーを見つけ、それをベースに周辺に一過性のツールを構築する。

4.6 Location

オンプレミス、クラウド、ハイブリッドクラウド、マルチクラウド。

オンプレミスのシステムを担当するデータエンジニアは、ピーク負荷や大規模ジョブに対しても十分な性能を持つ規模のシステムを、買いすぎずお金をかけ過ぎずに購入しなければならない。

クラウドでは、リソースの動的な拡張が可能になる。

オンプレからクラウドの移行を一度に完了させることは不可能であり、ハイブリッドクラウドが使われることがある。他の理由としては、一部クラウドに移すことでメリットが得られる特定のワークロードのみを移行することもある。

マルチクラウドは、クライアントのクラウドワークロードに合わせて複数のパブリッククラウドを使うこともある。あとは、クラウドプロバイダの特定のサービスを使いたいなど。

「クラウドオブクラウド」は、クラウド間でサービスを提供しクラウド間でデータをシームレスにレプリケートしたり、複数のクラウド上のワークロードを一家亞書で管理したりとマルチクラウドを使いやすくするサービス。現在急速に進化している。

Our Advice

「4.5 Today Versus the Future: Immutable Versus Transitory Technologies」の通り、シンプルさと柔軟性に重点を置きながら現在のビジネスニーズに合わせて選択する。

説得力のある理由がない限りはシングルクラウドを選ぶ。

ロックインから脱出できるように、世界の現状を評価して代替案を考えておく。

4.7 Build Versus Buy

構築か購入か。ビジネスに競争上の優位がもたらされるなら構築、そうでないならすでに市場にあるものを入手して利用したほうがいい。

オープンソースと、プロプライエタリ (proprietary: 独自の、非公開の)

コミュニティが管理するOSSプロジェクトで考慮すべき要素

商用OSSは、ベンダがOSSのコアを無償で提供し、拡張機能やフルマネージドサービスに課金。DatabricksのSpark、ConfluentのKafka、DBT Labsのdbtなど。

企業はOSSとしてリリースはせずクローズドソースのプロダクトを販売するプロプライエタリなソリューションを提供することもある。

Our Advice

一般にOSSと商用OSSを用いる。

何かを構築することで大きな付加価値が得られるか、あるいは摩擦が大幅に減るような、少数の分野においてだけ構築を行う。

4.8 Monolith Versus Modular

モノリスは、全てが一箇所に集められていてシンプル。単一のエンティティなので理解しやすい、構成要素が少ないので対応が容易。一つのバグがシステム全体に影響を与える。マルチテナントに向かない。乗り換えが困難。

モジュールは、システムをモジュールとして分離し、個々のモジュールに最善のテクノロジーを使うことができる。理解しなければならないことが増える。

分散モノリスは、モノリシックアーキテクチャの制限を多く受けている分散アーキテクチャ。個々のサービスで個々のタスクが実行されているが、これらは同じ依存ライブラリと同じコードベースを利用している。ユーザの全てのジョブを実行するために、あるユーザのためのライブラリをクラスタ全体にインストールする必要がある。

Our Advice

モノリスは理解しやすくシンプルだが、柔軟性の潜在的損失、機会費用、摩擦の大きい開発サイクルである。

モノリスとモジュールを評価する際には、相互運用性、目先の容易さではなく長期的に問題にならないかを考える、柔軟性と可逆な決定、を検討する。

4.9 Serverless Versus Servers

サーバレスかサーバか。

サーバレスはコストと利便性で人気。監視と課金モデルが重要。

サーバが支持される理由は、カスタマイズ、計算性能など。

Our Advice

サーバレスが適しているかの検討事項

まずはサーバレスの利用を検討し、うまくいかなければサーバを使う。サーバを使う場合はできるかぎりコンテナやオーケストレーション (Kubernetes) を使う。

4.10 Optimization, Performance, and the Benchmark Wars

データ領域において無意味なベンチマークが多い。無意味なコスト比較、非対称な最適化。

購入者はベンダのベンチマークに頼って盲目的にテクノロジーを評価せず、自分で調べよう。

4.11 Undercurrents and Their Impacts on Choosing Technologies

Data Managementについて、プロダクトを評価する際にデータ管理プラクティスについてコミュニティに質問しよう。

DataOpsについて、新しいコードのデプロイをどの程度制御できるか、問題が発生したときのどのようにアラートを出すのか、問題が発生したときにどのように対応するのか、などを確認しよう。

Data Architectureについて、最適なツールは常に変わり続ける。不必要なロックインは避け、データスタック全体の相互運用性を確保し、高いROIを生み出すことが重要。

ソフトウェアエンジニアリングについて、データスタック全体の簡素化と抽象化に務めるべき。カスタムコーディングやツールのためのリソースは、競争上優位を得られる分野に集中させよう。