Fundamentals of Data Engineering | 4 | Choosing Technologies Across the Data Enginieering Lifecycleの要約

Fundamentals of Data Engineeringの第四章の要約です

冒頭
Team Size Capabilities
Speed to Market
Interoperability(相互運用性)
Cost Optimization and Business Value(実施済み)
Today Versus the Future(実施済み)
Location
Build Versus Buy
Monolith Versus Modular
Serverless Versus Servers
Optimization, Performance, and the Benchmark wars
Undercurrents and Their Impacts on Choosing Technologies(実施済み)

冒頭

最新技術を追い求めることは簡単
- しかし、データエンジニアリングの基本的な目的は、データのライフサイクル全体を通じて信頼性の高いシステムを設計し、エンドユーザーのニーズに応えること

アーキテクチャは戦略的に、ツールは戦術的に
- アーキテクチャは高レベルなデザイン、ロードマップ、データシステムの設計図であり、ツールはそれを実現する手段
- 技術をアーキテクチャの前に優先すると、効果的なシステムが構築されないことが多い
- この第四章では「戦略的なアーキテクチャをまず確立し、その後技術を選ぶというアプローチ」を強調している

Team Size Capabilities

チームの規模と技術能力を確認すること
- 小規模なチームが大手技術企業のブログを読み、最先端技術を真似する
  –> 多くのコストをかけて、ほとんど成果を上げれない
- 小規模なチームや技術力の弱いチームはツールやSaaSツールを利用して労力を節約し、一方でビジネスに直接価値をもたらす複雑な問題に注力するのが良い
- チームのスキル
  - チームが慣れている技術に固執することをお勧めする
    – ローコードツール or ノーコードツール
    – 言語(Java, Python, Go …)
  - 新しい技術、言語、ツールを学ぶことはそれなりの時間投資となるため、慎重に行う

Speed to Market

迅速、確実、安全、確実に作業を進められるツールを選びましょう
テクノロジーは、市場投入のスピードが勝負
早く、頻繁に価値を提供することに注力すること
チームメンバーは、すでに知っているツールを使った方が、より良い活用ができるだろう
データチームの中には、何ヶ月も何年もテクノロジーの選択について熟考し、何一つ決定に至らないところもある

Interoperability(相互運用性)

技術やシステムを選ぶ際には、それが他の技術と連携し、動作することを確実にする必要がある
相互運用性とは、さまざまな技術やシステムがどのように接続し、情報を交換し、相互に作用するかを指す
意識するポイント
– データエンジニアリングのライフサイクル全体で、さまざまな技術をどれだけ簡単に接続できるか
– モジュール性を考慮して設計し、新しいプラクティスや代替手段が利用可能になったときに技術を簡単に入れ替えることができるようにすること

Cost Optimization and Business Value(実施済み)

鈴木さんの回で実施済み

Fundamentals of Data Engineering (English Edition) 輪読会資料第7回分 2023/5/29開催

著者としては、データエンジニアがクラウド上で、opex-first　なアプローチ　を中心に据えることを、強くおすすめする
TOCO は「わたしたちがなにかを選んだ時に受ける、機会喪失のコスト」
- 新しい技術・製品がどんどん出てくる中で、素早く、お金を安く、よりよい選択肢に移れるようにできると良い
FinOps がお金を節約するためだとおもったなら、考え直してほしい。FinOpsはお金を作り出すためのもの

Today Versus the Future(実施済み)

久保さんの回で実施済み

Fundamentals of Data Engineering 輪読会資料第8回分 20230605開催

変わらないものについて
- クラウドの土台になるような技術(オブジェクトストレージ, ネットワーク, サーバー, セキュリティ)
- 言語(SQL, bash)
- その技術が長く続いているほど、その技術は使われる(リンディ効果)
変わりゆく技術
- Javascriptのフロントエンドが古典的な例
変わりゆく技術は変わらない技術の周辺におきましょう

Location

技術スタックの実行場所を選ぶ際に多くの選択肢がある
- 現在多くの企業はクラウドに移行している
- 主な場所はオンプレミス、クラウド、ハイブリッドクラウド、マルチクラウド

