3.11 クラウドアーキテクチャ

概要と動機

クラウドコンピューティングとは、他者のインフラをネットワーク経由でオンデマンドに借り、使った分だけ課金され、終われば解放することです。クラウドアーキテクチャとは、借りたそれらのリソースを、古いデータセンターの借り物のコピーではなく、ネイティブな住処として扱うシステムを設計する規律です。その区別が、本章の要点のすべてです。レガシーのアプリケーションをクラウドのプロバイダーに移し、設計を何も変えなければ、より大きな請求書と、ほぼ同じ脆さを得ます。あるいはクラウドのために設計すれば、弾力性、区別のつかない仕事の分類全体を消すマネージドサービス、誰も呼び出さずに建物全体の障害を生き延びる能力を得ます。これは3.1章の基礎の上に直接築かれます。クラウドアーキテクチャはアーキテクチャであり、所有していない基盤に適用された、同じトレードオフと品質特性を持ちます。

大きなチームにとって、クラウドは誰が何をするかを配線し直すので、賭け金はより高くなります。チームがデータベース、キュー、グローバルな負荷分散装置を数分でプロビジョニングできるとき、ボトルネックは調達ではなくガバナンスになります。これを同時にやっている数十のチームにわたる、コスト、セキュリティ、一貫性です。クラウドはすべてのエンジニアに会社のクレジットカードと電動工具の倉庫を与え、それは同程度に素晴らしく、危険です。アーキテクチャを正しくすることは、利益(速度、弾力性、レジリエンス)を捉えながら、支出、セキュリティの姿勢、データ所在地を管理下に置くガードレールを設けることを意味します。

企業と政府は、両方の刃を鋭く感じます。企業は何十年もの既存システムとともに到着するので、そのクラウドの物語は通常、ハイブリッドの接続と難しい作るか買うかの判断に満ちた、移行の物語です。政府は、主権、認可の制度、法的に特定の国境を越えられない市民のデータという追加の重みを負います。ここでの決定(どのサービスモデルか、いくつのプロバイダーか、障害ドメインがどこにあるか、何がマネージドサービスで何が自分のコードか)は、十年にわたってコストとリスクを形づくります。

主要原則

データセンターを写真に撮るのではなく、クラウドのために設計する。 弾力性、マネージドサービス、障害ドメインへの認識がここにいる理由です。リフトアンドシフトはそれらを捨てます。
すべてはコードとしてプロビジョニングされる。 人間がクリックして生み出したものは、文書化されておらず、再現不能で、監査できません。
障害ドメインにまたがって意図して設計する。 リージョン、可用性ゾーン、サービスは失敗します。アーキテクチャが、それが肩をすくめることか障害かを決めます。
責任共有モデルは、スローガンではなく契約である。 どの線までをプロバイダーが保護し、どの線からをあなたが保護するかを正確に知ります。
区別のつかないものは買い、差別化するものは作る。 マネージドサービスは、配管については本物のお金に値します。競争上の優位は自分の手に保ちます。
ロックインは値付けするコストであって、避けるべき罪ではない。 可搬性には価格があり、てこには価値があります。反射ではなく意図して決めます。
コストは第一級の品質特性である。 クラウドでは、アーキテクチャと請求書は同じ決定です。

推奨事項

サービスモデルを意図して選び、マネージドを既定とする

クラウドのプロバイダーは、as-a-serviceのモデルで捉えられる範囲に沿って販売します。Infrastructure as a Service(IaaS)は生のコンピュート、ストレージ、ネットワーキングを貸し、Platform as a Service(PaaS)はマネージドなランタイムを貸して、サーバーの世話なしにコードをデプロイでき、Software as a Service(SaaS)は完成したアプリケーションを貸します。サーバーレスコンピューティングは、関数とマネージドなイベント駆動のサービスを含め、これをさらに押し進めます。コードや設定を提供すれば、プロバイダーがあらゆるプロビジョニングを扱い、アイドル時にはゼロまでスケールします。範囲を一段上がるごとに、制御がてこと交換されます。最も多くの制御と最も多くの運用負担を持つIaaSから、その両方が最も少ないサーバーレスまで。

