InterSystems IRIS の拡張性の概要

拡張の問題

1,000 万人の患者を治療するのか、1 日数十億件の金融オーダーを処理するのか、星雲を追跡するのか、工場の 1,000 台のエンジンを監視するのかにかかわらず、何をするにしても、データ・プラットフォームは、現在の業務をサポートするだけでなく、需要の増大に合わせて拡張可能でなければなりません。ビジネス固有の作業負荷ごとに、それぞれが運用されるデータ・プラットフォームに対して異なる課題が突きつけられ、ビジネスが拡大するにつれて、その課題はさらに深刻になります。

例えば、以下の図に示す 2 つの状況を考えてみましょう。

どちらも高い作業負荷を示していますが、どちらの方が負荷が高いのか、それらの需要を満たすにはどのように拡張すればよいのかを判断するのは困難です。

データ・プラットフォームの作業負荷とそれらを調整するには何が必要であるかをより的確に理解するには、個々に調整できるコンポーネントへと作業負荷を分解します。これらの作業負荷を簡単に分解する 1 つの方法は、ユーザ数とデータ量というコンポーネントを分離することです。作業負荷には、最初の例のように、比較的小規模なデータベースを頻繁に操作する多数のユーザが含まれるものもあれば、2 つ目の例のように、1 人のユーザまたは 1 つのプロセスからの要求は少なくても、大規模なデータセットを対象とするものもあります。ユーザ数とデータ量を別個の課題と見なすことにより、さまざまな拡張オプションを評価できます (この分割は単純ですが、作業しやすく便利です。多数の小規模なデータ・ライターや少数の大規模なデータ・コンシューマを含むものなど、これが簡単に当てはまらない複雑な作業負荷の例も数多くあります)。

垂直方向の拡張

高い作業負荷を処理するための最も簡単な最初の方法は、スケールアップする、つまり、垂直方向の拡張性を利用することです。基本的には、作業負荷に対応できるように個々のサーバの性能を高めることを意味します。

詳しく説明すると、垂直方向の拡張では、発生している作業負荷のボトルネックを軽減するハードウェア・コンポーネントを追加することにより、個々のサーバの処理能力を拡大する必要があります。例えば、現在のユーザ数やデータ量に必要な作業セットをキャッシュが処理できない場合は、マシンにメモリを追加できます。

一般に、垂直方向の拡張はよく理解されており、アーキテクチャも簡単です。十分なエンジニアリング・サポートがあれば、作業負荷の要件を満たすようにきめ細かく調整されたシステムを実現できます。ただし、以下のような制限があります。

• 100 を超える CPU コアとテラバイト単位のメモリを搭載した今日のサーバは非常に高性能ですが、その処理能力に関係なく、システムで受信接続について同時に作成および保持できるソケットの数は限られています。

• 高性能のハードウェアは高額であり、ソケットが不足したときには、システム全体をより大規模でより高価なものと交換するしか選択肢がない場合があります。

• 垂直方向の拡張を効果的に行うには、事前に慎重にサイジングする必要があります。これは、比較的静的なビジネスでは簡単な場合もありますが、急激に増加する作業負荷があるような動的な環境では、将来を予測するのが困難な場合があります。

• 垂直方向の拡張に弾性はありません。拡大した場合、作業負荷の変化により縮小が可能になっても、縮小することはできません。つまり、過剰な処理能力という代償を払うことになります。

• 垂直方向の拡張では、ハードウェアの処理能力の拡大に効果的かつ効率的に対応できる必要があるソフトウェアにストレスがかかります。例えば、アプリケーションで 32 のプロセスしか処理できない場合、128 コアに拡張してもほとんど役に立ちません。

InterSystems IRIS データ・プラットフォームの垂直方向の拡張の詳細は、"システム・リソースの計画と管理" および "InterSystems IRIS プラットフォームでの一般的なパフォーマンス強化" を参照してください。

水平方向の拡張

回避できないハードウェア (または予算) 上限に達した場合など、垂直方向の拡張で完全なソリューションが実現されない場合、または垂直方向の拡張の代替手段として、複数の小型サーバをクラスタ化することでいくつかのデータ・プラットフォーム・テクノロジを水平方向に拡張することもできます。特定のコンポーネントを 1 台の高価なサーバに追加する代わりに、この方法では、ボリュームの増大に伴って、より手ごろなサーバをクラスタに追加することで作業負荷をサポートできます。これは通常、1 台のサーバの作業負荷を小さく分割し、分割された個々の作業負荷を各クラスタ・ノードで処理できるようにすることを意味します。