オンプレミス
自社所有のハードウェアを使用し、故障時の修理や更新を自社で管理
クラウド
オンプレミスのモデルとは対照的
エンジニアは迅速にプロジェクトを立ち上げ、必要なときにリソースを動的にスケールできる
現在はPaaS（プラットフォーム・アズ・ア・サービス）やSaaS（ソフトウェア・アズ・ア・サービス）が成長している
ハイブリッドクラウドとマルチクラウド
クラウドとオンプレミスを組み合わせたハイブリッドクラウドや、複数のクラウドプロバイダーを使用するマルチクラウドを利用することができます。これにより、スケーラビリティや柔軟性を高めることができる
サーバーレス
自動スケーリングが可能で、利用した分だけ課金されます。サーバーレスは基盤となるサーバーの運用を意識することなくエンジニアが操作できるため、多くの企業にとって魅力的
クラウド技術の選定には慎重な検討が必要であり、適切な価格モデルに適応することが重要です

クラウド経済学の概略
- クラウドサービスを効率的に利用するためには、クラウドの収益構造を理解する必要がある
- 例) GCPのアーカイブストレージは標準のクラウドストレージと同じクラスターで動作しますが、料金は大幅に安く設定され、IOPSは高価に設定することで、読み取りを抑制している

クラウドとオンプレミスの違い
- クラウドサービスをオンプレミスサーバーは異なる価格モデルを持っているため、同様に考えるのは誤り
- クラウドの価値を最大限に引き出すためには、自動スケーリングを活用して、負荷が軽い時にはインフラを最小限にし、ピーク時には大規模なクラスターにスケールアップする必要があります。また、予約インスタンスやスポットインスタンスを利用して、より一時的で耐久性の低いワークロードに割引を適用することも重要

データグラビティ
- クラウドにデータを移行することは安価
- しかしデータを取り出す際の費用は非常に高くなる

Multicloud
- マルチクラウドを採用すると複数のクラウドの最良のサービスを利用することが可能
  デメリット
  – データのエグレスコスト
  – ネットワークのボトルネック
  – マルチクラウドの運用は複雑
- これらのデメリットを解決するための「クラウド・オブ・クラウズ」
  例)
  – 複数のクラウド間でのデータのシームレスなレプリケーション
  – 一つの管理画面で複数のクラウドのワークロードを管理することを可能にする
  – Snowflakeのアカウントは単一のクラウドリージョンで動作しますが、GCP、AWS、Azureに他のアカウントを簡単に立ち上げることができる
- 「クラウド・オブ・クラウズ」は急速に進化している

分散型：ブロックチェーンとエッジ
- 次の10年間で人気が出るかもしれない新しいトレンド
  – 分散型コンピューティング
  – 分散型コンピューティングでは、ブロックチェーン、Web 3.0、エッジコンピューティングといった技術を使って、データや計算の処理を分散させます
  (おそらく、データを集中管理する必要がなくなる可能性がある、ということを指している？)
  – 現時点では、分散型プラットフォームは非常に人気がありますが、データ分野においては大きな影響を与えていないが、この分散型のトレンドを注意深く見守りましょう

アドバイス
- ワークロードの配置と移行に関する証拠や議論は変動している
- 複雑なマルチクラウドやハイブリッドクラウド戦略は、必要な理由がない限り避けるべき
- 単一クラウド戦略は単純さと統合の利点がありますが、ロックインのリスクもある
  – 脱出プランを用意しておきましょう

クラウドリパトリエーション(=再移行)の議論
- Sarah WangとMartin Casadoが発表した「The Cost of Cloud, A Trillion Dollar Paradox」は、クラウドワークロードをオンプレミスサーバーに戻すべきだという議論を引き起こした
- Dropboxの事例
  - 大量のデータ: Dropboxは膨大なデータ（エクサバイト規模）を保存しており、そのデータの帯域幅消費も非常に大きい –> データエグレスコストが高い
    - Dropboxはコアプロダクトを自社サーバーに移行

Build Versus Buy

ビルド（自社開発）とバイ（購入）の議論は、技術分野で長年続いている
- ビルドの利点は、解決策を完全にコントロールでき、ベンダーやオープンソースコミュニティに依存しない
- バイの利点はリソースの制約と専門知識にある(使いこなせる知識があるか)
競争優位を提供する場合にのみビルドやカスタマイズに投資し、それ以外の場合は市場に既存のものを利用すること
3つの判断基準
- 総所有コスト（TCO）
- 総機会コスト（TOCO）
- その解決策が組織に競争優位をもたらすか

オープンソースソフトウェア（OSS）
- OSSの2つの主要な形態
  - コミュニティ管理型
  - 商用OSS

