管理型と非管理型VPSの違いと選び方

管理型 VPS と非管理型 VPS：簡単な結論

管理型 VPS と非管理型 VPS のどちらを選ぶかは、製品ではなく作業負担の問題です。非管理型では、パッチ適用、ファイアウォール、バックアップ、監視、午前 2 時の再起動を自分で担当します。管理型では、プロバイダーがその一部を代行します。ただし、どこまで代行するかはホストによって大きく異なります。比較で確認すべきなのは、各プランがどの作業を自分から取り除くかです。自分の作業時間と比較した料金も考慮します。

管理型 という言葉に標準的な定義はありません。あるホストでは、オペレーティングシステムにパッチが適用され、担当者がチケットに回答します。別のホストでは、コントロールパネルがインストールされているだけで、それより上の管理はすべて自分で行います。さらに別のホストでは、対応時間を定めた書面によるサービス契約が含まれます。同じ言葉を掲げた 2 つのプランでも、重要な点がすべて異なる場合があります。そのため、料金を見る前にサービス範囲の文書を確認してください。そのマシンの用途自体をまだ決めていない場合は、VPS で実際にできることを先に考えるべきです。

担当者を決める必要がある作業

稼働中のすべてのサーバーには、同じ作業一覧があります。アンマネージドプランでは、その一覧を自分で担当します。マネージドプランでは、その一覧から作業を減らすために料金を支払います。一覧を確認し、各項目の横に担当者名を書いてください。

• オペレーティングシステムのパッチ適用と、カーネル更新に必要な再起動。
• サービスの追加や削除に合わせて正しく維持するファイアウォールルール。VPS の ufw ファイアウォールの基本では、初期ルールセットを説明しています。
• SSH アクセス。鍵の管理、パスワードログインの無効化、担当者が離れたときの鍵の無効化、そして自分を締め出した場合に再びアクセスする方法が含まれます。
• バックアップ、オフサイトのコピー、そして実際に実行した復元。
• 監視。サーバーに到達できること、ディスク容量が残っていること、サービスが稼働していること、証明書の有効期限が切れていないことを把握します。
• ログの確認と、ログに異常が見つかった場合の対応。
• Web サーバー、データベース、リバースプロキシ、使用している場合はキューのサービス設定。
• 証明書の更新と、自動更新が停止した場合の復旧。
• キャパシティ。out of memory (OOM) killer に任せる前に、メモリが枯渇していることを把握します。
• インシデント対応。自分で選べない時間帯でも起きて、連絡を受けられる状態を指します。

これらの多くは定型作業であり、スクリプトに任せられます。インシデント対応だけは、判断できる人が必要なため、スクリプトには任せられません。マネージドプランが提供する本当の価値はそこにあります。そのため、後のチェックリストでは、パッチ適用よりもサポート範囲について多く質問しています。

通常、マネージドサービスに含まれないもの

ここは契約内容の認識違いが起きやすいため、正確に確認してください。マネージド契約の通常の対象は、オペレーティングシステムとプロバイダーがインストールしたソフトウェアです。対象範囲は、利用者のアプリケーションの手前までです。

利用者自身のコードは利用者の責任です。 アプリケーションから 500 エラーが返っても、サーバー障害ではありません。プロバイダーは Web サーバープロセスが実行中であることを確認し、チケットを利用者に戻します。これは妥当な責任分界です。一方で、購入者の想定と実際に購入したサービスの間に最も大きな差が生じる部分でもあります。

アプリケーションレベルの問題は、通常、対象外です。 遅いデータベースクエリ、更新後に動作しなくなったプラグイン、誤って設定されたキャッシュ、処理が進まなくなったメールキューなどは、基盤のソフトウェアをプロバイダーがインストールした場合でも、通常は対象範囲の外側です。

データ復旧の大部分は対象外です。 プロバイダーのバックアップは、サーバー全体に対するプロバイダー側のイメージを保護するもので、ホストのハードウェアに障害が発生した場合に備えたものです。行を削除した場合、誤ったマイグレーションを実行した場合、または 6 週間前にファイルを破損させて今日気付いた場合に備えたものではないことがほとんどです。保持期間、単一ファイルを取り出せるか、誰がリストアを実行するかを確認してください。

