Oracle Databaseのスマートな開発／運用の鉄則
「トラブルを防ぎ、性能もアップできる！」
「Oracle Databaseはちょっと気をつけるだけでもっと安全に、もっと高い性能で運用できる。しかもそれは、すごく簡単で当たり前のことをするだけでいい。」それをぜひ伝えたい！と考えるオラクル社内のエンジニアが集まって、Oracle Databaseの鉄則について議論しました。それがこの「トラブルを防ぎ、性能もアップできる！ Oracle Database開発／運用の鉄則」です。
《Oracle Databaseのスマートな開発／運用の鉄則》シリーズをお見逃しなく！
集まったのは以下の4人。いずれもお客様と日頃から接し、「こうするともっといいのでは？」というそれぞれの思いを持ち寄りました。
テクノロジー製品事業統括本部
データベースソリューション本部
Exadataソリューション部
シニアエンジニア
秋山真一
カスタマーサービス統括
データベーステクノロジーサポート本部
本部長
藤田一哉
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
本部長
小田圭二
産業営業統括本部
オラクルダイレクト
テクニカルサービスグループ
プリンシパルセールスコンサルタント
宇多津真彦
 司会の新野淳一（Publickey） |
司会はブログ「Publickey」のブロガーでITジャーナリストの新野淳一が行いました。
―――まずはそれぞれ普段はどのような仕事をされているのか、簡単に自己紹介していただけますか？ 最初はこの議論の言い出しっぺでもある秋山さん、お願いします。
秋山：
Oracle Exadataのプリセールスをしています。プリセールスの中でお客様にお会いしていると、現状のシステム構成でもっと性能を上げられるケースにときどき遭遇します。例えば、既存の環境に対してExadataで1000倍も速くなる、というケース。もちろんExadataは速いマシンですが、これだけ性能比がある原因は、Oracle Database Enterprise Editionの標準機能であるパラレルクエリを使っていないから、といった現状の環境にあることがほとんどなんですね。
パラレルクエリは、最初に設定しておけばあとはOracle Databaseが全部自動でやってくれるという、とても簡単なものです。プリセールスの仕事では新製品や新機能の紹介が中心で、既存の製品の使いこなしまではなかなか説明しきれないのですが、でもこういう状況はなんとかしたい。今日はそういう話ができたらいいなと思っています。
藤田：
サポート部門でマネジャーをやっています。秋山さんの話に同感で、サポートの現場でも、やっぱり何でこんなトラブルが起きるんだろうっていうことが多いんです。
データベースのすごく大事な機能に耐障害性がありますが、使っている人間がその重要性をを理解してないとせっかくの機能が活かされないんですね。その場合、何かあるとお客様自身、復旧にすごく労力がかかるので、そういうところが少しでも減らせればなと。そうすると僕の仕事がなくなっちゃうかもしれませんけど、それもいいかな（笑）。
小田：
コンサルティング部門のマネジャーをしています。ミッションクリティカル系の現場が多くて、そういう現場は一番見ているかもしれません。お客様が藤田さんのいるサポートに問い合わせる前に、その現場にはコンサルがいたりするわけです。ですから藤田さんからすると、何でこんな問い合わせが来るんだろう？ という裏を知っていたりするのがコンサルの立場だったりはしますね（笑）。
もちろん、逆にコンサルがいないからそういった問い合わせが来るケースもあるんでしょうけれど。
私たちの会社は、コンサル部門も含め、IT業界に対してオラクル製品に関するノウハウを普及するという面で貢献しないといけないと思っています。
宇多津：
オラクルダイレクトでプリセールスのエンジニアをしています。オラクルダイレクトは、弊社製品を購入していただく際のお客様お問い合わせ窓口ですので、一般の技術者やお客様から直接問い合わせをいただきます。製品の基本機能でどこまで何ができるのか、といったようなところを、マニュアルをきちんと押さえつつ紹介しているというような仕事が多いです。
■基本はアーカイブログモードを使ってほしい
―――さて、最初の話題としてはOracle Databaseの運用についてお話いただけたらと思っています。
ここにあるアンケート結果があります。約1000人のOracle Databaseユーザーに「アーカイブログモード」で運用していますか？ と聞いたところ、27％が「必ずアーカイブログモードにする」と答えたのに対し、43％が「必要に応じてアーカイブログモードにしている」、9％が「アーカイブログモードにしたことがない」もしくは「知らない」となっています。運用ではあまりアーカイブログモードが使われていないようですね？
 秋山真一氏 |