既定は、要求が許す限り、その範囲の高い所まで登ることであるべきです。パッチ、バックアップ、フェイルオーバー、スケーリングを扱うマネージドデータベースは、ほぼ常に、自前運用のものよりエンジニアの良い使い方です。より低水準のIaaSは、本当にそれを必要とするケースのために取っておきます。特殊なハードウェア、珍しいコンプライアンスの境界、ライセンスの制約、マネージドの提供が満たせない性能。理由をアーキテクチャ決定記録(3.1章)として書き留めてください。「自前のメッセージブローカーを運用している」は、毎年再び正当化されるべき主張だからです。

リージョンと可用性ゾーンを、明示的な障害ドメインとして設計する

クラウドのリージョンは地理的な領域です。その中で、可用性ゾーンは、独立した電源、冷却、ネットワーキングを持つ物理的に別のデータセンターで、低レイテンシのレプリケーションができるほど近く、一つの障害が他を巻き込まないほど離れています。これらはクラウドが壊れる継ぎ目なので、アーキテクチャはそれらを第一級として扱わなければなりません。本格的なワークロードの基準はマルチゾーンです。コンピュートとデータを少なくとも二つ、できれば三つのゾーンに分散させ、一つを失っても障害ではなく容量の低下で済むようにします。これは安い保険で、飛ばす良い言い訳はめったにありません。

マルチリージョンはより重い決定で、レジリエンスと復旧の目標(3.5章)と災害復旧計画(9.5章)に結びつきます。リージョンにまたがって広げることは、リージョン全体の障害の生き延びを買い、データをユーザーに近づけられますが、本物のコスト、レイテンシ、一貫性の問題を持ち込みます。リージョン間の同期レプリケーションは遅く、非同期レプリケーションはフェイルオーバーでのデータ損失を受け入れることを意味するからです。「高可用」でありたいという漠然とした願いではなく、明示的な目標復旧時間と目標復旧時点に基づいて決めます。ほとんどのシステムは、堅牢なマルチゾーンと、テストされたマルチリージョンの復旧経路を必要とし、リージョンにまたがるアクティブ・アクティブを本当に必要とするものはまれで、必要なく築いたものは、毎日その複雑さを払います。

責任共有モデルを、アーキテクチャ上の境界として扱う

クラウドのセキュリティは責任共有モデルで動きます。プロバイダーはクラウド(物理的な施設、ハイパーバイザー、マネージドサービスの内部)を保護し、あなたはクラウドに置くもの(データ、アクセス制御、ネットワークの設定、コード)を保護します。正確な線は、サービスの範囲を登るにつれて動きます。IaaSではオペレーティングシステムにパッチを当て、マネージドデータベースではそうしませんが、誰が接続できるか、データが暗号化されているかは、なお所有します。最も高価なインシデントは、この線の読み違いから来ます。最も有名なのは、プロバイダーが既定で非公開にしたと誰かが想定したために、何百万ものレコードを漏らした開いたストレージのバケットです。

設計で境界を明示し、詳細は、インフラとクラウドのセキュリティを深く扱う4.3章に任せます。アーキテクチャ上、命令は一定です。データを既定で保存時も転送中も暗号化する、ネットワーク上の位置ではなくアイデンティティを通じて最小権限を与える、一つの認証情報の影響範囲を小さく保つ、インターネットから到達可能なリソースは数分以内に探られると想定する。これらをランディングゾーンに組み込み、チームが引き継ぐようにします。

統治されたランディングゾーンの中で、すべてをコードとしてプロビジョニングする

成熟したクラウドの実践では、人がコンソールをクリックしたから存在する本番のリソースはありません。すべてがInfrastructure as Code(8.2章)で宣言され、バージョン管理され、レビューされ、パイプラインを通じて適用されるので、インフラは再現可能で、監査可能で、差分が取れます。これが、マルチゾーン、マルチリージョン、災害復旧を願望ではなく本物にするものです。環境が記憶ではなくプログラムなので、新しいリージョンに同一の環境を立ち上げられます。