水平方向の拡張は、多数の安価なコモディティ・システムから少数の高性能サーバまで、この範囲内のさまざまなハードウェアを使用して拡張できること、および垂直方向の拡張で必要な突然のデコミッションや置換ではなく、長期的にクラスタを拡張することで、拡張を徐々に行うことができることの両方の理由により、経済的に有利です。水平方向の拡張は、作業負荷の増加に伴って追加のノードをすばやくかつ簡単にプロビジョニングし、負荷が減少した場合はデコミッションできる、仮想インフラストラクチャやクラウド・インフラストラクチャにも非常に適しています。

その一方、水平クラスタでは、クラスタに含まれる複数のシステムに十分な帯域幅が提供されるように、ネットワーキング・コンポーネントに対してより大きな注意を払う必要があります。水平方向の拡張では、クラスタ全体での作業負荷の効率的な分散を完全にサポートするために、InterSystems IRIS のようなはるかに高度なソフトウェアも必要です。InterSystems IRIS は、ユーザ数の増加とデータ量の増加の両方に対応する拡張性を提供することにより、これを実現します。

ユーザ数に応じた水平方向の拡張

ユーザ数が増加し、許容できるコストの 1 つのシステムでは対処できなくなった場合、水平方向に拡張するにはどうすればよいのでしょうか。簡単に言えば、個々のユーザを、それぞれの要求を処理する異なるクラスタ・ノードに接続して、ユーザ作業負荷を分配します。

ユーザ作業負荷の分配

これを行うには、ロード・バランサを使用してラウンドロビン方式でユーザを分散します。ただし、同様の要求を持つユーザ (複数のアプリケーションが使用されている場合に特定のアプリケーションを使用するユーザなど) を同じノード上にグループ化すると、分散キャッシュによってユーザが相互のキャッシュを利用できるため、より効果的です。

InterSystems IRIS は、データ・サーバの前にあるアプリケーション・サーバの層全体にわたってユーザを分配するエンタープライズ・キャッシュ・プロトコル (ECP) によりサポートされているアーキテクチャ・ソリューションである分散キャッシュを使用して、効果的にこれを行うことができます。各アプリケーション・サーバは、独自のキャッシュを使用してユーザのクエリおよびトランザクションを処理しますが、データはすべてデータ・サーバに格納され、アプリケーション・サーバのキャッシュは自動的に同期された状態に維持されます。各アプリケーション・サーバが独自のキャッシュ内にそれぞれ独自の作業セットを保持するため、より多くのサーバを追加すると、より多くのユーザを処理できます。

InterSystems IRIS 分散キャッシュ・クラスタ

分散キャッシュは、ユーザおよびアプリケーション・コードに対して完全に透過的です。

ユーザ数に応じた InterSystems IRIS データ・プラットフォームの水平方向の拡張の詳細は、“分散キャッシュによるユーザ数に応じた水平方向の拡張” の章を参照してください。

データ量に応じた水平方向の拡張

今日の企業のニーズを満たすために必要なデータ量は、非常に大きい場合があります。さらに重要なことに、クエリが繰り返し実行されると、作業セットが大きくなり、サーバのキャッシュに収まらなくなることがあります。これは、作業セットの一部しかキャッシュに保持できず、ディスクの読み取りがはるかに頻繁になり、クエリのパフォーマンスに重大な影響が生じることを意味します。

ユーザ数の場合と同様に、作業負荷を複数のサーバ間で分配することにより、データ量に応じて水平方向に拡張できます。そのためには、データを分割します。

データ作業負荷の分配

InterSystems IRIS は、シャーディング機能を使用してこれを行います。InterSystems IRIS シャード・クラスタは、データの格納および対応するキャッシュを複数のサーバ間で分割して、クエリおよびデータ取り込みに応じた水平方向の拡張を実現しながら、きわめて効率的にリソースを使用することにより、インフラストラクチャの価値を最大化します。

基本的なシャード・クラスタでは、シャード・テーブルが、シャードと呼ばれるほぼ均等な行セットに水平方向に分割され、複数のデータ・ノード間で分散されます。例えば、1 億の行があるテーブルが 4 台のデータ・ノード間で分割された場合、約 2,500 万の行を含むシャードが各サーバに格納されます。シャード化されていないテーブルは、全体が最初に構成されたデータ・ノードに配置されます。

