翱谤补肠濒别设计
- 1. 初めての翱谤补肠濒别设计 株式会社アイ?ティ?プロデュース 塩原浩太 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved.
- 2. 免責事項 ? 本資料の内容及び発言は、私個人のものであり 所属会社や所属団体の見解を反映したものでは ありません。 ? 本資料に記載されている内容が設計の全てでは ありません。また、例示が全てでもありません。 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 2
- 3. 自己紹介 株式会社アイ?ティ?プロデュース所属 http://www.it-produce.co.jp/ データベース業界数十年のエンジニア メインはOracle Database、OSS系もちらほら 技術ブログ：Trying Database Twitter:@sora_to_umi 座右の銘：格物致知 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 3
- 4. 本セッションの目的とフォーカス ? 目的 – Oracle 設計の内容を注意点を知る – Oracle 設計に対する漠然とした不安意識の払拭 ? フォーカス – 非機能要件周り(物理周り) Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 4
- 5. システムカットオーバの流れ ? 企画 ? RFP作成 ? 要件定義 ? 基本設計 ? 詳細設計 ? 構築 ? テスト ? 移行 ? カットオーバ ? (運用) Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 5
- 6. 设计の流れ 要件定義 要件 基本設計 具体化 あいまい、 方針 不明な要素は 戻って確認 詳細設計 値 設定定義 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 6
- 7. 设计フェーズにおける実施内容 ? システムの目的、企画の整理 要件定義 ? 要件決定 ? 要件の整理 基本設計 ? 構成、方針の決定 ? サイジング 詳細設計 ? 設定値の決定 ? 導入時の設定書 設定定義書 ? 各種設定の設定結果 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 7
- 8. 要件定義 要件定義：一番のインプット – 求めるものを明確にする – 気付いていない自分の要求を明確にする 要件 – 何を優先するかを明確にする 必要な 困って こと いること あると いいな 要件定義 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 8
- 9. 代表的な要件 ? 性能要件 – 同時処理件数、レスポンス ? 可用性要件 – RTO,RPO,RLO,稼働率、多重障害 ? 拡張性要件 – スケールアップ、スケールアウト、リプレイス ? キャパシティ要件 – 目標使用率 ? セキュリティ要件 – 監査、アクセス制御、暗号化 ? 運用要件 – 監視、メンテナンス などなど Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 9
- 10. 要件定義で気を付ける点 ? 顧客は技術のプロではない ? 設計する側は対象システムのプロではない ? 顧客と協力して要件を明確にすることが大事 ? 現行踏襲の罠に嵌らない ? 数値、とても大事(件数、秒、人、、、) Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 10
- 11. 基本設計 基本設計：構成や方針を決める – 要件の整理、 ? 要件のOracle視点での落とし込み ? システムの理解 – 作戦?戦略を決める ? 他チーム(Oracle以外の要素)との切り分け ? Oracleの設計方針、構成決定 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 11
- 12. 要件の整理(システムの理解) 内容、目的 DBの位置づけ 要件定義書 重要度、影響度 データ特性 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 12
- 13. 要件の整理(要件のOracle視点での落とし込み） ? 要件定義書はOracle DB向けに書いてあるわけでない ? Oracle DBでもその要件を満たす必要があるか精査が必要 例) 監査証跡、暗号化、システムが使われるのは昼間だけ Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 13
- 14. 作戦?戦略を決める 他チーム(Oracle以外の要素)との切り分け ? 要件をどこで担保するか ? 要素は重複、連携してる AP ハード ストレージ ネットワーク サーバ OS Oracle 運用 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 14
- 15. 作戦?戦略を決める Oracleの設計方針、構成決定 ? 何が必要か ? 何が起きるかをイメージする – どんな使われ方する？ – 将来的なボトルネックは？ – 運用していくとどうなる？ メモリ I/O CPU Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 15
- 16. 構成?方式 ? HA?RAC? DG?レプリケーション？ ? EE? or SE? ? パーティショニング?圧縮? ? ASO?DBV?OAV? ? Diagnostics Pack? Tuning Pack? ? ホットバックアップ?コールドバックアップ? ? RMAN?Fast Recovery Area? Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 16
- 17. ちゃんと考えてみる ? SE-RAC – リソースの有効活用？ – スケールアウト出来る？ – 止まらない？ CPU使用率40% CPU使用率40% 稼働率99% × 稼働率99% CPU使用率80% Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 17
- 18. システム全体で考える ? 本当に冗長？ DNSサーバ SCAN SCAN VIP1 LISTENER1 SCAN SCAN VIP2 LISTENER2 SCAN SCAN VIP3 LISTENER3 APサーバ Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 18
- 19. 例 ３．構成設計 データベースシステムでは、サーバ障害対策としてOracle Real Application Clusters構成を採用する。 以下、表X.X.○○○に採用根拠を示す 名称 説明 停止時間 コスト 拡張性 RAC構成 ?複数のサーバでデータベースを共有、起動する 10~30秒 △ ○ ?特定サーバ上で障害が発生した場合でも、残りのサーバでサービス 継続が可能。 ?H/Wリソースの有効活用が可能。 ?リソース不足の際には、スケールアウトが可能 ?ライセンス費用は稼働サーバー数分必要。 HA構成 ?稼働系、待機系でデータベースを共有。(Active & Standby) 10秒～1分 ○ △ ?稼働系に障害が発生した場合には待機系切り替わり、 早期サービス復旧が可能 ?枯れた技術 ?ライセンス費用は稼働系1台分のみ。 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 19
- 20. 基本設計で必要なこと ? 知識 – Oracle DBの各種機能(とそのシステム要件) ? 高可用性機能、パフォーマンス関連機能、EMのオプション – EEとSEの標準機能の差異 ? パラレルクエリ、オンラインリビルド、 – ハードやストレージ、バックアップ機能 ? 参考資料 – Oracleライセンスマニュアル – 各種OTN資料(セミナー資料やホワイトペーパ) – ハードベンダー資料(ベストプラクティス的な。。) ? 検証 – 作ってみる、やってみる Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 20
- 21. 詳細設計 詳細設計：DBの構成要素/方針、詳細を決める – データベースを作成するのに必要な要素 – データベースを使うのに必要な要素 – データベースを安全に使っていくのに必要な要素 設定定義書 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 21
- 22. DB作成に必要な要素 ? 物理設計 – データブロック設計 – エクステント管理設計 – セグメント管理設計 – 領域サイジング※ – 表領域設計 – レイアウト設計 – パラメータ設計 ※概算はもっと上位の工程で完了している Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 22
- 23. 使うのに必要な要素 ? ネットワーク接続設計 – リスナーやフェイルオーバ、ロードバランスなど ? ユーザ設計(役割、権限) Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 23
- 24. DBを安全に使っていくのに必要な要素 ? セキュリティ設計 – 監査機能 – パスワード管理 – 暗号化設計 ? 運用設計 – リソース監視設計(障害、リソース、パフォーマンス等) – メンテナンス(索引やフラグメント、ログ、パッチ適用等) ? バックアップリカバリ設計 – 取得方法(方法、対象) – サイクル、世代 – リストア、リカバリ方法 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 24
- 25. サイジングで悩み過ぎない ? 根拠は必要(これ絶対) ? どっかから持ってくる – 既存環境 – 過去案件 – SPECint ? 分からないものは分からない ? 仮定する ? 足す、引く、掛ける、割る Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 25
- 26. ファイル配置をちゃんと考える ? SAME（Stripe And Mirror Everything）? ? REDOログ?ファイルのメンバ ? アーカイブREDOログ?ファイルのdest ? バックアップ 例) DBファイル群のLVをストレージコピーで日次バックアップ リストアは、LV単位 RPOは限りなく直近まで？？？ RMANでバクアップからのスナップミラー？ Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 26
- 27. パラメータ設計 ? DB作成後に変更不可のもの – キャラクタセット、ブロックサイズ ? テストの結果で簡単に変わる(変更する)もの – メモリ系のパラメータ、REDOログファイル関連 ? デフォルト値じゃ駄目？ – セキュリティ関係、領域管理 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 27
- 28. 詳細設計書例 8-2-1.エクステント管理方式 エクステントとは、複数の連損くしたデータブロックの集合から構成される。Oracleデータベース の領域割り当て単位。 エクステント管理方式にはディクショナリ管理方式とローカル管理方式が選択可能だが、本システム ではローカル管理方式を採用する。採用根拠とそれぞれの管理方式の特徴を表XXX, △ △ △に示す。 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 28
- 29. 詳細設計で必要なこと ? 知識 – Oracle DBのアーキテクチャ ? 動作、メモリ構造、領域管理方法 – 各種機能に付随する考慮事項や制限 ? 選択方式、必須要件、機能同士の組み合わせ – パラメータ ? 初期化パラメータ、動作 ? 参考資料 – 各種マニュアルや技術本 – 各種OTN資料(セミナー資料やホワイトペーパ) – ググる？ ? 検証 – 作ってみる、やってみる Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 29
- 30. 余裕率や安全率は悪か？ ? 様々なことが考えられる – 予想外のデータ増加や処理増加(商売繁盛) – システム追加(処理追加) – メンテナンス(フラグメント解消) – リストア – チューニング(マテリアライズドビュー) ? 問題 – 色々なチームで掛け算してる内にありえない値に ?他のチームと連携する – そもそもの母数が大きい ?常識的に考える Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 30
- 31. 設計書作成にまつわるエトセトラ ? 設計書そもそも必要？ – DBが作れればいいというものではない – 未来のためにも必要 ? 設計書みんなで書く？一人で書く？ – 重複は排除する。参照する。 – Oracle関連の設計書を大人数で書かない ? 設計書≒設定定義書 – 根拠?方針?思想≠設定値 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 31
- 32. まとめ ? インプット大切 ? 仲間大切 ? 想像力大切 ? 意味ある設計が大切 ? サイジング悩み過ぎないのが大切 ? アーキテクチャ?機能に関する知識は大切 ? 迷ったり?分からなかったら検証するのが大事 ? 設計書大切 Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 32
- 33. 考察 ? そもそもなんでOracle DBだったんだっけ？ ? RDBMSの性能差?機能差＝システムの差？ ? 構成や機能の選択肢が少ない方が設計楽なんじゃ？？ ? そもそもなんでRDBMSなんだっけ？？ ? そもそもなんで自前で作っちゃうの？？ Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 33
- 34. 次回予告 ?PostgreSQLとOracleの 設計比較 comming soon… Copyright ? 2012 Kouta Shiobara, Inc. All Rights Reserved. 34