利用者がインストールしたソフトウェアは利用者の責任です。 Docker をインストールした場合、通常、プロバイダーが管理するのはホストであり、コンテナ内のすべては利用者の責任です。

手動編集によってサポート対象外になる場合があります。 契約によっては、顧客がコンポーネントの設定を直接編集すると、そのコンポーネントがサポート対象外になります。設定を調整する予定がある場合は、この点を確認してください。

自分の時間を月額差額と比較する

目の前にある2つの見積もりを比較し、月額の差額を書き出します。その金額が、プロバイダーが上記の作業を代行するために請求する費用です。次に、自分側の負担にも金額を設定します。

• 自分の1時間の価値はいくらで、その一覧の作業を自動化した場合、1か月に何時間かかりますか？
• このサーバー上で稼働するサービスでは、1時間のダウンタイムにいくらかかりますか？

自動更新と外部監視を有効にした安定稼働中の Ubuntu サーバーは、通常の運用作業をほとんど必要としません。多くの月は、作業がまったく発生しません。スクリプトで定型作業を自動化すれば、その費用は小さくなります。費用が大きいのは割り込み対応であり、マネージドプランが提供するのもこの割り込み対応です。サーバーで趣味のプロジェクトを運用している場合、停止しても損失はなく、アンマネージドが明確な選択肢です。注文を受けるサービスであれば、サポート契約によって本当に停止時間が短縮されるかを慎重に確認してください。マネージドプロバイダーでも、チケットを読み、障害を再現し、対応する必要があるためです。

差額はサーバー台数に応じても変わります。マネージドサービスの料金は通常、サーバー単位で請求されます。一方、自動化は1回作成してコピーできます。2台目のサーバーを追加すると、1台目のために作成したスクリプトの実質的な費用は半分になります。そのため、サーバー単位の料金を契約する前に、複数の Linux サーバーを管理する方法を確認してください。比較の両側で使う基準額については、VPS の実際の月額費用が下限を示します。また、ワークロードが十分に大きくなり、マネージドサービスの割増料金が誤差になる段階では、VPS と専用サーバーのトレードオフが重要になります。

管理サービスの追加料金を支払う前にホストへ確認する質問

支払う前に確認し、回答は書面でもらってください。営業ページは作業範囲を定義する文書ではありません。

1. 作業範囲には、作業ごとに何が含まれますか。パンフレットではなく、一覧を提示してもらってください。
2. サポート対象は、自分でインストールしたソフトウェアも含みますか。それとも、ホスト側がインストールしたソフトウェアだけですか。
3. パッチは自動適用しますか。また、事前に確認せずにカーネル更新のための再起動を実行しますか。
4. 適用したパッチによってアプリケーションが壊れた場合、誰が責任を負いますか。
5. バックアップを取得しますか。どこに保存し、どのくらいの期間保持し、誰がリストアを実行しますか。
6. 最近、顧客のサーバーをリストアしましたか。完了までどのくらいかかりましたか。
7. チケットへの応答時間はどのくらいですか。日曜日の03:00でも変わりませんか。
8. root アクセスは維持できますか。root アクセスを使用すると、サポート対象が狭くなりますか。
9. 料金はサーバー単位ですか。それともアカウント単位ですか。
10. 解約する場合、何を持ち出せますか。専用のコントロールパネル内部に依存した構成は、エクスポートが難しい場合があります。

質問5が、他の多くの質問への答えを左右します。この質問に正確に答えられるホストは、実際にリストアを実施した経験があることを示しています。曖昧な回答は、リストアが一度もテストされていないことを意味します。テストされていないバックアップは、単なるコピーにすぎません。質問5には保存場所に関する側面もあります。コピーが物理的にどこに保存されているかは、技術的な問題であると同時に法的な問題でもあります。ホスティング国を選ぶ際に実際に重要なことでは、この点を詳しく説明しています。

中間の選択肢: 管理なし運用と自動化

多くの技術担当者は、どちらの極端も望みません。定型作業はマシンに任せ、マシンでは判断できないことに自分の注意を向けられる、管理なしのプランを求めています。初日に設定してください。新しい VPS で最初の 10 分は、管理なしを選ぶ人にとって実践的な出発点です。SSH アクセスの強化も同じ最初のセッションで行います。

セキュリティ更新の自動化

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

