【技術本】データベースリライアビリティエンジニアリング
【技術本】データベースリライアビリティエンジニアリング
https://amzn.to/4kDAL2H
【技術本】データベースリライアビリティエンジニアリング
へポスト
本書はDBA（データベース 管理者）が、DBRE（データベース リライアビリティ（信頼性）エンジニア）に進化するためのフレームワークを記している。
データーベース関連の技術的内容にとどまらず、チーム、組織として、いかに他の分野（アプリケーションエンジニア、運用メンバ）のメンバと協業し、システムの信頼性確保のために、自律的に継続的改善サイクルを持つための観点にまで言及してくれて居る。それらの内容はデータベースの信頼性にとどまらず、運用全般にも通用する観点として落とし込んでくれている。
ベースとなる技術的知見として、ビルドスクリプトや各設定ファイルなどをGitやchefを活用して、冪等性を確保してバージョンごとに自動化できるようにする仕組みで環境構築の効率化と、人的ミスの介在を排除する手法を推奨している。
それを踏まえて、インフラレベルからの技術説明に入り、各種DBが扱うメモリ管理とチューニングの目安の指標などを解説。ストレージにおいては、SSD,HDDの違いとそれに対するチューニングの指標などを解説。仮想化においては、DBaaS(DataBase As A service)について言及してくれて居る。
バックアップ（オンライン/オフライン、フルバックアップ/差分バックアップ/増分バックアップ）はデータ損失の対策として、ロギング、バリデーション、インフラ環境のバージョンの追跡、安全なAPIを要してアクセスする（手動で不用意に操作しない）、OSログメトリクスで兆候監視などを解説。
セキュリティにおいては、データ漏洩に関する予防策、DoS、SQLインジェクション、Network脆弱性をついた攻撃の対処を解説。
データベースのアーキテクチャとして、データモデル（リレーショナル/ドキュメント/キーバリュー/ナビゲーショナル/グラフモデル)やトランザクション(ACID属性、read uncommitted/read committed/repeatable read/serializable、dirty read/non repeatable read/phantom read)、DBデータブロックとOSファイルシステムのブロックの関係、DBデータ(バイナリツリー）、インデックス、レプリケーション(単一リーダ、複数リーダ[それぞれのリーダが書き込み/全ての他のノードに伝播する書き込み])などの定番技術を紹介。
その他のデータベース、データストア関連技術として、データプロキシ（レイヤ4/レイヤ７）を活用したスケールや信頼性向上、インメモリストア、キューの紹介、データアーキテクチャとしてLambdaを紹介している。
全体として、技術的知見だけにとどまらず、実際のDB運用業務における現場での協業観点なども学びたい人に価値が出てくる著作だと感じた。
以下、内容メモ
-------
１章：イントロダクション
今日、DBのプロフェッショナルは管理者でなく、エンジニアでなくてはならない。
コードを書き、ビルドができないといけない。> DevOpsを習熟することでチームは一つになる。
DevOps:ソフトウェア開発手法の一つ。開発 と運用 を組み合わせたもの。開発担当者と運用担当者が連携して協力する開発手法をさす。
エンジニアであればこそ、オペレーション作業にける繰り返しの多い作業や、固定化された手順において設計、ビルド、データ構造といった観点から問題点を洗い出し、最適化できる。
DBREの指針
・データを守れ
アクセス可能な領域、権限の適切な設定＞チーム間に壁を設けない権限設定と責任モデルの導入
バックアップとリストア、手順の定期的テスト＞手順標準化と自動化
プロビショニング、デプロイ自動化
手順へ行の場合は、テストや代替策の準備、影響範囲の把握
セキュリティ脆弱性の監査＞セキュリティ方針の標準化
DBやストレージの最適選択
・周囲を巻き込め
・骨折り仕事を減らせ
決まり切った作業の自動化
・分業制のとらわれるな
自分の守備範囲を狭めない＞ソフトウェアサイクルについて学習し、勉強会にも参加
オペレーションの本質
システムとソフトウェアを構築し、運用し、保守するための必要なスキルと知識の集大成
アーキテクチャやそこで実行されるコードのパフォーマンスについても知るべき
GCP, AWS..PagerDuy, Datalog...など代わりにオペレーションをしてくれるサービスがあるからこそ、それらを使いこなすために、学習する。
欲求段階説：マズローが提唱
DBに当てはめてみる
・生存と安全の欲求：バックアップ、レプリケーション、フェイルオーバ
・愛と帰属の欲求：データ管理＞修復可能になるように構築
可能な限り、メンバー全員がDBに習熟するよう働きかける
・承認の欲求：欲求ピラミッドの中で最も高い
DBが観測可能、デバッグ可能、内部で起こって居ることが把握可能なこと
ツール分析が可能
グラフで可視化＞つくりすぎてノイズが多く見逃してしまう状況にならないように
２章：サービスレベルマネジメント
サービスがあるべき運用レベルを見定めること
SLA:サービスがどういった環境で運用されるかの仕様
SLO:サービスレベル目標。設計、運用にかんして遵守すべきことをまとめたもの
SLOの指標
・レイテンシ：レスポンスタイム
・可用性：システムが利用可能である状態を時間枠に対してパーセンテージで示したもの
・スループット：一定時間に正常処理されたリクエストの割合：秒単位
・耐久性：一定の成功率で書き込みができるかどうか
・費用対効果：SLO定義から見過ごされがち
サービス目標の定義
・レイテンシ指標：100ms以下
amazon:100ms遅延で売り上げの1%が失われる
google:page読み込みに500msの遅延＞ゆーざの25%あ離脱
facebook:500ms遅延＞トラフィックが3%現象
一般的サービス：遅延１秒＞ユーザ満足度１６％減少
SLO例：リクエストの99%においてレイテンシは２５ミリ秒から１００ミリ秒の間に収めること
・可用性の指標
サービスはその稼働時間の９９．９％において利用可能なこと
年間５２６分：約９時間のダウンタイムを許容
・スループットの指標
・費用対効果の指標
コンテンツプロバイダ：ページビュー
オンラインサービス：ユーザ数
小売業：トランザクション数
３章：リスクマネジメント
リスクを適切の評価して、軽減する手法の繰り返しで影響範囲を小さくする
・潜在的な障害や脅威となるリスクを洗い出し一覧を作成
・各リスクについて発生する可能性と発生時の影響度について評価
・発生する可能性と発生した時の結果を分類
・発生する可能性を低くする手段、サービス影響を軽減する手段を洗い出す
・各リスクに優先順位をつける
・監視と対応策を実装
・上記を繰り返す
４章：オペレーションの見える化
見える化の重要性
・システムがいつ壊れたか、壊れそうになって居るのを検知できればSLO違反を防げる
・パフォーマンス測定で、現状のシステム状態のトレンドを把握できる
・キャパシティプラニングでリソースの有効活用
・デバッグとポストモーテムで、問題の早期発見
この障害はSLOにどういった影響があるか、どのようになぜ発生したかを知る必要がある
OpVizツールをOpsチームの所有物にするのではなく、ビジネスインテリジェンスツール(BI)として活用の幅を広げる必要がある。
５章：インフラストラクチャエンジニアリング
サーバレスや、DBaaS(Database as a Service)も含めた、データベース構築例の紹介
・物理サーバ：一般的にDBは、CPU,メモリ、ストレージI/Oを多く必要とする
リソースの奪い合いが起きないように、専用のデータベースサーバを用意するのが適切
DBREとして、データベースサーバに使用するホストは、適切なカーネル設定を施す必要がある。
・ユーザリソースのリミット：ファイルディスクリプタ、セマフォ、ユーザプロセス
・I/Oスケジューラ：
noopスケジューラ：I/Oコントローラによって制御荒れて居るSSDアレイのうち、最も適切なターゲットとなるブロックデバイスを選択。SSDは、シーク時間が安定していて、各I/Oリスエストは同等に処理される
デッドラインスケジューラ： I/O処理が待ちぼうけにならないように、
締め切りを設けて、I/Oレイテンシが最短となるように最適化
・メモリ割り当てと断片化：
MYSQL:InnoDB5.5は、glibcのmallocに手を加えた独自ライブラリを使用
GitHubによればカスタム版のtcmallocでレイテンシを30%おさえられる
PostgreSQL:mallocをカスタマイズした独自ライブラリ
メモリを巨大なチャンクとして割り当てている＞memoery contexts
Apache Cassandra 2.1:デフォルトメモリ管理に加えて、off-heapなメモリ管理が可能なjemallocをサポート
MongoDB3.2:デフォルトメモリ管理はmallocだが、設定によってtcmalloc, jemallocに切り替えが可能
Redis2.4: jemallocを使用
jemalloc, tcmallocは、glibcのmallocより負荷軽減、パフォーマンス改善できる
TLB(translation lookaside buffer)は仮想アドレスから物理アドレスの変換において高速化を図るため、そのキャッシュを保持する。
＞大容量のメモリとページを管理するためににはTLBのヒットミスは痛手となる。
THP(transparent huge pages):Linuxのメモリ管理。TLBのオーバヘッドを軽減。巨大なページの断片化は致命的＞全メモリの１０％を断片化阻止の設定に割り当てる
・スワッピング：メモリに収まりきれなくなったデータをディスクに退避
＞OSの最後の手段
スワップを無効にするのは、絶対確実なフェイルオーバが可能な時だけ
・NUMA:non-union memory access:非均一型マルチプロセッシング
cpuが各自ローカルバンクのメモリをもち、リモートバンクにアクセスるる場合は共有バンクメモリにアクセスする方式＞リモート爆のアクセスはコストが高い
メモリは最適に処理ができるであろう特定のノードに割り当てることが多々発生する＞特定ノードに大量メモリが割り当てられ、他のノードには割り当てられないといった事態が発生
＞このアンバランスさによって物理的に利用可能なメモリが余っていてもスワッピングが発生するケースがある。
TwitterにおけるNUMAとSQL（OSのメモリ管理まで踏み込んだ解決法）
numactl --interleave=all
インタリープアロケーションを強制する
MySQLデーモン起動前に、Linuxのバッファキャッシュをフラッシュ
sysctl -q -q vm.drom_caches=3
肥大化したデータがOSのバッファキャッシュに乗っていても清算できる
MYSQLデーモン起動後に、即座に強制的にOSにInnoDB buffer poolが必要とする
分のメモリを割り当てさせる
MAP_POPULATEを使用：カーネル2.6.23+から使用可能
これにより、memsetによるバイト埋めを回避
NUMAノードに割り当て決定を即座に強制させる
・ネットワーク：
トラフィックの種類：データストアが分散して居ると仮定
・クラスタにおける各ノード間の通信
・アプリケーションのトラフィック
・管理用のトラフィック
・バックアップとリカバリのトラフィック
物理的にNICを分けるか、一つのNICに仮想インタフェースを複数割り当てるか
複数のNICをボンディングして冗長性確保
ボンディングのアグリケートで帯域増大
・ストレージ
キャパシティ：保存とロギングのために利用可能な容量。 RAID構成の検討
ストレージのスループット：１秒あたりの入出力性能：IOPS
ストレージの可用性：Googleの調査結果 100このディスクのうち、３個は
最初の３ヶ月で故障する傾向がある。
その後、６ヶ月から１年で、５０個にうち一個は故障
＞RAID構成
・仮想化
・OSのバージョン
・データベースサーバのバージョン
・OSとデータベースの設定
・セキュリティやパーミッション
・インストルするソフトウェアやライブラリ
・管理スクリプト
これらの設定をコード化できる
一つのサーバに複数の仮想サーバを割り当ても可能
ストレージのI/Oレイテンシ：ハイパーバイザが仲介するので物理サーバより遅い
・コンテナの活用
Docker:仮想マシンより軽い。しかし、本番環境で使うにはさらなる
ツールキットが出てから
・DBaaS
デプロイ
フェイルオーバ
パッチとセキュリティアップデート
バックアップとリカバリ
メトリクス収集
これらが自動化され、オペレーションフリーとなる
だからといってデータベースエンジニアが不要になるわけではない、
適切に使いこなすためにDBREが必要
６章：インフラストラクやマネジメント
手作業による繰り返しをなくし、自動化によって素早く安定性のある
インフラストラクチャをいつでも構築できるようにする。
新規ノード増設、障害ノード置き換えなど
自動化対象の作業
・OSと必要ソフト、DB、関連パッケージ、ユーティリティツールのインストール
・環境や負荷に合わせたOSやソフトウェアの設定
・データベースサーバの初期設定
・監視、バックアップ、運用ツール、管理ソフトウェアのインストrーう
・新しく構築したインフラのテスト
・静的および、動的なコンプライアンスのテスト
バージョンコントロールツール：git,subversion
インフラのコード化に当たって、コードを管理する
データベースインフラの定義:chef など
設定管理ツール＞データベースクラスタの設定をコードとして定義
定型処理をコード化
７章：バックアップとリカバリ
最重要プロセス
・物理バックアップ：データを内容して居る実際のファイルを爆アップ
・論理バックアップ：データベースからデータを然るべきフォーマットで抽出して移植可能にすること
一行ずつデータを取り出すため、時間がかかる。
リカバリにも時間がかかる＞全世代のundo,redoログを実行する非町があるため、
その間データベースはロックが必要になる。＞行ベースのバックアップ
ステートメントベースのバックアップ＞レプリケーション
オンラインバックアップか、オフラインバックアップか
オンラインは本来の処理を圧迫しないよう注意が必要
フルバックアップ、増分バックアップ、差分バックアップ
データ損失の問題と対策
・ユーザのエラー：本番環境で手動変更などの変更許可は与えない
用意したAPIで安全に変更できるようにする
変更はテストされ、ロギングされ、適切なチームに通知されるようにする
・アプリのエラー：データのバリデーションを常に実施する
・インフラのエラー：インフラもバージョン管理の対象として追跡可能にする
・OSとハードウェアのエラー：
定常監視して居るログメトリクスに兆候が現れるものである
８章：リリースマネジメント
CI:continuous integration 継続的インテグレーション
CD:continuous deploy 継続的デプロイ
これらをワークフローの妨げとすることなく最適化することが重要
・教育と協力
データベースエンジニア以外も、高いレベルでのデータベースの知識を持てるようにする
DBREは自ら、キュレータとなり、DBの情報を発信していく（SNSなどの最新情報）
ドキュメントシステムの構築
静的に作成されて、実際の環境とずれたドキュメントはナンセンス
設定ファイルやコードから、ドキュメントを生成できる設定管理ツールを活用
アプリケーションコードと同様に、インフラ構築に必要となるコードや設定、
データベースの環境の構築スクリプトも、バージョン管理システムにコミットすべき
・データベースオブジェクトの変更履歴
・トリガ設定
・プロシージャと関数
・ビュー
・設定
・サンプルデータセット
・データ削除スクリプト
９章：セキュリティ
バックアップ、リカバリと同等レベルに最重要
・盗難
・破壊（意図的破壊、意図しない破壊）
・データ漏洩
・コンプライアンスと監査の標準化
機能としてのデータベースのセキュリティ
・結合テスト：SQLインジェクションの混入、認証レイヤの例弱声チェック、暗号化
・オペレーションの見える化
アプリレイヤの見える化：成功失敗のSQLステートメントのトレーサビリティ
データベースレイヤの見える化：
設定変更
データベースユーザ
実行したSQL
新しいデータベースオブジェクト
ログイン監査
応急処理とバイナリ変更
OSレイヤの見える化
設定変化
新しく追加したリソース（ソフトウェア、スクリプト、ファイル）
ログイン監査
応急処理とバイナリ変更
・STRIDE:どのように脆弱性が悪用されるかの分類手法
Spoofing identity:なりすまし
Tempering with data:改ざん
Repudiation:否認
Information disclosure:情報漏洩
Denial of service:サービス拒否攻撃
Elevation of privilege:特権奪取
・DREAD:驚異のリスク分析と優先順位をつける分類手法
Damage potential:攻撃の損害範囲
Reproductibility:攻撃の再現可能性
Exploitability:攻撃の技術レベル
Affected users:攻撃の影響範囲
Discoverability:攻撃手段の発見可能性
予防策
・不要な機能、設定の削除
・パッチ適用：脆弱性定期的チェック
・デフォルトユーザの削除
・ネットワークとホストのアクセス制限
MongoDBのデフォルトbindアドレス：0.0.0.0 = どのIPアドレスからも受け付ける
危険＞デフォルトから変更すべし
攻撃
・サービス拒否攻撃
データを盗む、壊すなどの破壊的ではない
迷惑行為、反競争的行為
対策：
リクエストに再送信までの時間に一定の制限を儲ける
リクエストに優先度を設けて、重要でないもの、悪用されそうなものの
優先度を下げておくことで、影響を最小化
クエリを一時的に性能低下させる
＞負荷状況に応じて低性能処理を用意して実行させる
リソースを長時間占有するリクエスをを強制終了
DB-Dosを悪用されているばあいは、データベースの継続的改善で対応
ログでモニタリングし、攻撃者をトレースできるようにする
・SQLインジェクション
動的クエリを避ける実装にする。＞バインド、バリデーション
・ネットワークと認識プロトコル
脆弱性を利用して、直接データベースに攻撃を仕掛ける場合がある
データの暗号化
・転送中のデータ
・データベースクライアント上のデータ
・ファイルシステム上のデータ
ファイルシステム状のデータの暗号化
ファイルシステム自体の暗号化
デバイスレベルの暗号化
どの地点でも盗聴のおそれがあるが、どこを暗号化するかは、
セキュリティ方針とのトレードオフ
データベースへのアクセス
・TLS1.1または1.2(1.0は脆弱性あり）
・SSH2,RDP(リモートデスクトッププロトコル）
１０章：ストレージ、インデックス、レプリケーション
単一ノードでデータを格納する
大規模なデータセットを分割して格納
複数ノードでデータをレプリケーションする
データ：ブロック単位
データサイズが1kでも、読み込みにはブロックサイズ16kが必要になる
データベースのブロックサイズがOSのファイルシステムのブロックサイズより小さいと、複数のページを無駄に消費することとなる＞むだなI/O
バイナリツリー構造
多くのデータベースは、データをバイナリツリー(B-tree)のフォーマットで構造化
データが増えても、自分でバランシング（二分探索）する性質を持って居る
プライマリキー＞バイナリツリー構造
セカンダリインデックスは、インデックスされたデータのみを含む：行全体は含まない
＞軽い、メモリに乗せやすい
バイナリツリーの書き込み
正しい葉ノードの探索が行われる
データを挿入することでノードが付随するルームと共に作成される
ノードがルームを持って居る場合は、順番に従って挿入
ルームが全て埋まって居る場合は、分割が発生>新たに二分木で決定される
場合によって、さらに追加でルートまでたどって分割が発生する場合もある
削除も、リバランスが発生する場合がある。
データが書き込まれていないデータベースの場合は、初期は読み込みと書き込みが線形で推移。
データが増えるにたびに分割が発生し、I/Oにかかる時間もランダムになってくる
SSD:小さいブロックサイズのほうがパフォーマンスがいい場合あり
HDD:大きいブロックサイズにたいして３０−４０％ほどレイテンシが高くなる
インデックス
・ハッシュインデックス
・ビットマップインデックス
レプリケーション
非同期：レイテンシ優先
同期：耐障害性優先
順同期：レイテンシと、耐障害性を両立して妥協したもの
・単一リーダによるレプリケーション
・複数リーダのレプリケーション
２台のリーダがそれぞれ違うデータセンターに配置されて居るケース
＞各々のリーダの役割を持ったノードが書き込みを行い、レプリカに伝える
どのノードも書き込みと読み込みができ、他のノードに伝播していくケース
１１章：データストフィールドガイド
データストア：データベース
フィールドガイド：多種多様なDBの特性を明らかにし、使用すべき時と場所、適切な設定、
運用方法を提供
データモデル
・リレーショナル
Oracle, MySQL, SQL Server..既存のSQLにとって変わろうとして居るもの
NewSQL: Google Spanner, Amazon RedShift, NuoDB, Firebird
・キーバリュー
・ドキュメント
キーバリューから派生：ドキュメント構造のメタデータを管理
・ネビゲーショナル/グラフモデル
階層的：ネットワーク状のデータベースが起源
トランザクション
ACID属性
read uncommitted：アントムリード、ノンリピータブルリード、ダーティリード発生
read ommitted：ファントムリード、ノンリピータブリリード発生
repeatable read : ファントムリード発生
serializable
PostgresSQL:read committed, repeatable read, serializable
Oracle:read committed, serializable(repeatable readに近い実装）
MySQL:read committed, repeatable read, serializable
CAP定理
一貫性(Consistency)、可用性(availability)、分断耐性(partition tolerance)
のうち2つは満たすことができるが、3つ同時は無理
ほとんどのシステムは、CA, APで構成
１２章：様々なアーキテクチャ
データベースプロキシ
レイヤ７プロキシ：
・バックグラウンドのサーバのヘルスチェック、ヘルシーなサーバへリダイレクト
・読みこみはレプリカ、書き込みはマスタへ送る
・コードでチューニング不可能なクエリを書き換えて最適化
・クエリ結果をキャッシュ
・トラフィクが少ないレプリカにリダイレクト:スケーラビリティ
・クエリのメトリクスの生成
・クエリタイプやホストごとにファイアウォールとしてフィルタを実行
レイヤ４よりレイヤ７のプロキシの方がレイテンシが大きい
イベントとメッセージシステム
キュー、分散キュー
キャッシュとメモリストア
インメモリデータストア、キャッシングシステム
データアーキテクチャ
Lambdaアーキテクチャ
バッチ処理レイヤ
リアルタイム処理レイヤ
クエリレイヤ
１３章：実践DBRE
アーキテクチャを決定するプロセス全てにDBREは関わるべき
開発の初期段階でデータベースの設計に携わるべき
以上。
へポスト