はじめに

このスクラップではデータベースリライアビリティ本を購入し、読書会をしていくにあたり章ごとのメモをまとめていきます。

やり方

章ごとに内容を整理する
関連の技術トピックを調べたことをまとめる
DBREJP Slack内で読書会をやる

Sadayoshi Tada / taddy 2021/05/28に更新

１章イントロダクション

Google の Ben Treynor 曰くリライアビリティエンジニアリングについて以下のように語る

偉業はオペレーションの現場ででき、エンジニアなしでは実現できない。

1.1 DBREの指針

これまでのデータベース管理者の原則
- データベースの権限制御
- バックアップリストア
- セキュリティ対応(パッチ、監査)
- 耐障害性
- 冗長性のある、高額なストレージの調達
これからのアプローチ
- チームの枠を超えた権限設定と責任モデルの導入
  - ↑でいう責任モデルってどういう考え方かは気にしておく
- セキュリティ、バックアップリストアは組織内で標準化と自動化
- データベースソフトウェアごとの耐障害性を考慮
- 高額なストレージを使うんじゃなくて自分たちで自動化、冗長化、経験を大切にあする
- デプロイや自動化の環境を変更する場合、万一に備えてテストや代替案を考える
- 他のチームの協力を得る
  - メンバーやチームの力を引き出し正しい方向に導く
  - DBRE = データベースに関するご意見番ではない
- 自動化できるのにしてないっ作業おw減らすこと
DBREはオペレーションよりは開発チームよりの立ち位置
DBREの役割
- 教育
- プラットフォーム構築
- 戦力倍増・自動化
- 運用
- 深い専門領域

従来の"DBA"と"DBRE" の違いは、最後の一行に集約されている気がします。門番として自分たちが全ての責任を持つのではなくて、各serviceチームに権限を渡しつつ、同時に正しくデータストレージを扱えるように導いてくれる存在であると。確かにこういった役割を果たしてくれる存在がいたら、各serviceチームが、開発スピードを維持しつつ、権限を持って、適切にデータストレージ運用をしていけそうです。

"SRE"をmicroservicesにおけるsidecar的役割として説明しましたが、"DBRE"はデータストレージに特化した組織のsidecar的役割を果たす存在とも言えそうです。

1.2 オペレーションの本質

拡張の可能性を考慮し、可用性を担保するオペレーションは高く評価されるべきでオペレーションはソフトウェアを構築、運用・保守するための必要なスキルと知識の集大成。
組織でオペレーションの体制や文化を作っていく。
- ここでいうオペレーションってなんだろ？
- オペレーションは絶対になくならない

1.3 欲求段階説

データベースにおける絶対要求：バックアップ、レプリケーション、フェイルオーバー
スケールについて準備：データベースがどのように成長するか、シャーディングどうするかなどをあらかじめ意識する
データベース操作を俗人化しない
- メンバーが破壊的な操作をしないよう権限制御し、間違いが起こらないように防御壁を設定する。
- 慣れてないメンバーは教育し、自信をつけさせる
データベースにおける承認(他者からの尊敬) = 観測可能なこと、デバッグ可能なこと、内部で起こっていることが把握可能なこと(ストレージを理解しそこで起きているイベントがどのように関係するかを結びつけて理解することが大事)
データベースにおける自己実現の欲求＝データベースが実現したいものの推進力になることはあっても障害になってはならない

Estyの防御壁の設定

Shemanatorというスキーマ変更管理するためのツール
- 変更管理はレビューを提示し、スキーマ定義がおかしくなることを防ぐ
  - 変更管理はスクリプト化されて変更が正しく適用できるかテスト実行する
- 影響が大きい変更はデータベースに対してサービスから切り離して変更を適用してサービスに戻す
- ワークフローを細分化して予想に反した変更が行われないようにする

参考

所感

DBRE がデータベースの番人じゃなくて、開発チームに寄り添ってサービスごとに運用を回していけるように権限制御、教育、仕組み化、基盤の構築・運用を通じていく仕事
- 1人でやらずチームを超えて協力体制を得る
- Not属人化
自己実現や承認という表現が面白かった
- データベースの気持ちを把握し、より良い形を追求する？

話してみたいこと

今は番人化しちゃっているけどどういうところからはじめたか
- 権限を与えるところからかなと思っているけど組織的な規模感でアプローチが変わりそうだから聞いてみたい
- 適切な権限設計ってどうやっていく？
  - 最初はRO
  - 必要な権限をヒアリングする
    - トラブルシュートする人にはつけたり
    - 権限をつけたらテストするか
  - 権限をつけたとして不安な要素として潰すべきこと
    - 情報漏洩
    - 破壊的行動
    - トラブルでサーバーが吹き飛んだ時
      - DBREとしては復旧を粛々と戻せたり、防御策を構えておく

雑談で話したリンク

PITRを仕組み化した
- https://speakerdeck.com/_awache/aws-devday-tokyo-2019-g-6-database-reliability-engineering-using-aws
スキーマの状態チェックをSchemaSpyを使っている
- https://dev.classmethod.jp/articles/schemaspy-docker-localize-jp/

Sadayoshi Tada / taddy 2021/06/06に更新

2章サービスレベルマネジメント

サービスが必要とする運用レベルはどのように定義したらいいか？運用レベルを満たしているかどうか、どのように測定・監視すれば良いかを学ぶ。

2.1 SLO の必要性

ユーザーの視点からSLOを捉えると大切なことはユーザー体験、ユーザー満足度を反映しているかどうか
- ユーザーに対してある目的に照らしてデータを掬い上げた時にサービスが指標となる数字を持っているかどうかが重要

2.2 SLO の指標

代表的な指標
- レイテンシー
- 可用性
- スループット
- 耐久性
- 費用対効果

2.3 サービス目標の定義

SLO はサービスが持つ特性によって変わる
- 指標の数字は三つで十分
レイテンシ指標
- ユーザー体験に決定的な影響を与える最重要指標
  - Amazon: 100msの遅延で売り上げの1%が失われる
  - Google: ページ読み込みに500msの遅延が発生したらユーザーの25%が離脱する
  - Facebook: ページ読み込みに500msの遅延が発生した場合、トラフィック量が3%減少する
  - 一般的なサービス: 遅延1秒につき、ユーザー満足度は16%減少する
可用性の指標
- ダウンタイムをどれくらい許容するか
スループットの指標
- サービスが対応可能な最大値にすべき
  - レイテンシーや可用性とは別の観点でサービスがユーザーの要求を満たしているかの視点
費用対効果の指標
- かかったコストが何に対しての効果と捉えるべきかを考える
  - オンラインサービス：ユーザー数
  - 小売業：トランザクション数
SLO(サービス、プロセスとインフラをどのように設計してくべきか決定するもの)を定義する時に注意すること
- 注目すべき指標は簡潔なものにしておき欲張らない
- ユーザーにとって失われてならないものが何かを自問してそこからSLOを作る
- 定期的にSLOを見直す

2.4 SLOに基づいた監視とレポート

SLO を決めたらそれぞれの項目の測定と監視を始める
SLOの各指標を監視する上大事なことはSLOを達成するリスクを洗い出して、リスクが発生した場合に影響を最小限に抑える対策を講じる
- 監視では収集と分析の自動化に努める
可用性の監視
- システムレベルの可用性とユーザーレベルのエラーは一緒にせず、別々に見えるかをする
  - ユーザーのリクエストに対するエラー発生率(RUM)
    - 理想は累積したデータから近い将来のエラー発生率を予測して週当たりのダウンタイムを超過する結果にならないかと判断できるようになること
  - 監視に加えて故意に作ったデータセットによるテストを走らせることが異常検知に役立つ
  - RUMと定点監視により可用性が上下するタイミングとその要因を把握して時間単位のSLOを守れるかを予測することが可能になる
レイテンシの監視
- 時間に対しての閾値であり、SLOの値を満たせるかを判断する
- エラーの測定はリクエストログをsyslogに流し込み、時系列のデータとして保存してある
スループットの監視
- 測定、収集、可用性とレイテンシのSLOを絡めたレビューが必要
  - 秒単位でトランザクションを記録すれば容易にできる
費用対効果の監視
- クラウドではストレージ、CPU、メモリ、NW帯域のコストの他
- 人件費

所感

SLOの指標はそうだよねって感じ
指標はサービスで必要な重要なファクターに絞る
監視し、常にブラッシュアップしなきゃいかないよ

話してみたいこと

指標作っている？作っているとしてどんな考えで指標を作って、測定している？
- SLOの数字を計測しても意味をなしていない
  - 事業の成長軸で見たSLOと内部的なSLOは異なる
  - ①測定、②事業の優先度や開発の優先度と兼ね合いになる
    - SLO作っていくにあたってDBREに限らずいろんな関係者を巻き込まないといけない
- 障害が起きた時にドキュメント化されているか、エスカレーションフローが確立されて、復旧までのフローが確立されているかが大切

雑談ネタ

https://github.com/yoku0825/anemoeater

Sadayoshi Tada / taddy 2021/06/21に更新

3章リスクマネジメント

オペレーションの本質とは何か？
- SLOを遵守するための作業
  - SLOを定義し、監視、日々オペレーションを改善していくか
  - SLO(Service Level Objective)
リスクマネジメントとはSLO違反の原因となる不確定要素をどのように扱うか
- サービス運用上の不確定要素をどのように発見し、その影響を見積もり優先順位をつけて対処するか
  - ヒト、モノ、カネ、テクノロジーをどのように活用し、不確定要素がもたらす問題を解決していくか
リスクのサイクル
- 潜在的な障害や脅威となるリスクを洗い出し、一覧を作る
- 各リスクについて発生する可能性と発生時の影響度について評価する
- 発生する可能性と発生した時の結果をそれぞれ分類する
- 発生する可能性をどうやったら低くすることができるか、また、発生した時サービスに与える影響を軽減する方法について洗い出す
- 各リスクについて優先順位をつける
- 監視と対応策を実装する
- 上記を繰り返す
リスクマネジメントの重要なことはリスクを評価することではなく、評価したリスクを認識、それらを軽減するために継続的改善を行う

3.1 リスク評価

リスク評価のプロセスに影響を与えるものは4つある
- 1. 不確定要素と複雑性のリスク
  - 今日のシステムは複雑なものになっているからそのリスク評価がより難しくなっている
  - システムの複雑さに立ち向かうには基本から理解をコツコツ積み上げよ
  - 不確定要素がもたらす影響の対応は難しいものがあある
    - AWS,GCPのクラウドインフラの影響
    - ハードウェアベンダに要る影響
    - エンジニアによる間違ったコードのデプロイの影響
    - マーケティングチームによる突発的な負荷の影響
    - サービス立ち上げ時、もしくは終了時に伴う影響
    - 使用しているソフトウェアのバージョアップによる影響
- 2.リソース不足とリソースマネージメント
  - 限られた時間でリスクマネジメントするためには優先度付けが必要
  - 最も起こりうる可能性が高く、最もサービスに影響を与えるリスクに絞って障害が発生してもすぐに回復が可能なシステムを構築する