秋山：
アーカイブログモードにしていない、ということは、いざとなったらデータが消えてしまってもかまわなということになります。ですのでアーカイブログモードが必要ではない、というケースはほとんどないはずなんですよね。もちろんテスト環境とかでは必要ではないケースもあるとは思うのですが。
藤田：
たぶん、本番環境で必要ないというわけではなく、開発環境とかテストとかフェーズごとに違った答えが出てくるとは思うんです。
秋山：
開発フェーズでも、検証のときにはアーカイブログモードにしておかないと負荷テスト時の反応が違ってきますね。
宇多津：
ですね。どれくらいログを出力するのか、といったところとか。
小田：
モードが違うとログの量も変わりますからね。やはりアーカイブログモードで検証すべきですね。それに大量データでの検証だと、検証環境でデータが壊れたりしたときにアーカイブログモードでないと復旧できないので、全部ロードし直しになります。それに数日かかったりすれば検証スケジュールも遅延しかねない。
宇多津：
コールドバックアップをとっていればいい、というのでは解決できない問題ですよね。
小田：
アーカイブログモードにしていないとリカバリーできないケースがありますから、障害が起きたときにリカバリーコマンドを実行する予定であればアーカイブログモードでの運用をしていただくのが基本ですね。
藤田：
私の最近の印象では、お客様はこうしたリカバリーの重要性は理解しつつ、でもめったにシステムは止まるはずないと考えていたりしますね。最近のデータベースは、OSのように堅牢であるべきで、そのシステムが落ちるのって3年に一回ありますか？ というぐらいな期待値を持っていたりします。
 宇多津真彦氏 |
秋山：
たしかに期待値は上がってますね。
藤田：
ただ、サポートの私たちは毎日たくさんのお客様と接しているのでシステムが止まってしまうことを目にする機会も多く、その重要性を強く意識します。まあ、それはおいておいて、経験のあるお客様ほど、逆にシステムを信頼してしまってアーカイブログモードにしていない、ということもあるかもしれませんね。
だからこそ、事故が起きたときにはやはりおおごとになるので、ぜひアーカイブログモードをお勧めしておきます。
秋山：
Oracle Enterprise Managerの設定画面から、1日1回自動でバックアップして、そのときに不要なログは消す、という設定で、あとはほとんど手間はかかりませんからね。
■チューニングは運用が始まってからも続けて
―――次はチューニングです。先ほどのユーザーアンケートによると、チューニングのための情報をコマンドラインから得ている人がまだ多いようです。32％がコマンドラインから。そして29％がStatspackを利用していて、22％はOracle Enterprise Managerを利用していますね。
秋山：
コマンドラインから情報を得ている、ということは動的パフォーマンスビューを見ているということでしょうね。おそらく、Oracle DatabaseのStandard Editionのお客様が多いのかもしれません。このエディションだとコマンドラインからしか情報がとれませんからね。
 藤田一哉氏 |