そのコードを、ランディングゾーンで包みます。すべてのチームがその上に築く、アカウント(またはサブスクリプションやプロジェクト)、ネットワーキング、アイデンティティ、ログ、ガードレールの、事前に築かれた統治された基盤です。一つのチームの間違いが別のチームのデータに届かず、すべてのドルが所有者にたどれるよう、別々のアカウントを影響範囲と課金の境界として使います。事後のレビューに頼るのではなく、禁止された設定(公開データベース、暗号化されていないボリューム、許可されないリージョンのリソース)を防ぐポリシー・アズ・コードとして、ガードレールを徹底します。中央のプラットフォームチームが通常ランディングゾーンを所有し、本章を、プラットフォームエンジニアリング(8.4章)とコンテナ、クラウドネイティブのランタイム(8.3章)に結びつけます。

ロックインを誠実に値付けし、マルチクラウドには懐疑的であれ

ベンダーロックインはプロバイダーを切り替えるコストで、二値ではなく範囲です。プロバイダーのマネージドキューを使うとある程度のロックインを生み、独自の機械学習プラットフォームを使うと多くを生みます。それへの反射的な恐れが、チームに、決して行使しない可搬性を守るために、本物のてこ(クラウドを使う価値を生むマネージドサービス)を犠牲にさせます。誠実な動きは、値付けすることです。重要な依存ごとに、去ることが実際にいくらかかるかを見積もり、今それがあなたに節約するものと量ります。可搬性を保つためにマネージドサービスを抽象化することは、それが保険をかける移行が決して要したであろうより、恒久的にコストがかかることがよくあります。

これが、本物のマルチクラウド(同じワークロードを二つのプロバイダーにまたがって動かすこと)が、通常は戦略ではなくカーゴカルトである理由です。最小公倍数の設計に押し込み、運用の表面を倍にし、チームが持たなければならない専門性を掛け合わせますが、すべては、めったに現実にならないリスクをヘッジするためです。二つ以上のプロバイダーに触れる正当な理由はあります。第二のベンダーのベストオブブリードのSaaS、規制当局のレジリエンスの義務づけ、意図した主権の要件(10.11章)。ハイブリッドクラウド、つまり一部のシステムをオンプレミスに置いてクラウドに接続することは、企業の移行の間と、法的に移せないデータのために、しばしば避けられません。スライドが「マルチクラウド」と言ったからではなく、明確な目と書面の正当化をもってこれらを選びます。

コストのためにアーキテクチャし、ウェルアーキテクテッドな考え方を採用する

クラウドでは、アーキテクチャ上の決定は支出の決定です。「念のため」の過剰なプロビジョニングは、来月の請求書に現れます。コストを設計する品質特性として扱い、FinOps、つまりクラウド支出に対する共有された財務上の説明責任の規律(9.4章)を採用して、エンジニアリング、財務、製品が一緒に請求書を所有するようにします。すべてのリソースに所有者をタグ付けし、チームごと、サービスごとにコストを可視にし、継続的に適正サイズにし、ピークではなく負荷に払うようオートスケーリングを使い、クラウドが提供する価格のてこ(コミット利用割引、中断可能な仕事のためのスポット容量)を活用します。

コストを超えて、ウェルアーキテクテッドなフレームワークをレビューのチェックリストとして使います。主要なプロバイダーはそれぞれ公開しており、同じ柱に収束します。信頼性、セキュリティ、コスト最適化、性能効率、運用上の卓越性、持続可能性。設計時と、その後定期的に軽いレビューを実施し、システムを各柱に照らして採点し、ギャップを追跡される作業として記録します。気づかなかったトレードオフを捉える、安い方法です。

トレードオフ: 長所と短所

