ホスティングモデルは、それらが割り当てる運用上の責任と、それらが可能にするアーキテクチャを通じて比較しましょう。クラウドの規模、仮想マシン、専用ハードウェアはシステムの異なる側面を表しており、どれか一つだけではプライバシー、コスト、復旧の挙動を証明することはできません。
誰かに所有してもらう必要がある作業から始める
ホスティングの決定は、コンピューティングリソースだけでなく運用上の作業も割り当てます。あるプロジェクトは従来のウェブサイトを運営するアカウントを必要とし、別のプロジェクトはオペレーティングシステムのパッケージとバックグラウンドプロセスの制御を必要とします。さらに別のプロジェクトは、特定のサービス契約の下でメンテナンスが行われるデータベースプラットフォームを必要とします。まずそれらの責任を、それらを維持できる人材とともにリストアップしましょう。
共有ホスティングは通常、アカウントレベルの環境を提供します。VPSはゲストオペレーティングシステムを提供し、専用ハードウェアはマシン境界を物理サーバーに移します。マネージドは別の問いです。製品ラベルは、誰がパッチを適用し、データを復元し、インシデントを調査するかを教えてくれません。普遍的な機能として扱うのではなく、管理の範囲と復旧手順を尋ねましょう。
クラウドが比較に何を加えるかを理解する
NISTは、オンデマンドアクセス、リソースプーリング、弾力性、測定されたサービスなどの特性を通じてクラウドコンピューティングを説明しています。仮想マシンはクラウドプラットフォームの一コンポーネントになり得るため、VPSとクラウドは相互排他的な技術ではありません。有用な比較は、提供される特定のサービス間、つまり固定仮想マシン、弾力的なフリート、マネージドサービスを中心に構築されたアプリケーションの間で行うものです。
ハイパースケーラーは、非常に大規模にインフラストラクチャとサービスプラットフォームを運用するプロバイダーを指す業界用語です。その規模は幅広いデプロイツールと地理的な選択肢を提供できますが、特定のアーキテクチャがあなたのニーズを満たすかどうかは教えてくれません。各コンポーネントのリージョン、サービス依存関係、IDモデル、契約を評価しましょう。小規模なプロバイダーも大規模なプラットフォームも、データがどこに行くかの明確な説明を必要とします。
| 運用モデル | プロジェクトが利用できる制御 | 選択する前の問い |
|---|---|---|
| 共有ホスティングアカウント | アカウントスコープ内のサイト設定 | ランタイムはアプリケーションに適合しますか? |
| 仮想マシン | ゲストOSとインストールされたサービス | ゲストを維持し復元するのは誰ですか? |
| 専用マシン | 物理サーバー境界 | ワークロードはこの境界を正当化しますか? |
| マネージドクラウドサービス | サービスAPIとサポートされる設定 | 顧客の責任として残るものは何ですか? |
復旧できるアーキテクチャを選ぶ
単一のマシンは、復旧要件が復元または計画的なメンテナンスウィンドウを許容する場合、小規模アプリケーションの妥当な出発点になり得ます。2番目のアプリケーションノードを追加することは、トラフィックルーティング、セッション、永続データが両方で正しく機能する場合にのみ設計を変えます。同じ不完全な復旧計画を実行する2台のサーバーは、依然として不完全な復旧計画です。
分散ストレージはこの区別を例示しています。Cephのようなソフトウェアはストレージ作業をクラスタ全体に分散し、オブジェクト、ブロック、ファイルインターフェースを提供します。レプリケーションやイレイジャーコーディングは特定のハードウェア障害の許容に役立つかもしれませんが、クラスタは復旧とリバランスのための容量も必要とします。分散されたライブコピーは独立したバックアップの代わりにはなりません。ネットワーク分断中の書き込みの挙動を決定し、選択した実装に関連する障害ケースをテストしましょう。
完全な運用予算を比較する
予算をワークロードとして書きましょう。通常のトラフィック、繁忙時間帯、保存データ、バックアップ保持、復旧に必要な転送です。有料ソフトウェア、外部API、管理時間、データを再度移動するコストを含めましょう。開始時の月額数値と使用量ベースの見積もりは、異なる問いに答えるものです。同じ期間で比較し、前提を結果とともに保持しましょう。
大規模なクラウドプラットフォームの場合、アプリケーションを稼働させ続けるために必要なすべてのサービスを特定しましょう。VPSの場合は、マネージドサービスが代わりに吸収する作業を含めましょう。どちらのアプローチも自動的に安くなるわけではありません。小規模な代表的なデプロイまたは文書化された見積もりから始め、実際の請求額をモデルと照らし合わせて見直しましょう。定常状態だけで予算を組むのではなく、復旧トラフィックと一時的な移行容量のための余地を確保しましょう。
プライバシーを依存関係マップとして扱う
マシンのリージョンは、より広い地図の一項目にすぎません。認証、監視、サポートツール、バックアップ、モデルAPIは、別々のサービスを通じて動作する場合があります。それぞれが何を受け取り、誰がアクセスでき、どのくらい保持されるかを記録しましょう。AWSの責任共有モデルは、プロバイダーがインフラストラクチャの義務と顧客の義務を明示的に分離する一例であり、その範囲はサービスによって変わります。
あるプロバイダーの義務を別の契約に持ち込むことなく、プロバイダーを比較する際にこの区別を使いましょう。SwissOctetの設定は、ホスティングの場所とリストされたリソースを記述します。後で追加する連携の場所を確立するものではありません。各依存関係が受け取るデータを最小化し、管理を安全にし、自分のアプリケーションのデータの流れについて述べる前にバックアップ先を検証しましょう。
移行パスを意思決定の一部として使う
アプリケーションデータ、設定、IDをどのようにエクスポートできるかを確認しましょう。仮想マシン上の従来のアプリケーションは移動が簡単かもしれませんが、サービス固有のデータベースやイベントシステムは適応が必要な場合があります。ポータビリティは運用知識にも依存します。誰も復元方法を知らないバックアップは、その形式がオープンであっても弱い出口計画です。
最初のSwissOctet候補リストとしては、アカウントレベルのWeb環境が適合する場合はCanvasを、ゲストOSの制御にはVectorを、物理境界が重要な場合はMetalの範囲を比較しましょう。ストレージ指向のオプションは別の容量の問いをサポートするものであり、マネージド分散クラスタとして説明すべきではありません。運用できる程度にアーキテクチャを小さく保ち、想像上の将来の規模ではなく、テストされた要件に対応する場合にプラットフォームの複雑さを追加しましょう。
実践チェックリスト。
- 管理と復旧の所有権を割り当てる。
- VMをより広いクラウドプラットフォームと区別する。
- 依存関係、転送、メンテナンスを予算化する。
- ノードを追加する前に障害境界をテストする。
- 実行可能なデータエクスポートと移行パスを記録する。
重要な詳細。
VPSはクラウドプラットフォームの一部になり得ますか?+
はい。仮想マシンはクラウドサービスになり得ます。名前が排他的な技術を表すと仮定するのではなく、実際のリソース、スケーリング、管理モデルを比較しましょう。
分散ストレージはバックアップの代わりになりますか?+
いいえ。ライブ冗長性は選択されたコンポーネント障害に対応します。独立したバックアップと復元テストは、削除やアプリケーションデータの破損など、他の障害に対応します。
大規模クラウドは常にプライバシーにとって悪い選択ですか?+
いいえ。特定のサービス、データフロー、契約上の制御を評価しましょう。プロバイダーの規模だけではアーキテクチャの適合性を確立することはできません。
出典へ。
これらの参考文献は、このガイドの技術的概念をサポートしています。本番システムを変更する前に最新のドキュメントを確認してください。
- NIST SP 800-145: クラウドコンピューティングの定義 nvlpubs.nist.gov
- AWS: 責任共有モデル aws.amazon.com
- Ceph: ストレージアーキテクチャ docs.ceph.com
- Ceph: イレイジャーコーディング docs.ceph.com
SwissOctetによる編集ガイダンス。例は例示目的です。サービス仕様、利用可能なオプション、契約条件は別途確認する必要があります。