これで、そのファイルには APT::Periodic::Update-Package-Lists "1"; と APT::Periodic::Unattended-Upgrade "1"; が記述されているはずです。ファイルがない場合、またはいずれかの行に 0 がある場合は、何も実行されず、通知も届きません。

システムを変更せずにテストします。パッケージ名は unattended-upgrades ですが、コマンドは単数形であることに注意してください。

sudo unattended-upgrade --dry-run --debug

出力には検討対象になったすべてのパッケージが表示され、保留中の更新がない場合は、最後に No packages found that can be upgraded unattended のような行が表示されます。実際の実行結果は /var/log/unattended-upgrades/unattended-upgrades.log に記録されるため、推測せずにそこを確認してください。

カーネルを更新しても、マシンを再起動するまで何も変わりません。実行中のカーネルは、起動時に読み込まれたものだからです。再起動が必要になると、/var/run/reboot-required ファイルが作成されます。このファイルを監視するか、/etc/apt/apt.conf.d/50unattended-upgrades でマシンに処理させてください。

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false" は、誰かがログインしている間は再起動を保留します。対話的に使用するマシンでは安全ですが、誰もログインしないマシンでは役に立ちません。Ubuntu での unattended upgrades の完全な設定では、ブロックリストの構文とメール設定について詳しく説明しています。

別の場所で実行する監視

サーバー上で動作する監視は、サーバーが停止したことを検知できません。監視も停止するからです。チェックは 2 台目のホストまたは外部サービスに配置してください。ステータス監視のための Uptime Kumaは、通常選ばれる自己ホスト型の解決策です。監視対象とは別のマシンに配置してください。

最低限、4 つを監視します。到達可能性、ディスク使用量、アプリケーションが実際のポートで応答するかどうか、証明書の有効期限です。特に問題になりやすいのはディスクです。毎日少しずつ増えるログファイルやデータベースによって、ほかの兆候がないままマシンが停止することがあります。最初の症状は、サービスが書き込みに失敗して終了することがよくあります。

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

ハートビートも追加してください。サーバー上のタイマーが、バックアップまたはヘルスチェックに成功するたびに URL を呼び出します。監視側は、その呼び出しが届かなくなると通知します。これにより、ネットワーク経路の障害が原因であっても、無応答のサーバーから自動的に通知を発生させられます。取得側からのチェックだけではこの検知はできません。

1 回以上リストアしたバックアップ

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init は created restic repository <id> at sftp:... を 1 回だけ出力します。すでに存在するリポジトリに対して実行すると、上書きせずに失敗します。これは望ましい動作です。そのパスフレーズのコピーをサーバー外にも保管してください。パスフレーズがなければリポジトリを読み取れず、復旧手段もありません。

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots には、今日の日付とともに、今実行した処理が表示されるはずです。restic check はリポジトリの構造を検証し、no errors were found を出力します。ここで、多くの人が省略する作業を行います。

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

期待したファイルが存在するかどうかを確認できます。今なら確認にかかる時間は 10 分です。その後、作業をタイマーに登録し、自分の操作に依存しないようにします。/etc/systemd/system/restic-backup.service を記述してください。

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

続いて /etc/systemd/system/restic-backup.timer を記述してください。

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers には、次回の実行予定と残り時間が表示されます。結果が空の場合は、タイマーではなくサービスを有効化したことを意味します。これはここで最も多い間違いです。Persistent=true は、次回の起動後に実行されなかったジョブを実行します。そのため、一晩停止していたマシンでもバックアップが取得されます。VPS での Restic バックアップでは、リポジトリの構成と保持期間について詳しく説明しています。systemd のサービスとタイマーでは、unit ファイルを行ごとに説明しています。

自動化で得られないもの

自動化しても判断力は得られません。02:00 の自動再起動は、アプリケーションが正常に復旧するかどうかに関係なく実行されます。そのため、各サービスが自動的に起動することを確認し、起きている時間に意図的に再起動してください。

systemctl is-enabled nginx docker
sudo reboot

unattended upgrade によって、アプリケーションを壊すパッケージがインストールされることもあります。パイプライン内の処理だけでは、その事実を検知できません。検知するのは監視です。更新を自動化したら、監視は必須になります。定型作業はマシンが処理します。しかし、インシデントへの対応は引き続きあなたの責任です。

管理サービスに費用をかける価値がある場合

管理サービス側にも公平な評価が必要です。次の4つの状況では、管理サービスが適切な選択になります。

• チーム内に Linux を運用できる人がおらず、採用する予定もない場合。
• コンプライアンス要件で、パッチ適用の責任者を指定する必要があり、その担当者を自分にできない場合。
• ホスティング事業者が専門とする構成を使っており、そのサポートが同じ障害を過去に経験している場合。
• 本来その作業を担当する人が最も高コストな従業員であり、その人の1時間分のコストがプレミアム料金の1か月分を上回る場合。

管理サービスだからといって、自動的に安全性が高くなるわけではありません。管理プランでは、不注意な所有者よりも迅速にパッチが適用されることがあり、これは実際の利点です。一方で、ログインページを備え、固有の脆弱性の履歴もある、大規模なネットワーク公開アプリケーションであるコントロールパネルがインストールされることもよくあります。これは合理的なトレードオフになり得ますが、トレードオフであることに変わりはありません。

判断基準は、毎回同じ一覧に集約できます。10個の作業を書き出し、各見積もりでそれぞれの作業を誰が担当するのかを記録してから、その差分を自分の1時間の価値と比較します。この比較を行った技術担当者の多くは、定型作業をタイマーに任せるアンマネージド構成に行き着きます。これは安さだけを理由にした選択ではなく、十分に説明可能な判断です。

FAQ

管理対象 VPS と非管理 VPS の違いは何ですか？

非管理 VPS では、サーバー本体以外は提供されないため、パッチ適用、ファイアウォール、バックアップ、監視、カーネル更新後の再起動を自分で担当します。管理対象 VPS では、これらの作業の一部をプロバイダーに任せられます。通常は、オペレーティングシステムのレイヤーと、プロバイダーがインストールしたソフトウェアが対象です。ただし、対応範囲は「管理対象」という名称ではなく、プロバイダーごとに決まります。2 つの料金を比較する前に、作業ごとの対応範囲を文書で確認してください。

管理対象 VPS なら、自分でバックアップを用意する必要はありませんか？

いいえ。プロバイダーのバックアップは通常、ホスト障害に備えてサーバー全体のイメージを保護します。ファイルを削除した場合、誤った移行を実行した場合、または数週間前にデータを破損させて今日気付いた場合には、役立たないことがほとんどです。スナップショットの保存期間、単一ファイルを復元できるか、復元を誰が実施するかを確認してください。そのうえで、restic などのツールを使用して独自のオフサイトコピーを保持し、restic restore latest --target /tmp/restore-check でテストして正常に機能することを確認してください。

管理対象 VPS は、非管理 VPS より安全ですか？

それだけでは安全とはいえません。管理対象プランでは、まったくログインしない所有者よりも迅速にパッチが適用されるため、実際にリスクは低下します。多くの管理対象プランではコントロールパネルもインストールされます。コントロールパネルは、独自のログインページと脆弱性の履歴を持つ、大規模なネットワーク公開アプリケーションです。自動セキュリティ更新、閉じたファイアウォール、鍵のみの SSH、不要な待ち受けサービスがない構成の非管理サーバーは、コントロールパネルを実行する管理対象サーバーよりも攻撃対象が小さくなります。

非管理 VPS で開始し、後から管理対象に切り替えられますか？

通常は可能ですが、チェックボックスを選ぶだけで済むことはほとんどありません。プロバイダーは、管理責任を引き受ける前にサーバーを監査または再構築することが一般的です。確認できない構成はサポートできないためです。導入時に何を行うのか、再インストールが必要か、自分で設定した内容がその後も対応範囲外になるかを確認してください。

管理対象 VPS でも root アクセスを維持できますか？

ほとんどの管理対象 VPS プランでは維持できます。ただし、root アクセスとサポート範囲は相互に関係します。手動で変更したコンポーネントについて、サポート範囲を縮小したり、サポート対象外にしたりするプロバイダーがあります。また、問い合わせの調査が深い段階に進むと、独自のテンプレートから再構築するプロバイダーもあります。設定を変更する前に、このルールを文書で確認してください。再構築の負担を週末ではなく 1 時間で済ませられるよう、設定ファイルはバージョン管理してください。