アプローチ	長所	短所
リフトアンドシフト(リホスト)	速く、初期の労力が少なく、データセンターを素早く出られる	古い脆さを保ち、弾力性とマネージドサービスを逃し、しばしばコストが高い
クラウドネイティブの再設計	完全な弾力性、レジリエンス、マネージドサービスのてこ	前もっての労力とスキルが高い。吸収すべき変化が大きい
単一クラウド、深い統合	単純さ、最大のてこ、より低い運用の表面	ロックインとプロバイダーのリスクの集中
マルチクラウド(同じワークロード、二つのプロバイダー)	プロバイダー障害のヘッジ、交渉のてこ	最小公倍数の設計、倍の運用と専門性
ハイブリッド(クラウドとオンプレミス)	データ所在地とレガシーの制約を満たし、段階的な移行	ネットワークの複雑さ、同時に動かす二つの運用モデル
サーバーレス / 高度なマネージド	最小のトイル、ゼロまでスケール、速いデリバリー	制御が少なく、プロバイダー固有、コールドスタートとクォータの制限

中心的な緊張は制御とてこで、すべての行に走っています。プロバイダーに渡すものが多いほど、速く動き、運用が少なくなり、結合が深くなるというコストを払います。解決は、一方の極を選ぶことではなく、各ワークロードを意図して置くことです。汎用の配管にはマネージドの範囲の高い所に登り、制御が本当にその価値を稼ぐ所ではより低く留まり、可搬性を無料で依存を罪として扱うのではなく、ロックインを両方向で値付けします。大きな組織は、恐れ(ロックインへの、クラウドへの、コストへの)に、分析ではなく反射でこの選択をさせたときに、困ったことになります。

チームで議論すべき問い