- 1. 個人にまつわるリスク
  - 人間が持つ潜在的リスクに注意を向けなければならない
    - 無気力症候群
    - ありふれたリスクを無視する
    - 不安への対処
    - 極端な楽観主義
- 1. 集団にまつわるリスク
  - 集団極性化：集団になるとリスクがある判断も合意が取れればリスクを低く見積もる
  - リスク転移：リスクを他人事にする
  - 他人任せの意思決定：意思決定を誰かに任せることでバケツリレーのレースになる。意思決定は役職と承認プロセスよりも個人の経験と専門知識を重視した自律的な組織を目指すことが大切

3.2 どうすればいいか

リスク管理のためのプロセスを確立し、時間かけて繰り返し改善していくことで最終的にリスクを軽減できるようにするほうが妥当
- リスク発生時の対応力を高めるのか、それとも全てのリスクの撲滅を目指すのか、継続的に改善進めていくようなリスクの取り方をしていくべき
ゴール設定で全てのリスクを撲滅することは望ましいことではない
- リスクが全て取り除かれた状態はシステムは成長も改善もない
- Googleの発案したエラーバジェットをリスク対応用に使用するという考え方がある。４半期に30分のダウンタイムをエラーバジェットにして計上する
- 徹底的なリスク回避を目指すのではなくある程度のリスクを許容する姿勢が健康的

3.3 してはいけないこと

リスクマネジメントでしてはいけないこと
- 主観的なものの見方に囚われすぎること
- 口コミや逸話といったあやふやなものを判断材料とすること
- 直近のインシデントや問題にのみ注力すること
- 壁に当たってそのまま放置すること
- 人的リソースの問題を無視すること
- アーキテクチャやワークフローの進化を受け入れず、昔ながらのものに固執すること
- 過去の成功体験に囚われること
- 問題に対して細かい対応を怠ること
- 最悪のケースを無視すること
上記以外にもつけくわたいものは定期的に更新する

3.4 実際の作業：はじめの一歩

リスク万字面とのはじめの一歩はSLOを脅かす可能性のあるリスクを認識すること
- 最終的なゴールはリスクを認識し、それを軽減する方法を考え、リスクを排除する計画を立て、どうオペレーションに落とし込むか、そのためのリソースをどう配分するか
プロダクトオーナーとサービスについてどこまでリスクを許容するかを話し合う
- SLOに定義すべき可用性とレイテンシをどう定めるか
- ダウンタイム発生時、もしくは極端にレイテンシが遅くなった場合、サービスに与える影響はどういったものになるか
  - ユーザー全体に影響があるか
  - ユーザーの一部に影響があるか
  - サービスは緊急モードで稼働可能か
  - サービスのパフォーマンスはどの程度まで落ち込むか
- サービスダウンしている間の損害は何か
  - 売上、
  - ユーザーのリテンション
  - サービスがダウンすることで会社そのものに悪影響をもたらすか
UberPony という書くの会社で小馬をオンデマンドで利用できるサービスを提供していると仮定したケーススタディ
6つの機能で成り立っている
- サインアップ
- 仔馬のオーダー及び確保
- 子馬の御者のサインアップ
- 子馬の御者の確保
- 子馬の御者への支払い
- 分析
やっていくこと
- 1, サービスを稼働させるために必要なリソースの棚卸しして、責任範囲を明確にする(データベースだけじゃなく、ソフトウェア、サーバー、ジョブ、ネットワーク、ハードウェアなど)
- 2, SLOに定義した各指標を潜在的に侵す可能性がある各リスクについて影響度をそれぞれ書き出し、考慮する
  - 非常に深刻な影響を与えるリスク(Secere: 即SLO違反となる)
  - 深刻な影響を与えるリスク(Major: SLO違反ギリギリ)
  - 中程度の影響を与える(Moderate: 他のケースが同時発生した場合SLO違反となりうる)
  - 軽微な影響を与える(Minor: 軽微)
  - 上記のような手法はフレーミングと呼ばれる手法で、日々の業務を実用的な一定の枠組みの中に当てはめていくこと（こうすることで最も起こりうる可能性が高い高いリスクのケース、そして最も影響度が高いリスクのケースとベクトルごとに洗い出せる）
潜在的なリスクに対して3つの選択肢がある
- リスク回避（リスクを撲滅する方法を見つける）
- リスク低減（リスクがハッセした時の影響軽減する）
- リスク受容（リスクを受け入れ、発生した時の対応策を用意しておく）
  - リスク確認：ストレージに起因する障害のパターン4つ
    - 書き込み用のインスタンスに障害が発生
    - 読み込み用インスタンスに障害が発生
    - レプリケーションに障害が発生
    - バックアップに障害が発生
  - リスク評価：
  - リスク低減と管理
  - 実装

3.5 改善のサイクル

継続的な改善プロセスには以下のものがある
- リリースレビュー（リリース評価と振り返り）
  - サービスがリスク許容、収益、コスト、ユーザーへの影響などそれぞれの観点で前より改善したかを定期的にチェックする
- 障害管理
  - リスクの優先順位づけ
  - 障害後のポストモーテムでは今まで見落としていたリスクを明らかにして、リストを更新する必要がある
- アーキテクチャのパイプライン
  - 設計段階で想定してなかったリスクを組み込むこと

雑談したこと

お金の決済以外でSLOとして考慮すべきことなんかある？
- 検索機能
- 初回登録
DB の不確定要素って考えてみた
- テーブルの設計の不確実性
  - カラムに複数の意味を持たせたい時
  - データベースでやる必要あるか？を確認する
  - SQL出して確認する
全部のリスクを対応をするのは難しいので、範囲を絞って優先順位をつける
- どこから手をつけるを誰が判断する？ => プロダクトオーナーと協議
  - プロダクトオーナーとはどこまで話しとく？
    - システムダウンのリスクをどこまで許容するか
MTBF使っている？
- 事例をきかない...
- 品質が悪そうだし、意味をなさない

雑談した時のリンク

Sadayoshi Tada / taddy 2021/07/09に更新

4章オペレーションの見える化

「見える化(モニタリングとは別物)」によって、日々刻々と変化していくデータベースと付随するコンポーネントの状況を把握することが可能になる
なぜ見えるかが重要なのか？

アラートの発生と収束
- システムがいつ壊れたのか、壊れそうなのを知ることができればSLO違反を防ぐ
パフォーマンス測定
- 外れ値を含んだレイテンシを理解して、現在のトレンドを把握する
キャパシティプランニング
- サービスがどこまでサーバーリソースを使っているかを把握してサーバーリソースを必要十分な状態になっているかを確認する
デバッグとポストモーテム
- 見える化することでどれくらいでサービスダウンするか、最適化のために何をすべきかを把握することで問題解決する
ビジネス分析
- サービスがどのような価値を生み出しているかを見える化し、コストをどう振るかを考える
原因と結果の相関分析
- サービスの負荷があった時、インフラとアプリでどのような相関があるかを把握する

チームが目指すものは、オペレーションの見える化(OpViz)で、どのようにアーキテクチャ全体を見える化をしていくかについて触れる
※ヒューマンエラーが発生するのはプロセスや環境にも原因になりうるので根本的な原因を追求しよう

4.1 現在の見える化の標準仕様

OpVizで見える化を進める理由 => Opsチームだけじゃ無くてチームの垣根を超えて設計、構築、管理できるようBIとして活用する
- 「この事象はSLOに対してどういった影響があるか」
- 「障害はどのように発生したのか？なぜ発生したのか？」
  - 上記を把握できる
究極の見えるかはビジネスがどのように動作し、インフラとアプリによりビジネスはどのように影響を受けるのかを誰もが理解できるもの
今日のデータベースインフラは頻繁にサーバーが入れ替わるが、そのノード情報を収集しないわけにはいかない
- 動的に変化するインフラではメトリクスはロールごとに保存されることが必要
メトリクスは1秒以下の集取間隔を保つことが大切
- メトリクスが1秒から10秒の間に変化が発生するとSLOに影響を与える
- メトリクスとしてはSLOに直結するものを優先してみる
  - レイテンシ
  - 可用性
  - コールレート(リクエストの集中度合い)
  - 利用率(どれくらいの負荷でサービス影響が出るか、どこでインフラを拡張しなければならないかの分岐点の見極め)

4.2 OpViz フレームワークの構築

OpViz をI/Oデバイスにした時、入力データはルーティング、構造化、出力される
各プロセスをみていく
- データは収集エージェントやクライアントによって収集されデータタイプごとに中央サーバーに格納される
  - 分散システムの利点は設定管理のコストを圧倒的に低く抑えられる
クライアントがメトリクスを収集もしくはイベントルータに転送する
イベントルータは経験則に従いデータを所定の場所に送信する
最終的にデータは長期期間保存される
- チケット、グラフ、アラートを含む

4.3 データの入力

システムにリクエストを送信するユーザーのシミュレーションを行う時は、ブラックボックスモニタリングという
- ブラックボックスモニタリングでは、さんんプルとなるカナリアユーザー、もしくはインターネットからの入力と出力を監視する
  - 監視対象の期間やアイテムがそれほど多くない場合に有効な手段
もし十分なデータがない場合は、ホワイトボックスモニタリングを採用する
- どのアプリケーションのどの部分を監視するかを決める必要がある(AppDynamics,New Relic,HoneyComb)
ホワイトボックス式アプローチのメリット
- データを生成するコンポーネントを全てエージェントとして管理できること
- 監視を中央集権的に構成していく場合、サービスが成長し、監視対象が拡大していくにつれて中央集権の中身となるサーバーの負荷も比例して増えるのが常だがホワイトボックスモニタリングを採用し監視対象をアーキテクチャそれぞれに分散することでこの問題を回避できる
  - 各リソースの登録・解除が収集対象の礼ごとに容易に行える点もOpVizと相性がよい
メトリクスはアプリケーション、インフラが日々稼働しつける際に生み出される財産
- 定期的に観察、時系列順に制される
- 典型的なメトリクスは4つに分類される
  - カウンタ：累積する値であり事象の発生回数を示すもの
  - ゲージ：温度・キュー中のジョブ数、アクティブ六k数雨など増減の振れ幅があるもので現在の値を示すもの
  - ヒストグラム：データ集合のうちイベントの発生回数を示すもの
  - サマリ：特定の時間枠単位でのカウントに特化したもの
重要な関数
- Count/Sum/Average/Median/Percentiles/Standard Deviation/Rates of Change/Distributions
イベント
ログ

4.4 データの出力

システムに流れるデータの出力を使ってどのようにOpVizを構築すれば良いか
- アラート
  - アラートはSLOに準拠できない事象がまさに起ころうとしているケースのみ送られるべき
- チケット/タスク
  - 必ず完了させなければならない重要な作業はチケットとタスクを作成する
- 通知
  - システムに発生するイベントを記録することでチームでいつ新しいバージョンがリリースされたのかを記録しておくことができる
