Ensemble サーバの配置の計画

この章では、プロダクション Ensemble サーバを配置するときに考慮が必要な主要な問題について説明します。このドキュメントの以前の章では、インストールと配置のトピックについて説明していましたが、それらは開発バージョンの Ensemble のインストールを想定していました。それらのトピックはインストールと配置の仕組みについて説明していましたが、堅牢かつ安全な方法でプロダクション・サーバに Ensemble を配置するために重要な事項の多くについては説明していません。

Ensemble サーバの配置の計画を担当している場合、この章は、計画する項目のチェックリストとして役立ちます。ただし、同様に考慮が必要なその他の項目も存在します。

このチェックリストは、信頼性が高く、効率的で、メンテナンス可能な Ensemble システムを配置するために対処する必要があるいくつかの重要事項を示していますが、それらの事項の詳細な指針を与えるものではありません。このドキュメントでは、各事項を以下のチェックリストに分類しています。

キャパシティの計画とチェックリスト　—　Ensemble サーバがピーク時の負荷を効率的に処理できるかを確認します。
堅牢性のチェックリスト　—　Ensemble サーバに高い可用性構成が備わっており、災害から復旧できるかを確認します。
セキュリティのチェックリスト　—　データのプライバシと攻撃への耐性を確認します。
メンテナンスのチェックリスト　—　ソフトウェアおよびハードウェアの更新によって、Ensemble サーバが長期的に正常に機能し続けることを確認します。

キャパシティとパフォーマンスのチェックリスト

Ensemble サーバのパフォーマンスは、ピーク時のメッセージ負荷を処理できる能力によって計測します。Ensemble サーバのパフォーマンスは、数多くのコンポーネントと設定との間の複雑な相互関係に左右されます。Ensemble サーバの負荷は主に以下の要素に左右されます。

メッセージの数とサイズ　—　ピーク時の負荷と通常の負荷の両方が重要です。
各メッセージに必要な処理多くの場合、メッセージの処理の無駄をなくして効率化する必要があります。例えば、メッセージの検証には利点がありますが、完全な検証は各メッセージの処理負荷を大きく増加させてしまう可能性があります。

多くの場合、Ensemble システムでのメッセージの負荷は時間と共に増加します。この増加は、Ensemble プロダクションでのサポートするビジネス機能の増加や、業務量の増加による可能性があります。この負荷を処理するサーバのキャパシティは、CPU コアの数、マルチプロセッサ・アーキテクチャ、ストレージのサイズとスピード、ネットワークの帯域幅と構成、オペレーティング・システムのバッファ割り当て、および Ensemble と Caché の構成など、数多くのコンポーネントと構成設定との間の複雑な相互関係に左右されます。Ensemble サーバのパフォーマンスは複雑な相互関係に依存しているため、簡単に予測できる公式はありませんが、Ensemble サーバがビジネス・ニーズに適合することを確認するために、パフォーマンスの見積もり、計画、プロトタイプ製作、および追跡を行うことができます。

Ensemble サーバに十分なキャパシティがあり、負荷を効率的に処理できることを確認するには、以下を行う必要があります。