ワークロードのうち、どれがリフトアンドシフトされていて、データセンターのアーキテクチャに対してクラウドの価格を払っていますか。 締め切りのもとで移行し、すべてをそのままリホストして勝利を宣言し、それから請求書がデータセンターより高く、レジリエンスや弾力性の利益が何も実現しなかったことを発見するのはよくあることです。誠実な監査は、主要なワークロードを一覧にし、それぞれをリホスト、リプラットフォーム、本当に再設計のいずれかとして印を付け、どれがまだ固定サイズで常時稼働の単一ゾーンの足跡で動いているかを見ることです。一部のリフトアンドシフトは正当な最初の一歩なので、問いはそれをしたかではなく、さらに進む計画とタイムラインがあるかどうかです。ワークロードごとのコストとインシデントの履歴を持ち込んでください。高価で脆いワークロードが、再設計が最も速く元を取る所だからです。移行の一年後もすべてが古いデータセンターの形をしていたなら、より高価なデータセンターを買ったのです。
可用性ゾーンやリージョン全体が失敗したとき、実際に何が起こり、それをテストしましたか。 多くのチームは、クラウドにデプロイしたから、障害ドメインを設計したことも、確かめるためにプラグを抜いたこともなく、レジリエントだと信じています。具体的には、重要なシステムごとに、いくつのゾーンにまたがり、文書化された目標復旧時間と目標復旧時点は何で、最後にゾーンを失敗させたり、リージョンの復旧をリハーサルしたりするゲームデーを実施したのはいつか。マルチゾーンは当たり前の基準であるべきなので、重要な単一ゾーンのワークロードは指摘事項で、マルチリージョンは、既定で採用されるのではなく、明示的な復旧目標に結びついた、より重くコストのかかる決定です。依存関係マップを持ち込んでください。痛い失敗は、通常、誰も障害ドメインを描いたことのない共有サービス(データベース、アイデンティティプロバイダー)だからです。テストしたことのないレジリエンスは、性質ではなく仮説です。
最大のプロバイダーへの依存について、去ることは実際にいくらかかり、避けるために払う価値のある価格ですか。 ロックインの議論は、数字ではなくイデオロギーで進みがちです。一方の陣営は可搬性を保つためにあらゆるマネージドサービスを抽象化し、もう一方は集中リスクをまったく無視します。地に足をつけてください。最も深い三つの依存を選び、それぞれを置き換える本当のエンジニアリングのコストと経過時間を見積もり、今それがあなたに節約するものと、実際に切り替える可能性と量ります。規制当局が第二の調達先を求める、データがどこに住めるかについての主権の規則のような、可搬性が解決しないリスクを重ねてください。それらは、純粋な経済性が正当化しなくても、マルチクラウドやハイブリッドを正当化しえます。目標は、一律の方針ではなく、依存ごとの意図した書面の立場です。値付けすれば、恐れられたロックインのほとんどは、それを避けるために築かれた抽象化の層より、受け入れるほうが安いと判明します。
自分たちで運用しているサービスのうち、プロバイダーが喜んで代わりに運用してくれるものはどれで、その選択はエンジニアの時間でいくらかかっていますか。クラウドのてこの全体は、パッチ、バックアップ、フェイルオーバー、スケーリングを、それが専任の仕事である誰かに渡すことですが、チームは日常的に、習慣や見当違いの誇りから、自前のデータベース、メッセージブローカー、検索クラスターを保ちます。大きな組織にとって、コストは一つのチームのトイルではなく、十数の隅で再発明された同じ区別のつかない運用で、それぞれがオンコールの当番と、ずれの源です。相反する考慮は本物です。特殊なハードウェア、ライセンスの条件、珍しいコンプライアンスの境界、マネージドの提供が満たせない性能が、範囲のより低い所に留まることを正当化しうるので、答えは一律ではなくサービスごとです。自前運用のサービスの一覧、それぞれが保守とインシデントで消費するエンジニアの時間、マネージドの代替の価格を持ち込み、毎年再び正当化される、すべての「自前で運用している」にアーキテクチャ決定記録を求めてください。企業や政府の設定では、自前運用の選択が、実際にコンプライアンスやライセンスの制約なのか、それともそれを装った惰性なのかを加えてください。監査人と予算の所有者が同じ問いを尋ねるからです。
今月、すべてのチームとサービスにいくらかかっているかを見られ、名前のある人がその数字に責任を感じていますか。 クラウドの支出は静かに膨らみます。エンジニアが数分でグローバルなデータベースをプロビジョニングできるのと同じセルフサービスが、それをピークのサイズで永遠に動かしたままにすることも許し、単一の請求書の行が警戒すべきに見えることはないからです。チームごと、サービスごとのコストの可視性がない大きな組織では、財務は何か月も遅れて問題を発見し、反応は、規律あるものを無駄なものと並べて罰する、粗い凍結です。緊張は本物です。あらゆるドルを追うことはデリバリーを遅くするので、目標は緊縮ではなく、説明責任と適正サイズ化で、コストを事後に読むレポートではなく、設計する品質特性として扱います。チームごとのコストの内訳、タグ付けされていない、あるいは帰属できない支出の割合、プロビジョニングされた容量に対する現在の使用率、コミット利用割引やスポット容量が取り残されている所を持ち込んでください。企業や政府機関では、これをFinOpsの実践と公的支出の精査に結びつけてください。タグ付けされていないリソースは、単なる無駄ではなく、起こりかけている監査の指摘だからです。
チームは今、公開データストア、暗号化されていないボリューム、禁止されたリージョンのリソースを立ち上げられ、私たちはそれを知ることさえできますか。最も高価なクラウドのインシデントは、プロバイダーの侵害ではなく設定の誤りで、責任共有モデルは、漏れるストレージのバケットやインターネットに開かれたデータベースが、完全にあなたの側の線にあることを意味します。多くのチームの規模でこれを防ぐことは、ランディングゾーンの問いです。レコードがすでに漏れた後に見つける事後のレビューではなく、禁止された設定が存在する前にブロックする、ポリシー・アズ・コードとして徹底されるガードレール。相反する圧力は開発者の自律です。あまりに厳しいガードレールはチームを影のアカウントに押しやるので、設計は、本当に危険なものを防ぎつつ、動く余地を残さなければなりません。実際に徹底されているガードレールの一覧、本物のアカウントで準拠しないリソースをプロビジョニングしてみる誠実な試み、予防が失敗したときの検出の遅れを持ち込んでください。規制された政府の文脈では、これをデータ所在地と認可の制度に結びつけてください。許可されないリージョンのリソースは、スタイルの違反ではなく、監査人が報告義務のある事象として扱う法的な違反だからです。

