Public Cloud運用サーバ要件

概要

QueryPieサーバをAWS、GCP、AzureなどのPublic Cloudで運用する場合、以下のような構成を適用することを推奨します。

• High Availability構成適用
  • Application Load Balancer、Network Load Balancerを適用して、高可用性、負荷分散に適した構成を適用します。
  • 2つ以上のVM InstanceをLoad BalancerのUpstreamサーバとします。要求される処理容量が高い場合、VM Instanceの数を増やすScale-Out方式の構成を適用します。
• QueryPie MySQL、RedisをVMではなく、Managed Service方式のMySQL、Redisを適用します。
  • AWSの場合Aurora RDS for MySQL、Aurora RDS for MariaDB、ElastiCacheを使用することを推奨します。
• VMのOSはLinuxディストリビューションは大部分サポートします。ただし、docker daemonをインストールして使用できる必要があります。
  • AWSの場合、Amazon Linuxを推奨します。
  • GCPの場合、Ubuntu 24.04 LTS（または以降の最新LTSバージョン）を推奨します。

QueryPie Container用VMモデル

基本仕様：CPU 4 vCPUs AMD64 Architecture、Memory 15 GiB以上、Disk 100 GiB、CPU AMD

• 基本仕様のVMを2つ以上作成して、Scale-Out構成を適用することを推奨します。
• AWS EC2 Instance Type: m6i.xlarge、m7i.xlarge
• GCP Compute Engine Machine Type：c4-standard-4、n4-standard-4（またはAMD64アーキテクチャの-standard-4モデル）
• Disk IO性能：汎用Disk Volumeを適用します。AWSの場合、EBS General Purpose SSD (gp3)を適用します。

高い処理量が必要な場合推奨仕様：CPU 8 vCPUs AMD64 Architecture、Memory 30 GiB以上、Disk 100 GiB

• 推奨仕様のVMを2つ以上作成して、Scale-Out構成を適用することを推奨します。
• AWS EC2：m6i.2xlarge、m7i.2xlarge
• GCP Compute Engine：c4-standard-8、n4-standard-8（またはAMD64アーキテクチャの-standard-8モデル）
• Disk IO性能：高いIOPSのVolumeを適用します。AWSのEBS Provisioned IOPS SSD (io1)またはそれ以上の性能のVolumeを適用します。

QueryPie MySQL

基本仕様：CPU 2 vCPUs、Memory 16 GiB以上、Disk 100 GiB以上

• Managed Service方式のMySQLまたはMariaDBを使用することを推奨します。
• AWS Aurora：db.r7g.large、db.r6g.large
• Disk IO性能：汎用Disk Volumeを適用します。AWSの場合、EBS General Purpose SSD (gp3)を適用します。

高い処理量が必要な場合推奨仕様：CPU 4 vCPUs、Memory 32 GiB以上、Disk 100 GiB以上（保存容量サイズは別途算定必要）

• Managed Service方式のMySQLまたはMariaDBを使用することを推奨します。
• AWS Aurora：db.r7g.xlarge、db.r6g.xlarge
• Disk IO性能：高いIOPSのVolumeを適用します。AWSのEBS Provisioned IOPS SSD (io1)またはそれ以上の性能のVolumeを適用します。
• Disk容量：QueryPieで記録するAudit LogをMySQLに保存します。Audit Logが記録される頻度、平均サイズ、保管期間に従って、保存空間のサイズを適切に算定する必要があります。

QueryPie Redis

基本仕様：CPU 2 vCPUs、Memory 1 GiB以上

• Managed Service方式のRedis互換サービスを使用することを推奨します。
• AWS ElastiCache On-Demand Nodes：cache.t4g.smallまたは類似モデル

高い処理量が必要な場合推奨仕様：CPU 2 vCPUs、Memory 3 GiB以上

• Managed Service方式のRedis互換サービスを使用することを推奨します。
• AWS ElastiCache On-Demand Nodes：cache.t4g.mediumまたは類似モデル

Availability ZoneによるVM構成方法

可用性ゾーン（Availability Zone）に従ってVMを配置し、VMの仕様を調整する方法を案内します。

運用環境では可用性ゾーン3つ（または4つ）にそれぞれVMを作成して配置します。

1つの可用性ゾーンにVMが集中しないように、各可用性ゾーンに均等にVMを分散して配置します。

サービス使用量が高くなく、VMサーバのCPUリソースに余裕が多い場合、2つのVMでサービスを構成してもよいです。 サービス使用量が高くなると、VMの数を増やし、普段測定される最大使用量が一定レベル以下を維持するように調整します。 具体的な調整基準は以下で説明します。

1つのVM Instanceがサービスを中断しても、普段測定される最大使用量を処理可能にするように、VMの仕様を調整します。

例えば、3つのVMを構成してサービスを提供する場合、2つのVMだけで最大使用量を処理可能にするようにVMの仕様を調整します。 2つのVMが最大使用量を処理する時点で、CPU使用量が85%を超えないように調整します。 2つのVMが85% CPU使用量を示すなら、合計170%のCPUを使用する計算です。 この負荷を3つのVMが分けて処理すると、1つのVMでは約56%のCPUを使用することになります。 したがって、3つのVMが正常に動作する場合、最大使用量を示す時期に、CPU使用量56%を超えないことが必要です。

