IBM マネージド・サービス・アーキテクチャーがどのようにマルチクラウド・プラットフォームに対応しているかについて

IBM Db2 Warehouse on Cloud Flex for Amazon Web Services (AWS) アーキテクチャ概説

Comments

IBM のエンジニアリング・チームは、Amazon Web Services (AWS) 向けの IBM Db2 Warehouse on Cloud Flex オファリングの提供開始を発表しました。この新規オファリングには、Flex および Flex Performance という 2 つのモデルがあります。IBM Db2 Warehouse on Cloud の中核は BLU アクセラレーション、IBM のインメモリー・カラム処理テクノロジー、アクショナブル圧縮、そしてデータ・スキッピングのテクニックです。Flex と Flex Performance オファリングは、データが複数の区画に広がり、複数のリソースがデータに同時に作用する状況において、超並列処理 (MPP) アーキテクチャーを使用します。さらに、独立したコンピュートおよびストレージ・スケーリングや、日次バックアップ、ならびに高可用性などの特長を含め、IBM Cloud で設定されているのと同じフィーチャーがこの AWS オファリングにも備わっています。

このテクニカル・ブログでは、短時間で他のクラウド・プラットフォームに移動できるようにする場面において、IBM のマネージド・サービス・アーキテクチャーがマルチクラウド・プラットフォームに対応しやすい理由についてお話しします。同様の基礎が IBM Cloud Flex オファリングにも使用されています。

Flex オファリングは、Kubernetes をファウンデーションとして構築されています。ベースは AWS プラットフォーム上の Amazon Elastic Container Service for Kubernetes (AKS) クラスターです。この Kubernetes クラスターで Flex クラスターをプロビジョンします。単一の Kubernetes クラスターに複数の Flex クラスターが存在します。IBM が使用するコンピュート・ワーカー・ノードは Broadwell ベースで、具体的に言うと、Flex Performance クラスターでは r4.16xlarge (64 vCPU、488 GB RAM、ネットワーク帯域幅 20Gbps)、Flex クラスターでは r4.8xlarge (32 vCPU、244 GB RAM、ネットワーク帯域幅 10 Gbps) となっています。

プロビジョニングの依頼があった際には、お客様のコンピュート・レベルに基づいてクラスター構成が判断されます。依頼に基づき、ワーカー・ノードが既存のプールから選ばれるか、もしくは動的にプロビジョンされます。ストレージ・ボリュームは、動的にプロビジョンされるか、もしくはプールから適宜選択されます。クラスターのデプロイメント・プロセスは、お客様が IBM Cloud Marketplace でインスタンスを作成するための「Create」ボタンをクリックするところから、お客様がウェルカム・メッセージを受信するところまで、完全に自動化されています。お客様が実際に取得するのは Flex クラスター (後掲の図を確認してください) であり、お客様のクラスターを構成する数々のワーカー・ノード、専用ストレージ・ボリューム、および接続するためのホスト名が伴います。クラスターでオープン状態のポートは、異なるアプリケーションを実行するのに必要なポートのみです。各クラスターは、専用ワーカー・ノード一式と専用ストレージ・ボリュームを取得します。

ウェアハウス・ストレージについては、ユーザー・データ、一時データ、およびアーカイブ・スペースにはプロビジョンされた IOPS SSD (io1) の Elastic Block Storage (EBS) が使用され、共有する必要があるファイル・システムには Elastic File Storage (EFS) が使用されます。オファリングとパフォーマンスのニーズに基づいて、異なる IOPS ティアが使用されます。ユーザー・データと一時データには、ボリュームあたり、より高い IOPS を使用します。EBS と EFS のボリュームでは両方とも、すべての保存データが暗号化されており、転送中データの暗号化も提供します。ストレージ・レベルでの暗号化に加え、Db2 Warehouse のエンジンは、データベース・レベルの暗号化も提供します。

システムの高可用性モデルでは、複数の対策が用意されています。まず、どのようなポッドやノードの障害にも、Kubernetes がすぐに対応します。EC2 インスタンスの予備のプールにより、Kubernetes が新規ノードを移動し、Flex クラスターを以前と同じキャパシティーで実行し始められるようになります。ノードのダウンタイムについては、数分程度で回復できます。また、すべてのマイクロサービス・コンポーネントが問題なく実行されているようにするために、内部で継続的にプロセス・レベルのモニターも行われています。マイクロサービス・コンポーネントに問題があった場合には、IBM 内の高可用層で問題を特定し、解消します。ストレージ回復力については、EBS ボリューム自体が提供します。コンポーネントの障害によるデータ損失を回避するために、EBS ボリュームはアベイラビリティー・ゾーンで複数のサーバーにわたり、デフォルトで複製されます。

AWS でのコンピュート・スケーリングについては、お客様のスケーリング (アップまたはダウン) に基づき、IBM により新しくデプロイメント・テンプレートが作成されます。古い構成をシャットダウンし、新しいデプロイメント・テンプレートで再起動します。コンピュート・スケーリングではデータの再配布は行われません。データ・ボリュームは、あるポッド/コンテナーから別のポッド/コンテナーへと移動されます。新規のコンピュートには、一時スペースおよびアーカイブ・スペース用に独自のボリュームが割り当てられ、新規の構成でエンジンが再起動されます。スケーリングは数分以内で行われます。

ストレージのスケーリングは完全にオンラインです。お客様が新しいストレージ・サイズを選ぶと、拡張プロセスがすぐに始まります。完全なストレージ・アベイラビリティーはプラットフォームによります。AWS EBS ボリュームのスケーリングは、ストレージが完全に使用できるようになる前に、state transition (状態遷移) を経ます。また、AWS のストレージ拡張は、6 時間に 1 度しか適用できません (EBS の制約)。コンピュートとストレージのスケーリングは、REST API を使用して、または IBM Cloud コンソールから行えます。

デフォルトで、バックアップは日次で実施されます。実際、バックアップはストレージ・レベルのスナップショットであり、Amazon Simple Storage Service (S3) にコピーされます。バックアップ・プロセス全体の所要時間は数分未満です。お客様は、IBM Db2 Warehouse on Cloud コンソールを使用して、バックアップのタイミングの変更と、以前に取られたバックアップへの復元を行えます。復元プロセスにより、選択されたスナップショットが復元され、スナップショットのレベルでクラウド上の Warehouse が開始されます。復元にかかる時間はここでも数分程度です。デフォルトで、オファリングでは、最大 7 日分までのバックアップを維持することができます。バックアップの数は変更可能です。

このオファリングには、複数層のセキュリティーが適用されています。AWS では、お客様のデプロイメント、VPC (すべてが VPC の境界で保護されています)、複数レベルのセキュリティー・グループ (EC2 インスタンス、VPC)、ならびに Kubernetes レベルのネットワーク・ポリシーおよび RBAC ルールの安全性を確保するために、プラットフォームの必要不可欠なすべてのコンポーネントを使用しています。

詳細については、当社のWebサイトをご覧ください。

この記事は米国時間2019年4月16日に発表された記事(英語)の抄訳です。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=ビジネス・アナリティクス, Information Management
ArticleID=1066386
ArticleTitle=IBM マネージド・サービス・アーキテクチャーがどのようにマルチクラウド・プラットフォームに対応しているかについて
publish-date=07262019