セクター別の視点

スタートアップ。 初日から単一のプロバイダーでクラウドネイティブに行き、意図してロックインを受け入れてください。ゼロまでスケールするサーバーレスとマネージドサービスで動かし、二人のエンジニアがプラットフォーム全体を所有できるようにします。最も乏しい資源は可搬性ではなく注意だからです。支出に厳しい上限を設け、バイラルの瞬間が障害にならないようすべてをInfrastructure as Codeで保ち、意図したロックインの決定を、一時的だというふりをするのではなく、規模になったとき見直すために書き留めます。

小規模事業者。 プラットフォームエンジニアはおらず予算も厳しいので、クラウドを運用するものではなく消費するものとして扱ってください。自分で動かすものよりSaaSと完全マネージドのサービスを好み、プロバイダーの安全な既定に頼り、マネージドデータベースにバックアップとフェイルオーバーを扱わせて誰もしなくて済むようにします。選択を、買うことに強く親指を置いた、作るか買うかとして枠づけ、忘れられたリソースが月を使い果たさないよう課金アラートを設定し、人員を配置できないサーバーを立ち上げる前に、ローコードやマネージドの選択肢に手を伸ばします。

大企業。 クラウドの物語は多くのチームにわたる移行の物語なので、アーキテクチャは実のところガバナンスの問題です。影響範囲と課金の境界としての事業単位ごとのアカウント、既定で暗号化されたガードレール、公開データストアをブロックするポリシー・アズ・コードを備えた、統治されたランディングゾーンを立ち上げ、中央のプラットフォームチームにその基盤を所有させます。事業単位ごとのショーバックを伴うFinOpsを運用し、重要な設計をウェルアーキテクテッドなレビューでゲートし、何年も動かない記録のレガシーシステムとのハイブリッド接続を管理します。

政府。 調達規則、透明性、主権があらゆる決定を形づくります。認可された、あるいは政府のクラウドのリージョンにデプロイし、責任共有の境界を監査人のために一行ずつ文書化し、ストレージと処理を国内のゾーンに固定して、許可されないリージョンのリソースをブロックするポリシー・アズ・コードを使います。必要な認可の制度を追求し、監査の証拠を慌ただしさではなくgitの履歴として保ち、自分で認証しなければならない特注のインフラより、プロバイダーが証明するコンプライアンスの姿勢を持つマネージドサービスを好みます。

事例

スタートアップ。 12人のスタートアップは、初日から単一のプロバイダーでクラウドネイティブに築き、それに罪悪感を持ちません。APIは夜間にゼロまでスケールするサーバーレス関数で動き、データは自動バックアップとマルチゾーンのフェイルオーバーを備えたマネージドPostgresにあり、バックグラウンドのジョブはマネージドキューで動きます。すべてがInfrastructure as Codeで定義され、プロバイダーが難しい部分を運用するので、二人のエンジニアがプラットフォーム全体を所有しています。バイラルの瞬間が一時間でトラフィックを50倍に押し上げたとき、オートスケーリングがそれを吸収し、請求書は実際の使用量に比例して上がり、それから再び下がります。創業者は、小さなチームで速く動く代価として、意図してロックインを受け入れ、規模になったときに見直すためにその決定を書き留めました。

大企業。 300のレガシーアプリケーションを持つ多国籍の保険会社が、「6つのR」(リホスト、リプラットフォーム、リパーチェス、リファクタ、リタイア、リテイン)に統治された数年にわたる移行を運用しています。価値の低い汎用のアプリは、期限までに二つのデータセンターを出るために素早くリホストされ、中核の契約プラットフォームはクラウドネイティブにリファクタされ、自作のツールはSaaSとして再購入され、陳腐化したシステムは退役します。中央のプラットフォームチームが、事業単位ごとのアカウント、既定で暗号化されたガードレール、公開データストアをブロックするポリシー・アズ・コードを備えたランディングゾーンを所有し、ハイブリッド接続は、何年も動かない記録のメインフレームのシステムにクラウドをつなぎます。コストは事業単位ごとのショーバックを伴うFinOpsの実践で統治され、ウェルアーキテクテッドなレビューが、各アプリケーションの本番ローンチをゲートします。