- 自動化
  - リソース利用率のデータに応じてオートスケールするよう自動化する
- 見える化
  - 各部門が知りたい情報を即座に理解できるようにグラフ化する

4.5 監視の大一歩

OpViz も最初は小さく初めて徐々に進化させる
- スタートアップなら尚更
  - スタートアップは必要最小限のサバイバル監視セットから始める
監視したいメトリクスは無数にあるが、サービスにおいて影響を及ぼす要素を整理して監視することから始める
- まず始めるべきの監視は何か？
  - データベースプロセスの死活監視
  - 全体のレイテンシとエラー率の監視、E2Eのヘルスチェック
  - アプリケーションレイヤからデータベースを利用する際のレイテンシとエラー率
  - 取得可能なメトリクスを収集する
  - 既知の問題に対して能動的にチェックする仕組みを入れること
    - ノード障害やロックが発生するなど
ミッションクリティカルなデータは少なくとも合計3つのレプリケーションコピーをも持つ必要がある
データの中でも失われちゃいけないデータは最低限そのデータを確保するノードの個数がnの場合、n+1個確保できていれば十分
データの安全性の監視
- 3つ以上のノードが稼働していること
- レプリケーションスレッドが稼働していること
- レプリケーションの遅延が1秒以下であること
- 直近のバックアップが成功していること
- 直近のバックアップからスレーブが自動的に構築できること
外部からのE2Eのヘルスチェックは一気通貫でチェックできるようにする
- データベース可用性の監視サンプル
  - アプリケーションレイヤでヘルスチェックが有効であること
  - クエリが各パーティションやクラスタの各ノードを参照するようなものであること
  - キャパシティ不足の兆候を把握できること
  - エラーログのスクレイピングを実施することでデータベースの再起動やデータベースの破損を感知できる
監視システムができてもレイテンシが悪くなったり、リクエストの10%がエラーを返すようになったら顧客のサービス体験にネガティブな影響を与える
- 障害の原因の特定、障害の見届け、将来の糧にする

4.6 アプリケーションの計器

アプリケーションのメトリクスをまず収集する
- APIエンドポイントにおけるリクエストとレスポンスは全てロギングおよび測定する
- アプリケーションが利用している外部リソース、データベース、インデックス、キャッシュも測定する
- アプリケーションのジョブ及びワークフローも同様に監視する
- 各エンドポイント、ページ、そしてメソッドや関数ごとにどれくらいのデータベースに対してクエリを発行しているかを監視する
  - データベースにアクセスするコードを追跡することでクエリログと照らし合わせることでクロスチェックが可能になる
アプリケーションレイヤからデータベースレイヤまでE2Eで何か発生しているかを把握するためには多くのコンポーネントに興味を持つ
- データベースへの接続確立
- コネクションプールにおける接続待ちのキュー
- キューやメッセージングのロギング
- UUIDを利用したユーザーIDの作成と管理
- クラスタにおけるユーザーIDなどをベースにしたシャーディング
- データキャッシュにおける検索、キャッシュ、そして有効期間の設定
- アプリケーションレイヤにおけるデータの圧縮と暗号化
- クエリの実行
イベントとログ
- デプロイの実施
- デプロイの時間
- デプロイのエラー

4.7 サーバーやインスタンスの計器

サーバーのメトリクスとして取っておくこと
- CPU、メモリ、ネットワークインタフェース、ストレージI/O、ストレージキャパシティ、ストレージコントローラ、ネットワークコントローラ、CPUインターコネクト、メモリインターコネクト、ストレージインターコネクト
- カーネルの排他ロック制御、ユーザーの排他ロック制御、タスク管理、ファイルディスクリプた
イベントとログ
- サービスに組み込まれたまたは外されたホストのログ
- 設定管理ツールやプロビジョニングツールのログ
- ホストの再起動、サービス再起動、ホストの障害、サービスの障害に関するログ

4.8 データベースの計器

データベースの監視として何をすればならないか
- データベースの接続レイヤ
  - 接続にかかる時間や発生するエラー
  - 接続の最大接続数
    - 接続数の上限と接続数のカウント
    - 接続状態
    - カーネルレベルでのファイル利用率
    - カーネルレベルでのプロセス使用率
    - メモリ利用率
    - スレッドプールのメトリクス、スレッドプールの利用率
    - ネットワークスループットの利用率
- データベース内部の見える化
  - リソースの飽和点
    - TCP接続ログ
    - データベースの接続キュー
    - タイムアウトエラー数
    - コネクションプールにおける割り当てスレッド数
    - メモリのスワッピング状態
    - ロック状態のデータベースプロセス数
  - 目的はレイテンシに悪影響をお呼びしているか、なぜ飽和点に達してないのにリクエストの上限が低い天井で止まるのか、または何が現在、原因不明となているエラーを引き起こしているのか、これらを見えるかすること
    - データベースエンジン、マスタとレプリカのロールなど見える化は個別の視点とロールごとにまとめた視点を持つ
  - スループットとレイテンシの見える化
    - 読み込み、書き込み処理
    - その他の処理(コミット、ロールバック、DDLの実行など)
  - コミット、再実行、ジャーナリングの見える化
    - ダーティバッファ
    - チェックポイントの経過時間
    - コンパクションタスクの中断及び完了
    - ダーティバイト
    - 修正された、もしくは未修正の待避ページ
    - log_checkpointsの設定
    - pg_stat_bgwriteビュー
      - チェックポイント処理、フラッシュ処理、コンパクト化の処理はデータベースのパフォーマンスに影響を与える＝＞I/O負荷が高くなったり書き込み処理が全て停止することもある
  - レプリケーションの見える化
    - レプリケーション遅延は他の障害の原因にある
      - レプリケーションのレイテンシ
      - レプリケーションの失敗がないか
      - レプリケーションドリフトが発生してないか
  - メモリ構造の見える化
    - データキャッシュを見える化する際に注意点
      - 利用率
      - かくはん率
      - ヒット率
      - 同時並行生
  - ロックと並行性の見えるか
    - mutex
    - セマフォ
- データベース内のオブジェクト
  - 最低限1つのオブジェクトそのリレーションになるキーやインデックスがそれぞれストレージを消費するか
- データベースに投げられるクエリ
  - Coretex,Circonusといったツールを使えばTCPレベルで必要なデータをロギングできる
  - スロークエリ
  - アサートとエラー
    - 接続試行回数とエラー数
    - データが破損していることを示すメッセージ
    - データベースの再起動
    - 設定の変更
    - デッドロック
    - コアダンプとスタックトレース

雑談

監視を小さく始めようと書いているけど結構包括的な記述が多い
SLO みたいな共通言語がないと判断が決められない
- ユーザーファーストであることは大事
パラメーターグループをIaC 化している？
- 環境によって変化するものはちゃんと保管しておく

Sadayoshi Tada / taddy 2021/07/09に更新

監視で何をみていますか

Sadayoshi Tada / taddy 2021/07/30に更新

5章インフラストラクチャエンジニアリング

データベースをホストごとの構築例を紹介し、サーバーレスやDBaaSだけでなく、ストレージの使い分けにも触れる

5.1 ホスト

ホストは仮想サーバー、コンテナ、抽象化されたマネージドサービスに至るまで取りうる選択肢は広がっているため、メリデメそして実装がどうなっているかを比較検討する

物理サーバー

DBRE は他のサーバーとデーターベースサーバーを分離する
- そのためにリソース状況を把握する必要がある
- 一般的にはデーターベースサーバーはCPU、メモリ、ストレージI/Oのリソースをかなり割り当てるから相乗りにすると、リソースの奪い合いが起きるため専用のサーバーが必要
  - HW,OSについてデータベースエンジニアはどうやって性能を最大限に引き出せばいいか、そのために何を知るべきかを解きほどく
カーネル設定
- ユーザーリソースのリミット（ファイルティスクリプタ、セマフォ、ユーザープロセス）
- I/Oスケジューラ
- メモリ割り当てと断片化
  - データベースサーバーがメモリを最も消費するため
- スワッピング
- NUMA(非均一型マルチプロセッシング)
- ネットワーク
  - クラスタのノード間通信
  - アプリケーションのトラフィック
  - 管理ようのトラフィック
  - バックアップとリカバリのトラフィック
- ストレージ
  - キャパシティ
    - データ保存とロギングのための利用可能な容量
  - スループット(IOPS)
  - レイテンシ
  - 冗長性
  - 耐障害性
- SAN
  - スナップショット取得をはじめとする管理機能を考えるとSANがよさげ
物理サーバーの利点
- アーキテクチャをシンプルにできる
  - シンプルになることで見える化につながる
- コンポーネントやランタイムのもたらす複雑さはない
- ストレージ操作がOSから直接操作できること
物理サーバーのコスト

5.2 仮想化

仮想化の価値は OSを含めて利用するソフトウェアの設定をコード化して管理できること
- DBREとしては以下をコード化したい
  - OS バージョン
  - データベースサーバーのバージョン
  - OS とデータベースの設定
  - セキュリティやパーミッション
  - インストールするソフトウェアやライブラリ
  - 管理スクリプト
仮想サーバーのデメリット
- 抽象化されたレイヤがあり、複雑さもある
ハイパーバイザー
並行性
ストレージ
- 物理サーバーより I/O レイテンシは大きくなる
- ストレージタイプは大きく2つ->揮発性か永続性か
- ネットワーク帯域が圧迫されるとディスクパフォーマンスは落ちることがある
仮想サーバーでデータベースサーバーの構築注意点
- データ損失が必ず発生するものとして設計(Design of Failure)
- 仮想サーバーの不安定性から自動化、フェイルオーバー、リカバリは必須として用意する
- 水平スケールアウトできるよう自動化
- レイテンシの不安定さをアプリケーション側で許容できるようにする
仮想化のメリット
- 即座に構築可能
  - チームにDBREが少数の場合有効
- デプロイを迅速に実施できる

5.3 コンテナ

コンテナは仮想マシンよりもずっと軽く、起動時間も早い特徴がある
- 起動スピードは速いけどストレージ、カーネル、ネットワークの観点からデータベースサーバーとしてコンテナを選択する意義は薄い
- 本番で使うならさらなるツールキットが登場してからになる

5.4 DBaaS

パブリッククラウドのデータベースマネージドサービスが提供されているのがあたる
DBaaSは何を自動化し、何の管理を委譲したいか
- デプロイ
- フェイルオーバー
- パッチとセキュリティアップデート
- バックアップとリカバリ
- メトリクス収集
- Aurora のような DBaaS の魅力となる特別な機能と高いパフォーマンス
  - 上記が自動化されてオペレーションフリーになることでこれ以外のタスクに集中できるようになるが、DBaaSを理解して使いこなすための技量は必要になる
DBaaS では見えないぶぶが多いため限られた機能頼らざるを得なくなる
DBaaS を使うにしても使いこなすためにどうすれば良いかの仕事は DBRE に委ねられている
- DBaaS は小さな組織に魅力的
- DBaaS からマイグレーションや DR を考慮しておく
  - DBaaS の機能に寄っかからず自分たちでもサービス提供可能な状態にする