VM数を増やすScale-Out構成を適用する場合、正常運用時最大CPU使用量として許可できるレベルがより高くなります。 このような方式で、1つVM障害時、残りのVMで正常にサービスを提供しながら、普段VMのリソース使用率を高めて、コスト対処理性能を高めることができます。

VM数を増やさず、2つまたは3つを固定とする場合、正常運用時最大CPU使用量として計算された基準値より高い実際の使用量を示す場合、VMのCPU数を増やすか、Instance Typeを高仕様に変更して、計算された基準値より低い実際の使用量を示すように調整します。

Auto Scaling Group設定を適用しません。

サービスが処理するトラフィック、負荷の程度に従ってUpstreamサーバを自動的に増減するAuto Scaling Group設定を適用しません。

QueryPieはウェブアプリケーションの特性を持っていますが、一般的なウェブアプリケーションと異なり、利用者の接続に従って、特定のDB、システムと接続を確立し、この接続を通じてSQL Queryを実行し、sshを通じてシステムコマンドを実行する機能的特性を持っています。 これにより、利用者が接続した特定のServer Container内でDB接続、ssh接続を維持し、後続する問い合わせ、コマンドを実行する方式で動作します。

Auto Scaling Groupを適用する場合、Upstreamサーバ数が変更されるとき、Web Consoleに接続されたセッションの認証が切断され、再度ログインを要求する現象が発生する可能性があります。

参照 - HA構成でSticky Sessionがなぜ必要ですか？ 

要求される性能に関する根拠

QueryPie Serverが要求するコンピューティングリソースのタイプ

QueryPie Server ContainerとMySQLは以下のようなタイプの作業を処理するのに、コンピューティングリソースを主に使用します。

• 利用者の接続、クエリ実行、コマンド実行などに従ってAudit Logを記録する機能がMySQLがデータを保存します。
• 利用者の接続、クエリ実行、コマンド実行に従って、アクセス制御ポリシーを照会し、許可または拒否します。
• 多数のSQLクエリを含むWorkflow作業をバックグラウンドで実行します。
• SSO Integrationに従って、定期的に多数利用者のリストを受信し、各利用者のQueryPieアカウント情報をアップデートします。
• External APIを利用して、多数のDB、Server資産を登録または変更し、アクセス制御ポリシーを変更します。

QueryPie Containerが要求するメモリサイズ

• QueryPie Containerは初期実行時に約7 GiBのメモリを使用します。利用者の使用に従って、Containerが使用するメモリが2～3 GiB程度増加する可能性があります。
• Mongo、Document DBにアクセスする場合、メモリ使用量が1 GiB以上増加する可能性があります。
• 大量のResult SetをダウンロードするSQL問い合わせを実行する場合、メモリ使用量が増加する可能性があります。
• Audit Logを記録する過程で、Container内部で一時ファイルを生成して使用します。これにより、DiskデバイスのためのOSのCacheのためのメモリを1～2 GiB程度割り当てる必要があります。

FAQ

Q: 利用者数に従ってサーバ処理容量を推定するガイドを提供してください。

A: 顧客社の利用者数に従ってサーバ処理容量を推定するガイドを一般的に提供することは困難です。 ガイドを提供することが困難な理由について説明いたします。

QueryPieは一般的に、人利用者の接続、クエリ実行、コマンド実行に対してアクセス制御を行い、監査ログを記録する条件で使用することを推奨します。 人利用者ではない利用者の場合は、Application、ProgramがQueryPieを通じて対象システムに接続する場合です。

QueryPieは基本仕様のVM 1台で、DAC基準で簡単なクエリの場合、1秒あたり70件以上のクエリを低いLatencyで処理する性能を持っています。 1秒あたり70件のクエリを処理するということは、1分に4,200件、1時間に25万件のクエリを処理できる性能を意味します。

数百名または数千名の利用者が日常的に軽いクエリを実行する場合、基本仕様のVM 1台または2台で十分に余裕を持って処理可能な処理性能を提供します。

しかし、以下のタイプのクエリ、アクセス方式を使用する場合、要求されるサーバ処理容量が大きく増加し、このとき実際に要求されるサーバ処理容量を一般的に推定することは困難です。

• 人利用者が数万個以上のStatementで構成されたSQL Queryを実行する場合
• 人利用者が数十万件以上のResultSetを得るSQL Queryを実行する場合
• 人利用者ではない、Application、ProgramからDBに接続して動作する場合
• QueryPieを通じてDBに接続された状態で、アプリケーション性能テストプログラムを実行する場合
• QueryPieを通じてDBに接続された状態で、アプリケーションのテストコード、統合テストケースを実行する場合
• 1万個以上のDB、System資産をExternal APIを通じて登録、管理する過程を自動化した場合

顧客社でQueryPieのサーバ処理容量が不足していると報告された事例は、大部分上記のような事例です。 このような場合は、事前に要求される処理容量の推定を試みることはできますが、正確にまたは有意義に推定することは困難な限界があります。 このような場合には以下のような方式でアプローチすることを推奨いたします。

• QueryPieを新規導入する場合、内部利用者に対して段階的に配布を実行し、VMのCPU、Memory、Disk IO使用量指標をモニタリングし、性能が不足していないか、モニタリングします。
• 既存使用中のアクセス制御システムがある場合、利用者の使用量指標を提供받いて、分析します。1日または1週間程度の期間中、利用者の接続件数、クエリ実行件数、ResultSetのサイズ、生成されたAudit Logのサイズなど使用量指標が必要です。