シャード・テーブルに対するクエリは、複数のシャードローカル・クエリに分解され、データ・ノード上で並列で実行されます。その後、結果が結合され、ユーザに返されます。さらに、この分散データ・レイアウトはデータの並列ロードに利用したり、サードパーティ・フレームワークと共に利用したりすることもできます。

並列処理に加えて、シャーディングでは、キャッシュが分割されるため、クエリのパフォーマンスが向上します。各データ・ノードは、サーバに格納されているデータに対するシャードローカル・クエリに独自のキャッシュを使用するため、シャード・データを処理するクラスタのキャッシュは、すべてのデータ・ノードのキャッシュの合計とほぼ同じ大きさになります。データ・ノードの追加は、より多くのデータを処理するために専用キャッシュを追加することを意味します。

アプリケーション・サーバ・アーキテクチャと同様に、シャーディングは、ユーザおよびアプリケーションに対して完全に透過的です。

シャーディングには、使用可能なソリューションの幅が大幅に広がる、以下のような追加オプションがあります。

• ミラーリング

  InterSystems IRIS のミラーリングを使用して、データ・ノードの高可用性を実現できます。

• 計算ノード

  常に大量のデータが取り込まれるような状況でも、遅延が小さいことが求められる高度な使用事例では、計算ノードを追加して、クエリを処理するための透過的なキャッシュ層を提供できます。計算ノードはクエリの実行のみをサポートし、割り当てられているデータ・ノードのシャード・データ (および、必要に応じてシャード化されていないデータ) をキャッシュします。クラスタに計算ノードが含まれている場合、計算ノードでは読み取り専用クエリが自動的に実行され、データ・ノードではすべての書き込み操作 (挿入、更新、削除、および DDL 操作) が実行されます。このクエリの作業負荷とデータ取り込みの分離により、それら両方のパフォーマンスが向上し、1 つのデータ・ノードに複数の計算ノードを割り当てることで、クエリ・スループットとクラスタのパフォーマンスを向上させることができます。

データ量に応じた InterSystems IRIS データ・プラットフォームの水平方向の拡張の詳細は、“シャーディングによるデータ量に応じた水平方向の拡張” の章を参照してください。

InterSystems IRIS の拡張ソリューションに関する作業負荷の評価

このドキュメントの後続の章では、InterSystems IRIS を拡張するための個々の機能について詳しく説明します。データ・プラットフォームの拡張プロセスを開始する前に、各章を参照してください。ただし、以下のテーブルでは、この章の概要をまとめ、現在の状況に最も有効であると思われる拡張アプローチに関する一般的なガイドラインを提供します。

InterSystems IRIS プラットフォームでの一般的なパフォーマンス強化

以下の情報は、InterSystems IRIS の導入のパフォーマンスを向上させる際に役立ちます。

• 同時マルチスレッディング

  ほとんどの状況では、物理サーバ内、または仮想環境内のハイパーバイザ層でパフォーマンスを向上させるには、Intel のハイパースレッディングや AMD の同時マルチスレッディング (SMT) の使用をお勧めします。仮想環境において、ハイパースレッディングや SMT の無効化が必要な場合もありますが、これらは指定されたアプリケーションに固有の例外的なケースです。

  IBM AIX® の場合、IBM Power プロセッサは 1 コアあたり 2、4、8 スレッドという複数の SMT レベルを提供します。最新の IBM Power9 および Power10 プロセッサでは、SMT-8 が InterSystems IRIS で最もよく使用されているレベルです。ただし、以前の世代の Power7 や Power8 プロセッサでは特に、指定のアプリケーションには SMT-2 や SMT-4 の方が適している場合もあります。特定の導入で理想的な SMT レベルを判断するには、アプリケーションのベンチマークがお勧めです。

• セマフォ割り当て

  既定では、InterSystems IRIS は、セットあたりのセマフォの数を最大にすることで、最小数のセマフォ・セットを割り当てます ("インターシステムズ製品のセマフォ" を参照)。ただし、non-uniform memory access (NUMA) アーキテクチャの Linux システムでのパフォーマンスに対しては、これは理想的ではないという情報もあります。

  これに対処するため、構成パラメータ・ファイル (CPF) の semsperset パラメータを使用して、セットあたりのセマフォをより小さい数に指定できます。既定では、semsperset は 0 (既定の動作を指定) に設定されます。最も効果的な設定を決定するには経験が必要です。Linux/NUMA システムで InterSystems IRIS を導入した場合、初期値である 250 を試すことをお勧めします。