負荷の見積もり　—　Ensemble システムでは、どのくらいの数のメッセージが処理されますか。サーバの起動後、負荷は徐々に増加しますか。メッセージをサーバ・ストレージでアーカイブおよび削除するまで、どの程度の期間保存する必要がありますか。
キャパシティの計画　—　計画のスキルは、同様な Ensemble サーバを実装した経験に左右されます。組織にこの経験がない場合は、この経験を有するコンサルタントや InterSystems のセールス・エンジニアなどと共同で作業する必要があります。このような人員の紹介については、インターシステムズのサポート窓口に問い合わせることができます。
プロトタイプ・サーバおよび負荷のテスト　—　負荷を見積もって必要なキャパシティを計画したら、プロトタイプ・システムを実行し、そのパフォーマンスを監視することが重要です。プロトタイプは、キャパシティの計画を確認するために役立ち、配置済みシステムのパフォーマンスと比較する基準として利用できます。
コードとデータベースのディスク・レイアウトの計画　—　デフォルトでは、Ensemble のネームスペースで作成されるすべてのコードおよびデータが、同じデータベース・ファイルに格納されます。データを複数のデータベース・ファイルにマッピングすることにより、データを格納する場所の制御性が向上します。これは、ハイエンド・システムのパフォーマンス向上に役立ち、さらに新しいバージョンへのアップグレードが容易になります。また、ジャーナル・ファイルをデータベース・ファイルと異なるディスクに保存して、ディスクの障害によってデータが消失しないようにすることも重要です。
サーバの配置　—　冗長化されたフェイルオーバー・マシンを含むライブ・システムをインストールおよび構成します。
パフォーマンスと負荷の追跡　—　解決が必要なパフォーマンスの問題が発生する前に、サーバのパフォーマンスを追跡して基準値を取得することは重要です。メッセージの全体的な負荷とピーク時の負荷、CPU 使用率、ディスクの空き領域、メッセージ処理にかかる時間の平均などの測定値を収集する必要があります。
パフォーマンスの問題が重大になる前に解決する　—　パフォーマンスを追跡し、拡大を予測することで、パフォーマンスの問題が組織のパフォーマンスの重大な障害となる前に、アップグレードや効率の改善を計画できる可能性が高くなります。

堅牢性のチェックリスト

堅牢性は、Ensemble サーバが災害の際も利用可能に維持され、短期間で復旧できる能力です。堅牢性は、以下の要因によって決まります。

サーバの高い可用性の確保。詳細は、"Caché 高可用性ガイド" を参照してください。
データを回復し、障害時にサーバの再起動を可能にするデータのバックアップ。
サーバがネットワークの障害時にも機能を継続できる、冗長化されたネットワーク・アクセス。
堅牢な Web サーバの使用。Ensemble と共にインストールされる、機能が限定された Apache サーバは使用しないでください。これは、開発システム用の便宜のために付属しているもので、Web サーバの機能を完全には備えていません。
災害復旧の手順とドキュメント。

セキュリティのチェックリスト

セキュリティは、データへのアクセスを制御し、悪意のある攻撃からサーバを保護する機能です。ビジネス上の目的によってプライバシを管理するだけでなく、多くの場合プライバシの遵守要件が存在します。機密情報へのアクセスを可能にしたり、悪意のある情報の更新や削除を行ったり、システムのパフォーマンスを劣化させたりすることを意図した攻撃が発生する可能性があります。セキュリティは、以下の要因によって決まります。

ユーザ・アカウントとパスワードのポリシー　—　システムにアクセスするユーザの認証を徹底します。
権限とロールの慎重な定義　—　ユーザに正しい認証が行われ、必要なアクセス権が与えられ、さらに必要以上のアクセス権が与えられないようにします。
すべての構成の変更を追跡するための監査証跡　—　監査は、安全性を低下させる可能性があるシステムへの変更を追跡するためのメカニズムを提供します。
プライバシの遵守に適合するために要求される可能性があるドキュメント。
ユーザとオペレータのセキュリティ・トレーニング　—　ユーザがセキュリティに配慮していなければ、最高に安全なシステムでも危険にさらされる可能性があります。
オペレーティング・システムとアプリケーションに適切な時点でセキュリティ・パッチと更新を適用します。
サーバへの物理的およびネットワークによるアクセスの制御　—　セキュリティには、堅牢なファイアウォール、ネットワーク保護、およびサーバおよびネットワーク・ハードウェアへの物理的アクセスの制限が必要です。
データベースとジャーナリングの暗号化　—　データ・センタを取り囲むファイアウォールによってセキュリティやデータの整合性が保護されますが、データベースやジャーナル・ファイルを暗号化することでこれ以上のレベルのセキュリティを実現できます。

