# DBRE 輪読会 vol.05 2021/07/29 [@kdnakt](https://twitter.com/kdnakt) --- ### 復習 - 1章:学習を続け、チームを超えて改善を進める - 2章:SLOが全ての基礎 - 3章:SLOのためにリスクを認識し低減する - 4章:SLOへの影響を知るための見える化 ---- - ここまでは準備運動 - ここからが本番！ - DBクラスタ構築の実践例 --- ### 今日の範囲 - 5章 インフラストラクチャエンジニアリング - 5.1 ホスト - 5.2 仮想化 - 5.3 コンテナ - 5.4 DBaaS - 5.5 まとめ --- ### 今日の概要 - 物理サーバDBはアーキテクチャがシンプル、 見える化しやすい：反面手間がかかる - 仮想化/コンテナDBは開発/テスト環境向き - DBaaSにも専門家(DBRE)は不可欠 --- ### 1. 物理サーバDB - アーキテクチャがシンプル - 見える化しやすい - OSの状態をコマンドで可視化可能 - 反面、手間がかかる - 発注,各種インストール作業... - 最適化のため各方面の知識不可欠 ---- #### 物理サーバ（正確にはホスト） - ハードウェアリソースを100%利用可能 - OSやカーネル設定はSREと協力必須 - CPU,メモリ,ストレージI/O,ネットワーク ...考慮事項多数 ---- #### メモリ - DBは最もメモリを消費するサーバ - 効率が最重要 - 各DBが独自ライブラリを利用し負荷軽減 - MySQL/PostgreSQLはmalloc改造 - Cassandra/Redisはjemallocを利用 - MongoDBではtcmalloc/jemallocを利用可 - 断片化対策：DBに全て割り当てるのはNG - スワッピングによるパフォーマンス低下問題 ---- #### ネットワーク - 用途によって要求が異なる - クラスタの各ノード間通信 - アプリからの各種クエリ - 管理用のトラフィック（設定変更） - バックアップとリカバリのトラフィック - 用途別にネットワークを構築する必要 - 高品質なネットワークのために TCP/IPの知識不可欠 ---- #### ストレージ - 超巨大なトピック：構成要素が多い - ファイルシステム - ページキャッシュ - I/Oスケジューラ - 物理ディスク - RAID etc - 観点も多い - キャパシティ - スループット - レイテンシ - 可用性、耐久性 --- ### 2. 仮想化/コンテナDB - OS設定をコード化して管理できることの利点 - 環境を複数立てやすい：開発/テスト向き - デプロイ経験/ベストプラクティス を共有しやすい - 仮想化によるデメリットもある - 物理サーバよりレイテンシ大 - 物理サーバより並行実行性能劣る - 物理ディスクへの書き込み保証なし --- ### 3. DBaaS - 自動化されたデータベースサービス： - デプロイ、フェイルオーバー - パッチ、セキュリティアップデート - バックアップ/リカバリ、メトリクス収集 - 各パブリッククラウドが提供 - Amazon DynamoDB - Amazon RDS - Azure Cosmos DB - Cloud Spanner - Oracle Autonomous Database ---- #### DBaaSとDBRE - DBaaS≠夢のようなサービス - ハードウェア情報が取得できず 見える化で不利 - 環境の耐久性はクラウド業者任せ - 稀にバグる - DBREの貢献ポイント - DBエンジンの選択 - データモデルの設計 - DBのセキュリティ、アクセス権限設定 - キャパシティプランニング - マイグレーションや災害復旧 --- ### 今日の概要(再掲) - 物理サーバDBはアーキテクチャがシンプル、 見える化しやすい：反面手間がかかる - 仮想化/コンテナDBは開発/テスト環境向き - DBaaSにも専門家(DBRE)は不可欠 --- ### おまけ - SMP: Symmetric Multiprocessing - それぞれのCPUが等しくメモリアクセス - NUMA: Non-Uniform Memory Access - それぞれのCPUがローカルメモリを持つ - UMA: Unified Memory Architecture - CPUとGPUなどがメモリを共有する - 参考： [Rebuild 288: Unidentified Mysterious Animal (hak)](https://rebuild.fm/288/) 14:03~51:48