雑談

昔を思い出す内容
DB が動くホストをちゃんと把握できる DBA が機能しないと環境が違っても本質的な仕事ができない
データ領域はディレクトリ分けますか？
Auroraではディレクトリ分かれている
- basedir /rdsdbbin/oscar/
- datadir /rdsdbdata/db/
- slow_query_log_file /rdsdbdata/log/slowquery/mysql-slowquery.log
Aurora のパラメーターは基本いじらないよね

mamy1326 2021/07/30

mysql> show variables like '%dir%';
+-----------------------------------------+---------------------------------------------------------------+
| Variable_name                           | Value                                                         |
+-----------------------------------------+---------------------------------------------------------------+
| basedir                                 | /rdsdbbin/oscar/                                              |
| binlog_direct_non_transactional_updates | OFF                                                           |
| character_sets_dir                      | /rdsdbbin/oscar-5.7.mysql_aurora.2.10.0.0.4.0/share/charsets/ |
| datadir                                 | /rdsdbdata/db/                                                |
| ignore_db_dirs                          |                                                               |
| innodb_data_home_dir                    |                                                               |
| innodb_log_group_home_dir               | ./                                                            |
| innodb_max_dirty_pages_pct              | 75.000000                                                     |
| innodb_max_dirty_pages_pct_lwm          | 0.000000                                                      |
| innodb_tmpdir                           |                                                               |
| innodb_undo_directory                   | ./                                                            |
| lc_messages_dir                         | /rdsdbbin/oscar-5.7.mysql_aurora.2.10.0.0.4.0/share/          |
| plugin_dir                              | /rdsdbbin/oscar-5.7.mysql_aurora.2.10.0.0.4.0/lib/plugin/     |
| slave_load_tmpdir                       | /rdsdbdata/tmp/                                               |
| tmpdir                                  | /rdsdbdata/tmp/                                               |
+-----------------------------------------+---------------------------------------------------------------+
15 rows in set (0.00 sec)

mamy1326 2021/07/30

mysql> show variables like '%slow%';
+---------------------------+----------------------------------------------+
| Variable_name             | Value                                        |
+---------------------------+----------------------------------------------+
| log_slow_admin_statements | OFF                                          |
| log_slow_slave_statements | OFF                                          |
| slow_launch_time          | 2                                            |
| slow_query_log            | ON                                           |
| slow_query_log_file       | /rdsdbdata/log/slowquery/mysql-slowquery.log |
+---------------------------+----------------------------------------------+
5 rows in set (0.01 sec)

Sadayoshi Tada / taddy 2021/08/15に更新

6章インフラストラクチャマネジメント

インフラをどのように管理し、スケールさせていくかに着目する
- 本章の目的は手作業による繰り返しをなくして自動化によって素早く簡単に安定性のあるインフラをいつでも構築できるようになること
自動化しなければならない作業の例
- OSと必要なソフトウェア、データベースと関連するパッケージとユーティリティーツールのインストール
- 環境や負荷に合わせたOSおよびソフトウェアの設定
- データベースサーバーの初期設定
- 監視、バックアップ、運用ツールなど、管理用ソフトウェアのインストール
- 新規構築したインフラが意図した通りのものになっているかのテスト
- 静的および動的なコンプライアンスのテスト
  - 実現したいインフラというのは確実に再構築可能であり、データベースサーバーとしての設定に加えて関連ツールも導入済みであり、過去そして現在の状態を把握することができいつでもトラシュのための診断ツールやテストを実行できる環境
  - これはかなりレベルの高い目標

6.1 バージョンコントロール

バージョンコントロールする対象
- ソースとスクリプト
- ライブラリとその依存関係にあるツール群
- 設定ファイルとそれに関する情報
- OS イメージ及びデータベースのバイナリのそれぞれのバージョン
  - VCSで上記のものを管理する

6.2 データベースインフラ設定の定義

データベースクラスタの設定とビルドを自動化するにあたっては設定管理ツール(Chef/Puppet/Ansible/SaltStack/CFEngine)でやる
- DSLを備えているものならプログラミング言語をそのまま使用可能なものもある
これらのツールで実現したいのは冪等性(ある動作を繰り返した場合に同じ結果が得られる)
設定管理ツールをまとめるべき設定はいくつかある
- コアアトリビュート
  - インストール方法、ロケーション、ハッシュ
  - クラスタ名とバージョン
  - グループとユーザーのパーミッション
  - ヒープサイズ
  - JVMチューニングと設定
  - ディレクトリレイアウト
  - サービス設定
  - JMXセットアップ
  - 仮想ノード
- JBODセットアップとレイアウト
- ガベージコレクタの挙動
- シードディスカバリ
- YAML設定ファイルの管理
- OS設定
- 外部サービス
  - PRIAM
  - JAMM
  - ロギング
  - OpsCenter
- データセンタとラックのレイアウト
設定管理ツールでは構築前後でテストすること、および監視とロギングもセットでコード化したほうがよい
- 全ての設定が反映された結果機能が期待通りに動いているかを保証するため

6.3 データベースインフラ設定とビルド

6.4 データベースインフラ設定の管理

構築後に設定が変動してしまうため差分が生じる(設定漂流)
イミュータブルインフラストラクチャのメリット
- 単純さ
- 予測が用意
- リカバリ
運用方針に基づいたインフラ設定を更新するか
- 全サーバーで設定を同期する
- サーバーの再構築

6.5 インフラストラクチャ定義とオーケストレーション

インフラ設定を抽象化するにあたってはコード化された各コンポーネントのバージョンとオーケストレーションツールが連携して動作する必要がある
オーケストレーションルールはリポジトリからインフラとアプリケーションのコードをチェックアウトし、それらをもとにバージョン管理されたインフラを自動的に構築できる
DBREとしてどこような責任を持つべきか、役割を果たすかについてみていく
モノシリックな場合
- モノシリックなインフラストラクチャ定義として異なるアプリと対応したそれぞれが異なるデータベースが同じファイルで定義されている
  - 良い点はなく悪い点はたくさんある
    - 1つの設定を更新すると全ての設定をテストし直す手間が出る
    - 設定が適切に分離されるため1つの変更が全体を壊す可能性がある
    - コンポーネントの一部だけをテストしたい場合でもすべてを一緒にビルドしなきゃいけない
    - インフラの全体像をハックできているのが少数の開発者のみとなりやすく変更に時間がかかり、開発のボトルネックとなる
  - Terraformの様なツールをつかうことで全てのサービスを1つの定義の中に突っ込まず水平的な分割(1つのスタックの中に並列におけるコンポーネント)と垂直的な分割(1つのスタックに1つのサービスが基本)で定義を分割できる
垂直的な統合
- 垂直的な分割によってはより小さくよりシンプルなアーキテクチャ単位で構築管理が可能になる
  - まずは1つのファイルを2つにしたり、小さく初めて最終的に全てのサービスをサービスごとに管理する
- これによりインフラを更新した際に障害ドメインが発生してもその影響範囲を対象のサービスのみにとどめることができる
  - 図6-2に示すものでは3つのデータベース定義が必要(1つは共有データベースの定義、2つは各サービス用の定義)
水平的な分割
- スタックを垂直同様に分割すると障害ドメイン発生時の影響範囲を狭めることができる
  - DBの設定変更によりWebサーバーの挙動まで犯してしまう心配がなくなる
- スクリプトの分割だけでなくスタックを超えてリソースのステータスとスタック同士の接続を統合管理のためにサービスカタログが必要になる

6.6 テストとコンプライアンス

Serverspecのようなツールを利用することでインフラに対してテストを実行できる
- インフラ構築にもTDDを適用可能

6.7 サービスカタログ

インフラのコード化によってサーバーは自動的にビルドされ、スケールし、そして破棄される様になると全てのサーバーの現在の状態が全体としてどの様になっているかを示す何かが必要になる
- サービスディスカバリはこうした状態を抽象的に示すもので特定の機能やサービスのポート番号、ロードバランサをマッピングして意味のある名前付けを行う
- アプリケーションからみると使いたいサービスについてサービスディスカバリに問い合わせれば、その時利用可能なサービスのエンドポイントを返せる
- Zookeeper/Consul.io/Etcd/もしくは自分で実装
DBREとして関わるサービスカタログ例
- データベースのフェイルオーバー
- シャーディング
- Cassandraのシードノード

6.8 すべてを1つに

DBRE としてEC2上にMySQLを構築する時にどう動くかを考える
- ユーザー情報を格納しているプライマリサーバーの容量が逼迫しており、シャーディングが必要な状況
- 利用可能なツールとして MySQL Server5.6/MySQL MHA/Consul/Terraform/Chefがあり、これらを使うとどの様に構成するかを見る

6.9 開発環境

変更前に変更を自由に試せるサンドボックスを開発環境としてワークフローに組み込むのが大事
- サンドボックスが用意されていれば、変更の影響を試せる
サンドボックスは本番環境で動いているソフトウェア、設定、そしてインフラと限りなく重なる様にすることで再現性を保つことが大切

6.10 まとめ

インフラのコード化、自動化、バージョン管理はDBREに必要なスキルセット
- 本章ででてきたツールやスキルを使えば、自動化できヒューマンエラーを撲滅できる

Sadayoshi Tada / taddy 2021/08/24に更新

7章バックアップとリカバリ

5,6章ではインフラの設計と管理について焦点を当てた
- バックアップとリカバリについて本章では触れる
バックアップとリカバリは多くのエンジニアが骨折り仕事(toil)の最たるものと考える
- とはいえ、疎かにできない作業だから一度リカバリ作業をエンジニアが経験することを勧める

7.1 基本的原則

物理vs仮想
- 物理バックアップ：データベース固有のファイルフォーマットと一連のメタデータ、内部のデータ構造を維持しないとリストアできない
- 論理的なバックアップ：データベース固有のファイルフォーマットと一連のメタデータも含まれるが、重要なのはバックアップ日時
  - 1行のinsertを入れると後に復元できるかどうか
  - 論理的なバックアップは物理バックアップとは違い時間がかかる(1行ずつデータを抽出するから)
    - リカバリも時間がかかる
オンラインvsオフライン
- オフラインはデータベースを落とさないとできない
- 大体はオンライン(クラウドのマネージドもこれ)
フル、増分、差分バックアップ
- フルバックアップ：全部
- 増分：フルバックアップ - 増分　を差分としてバックアップする
  - リストアする時はフルバックアップと増分を全て順にリストアする
- 差分：フルバックアップから差分があったデータのみバックアップする

7.2 リカバリ考察

リカバリの戦略を立てるにはまずはSLOに立ち戻らなければならない
- 2章で振られた冗長性と耐障害性の指標に沿って、制約された時間内にリカバリを完了させる必要がある
アプリケーションがデータのフォーマットが変更する場合に対応する必要があり、DBREは備える必要がある
リカバリ計画
- 不測の事態と、予測困難な事態に対して可能な限り手を打つ
- 可能な限りリカバリを実行できる状態に保ち、潜在的な問題に対して備えることがDBREが果たすべき基本的かつ絶対的な職務

