Oracle Databaseのスマートな開発／運用の鉄則
第5回 「共通基盤の構築はココでつまずく ～コスト効果を出すには細かな工夫が不可欠。熟練コンサルタントのノウハウも活用せよ～」
昨今、仮想化技術などを用いたサーバ統合により、社内／企業グループ内の共通基盤（クラウド・インフラ）を構築する企業が増えている。そうした共通基盤の導入にあたっては、技術面の壁に加えて組織など非技術面の壁も乗り越えなければならず、それを考慮して取り組みを進めなければプロジェクトが失敗することすらある。日ごろ、オラクル製品を用いた共通基盤の構築支援に携わるコンサルタントらに、共通基盤導入の成否を決めるポイントを聞いた（編集部）。
日本オラクル
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
本部長
小田圭二
日本オラクル
コンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
データベースソリューション第4部
シニアプリンシパルコンサルタント
加藤健
「今日、クラウド技術を用いた社内／グループ共通基盤を構築する企業が多いが、そうしたプロジェクトを支援していると、テクノロジー以外の面で考慮すべきことが非常に多く、それらが導入の成否を決めるくらい重要だということを痛感させられる」――これまで、多くの企業の共通基盤構築を支援してきた小田氏はこう語る。
■まず「社内標準」、「インフラ・ロードマップ」を作って関係者に周知する
共通基盤の構築において、小田氏が"最初の関門"と位置づけるのは、「標準化の推進」だ。開発方式の標準化やアプリケーション／ソフトウェアの統廃合と標準化（使用するバージョンの統一、アップグレード周期の統一）などを進め、各種コストと運用の手間を減らすのである。これをやらずにインフラだけを統合しても、その上で動くアプリケーションの運用コストは削減できず、共通基盤の導入効果が出にくくなる。
「例えば、アプリケーションごとに異なるソフトウェアをそのまま共通基盤上で運用したら、個々のソフトウェアに対応するために複雑な設計／運用を迫られる。また、あるアプリケーションが特定のソフトウェアの特殊な機能を使っていたが、その機能のバグ修正で共通基盤全体にパッチを当てなければならなくなり、動作検証などで多額の出費を強いられたというケースもある」（小田氏）。
さらに、共通基盤を今後どう成長させていくのかをロードマップにまとめ、関係者に提示する。その中には、システムを構成する各ソフトウェアのアップグレード予定も明記しておこう。そうすれば、各部門は「このタイミングでOracle Databaseがバージョン11gにアップグレードされるのなら、あのアプリケーションはその時期から共通基盤に載せよう」といった計画を立てやすくなる。
「例えば、ロードマップで『プラットフォームは6年ごとに刷新する』と寿命を決めたとする。、そして、現行プラットフォームの4年目にシステムを載せる場合、新プラットフォームがないとわずか2年（6年－4年）しか運用できないことになるため、新プラットフォームを平行して運用し、ユーザーが新旧両方のプラットフォームを選択できるようにする」（加藤氏）。
パッチに関しても、集積パッチを当てるタイミングをあらかじめ定め、公開しておく。こうして、すべての計画／情報を公開して厳格に運用するというポリシーを示せば、個々のアプリケーションのオーナー部門も先が見えるため文句が出にくくなるという。
門外不出のOracle現場ワザ
第2章 万全の予防とテストで致命的トラブルを回避するOracle管理 転ばぬ先の杖
■どの範囲でやるのか、だれが何をやるのかを決める
共通基盤をどう持つのか、どの範囲まで共通基盤に載せるのかを最初に明確にしておくことも大切だ。全社でやるのか、それとも特定部門だけやるのかといった方針の違いは、後々まで大きな影響を与える。「全社でやる」と決め、経営陣の大号令の下、トップダウンで進められるのなら話は早い。一方、会社としての方針が曖昧なまま、いくつかの部門が自発的に集まってやるケースは要注意だ。共通基盤の運用はどの部門がやるのか、コスト負担をどうするのか、将来的に基盤をどう成長させていくのかについて明確な計画がないと、プロジェクトが途中で頓挫しかねない。
■既存システムのオーナーには利点を示しつつ、トップダウンで移行を促す
新たに共通基盤を作る際には、既存システムの扱いに頭を悩ませることになる。共通基盤構築の大きな目的の1つはコスト削減であり、これは経営層の強い意向でもある。当然、CIOらは既存システムも共通基盤上に載せたいが、既存システムのオーナー部門からすれば、クラウドのような新たな技術を使ったインフラにシステムを載せるのは不安であり、できれば避けたいと思うこともあるだろう。
そんな彼らを説得するには、共通基盤のメリットをわかりやすく示し、魅力を感じてもらわなければならない。また、特定アプリケーションの動作の影響が他に伝播しないようにする仕組み（例：リソース制御）を実装しており、比較的安全に他システムと共存できることを説明し、不安を払拭することも重要になる。そのうえで、トップダウンの号令をかけて進めなければ、共通基盤上への移行がなかなか進まず、クラウドのコスト・メリットを出しづらくなる。
既存システムの移行をスムーズに進めるには、社内で使用しているサーバの機種やスペック、CPU使用率、使用形態、システム特性などを細かく洗い出し、「これはすぐに共通基盤上に載せる」、「これは検討のうえ決定」、「これは載せない」といった具合に優先順位を付ける。「私の経験では、このくらい強制的にやらないと前に進まない。各オーナー部門が自発的に移行することはないくらいに思ったほうがよい」（加藤氏）とのことだ。
■インフラの冗長化には「N＋1」構成も有効
基盤構築では、障害対策としての冗長構成をどう取るかがポイントの1つとなる。Oracle Real Application Clusterのようなクラスタ技術を使っている場合、複数サーバに負荷を均等に分散し、いずれかのサーバが障害で停止したら、その処理を他のサーバに均等に分散して処理を継続する仕組みを設計したくなるだろう。
「実際のシステムでは、均等な負荷分散による冗長化はアプリケーションも含めると制御が複雑すぎて、うまく機能しないこともある。その場合に有効なのは『N＋1』構成だ。常に1台のサーバを"空"の状態で待機させ、いずれかのサーバに障害が起きたら、そのサーバ上の処理を丸ごと待機サーバに移して処理を継続する。そして、障害発生サーバが復旧したら、今度はそれを待機サーバにする。このような冗長化構成がうまく動作した経験がある。この方式はフェールオーバーしてくることを考えなくてもよいため、均等な負荷分散に比べて各サーバの稼働率を上げやすいといったメリットもある。サーバが4台以上になるときは、この構成も検討することをお勧めする」（加藤氏）。
■バックアップは「インフラ全体」と「個別アプリケーション」で分ける
バックアップに関しては「時間が重なる」という問題にぶつかりやすい。しかも複数システムが共存する共通基盤では、「どのタイミングでバックアップするのが適切か」という面倒な問題もつきまとう。通常は夜間にバックアップをとるが、その時間帯に多くのシステムでバッチ処理が動いている場合、共通基盤全体を通した「完全なデータベース静止点」が存在しないことになるからだ。また、バックアップからリストアする場合は全システムのデータが戻ってしまうため、個別システムの要求に応じて安易にリストアすることはできない。
この問題に関しては、割り切って対応するしかない。まず、共通基盤全体については、それを管理するインフラ・チームが定期的にバックアップをとる。ただし、これは共通基盤に障害が生じたときのためのバックアップであり、個々のアプリケーションのデータは保証の対象外だ。それについては、個々のアプリケーションのオーナー部門が自らバックアップをとり、アプリケーションに障害が起きたら、そのデータを使って復旧するのである。
門外不出のOracle現場ワザ
第3章 データベース管理 転ばぬ先の杖～設計編
■公平なコスト負担のためには利用実績の細かな記録が不可欠
部門ごとの利用実績に応じて公平なコスト負担を求めることも、共通基盤の運用では不可欠となる。そのためには、インフラの利用実績を詳細に記録しなければならない。
「あるお客様では、CPUの使用量に応じて課金する体系を導入した。CPU使用率を10％ごとに区切り、その状況を5秒ごとに記録して利用実績を出す。そして、例えばある月の使用率平均が13％だったら、20％のコスト負担を求めるといった運用を行っている」（加藤氏）。
ただし、事業部門からすれば、年間で予算を持っていることが多く、毎月のコスト負担額が変動するよりは、一定額に決まっていたほうがよい。それに当然、使った分以上は支払いたくない。
そこで、事前に毎月の利用量を予測し、それに応じた額を1年間支払う決まりにする方法もある。事前に各部門の代表的なアプリケーションについて動作検証を行い、それぞれがどれだけインフラを使うかを調査するのだ。そのようにして予測の精度を高めるとともに、毎月の利用状況も細かくチェックし、予測と違った利用実績が出た場合には、その実績に基づいて次年度のコスト負担額を定めるといった運用になる。
なお、利用実績をメモリ上に保持するだけでは、システム障害発生時に、その記録が失われ、正確な請求ができなくなる。よって、必ずこまめにファイルへ記録しておこう。公平なコスト負担を求めようとすれば、ここまで細かな部分に気を配った運用が必要になるのだ。
■トラブル切り分けのための情報は必ず仕込む
最後に、共通基盤の運用時に忘れてはならないことを1つ。トラブル発生時の原因切り分けのための仕組みや情報は必ず仕込んでおこう。
共通基盤にはさまざまなシステムが相乗りするので、どのシステムが原因で障害が起きたのかを判断できる仕組みを整えておかないと、原因を究明できず、各システムのオーナーへの説明責任も果たせない。定期的にシステムのCPU／メモリ使用率をチェックし、障害が起きる前に異変に気づくくらいでないと、安定した運用はできないのだ。
「データベースなら、Oracle Databaseが残す統計情報は定期的にチェックしておきたい。その用途に適しているツールを挙げるとすれば、『Oracle Diagnostics Pack』だろう。このツールを使えば、アクティブなセッションの履歴（Active Session History）を記録し、それを基にして速やかに障害の原因を特定できるはずだ。併せて、Oracle Tuning Packを用いると適切なアドバイスを得ることができる。共通基盤化すると、個々のアプリケーションの詳細をDBAが把握しきれないケースもあるので、ツールの活用は非常に有効だ。」（小田氏）。
共通基盤の構築／運用を成功させるには、以上に紹介したようなノウハウが不可欠であり、それらが導入の成否を決めると言っても過言ではない。特にオラクル製品を用いた基盤構築のノウハウは、小田氏や加藤氏のようなオラクルのコンサルタントに聞くのが一番だ。彼らが持つノウハウもうまく活用し、自社に最適な共通基盤を構築していただきたい。
門外不出のOracle現場ワザ
第0章 オラクル社のテクノロジーコンサルタントって？
Oracle Direct
オラクル製品を用いた共通基盤の構築にご興味を持たれたら、まずはOracleDirectへ。
あなたのニーズに合ったオラクル・コンサルタントをタイムリーにご紹介できます。
日本オラクルコンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
本部長
小田圭二
日本オラクルコンサルティングサービス統括
テクノロジーソリューションコンサルティング統括本部
データベースソリューションコンサルティング本部
データベースソリューション第4部
シニアプリンシパルコンサルタント
加藤健
「今日、クラウド技術を用いた社内／グループ共通基盤を構築する企業が多いが、そうしたプロジェクトを支援していると、テクノロジー以外の面で考慮すべきことが非常に多く、それらが導入の成否を決めるくらい重要だということを痛感させられる」――これまで、多くの企業の共通基盤構築を支援してきた小田氏はこう語る。
■まず「社内標準」、「インフラ・ロードマップ」を作って関係者に周知する
共通基盤の構築において、小田氏が"最初の関門"と位置づけるのは、「標準化の推進」だ。開発方式の標準化やアプリケーション／ソフトウェアの統廃合と標準化（使用するバージョンの統一、アップグレード周期の統一）などを進め、各種コストと運用の手間を減らすのである。これをやらずにインフラだけを統合しても、その上で動くアプリケーションの運用コストは削減できず、共通基盤の導入効果が出にくくなる。
「例えば、アプリケーションごとに異なるソフトウェアをそのまま共通基盤上で運用したら、個々のソフトウェアに対応するために複雑な設計／運用を迫られる。また、あるアプリケーションが特定のソフトウェアの特殊な機能を使っていたが、その機能のバグ修正で共通基盤全体にパッチを当てなければならなくなり、動作検証などで多額の出費を強いられたというケースもある」（小田氏）。
さらに、共通基盤を今後どう成長させていくのかをロードマップにまとめ、関係者に提示する。その中には、システムを構成する各ソフトウェアのアップグレード予定も明記しておこう。そうすれば、各部門は「このタイミングでOracle Databaseがバージョン11gにアップグレードされるのなら、あのアプリケーションはその時期から共通基盤に載せよう」といった計画を立てやすくなる。
「例えば、ロードマップで『プラットフォームは6年ごとに刷新する』と寿命を決めたとする。、そして、現行プラットフォームの4年目にシステムを載せる場合、新プラットフォームがないとわずか2年（6年－4年）しか運用できないことになるため、新プラットフォームを平行して運用し、ユーザーが新旧両方のプラットフォームを選択できるようにする」（加藤氏）。
パッチに関しても、集積パッチを当てるタイミングをあらかじめ定め、公開しておく。こうして、すべての計画／情報を公開して厳格に運用するというポリシーを示せば、個々のアプリケーションのオーナー部門も先が見えるため文句が出にくくなるという。
門外不出のOracle現場ワザ
第2章 万全の予防とテストで致命的トラブルを回避するOracle管理 転ばぬ先の杖
■どの範囲でやるのか、だれが何をやるのかを決める
共通基盤をどう持つのか、どの範囲まで共通基盤に載せるのかを最初に明確にしておくことも大切だ。全社でやるのか、それとも特定部門だけやるのかといった方針の違いは、後々まで大きな影響を与える。「全社でやる」と決め、経営陣の大号令の下、トップダウンで進められるのなら話は早い。一方、会社としての方針が曖昧なまま、いくつかの部門が自発的に集まってやるケースは要注意だ。共通基盤の運用はどの部門がやるのか、コスト負担をどうするのか、将来的に基盤をどう成長させていくのかについて明確な計画がないと、プロジェクトが途中で頓挫しかねない。
■既存システムのオーナーには利点を示しつつ、トップダウンで移行を促す
新たに共通基盤を作る際には、既存システムの扱いに頭を悩ませることになる。共通基盤構築の大きな目的の1つはコスト削減であり、これは経営層の強い意向でもある。当然、CIOらは既存システムも共通基盤上に載せたいが、既存システムのオーナー部門からすれば、クラウドのような新たな技術を使ったインフラにシステムを載せるのは不安であり、できれば避けたいと思うこともあるだろう。
そんな彼らを説得するには、共通基盤のメリットをわかりやすく示し、魅力を感じてもらわなければならない。また、特定アプリケーションの動作の影響が他に伝播しないようにする仕組み（例：リソース制御）を実装しており、比較的安全に他システムと共存できることを説明し、不安を払拭することも重要になる。そのうえで、トップダウンの号令をかけて進めなければ、共通基盤上への移行がなかなか進まず、クラウドのコスト・メリットを出しづらくなる。
既存システムの移行をスムーズに進めるには、社内で使用しているサーバの機種やスペック、CPU使用率、使用形態、システム特性などを細かく洗い出し、「これはすぐに共通基盤上に載せる」、「これは検討のうえ決定」、「これは載せない」といった具合に優先順位を付ける。「私の経験では、このくらい強制的にやらないと前に進まない。各オーナー部門が自発的に移行することはないくらいに思ったほうがよい」（加藤氏）とのことだ。
■インフラの冗長化には「N＋1」構成も有効
基盤構築では、障害対策としての冗長構成をどう取るかがポイントの1つとなる。Oracle Real Application Clusterのようなクラスタ技術を使っている場合、複数サーバに負荷を均等に分散し、いずれかのサーバが障害で停止したら、その処理を他のサーバに均等に分散して処理を継続する仕組みを設計したくなるだろう。
「実際のシステムでは、均等な負荷分散による冗長化はアプリケーションも含めると制御が複雑すぎて、うまく機能しないこともある。その場合に有効なのは『N＋1』構成だ。常に1台のサーバを"空"の状態で待機させ、いずれかのサーバに障害が起きたら、そのサーバ上の処理を丸ごと待機サーバに移して処理を継続する。そして、障害発生サーバが復旧したら、今度はそれを待機サーバにする。このような冗長化構成がうまく動作した経験がある。この方式はフェールオーバーしてくることを考えなくてもよいため、均等な負荷分散に比べて各サーバの稼働率を上げやすいといったメリットもある。サーバが4台以上になるときは、この構成も検討することをお勧めする」（加藤氏）。
■バックアップは「インフラ全体」と「個別アプリケーション」で分ける
バックアップに関しては「時間が重なる」という問題にぶつかりやすい。しかも複数システムが共存する共通基盤では、「どのタイミングでバックアップするのが適切か」という面倒な問題もつきまとう。通常は夜間にバックアップをとるが、その時間帯に多くのシステムでバッチ処理が動いている場合、共通基盤全体を通した「完全なデータベース静止点」が存在しないことになるからだ。また、バックアップからリストアする場合は全システムのデータが戻ってしまうため、個別システムの要求に応じて安易にリストアすることはできない。
この問題に関しては、割り切って対応するしかない。まず、共通基盤全体については、それを管理するインフラ・チームが定期的にバックアップをとる。ただし、これは共通基盤に障害が生じたときのためのバックアップであり、個々のアプリケーションのデータは保証の対象外だ。それについては、個々のアプリケーションのオーナー部門が自らバックアップをとり、アプリケーションに障害が起きたら、そのデータを使って復旧するのである。
門外不出のOracle現場ワザ
第3章 データベース管理 転ばぬ先の杖～設計編
■公平なコスト負担のためには利用実績の細かな記録が不可欠
部門ごとの利用実績に応じて公平なコスト負担を求めることも、共通基盤の運用では不可欠となる。そのためには、インフラの利用実績を詳細に記録しなければならない。
「あるお客様では、CPUの使用量に応じて課金する体系を導入した。CPU使用率を10％ごとに区切り、その状況を5秒ごとに記録して利用実績を出す。そして、例えばある月の使用率平均が13％だったら、20％のコスト負担を求めるといった運用を行っている」（加藤氏）。
ただし、事業部門からすれば、年間で予算を持っていることが多く、毎月のコスト負担額が変動するよりは、一定額に決まっていたほうがよい。それに当然、使った分以上は支払いたくない。
そこで、事前に毎月の利用量を予測し、それに応じた額を1年間支払う決まりにする方法もある。事前に各部門の代表的なアプリケーションについて動作検証を行い、それぞれがどれだけインフラを使うかを調査するのだ。そのようにして予測の精度を高めるとともに、毎月の利用状況も細かくチェックし、予測と違った利用実績が出た場合には、その実績に基づいて次年度のコスト負担額を定めるといった運用になる。
なお、利用実績をメモリ上に保持するだけでは、システム障害発生時に、その記録が失われ、正確な請求ができなくなる。よって、必ずこまめにファイルへ記録しておこう。公平なコスト負担を求めようとすれば、ここまで細かな部分に気を配った運用が必要になるのだ。
■トラブル切り分けのための情報は必ず仕込む
最後に、共通基盤の運用時に忘れてはならないことを1つ。トラブル発生時の原因切り分けのための仕組みや情報は必ず仕込んでおこう。
共通基盤にはさまざまなシステムが相乗りするので、どのシステムが原因で障害が起きたのかを判断できる仕組みを整えておかないと、原因を究明できず、各システムのオーナーへの説明責任も果たせない。定期的にシステムのCPU／メモリ使用率をチェックし、障害が起きる前に異変に気づくくらいでないと、安定した運用はできないのだ。
「データベースなら、Oracle Databaseが残す統計情報は定期的にチェックしておきたい。その用途に適しているツールを挙げるとすれば、『Oracle Diagnostics Pack』だろう。このツールを使えば、アクティブなセッションの履歴（Active Session History）を記録し、それを基にして速やかに障害の原因を特定できるはずだ。併せて、Oracle Tuning Packを用いると適切なアドバイスを得ることができる。共通基盤化すると、個々のアプリケーションの詳細をDBAが把握しきれないケースもあるので、ツールの活用は非常に有効だ。」（小田氏）。
共通基盤の構築／運用を成功させるには、以上に紹介したようなノウハウが不可欠であり、それらが導入の成否を決めると言っても過言ではない。特にオラクル製品を用いた基盤構築のノウハウは、小田氏や加藤氏のようなオラクルのコンサルタントに聞くのが一番だ。彼らが持つノウハウもうまく活用し、自社に最適な共通基盤を構築していただきたい。
門外不出のOracle現場ワザ
第0章 オラクル社のテクノロジーコンサルタントって？
Oracle Direct
オラクル製品を用いた共通基盤の構築にご興味を持たれたら、まずはOracleDirectへ。
あなたのニーズに合ったオラクル・コンサルタントをタイムリーにご紹介できます。
Printer View