人類は如何にして大切な データベースを守るべきか
•
22 likes•4,543 views
SQLアンチパターン読書会最終回（第25章）で用いた資料です。章タイトルは「砂の城」でしたが、スライド自身にはもう少し分かりやすいタイトルをつけています。サービス安定稼働のためにどういったことが必要なのかというのが、スライドの主旨です。最後に少しオマケあり。
人類は如何にして大切な データベースを守るべきか
- 3. 自己紹介 ● MySQL サポートエンジニア – 日々のしごと ● トラブルシューティング全般 ● Q&A 回答 ● パフォーマンスチューニング など ● ライフワーク – 自由なソフトウェアの普及 ● オープンソースではない ● ブログ – 漢のコンピュータ道 – http://nippondanji.blogspot.com/ 今日は個人として 参加しています。
- 4. 自己紹介 その２ ● サポート一筋 14 年半 ● 幾多のトラブルを経験 – ハードウェア故障 ● ディスク（ドライブ、アレイ装置）、 CPU 、メモリ ... – ソフトウェアのバグ – ファームウェアのバグ – データ破壊 etc etc
- 6. 枕を高くして眠るために・・・ ● 問題が絶対に起きないシステムは存在しない ● 問題に対応する手段を講じておく – 例外処理 – 冗長化 – 運用 ←← できるだけここの負担を減らしたい ● 課題 – 如何に有事の際に手間をかけずに運用するか ● できるだけ多くの問題を自動的に修復する – 如何にして金と手間をかけるべきポイントを見抜くか ● 備えあれば憂いなし
- 8. 安全神話は存在しない ● この世に絶対はない ● 安全性はコストをかければかけるほど高まるが・・・ – 絶対安全＝コストは∞（無限） – しかしこの世界は有限 – ∴ 絶対的な安全はあり得ない ● どれだけ対策したところで、想定外の事象はあり得る
- 9. 目的：サービスの安定稼働 ● トラブルはサービスによる収益に直結する！！ – ダウンタイム＝機会損失＋ユーザー満足度低下等々 – データロスト＝壊滅的なダメージ ● サービス再開まで大きなダウンタイムに – 情報漏えい＝社会的責任、賠償問題や信用問題に ● サービスの安定稼働は至上命題 – ・・・にも関わらず、痛い目を見る現場が続出
- 10. アンチパターン：想定不足 ● 冗長化などの仕組みは、想定された事象しか対処できない – 何故ならば、プログラムは書かれた通りに動くから ● 魔法のように良きに計らってくれることはない ● つまり、起きうる事象を網羅的に想定しておく必要がある – どのような事象に対して自動でサービスを継続する仕組 みが必要か – どのような仕組みを使って実装するか – 運用はどうすべきか – 想定以上のことが起きてしまったらどうするか etc ● 最大の問題は、十分な想定も準備もせずに見切り発車して しまうこと。 – 無計画と言ったほうが適切かも知れない。
- 11. アンチパターンの見つけ方 ● 想定以外のことが起きるときの「あるある」話 – データサイズが想定以上に大きくなった ● アプリケーションは未知の領域へ・・・ – デッドロックは製品のバグでは？ ● 想定不足以前に知識不足。話にならない。 – 解析のためのデータのが取れない ● じゃあ調査も無しということで・・・ – 速いマシンだから無問題！！ ● 思考停止はよくない！
- 12. 解決策
- 13. ベンチマークは超重要 ● 性能にまつわる問題はとても多い – よくある要因 ● データサイズが増えた ● アクセスが増えた ● クエリがクソだった – サービスに悪影響を与えるが HA では解決できない問題 ● 実際の測定結果無しに性能問題を語るのは不毛！！ – 想定と測定結果が異なるのは日常茶飯事 – 実装には様々なオーバーヘッドやボトルネックがある – 実際の性能はどの程度かを知るにはベンチマークが必須 ● 本番環境で測定するのはリスクがある – ならばテスト環境でベンチマーク！！
- 14. テスト環境 ● テストは超重要！！ – プログラムのテストケースに限らない ● システムテスト ● ベンチマークテスト ● テストする環境が無かったら、どこでテストすればいいん だ！！ – 大事なのに、存在しないか十分でない場合が多い ● テスト環境だけスペックがショボイ ● 本番は実マシンだがテスト環境は仮想マシン – 本番環境で起きうる問題をテストする ● 本番環境を使うのはリスクやオーバーヘッドがある ● 本番環境と同じものが必要
- 15. 例外処理 ● 想定外な処理の基本 – アプリケーションの内部で対応できる範囲について記述 ● 手に負えない部分はアプリ外の仕組みで – HA やバックアップからのリストア、ディザスタリカバリ等 – アプリケーション内で起きうる事象を網羅的に想定するの は現実的でない ● データベースに限って見ればそれほど難しくない
- 16. バックアップ ● サービスにとって最後の砦 ● 綿密な計画を推奨 – 方式 ● 物理 or 論理 ● フル or 差分、増分 ● レプリケーション – 頻度 – リカバリにかかる時間の見積り
- 17. 高可用性とディザスタリカバリ ● 冗長性 – 何かが故障したときに代わりになるものを準備する – 実に様々なものが冗長化できる ● ディスク ● NIC ● 電源 ● サーバーマシン ● スイッチ ● データセンターそのもの ● 冗長性を高めれば高めるほど – 可用性は高くなる – コストは増大する ● どこまで金をかけるべきか
- 18. 最終的には運用と保守でカバー ● 例外処理も HA も、想定した事象しか対応できない – 想定外の事象をどうするべきか – 事前にポリシーを決めておく ● 想定外の対応を決めておくことで物事がスムーズに ● 高可用性の限界を超えた障害 – 通常の HA ● 地震でデータセンターごと使用不能に ● うまく切り替わらない（データ破壊、ピンポン等） ● 問題の調査 – 問題は起きるという前提でどうするか決めておくべき – 手順を作ったりオーバーヘッドを我慢するか、調査を諦め るか ● 性能の劣化 – いくらスケールアウトしてもクエリがクソでは・・・
- 19. まとめ ● システムを安定稼働させるには、そのための仕組みが必要 – プログラムは書かれた通りにしか動かない – どのような問題に対応できるかをできるだけ多く想定する – プログラム単体だけでは対処できない問題もある – 想定以上のことも起きるという認識が必要 ● ポリシーを決めておくことで対応がスムーズに ● プログラムの内部しか見ないことがアンチパターン ● DB アプリケーションでよくある問題はおさえておくこと – ベンチマーク、テスト環境、 HA 、例外処理、バックアップ etc ● 枕を高くして QOL も高く！！
- 20. おまけ
- 21. 載せ忘れた話その１ セキュリティ関係 ● 安定稼働とは別の切り口だが、サービスにとっての脅威 ● 万全の対策は難しく、ひとたび被害に遭うと損害は甚大 – ひと通り鉄板の対策はやっておく（徳丸本等） – クレジットカード情報は安易に保存しない
- 22. 載せ忘れた話その２ キャパシティプランニング ● データサイズ – どこまでデータを保管できるか – 今のペースでデータが増え続けると仮定すると、いつまで システムを使い続けられるか ● アクセス数 – 何ユーザーまで耐えられるか ● いくら冗長化しても、キャパシティを超えてシステムを使用 することはできない
- 23. 載せ忘れた話その３ 論理的なデータ破壊 ● 論理的なデータ破壊 – データベースに格納された値が、本来あってはいけない 状態になっている – 矛盾している – 想定していない値が返ることでアプリケーションの動作が 不定に – アプリケーションにとって壊滅的なダメージだが軽視され がち ● リレーショナルモデルを実践すべし！！ – 正規化 – 直交性 – 制約
- 24. 余談：タイトルについて ● 脆くて壊れやすいけど大切なもののイメージ – みんなで一生懸命この城を守るんだ！！ ● 城＝大切 – 砂で作ったものは脆い ● 諸行無常 ● ドラマとは関係ないので悪しからず。
- 25. 宣伝：新書籍の紹介 ● 理論から学ぶ データベース実践入門 – 副題：リレーショナルモデルによる効率的な SQL ・ DB 設計 – どうやってリレーショナルデータベースを使いこなすか！ ● リレーショナルモデル基礎編 – SQL とリレーショナルモデル – 述語論理とリレーショナルモデル – 正規化 1: 関数従属性 – 正規化 2: 結合従属性 – 直交性 – ドメインの設計 etc ● アプリケーション開発実践編 – 履歴 – グラフ – インデックスの設計 – ウェブアプリケーションのためのデータ構造 etc 基礎の基礎から よくある間違いを 指摘しつつ 応用まで