7.3 リカバリシナリオ

可能な限り不測の事態に備え、リカバリを実行可能な状態に保つことを念頭において生涯のタイプ別にどう言ったリカバリが必要になってくるのかを考える
障害タイプ：想定内と想定外にわける
- 想定内
  - リカバリのケース
    - 新規ノードや新規クラスタの構築
    - 既存とは異なる環境を構築する時
    - レプリケーションのスレーブなどにデータを抽出・移管・ロードするとき
    - リカバリオペレーションのテストをするとき
  - リカバリ作業をする時プロセスが見える化され、次の情報が取得可能なことを確認する
    - 時間：リカバリにかかる時間
    - バックアップのサイズ
    - スループット：リカバリによるハードウェアへの負荷
      - 予防訓練をしてオペレーションの経験値を積む
      - 各環境用のリカバリAPIを用意したりする
      - 運用テストをする
- 想定外
  - 想定外でもリカバリで対応する可能性のあるケースを検討していく
    - オペレーションミス
    - アプリケーションのエラー
    - インフラ環境のエラー
    - OSとハードウェアのエラー
    - ハードウェア障害
    - データセンター障害
- エラーの影響範囲
  - 想定内と想定外の障害に対してどこまで影響を及ぶかを想定しておけば対応が可能になる
    - ローカルもしくはシングルノードのみ
      - 単一のオブジェクト
      - 複数のオブジェクト
      - データベースのメタデータ
    - クラスタ全体
    - データセンターもしくは複数のクラスタ全体
- 障害の重大度
  - SLO違反となる障害
  - SLO違反になりうる障害
  - SLOには抵触しない障害

7.4 リカバリ戦略の解剖

バックアップはリカバリの要件によって実行される必要がある
- 効果的な戦略は複数のシナリオに対応するだけでなく、データの破損や損失の検出、リカバリのテストとその実現性の確認も含む
計画1:問題の発見
- データ損失
- アプリケーションのエラー
- インフラのエラー
- OSとハードウェアのエラー
- ハードウェアとデータセンタのエラー
計画2:階層化ストレージ
- 効果的なリカバリ戦略を立てるために複数の階層化されたストレージを考える必要がある
  - オンラインで高パフォーマンスのストレージの場合
  - オンラインで低パフォーマンスのストレージの場合
  - オフラインストレージ
  - オブジェクトストレージ
計画3:リカバリに役立つツール
- リカバリに対してどのように対応していくか、どのようなツールが向いているかについて言及
計画4:テスト
- バックアップとリストアのテストしよう

7.5 リカバリ戦略を定義する

オンラインのリカバリ戦略(高性能なストレージの場合)
- 毎日リカバリすること
  - いざって時に備えられる
- ユースケース
  - 障害が発生したノードの置き換え
  - 新規ノードを追加
  - テスト環境に機能テスト用環境を一時構築
  - テスト環境にオペレーションテスト用環境を構築
- 問題のあるノードやコンポーネントの検知
- 環境に応じたストレージの選択
- バックアップは圧縮しない
- リカバリテストの実施
オンラインのリカバリ戦略(低性能なストレージの場合)
- 低価格だけど大容量なストレージを使える場合の戦略
- ユースケース
  - アプリケーションのエラー
  - ユーザーのエラー
  - データ破損の修復
  - オペレーションテスト用にテスト環境の構築
- データの破損が発生した場合や二次災害が発生しても大容量ストレージにバックアップを入れておけば戻せる
- 問題の早期発見し継続的に適切なバックアップとリカバリを投入する必要がある
- 環境に応じたストレージの選択
- バックアップを圧縮する
- リカバリテスト
オフラインストレージ
- 低価格で、I/Oパフォーマンスも低くなるストレージ
- ユースケース
  - 監査とコンプライアンスの環境構築
  - BGPの観点で異なる物理拠点からバックアップのコピーを持ってくる必要がある場合
オブジェクトストレージ
- S3
- ユースケース
  - アプリケーションのエラー
  - ユーザーのエラー
  - データ破損の修復

7.6 まとめ

リカバリが必要とされるケースは多く、中には予測不能な事態もある
- 全てのケースに備えられないが、バックアップとリカバリを適材適所のストレージを使用して備えておけば対応可能
- サービスレベルマネジメント、リスクマネジメント、そしてインフラストラクチャマネジメントの総合力をもってすれば対応していける
DBRE の基本にして至高の奥義 = いつもデータがリカバリ可能な状態を維持する

Sadayoshi Tada / taddy 2021/08/31に更新

8章リリースマネジメント

DBRE としてしなきゃいけない仕事
- 他のエンジニアとし協力して、開発・テスト・デプロイすること
  - 昔のDBAのようなデータベースの変更確認を行うようなことは非現実的
- 8章ではDBREがどのようにして自身の時間とスキルを活用にしてほかのエンジニアをサポートするか
  - そのためにはCI/CDを最適化することが重要

8.1 教育と協力

リリースマネジメントでまずやることはデータベースに関する教育
- データ構造、SQL、アプリケーションとデータベースのやり取りについて質問を受けることが減る
- 目指すのはDBREだけでなくエンジニアもデータベースの知識をもって決断を行えるよう方向付けること
  - 情報のキュレーターになるおこと
  - データベース議論や質問をしやすいようにする
  - 組織の固有ドメインに関する知識の共有
  - 協力関係を築く
開発からデプロイに至るフローの過程でいかに効率よくサポートできるかを意識する
- データベースのテストをデプロイサイクルに組み込むか

8.2 継続的インテグレーション

データベースを操作するコードやライブラリが更新される、データモデルを変更した、リアファクタしたとき、新しいデータセットを投入したとき、クエリの書き方を変えたときなどにビルドを走らせる
- DBRE とエンジニアがビルドに対して責任を持つ
データベースを CI に組み込む要件
- バージョン管理システム
  - インフラ構築に必要となるコードや設定
  - データベース環境の構築スクリプト
  - データベースオブジェクトの変更履歴
  - トリガ設定
  - プロシージャと関数
  - ビュー
  - 設定
  - サンプルデータセット
  - データ削除スクリプト
- データベースの自動ビルド
- テストデータ
- マイグレーションとパッケージング
- CIサーバーとテストフレームワーク

8.3 テスト

CI を仕込んだら次はデプロイになるが、デプロイは難しい
- そのためにサポートするソフトウェアがある
開発プロセスの中にテストを簡単に仕込むための施策がある
- 抽象化とカプセル化
  - コードに変更を加えたらデータへのアクセスと更新をまず最初にテストする
- 効率的にやる
  - SELECT *のようなクエリはFuture proof、つまり無駄が多くアプリケーションを危険に晒す
コミット後のテスト
- 目的は変更が正常に適用されアプリケーションが破損していないことを検証すること
- セキュリティとコンプライアンスの影響、分析とルールに基づいた検証
  - ビルド前
    - 影響範囲とコンプライアンスの観点での検証
  - ビルド
    - 変更に伴うアプリケーションが適切に動作するかの確認
  - ビルド後
    - 影響の分析と変更で発生したルール違反を示すレポートの作成
負荷テスト
- SLOを満たさないような変更になっていないかを確認する
ダウンストリームテスト
- データベースに加えた変更によって一連のパフォーマンスが悪影響を受けないことを保証するためのもの
運用テスト
- バックアップおよびリストア
- フェイルオーバー
- インフラとオーケストレーション
- セキュリティ
- キャパシティ

8.4 デプロイメント

データベースの変更による影響をパフォーマンスの観点から分析する方法
影響分析
- オブジェクトのロック
- リソースの飽和
- データの整合性
- レプリケーションの停止
マイグレーションを適用する方法
- 新規のデータ追加、変更は問題ないが既存のデータの変更に関するマイグレーションは気をつける
- ロックを必要とするような変更
- 高いリソース使用率をもたらす変更
- ローリングマイグレーション
マイグレーションを使用する時の利点はDBREのレビューと実行を待つことなく、自動承認とデプロイが可能になること
- 最低限問題が発生したら戻せるようにする

8.5 まとめ

DBRE としてチーム間のコミュニケーションや知識の共有、イベント作り、データベースに関する教育の場の設置などの活動に投資すればするほどより良い結果が期待できるようになるはず

Sadayoshi Tada / taddy 2021/09/14に更新

9章セキュリティ

セキュリティはデータベース管理者の仕事の中で重要な部分
- データを守ることは最優先事項
- データだけでなく包括的なキュリティ対策が求められる
DBREが組織やインフラに合わせてセキュリティをどのような枠組みを持って作るべきかを紹介し、セキュリティの構築や考えうる攻撃、対応策と戦略にふれる

9.1 セキュリティの目的

7章で扱ったようにデータが重要な資産であることを理解できていれば、セキュリティも同じくらい重要な要素であることが理解できる
- データが盗まれたり破損したりしたら損害は計り知れない
盗難からの保護
- データがあるところには常にそのデータに不正な方法でアクセスを試みる攻撃者が存在する
- 攻撃者が狙っているもの
  - オンラインデータベースのデータ
  - データストア間で移動中のデータ
  - バックアップやアーカイブされているデータ
  - データストアからアプリケーションやクライアントに送信されるデータ
  - アプリケーションサーバーのメモリ上のデータ
  - インターネットを通してアプリケーションからユーザーに送信sなれるデータ
- 外部だけでなく内部の場合もあるのでDBREは情報セキュリティ、運用、ソフトウェアエンジニアと協力してデータの読み取り、コピ＾ー、そして移動を適切に実施する
意図的な破壊からの保護
- 攻撃に対してはバックアップとリストアを介して回復可能なケースが多い
  - バックアップを損傷させる方がオンライでのデータを損傷するよりも簡単なことがあるのでバックアップを壊されないようにする
意図しない破壊からの保護
- うっかり間違いに対する対応
  - スキーマ、オブジェクト、行の設定が十分に安全でない場合、誰かが意図せずに損害を与えることがある
データを外部に晒さない
- 不本意に顧客のブラウザにデータを晒したり
コンプライアンスと監査の標準化
- 顧客や個人を保護するためのルールを理解して、組織を教育し、内外のセキュリティを十分に維持する

9.2 機能としてのデータベースのセキュリティ

DBREと情報セキュリティチームと協力して内外の攻撃や事故から守らないといけない
- どのようにして脅威から身を守るかを議論し、協力しt対応速を組織に浸透させていなければならない
  - チームを超えた会話の促進
  - 現場で培われるドメイン固有知識の共有
  - ペアプロミングやレビューでの協業
- データベースセキュリティに関して常に以下の教育と協業を組織に伝搬する
  - データベースアクセスの設定と管理を安全に行う方法
  - 暗号化、アクセス制御、データ管理といったセキュリティ機能を有効に使う方法
  - 攻撃を助長する情報、ログ、ディレクトリが不用意に公開されてないかどうかを調べる方法
  - 新しいCVEがリリースされたときの更新、及び他のレイヤで管理すべき必要がある脆弱性対応
