本記事の位置付け

こちらの勉強会　英語で技術書を読もう：Fundamentals of Data Engineering 第1回　に参加し、その際に発表したもの。

なお、なぜ第１回で「Chapter3 Good Data Architecture」の、
しかもその途中の「Principles of Good Data Architecture」から入っているかというと、
参加者からの要望が多かった箇所だから。
（本の情報量が多いので、おそらく全内容を輪読できない想定から、興味のある箇所を選んで輪読予定。）

Principles of Good Data Architecture / 良いデータアーキテクチャの原則

主なアーキテクチャ決定と実践を評価するのに役立つ原則に寄り添うことで、遥かな高みからの視座を得る。
複数の情報源、特にAWSの「AWS Well-Architected Framework」と、Google Cloudの「Five Principles for Cloud-Native Architecture」から洞察を借りる。

AWS : Well-Architected Framework

6つの柱から構成される
- 卓越した運用（Operational Excellence）
- 安全保障(Security)
- 信頼性(Reliability)
- パフォーマンス効率(Performance efficiency)
- コスト最適化(Cost optimization)
- 持続可能性(Sustainability)

Google Cloud : Five Principles for Cloud-Native Architecture

5つの柱から構成される
- 自動化の設計(Design for automation)
- 状態で賢い？（Be Smart with state）
- 望ましいマネージド・サービス(Favor managed services)
- 多層防御の実践(Practice defence in depth)
- 常に設計せよ(Always be architecting)

Principles of Good Data Architecture

両方を注意深く研究し、価値ある考えを特定し、同意できない点を決めよ
我々はこれらを拡張し以下9つのデータエンジニアリングアーキテクチャの原則に拡大・精緻化する。
- Principle 1 Choose Common Components Wisely / 共通要素を賢く選べ
- Principle 2 Plan for Failure / 失敗を計画せよ
- Principle 3 Architect for Scalability / 拡張の為のアーキテクト
- Principle 4 Architecrture Is Leadership / アーキテクチャがリーダーシップ
- Principle 5 Always Be Architecting / 常に設計せよ
- Principle 6 Build Loosely Coupled Systems / 疎結合なシステムを構築せよ
- Principle 7 Make Reversible Decisions / 裏返せる決断をせよ
- Principle 8 Prioritize Security / セキュリティに優先順位をつけよ
- Principle 9 Embrace FinOps / FinOps（クラウドのコスト最適化）を導入せよ

Principle 1 Choose Common Components Wisely / 共通要素を賢く選べ

データエンジニアの大事な仕事の一つ　：　組織全体で使える共通要素と実践を選び取ること
アーキテクトが上手に選んで効果的にリードすることで、共通要素は
- チームの共創を容易にし、タコツボ化を壊す下地になる
- 共有された知識や技術と共に組織内外の速度を向上させる

共通要素(Common Components)

組織内に広く適用可能な何らかのもの
- 以下のものを含む
  - オブジェクトストレージ（S3とかICOSとか）
  - バージョン管理システム（VCSとかGitとかGithubとか）
  - 可観測性（DatabandとかDynatraceとかSplunkとかNew Relicとか）
  - 監視とOrchestration（敢えて訳すとなると、編曲、または調整？）
  - 処理エンジン（これが何を指すのかは不明）
- 適切な使い方とともに万人が使えるものであるべき
- 組織は車輪の再発明をすることなくありものの共通要素に頼ったほうがいい
- 不適切なアクセスを防ぐために
  - 堅牢な権限
  - セキュリティ（認証や認可？）設定

クラウドプラットフォーム

共通要素を適用するには最適な場所
- 例：
  - クラウドデータシステムにおいて、以下は分離されている。
    - 計算（Compute）
    - 蓄積（Storage）
  - そのことによってユーザは共有されたストレージにアクセスし、特定の用途の為にデータを問い合わせる（Query）事ができる
  - （Snowflakeなんかは典型的ですね）

共通要素を選ぶことはバランスが大事。

一方では、
- データエンジニアリングライフサイクルや組織全体で、
  - 共通要素を個別のプロジェクトに役立てたり、
  - 同時にシステム間の運用性や協力が簡単になる。