藤田：
コマンドラインから情報収集をしてチューニングすることで問題ないと思います。そのスキルに自信がない方は、Enterprise Editionの機能としてOracle Enterprise Managerを使うとかなり深いところまで分析して教えてくれるんですね。
それからせっかく運用前にチューニングをしても、運用が始まった後でも統計を取って最新の状態を把握させておかないと、数カ月後に遅くなってしまうことがあります。
運用を始めてからチューニング周りのトラブルの多くはメモリ周りなんですね。サイジングのところ。そういったところまでチェックしていただければうまくいくと思います。
実はOracle Databaseの新しいバージョンではそういうところも自動化されるようになってきているので、古いバージョンのまま運用でカバーするよりもアップグレードして自動化機能をどんどん使っていただく方がいいのではないかと。
秋山：
保守契約（Oracle Premier Support）をしていれば、追加コストなしに何回でも新バージョンの入手ができるんです。あまりご存じない方が多いのですが。そういう特典をうまく使っていただけたらと思います。
■バインド変数のテクニック
それからチューニングに関連してアプリケーションの典型例でいうと、バインド変数を使っていない例があります。バインド変数というのは、アプリケーションの中でSQLを書くときに条件のところをこのバインド変数にしておくと、Oracle Database側では毎回構文解釈をしなくて済むんです。その分処理が減って実行が速くなる。
ところがバインド変数を使わずに毎回文字列としてSQLを組み立てていると、毎回違うSQLとして構文解釈をするし、その結果をメモリにとっておくなど余計なメモリも使うことになります。さらにこの方法だとSQLインジェクションというセキュリティの攻撃にも弱くなります。
藤田：
メモリを圧迫してたり、負荷が高くて遅い、データが増えたら遅くなったというケースの多くで、バインド変数が絡んでますね。バインド変数のテクニックはぜひ積極的に使っていただきたい。
■パラレルを使わないともったいない
―――Oracle Databaseのパラレル機能を利用したことがありますか？ という問いには、75％の人が「ない」と答えていますね。
秋山：
それはすごくもったいないですね。いまや普通のパソコンだってデュアルコアのプロセッサですから。
今はオプティマイザもかなり賢くなっていて、Oracle Databaseでパラレルを有効にしておけば、必要なときだけパラレルを有効にしてくれて、滅多に弊害もありません。
 小田圭二氏 |