- セキュリティを高めるために方針
  - ソフトウェアのバージョン番号やビルド番号取りリースノートを付き合わせ、バグが含まれていない安全なビルドを使用する
  - データベースのデフォルトのアカウントとパスワードを削除する
  - 不要なポートを解放しない
  - アクセス権限を適切に設定し不必要な権限を付与しない
  - ファイルシステムやネットワークを介してデータベースに不正にアクセス可能な機能や設定を削除する
  - SSLを介した通信を利用する
  - パスワードポリシーの確認及び適用するためのスクリプトを用意する
  - 全てのアクセスログとログ転送を行い、改竄の発見に使う
- セキュリティに関する出力の見えるか
  - アプリケーションレイヤの見える化
  - データベースレイヤの見える化
  - OSレイヤの見える化

9.3 脆弱性と悪用

Microsoftが提唱するSTRIDEという方法
- 成りすまし(Spoofing identity)
- 改竄(Tampering with data)
- 否認(Repudiation)
- 情報漏洩(Information disclosure)
- サービス拒否攻撃(Denial of service)
- 特権奪取(Elevation of priviledge)
DREAD = リスク分析と優先順位づけを行う分類方法
- 攻撃の損害範囲(Damage potential)
- 攻撃の再現可能性(Reproducibility)
- 攻撃の技術レベル(Exploitablity)
- 攻撃の影響範囲(Affected users)
- 攻撃手段の発見可能性(Discoverability)
予防策のベストプラクティス
- サービス拒否攻撃
  - サービス拒否攻撃(DoS)はリソースに大量のリクエストを投げてサービスやアプリケーションを利用できることを目的とした攻撃
  - 対策
    - 標準的な対策、オートスケールなど別のアプローチもある
      - ただ上りソースは限にたっする
  - リソース管理と負荷制限
    - どのようなふかがたくなるのかを理解する
  - 継続的な改善
    - データベースレイヤーの重いクエリを撲滅するためにDBRE、SWEが一丸となって対応する
      - 重いクエリを探し出してチューリングする
  - ログとモニタリング
    - ちゃんとモニタリング
- SQLインジェクション
  - データベースのコード、SQLをアプリケーションの入力情報としてそのまま渡す攻撃方法
  - SQLインジェクションでバッファオーバーフローによってDBを落としたり、DB-DoS攻撃を実行してデータベース、OSレベルでの高い特権を奪取される可能性がある
  - 対応策
    - クエリをテンプレートから生成する
    - 入力値のバリデーション
    - アプリケーション側でもできる限り防御する対応を行う(パッチ適用、不必要なストア度コード、データベースユーザーも削除)
- ネットワークと認証プロトコル
  - TCP 1433のセッションを開始する"hello"を利用したバグで、プロトコルの脆弱性を突いた攻撃が報告されている
    - 一部のサーバーは暗号化されていない通信を許可しているため、資格情報を盗まれて使用される可能性がある
  - 攻撃を軽減する施策はデータベースの攻撃経路と可能性を軽減する
    - 認証プロトコルとデータベースの機能について深く理解することができれば、攻撃に対して十分に安全な設定を施すことができる

9.4 データの暗号化

暗号化とは一連の鍵または秘密情報を使用してデータを変換するプロセス
- データが不正にアクセスされて盗まれたら暗号化がデータを守最後の砦
  - 転送中のデータ
  - データベースクライアント上のデータ
  - ファイルシステム上のデータ
DBREは情報セキュリティ、ソフトウェアと連携して機密データを守る
- 財務情報
- 個人情報
- 健康情報
- 軍や政府の情報
- 機密及び部外秘の情報
送受信中のデータの暗号化
- 内部
- 外部
- 暗号化通信を使って安全な通信を確立する
  - SSL/TLS
  - 証明書通信
- データ保管時の暗号化
データベースクライアント上のデータ
データベース専用のプラグインを使って暗号化
セキュリティアプライアンスをを使った暗号化
- 暗号化したらクエリのパフォーマンス落ちるかもしれないのでみていく必要がある
- 最終的にはデータはファイルシステム上に置かれるので、ファイルシステムの暗号化をみていく
ファイルシステム上のデータ
- ファイルシステム上のデータの暗号化
- ファイルシステムそのものの暗号化
- デバイスレベルの暗号化

Sadayoshi Tada / taddy 2021/09/25に更新

10章ストレージ、インデックス、レプリケーション

単一ノードにおいてデータを格納する方法、大規模なデータセットを分割して格納する方法、及び複数ノードにおいてデータをレプリケーションする方法について触れる

10.1 データ構造のストレージ

データベースがどのようにデータを格納しているかを理解する場合、生データの格納と取得の両方を考えなければならない
リレーショナルデータベースのデータはブロックもしくはページに格納される(以下ブロック)
- ブロックはレコードを格納する最小単位
多くのデータベースはデータをバイナリツリー(BTree)のフォーマットで構造化している
- データが増えてもバランシング(2分検索)する性質を持っているからデータブロックの読み書き、ファイルシステムやデータベース向けの構造
データベースのブロックサイズにも気をつける
バイナリーツリーが持つ特性と利点
- 範囲ベースのクエリに対して高パフォーマンスである
- 単一行ベースの検索に対しては最も理想的なモデルというわけではない
- ソートされたキーに対しては検索と範囲スキャンは効率的に実施できる
- 大規模データセットにおいてページの読み込みを最小に抑える
- ページごとにキーを格納する必要がないので削除と挿入が効率的に実施できる
- バイナリツリーがメモリに全て載る場合は、良いパフォーマンスを発揮する
インデックスの生成
- ハッシュインデックス
- ビットマップインデックス
- バイナリツリーにおける並び替え
  - 関数ベースの並び替え
  - 逆インデックス
  - クラスタリングされたインデックス
  - 空間インデックス
  - サーチインデックス
ログはデータベースの冗長性維持のために使っていたが、可用性やスケーラビリティの確保のためにデータをレプリケーションする場面でも使われるようになった

10.2 データのレプリケーション

DBREはレプリケーションのメソッドを理解し、どのようにレプリケーションが動作するかを把握することが大事
レプリケーションはアプリケーションから書き込みを要求されるリーダーノード、リーダーに付随してデータの提供を受け、それを適用するフォロワーとなるノードに分かれる
- 単一リーダー：データは特定のリーダーに送られる
  - 単一リーダーで保証されること：コンフリクトはなくデータの一貫性が保たれる、ノードで実施されたおpレーションに対して同じ結果が保証される
  - レプリケーションの構成：非同期(レイテンシ>耐障害性)、同期(レイテンシ<耐障害性)、準同期(レイテンシ=耐障害性)
  - レプリケーションに使うトランザクションログ：ステートメントベースのログ、redolog
  - レプリケーションパターン：行ベース(CDCメソッド)、ブロックレベル(分散ブロックデバイスレプリケーション)
  - 可用性：障害が発生したらリカバリできるようにする
  - スケーラビリティ：
  - ローカリティ
  - シングルレプリケーションの課題：
    - MTTRを維持してバックアップ戦略を作る必要がある
    - レプリカの同期を維持：レプリカラグが発生するとSLOに影響与えるかもしれないので見ておく
    - フェイルオーバー
    - レプリケーションのプロセス
- 複数リーダー：リーダーの役割を持つノードが複数あるため、複雑さがある
  - 可用性
  - ローカリティ
  - ディザスタリカバリ
- リーダー不在：全て書き込み
どこからでも書き込み可能なレプリケーション
- リーダーはない
- DynamoDBに影響を受けたシステム(Riak/Cassandra/Voldemort)
- 共通の仕様
  - 結果整合性
  - 読み込みと書き込みの定足数
  - 反エントロピー

Sadayoshi Tada / taddy 2021/10/12に更新

11章データストアフィールドガイド

データストアとはデータの保存場所として機能し、データ構造を修正、保存するソフトウェア
フィールドガイドとは多種多様なデータベースの特性を明らかにし、各データベースを使用すべき時と場所、適切な設定と運用方法を提供する
本章ではデータベースの属性とカテゴリを定義 -> カテゴリについてアーキテクトや運用チーム向けの考察に移る -> 自分たちに合うデータベースをさがる

11.1 概念としてのデータストアの属性

関わる人によってデータベースの活用方法は関わる
- ORMやサーバーレスではデータストアが高度に抽象化される(ユーザーは深い理解なくてもただ使えればいいという考えもあるが、それは賛成できない)
データモデル
- データストアでデータがどのように構造化され、リレーションがどのように管理されるかはアプリケーションにとって大事
  - データベース管理的にも大事
- 4つのモデル：リレーショナル、キーバリュー、ドキュメント、ナビゲーション/グラフ
- リレーショナル(Oracle,MySQL,DB2,SQLServer,Google Spanner,Redshift,NuoDB,Firebird)
  - データが一連のリレーションを持ち任意のデータはユニークなキーによって一意に特定可能
  - データの整合性：テーブルの制限、カーディナリティ、値、属性
    - => 複数テーブルを横断したリレーションを実現していたり、データの矛盾や重複を排除し、データの独立性を維持するグループ(正規化)
  - 検索：join,一対多、多対多をサポートすることで開発者はデータモデルに高次元なレベルで柔軟性を持たせることが可能
    - 同時にスキーマの追加や修正やテーブル、リレーションそして属性の削除といった広範囲に及ぶ調整が必要な操作も可能になる
- キーバリュー(DynamoDB,Cassandra,Riak,Voldmort)
  - データをディクショナリもしくはハッシュとして保存する
    - オブジェクトのデータのBlobとして捉え、データの中身をみていないためオブジェクトによって異なったフィールドやネストされたオブジェクトなどバリエーションが多い
  - 整合性：バリエーションが多い分生合成の点で問題になる
  - データの型による効率性、インデックス付けもdけいない
    - 異なる型、制約、リレーションを管理不要なのでアプリケーションが区別なく使える
- ドキュメントモデル
  - キーバリューから派生したのがドキュメントモデルで、ドキュメント構造のメタデータを管理する点が異なる
    - データ型に最適化、セカンダリインデックスなどの最適アを可能にしている
    - 1度の呼び出しで全てのデータを取得できるため、マシンパワーはかなり必要。ORMレイヤの必要はなくなる。
    - 整合性はリレーショナルと変わらない
  - ナビゲーションモデル
    - 最初は階層的でネットワーク状のデータベースからスタートし、グラフデータモデルのことを指すようになった
トランザクション：データベース内部で実行される一連の作業であり、それ以下に作業を分割できない
- データベース整合性を維持するために、必ず実行もしくはロールバックされなければならない
  - 上記できるとアプリケーション側はエラーハンドリングのロジックを単純にすることができる
