人類は如何にして大切な人類は如何にして大切なデータベースを守るべきかデータベースを守るべきか

 奥野 幹也Twitter: @nippondanjimikiya (dot) okuno (at) gmail (dot) com

@SQL  アンチパターン読書会 2015/01

免責事項● 本プレゼンテーションにおいて示されている見解は、私自身の見解であって、オラクル・コーポレーションの見解を必ずしも反映したものではありません。ご了承ください。

自己紹介

● MySQL サポートエンジニア– 日々のしごと

● トラブルシューティング全般● Q&A 回答● パフォーマンスチューニング

など● ライフワーク

– 自由なソフトウェアの普及● オープンソースではない

● ブログ– 漢のコンピュータ道– http://nippondanji.blogspot.com/

今日は個人として参加しています。

自己紹介 その２

● サポート一筋 14 年半● 幾多のトラブルを経験

– ハードウェア故障● ディスク（ドライブ、アレイ装置）、 CPU 、メモリ ...

– ソフトウェアのバグ– ファームウェアのバグ– データ破壊

etc etc

枕を高くして眠りたい！！

枕を高くして眠るために・・・

● 問題が絶対に起きないシステムは存在しない● 問題に対応する手段を講じておく

– 例外処理– 冗長化– 運用 ←← できるだけここの負担を減らしたい

● 課題– 如何に有事の際に手間をかけずに運用するか

● できるだけ多くの問題を自動的に修復する– 如何にして金と手間をかけるべきポイントを見抜くか

● 備えあれば憂いなし

安全神話は存在しない！！

安全神話は存在しない

● この世に絶対はない● 安全性はコストをかければかけるほど高まるが・・・

– 絶対安全＝コストは∞（無限）– しかしこの世界は有限– ∴ 絶対的な安全はあり得ない

● どれだけ対策したところで、想定外の事象はあり得る

目的：サービスの安定稼働

● トラブルはサービスによる収益に直結する！！– ダウンタイム＝機会損失＋ユーザー満足度低下等々– データロスト＝壊滅的なダメージ

● サービス再開まで大きなダウンタイムに– 情報漏えい＝社会的責任、賠償問題や信用問題に

● サービスの安定稼働は至上命題– ・・・にも関わらず、痛い目を見る現場が続出

アンチパターン：想定不足

● 冗長化などの仕組みは、想定された事象しか対処できない– 何故ならば、プログラムは書かれた通りに動くから

● 魔法のように良きに計らってくれることはない● つまり、起きうる事象を網羅的に想定しておく必要がある

– どのような事象に対して自動でサービスを継続する仕組みが必要か

– どのような仕組みを使って実装するか– 運用はどうすべきか– 想定以上のことが起きてしまったらどうするか

etc● 最大の問題は、十分な想定も準備もせずに見切り発車して

しまうこと。– 無計画と言ったほうが適切かも知れない。

アンチパターンの見つけ方

● 想定以外のことが起きるときの「あるある」話– データサイズが想定以上に大きくなった

● アプリケーションは未知の領域へ・・・– デッドロックは製品のバグでは？

● 想定不足以前に知識不足。話にならない。– 解析のためのデータのが取れない

● じゃあ調査も無しということで・・・– 速いマシンだから無問題！！

● 思考停止はよくない！

解決策

ベンチマークは超重要

● 性能にまつわる問題はとても多い– よくある要因

● データサイズが増えた● アクセスが増えた● クエリがクソだった

– サービスに悪影響を与えるが HA では解決できない問題● 実際の測定結果無しに性能問題を語るのは不毛！！

– 想定と測定結果が異なるのは日常茶飯事– 実装には様々なオーバーヘッドやボトルネックがある– 実際の性能はどの程度かを知るにはベンチマークが必須

● 本番環境で測定するのはリスクがある– ならばテスト環境でベンチマーク！！

テスト環境

● テストは超重要！！– プログラムのテストケースに限らない

● システムテスト● ベンチマークテスト

● テストする環境が無かったら、どこでテストすればいいんだ！！

– 大事なのに、存在しないか十分でない場合が多い● テスト環境だけスペックがショボイ● 本番は実マシンだがテスト環境は仮想マシン