OLTPのアプリでも、選択のプルダウンメニューを出すたびに実は裏でフルスキャンかけてトップテンリストみたいなのを作るケースもあって、そういうときの集計業務ではパラレルの効果があったりします。
小田：
今後のCPUのトレンドは、クロックはあまり上がらずコア数が増えていくことを考えると、パラレルを使用してメリットを得る必要が増えてくるはずです。なので、ぜひパラレル化を検討していただきたいです。向き不向きがあるので、使用前にはテストをお勧めします。
秋山：
特にどんなケースで有効かといえば、大量のデータを見に行くような処理でしょう。100万件から1件取り出すのなら索引を使うのが効果的ですが、100万件から10万件取り出して集計するのならパラレルのほうが非常に効果的です。
小田：
別の言い方をするとすれば、バッチ処理やDWH、BI系の処理はパラレルの適性が高めです。
■インデックスはテストしながら付ける。パーティションも重要
―――今、インデックスの話もでてきましたが、チューニングについてもう少しテクニックがあれば教えてください。
小田：
インデックスはたくさん付ければいい、というものではないので、無駄なインデックスが作られるのは「ここにインデックスがいるんじゃないか」という予測だけで作っておいて結局使われない、というパターンですかね。
秋山：
プライマリキーだけ作って、あとはテストして遅かったらインデックスを作る、など検証しながら作業するのがいいですね。チューニングとは、テストをして現状を把握してボトルネックを想定して手を打つ。そしてそれをテストで確認する、というPDCAを回せるかどうかだと思います。
それからストレージの設計も大事です。ストレージもパラレルにやった方が速いので、1つのディスクに集中しないほうがいい。例えば、ストレージにディスクがたくさん搭載されていても、適切なディスク割当が実施されておらず、ほんの数本のディスクにアクセスが集中していた、ということもあります。せっかくたくさんディスクを積んでいるのに、もったいない。
藤田：
ストレージの設定までいかなくても、パーティション表を使うことでも大きく変わりますね。
秋山：
パーティション・ワイズ・ジョインなどはめちゃくちゃ速くなりますからね。
小田：
バッチ処理に特に効きますね。すごく速くなります。OLTPならインデックス、バッチやデータウェアハウス系はパーティションとパラレルの見直し、というのはテクニックの鉄則かもしれません。
■3ノード以上のRACが絶対におすすめ！
―――最後は高可用性についての話題にしたいと思います。アンケートでは52％のユーザーが高可用性構成の経験がないと答えているようです。Oracle Real Application Cluster（RAC）を含め、高可用性の鉄則があれば教えてください。
秋山：
RACっていう観点だと、3ノード以上で構成したRACってどう思いますか。
小田：
私はお勧めです。
宇多津：
僕もお勧めですね。
小田：
というのも2ノードのRACだと、障害時の切り替えの早いHA（ハイアベイラビリティ構成）と同じ程度のメリット享受となってしまうからなんです。切り替えの早いHAはそれはそれで価値があるのですが、片方死んでも大丈夫なハードウェアリソースをあらかじめ用意すると、それってかなりコストがかかってしまいます。
コストの観点からは、たとえばRACの3ノード構成で、1台コケても2ノードでいけるという構成であれば、1台分を2台で引き受ければいい。つまり、1台あたりの余裕も少なくていい。これが2ノードだと余裕率が理屈上50%必要なわけです。つまり、ノード数が多いほど資源を有効に使える計算になります。
藤田：
2ノードだと、アプリケーションをノードごとに固定して、お互いにクロスでバックアップにしている構成が多いです。そのため片方がダウンしたときでも動作はし続けるのですが、縮退率が50％になってしまいます。
宇多津：
今どきのシステムって、サーバー1台が8割、9割の使用率で組まれているので、処理性能が半分になると現場のビジネスが成り立たないんですよね。可用性でRACを入れているのにビジネスの機会喪失になってしまいます。そういう意味でRACを組むのであれば3ノード以上がお勧めですね。
■部門を超えてリソースを共有しよう
―――仮想化によってサーバー統合、あるいは高可用性を実現しているお客様のケースも増えてきたのではないですか。
秋山：
サーバー統合は、コストダウンのためという理由が大きいと思うのですが、ハードウエアは最近かなり安くなってきたので、最近ではハードウエアの台数を減らしてもそれほど大きなコスト削減効果は出ない可能性があります。
そこで、同時に運用手順などの標準化、アプリケーションの標準化、開発手法の標準化などをすることで、大きなコスト削減になると思います。
小田：
ただ、組織の壁、業務の壁といったものがあり、物理的なサーバー統合はできても、それを本当の意味でサーバー統合にするのは難しいですね。サーバー統合したようで、実は仮想サーバーごとにリソースがきっちり分かれていたりする。
秋山：
例えば、昼間は仮想サーバーごとにリソースをきちんと区分していたとしても、夜間バッチはほかのアプリはほとんど動いていないんだから、サーバー内の8個のコアを全部使って処理する、といった組織の壁を越えてリソースを融通し合うことができると理想的ですね。
小田：
そう。統合によるメリットを実現するためには、関係部署みんなでリソースを共有しようよ、っていう文化にしないといけないですね。
ですので私のお客様の場合には、そういう組織を超えたリソース配分ができるようにコンサルティングでリードします。組織を越えないと、やっぱりオラクル製品のいいところも出てこないし、お客様にとってのメリットがないんです。
それを部門間の課金のための仕組みも含めて、コンサルするんですよね。統合基盤や統合DB、プライベートクラウドをどう企画するか、課金の仕掛けはこうしましょう、組織を超えて推進する方法はこうしましょうと。
―――最後はOracle Databaseの話から組織の話にまで発展してしまいました。今日皆さんにお話いただいた内容は、多くのエンジニアの方の役に立つと思います。ありがとうございました。
（文：Publickey 新野淳一）
Printer View