- トランザクションモデル：ACID
  - アトミック性、整合性、分離性、永続性
    - アトミック性：トランザクション全体のコミット、書き込み、トランザクション全体のロールバックを保証する
      - ソフトウェアエンジニアリングでいうものとは性質が異なる、並行で現在実行中状態であるプロセスからの分離を保証する
    - 整合性：どのようなトランザクションであってもデータベースの状態をある状態から別の状態に確実に移行できること
    - 分離性：トランザクションが並列実行されても同じ状態の結果になること
      - 連続して順次実行されても同じ状態の結果になれば、分離性が保証されてる
      - 書き込みロック、リアルロック、スナップショットの組み合わせを駆使して分離性を実現(並行性コントロール)
      - 3つのレベル：ダーティリード、ノンリピータぶるリード、ファントムリード
      - 上記の3つのレベルの問題に対して4つの分離レベル：リードアンドコミッテド、リードコミッテド、リピータぶるリード、シリアライズ
    - 永続性
      - トランザクションがコミットされ、コミットされたままであることを保証するのが永続性
      - 多くのデータベースがWAL(write ahead log)を実装し、変更をディスクにプッシュする前に書き込みログをキャプチャするようにしている
        
        このログはトランザクションログやリドゥする時に使う
    - DBREはACIDを理解しておき、開発組織にも価値がある
      - Jepsen/Hermitageツールを使って理解するのもあり
      - トランザクションに関する知識を見つければどのような設定が利用可能であり、その中で最適な設定は何か、サービスに応じて取捨選択できる
      - サービスによってある程度緩やかな永続性や分離レベルでもよかったり、データベースの設定がアプリケーションが想定するデータベースに適しているかを判断できる
BASE
- 基本的に利用可能、厳密でない状態、結果整合性 = BASE とは非トランザクションシステムに焦点に当てており、分散システムや非慣習的なレプリケーション、同期について定義する
  - ACIDとは異なり、システムが稼働済みでトラフィックを受けている時の名家かうな状態はなく、トランザクションに対する平衡性コントロールをなくして書き込みのスループットや並行処理を劇的に上昇させる代わり、アトミック性、分離レベル、整合性を犠牲にしている

11.2 データベースの内部特性

データベースをカテゴリ分けする方法は無数にあるためデータベースの選択ではその内部実装を理解した選択が必要
- ストレージ：データの読み書き、ロック、並行アクセスをはじめとするデータ構造を管理する
  - データ構造はBツリーインデックス、LSM(RocksDB)、ブルームフィルタ
  - ストレージエンジンの特性：書き込みのパフォーマンス、読み込みのパフォーマンス、書き込みの永続性、ストレージサイズ
- CAP定理：分散コンピューティングのデータ複製における定理。一貫性と可用性のトレードオフを理解するための定理
  - データ複製において一貫性、可用性、分断耐性の2つを満たすことはできるが、3つ全て満たせない
  - ACIDのCとCAPのCは一緒ではない
- 分散データベースのノードにデータを書き込む場合、一貫性がハンたんする機会がある
  - 防ぐにはPaxosのように書き込みのzyん版を効率的にコーディネートするプロセスが必要になる
    - でもトランザクションのレイテンシを増加させる
  - 読み込みの場合もタイムアウトが発生した場合、リトライするとその分レイテンシが増加する(これもトレードオフ)
  - ノードが所属するネットワークが混雑するとレイテンシがます(レプリケーションとレイテンシのトレードオフ)
    - 準同期もしくはレプリケーション設定を変える
  - トレードオフを理解してレイテンシと可用性をどっちを巡視するかによってチューニングする必要がある
可用性
- 分散システムの可用性を議論するには処理能力と処理結果という用語が効果的
  - 前者はリクエストを処理できる能力、後者は結果のデータセット
    - 障害に対して処理能力を減らすのか、処理結果を減らすのかというアプローチ
  - ノードの25%ダウンしても処理結果が75%になることを許容するかどうか
  - 処理結果が大量の検索ならOKだが、より高い耐障害性を持つことになりCassandraを例にするとレプリケーションファクタを減らせることになる
- 処理結果がほぼ100%に維持しなければならない場合、レプリケーションファクタを増やしてより多くのれぷりkが必要になるだけでなく、アベイラビリティーゾーンをも用意してレプリカを配置する
アプリケーションを分割する場合も同じで機能単位での分割、マイクロサービス化にせよ、分割した探知で障害が発生してもその障害を分割した単位に閉じ込めたり、他のシステムに影響を及ぼさないようにせんといけない

まとめ

本章で扱った内容が理解できて扱えるようになればアプリケーションのパフォーマンスや機能の責任を担うエンジニアやアーキテクトは興味を持ち、運用チーム側は特性を理解し、それがSLOを満たすためにどのように役立つかに焦点を当てる
次はデータベースアーキテクチャとパイプラインについて

Sadayoshi Tada / taddy 2021/10/18に更新

12章さまざまなデータアーキテクチャ

12.1 アーキテクチャのコンポーネント

データベースのコンポーネントを理解して使いこなすのはDBREの業務の1つ
- コンポーネントの1つ1つがデータベースの可用性、データ整合性、一貫性それぞれに確かな影響を及ぼす設計、運用に気にかける
フロントエンドデータベース
- ユーザーはアプリケーションのデータ操作レイヤを通してデータのクエリ、挿入、変更操作を行うため、常に利用可能なものとして設計される
  - つまり、フロントエンドデータベースがダウンすると顧客のサービス体験に直接影響を与える
  - OLTP
- 特徴としてはユーザー自身によってデータが追加されること
  - OLAPとも呼ばれる
- フロントエンドデータベースの仕様
  - 低いレイテンシでの読み込みと書き込み
  - 高い可用性
  - 短い平均復旧時間
  - 高いスケーラビリティ
  - アプリケーションと運用側サービスとの連携が容易であること
アプリケーションはビジネスロジックとそれを実現するプレゼンテーションレイヤに分けて実装されることが多い
- ビジネスロジックはデータアクセスレイヤ(DAL)としても知られている
  - アプリケーションがデータベースにアクセスし、読み込みや書き込みを行うための方法を提供する(実態はクエリやストアドをメソッドとして利用可能な一連のオブジェクト郡)
  - DALの一例はデータアクセスオブジェクト (DAO)の使用
    - DALの別の例はORMがある
データベースのプロキシ
- プロキシレイヤはアプリケーションサーバーとフロントエンドデータベースの間にある
- レイヤ4
  - 特定のアルゴリズムに基づいてリクエストを分散することが可能であるが、負荷状況やレプリケーションラグを考慮した動きはできない
- レイヤ7
  - TCPパケットに含まれる多くのデータを参照することができ、データベースプロトコルやルーティングプロトコルにもたいおうできる
  - 他の特徴
    - バックグランドのサーバーへヘルスチェックを実行し、リクエストをヘルシーなサーバーへリダイレクト
    - 読み込みリクエストはレプリカに書き込みリクエストはますたに送るといった種別ごとに分散する
    - コードでチューニングが不可能なクエリを書き換えて最適化する
    - クエリ結果をキャッシュする
    - トラフィックをラグが少ないレプリカにリダイレクトする
    - クエリのメトリクスを生成する
    - クエリタイプやホストごとにファイアーウォールとしてのフィルタを実行する
  - 上記の特徴はトレードオフ = レイテンシとなり、長期的には技術的負債になるかもしれない
- 可用性
  - ここではプロキシレイヤが耐障害性を備えた構成と仮定
  - プロキシを使うことでMTTRを減らせる
- データの統合性
  - プロキシの役割的にレイヤ7ならラグが大きいレプリカをサービスから除外する
    - ラグが大きく同期が追いついてないレプリカはアプリケーションに最新ではない少し前の古い結果を返す可能性があるため、その可能性を潰す
  - プロキシ配下のノードが多い時はキャッシュを有効にする方法もある
- スケーラビリティ
  - プロキシレイヤが効果的に構築した場合、スケーラビリティは劇的に向上する
    - 読み込みリクエストを複数のレプリカに分散する(プロキシアガナイト負荷分散は単純な振り分け、ラグの状態をチェックできないため分散機構がお粗末になる)
  - プロキシレイヤがスケーラビリティの向上に寄与しているのが負荷の分割
    - 大量の並行コネクションをキューのように扱い、配下のデータベースサーバーが許容な可能な最大接続数に応じて分割する
- レイテンシ
  - レイヤ4なら全体のトランザクションのレイテンシは少なくて済むが、レイヤ7は非常に大きくなる
    - クエリのキャッシュ、負荷が大きいサーバーへの振り分け停止、クエリの書き直し
    - シンプルなアーキテクチャを保つ
イベントとメッセージシステム
- トランザクションはイベントであり、そのイベントと連動して実行されるべきアクションがあるということでそのイベントの例
  - データベースと連携している分析システムやリポジトリとの同期を取るアクション
  - アクションごとの順番を保持するアクション
  - トランザクションの内容が詐欺に関わるものでないかをチェックするアクション
  - キャッシュやCDNにデータをアップロードするアクション
  - 個人情報に関わるデータを加工するアクション
- メッセージシステムの実装例：Apache Kafka(分散キューを構成)
  - プロデューサー、コンシューマ、トピックそれぞれのレベルで水平方向でかなりのスケーラビリティを誇る
  - これらのメッセージングシステムはデータストアに追加される新規データを継続的もしくは定期的にポーリングし、データのETLを行う
可用性
- イベントシステムはデータストアの可用性を向上させる作用がある
  - キューを利用したイベントのエンキューとデキューを利用することで読み込みと書き込みの両方に対応できる
  - 同時にリソースの最適化と同時並行性の負荷を減らすことでコアとなるサービスの可用性を向上させる
データの統合性
- システム間のデータの受け渡しでのリスクの1つにデータの破損と損失がある
  - データの損失を避けるためにコンシューマはキューの中のデータのコピー作らないとコンシューマの監査プロセスはオリジナルデータの比較ができない
  - イベントやメッセージを保持するストレージのメカニズムがメッセージのライフサクるで一貫性を保持できるようになっているかも検証しておくことも大事
スケーラビリティ
- メッセージキューに入れたイベントをのその都度取り出して連続して処理するようになればデータベースの負荷が減少する
レイテンシ
- フロントエンドのデータストアからイベントを取り出して処理するのは潜在的に発生するコンフリクトを減らし、アプリケーションのレイテンシを減らすことにもつながる
- が、データストアにイベントを格納し、取り出すことは追加のレイテンシも発生している
キャッシュとメモリストア
- 予算があればメモリが十分なデータベースで
  - データベースのデータをキャッシングシステムとインメモリデータストアの使用もあり
- 可用性
  - キャッシュにより可用性を向上できる
    - メインのデータばエースが障害で落ちていても残存するキャッシュを使用することで読み込みリクエストに答えられる
      - 読み込みのキャッシュの可用性はメインデータベース同様に大事
- データの統合性
  - キャッシュされたデータの統合性は常について回る問題
    - オリジナルのデータベースに更新チェックをかける頻度と古いキャッシュによってクエリに最新ではない結果を返してしまう可能性とのトレードオフをはかる