他方では、
- アーキテクトは共通技術を押し付けることでエンジニアが専門的な課題を解決することを邪魔するな。
  - （久保の解釈：特定の課題を解くには特定の別な技術が必要）
詳細はチャプター４で説明される。

Principle 2 Plan for Failure / 失敗を計画せよ

全ては故障する（fails）。常にだ。（ワーナー・ヴォーゲルズ　AWS CTO）
- 諸行無常
現代のハードウェアがどれほど堅牢で頑丈であろうとも、必ず故障する。いつかは（given enough time）。
堅牢なデータシステムを構築するには、設計の中に故障のことも組み込む必要がある。
故障のシナリオを考えるにあたって以下キーワードを挙げる

Availability （可用性）

ITのサービスや要素が操作可能な状態である時間の割合

Reliability （信頼性）

システムが特定の時間内において意図された機能を実現する期待値を満たせる可能性

Recovery Time Objective （RTO：目標復旧時間）

サービスやシステムが停止していても許容可能な最大限の時間。
一般的にシステム停止がビジネスに与える影響度合いにより決定される。
- 内部のレポートシステムなら1日停止しても問題ないかもしれない。
- Webサイトが5分停止したらオンラインの小売業者に対して大きな悪影響があるかもしれない。

Recovery Point Objective （RPO：目標復旧地点）

復旧後に許容可能な状態。
システム停止ではデータが失われる事がよくある。
RPOはどの程度までデータが失われても大丈夫か、という意味。

計画に失敗を組み込む為のまとめ

エンジニアは設計時に許容可能な可用性、信頼性、RTO、RPOを考慮する必要がある。
故障を予想しつつアーキテクチャを決定する際に役立つ。

Principle 3 Architect for Scalability / 拡張の為のアーキテクト

データシステムの拡張性には以下2つを含む
- 1.スケーラブルなシステムは大量のデータを扱う為にスケールアップ（でかくする）できる
  - ペタバイト級の顧客データでモデルを訓練するために巨大なクラスターを起動する
  - 負荷の急増に対応するためにストリーミング取り込みシステムをスケールアウト（頭数を増やす）させる
  - スケールアップの能力は一時的な負荷増大に対応できる
- 2.スケーラブルなシステムは大量のデータを扱う為にスケールダウンできる
  - 急激な負荷が終われば、コスト削減の為に計算資源を削減すべき（原則9に関係）
- 拡大縮小できるシステムは、理想的な形としては自動的に、負荷に対応できる
ゼロサイズにまでスケールダウンできるシステムもある。
- 使われない場合はシステム停止
- 大きなモデルのトレーニング用ジョブが終わればクラスターを削除できる
- サーバレスのシステムは自動的にゼロにまでスケールダウンできる
  - サーバレス関数、サーバレスオンライン分析、またはOLAPデータベースなど
不適切なスケーリング戦略を取ることは複雑なシステム、高いコストにつながる
- アプリケーション用には、一つのファイルオーバー用ノードを備えた単純なRDBのほうが、複雑なクラスタを組むよりよいかもしれない。
現状の、または今後数年の負荷の最大を予測し、今のDBのアーキテクチャが適切か評価しましょう。
あなたがスタートアップに勤めていて成長しているなら、この成長は拡張により再構築する為のリソースを必要とする(?)

Principle 4 Architecrture Is Leadership / アーキテクチャがリーダーシップ

データアーキテクトは、
- 以下の事項に責任を持つ
  - テクノロジーの決定
  - アーキテクチャの説明
- リーダーシップとトレーニングで選び取った内容を広めていく
- 高度な技術を備える必要があるが、作業は他の人に委託する
専門性とリーダーシップを兼ね備えた人材は貴重
最高のアーキテクトはこの専門性とリーダシップの二刀流を真剣に考えている
リーダーシップとは
- 技術に対する上意下達、指揮統制を意味しない
- 過去には、一つのデータベースを選んだらそれをチームに強制させてデータを全てそこに格納させるような事はよくあった。
  - 現代のデータプロジェクトには邪魔なので、我々はこのような方針には反対している。