政府。 市民の給付サービスを提供する国の機関は、住民のデータを国境内に保ち、認可されたインフラで動かすことを法的に求められています。プロバイダーの政府のクラウドリージョンにデプロイし、米国のFedRAMPのような制度のもとでの認可を追求し(コンプライアンスの作業は4.6章)、責任共有の境界を監査人のために一行ずつ文書化します。データ所在地とより広い主権の懸念(10.11章)が、ストレージと処理を国内のゾーンに固定し、ポリシー・アズ・コードを通じて許可されないリージョンのリソースをブロックするアーキテクチャを駆動します。システムは、テストされたゾーン間の復旧計画を伴う三つの可用性ゾーンにまたがり、すべてをコードとしてプロビジョニングするので、監査の証拠は慌ただしさではなくgitの履歴です。

ビジネスケース: 動機、ROI、TCO

クラウドの看板の約束は、資本支出を運用支出に変えることです。何年も先の需要に先立ってサーバーを買い、低い使用率で動かす代わりに、使った分を払い、事業とともにスケールします。それは本物ですが、より深い見返りは速度と焦点です。パッチ、バックアップ、フェイルオーバーを消すマネージドサービスは、それらのエンジニアの時間を製品の仕事に返し、数か月ではなく数分でのプロビジョニングは、アイデアから本番までの時間を圧縮します。弾力性は、年に二回しか使わないピークの容量にもう払わなくて済むことを意味します。アーキテクチャが正しいとき、これらは複利で効き、コストと能力の両方でデータセンターに勝る総所有コストになります。

間違えたコストも同じく本物なので、ビジネスケースは誠実でなければなりません。再設計なしのリフトアンドシフトは、しばしば利益を何も届けずにコストを上げ、管理されない支出は、財務が警報を鳴らすまで、数十のチームにわたって静かに膨らみえます。リーダーシップには、三つのてこを軸に論拠を示してください。速度(より速いデリバリーと短いプロビジョニング)、レジリエンス(より少なく短い大きなインシデント)、選択肢の価値(データセンターのプロジェクトなしに新しい市場やリージョンに入ること)。避けられたデータセンターの更新、汎用のインフラのための削減された人員、防がれた障害の分に数字を付け、移行のコストと継続的なFinOpsとプラットフォームへの投資と比べます。最も強い論拠はめったに生のコストの節約ではありません。まだハードウェアを待っている競合より速く動く選択肢の価値です。

アンチパターンと落とし穴

リフトアンドシフトして「クラウド」と呼ぶ。 データセンターの設計を借りたインフラにリホストすることは、コストを捉え、利益は何も捉えません。
コンソールでクリックされたインフラ。 手で作られたリソースは、再現不能で、文書化されておらず、復旧も監査も不可能です。本番への手作業の変更は欠陥として扱います。
カーゴカルトのマルチクラウド。 まれなリスクをヘッジするために、同じワークロードを二つのプロバイダーにまたがって動かし、毎日、複雑さと最小公倍数の設計で払うこと。
単一ゾーンの「高可用性」。 クラウドが既定でレジリエントだと信じながら、テストされたフェイルオーバーなしに、一つのゾーンで重要なワークロードを動かすこと。
責任共有の読み違い。 プロバイダーが、実際には自分が所有するものを保護すると想定すること。何百万ものレコードを漏らす公開バケットへの典型的な道です。
後付けとしてのコスト。 支出を考えずに設計し、請求書が代わりに自分のアーキテクチャ上の決定を下したと発見すること。

成熟度モデル