- スケーラビリティ
  - キャッシュやインメモリを使うのは読み込みの負荷をスケールできるからで、複雑性は増すもののスケーラビリティを得られる
    - キャッシュを使うことでSLOを順守するために新たな依存関係ができる
      - 障害や利用不能になるとSLOに違反する
- レイテンシ
  - スケーラビリティのほかにキャッシュを使う理由の1つにレイテンシがある
    - キャッシュを追加することでリスクを受け入れる必要があり、DBREとしてはコンポーネント追加にまつわる潜在的リスクやアーキテクチャの複雑性を十分に考慮する

12.2 データアーキテクチャ

データドリブンシステムで、アーキテクチャによってデータの収集、処理、受け渡しの方法は異なる
- アーキテクチャの基本思想、想定利用方法、トレードオフに由来
LambdaとKappa
- Lambdaはリアルタイムな大規模データ処理アーキテクチャで、KappaはLambdaと似ているけどシンプルさを追求したアーキテクチャ
- Lambda アーキテクチャの特徴は大量データをほぼリアルタイムで素早く捌く一方、長い時間を要する処理への対応も両立して実現している(3つのレイヤ：バッチ処理レイヤ、リアルタイム処理レイヤ、クエリレイヤ)
- リアルタイム処理レイヤがあることでクエリに対して低いレイテンシで素早く結果を返せる利点
  - 入力データが変更されずにますたのデータセットに格納される点も利点
  - 2つの異なるコードベースを保守していかなければならないのが短所(リアルタイム処理とバッチ処理)
    - 今日ではレイヤを分ける必要がないという意見もある
- Kappaはデータストアは追加書き込みのみのイミュータブルなデータとされ、Kappが使用される
  - Lambdaのバッチレイヤをなくしてストリーミングシステムがデータの加工からクエリへの応答まで担う
- KappaのメリットはLambdaからバッチ処理レイヤをなくして2つのレイヤ管理がもたらす運用や管理の複雑を解消している
イベントソーシング
- イベントソーシングアーキテクチャではエンティティへの変更は一連の状態変化の集合として扱われる
  - 一連の状態変化が発生すると新しいイベントがログに追加される
  - 従来のリレーショナルやキーバリューなどのデータストレージはステートフルな複数の値を上書きできるが、イベントソーシングはイベント単位でデータ管理することでいくつかある従来のデータストアの欠点を補う
- イベントソーシングがもたらすメリットはエンティティのライフサイクルが極めてシンプルに追跡可能、デバッグやテストがやりやすい
CQRS
- イベントストアは補助的なストレージを抽象化したがそこからさらにコアデータストレージレイヤへと進化させたのがCQRS(コマンドクエリ責務分離)
- CQRSはともすると不必要なほど複雑になってしまう可能性がある
  - 1つのビューで良かったところを無駄に分離したビューにしてしまった、本来必要なビュー以上に過度に分離してしまったということもよく起こる

まとめ

データドリブンなアーキテクチャのポイントはライフサイクルを理解し、適切なストレージを見つけること
- システムの各コンポーネントにそのデータを効果的に届けること
コアとなるデータセットを統合し、破綻させないようにする一方でデータは複数の方法で閲覧や表示することが求められる

Sadayoshi Tada / taddy 2021/10/24に更新

13章 DBREの実践

DBREの文化を組織に導入し、どう適合させていくかを説明する

13.1 データベースリライアビティ文化

リライアビティ文化とは何か
- 非難なしのポストモーテム
- 繰り返し作業を自動化
- 構造化かつ合理的な意思決定
DBREはサービスに関わる全てのチームを横断しての貢献が必要
- データベースエンジニアがチームの枠を越えるのは難しいところもある
アーキテクチャへの関与はやるべき
- 設計段階で適切なデータベースを選択し、本番前にテストを行うことが理想
- ストレージの選定も
  - Tier1 ストレージ
    - プロダクション環境で事前テスト済み
    - コアサービスが対象
    - SLA に対して15分以内のレスポンスを提供し、可用性・レイテンシ・スループット・耐障害性を最高レベルのSLA(SLO?)で保証
  - Tier2 ストレージ
    - コアでないサービスが対象
    - SLA に対して30分以内のレスポンスを提供し、可用性・レイテンシ・スループット・耐障害性をやや低いレベルのSLOを保証
  - Tier3 ストレージ
    - プロダクション環境でのテストしない
    - SLOに対する保証はない
      - ソフトウェアエンジニアチームによってサポートされなければならない
- リライアビティ文化の浸透しているかの指標
  - どれだけDBREと一緒に仕事しているか,承認したテンプレートを使用しているか
  - どういったストレージが使用されてデプロイされているか
  - プロジェクトの各フェーズにおいてDBREが関わった時間はどれくらいか
  - リライアビティの証拠となる可用性、スループット、レイテンシといったメトリクスの指標がレベルやエンジンごとにグルーポングされ共有されているか
データベース開発
- 開発の初期段階でデータベースの設計にも携わることができればプロジェクトの成功に大きく貢献することができるはず
  - ただSWEがデータベースの設計についてDBREと話すべきという考えを持っていないと難しい
    - 最終的にDBREと一緒に仕事をして良かったと思われること
  - SWEとDBREの間で浸透されてるかの指標
    - 開発においてSWEとDBREが一緒に仕事した時間はどれくらいか
    - DBREから提案されたユーザーストーリを使用しているか
    - レイテンシや耐障害性といったメトリクスがDBREにも共有されているか
    - オンコールシフトにDBREだけでなくSWEも関わっているか
プロダクション環境のマイグレーション
- マイグレーションによる変更の管理としてSWEにDBREが策定したプロセスとツールを示して使ってもらうのが良い
  - 改善の一歩はマイグレーションによる変更が安全化危険なのかを発見するライブラリを少しずつ作成する
  - SWEチームの自主性を可能な限り重んじる
    - DBREがマイグレーションパターンを作ってSWEに最新の変更を適用してもらう
  - その他ペアプロ、ワークショップ、勉強会、ドキュメントなどもやる
    - 上記をやっていければ組織全体にリライアビティへの意識が浸透していくはず
  - プロダクション環境のマイグレーションへのリライアビティへの意識がどれほど浸透しているかを測る指標
    - SWE/Ops/DBREが一緒に作業した時間はどれくらいか
    - 全体のマイグレーションのうちDBREが必要とされたマイグレーションはどれくらいか
    - マイグレーションの成功及び失敗、およびその影響範囲はどれくらいか
インフラ設計と開発
- 理想の実現のために組織内で信用を積み重ねる必要がある
  - DBREチームが組織において有用であると示す
    - そのためにバージョン管理システムでスクリプトや設定ファイル、ドキュメントを積み重ねる
    - オペレーションチームと一緒に管理ツールを用いてからのデータベースの設定と構築を行い、インフラ構築の自動化を進める
    - 最終的にはオペレーションチームやインフラを管理しているエンジニアにオンコールで対応をお願いするようになる
  - この点でのリライアビティ意識の浸透を測る指標
    - 設定管理ツール経由で構築されたインフラコンポーネント数
    - オーケストレーションツールに統合されたインフラのコンポーネント数
    - プロビジョニングの成功及び失敗の数
    - データベースを使用しているシステムのリソース消費量を可視化したメトリクス数
    - DBREでないスタッフによるシフト数
    - DBREではないスタッフによるインシデント発生数とMTTR
    - DBREエスカレーションされた問題数
データドリブンな意思決定
- ファクトベースで意思決定できるようなわかりやすいメトリクスとダッシュボードを示す
- データドリブンな意思決定を重視する組織に身を置き、データの収集と分析からデータ活用の規範作りまで実装できればDBREは動きやすい
- SLOとメトリクスを実装すれば組織が理想
データ整合性とリカバリ力
- リカバリーはDBREだけでは実現できない
  - SWEチームにデータの検証のためのパイプラインとリカバリ用APIの重要性を理解してもらい、開発リソースを割いてもらう
  - アーキテクチャやソフトウェア開発においてチームの壁を破って知見を共有する
    - 上記の活動はむずい...ほとんどのSWEはデータの整合性はDBREの守備範囲であり、自分は関係ないと考える人が多い
      - 過去の問題を集めて手動のリカバリマニュアルを読み解いて自動化を行うことでリライアビティの実現に近づく
      - 進化は少しずつ、けれども確実に組織全体を変える

このスクラップは2021/10/26にクローズされました

はじめに

やり方

１章 イントロダクション

1.1 DBREの指針

1.2 オペレーションの本質

1.3 欲求段階説

Estyの防御壁の設定

参考

所感

話してみたいこと

雑談で話したリンク

2章 サービスレベルマネジメント

2.1 SLO の必要性

2.2 SLO の指標

2.3 サービス目標の定義

2.4 SLOに基づいた監視とレポート

所感

話してみたいこと

雑談ネタ

3章 リスクマネジメント

3.1 リスク評価

3.2 どうすればいいか

3.3 してはいけないこと

3.4 実際の作業：はじめの一歩

3.5 改善のサイクル

雑談したこと

雑談した時のリンク

4章 オペレーションの見える化

4.1 現在の見える化の標準仕様

4.2 OpViz フレームワークの構築

4.3 データの入力

4.4 データの出力

4.5 監視の大一歩

4.6 アプリケーションの計器

4.7 サーバーやインスタンスの計器

4.8 データベースの計器

雑談

5章 インフラストラクチャエンジニアリング

5.1 ホスト

物理サーバー

5.2 仮想化

5.3 コンテナ

5.4 DBaaS

雑談

6章 インフラストラクチャマネジメント

6.1 バージョンコントロール

6.2 データベースインフラ設定の定義

6.3 データベースインフラ設定とビルド

6.4 データベースインフラ設定の管理

6.5 インフラストラクチャ定義とオーケストレーション

6.6 テストとコンプライアンス

6.7 サービスカタログ

6.8 すべてを1つに

6.9 開発環境

6.10 まとめ

7章 バックアップとリカバリ

7.1 基本的原則

7.2 リカバリ考察

7.3 リカバリシナリオ

7.4 リカバリ戦略の解剖

7.5 リカバリ戦略を定義する

7.6 まとめ

8章 リリースマネジメント

8.1 教育と協力

8.2 継続的インテグレーション

8.3 テスト

8.4 デプロイメント

8.5 まとめ

9章 セキュリティ

9.1 セキュリティの目的

9.2 機能としてのデータベースのセキュリティ

9.3 脆弱性と悪用

9.4 データの暗号化

10章 ストレージ、インデックス、レプリケーション

10.1 データ構造のストレージ

10.2 データのレプリケーション

11章 データストアフィールドガイド

11.1 概念としてのデータストアの属性

11.2 データベースの内部特性

まとめ

１章イントロダクション

2章サービスレベルマネジメント

3章リスクマネジメント

4章オペレーションの見える化

5章インフラストラクチャエンジニアリング

6章インフラストラクチャマネジメント

7章バックアップとリカバリ

8章リリースマネジメント

9章セキュリティ

10章ストレージ、インデックス、レプリケーション

11章データストアフィールドガイド

12章さまざまなデータアーキテクチャ