データ指向アプリケーションデザイン
はじめに
2010年代の技術の発展によりアプリケーションの特性が変わってきた
データの量や複雑さ、変化の速度が主な課題となるデータ指向のアプリケーション データシステムのアーキテクチャ、データシステムが組み合わさってデータ指向アプリケーションになっていく様子を主に見ていく 第I部
分散システムでも単一システムでも重要な概念を説明する
https://gyazo.com/fa0f8d037405070217d8efe327e3ce9e
1章 信頼性、スケーラビリティ、メンテナンス性に優れたアプリケーション
データシステムという包括的概念
旧来の分類には当てはまらず、境界が曖昧になっている
Redisはデータストアでありながらメッセージキューとしても使われる データ処理やストレージへの要求が多様化し、単一のツールではすべてを処理できない
現代におけるアプリケーション開発はデータシステムの設計
汎用的な小さなコンポーネント群から特定の目的のためのデータシステムを作り出す行為
APIによって内部は隠蔽される
ソフトウェアシステムの重要な課題
障害があったとしても正しく動作し続けること
データ・トラフィック・複雑さの成長に対して無理なく対応可能である
一次元のラベルでなく、ある側面からみた時の問いかけが重要
システムに関わる人々の生産性を維持できる
複数マシンによる冗長化が必須になるのは高可用性が欠かせない少数のアプリケーションのみだったが、データの量やアプリケーションの処理量の増大と使用マシンが増え、ハードウェア故障の発生率も増大した
マシンが失われても耐えられるシステムへ
ソフトウェアによる耐障害性の手法
Twitterの例
当初は正規化されたRDBMSでJOINしてタイムラインを生成していたがクエリの負荷に追従できなくなった 投稿されるたびにフォロワーごとのタイムラインのキャッシュに挿入する方式に切り替えた
3100万フォロワーを持つアカウントにおいては大変なことになる
投稿よりも読み込みのほうが2桁以上多く行われるシステムだったため
最終的にはハイブリッドなアプローチにした
キャッシュされたタイムラインと、フォロワーの多いアカウントのツイートをマージする
パフォーマンス
負荷のパラメータを増やしながら、システムのリソース（CPU、メモリ、ネットワークの帯域など）は一定のままに保つと、システムのパフォーマンスにどういった影響が生じるでしょうか？
負荷のパラメータを増やしたときに、パフォーマンスを一定に保つにはリソースをどれほど増やさなければならないでしょうか？
1秒あたりに処理できるレコード数や、あるサイズのデータセットに対して1つのジョブを実行するのにかかる合計時間
オンラインシステムではクライアントがリクエストを送信してからレスポンスを受信するまでの時間、レスポンスタイムが重要になる リクエストが処理を待っている期間を表すレイテンシとは異なる Amazonの例
内部サービスのレスポンスタイムの要件を99.9パーセンタイルで示している
100ミリ秒遅れると売上が1%下がる事を観測している
負荷対策
負荷の増大を検知して自動的にコンピューティングリソースを追加できるシステム
ストートレスなサービスの分散は容易だがステートフルなデータシステムを単一ノードから分散システムに移行するのは複雑になる データベースがその筆頭で、スケーリングコストや高可用性のために分散せざるを得ない要求出でてまでは単一ノードでスケールアップするのが一般的だった
どんな処理が頻繁で、どんな処理がまれなのかという推定によりアプローチはまるで変わる
メンテナンス
運用担当者の負荷が低く、価値の大きい活動に集中できる
自動化のセットアップ
シンプルで表現力に富むコードで書かれている
機能を減らさずとも実現できる
要求が変わらないシステムはほとんどない
組織のプロセスという点ではアジャイルが変化に適応するフレームワーク ただし手法に関する議論は小さなスケールにとどまる事が多く、大規模なデータシステムの方法に焦点をあてるのが本書
データシステムのレベルにおけるアジリティのことを進化性と呼ぶ 2章 データモデルとクエリ言語
https://gyazo.com/33dfe34761ce4538982fafce54790d40