– 本番環境で起きうる問題をテストする● 本番環境を使うのはリスクやオーバーヘッドがある● 本番環境と同じものが必要

例外処理

● 想定外な処理の基本– アプリケーションの内部で対応できる範囲について記述

● 手に負えない部分はアプリ外の仕組みで– HA やバックアップからのリストア、ディザスタリカバリ等

– アプリケーション内で起きうる事象を網羅的に想定するのは現実的でない

● データベースに限って見ればそれほど難しくない

バックアップ

● サービスにとって最後の砦● 綿密な計画を推奨

– 方式● 物理 or論理● フル or差分、増分● レプリケーション

– 頻度– リカバリにかかる時間の見積り

高可用性とディザスタリカバリ

● 冗長性– 何かが故障したときに代わりになるものを準備する– 実に様々なものが冗長化できる

● ディスク● NIC● 電源● サーバーマシン● スイッチ● データセンターそのもの

● 冗長性を高めれば高めるほど– 可用性は高くなる– コストは増大する

● どこまで金をかけるべきか

最終的には運用と保守でカバー

● 例外処理も HA も、想定した事象しか対応できない– 想定外の事象をどうするべきか– 事前にポリシーを決めておく

● 想定外の対応を決めておくことで物事がスムーズに● 高可用性の限界を超えた障害

– 通常の HA● 地震でデータセンターごと使用不能に● うまく切り替わらない（データ破壊、ピンポン等）

● 問題の調査– 問題は起きるという前提でどうするか決めておくべき– 手順を作ったりオーバーヘッドを我慢するか、調査を諦め

るか● 性能の劣化

– いくらスケールアウトしてもクエリがクソでは・・・

まとめ

● システムを安定稼働させるには、そのための仕組みが必要– プログラムは書かれた通りにしか動かない– どのような問題に対応できるかをできるだけ多く想定する– プログラム単体だけでは対処できない問題もある– 想定以上のことも起きるという認識が必要

● ポリシーを決めておくことで対応がスムーズに● プログラムの内部しか見ないことがアンチパターン● DB アプリケーションでよくある問題はおさえておくこと

– ベンチマーク、テスト環境、 HA 、例外処理、バックアップ

etc● 枕を高くして QOL も高く！！

おまけ

載せ忘れた話その１セキュリティ関係

● 安定稼働とは別の切り口だが、サービスにとっての脅威● 万全の対策は難しく、ひとたび被害に遭うと損害は甚大

– ひと通り鉄板の対策はやっておく（徳丸本等）– クレジットカード情報は安易に保存しない

載せ忘れた話その２キャパシティプランニング

● データサイズ– どこまでデータを保管できるか– 今のペースでデータが増え続けると仮定すると、いつまで

システムを使い続けられるか● アクセス数

– 何ユーザーまで耐えられるか● いくら冗長化しても、キャパシティを超えてシステムを使用

することはできない

載せ忘れた話その３論理的なデータ破壊

● 論理的なデータ破壊– データベースに格納された値が、本来あってはいけない状態になっている

– 矛盾している– 想定していない値が返ることでアプリケーションの動作が不定に

– アプリケーションにとって壊滅的なダメージだが軽視されがち

● リレーショナルモデルを実践すべし！！– 正規化– 直交性– 制約

余談：タイトルについて

● 脆くて壊れやすいけど大切なもののイメージ– みんなで一生懸命この城を守るんだ！！

● 城＝大切– 砂で作ったものは脆い

● 諸行無常● ドラマとは関係ないので悪しからず。

宣伝：新書籍の紹介● 理論から学ぶ データベース実践入門

– 副題：リレーショナルモデルによる効率的な SQL ・ DB設計– どうやってリレーショナルデータベースを使いこなすか！

● リレーショナルモデル基礎編– SQL とリレーショナルモデル– 述語論理とリレーショナルモデル– 正規化 1:  関数従属性– 正規化 2: 結合従属性– 直交性– ドメインの設計

etc● アプリケーション開発実践編

– 履歴– グラフ– インデックスの設計– ウェブアプリケーションのためのデータ構造

etc

基礎の基礎からよくある間違いを

指摘しつつ応用まで

Q&Aご静聴ありがとうございました。