- クラウド技術によりアーキテクトは共通要素をバランス良く選択できプロジェクトでイノベーションが可能となるような柔軟さがもたらされる
技術リーダーシップという概念として、Martin Fowler曰く
- 理想的なソフトウェア・アーキテクトの具体的な原型は、彼の同僚デイブ・ライスが体現
  - Architetus Oryzusの最も重要な活動
    - 開発チームの指導
    - より複雑な課題に取り組めるようにレベルを上げること
  - 開発チームの能力を向上させれば、一人きりで意思決定してアーキテクチャ上のボトルネックとなるような危ない橋を渡るよりも利益がある。
理想的なデータアーキテクトは似たような特性を持っている
- データエンジニアリングのスキルをもっているが、そのスキルを実践したりはしない
- 現役のデータエンジニアを指導する
- 組織にたいしてコンサルティングしつつ注意深く技術を選択
- 訓練やリーダーシップによって技術を拡散させる
- エンジニアをベストプラクティスをもって訓練し、組織のエンジニアリング力を束ね、技術面、ビジネス面での目的を追求する
データエンジニアとして、読者はアーキテクチャリーダーシップを発揮し、メンターの指導を仰げ
いずれあなたがアーキテクトの役割を担うかもしれない。

Principle 5 Always Be Architecting / 常に設計せよ

Googleの5つのクラウドネイティブアーキテクチャから借りてきた原則
データアーキテクトは現状維持の為に単純に役割を演じたりしない。
技術やビジネスの変化に応じて常に新しくエキサイティングな事を常に設計している。
EABOKによればアーキテクトの仕事は、
- 現状のアーキテクチャの知識を深める
- 目標とするアーキテクチャを開発する
- アーキテクチャの変更の優先順位と順番を決めて連続的な計画を建てる
現代のアーキテクチャは
- 指揮統制型、またはウォーターフォール型であるべきではない。
- 協創的で高速であるべきだ。
データアーキテクトは目標とするアーキテクチャや、時間をかけ変更計画を整える
目標とするアーキテクチャはビジネスや技術の内部的な、または世界的な変化に応じて動く目標だ
連続する計画が実装の為の優先順位を決める

Principle 6 Build Loosely Coupled Systems / 疎結合なシステムを構築せよ

Google DevOps tech architecture guideより
- システムのアーキテクチャが、チームが他のチームに依存することなくシステムのテスト、配置、変更ができる時、チームは仕事を完了させるのに、より少ないコミュニケーションで済む。
- こういうのをアーキテクチャとチームの疎結合という
2002年、ジェフ・ベゾスは後に「ベゾスのAPI勅令（Bezos API Mandate）」と呼ばれるメールを従業員に出した。
- 1.全チームは今後データと機能をサービスインターフェース経由で開放すること
- 2.全チームは全てこれらのインターフェースで意思疎通せねばならない
- 3.その他の形式のプロセス間通信は認めない
  - （例えば以下）
    - 直接リンク
    - 他チームのデータソースを直接読む
    - メモリ共有モデル
    - バックドア
  - 許可される疎通手段はネットワーク経由のサービスインターフェースコールのみ
- 4.どんな技術を使っても構わない。
  - http
  - Corba
  - Pub/sub
  - 独自プロトコル
  - 何でもいい。
- 5.全てのサービスインターフェースは例外なく外部公開可能なように1から設計する必要がある。
  - つまり全チームは例外なく、全世界の開発者に対してインターフェースを公開できるように計画し設計しなければならない。
実は6と7もあり、この本には記載がなかったので、以下に記載する。（外資系って怖いね）
- 6.これを守らない人は誰であれクビにする。
- 7.それでは良い一日を。

