「会社に合うクラウド」を探してはいけない理由
会社単位の選択は、複数のワークロードが同じ条件だと前提します。実際にはそうでない場合が多いです。外部顧客が使う公開ウェブサービスは、突発的なトラフィックと利用者の体感遅延が重要です。夜間だけ回るデータ集計処理は、実行時間帯と内部データへの依存が重要です。社内管理システムは同時利用者が少なくても、権限と監査、既存業務システムとの接続が先に立ちます。データベースはアプリケーションより移動と復旧の負担が大きくなります。
これらを一括りにして「AWSを維持するか、他のCSPへ移すか」と問えば、異なる要求が一つの平均値に消えます。その結果はたいてい二方向のどちらかに流れます。機能が最も多い事業者を選んで実際には使わない複雑さまで抱えるか、月額基本料金の低い商品を選んでデータ移動と支援、運用人員、障害対応で想定外の負担に出会うかです。どちらにせよ問題は事業者ではなく、比較の前にワークロードの条件を分けなかったことにあります。[1]
ワークロードはどの単位で分けるべきか
ワークロードは、目的と責任、障害影響を個別に判断できる実行単位として捉えます。サーバー一台と一致する必要はありません。一台のサーバーに複数のワークロードが同居することもあります。一つのワークロードが複数のサーバーとマネージドサービスにまたがることもあります。
AWSのWell-Architectedの範囲指針は、レビューの前にワークロードの所有者と目的、停止時の影響、境界、外部依存を先に確認させます。これらの問いは、インフラ資産の一覧より事業成果と責任境界を先に見せます。[2]
次の五条件のうち一つでも実質的に異なれば、別ワークロードとして分ける候補になります。業務所有者や最終承認者、個別に開始・停止・廃止できるかどうか、扱うデータの機微度と所在と保存条件、停止影響と運用支援時間、利用者の地域と遅延要求と需要パターンと外部依存です。
逆に、目的と所有者、データ、障害影響、運用方式がすべて同じで常に一緒に変わる構成要素なら、一つのワークロードにまとめます。最初からマイクロサービス単位に細かく割る必要も、現在のサーバー一覧をそのままワークロード一覧に写す必要もありません。
依存関係を確認し、移行を検証 — 一緒に移すシステムを整理し、リハーサルと切戻し条件を整えてから本番移行を実施します。
Workload Classification Matrix
下のマトリクスは、NISTの役割・統制モデルとAWS・Azure・Google Cloudのアーキテクチャ検討項目を、一つの配置意思決定の順序に再構成したものです。製品機能を比べる表ではなく、比較に入る前に要求を整える表です。[3][6]
この表の値は推測で埋めません。各項目にはConfirmedかUnknownを付けます。確定した値には根拠と承認者を残します。
とくに「規定上は国内になければならない」「セキュリティのため専用線が必須だ」「24時間支援が必ず要る」といった文は、誰がどの法令・契約・社内方針・業務要求を根拠に確定したのかを確認しなければなりません。特定の産業に適用されるデータ所在や規制の結論を、他の組織へそのまま移してはいけません。
分類軸 | カードに記録する問い | 代表的な記録値 | 配置判断での使い方 |
|---|---|---|---|
| 業務目的と所有者 | このワークロードが生む事業成果は何で、誰が最終責任を負うか | 顧客注文処理、社内レポート配布 / 業務Owner / 技術Owner | 障害影響と承認責任を明確にする。Ownerがなければ最終配置を承認しない |
| 境界とライフサイクル | 何と一緒に変わり、何を独立して止められるか | 独立デプロイ可能、共同変更、期間限定プロジェクト、常時運用 | ライフサイクルと変更周期が異なる構成を分ける |
| 相互作用と状態 | 利用者は即時応答を待つか、実行中に状態を保持するか | Interactive、Batch、Event-driven / Stateful、Stateless、Mixed | 同じ障害・拡張方式で扱えるかを判断する。ここで実装方式は選ばない |
| 需要と性能 | 負荷は一定か急変か、特殊な演算資源が必要か | 一定、突発、季節性、予約実行 / 遅延敏感 / GPU要・不要・未確認 | 候補環境が要求の形を支えるか確認する。サーバー容量は別途測定に回す |
| 利用者と地域 | 利用者はどこにいて、どこまでの遅延を許容するか | 国内利用者、多地域利用者、内部網利用者 / 遅延要求の確定・未確定 | Regionとネットワーク候補を絞る。利用者が国内にいるという理由だけでデータ所在要求を推定しない |
| データと移動 | どのデータを読み書きし、どこからどこへ移動するか | データ等級、保存場所、処理場所、保存条件、移動経路 | セキュリティ・法務・契約・社内方針の担当者が確定した条件だけをHard Constraintに使う |
| 依存とネットワーク | どのDB・認証・外部API・オンプレミスに依存するか | 強い結合、緩い結合、同期呼び出し、非同期配信 / Ingress・Egress経路 | 遅延と接続の安定性、データ移動、障害伝播の可能性を確認する |
| 障害影響と復旧要求 | 停止すると顧客・売上・業務にどんな影響があり、どこまで許容されるか | 即時停止、限定運用可能、翌営業時間に復旧可能 / 承認済みの許容停止・損失水準 | 復旧要求が候補環境を制限するかだけを記録する。復旧設計はこの記事の範囲ではない |
| 運用能力と責任 | 誰がパッチ・監視・障害対応・支援要請を担当するか | 24時間対応、業務時間対応、外部運用、役割未定 | チームが実際に負えない運用の複雑さを候補から外す |
| 費用構造と離脱 | どの使用量が費用を動かし、環境を変えるとき何を移すか | 常時利用、遊休時間、データ移動、支援、ライセンス / 移植性の確認・未確認 | 最安の月額より主要な費用要因とExit制約を確認する |
Hard Constraint / Preference / Unknownを混ぜない
要求の一覧があっても、すべての項目を同じ重みで比べれば決定が歪みます。三つの状態を分けなければなりません。
判断の規則は簡単です。すべてのHard Constraintを満たす環境だけが候補になります。優先順位はその候補の中でPreferenceを比べて決めます。候補群を変えうるUnknownが残っていれば判断を保留します。
既存の契約や割引、事業者とのパートナー関係、チームの慣れはおおむねPreferenceです。文書として残る契約上の制約や技術的な依存がない限り、Hard Constraintに上げてはいけません。パートナー関係は技術的優位を証明するEvidenceでもありません。
Unknownを別の状態として置く理由は、意思決定の空欄を隠さないためです。データ移動量が分からない状態で転送料金の安い事業者を探すのは順序が違います。夜間の障害対応主体が決まっていない状態で24時間サービスの構成を比べるのも同じです。
状態 | 意味 | 判断規則 | 例 |
|---|---|---|---|
| Hard Constraint | 満たせなければ候補になれない条件 | 一つでも違反すれば候補から外す。根拠と承認者が要る | 承認済みの処理地域、必須の接続方式、要求される支援時間、特定の運用責任境界 |
| Preference | 満たせばよいが他の利点と交換できる条件 | Hard Constraintをすべて通過した候補の中だけで比較する | チームの既存経験、慣れた管理画面、既存契約、割引、導入速度 |
| Unknown | まだ事実や責任者が確認されていない条件 | 0や問題なしとみなさない。Owner・Evidence・Due Dateを指定する | データ等級が未確定、最大負荷が未測定、夜間障害の担当者が未定、データ移動経路が未把握 |
Workload Placement Card
分類の結果は議事録の文よりも一枚のカードに残すほうが良いです。次の様式は、クラウド事業者が決まっていない状態でも書けます。七つの欄に分かれます。
カードは長く見えますが、埋められない項目こそが今の意思決定の危険です。すべてのフィールドに詳細設計が要るわけではありません。少なくとも確定、該当なし、Unknownのいずれかは残します。
- Identity
- ワークロードIDと名称、生む業務成果、業務Ownerと技術Owner、現在のLifecycleを記す欄です。
- Boundary
- 含む構成要素と含まない構成要素、一緒に変わる対象、主要な外部Dependencyを記す欄です。
- Behavior
- InteractionとState、需要パターン、遅延・性能要求、特殊な演算資源の要求を記す欄です。
- User & Data
- 利用者と呼び出し主体の所在、データ等級、保存・処理・移動の場所、保存条件、要求を確定した担当者と根拠を記す欄です。
- Failure & Operations
- 停止時の影響、承認済みの許容停止とデータ損失要求、支援時間、パッチ・監視・障害対応の責任、外部支援とEscalation経路を記す欄です。
- Economics & Exit
- 主要な費用Driver、遊休・変動の利用特性、データ移動経路、移植性の制約、環境離脱と復旧経路の有無を記す欄です。
- Decision State
- Hard ConstraintsとPreferences、UnknownごとのOwner・Evidence・Due Date、候補環境の範疇、候補Operating Model、Vendor比較の可否を記す欄です。
Workload → Constraint → Operating Model → Vendor Funnel
クラウドの選択は四段階で絞ります。ワークロードを定義し、次に制約を確定します。運用モデルを決めたうえで、最後に事業者を比べます。
ここでのOperating Modelは、特定のデプロイ技術を選ぶ段階ではありません。OSとランタイム、データ、観測、障害対応のうち、どの責任を社内チームが持ち、どの責任を外部へ渡すかを決める段階です。NISTの参照アーキテクチャも、サービスモデルによって提供者と利用者の統制範囲が変わることを示します。[4]
運用モデルが先である理由は、同じ機能を提供するサービスでもチームが負う責任の範囲が違うからです。管理の負担を担う人員がいないチームには、低いインフラ価格は十分な利点になりません。逆に、プラットフォームの制約を受け入れにくいワークロードは、運用の楽さだけで候補を決められません。
Google CloudのHybrid・Multicloud戦略の指針も、組織全体に一つの環境を当てるより、事業のUse Caseとワークロードごとの要求を確認し、どのワークロードをどの環境で動かすか計画するよう促します。だからといって複数のクラウドを使うこと自体が目的になるわけではありません。複数のワークロードが同じ候補に集まれば一つの事業者に決めます。条件が大きく違えば異なる配置結果になります。[5]
同じ会社の中でもカードは分かれます。公開商品カタログは外部利用者が読み中心で使い、リクエスト量が急変し、状態への依存が低いため、利用者の地域と遅延、コンテンツの更新方式、障害時に許容される機能縮小を先に確認します。精算バッチは決まった時刻に実行され、状態と内部データへの依存が高く、失敗すると次の業務が遅れるため、データの所在と移動、実行完了の時点、再実行の責任、夜間支援の可否を先に確認します。
二つのワークロードが同じ会社にあるからといって、同じ環境が自動的に正解になるわけではありません。逆に特性が違うからといって必ず別の事業者を使う必要もありません。カードが示すのはVendorの数ではなく、配置判断を分けるべき理由です。
段階 | 決める内容 | この段階でしないこと | 成果物 |
|---|---|---|---|
| 1. Workload | 目的、所有者、境界、状態、利用者、依存 | 事業者名や商品の選択 | ワークロード一覧と境界 |
| 2. Constraint | 障害影響、データ、地域、遅延、運用、Exit条件 | 必須と選好を混ぜた採点表の作成 | Hard Constraint / Preference / Unknown |
| 3. Operating Model | パッチ・観測・障害・支援・セキュリティの責任を誰が持つか | VM・PaaS・Container・Kubernetesの詳細設計 | 実現可能な責任分担モデル |
| 4. Vendor | 条件を満たす事業者の実際のRegion・サービス・支援・価格の確認 | 条件の違う商品を月額だけで比較 | Shortlistと追加検証項目 |
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
Vendor比較を始めてよいかを確かめるPreflight
次の11項目に答えられなければ、事業者比較表を作る前に要求から補います。前の四項目はワークロードそのものを問います。業務成果と業務・技術Ownerが決まっているか、含む範囲と主要なDependencyが文書に残っているか、Stateful・Stateless・Interactive・Batchなどの動作特性が分類されているか、停止影響と許容できる停止・データ損失の要求が承認されているかです。
次の四項目は制約を問います。データ等級と保存・処理・移動の場所の要求とその根拠が確認されているか、利用者の所在と遅延要求とネットワーク経路が確認されているか、Hard ConstraintとPreferenceとUnknownが分かれているか、結果を変えうるUnknownごとにOwnerとEvidenceとDue Dateがあるかです。
最後の三項目は運用と費用を問います。パッチ・監視・障害対応・支援時間の責任境界が決まっているか、費用を動かす利用特性とExit制約が特定されているか、候補事業者を同じRegion・支援・責任・使用量の前提で比べられるかです。
READYは最終選択が終わったという意味ではありません。ここでようやく実際のRegion提供の有無、サービス責任の範囲、支援条件、移植性、同じ使用量で計算した費用を確認できるという意味です。
判定 | 条件 | 次の行動 |
|---|---|---|
| READY | すべてのHard Constraintが確認済みで、候補群を変えるMaterial Unknownがない | 実際の事業者・サービス比較を開始 |
| CONDITIONAL | 候補群は作れるが、一部の非本質的なUnknownが残る | 前提を明示した限定比較と追加検証を並行 |
| NOT READY | データ、障害影響、Owner、運用責任など中核条件が未確定 | 価格・機能比較を止めてPlacement Cardから補う |
この記事が止まる地点
Placement Cardが完成した後にも別の意思決定が残ります。リクエスト量と資源要求をどう測るか、ネットワーク経路ごとに料金がなぜ生じるか、どのバックアップ手段がどの障害を防ぐか、許容停止とデータ損失をどう数値に移すか、顧客・取引あたりの費用をどう計算するか、移行の総費用をどう検討するかは、それぞれ独立した分析が要ります。
VM・PaaS・Container・Kubernetesのどれを選ぶか、サービスの健全性をどの指標で定義するか、デプロイとロールバックをどの方式で実装するかも、この記事では決めません。ここでは、そうした要求が当該ワークロードのPlacement Constraintとして存在するかだけを記録します。
良いクラウドの決定はロゴではなく配置地図を残す
クラウド選定の会議が終わったとき「A社にした」という一行しか残らなければ、次のワークロードでも同じ議論を最初から繰り返します。
代わりに、どのワークロードがどの条件のためにどの候補環境へ絞られたのか、何が必須で何が選好だったのか、どのUnknownを誰が確認したのかが残るべきです。そうすれば事業者が変わっても、新しいRegionやサービスが増えても、判断の構造をもう一度使えます。
クラウドをうまく選ぶ方法は、事業者の一覧を長くすることではありません。ワークロードを分け、障害の費用と運用の制約を先に確定したうえで、その条件を通過した候補だけを比べることです。
