ストレージとバックアップの構成判断

ストレージ用途に適した物理サーバー、NVMeは各ドライブ直結

OnuCloudのサーバーは日本の東京に設置されています。

共有ディスクの変動がクエリに影響するのか、バックアップ時の圧縮や検証が処理能力を圧迫するのか。まずボトルネックを見極め、ディスク構成、メモリ、復元帯域を計画しましょう。物理サーバーを専有しても、冗長化設計の代わりにはなりません。

以下では、ホスト、データサービス、バックアップ、サービス接続の順に検討します。単一のスペックだけで負荷を判断することはできません。

仮想マシンとホストのリソース

ホスト分を確保してから仮想マシンへ割り当てる

Proxmox VEを使うと、長期稼働する複数のサービスを1台の専用サーバーに集約できます。リソースの割り当て先は明確ですが、各仮想マシンの割り当て量、ネットワーク分離、バックアップは個別に設定する必要があります。

計算リソースは割り当て可能、物理リソースには上限あり

AMD EPYC 7543Pは32コア64スレッドを備え、AMD-VとNPTに対応し、ネステッド仮想化を有効にできます。ネステッド環境は仮想化構成の検証に適していますが、多層のスケジューリングにはオーバーヘッドが生じます。対応しているからといって性能への影響がないわけではありません。

128GB DDR4-3200 ECCは、必要なリソース規模が明確なホストに適しています。仮想マシンの台数が多い場合や、ZFS ARC用のメモリを多く確保する場合は、256GBプランもご検討ください。CPU割り当て、ホストの余裕、メモリ予算を合わせて計算し、スレッド数だけでインスタンス数を決めないようにしましょう。

メモリは開通後に同じサーバー上で増設できません。プラン変更には別のサーバーを新規契約し、サービスを移行する必要があります。

業務用ディスクとバックアップ領域を分けて管理

仮想マシンのディスクは、標準搭載の2 × 1TB NVMe(各ドライブ直結)に配置できます。復元要件に応じて個別に使うか、ミラーを構成してください。オプションの2TB NVMeはバックアップ領域として利用でき、最大2台まで追加できます。追加分も各ドライブ直結です。

同じサーバー内のバックアップは日常的なロールバックに便利ですが、業務データと同じサーバー障害の影響を受けます。重要なコピーは別途、遠隔地へ転送してください。別の仮想マシンにバックアップを保存しても、同一の物理サーバー上にあることに変わりはありません。

仮想化ホストを管理できる管理者に適しています。仮想マシン、バックアップ方針、システム設定の管理を任せたいプロジェクトには適していません。

データベースとミドルウェア

共有ストレージとの競合を避けても、高可用性の設計は必要

データベースのクエリ、インデックス作成、ログ書き込み、キャッシュの永続化では、ディスク待ちの要件が異なります。NVMeは各ドライブ直結で共有ストレージを経由しないため、他の利用者による共有クラウドディスクの競合に起因する変動を避けられます。一方、アプリケーション内のロック、クエリプラン、同じサーバー上のタスクは、引き続きレイテンシに影響します。

適している用途:継続的な書き込みと予測可能なワーキングセット

データベースやミドルウェアを長期運用し、CPU・メモリ・ディスクの割り当てを明確にしたい場合は、サーバー全体のリソースを管理しやすくなります。まずデータベースのバッファとキャッシュ用ワーキングセットに必要なメモリを確保し、OS、ログ処理、バックアップ圧縮の分も残してください。

バックアップのスキャンや検証と業務クエリは、同じ契約者の処理であってもディスクやCPUを奪い合うことがあります。サーバー専有を、すべてのタスクを常時フル稼働できるという意味に捉えず、業務の低負荷時間帯に合わせて実行してください。

適さない用途:1台のサーバーを自動で災害復旧できる環境と見なすこと

直結ディスク2台は、RAID-1構成済みで提供されるわけではありません。フェイルオーバー、ミラーリング、別サーバーへの復旧が必要なサービスでは、レプリケーション、障害検知、復旧手順を個別に設計してください。同じサーバー内でディスクを分けるだけでは、高可用性は実現できません。

ハードウェアとネットワークは本サービスの提供範囲です。データベースの設定、レプリケーション構成、データバックアップは契約者側で管理してください。データセンターによる冗長化やデータベース管理が必要なプロジェクトは、サービスの提供範囲外です。

ファイル保存と遠隔地コピー

ディスクは容量の合計ではなく、復旧作業に応じて使い分ける

ファイル保存では空き容量が重要ですが、バックアップではコピーの分離と復旧経路も考慮する必要があります。標準搭載の1TB NVMe 2台は、合計で容量2TBです。2台でミラーを構成すると、公称の使用可能容量は約1TBとなり、実際にはフォーマットやファイルシステムのオーバーヘッド分が差し引かれます。

容量はドライブの公称値です。ハードウェアRAIDはなく、プールとミラーは契約者側で構成してください。
ディスク構成 推奨用途 容量の目安 必ず考慮する制約
標準:2 × 1TB NVMe ZFSミラーで頻繁に使うデータやファイルを保存 合計2TB(生容量);2台ミラーで約1TB ミラーは過去のバージョンを保持せず、誤削除の同期も防げません
オプション:2 × 2TB NVMe 独立したバックアッププールを作成し、業務データのコピーを保存 合計4TB(生容量);2台ミラーで約2TB 同じサーバー内のコピーです。重要なデータは別途、遠隔地にもバックアップしてください
外部の遠隔地コピー このサーバーの障害範囲から切り離したデータを保存 別途用意するバックアップ先によって異なります データの読み取り可否、復旧手順、所要時間を定期的に確認してください
海外向けサービスと固定IPアドレス

IPアドレスをサービスに割り当て、分離はシステム側で設定