API Mandateは、Amazonにとって重要な転機となった。
- データとサービスをAPIの背後に配置することで疎結合が可能になり、最終的に現在の AWSが誕生した。
Googleは疎結合を追求することで、システムを驚異的な規模に拡張することができた。
ソフトウェアアーキテクチャの場合、疎結合システムには以下の特性がある。
1.　システムは小さい部品に分解される
2.　これらのシステムは抽象化レイヤーを通じて他のサービスと疎通する。
- 例えば
- メッセージングバス
- API
- これらの抽象化レイヤーは、DBとか内部クラスとかメソッドなどの詳細を保護し秘匿する。
3.　2.の結果
- システムの構成部品へ変更があっても他の部品への変更は必要ない。
- コードの更新の詳細は安定したAPIの背後に秘匿される。
- それぞれの部品は独自に進化することができる。
4. 3.の結果
- ウォーターフォールやシステム全体の為の全世界的なリリースのサイクルは最早無くなる。
- その代わりに個別の部品は、変更されたり進化する度に個別に更新される。

参考

APIの例えに焼き鳥の皮（塩）ともも（たれ）の例を書いた人に会いたい。受けた笑。経産省電力データ活用の資料https://t.co/29b9EfFJVw pic.twitter.com/uMtpEfN4i1
— 樋口悟@住宅用/産業用太陽光+蓄電池+EV V2H経済効果試算ツールエネがえる (@satoruhiguchi) March 3, 2020

我々は技術的なシステムについて話している。
もっと大きな話をする必要がある。
技術的な特徴を組織的な特徴に翻訳してみよう。
1. 多くの小さなチームが一つの大きなシステムを設計する。各々のチームは、システムの個別の構成要素の設計・維持・改善を役割としている。
2. これらのチームは、
  - API定義やメッセージングの図式を通じて構成要素の抽象的な詳細を、他チームへ公開する。
  - 他のチームは構成要素を呼び出す為に、公開されたAPIやメッセージを呼び出せばよい。
  - チームは、
    - 自分の担当箇所のパフォーマンスや機能向上を繰り返す。
    - 新機能や他チームから要求のあった機能を付け加えたりする。
      - 後者について、チームは要求された技術の詳細を気にすることがなくなる。
3. 特徴2.の結果、書くチームは他のチームから独立して機能を向上させる事ができる。
4. 特徴3.を具体的にいうと、
  - チームは最小限のダウンタイムで機能更新をリリースできる。
  - 営業時間内にコードを変更しテストするという繰返しの中でリリースされる。

Principle 7 Make Reversible Decisions / 裏返せる決断をせよ

データをめぐる風景は目まぐるしく変わる。
今日の流行り技術は明日には流行遅れ（afterthought、この訳で合っている？）
主張はすぐに変わってしまうから後で覆せる決定をすべきだ。
- そのことでアーキテクチャが簡易になり対応が素早くなる。
フォウラー：アーキテクトの重要な仕事の一つは、ソフトウェア設計の中から不可逆さを消すことでアーキテクチャを取り除くことだ。
- フォウラーが2003年に書いたこの真実は現在でも通用する。
ベゾスは覆せる決定のことを双方向ドアと読んだ。
- ドアをくぐって見たものが気に入らないけど戻れない。これをタイプ１の決定とする。
- しかしほとんどの決定はこれとは異なり、変更可能だ。これは双方向ドアだ。
可能な限り双方向ドアを目指せ。
あなたの組織のデータ構造全体の技術の疎結合化と部品化、そして変化の速さ、今日最善の組み合わせを選ぶよう努力します。
- 主語がどこかわからない。
状況の変化に合わせて更新したり、よりよい実践を受け入れられるように準備せよ。

Principle 8 Prioritize Security / セキュリティに優先順位をつけよ

全てのデータエンジニアは作ったシステムのセキュリティに責任を負わなければならない。
２つの考えに集中する。
1. ゼロトラストセキュリティ
2. セキュリティの責任共有モデル
これらはクラウドネイティブアーキテクチャに深く関わる。

堅牢化された境界線とゼロトラストセキュリティモデル

ゼロトラストセキュリティの理解の前に、堅牢化境界線セキュリティモデル、そしてその限界を理解すると役立つ
- Google Cloud の５つの原則に詳細がある。
従来のアーキテクチャは、以下のようなおおまかな内外の境界を定義していた
- 内部は安全
- 外部は危険
このアプローチは、以下のものに弱い
- 標的型攻撃のような外部の脅威
  - 参考資料：サイバーキルチェーンで読み解く日本史上最大の標的型攻撃
- 内部犯行
  - 参考資料：https://www.benesse.co.jp/customer/bcinfo/01.html
