はじめに
今日、世界で生成される膨大かつ増え続けるデータに直面し、ソフトウェア・アーキテクトはソリューションのスケーラビリティに特別な注意を払う必要があります。 また、必要に応じて、何千人もの同時使用者に対応できるシステムを設計しなければなりません。 それは簡単なことではありませんが、大規模なスケーラビリティのための設計は絶対に必要です。
ソフトウェア・アーキテクトには、スケーラブルなシステムを設計するための選択肢がいくつかあります。 何十ものコアを持つより大きなマシンを使うことで、垂直方向に拡張することが可能です。 データ分散(レプリケーション)技術を使って、ユーザー数の増加に合わせて水平方向に拡張することができます。 また、データ・パーティショニング戦略によって、データ量を水平方向に拡張することができます。 実際には、ソフトウェア・アーキテクトは、特定のニーズに合わせて、ハードウェアのコスト、コードの複雑さ、デプロイの容易さをトレードオフしながら、これらのテクニックをいくつか採用します。
本稿では、InterSystems IRIS Data Platform™ がどのようにユーザとデータ量の垂直スケーラビリティと水平スケーラビリティをサポートしているかについて説明します。 データおよび/またはユーザー・ボリュームの分散とパーティショニングに関するいくつかのオプションについて概説し、各オプションが特に有用であるシナリオを示します。 最後に、InterSystems IRISが分散システムのコンフィギュレーションとプロビジョニングをどのように簡素化するかについて述べています。
垂直スケーリング
おそらく、スケールを拡大する最も単純な方法は、より多くのCPUとメモリを搭載したより大きなマシンにデプロイするという「垂直方向」に行うことです。 InterSystems IRIS は SQL の並列処理をサポートしており、マルチコア・マシンの CPU の使用を最適化する技術も含まれています。
しかし、垂直スケーリングだけで達成できることには現実的な限界があります。 ひとつには、利用可能な最大のマシンであっても、最新のアプリケーションが必要とする膨大なデータ量とワークロードを処理できない可能性があります。 また、"big iron(高速なコンピュータ) "は法外に高価な場合もあります。 多くの組織では、64コアのマシンを1台購入するよりも、16コアのサーバを4台購入する方がコスト効率が良いと考えています。
シングルサーバアーキテクチャのキャパシティプランニングは、特にワークロードが大きく変化する可能性が高いソリューションでは困難です。 ピーク負荷に対応する能力を持つことは、時間外の無駄な利用不足を招く可能性があります。 一方、コア数が少なすぎると、使用量の多い時間帯にパフォーマンスが低下する可能性があります。 さらに、1台のサーバー・アーキテクチャーの容量を増やすには、マシン全体を買い換える必要です。 その場で追加することは不可能です。
要するに、ソフトウェアにとって、それが導入されるハードウェアの可能性をフルに活用することは重要だが、垂直方向のスケーラビリティだけでは、最も静的なワークロードを除いて、すべてを満たすには不十分ということです。
水平スケーリング
上記の理由から、大規模なスケーラビリティを求めるほとんどの組織は、ネットワーク化されたシステムに導入し、複数のサーバーに作業を分散させることでワークロードやデータ量を「水平方向」に拡張します。 通常、ネットワーク内の各サーバーは手頃な価格のマシンを使用するが、垂直方向のスケーラビリティを利用するために、必要に応じてより大きなサーバーを使用することもあります。
ソフトウェアアーキテクトは、2つとして同じワークロードはないことを認識します。 最新のアプリケーションの中には、数十万人のユーザーが同時にアクセスし、1秒間に非常に多くの小さなトランザクションを積み重ねるものもあります。 また、ユーザー数はほんの一握りだが、ペタバイト級のデータを照会する企業もあります。 どちらも非常に負荷の高いワークロードだが、スケーラビリティに対するアプローチは異ります。 まず、それぞれのシナリオを別々に考えてみます。
ユーザー数の水平スケーリング
膨大な数の同時ユーザ(またはトランザクション)をサポートするために、InterSystems IRISは、エンタープライズ・キャッシュ・プロトコル(ECP)と呼ばれる独自のデータ・キャッシング技術に依存しています。
サーバーのネットワーク内では、1台がデータを永続化するデータサーバーとして設定されます。 他はアプリケーションサーバーとして構成されます。 各アプリケーション・サーバは、InterSystems IRIS のインスタンスを実行し、ローカル・データベースのようにデータをアプリケーションに提示します。 データはアプリケーション・サーバーに永続化されません。 データはそこに存在し、キャッシュとCPU処理能力を提供しています。
ユーザーセッションは、通常はロードバランサーを介してアプリケーションサーバー間で分散され、クエリは可能であればローカルのアプリケーションサーバーキャッシュから行われます。 アプリケーションサーバーは、必要な場合のみデータサーバーからデータを取得します。 InterSystems IRIS は、すべてのクラスタ参加者間でデータを自動的に同期します。
計算作業はアプリケーション・サーバによって処理されるため、データ・サーバは主にトランザクション結果の永続化に専念することができます。 アプリケーションサーバーは、ワークロードの変化に応じてクラスタに簡単に追加したり、クラスタから削除したりできます。 例えば、小売業のユースケースでは、ブラックフライデーの例外的な負荷に対処するために数台のアプリケーションサーバを追加し、ホリデーシーズンが終わった後に再び電源を切ることが考えられます。
アプリケーションサーバは、大量のトランザクションを実行しなければならないが、各トランザクションはデータセット全体の比較的小さな部分にしか影響しないようなアプリケーションに最も有用です。 ECP を搭載したアプリケーション・サーバーを使用した導入は、さまざまな業界で何千人もの同時ユーザーをサポートすることが示されています。
データ量の水平スケーリング
クエリ(通常は分析クエリ)が大量のデータにアクセスしなければならない場合、クエリワークロードを効率的にサポートするためにキャッシュする必要がある「作業データセット」が、1台のマシンのメモリ容量を超えることがあります。 InterSystems IRIS は、大規模なデータベース・テーブルを複数のサーバ・インスタンスに物理的に分割する、シャーディングと呼ばれる機能を提供します。 アプリケーションは依然として、シャード・マスターとして指定されたインスタンス上の単一の論理テーブルにアクセスします。 シャード・マスターは受信したクエリを分解し、シャード・サーバーに送信します。シャード・サーバーはそれぞれ、テーブル・データの別個の部分と関連するインデックスを保持します。 シャード・サーバーは、シャード・ローカル・クエリーを並行して処理し、その結果をシャード・サーバーに返送して集約します。
データは、シャード・キーに従ってシャード・サーバー間で分割されます。シャード・キーは、システムによって自動的に管理されるか、選択したテーブル・カラムに基づいてソフトウェア・アーキテクトによって定義されます。 シャード・キーを注意深く選択することで、頻繁に結合されるテーブルを共同シャード化することができます。そのため、通常は一緒に結合されるテーブルの行が同じシャード・サーバーに保存され、結合が完全に各シャード・サーバーのローカルで行われるようになり、並列化とパフォーマンスが最大化される。
データ量が増大しても、シャードを簡単に追加することができます。
すべてのテーブルをシャーディングする必要はありません。 例えば、分析アプリケーションでは、ファクト・テーブル(小売シナリオの注文など)は通常非常に大きく、シャーディングされます。 もっと小さな寸法のテーブル(製品、販売時点情報など)は、異なります。 非シャード・テーブルはシャード・マスターに永続化されます。 クエリで、シャード化されたテーブルとシャード化されていないテーブル間の結合が必要な場合、または、2つの異なるシャードのデータを結合する必要がある場合、InterSystems IRIS は、非常に効率的な ECP ベースのメカニズムを使用して、正しく効率的に要求を満たします。 このような場合、InterSystems IRIS は、他の多くのテクノロジのようにテーブル全体をネットワーク経由でブロードキャストするのではなく、必要な行のみをシャード間で共有します。 InterSystems IRIS は、処理可能なクエリの種類を制限することなく、シャーディングによってビッグデータのクエリワークロードの効率とパフォーマンスを透過的に向上させます。
InterSystems IRIS アーキテクチャは、分散され、パーティショニングされたデータセットにクエリを実行する際に、共同シャーディングを必要とせず、データを複製することなく、テーブル全体をネットワークにブロードキャストすることなく、複雑なマルチテーブル結合を可能にします。
ユーザー数とデータ量のスケーリング
最新のソリューションの多くは、高いトランザクション・レート(ユーザー・ボリューム)と大量のデータに対する分析の両方を同時にサポートしなければなりません。 その一例として、顧客のポートフォリオとリスクを要約したダッシュボードを、現在の市場データに基づいてリアルタイムで提供する個人資産管理アプリケーションがあります。
InterSystems IRIS は、アプリケーション・サーバとシャーディングを組み合わせて使用することで、このようなハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング(HTAP)アプリケーションを実現します。 図#2のアーキテクチャにアプリケーションサーバーを追加して、シャードマスターの作業負荷を分散することができます。 ワークロードとデータ量は、アプリケーションのニーズに応じて、それぞれ独立して拡張することができます。
アプリケーションに究極のスケーラビリティが必要な場合(例えば、予測モデルが大規模なテーブルのすべてのレコードをスコアリングする必要があり、同時に新しいレコードが取り込まれクエリされる場合)、個々のデータシャードはECPモデルのデータサーバーとして機能します。 InterSystems IRIS は、データシャード上でワークロードを共有するアプリケーションサーバを "クエリシャード" と呼んでいます。InterSystems IRIS クラスタの高可用性を保証する透過的なメカニズムと組み合わせることで、ソリューションアーキテクトは、ソリューション固有のスケーラビリティと信頼性の要件を満たすために必要なすべてを提供できます。
InterSystems IRIS のシャーディングに対するアプローチの比較パフォーマンスと効率性は、大手テクノロジーアナリスト企業によって検証されたベンチマークテストで実証され、文書化されています。1 実際のミッションクリティカルな金融サービスのユースケースのテストでは、InterSystems IRIS は、より少ないハードウェアでより多くのデータにアクセスできる一方で、複数の高度に専門化されたデータベースよりも高速であることが示されました。
柔軟な展開
InterSystems IRISは、ソフトウェア開発者が非常に効率的でスケーラブルなソリューションを設計する際に、非常に大きな柔軟性を提供します。 しかし、スケーラビリティは、さまざまな役割を担うサーバーがアーキテクチャに追加されることで、複雑さが増すという代償を払うことになるかもしれません。 InterSystems IRIS により、分散アーキテクチャにおけるサーバ(物理、仮想を問わず)のプロビジョニングとデプロイメントを簡素化します。
InterSystems では、InterSystems IRIS コンテナをデータ・サーバ、シャード・サーバ、シャード・マスタ、 アプリケーション・サーバなどとして構成するための簡単なスクリプトを使用できます。 また、廃棄も容易であるため、スケーラブルなアーキテクチャを設計し、ニーズの変動に合わせて成長または縮小させることができます。
結論
大規模なスケーラビリティは、最新のアプリケーション、特に非常に大きなワークロードとデータ量を同時に処理しなければならないハイブリッド・トランザクションおよび分析処理アプリケーションの要件です。 InterSystems IRIS Data Platform は、ソフトウェア・アーキテクトに、アプリケーションをコスト効率よく拡張するためのオプションを提供します。 垂直方向のスケーリング、ユーザー量を水平方向にスケーリングするためのアプリケーションサーバー、ネットワークブロードキャストを不要とするデータ量を水平方向にスケーリングするための非常に効率的なシャーディングアプローチをサポートしている。
InterSystems IRIS Data Platform の詳細については、InterSystems.com/IRIS をご覧ください。
インターシステムズについて
インターシステムズは、世界で最も重要なアプリケーションを支えるエンジンです。 医療、金融、政府機関など、生命と生活が危機に瀕している分野において、インターシステムズは、What matters™を支える力となっています。 1978年に設立されたインターシステムズは、米国マサチューセッツ州ケンブリッジに本社を置き、世界中にオフィスを持つ株式非公開企業で、そのソフトウェア製品は80カ国以上で数百万人に毎日利用されている。 詳しくはInterSystems.com/jp/をご覧ください。
1 - InterSystems IRIS Data Platform: A Unified, Efficient Data Platform for Fast Business Insight, Kerry Dolan, Senior IT Validation Analyst, Enterprise Strategy Group, March 2018.