レベル1、開始: クラウドの使用は場当たり的で反応的です。チームは共有アカウントでリソースをクリックして生み出し、ワークロードはリフトアンドシフトされ、ランディングゾーンもコストの可視性もなく、レジリエンスは設計されるのではなく想定されます。最初の深刻な障害や請求書のショックは驚きです。
レベル2、発展: 基本的な実践が現れますが、チームごとに異なります。一部の中核のインフラはコードとしてプロビジョニングされ、一部のワークロードはマルチゾーンで動き、いくつかのアカウントが分離されていますが、カバレッジは不均一です。サービスモデルとロックインの選択は習慣で行われ、コストは事後に見られ、ガードレールは一貫せず、マルチリージョンの復旧はテストされていません。
レベル3、標準化: ポリシー・アズ・コードのガードレールを伴う統治されたランディングゾーンが、文書化され、組織全体で徹底されています。プラットフォームチームが基盤を所有し、本番のすべてがコードとしてプロビジョニングされ、ウェルアーキテクテッドなレビューが重要な設計をゲートし、作るか買うかと障害ドメインの決定が、すべてのチームにわたって意図的で一貫して記録されます。
レベル4、管理: 資産がベースラインに対して測定され、制御されます。チームごと、サービスごとのコストが目標に対してFinOpsを通じて追跡され、目標復旧時間と目標復旧時点は主張されるのではなく検証され、ガードレールの違反と設定のドリフトは指標として表面化し、適正サイズ化は使用率のデータで駆動され、継続・中止の判断はそれぞれ、コスト、信頼性、セキュリティのダッシュボードの証拠に裏付けられます。
レベル5、オーケストレーション: クラウドアーキテクチャは、ビジネスとリスクの計画と統合され、継続的に改善されます。障害ドメインは日常的なゲームデーで実行され、適正サイズ化と価格は自動化され、主権と所在地はポリシーで徹底され、サービスモデルとロックインの立場は定期的な周期で値付けし直され、ワークロードのポートフォリオは、市場、価格、リスクの状況の変化に応じて適応的に再均衡されます。

議論のためのアイデア

主要なワークロードは、それぞれIaaSからサーバーレスまでの範囲のどこにあり、本当に必要な制御を失わずにトイルを削るために、より高く登れるものはありますか。
主要なプロバイダーが価格を大幅に上げたり、数日間のリージョン障害に見舞われたりしたら、本当の計画は何で、それは抱えているマルチクラウドやハイブリッドの複雑さを正当化しますか。
ランディングゾーンとそのガードレールを所有するのは誰で、チームは今日、準拠しないリソース(公開データストア、暗号化されていないボリューム、許可されないリージョン)を出荷できますか。
規制された、あるいは主権のあるワークロードについて、慌ただしさなしに、責任共有の境界と認可された設定を証拠として示せますか。

要点

データセンターを写真に撮るのではなく、クラウドのために設計します。弾力性、マネージドサービス、障害ドメインへの認識がここにいる理由です。
汎用の仕事にはサービスモデルの範囲をマネージドとサーバーレスへ登り、制御が本当にそのコストに見合う所でだけ、より低い制御を保ちます。
リージョンと可用性ゾーンを明示的な障害ドメインにします。基準としてのマルチゾーン、テストされた復旧目標に結びつけたマルチリージョン。
ポリシー・アズ・コードのガードレール、別々のアカウント、基盤を所有するプラットフォームチームを伴う、統治されたランディングゾーンの中で、すべてをコードとしてプロビジョニングします。
ベンダーロックインを両方向で誠実に値付けし、具体的な規制、主権、ベストオブブリードの理由が求めない限り、マルチクラウドには懐疑的であれ。
FinOpsを通じてコストを第一級の品質特性として扱い、見逃したトレードオフを捉えるためにウェルアーキテクテッドなレビューを実施します。

参考文献とさらなる読み物

Peter Mell and Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework and Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (and the “6 Rs” migration strategies)
J.R. Storment and Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, FedRAMP programme documentation and security baselines
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing