3. Designing Good Data Architecture
3.1 What Is Data Architecture?
エンタープライズアーキテクチャは、「企業内での変化」に対応しうるシステム設計であり、柔軟性とトレードオフのバランスを取る。
データアーキテクチャは、企業の進化するデータへの要求をサポートするシステムの設計であり、柔軟性とトレードオフのバランスを取る。
データアーキテクチャは、「オペレーショナルアーキテクチャ」と「テクニカルアーキテクチャ」に分けられる。
「オペレーショナルアーキテクチャ」は、人やプロセスやテクノロジに対して 何を しなければならないかの機能要件。
「テクニカルアーキテクチャ」は、データがデータエンジニアライフサイクルに沿って どのように データが取り込まれ、保存され、変換され提供されるか。
3.2 Principles of Good Data Architecture
データエンジニアリングアーキテクチャの原則
- 共通コンポーネントを賢く選択する
- 障害に備える
- スケーラビリティ設計
- アーキテクチャはリーダーシップだ
- 常に設計し続ける
- 疎結合システムを構築する
- 可逆な決定をする
- セキュリティを優先する
- FinOps を活用する
Principle 1: Choose Common Components Wisely
組織全体で広く使われる共通コンポーネントとプラクティスを選択する。
オブジェクトストレージ、バージョン管理システム、可観測性、監視、オーケストレーションシステム、処理エンジンなど。
理想はクラウドプラットフォーム。
Principle 2: Plan for Failure
障害を想定した設計において、可用性、信頼性、目標復旧時間 (RTO: Recovery Time Objective)、目標復旧時点 (RPO: Recovery Point Objective) を考慮する必要がある。
Principle 3: Architect for Scalability
エラスティックなシステムは、理想的には自動的に負荷に応じて動的にスケールアップ・ダウンすることができる。
不適切なスケーリング戦略は、システムの複雑化や高コストを招く。
Principle 4: Architecture Is Leadership
優れたデータアーキテクトは、高い技術力と強力なリーダーシップを兼ね備えている。
エンジニアのベストプラクティスのトレーニングを行い、会社のエンジニアリング資源をまとめて、テクノロジとビジネスの両面で共通の目標を追求する。
Principle 5: Always Be Architecting
アーキテクトの仕事は、ベースラインアーキテクチャ (現在の状態) についての深い知見を持ち、ターゲットアーキテクチャを開発し、アーキテクチャ変更の優先順位付けプランを考えること。
ビジネスやテクノロジによって時間とともに変化するターゲットアーキテクチャと、直近で提供するシーケンスプランを管理する。
Principle 6: Build Loosely Coupled Systems
ベゾスAPI指令 (Bezos API Mandate) https://nordicapis.com/the-bezos-api-mandate-amazons-manifesto-for-externalization/
疎結合にすると、各チームが他のチームに依存せずにテスト、デプロイ、変更を行うことができれば、他のチームとほとんどコミュニケーションをせずに仕事を完了できる。
Principle 7: Make Reversible Decisions
可逆な決定をしよう。変化に合わせて柔軟にもとに戻せる双方向ドアを目指す。
Principle 8: Prioritize Security
ゼロトラストセキュリティ: 信頼されるものを内部に、信頼されないものを外部に配置したセキュリティ境界を設けるのではなく、信頼を何に対しても与えない対策
責任共有モデル: セキュリティをクラウドのセキュリティとクラウド内のセキュリティに分ける。AWSはクラウドのセキュリティに責任を持ち、AWSユーザはクラウド内部のセキュリティに責任を持つ。
Principle 9: Embrace FinOps
FinOpsでは、エンジニアはクラウドシステムのコスト構造について考えることを学ばなければならない。
支出急増のアラート、DDoS攻撃などのアクセスの遮断。クラウドの高額請求に遭遇する前に早めにFinOpsについて学ぼう。
3.3 Major Architecture Concepts
Domains and Services
ドメインとサービス。
ドメイン: 設計対象となる現実世界の領域。
サービス: あるタスクを達成することを目的とした一連の機能。
ドメインには複数のサービスが含まれる。
Distributed Systems, Scalability, and Designing for Failure
分散システム、スケーラビリティ、障害に備えた設計。
「原則2: 障害を想定する」、「原則3: スケーラビリティを考慮して設計する」と関連する4つの特性、スケーラビリティ、伸縮性 (Elasticity)、可用性、信頼性。
Tight Versus Loose Coupling: Tiers, Monoliths, and Microservices
密結合と疎結合: ティア、モノリス、マイクロサービス。
様々なドメイン、サービス、資源にどれだけの相互依存性をもたせるかを選択する必要がある。
アーキテクチャのティアを意識すべき。データティア、アプリケーションロジックティア、プレゼンテーションティアの3ティアアーキテクチャにするなど、単ティア (DBとアプリケーションが単一サーバに存在) ではなく 多ティアアーキテクチャにする。個々のノードがリクエストを個別に処理し、他ノードとメモリやディスクなどのリソースを共有しない、シェアードナッシングアーキテクチャを検討する。
モノリスから始めるのも悪くはないが、この密結合はいずれ大きな泥団子になる。
可能なk質、モジュール化と疎結合を可能にする可逆なテクノロジー選択を行おう。
User Access: Single Versus Multitenant
ユーザアクセス: シングルテナントとマルチテナント。
マルチテナントでは、性能とセキュリティを考慮しなければならない。
クラウドシステム内に複数の大規模なテナントがある場合、すべてのテナントに対して一貫した性能を提供できるか、セキュリティ的に隔離されているか。
Event-Driven Architecture
イベント駆動アーキテクチャ。
イベント駆動のワークフローを受け付けて、様々なサービス感で通信してワークフローを実現する。イベントの状態を複数のサービスに分散できるメリットが有る。
Brownfield Versus Greenfield Projects
ブラウンフィールドプロジェクトとグリーンフィールドプロジェクト。
ブラウンフィールドプロジェクト: 既存のアーキテクチャを再設計する。レガシーアーキテクチャとさまざまな新旧テクノロジーの関係を理解する必要がある。直接書き換える方法、段階的に置き換える方法 (ストラングラーパターン) がある。
グリーンフィールドプロジェクト: 新しく一からアーキテクチャを考える。こっちのほうがエキサイティングであり、新しい技術に手を伸ばしがちだが、要件を常に優先しよう。
3.4 Examples and Types of Data Architecture
現在よく使われているデータアーキテクチャの例とその種類について。
- データウェアハウス
- データレイク
- データレイクハウス
- モダンデータスタック
- Lambdaアーキテクチャ
- Kappaアーキテクチャ
- Dataflowモデル。バッチとストリームの統合
- IoTのためのアーキテクチャ
- データメッシュ
その他のデータアーキテクチャ
- データファブリック: 組織の分散されたデータ環境(オンプレミスのデータセンター、パブリッククラウドなど)のデータアクセスを管理するアーキテクチャ。
- データハブ: 組織内でデータを保存、管理、共有するためのセントラライズされたリポジトリ
- スケールドアーキテクチャ: “Data Management at Scale” で紹介されているアーキテクチャ。大量のデータと高速のデータ取り込み、処理、分析ができるデータ管理システムのアーキテクチャ。リソース追加やワークロードの分散で水平にスケールできる。
- メタデータファーストアーキテクチャ: メタデータを優先するデータ管理。組織はデータの見つけやすさやリネージ、ガバナンスを改善し、多くの種類のデータ管理や分析が簡単になる。
- イベント駆動アーキテクチャ: イベントによってデータや処理のフローがトリガーされるアーキテクチャーパターン。
- ライブデータスタック: モダンデータスタックを後継のストリーミングテクノロジーを実現する。アプリケーションソースシステムからデータ処理、そしてMLまで、データのライフサイクル全体をカバーし、ストリーミングテクノロジーでリアルタイム分析とMLをアプリケーションに融合させる。
新しいアーキテクチャに常に注意を払い、組織にどのように役立つか考えておこう。
3.5 Who’s Involved with Designing a Data Architecture?
データアーキテクチャはデータエンジニアリングサイクルの根幹なので、データエンジニアは「優れた」アーキテクチャと様々なタイプのデータアーキテクチャを理解して置かなければならない。
データアーキテクチャを設計する際には、ビジネス利害関係者とともにトレードオフを評価することになる。