１９９６年の映画ミッションインポッシブル
参考画像
- 境界線モデルとその限界の完璧な事例
  - CIAの重要データは厳しい物理的なセキュリティに覆われた部屋のストレージシステムに格納されている
  - イーサン・ハントはCIAに侵入。内部の人間につけ込んでシステムへの物理的な足がかりを得る
  - 一度部屋に入ってしまうとデータを盗むのは比較的カンタン。
過去１０年、境界線の内部の人間の弱みにつけ込んだセキュリティ事案が増えている。
- 従業員は
  - 堅牢な企業ネットワーク内に接続しているが
  - Emailやモバイルなどで外部とも接続している
- 外部脅威は効果的に内部脅威になりうる。

責任共有モデル

AWSは責任共有モデルを強調する
- セキュリティを以下の通り２分する
  - クラウドとしてのセキュリティ
  - クラウド内部でのセキュリティ
- AWSはクラウドとしてのセキュリティに責任を持つ。
  - AWSのサービスを稼働させるインフラを守る事について責任を持ち、ユーザが安全に使用できるサービスを提供する。
- AWSユーザーはクラウド内部でのセキュリティに責任を持つ。
  - ユーザーの責任は使用するAWSのサービスにより決まる。
  - ユーザーはその他の要因（データの秘匿性、組織の要件、適用される法と規制）にも責任を負う。
一般的に全てのクラウドプロバイダでこの責任共有モデルが採用されている。
クラウドプロバイダは公開された仕様に基づいてサービスを保護している。
アプリとデータの為のセキュリティモデルを設計し、そのモデルを実現するためのクラウドの能力を活用するのはユーザの責任である。

セキュリティエンジニアとしてのデータエンジニア

企業の組織において、指揮統制型のセキュリティモデルは共通的
- そこでセキュリティとネットワークのチームは境界線を守るべくセキュリティを実践している。
クラウドはこの責任をセキュリティの担当でないエンジニアに押し付けるもの
この責任によって、強固なセキュリティ境界線の侵入もあいまって、全てのデータエンジニアは自らをセキュリティエンジニアとみるべきだ。
新しい暗黙の責任をうまく引き受けられないと悲惨な結果になる。
- 多くのデータ漏洩はS3のアクセス制御がPublicになっていた事による。
- データを扱う者は最終的には自らがそれを守る責任を持つ。

参考リンク

Principle 9 Embrace FinOps / FinOps（クラウドのコスト最適化）を導入せよ

FinOps とは
- クラウドの財務管理の原則と文化的実践
- 組織のビジネス価値を最大化させる
- データに基づいた決定の上で、以下チームを助ける。
  - エンジニアリング
  - ビジネス
  - 財務
  - 技術

Cloud FinOps の中でこのような記述がある
- FinOpsという言葉は、
  - 現在勃興しつつある、DevOpsチームと財務チームの共創関係を支持する、職業的な動きで、
    - 結果として、インフラ支出をデータに基づいて管理する事を繰り返す。
      - クラウドの支出（unit economics of cloud）を下げる等
    - 他方で、コスト効率性とクラウド環境の収益性を向上させる

クラウド時代にデータのコスト構造は劇的に進化した。
- オンプレミス時代には、
  - データシステムは数年ごとに設備投資として購入された。（詳細はChapter4）
  - 責任部署は、要求される計算やストレージ性能と見合った予算をバランスを取らなければならない。
    - 過大な予算だと
      - お金を無駄にする。
    - 過小な予算だと
      - 以下を無駄にする。
        
        将来のデータプロジェクト
        
        システムの負荷やデータサイズを調整する人の貴重な時間を無駄にする
      - より早い技術サイクルが必要になるが、それには余計なコストがかかる。

クラウド時代には、ほとんどのデータシステムは従量課金で、拡張も可能だ。
- システムは以下の従量課金体系上で稼働できる。
  - １問い合わせあたり幾ら
  - 処理キャパシティあたり幾ら
  - その他の従量課金方式
- この方式は設備投資方式に比べて遥かにコスト効率が良い。
  - パフォーマンス向上の為に拡張することも可
  - コスト削減で縮小することも可