コミュニティ管理型OSSの評価基準
- 認知度: Githubのスター数、フォーク数、コミット量など
- 成熟度：プロジェクトがどれくらい長く続いているか、現在の活動状況
- トラブルシューティング：問題が発生したときにどのように対応するか、コミュニティが問題解決を支援してくれるか
- プロジェクト管理：Gitの問題の対応方法とその速さ
- チーム：プロジェクトをスポンサーする企業があるか
- 開発者関係とコミュニティ管理：プロジェクトが採用を促進するために何をしているか、活発なチャットコミュニティがあるか
- 貢献：プロジェクトがプルリクエストを受け入れるか
- ロードマップ：プロジェクトに明確で透明なロードマップがあるか
- 自己ホスティングとメンテナンス：OSSソリューションをホスティングしメンテナンスするリソースがあるか

商業用OSS
- OSSには、環境内でのホスティングとメンテナンスが必要であるなどの欠点があります。この管理上の問題を解決するために、商業ベンダーはクラウドのSaaSとしてOSSソリューションをホスティングおよび管理します。これが商業用OSS（COSS）と呼ばれるモデル
商業用OSSの評価基準
- 価値：ベンダーが提供する価値が、自分でOSS技術を管理するよりも優れているか
- 提供モデル：サービスへのアクセス方法。ダウンロード、API、ウェブ/モバイルUIなどの形式で提供されているか
- サポート：サポートのモデルとその費用
- リリースとバグ修正：リリーススケジュールや改善、バグ修正が透明か
- 販売サイクルと価格設定：オンデマンド価格と長期契約の割引のトレードオフ(前払いする価値があるか)
- 企業の財務状況：企業の存続可能性を確認
- ロゴ対収益：顧客数の拡大に注力しているか、収益の成長に注力しているか
- コミュニティサポート：企業がOSSプロジェクトのコミュニティバージョンをどの程度支援しているか

プロプライエタリ(専門的、独占的)な閉鎖環境
- OSS（オープンソースソフトウェア）が広く使われている一方で、クローズドソースのプロプライエタリな技術も大きな市場がある
  - 一般的にその製品やサービスを提供する企業によって開発され、使用に際してライセンスの購入が必要
    (例えば、Microsoft Office Suite(エクセルなど)、Oracle Database、Salesforce)
- 評価基準
  - 相互運用性: 他のツールと連携できるか。
  - マインドシェアとマーケットシェア: そのソリューションの人気や市場での地位。
  - ドキュメントとサポート: 問題が発生した際に適切なサポートが得られるか。
  - 価格設定: 価格がわかりやすく、使用に応じたコストが理解できるか。
  - 持続性: 企業が長期的にサポートを提供するかどうか

クラウドプラットフォームのプロプライエタリサービスオファリング
- クラウドベンダーは、ストレージやデータベースなどのプロプライエタリサービスを開発・販売しています
- 例えば、AmazonはDynamoDBを内部ツールとして開発し、その後AWSで提供している
- 評価基準
  - パフォーマンス対価格の比較：クラウドオファリングが独立系やOSSバージョンと比べて優れているかどうか
  - 購入考慮事項：オンデマンド価格が高価である場合、予約容量の購入や長期契約でコストを削減できるかどうか

アドバイス
- コスト削減のため、一般的にはOSSおよびCOSSをデフォルトで推奨します
- その上で、不足している部分や強化が必要な部分にリソースを集中させるべき
- 既存のデータチームに高度なシステム構築のスキルを身につけさせることは、長期的に見て価値があります。チームのスキルを向上させることに投資するのも一つの選択肢
- 会社の収益構造や販売・顧客体験チームの取り組みを考慮し、予算の決定権を持つ人物とその承認プロセスを事前に把握しておきます。技術選択が予算承認待ちで停滞しないように注意し、迅速な承認を得るための準備を行います。

Monolith Versus Modular

モノリスシステム
- 一つのシステムで複数の機能を持ち、すべてが一箇所にまとまっているため、シンプルで理解しやすく、迅速に動けるという利点があります
- モノリスは長年にわたり主流の技術
- 一つの技術やプログラミング言語で全体を理解しやすく、認知負荷が低いこと
- デメリット
  - モノリスは一度に多くの機能を更新する必要があるため、システム全体が壊れやすく、バグが発生するとシステム全体に影響を及ぼす可能性がある
  - 複数のユーザーが同時に使用する場合、リソースの競合が発生しやすい
  - システムの切り替えが難しく、移行が高コストとなる可能性がある

