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