信頼できるデータベースの設計。 第1章はじめに

第1章はじめに

この本の目的は、真のエンジニアとして真の信頼性エンジニア（DBRE）になるための開発に関するガイダンスを提供することです。 本のタイトルでは、管理者ではなくエンジニアという言葉を具体的に使用しました。



Ben Trainor（Googleエンジニア）は、このアクティビティを次のように説明しました。



基本的に、これは運用チームによって歴史的に実行されてきた作業ですが、ソフトウェア設計の経験を持つエンジニアの関与、および人間の労働を自動化する欲求と能力を伴います。



今日、プロのDBAは管理者ではなくエンジニアでなければなりません。 構築して作成します。 DevOpsの原則に従って、私たちは全員同じ船に乗っており、「エイリアン」の問題はありません。 エンジニアとして、知識と専門家の判断を適用して、データウェアハウスとデータ構造を設計、構築、使用します。 DBREとして、私たちは他の人よりも多くの基本原則と深い知識を適用しなければなりません。



今日の非ストレージインフラストラクチャを見ると、プログラムによって、また多くの場合自動的に簡単に作成、実行、および破壊されるシステムが表示されます。 これらのコンポーネントのライフサイクルは、数日または数分で計算できます。 一方が消えると、他の人が代わりに表示され、必要なレベルでサービスの品質を維持します。



次の目標は、信頼性の高いシステムとDevOpsカルチャを設計するというパラダイムで、データウェアハウスの設計、構築、管理の原則と実践を習得することです。 この知識は、組織の開発の任意の段階で作業するように依頼された任意のデータベーステクノロジーに適用できます。

DBREガイドライン

この本を書き始めたとき、私たちが最初に問いかけた質問の1つは、DBA専門職の開発の新しい段階の根底にある原則は何かということでした。 データウェアハウスの設計と管理のアプローチを再定義する場合、サポートする動作の原則も定義する必要があります。

データ保護

従来、データ保護は常にDBAプロフェッショナルの中心的な教義でした。 通常、目標は以下によって達成されました。

• DBAと開発者間の職務の厳密な分離。
• 定期的にテストされたバックアップおよびリカバリ手順。
• 定期監査を伴うセキュリティ手順。
• 信頼性と安定性が保証された高価なDBMS。
• すべてのコンポーネントのフォールトトレランスを備えた高価なストレージシステム（SHD）。
• 変更および管理タスクの広範な制御。

一緒に仕事をすることに慣れているチームでは、職務の厳密な分離は負担になるだけでなく、開発のブレーキにもなります。 第8章「リリース管理」では、「セーフティネット」を作成し、職務分離の必要性を減らす方法について説明します。



アーキテクトとエンジニアは、これまで以上に、たとえばOracleと同じ信頼性を保証できないオープンソースDBMSを選択しています。 これにより、パフォーマンスとスケーラビリティの利点が得られる場合があります。 適切なDBMSの選択と、この選択の結果の理解については、第11章で検討します。さまざまなツールが存在し、それらを効果的に選択できることがすぐに標準になりつつあります。



ストレージサブシステムも大幅に変更されています。 システムが頻繁に仮想化される世界では、データベース管理システムの設計にネットワークと一時的なデータストレージシステムが使用されます。 これについては、第5章で後述します。

エフェメラルストレージシステム上のデータベースとの戦闘。



2013年に Pinterestは、MySQLデータベースを一時的なAmazon Web Services（AWS）ストレージシステムに移行しました。 一時ストレージとは、仮想マシンがクラッシュまたはシャットダウンした場合、ディスクの内容全体が消えることを意味します。 Pinterestは、一貫して高い帯域幅と低いレイテンシを実現するため、一時ストレージを選択しました。



このような選択には、自動および鉄筋コンクリートのバックアップへの多大な投資と、ストレージサブシステムなしで短時間実行できるコンピューティングノードの能力の両方が必要でした。 エフェメラルストレージシステムはスナップショットをサポートしていないため、トランザクションログをスナップショットにロールするのではなく、ネットワーク経由で完全バックアップをコピーすることが唯一の復旧方法でした。