モジュラーシステム
- 「モジュラリティ(モジュール化)」はソフトウェア工学で古くからある概念ですが、特にマイクロサービスの普及とともに注目されている
- システムやプロセスを独立したコンポーネントに分割し、APIを介して通信することで、各コンポーネントが自分の領域に集中できる
- 異なる技術を組み合わせて最適な結果を出すことを目指し、特にデータ分野では変化に対応しやすいという利点があります
- 技術の進化に伴いツールを簡単に交換できる
- デメリットとしては、扱うシステムが増えるため理解や運用が複雑になる点
  - モジュール化されたシステムを調整するオーケストレーションが重要な役割を果たす

ディストリビューションモノリス
- 分散型アーキテクチャでありながら、モノリシックアーキテクチャの多くの制約を抱えたもの
- 異なるタスクを実行するための異なるサービスが分散システム上で動作する
- 例) Hadoopクラスターは同時に複数のフレームワーク（Hive、Pig、Sparkなど）をホストし、共通の依存関係を持つことがある
  –> アップグレードやインストールの管理が大きな課題となる
  –> 解決策は各ジョブが専用のサーバーやクラスター(またはコンテナ)を一時的に使用し、依存関係の競合を大幅に減らすこと

アドバイス
- モノリスとモジュラーオプションを評価する際に考慮すべき点
  - 相互運用性：システム間の共有と相互運用性を考慮して設計しましょう。
  - 「ベアトラップ」を避ける：簡単に入れるが、抜け出すのが困難または不可能な状況を避けるべきです。
  - 柔軟性：現在、データの分野では急速な変化が進んでいます。モノリスにコミットすると、柔軟性や後戻りできる選択肢が減少します。

Serverless Versus Servers

サーバーレス
- AWS Lambdaが火付け役
  　サーバーを管理せずにコードを必要なときに実行できる利便性とコストの低さが人気
- サーバーレスが適しているかどうかは、使用ケースによって判断する
  バッチ処理を低コストで実行可能だが、一方で高頻度のイベント処理ではコストが高くなる
コンテナ
- コンテナは軽量な仮想マシンで、Kubernetesのようなコンテナ管理システムは、開発者や運用チームがマイクロサービスをマシンの詳細を気にせずデプロイできる環境を提供できる
- コンテナエスケープのリスクがあるため注意が必要
  - コンテナエスケープ: コンテナ内で実行されているアプリケーションやプロセスが、コンテナの隔離された環境からホストシステムや他のコンテナにアクセスする、または影響を与えるセキュリティ上の脆弱性
サーバーレスとサーバーのどちらを選ぶかは、ユースケースとコストモデルを詳細に理解することが重要

サーバー vs. サーバーレスの評価方法
- サーバーを選ぶ理由
  - コストが大きな要因で、使用量とコストがサーバーの運用と保守の継続コストを超える場合、サーバーレスの利点が減少
  - カスタマイズが過度なサーバーは脆弱性を持つため、必要に応じて作成・削除できる一時的なリソースと見なす
  - インフラをコードとして扱う: 自動化はサーバーだけでなく、インフラ全体に適用すべき
  - コンテナの使用: 複雑な依存関係がある高度なワークロードには、単一サーバーまたはKubernetes上でコンテナを使用する

サーバーレスの適用に関するアドバイス
- シンプルで個別のタスクやワークロードに最適
- 複雑な計算やメモリが必要な場合は、コンテナとKubernetesのようなオーケストレーションフレームワークを検討する
- 実行頻度と持続時間: サーバーレスプラットフォームには実行頻度、同時実行数、持続時間の制限があるため、それに適合しない場合はコンテナの使用を検討する
- 使用言語
- ランタイム制限
- コスト: サーバーレスは便利だが、イベント数が増えるとコストが急増する可能性がある
まずサーバーレスの使用を検討し、サーバーレスのオプションを超えた場合にサーバーとコンテナおよびオーケストレーションを使用することを推奨します

Optimization, Performance, and the Benchmark wars

最適化、パフォーマンス、ベンチマーク戦争
データベースのパフォーマンス比較は非常に難しいため、ベンチマーク結果を盲信せず、実際の使用ケースやニーズに基づいて評価することが重要

データベース分野でも不適切な比較が頻繁に行われている
- 異なる使用ケースの比較
  - 例) 大規模データ処理に優れている一方、別のデータベースはリアルタイムクエリ処理に特化している
- 現実離れしたテストシナリオ
- 多くのベンチマークテストは、実際の使用状況とはかけ離れたシナリオを基にしているため、実際のパフォーマンスを正確に反映しない結果が得られることがある
最近のベンチマーク戦争
- 主要データベースベンダー間で自社製品の優位性を示すためにベンチマーク結果を競い合う