- しかしそのために支出が動的になる。
- 財務リーダーの新たな課題は予算・優先順位・効率性をやりくりすることだ。

クラウドを使うことは支出と資源のやりくりが必要だ。
- 過去には、データエンジニアはパフォーマンスエンジニアリングの事を考えていた。
  - 一定のリソース上でおこなうデータ処理のパフォーマンスを最大化すること。
  - 将来必要になりそうなリソースを購入しておくこと。
- FinOps では、
  - エンジニアはクラウドのコスト構造を理解しなければならない。
  - 例えば、
    - 分散クラスターを稼働させる場合のAWS Spotインスタンス適切な組み合わせは何だろう。
    - コストやパフォーマンスの効率よく大規模な日次ジョブを稼働する一番良い手法は何だろう。
    - 会社はいつ「１問い合わせあたり幾ら」モデルからキャパシティ確保型に移行すべきだろう。
FinOps は運用監視モデルを支出監視モデルに進化させる。
- FinOpsは以下を監視する。
  - リクエストやCPU使用率の監視
  - 負荷を処理するサーバレス関数の現行コスト
  - アラートを引き起こす負荷の急上昇
- 組織は支払いの急激な上昇した場合に穏やかに停止できる為の支払い上限を定める事もある。
運用チームはコスト攻撃についても考慮すべきだ。
- DDoS攻撃によってサーバへのアクセスが邪魔される
  - DoSが降る夜にあなたに会えた　あの攻撃を忘れはしないという歌詞がありましたね。
- S3バケットからの大量ダウンロードがスタートアップ企業に破産をもたらす（悔しいのう）。
データを一般公開する場合、データチームは以下のように対応できます。
- データ要求側が支払うようにコストをつけかえる
- 過剰なデータアクセスを監視し、受け入れられないレベルに支払いが上昇し始めたらアクセスを除外する
FinOpsは最近できた実践方法。
- FinOps Foundation は２０１９年に創立。
早いうちからFinOpsについて考え始めたほうが良い。
- 高いクラウド料金を支払うハメになる前に。
FinOpsについては以下を参照。
- FinOps Foundation
- Cloud FinOｐｓ
データエンジニアはデータエンジニアリングの為のFinOpsのコミュニティ活動をすべき。
- 新しい領域であり、未発見のものがたくさんある。

ここまでで、読者はデータアーキテクチャに関する概要を理解しました。
設計し良い構築を実践する必要がある主な概念を深堀りしていきましょう。

Fundamentals of Data Engineering 輪読会資料 第1回分 20230410開催 Principles of Good Data Architecture

本記事の位置付け

Principles of Good Data Architecture / 良いデータアーキテクチャの原則

AWS : Well-Architected Framework

Google Cloud : Five Principles for Cloud-Native Architecture

Principles of Good Data Architecture

Principle 1 Choose Common Components Wisely / 共通要素を賢く選べ

共通要素(Common Components)

クラウドプラットフォーム

共通要素を選ぶことはバランスが大事。

Principle 2 Plan for Failure / 失敗を計画せよ

Availability （可用性）

Reliability （信頼性）

Recovery Time Objective （RTO：目標復旧時間）

Recovery Point Objective （RPO：目標復旧地点）

計画に失敗を組み込む為のまとめ

Principle 3 Architect for Scalability / 拡張の為のアーキテクト

Principle 4 Architecrture Is Leadership / アーキテクチャがリーダーシップ

Principle 5 Always Be Architecting / 常に設計せよ

Principle 6 Build Loosely Coupled Systems / 疎結合なシステムを構築せよ

参考

Principle 7 Make Reversible Decisions / 裏返せる決断をせよ

Principle 8 Prioritize Security / セキュリティに優先順位をつけよ

堅牢化された境界線とゼロトラストセキュリティモデル

責任共有モデル

セキュリティエンジニアとしてのデータエンジニア

参考リンク

Principle 9 Embrace FinOps / FinOps（クラウドのコスト最適化）を導入せよ

参考リンク

Fundamentals of Data Engineering 輪読会資料第1回分 20230410開催 Principles of Good Data Architecture