この例は、適切な方法とツールを使用して一時ストレージのデータを管理することが安全であることを示しています。

データ保護の新しいアプローチは次のようになります。

• データの責任は職域を超えたチーム間で共有されます。
• DBREチームが使用する規制された自動化されたバックアップおよび復元プロセス。
• DBREおよびセキュリティチームによって適用される規制されたセキュリティポリシーとセキュリティ手順。
• すべてのポリシーが自動的に適用されます。
• データ要件とフォールトトレランスにより、DBMSの選択が決まります。
• 高価な洗練された機器の代わりに、自動プロセス、一般的な慣行、およびフォールトトレランス。
• テスト、ロールバック、および緩和に特に注意を払って、変更が展開に組み込まれます。

スケーラビリティのためのセルフサービス。

才能のあるDBREは、確かにサイト信頼性エンジニアよりもまれな製品です（SRE、「Googleのサイト信頼性エンジニアリング」という本への参照です）。 ほとんどの企業は、1つまたは2つ以上を維持する余裕はありません。 そのため、可能な限り多くの価値を生み出さなければなりません。これは、セルフサービスプラットフォームを作成することによって達成されます。 標準とツールに基づいて、チームは仕事で過負荷のDBAに頼ることなく、新しいサービスを立ち上げ、必要な速度で変更を加えることができます。 セルフサービス方式の例：

• データウェアハウスから適切なメトリックを収集します。
• 新しいデータウェアハウスに展開できるバックアップおよび復元ツールを作成します。
• 参照アーキテクチャとデータウェアハウス構成の定義。
• セキュリティ部門と協力して、データウェアハウスの標準を定義します。
• 予備テストにより、データベースへの変更を安全に適用するためのメソッドの作成。

言い換えれば、効果的なDBREは、監視員として働くのではなく、他の人を導くことで他の人を助ける。

ハードワークを取り除く

GoogleのSREチームは「Googleのサイト信頼性エンジニアリングの第5章」で説明されているフレーズ「Eilmination of Toil」をよく使用します。 本書では、ハードワークとは、戦闘サービスの立ち上げに関連する作業として定義されています。これは、手動で繰り返し可能になり、自動化の可能性があり、持続可能な価値がなく、サービス自体の成長に比例して成長する傾向があります。



DBREチームを苦労から救うには、効果的な自動化と標準化が必要です。 この本では、DBREに特有のハードワークの例と、それを取り除く方法を示します。 もちろん、ハードワークは曖昧な概念であり、人によってさまざまな偏見があります。 この本では、手動の非創造的作業として定義します。これは繰り返され、脳の作業を必要としません。

データベースの手動変更。



データベースエンジニアの多くのクライアントは、変更を確認してデータベースに適用するよう求められます。これには、テーブルやインデックスの変更、データの追加、変更、削除が含まれる場合があります。 DBAがこれらの変更を適用し、結果をリアルタイムで監視することは誰もが確信しています。



あるクライアントでは、データベースにこのような変更が多数ありました。 私たちは、週20時間が申請に従事しているという結論に達しました。 言うまでもなく、彼の勤務時間の半分を単調な仕事でなくしていた不幸なDBAは病気になり、去りました。



手が足りなかったため、管理者は最終的にDBAチームが開発者ツールを作成して、管理者の1人が表示して承認した後、変更パッケージの適用を自動化することができました。 まもなく、誰もが新しいツールを信頼するようになり、DBREチームはこれらのプロセスを展開プロセスと統合することに集中できるようになりました。

データベースは特別な雪片ではありません

私たちのシステムは、ビジネスのニーズを満たす他のコンポーネントほど重要ではありません。 私たちは標準化、自動化、柔軟性に努めなければなりません。 データベースコンポーネントは神聖ではないことを理解することが重要です。 どんなコンポーネントも紛失して交換できなければなりません。 ガラスの部屋にある壊れやすいデータウェアハウスは過去のものです。



特殊な雪片とサービスコンポーネントの違いを示すために、ペットと牛を比較できます。 サーバー「ペット」は、あなたが餌をやり、彼の世話をし、病気になったときに耐えるサーバーです。 彼には名前もあります。 会社で