固定の送信元IPアドレスは、店舗管理画面、サービス間コールバック、アクセス許可リストに適しています。専用IPv4でアドレスの割り当て先を明確にできますが、IPアドレスの数がサービスの分離を自動的に実現するわけではなく、外部プラットフォームの審査やリスク管理を回避できるわけでもありません。

適している用途:対応関係が明確な複数サービスの運用

標準で専用IPv4を1個利用できます。最大255個を追加でき、合計で最大256個です。仮想マシンやサービスごとに、用途、割り当て先、アクセスルールを記録したIPアドレス台帳を作成し、同じアドレスの重複設定を防いでください。

複数のIPアドレスは、システム上で個別に割り当てる必要があります。リモート管理にはコンソールに表示される最初のIPv4のみを使用し、残りはサービスの要件に応じて利用してください。ファイアウォール、ポート転送、仮想マシンのネットワークは契約者側で設定します。

適さない用途:複数のIPアドレスを複数拠点の代わりに使うこと

同じサーバーにIPv4を追加しても、地理的な分散にはならず、サーバー単位の障害範囲も変わりません。複数都市への配置、地域間のフェイルオーバー、各地の利用者に近い接続が必要な構成を、1台のサーバーだけで担うことはできません。

複数店舗の管理画面を同じサーバーで運用する場合は、アカウント、認証情報、サービス権限を個別に管理してください。ネットワークアドレスを割り当てても、システム権限やコンプライアンス要件への対応は別途必要です。

Windowsの業務利用

ライセンスを確認してから、リモート接続を設定

Windows Serverに依存するアプリケーションには、月額課金のStandardまたはDatacenterライセンスを選択できます。Windowsの運用経験があり、アプリケーションのインストールとシステム管理を自ら行える業務に適しています。アプリケーションのホスティングや運用代行サービスではありません。

OSのバージョンと接続方法

Windows Serverは2019、2022、2025を提供しています。システム言語は英語、繁体字中国語、簡体字中国語から選べます。提供後はコンソールで認証情報を確認し、RDPで接続してください。IPv4が複数ある場合も、リモート接続には最初のアドレスのみを使用します。

業務アプリケーション、ドライバー、依存コンポーネントが選択したOSバージョンに対応しているか、事前に確認してください。システム言語を選択しても、アプリケーションがローカライズ済みとは限りません。アプリケーション自体の言語とライセンスも個別に確認が必要です。

ライセンスはアプリケーション設定の代わりにはならない

StandardとDatacenterは、実際のライセンス要件に応じて選択してください。メモリ容量だけで判断することはできません。仮想化環境でWindowsとLinuxの業務を1台のサーバー上に共存させる場合は、ゲストOSに適用されるライセンス条件も別途確認してください。

業務用のプロプライエタリーソフトウェアの事前インストール、ディレクトリサービスの設定代行、アプリケーションアカウントの管理は、標準の提供範囲外です。契約前にソフトウェアの依存関係、アクセス権限、バックアップ方法を整理し、OSとハードウェアが要件を満たすか確認してください。

サーバー全体を借りないほうがよいケース

リソース使用量が少ない場合、専有が必ずしも割安とは限らない

OnuCloudの物理サーバーは、継続的にリソースを使用し、必要な規模が明確で、システムを自ら管理できるワークロードに適しています。ボトルネックが専有の計算リソース、直結ディスク、固定IPアドレスにない場合、サーバー全体の利用は未使用リソースと運用作業の負担を増やす可能性があります。

  1. 01

    数コアだけのテスト

    計算量が少なく、ディスクの動きも小さく、作業終了後に解放できるテスト環境なら、汎用の共有VPSのほうが割安な場合があります。32コア64スレッドのサーバーを長期間使わないままでは、専有のメリットを十分に活用できません。

  2. 02

    すぐにリソースを増減したい

    インスタンスを時間単位で増減したり、イベントに合わせて大量のリソースを一時的に調整したりする場合は、柔軟に拡張できるサービスを優先してご検討ください。本サービスではメモリのプラン変更に別のサーバーが必要なため、急なトラフィック増加への対応として同じサーバーを増強することはできません。

  3. 03

    システム運用の知識が不足している

    ソフトウェアRAID、ZFS、仮想化ネットワーク、データ復旧には継続的な管理が必要です。システム設定やバックアップの検証を担える体制がない場合は、ハードウェアの専有を運用代行と見なさず、まず運用体制を整えてください。

別のタイプの計算タスク

DGX Sparkはモデル実験とCUDA開発向け

ローカルでの大規模言語モデル推論、LoRA / QLoRAのファインチューニング実験、AIアプリケーションのプロトタイプ検証には、DGX Sparkもご検討ください。AMD搭載ストレージサーバーのアクセラレーターではありません。2つの製品ラインは別々に選択してください。

適している用途:明確な実験目標がある開発タスク

モデル出力の比較、推論フローの検証、ファインチューニング手法の試行、CUDAプログラムの開発に適しています。まず評価目標と結果のエクスポート方法を明確にし、サーバー環境が要件に合うか確認してください。モデルと開発環境の依存関係は、利用者側で準備する必要があります。

適さない用途:x86環境の継続利用やマルチノード学習

x86プログラム、Windows環境、マルチノード学習に依存するプロジェクトは、この製品ラインへそのまま移行できません。アーキテクチャとソフトウェアの互換性を確認してからモデル実験を計画し、環境移行のコストを見落とさないようにしてください。

ディスク構成と復旧目標を決めてから、オプションを選ぶ

頻繁に使うデータの容量、コピーの保存先、メモリのワーキングセット、復旧帯域を確認し、要件に合わせてOnuCloudの構成ページへお進みください。冗長化とバックアップの計画は、サーバーの仕様と合わせて決定してください。