SQLアンチパターン読書会最終回（第25章）で用いた資料です。章タイトルは「砂の城」でしたが、スライド自身にはもう少し分かりやすいタイトルをつけています。サービス安定稼働のためにどういったことが必要なのかというのが、スライドの主旨です。最後に少しオマケあり。

1. 人類は如何にして大切な人類は如何にして大切な
データベースを守るべきかデータベースを守るべきか
奥野 幹也
Twitter: @nippondanji
mikiya (dot) okuno (at) gmail (dot) com
@SQL アンチパターン読書会 2015/01

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

3. 自己紹介
●
MySQL サポートエンジニア
– 日々のしごと
● トラブルシューティング全般
●
Q&A 回答
● パフォーマンスチューニング
など
●
ライフワーク
– 自由なソフトウェアの普及
● オープンソースではない
●
ブログ
– 漢のコンピュータ道
– http://nippondanji.blogspot.com/
今日は個人として
参加しています。

4. 自己紹介 その２
●
サポート一筋 14 年半
● 幾多のトラブルを経験
– ハードウェア故障
●
ディスク（ドライブ、アレイ装置）、 CPU 、メモリ ...
– ソフトウェアのバグ
– ファームウェアのバグ
– データ破壊
etc etc

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

6. 枕を高くして眠るために・・・
● 問題が絶対に起きないシステムは存在しない
●
問題に対応する手段を講じておく
– 例外処理
– 冗長化
– 運用 ←← できるだけここの負担を減らしたい
● 課題
– 如何に有事の際に手間をかけずに運用するか
● できるだけ多くの問題を自動的に修復する
– 如何にして金と手間をかけるべきポイントを見抜くか
●
備えあれば憂いなし

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

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
基礎の基礎から
よくある間違いを
指摘しつつ
応用まで

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