2000年のTravelocityでは、サーバーはSimpsonsのヒーローと呼ばれ、2つのOracleサーバーはPattyとSelmaと名付けられました。 私はこれらの女の子と多くの夜を過ごしました。 彼らはまだ彼らのものでした！



ビッグハンドサーバーには名前がありません-番号があります。 サーバーのセットアップ、各ホストへのアクセスに時間を費やす必要はありません。 誰かが病気の兆候を見せたら、群れから彼を連れ出し、法医学的検査の近くに彼を置きます。



データウェアハウスは最新のペットの1つです。 それでも、彼らは「データ」を保存し、短いライフサイクルと完全な標準化を備えた牛に置き換えることはできません。 レポート用のレプリカの特別なレプリケーションルールについてはどうですか？ プライマリノードのフォールトトレランスのためのレプリカの特別な構成はどうですか？ 彼らにはさまざまなタスクがあります。

開発と運用の間の障壁を取り除きます

インフラストラクチャ、構成、データモデル、およびスクリプトはすべてソフトウェアの一部です。 他のエンジニアと同じように、ソフトウェア開発を学び、参加してください。 コードの記述、テスト、統合、ビルド、テスト、展開。 テストを忘れていませんか？



バックエンドのスクリプトを管理および作成している人にとって、これは複雑なパラダイムシフトになる可能性があります。 従来の環境では、製品の設計、構築、およびテストのプロセスは、開発者、システム管理者、およびDBAの間で共有されます。 議論中のパラダイムシフトにより、プロセスの編成方法に関する見解の違いが解消されるため、DBREとシステム管理者は同様の方法で作業を行いたいと考えています。

開発者は管理方法を学ぶ必要があります！



管理者は、多くの場合、プログラミングを習得するか、「帰宅する」ように言われます。 一般的に私はこれに同意しますが、反対も真実でなければなりません。 インフラストラクチャ管理の原則を理解していない開発者は、脆弱で非効率的で潜在的に安全でないコードを作成します。

DBREは、開発チームに直接統合し、同じコードで作業し、コードがデータベースとどのように相互作用するかを確認し、速度、機能、および信頼性のためにコードを変更できます。



これらの組織の障壁を取り除くと、従来のモデルよりも生産性と開発速度が向上し、DBREはこれらの新しいプロセスと文化に適応する必要があります。

運営

DBREのコアコンピテンシーの1つは運用です。 スケーラビリティと信頼性に関する複雑な要件を持つシステムの設計、テスト、組み立て、および運用が含まれます。 つまり データベースエンジニアになりたい場合は、これらのことを知る必要があります。



マクロレベルでは、搾取は役割ではありません。 運用とは、品質システムとソフトウェア製品の管理の実践に関して会社が構築したすべての知識、スキル、および価値の合計です。 これらはあなたの隠れた価値であり、明らかな価値、習慣、経験の共有、報酬システムです。 サポートからCEOまで、すべてが運用結果に関与しています。



多くの場合、これはあまりうまくいきません。 多くの企業では、搾取の文化は非常に恐ろしいため、それに近づいた人は誰でも火傷します。 それにもかかわらず、あなたの搾取の文化はあなたの会社の突然現れた特徴であり、それがその技術的使命とどのように関係しているかです。 したがって、あまり使い道がないと言われても、私たちは取り引きしません。



サービスインフラストラクチャの開発者またはサポーターになる場合があります。 大胆不敵なDBAにとって、運用原則が不可欠であることに疑問があるかもしれません。 クラウドコンピューティングモデルが運用上の問題から開発者を解放すると考えるのは間違いです。 実際にはまったく逆です。 これは、管理者がいない新しい大胆不敵な世界であり、Google、Amazon、PagerDuty、DataDogなどのエンジニアが作業を行います。 この世界では、開発者は現在よりも管理、アーキテクチャ、およびパフォーマンスをよりよく理解する必要があります。

ニーズの階層

あなたの一部は企業での経験でこの本にアプローチし、一部はスタートアップで経験しました。 他のシステムを見るように、データベースの責任を負う最初の日に何をするかを考える価値がありますか？ バックアップはありますか？ 彼らは労働者ですか？ よろしいですか 切り替え可能なレプリカはありますか？ これを行う方法を知っていますか？ 同じ電源ケーブル、ルーター、機器上にありますか？メインノードはどこですか？ バックアップの実行が停止したかどうかを知っていますか？ これについてどうやって知っていますか？



