最適なシステム・パフォーマンスは設計段階で決まり、その効果は使用して いるシステムが存続するかぎり持続します。初期の設計段階でパフォーマン ス問題を慎重に検討すると、本番環境でのチューニングが容易になります。
この章の構成は、次のとおりです。
オラクル社の新しい方法論 投資の選択肢について スケーラビリティについて システム・アーキテクチャ アプリケーション設計の原則
ワークロードのテスト、モデル化および実装 新規アプリケーションのデプロイ
オラクル社の新しい方法論
コンピュータ・システムの規模が拡大して複雑になり、ビジネス・アプリケーションでのインタ ーネットの役割が重要になるに従い、システムのパフォーマンスはますます重要になっていま す。オラクル社では、この状況にあわせて、設計およびパフォーマンスに関する長年の経験に基 づいてパフォーマンス方法論を作成しました。この方法論は、システム・パフォーマンスを大幅 に向上させる、明瞭で簡潔なアクティビティについて説明したものです。
パフォーマンス計画は、その効果によって異なります。業務システムや意思決定支援システムな どのようにシステムの目的が異なると、求められるパフォーマンス・スキルも異なります。この マニュアルでは、データベース設計者、管理者またはパフォーマンス・エンジニアが重点的に考
慮する必要がある事柄について説明します。
システムのパフォーマンスは、設計してシステムに組み込むものです。偶然にパフォーマンスが よくなるわけではありません。パフォーマンスの問題は、通常、システム・リソースの競合、ま たはシステム・リソースを使い切ったことが原因で発生します。システム・リソースを使い切る と、システムを拡張してパフォーマンス・レベルを向上させることができません。ここで説明す る新しいパフォーマンス方法論は、データベースの慎重な計画と設計に基づいており、システ ム・リソースを使い切ったことが原因で停止時間が発生するのを防止します。リソースの競合を 除去することによって、ビジネス要件を満たすレベルまでシステムをスケーラブルにすることが できます。
投資の選択肢について
高性能のプロセッサ、メモリーおよびディスク・ドライブが比較的安価に入手できることから、
安易なシステム・リソースの追加購入によって、パフォーマンスを改善しようとする傾向があり ます。多くの場合、新しいCPU、メモリーまたはディスク・ドライブの増設によって、確かにパ フォーマンスは一時的には改善されます。しかし、ハードウェア増設によるパフォーマンスの改 善は、目の前の問題の短期的解決にすぎません。アプリケーションに対する需要と負荷が増加し 続けると、すぐに同じ問題に直面する可能性があります。
状況によっては、ハードウェアを増設してもシステムのパフォーマンスがまったく改善されない 場合もあります。システム設計が不適切な場合、追加のハードウェアをいくつ割り当ててもパフ ォーマンスは改善されません。ハードウェアを追加購入する前に、アプリケーション内にシリア ライズやシングル・スレッドがないことを確認してください。長期的には、各ビジネス・トラン ザクションで使用する物理リソース数の観点からみて、アプリケーションの効率を上げるほうが 一般的には効果的です。
スケーラビリティについて
スケーラブルという用語は、開発環境の様々な状況で使用されます。次の項では、アプリケーシ ョン設計者とパフォーマンス・エンジニアを対象にしたスケーラビリティについて説明します。
このセクションでは、次のトピックについて説明します。
スケーラビリティとは
システムのスケーラビリティ スケーラビリティを妨げる要因
スケーラビリティとは
スケーラビリティとは、より多くのワークロードを処理するためのシステムの能力で、それと比 例してシステム・リソースの使用が増大します。
スケーラブルなシステムでは、ワークロードが2倍になると、使用するシステム・リソースも2倍
になります。これは当たり前のようですが、システム内で競合が発生すると、元のワークロード に対し、リソースの使用が2倍よりも多くなる場合があります。
リソースの競合によってスケーラビリティが低くなる例を次に示します。
ユーザー数の増加に伴い、アプリケーションでかなりの同時実行性管理が要求される場合 ロック・アクティビティが増加した場合
データ整合性に関するワークロードが増加した場合
オペレーティング・システムのワークロードが増加した場合
データ量の増加に伴い、トランザクションでデータ・アクセスの増加が要求される場合 SQLと索引の不適切な設計が原因で、同じ戻り行数に対する論理I/O数が増加した場合
データベース・オブジェクトのメンテナンス時間が長くなったことで、可用性が低下した場 合
アプリケーションのワークロードが増加してもこれ以上のスループットの向上は不可能という点 までシステム・リソースを使い切った場合、そのアプリケーションは拡張性がありません。この ようなアプリケーションでは、スループットが固定化し、レスポンス時間が長くなります。
リソースを使い切った例を次に示します。
ハードウェアを使い切った場合
大量トランザクションでの表スキャンによって、ディスクI/O不足が発生する場合
過剰なネットワーク・リクエストによって、ネットワークとスケジューリングにボトルネッ クが発生する場合
メモリー割当てによって、ページングとスワッピングが発生する場合
プロセスやスレッドの過剰な割当てによって、オペレーティング・システムのスラッシング が発生する場合
このことから、アプリケーション設計者は、ユーザー数やデータ量に関係なく同一リソースを使 用するように設計し、限界を超える負荷をシステム・リソースに与えないようにする必要があり ます。
システムのスケーラビリティ
インターネット経由でアクセスできるアプリケーションでは、パフォーマンスや可用性の要件が さらに複雑になります。
インターネット専用に設計および作成されたアプリケーションもありますが、一般会計アプリケ ーションなどの典型的なバック・オフィス・アプリケーションであっても、データの一部または すべてをオンラインで利用できるようにすることが必要な場合があります。
インターネット時代のアプリケーションの特徴は、次のとおりです。
1日24時間、1年365日の可用性
同時ユーザー数が予測不可能で正確な把握が困難 容量の計画が困難
あらゆるタイプの問合せが選択可能 多層アーキテクチャ
ステートレスなミドルウェア 短い開発期間
最小限のテスト時間
次の図は、需要が増大するときの典型的なワークロード成長曲線を示しています。アプリケーシ ョンは、ワークロードの増大に伴い拡張できる必要があります。また、増大する需要をサポート するためにハードウェアが追加されたときにも拡張できる必要があります。設計に失敗すると、
ハードウェア・リソースの増設や再設計に関係なく、実装が限界に達する可能性があります。
図2-1 ワークロード成長曲線
「図2-1 ワークロード成長曲線」の説明
アプリケーションは非常に短期間での開発が要求され、テストや評価の時間も限定されていま す。しかし、一般的に、不適切な設計は、後でシステムの再構築および再実装が必要になること を意味します。アーキテクチャや実装に既知の制限があるアプリケーションをインターネット上 にデプロイした場合、ワークロードが需要予測を超過すると、実際に障害が発生する可能性があ ります。ビジネスの観点からは、低いパフォーマンスは顧客を失うことにつながります。Webユ ーザーの場合、7秒以内にレスポンスがないと、ユーザーの興味は二度と喚起できません。
多くの場合、新規の実装に移行するためにシステムを停止する間のコストも含めて、システムを 再設計するコストは、最初からシステムを適切に構築する場合のコストを上回ります。ここでの
教訓は単純明快です。開発の当初からスケーラビリティに留意して設計と実装を行うということ です。
スケーラビリティを妨げる要因
アプリケーションを作成するとき、設計者とアーキテクトは、可能なかぎり完全なスケーラビリ ティに近づけることを目指す必要があります。これは線形のスケーラビリティと呼ばれ、システ ムのスループットがCPUの数に比例するものです。
スケーラビリティを直線的に高めることは、設計者の制御の及ばない部分があるため、実際には 不可能です。しかし、アプリケーションの設計や実装に可能なかぎりスケーラブルにしておく と、現在も、将来においても、ハードウェア・コンポーネントの拡張やCPUテクノロジの発展と ともにパフォーマンス目標を達成できます。
線形のスケーラビリティを妨げる要因としては次のものが考えられます。
不適切なアプリケーションの設計、実装および構成
アプリケーションは、スケーラビリティに最も大きく影響します。次に例を示します。
スキーマ設計が不適切であると、SQLにコストがかかり、拡張性を持ちません。
トランザクション設計が不適切であると、ロックおよびシリアライズの問題が発生し ます。
接続管理が不適切であると、レスポンス時間が長くなり、システムの信頼性が低下し ます。
問題となるのは、設計のみではありません。アプリケーションの物理的な実装が弱点になる 場合があります。次に例を示します。
システムが誤ったI/O方針のまま本番環境で使用される場合。
テスト時に生成された実行計画とは異なる実行計画が本番環境で使用される場合。
実行時のメモリーの解放を十分に考慮せずに、大量のメモリー割当てを行うメモリー 集中型アプリケーションで、メモリーが過剰に使用される可能性がある場合。
非効率的なメモリー使用やメモリー・リークによって、動作中の仮想メモリー・サブ システムに高いストレスがかかる場合。このようなストレスは、パフォーマンスや可 用性に影響を与えます。
ハードウェア・コンポーネントの誤ったサイズ指定
ハードウェア価格の低下に伴い、どのハードウェア・コンポーネントについても容量計画が 不適切で問題になるということは少なくなっています。ただし、容量が大きすぎると、シス テムでワークロードが増大したときに、スケーラビリティの問題が隠されてしまう場合があ ります。
ソフトウェア・コンポーネントの制限