メンテナンスのチェックリスト

Ensemble サーバの配置後に、負荷が堅実かつ安全に処理されていることを確認するだけでなく、長期的に良好に実行されていることを確認する必要があります。ソフトウェアおよびハードウェアの更新と、予期しない要求に対応する方法を規定する手順が必要です。メンテナンスは、以下の要因によって決まります。

定期的なメッセージのパージとバックアップ　—　メッセージを保管して、処理後も参照できるようにすることと、メッセージをパージして新しいメッセージのためにストレージの空きを増やすことには相反する関係があります。
バックアップとリストア　—　バックアップを定期的に実行し、不定期にバックアップ・プロセスからのリストアのテストを実施します。
ハードウェア、ソフトウェア、およびアプリケーションの更新　—　システムのパフォーマンスや安全性を低下させることなくこれらを更新できるように計画します。以下の点を考慮してください。
- 重要な時間帯にサーバがアクセス不能にならないように、ハードウェア・メンテナンス、ソフトウェア・パッチ、およびソフトウェア・アップグレードのスケジュールを決めます。
- 開発システムからテスト環境へのコンポーネントの配置、および最終的に稼働中のライブ・プロダクションへの配置を計画します。この計画の実施には、システムのデフォルト設定の使用、配置の機能のエクスポート、ソース・コントロール・システムの使用、またはこれらすべてが含まれます。インストール手順をテストするだけでなく、更新をプロダクション・サーバに適用する前にテスト・システムでテストすることが重要です。
- ソース・コントロールは、プロダクションのアップグレードを制御、監視、および計画的に実施するメカニズムです。これは特に複数の作業者が関連するコンポーネントを更新する場合に重要であり、しばしば開発からプロダクションへの昇格の際や、バージョン管理で使用されます。
問題を早期に検出するための積極的な監視手順　—　監視で見つかった潜在的な問題に対応する方法の手順を定義しておく必要があります。監視には、以下のものがあります。
- プロダクション監視　—　運用スタッフは、さまざまな監視画面を使い慣れる必要があります。
- エンタープライズの監視　—　複数のネームスペースまたはシステムがある場合、エンタープライズ・モニタを使用してシステム全体の処理の概要を表示できます。エンタープライズ・メッセージ・バンクおよびエンタープライズ・メッセージ・ビューワは、複数のプロダクションからのメッセージを監視する手段です。
- アラート　—　Ensemble アラートは、障害について適切な人に迅速に警告するために使用することができ、オペレータが画面を監視する必要がありません。ただし、生成するアラートが多すぎると逆効果になる可能性があり、バランスの良いレベルを探す必要があります。アラート管理は、アラートの解決を追跡するメカニズムを実現します。

その他のリソース

Ensemble サーバを計画および配置することは骨の折れるプロセスですが、問題が発生した重大な Ensemble の配置を修復することよりも容易です。Ensemble と Caché のドキュメントおよびクラス・ライブラリ・ドキュメントは、機能やインストールについての詳細情報を提供しています。サーバの配置についての主要なドキュメントは以下のとおりです。

InterSystems では Ensemble の計画と配置に役立つ以下のリソースを提供しています。

インターシステムズのサポート窓口では、Ensemble サーバの配置について説明を行ったり、必要に応じて関連するリソースを紹介したりすることができます。WRC Direct にアクセスするには、http://wrc.InterSystems.comOpens in a new tab に移動して、ユーザ名とパスワードを入力します。ユーザ名とパスワードがない場合は、インターシステムズのサポート窓口 (support@intersystems.com または +1.617.621.0700) までお問い合わせください。
InterSystems 教育サービスでは、Ensemble のトレーニングを行っています。
InterSystems Developer Connection およびサポート・コミュニティは疑問点を解決する手段として利用でき、InterSystems の従業員や、類似する問題を経験した InterSystems の顧客から回答を得ることができます。