つまり、データベースのニーズについて話す必要があります。



人々のために、マズローのニーズのヒエラルキーが発明されました-成功を感じるために満たさなければならない欲望のピラミッド：物理的な生存、安全、愛と帰属、敬意と自己実現。 ピラミッドの中核には、生存などの最も基本的なニーズがあります。 彼らが満足するとき、私たちは安全に勉強し、遊び、創造し、私たちのユニークな可能性の完全な開示を達成できるとき、自己実現に行きます。 これは人々のためです。 このアプローチをデータベースに適用してみましょう。

生存と安全

データベースの主なニーズは、バックアップ、レプリカ、および切り替え機能です。 データベースはありますか？ 彼女は労働者ですか？ ping？ アプリケーションは応答しますか？ バックアップされていますか？ リカバリは機能しますか？ 動作しなくなったかどうかはどうやってわかりますか？



データは安全ですか？ データのコピーはありますか？ 切り替える方法を知っていますか？ データのコピーは、異なる電源を持つ異なる機器にありますか？ コピーは一貫していますか？ ある時点で回復できますか？ データが破損したかどうかをどのように確認しますか？



これらの問題については、バックアップとリカバリの章で詳しく説明します。



また、スケーリングの準備をする価値があります。 もちろん、事前にスケーリングする必要はありませんが、重要なデータオブジェクト、ストレージシステム、およびアーキテクチャの識別子を定義するのと同じ方法で成長を考慮する必要があります。

スケーリングの種類

スケーリングについてはかなり頻繁に説明します。 スケーラビリティとは、増加する作業に対処するためのシステムまたはサービスの能力です。 これは、システム全体が成長を念頭に置いて構築された場合は実際の能力であり、アーキテクチャは成長に必要なリソースとコンポーネントの追加を提供する場合は潜在的な能力です。 4つの一般的なスケーリング方法があります。

• 垂直、リソースの追加による（スケールアップ）。
• システムまたはサービスの重複による水平（スケールアウト）;
• 機能ごとに負荷を小さな部分に分割し、それぞれを個別にスケーリングできるようにします（機能分割）。
• 作業中のデータセットが異なる同一部分への負荷分散（シャーディング）。

これらのアプローチの特定の側面については、第5章「インフラストラクチャの設計」で説明します。

愛と所属

愛と帰属とは、データをソフトウェア開発プロセスの一流の市民オブジェクトに変えることを意味します。 これは、データベースを他のシステムから分離するのをやめることです。 これは技術的および文化的な問題であるため、「DevOps要件」と呼ぶことができます。 最上位レベルでは、これは、データベースの管理が他のすべてのシステムの管理と同じように（できるだけ）ルックアンドフィールする必要があることを意味します。 また、ボラティリティとクロス機能を促進することを意味します。 愛と帰属の段階は、ルートとしてのログインを徐々に停止し、無礼なコマンドを実行することです。 これは、同じコード分析と展開のプラクティスを使用し始めるときです。



データベースインフラストラクチャは、他のアーキテクチャコンポーネントとともに1つのプロセスの一部である必要があります。 データの操作は、アプリケーションの他のすべての部分と調整する必要があります。これにより、データベースサポートに対処できると誰もが感じられるはずです。



開発者に恐怖を植え付ける衝動と戦ってください。 すべてをコントロールしていると感じるのはとても魅力的です。 実際、いいえ-あなたにはコントロールがありません。 事故によって何かを破壊することが困難になるように、誰もがエネルギーを「手すり」の作成に向けることがはるかに良いでしょう。 トレーニングして、誰でも変更を行えるようにします。失敗に対処する。言い換えれば、回復力のある回復力のあるシステムを作成し、できるだけ多くの人がデータベースを操作できるようにします。

Etsyの手すり。



Etsyは、戦闘環境でデータベースを安全に変更するためのSchemanatorというツールを導入しました。開発者が変更を適用できるように、次のような多くの手すりが使用されました。

• 標準規格への準拠を検証するための変更のヒューリスティック分析。
• 変更されたスクリプトが正常に実行されることを確認します。
• 開発者にシステムの現在のステータスを示すプリフライト準備。
• 負荷から削除されたサーバーへの変更の連続的な適用。
• 予期しない問題が発生した場合にプロセスを停止できるように、変更をサブタスクに分割します。

ブログで詳細を読むことができます。

敬意

敬意はピラミッドの最も高い必要性です。人々にとって、これは卓越性の認識を意味します。データベースの場合-これは、監視、デバッグ、イントロスペクション、およびツールを備えた機能です。これは、ストレージシステムを単独で理解し、スタック全体でイベントを相関させる機能です。この段階には、サービスと人員という2つの側面があります。



サービスは、落下、上昇、または問題が発生している場合に通知する必要があります。グラフを見て調べる必要はありません。開発されたシステムでは、変化率が低下し、動作がより予測可能になります。戦闘環境では、毎日、ストレージシステムの弱点、障害につながる動作機能、および条件を調査します。これは、10代のデータインフラストラクチャと比較できます。何が起こっているのかを見ることができる必要があります。製品が複雑になるほど、可動部分が増え、監視ツールを開発する必要が増えます。



ボタンとレバーも必要です。サービスを完全に削減するのではなく、サービスの品質を選択的に低下させる機能が必要です。例：

• 読み取り専用モードに移行します。
• 一部の機能を無効にします。
• ;
• – .

あなたの人々は似たようなニーズを持っていますが、一致するニーズはありません。販売に関しては、人々が反応しすぎることがよくあります。彼らは何が起こっているのか理解しておらず、すべてを連続して監視し始め、何百ものグラフのビューに到達しますが、そのほとんどは無意味です。このノイズの中に有用な信号がなく、ログを見て理由を推測せざるを得ない場合、これはグラフの完全な欠如と同じくらい悪いです。



この場合、あなたはあなたの人々を「燃やし始める」ことができます-割り込み、目を覚まし、受け取ったアラートに反応しないように彼らに教えます。早い段階で、全員が電話をかけることを期待しています。ループがドラッグされると、会議を作成し、人々を快適ゾーンから押し出して、少し助けます。

自己実現

自分の才能を完全に明らかにした各人がユニークであるように、各組織で開発されたストレージシステムはユニークです。 Facebook、Pinterest、Githubの理想的な理論上のストレージシステムは外観が異なりますが、スタートアップの段階では一致する場合があります。しかし、健康な発達した人々に共通の特徴があるように（彼らは店でかんしゃくを持ち、健康的な食べ物を食べ、スポーツをしません）、健康な発達したストレージシステムには共通の特徴があります。



この意味で、自己実現とは、データウェアハウスが、進行を妨げることなく必要なものを取得できるようにすることを意味します。開発者が自分の仕事を行い、間違いを避けることができます。一般的な問題と一般的な問題は、人間の介入なしで自分で解消する必要があります。つまり、スケーリングは毎年機能し、10倍の成長に対応するため、3年後には容量とパフォーマンスについて考えることになります。率直に言って、ほとんどの場合、現在の問題を排除するのではなく、新製品や将来の問題の防止など、他の興味深いことを考えると、ストレージシステムは成熟していると言えます。



レベル間を前後に移動するのは正常です。ほとんどの場合、レベルに優先順位を付ける必要があります。たとえば、作業バックアップの可用性に対する信頼は、自動シャーディングと容量の追加のためのスクリプトを記述するよりもはるかに重要です。まだオンラインでデータのコピーが1つしかない場合、または障害が発生した場合にリザーブに切り替える方法がわからない場合は、他のことをやめ、これらの優先事項に対処する必要があります。

まとめると

DBREロールは、既存の理解可能なDBAロールに関するパラダイムシフトです。このプラットフォームは、刻々と変化する世界でのデータベース管理機能への新しいアプローチを提供します。次の章では、これらの機能を詳細に検討し、日常業務のタスクに優先順位を付けます。これらの言葉で、私の勇敢なエンジニア、大胆に前進しましょう！