8.3 コンテナ、オーケストレーション、クラウドネイティブ

概要と動機

コンテナは、アプリケーションをその依存関係とともに、単一の、可搬で、隔離された単位にパッケージ化します。ノートパソコンでも、テスト環境でも、本番でも同じように動きます。オーケストレーションのプラットフォーム、最も目立つのはKubernetesで、マシンのフリートにわたって多数のコンテナをスケジュールし管理します。配置、スケーリング、ヘルス、ネットワーキング、回復を扱います。クラウドネイティブは、これらの基盤の上に築かれた、より広いアーキテクチャのスタイルです。疎結合で、独立にデプロイ可能で、水平にスケール可能なサービスとして設計され、動的で自己修復するインフラストラクチャを前提とするアプリケーション。

大きなチームにとって、コンテナとオーケストレーションは一つの難しい問題を解決します。多くのチームが築いた多くのサービスを、共有のインフラストラクチャ上で、確実かつ効率的に動かす必要があります。コンテナはすべてのチームに一貫したパッケージングと実行時の契約を与え、「自分のマシンでは動く」という種類の失敗を退役させます。オーケストレーションは、個々のマシンを共通の基盤の背後に隠すので、チームはサーバーではなくプラットフォームにデプロイします。この標準化が、すべてのチームがデプロイ、スケーリング、レジリエンスを再発明せずに、数百、数千のサービスを運用できるようにするものです。

企業と政府の採用者は、可搬性、レジリエンス、ロックインから離れる道を得ます。その代わりに、本物の複雑さと新しいセキュリティの責任を引き継ぎます。コンテナのプラットフォームは、プログラム可能で動的であるまさにそのために強力で、それは慎重に統治しなければならないことを意味します。イメージの出所、マルチテナンシーの隔離、ネットワークポリシー、コストのすべてが、プラットフォームレベルの関心事になります。公共部門の採用者は、ますます主権の要件を加えます。データがどこに住み、誰がアクセスできるかの制御。それは、選んだ環境にわたって一貫したワークロードを動かす能力を、単なる技術的な詳細ではなく、戦略的な能力にします。

主要原則

アプリケーションを、小さく、単一目的の、不変のコンテナイメージとしてパッケージ化します。
イメージの衛生を実践します。最小限のベースイメージ、固定されたバージョン、脆弱性のスキャン、署名。
可能な所では、アプリケーションをステートレスで水平にスケール可能になるよう設計し、状態を外部化します。
オーケストレーションのプラットフォームの望ましい状態のモデルを真実の源として扱い、自己修復させます。
テナント、ワークロード、名前空間の間の隔離と最小権限を徹底します。
twelve-factorの原則、つまり使い捨てで、設定が外部化され、水平にスケール可能なアプリを築くための方法論に従い、分散システムの現実のためにそれを拡張します。
コストを、後付けではなく、第一級で可視のエンジニアリングの関心事にします。
戦略的な柔軟性を保つために、可搬で標準ベースの抽象化を好みます。

推奨事項

厳格なイメージの衛生を実践する

コンテナイメージは、信頼とデプロイの基本単位なので、そのように扱ってください。攻撃面を縮めるために、最小限で信頼されたベースイメージから始めます。再現性のために、依存関係とベースイメージのバージョンを固定します。ビルドパイプラインで、すべてのイメージを既知の脆弱性についてスキャンし、重大な発見のあるものをブロックします。承認された未改変のイメージだけが走るよう、イメージに署名し、デプロイ時に署名を検証します。チームが構築元とする、強化されたベースイメージの選り抜きの内部レジストリを保ちます。それが良いセキュリティの既定を自動的に広げます。

Kubernetesのパターンを再発明せずに使う

Kubernetesは、確立されたパターンを採用するチームに報い、そのモデルと戦うチームを罰します。望ましい状態には宣言的なマニフェストを使います。プラットフォームが不健全なインスタンスを検知して置き換えられるよう、ヘルスプローブを加えます。スケジューラーがワークロードを安全に詰め込めるよう、リソースのリクエストと上限を設定します。弾力的な需要には水平オートスケーリングを使います。データベースの管理、証明書のローテーション、カスタムリソースの調整のような、継続的に走らなければならない運用ロジックには、状態を観察して行動するソフトウェアに人間の運用知識を符号化する、オペレーターパターンを使います。プラットフォームの上にオーダーメイドのオーケストレーションを築きたい衝動に抵抗してください。ネイティブの構成要素を好みます。

マルチテナンシーを意図して設計する

多くのチームがクラスターを共有するとき、隔離はあれば良いものではなく、セキュリティと信頼性の要件です。名前空間をテナンシーの境界として使います。どのテナントも他を飢えさせないよう、リソースクォータを徹底します。トラフィックを明示的に許可されたものに制限するため、ネットワークポリシーを適用します。各チームができることを制限するため、ロールベースのアクセス制御(RBAC)を使います。より強い隔離のニーズを持つワークロードには、別々のクラスターやより強いサンドボックスを検討します。モデルがソフトなマルチテナンシー(信頼された社内チーム)かハードなマルチテナンシー(互いに信頼しないワークロード)かを早期に決めてください。二つは非常に異なる統制を要求するからです。

クラウドネイティブを築く、twelve-factorとその先

明示的な依存関係、環境内の設定、ステートレスなプロセス、使い捨て性などを伴うtwelve-factorの方法論は、動的なプラットフォームで栄えるサービスの優れた基準線であり続けます。分散システムの追加の現実のために拡張します。部分的な失敗に備えて設計します。操作を冪等で再試行可能にします。ヘルスとテレメトリを公開します。オブザーバビリティを、追加ではなく組み込みの機能として扱います。アプリケーションのインスタンスが使い捨てで水平にスケール可能に保たれるよう、すべての状態をマネージドなデータサービスに外部化します。

マルチクラウド、ハイブリッド、ソブリンの戦略を実用的に計画する

可搬性は価値がありますが、はっきりした目で追求してください。ワークロードが必要なら動けるよう、コンテナ、Kubernetes、オープンなAPIのような可搬な抽象化に標準化します。しかし、本物の生産性を仮説上の可搬性と交換する、すべてのマネージドなサービスを拒否する罠は避けます。ハイブリッドとソブリンの要件には、同じワークロードとパイプラインが、選んだリージョン、プライベートなデータセンター、法域とデータ所在地のルールを満たすソブリンクラウドで走れるよう設計します。主権と所在地の境界を、アーキテクチャと方針で明示的にします。

FinOpsでコストを可視にする

弾力的なクラウド環境では、コストはエンジニアリングの決定の直接の結果なので、エンジニアに可視性と責任を与えます。コスト配分のためにリソースにタグを付けます。支出をチームとサービスに帰属させます。コストのデータをパフォーマンス指標と並べて示します。ワークロードを適切なサイズにし、需要に合わせるためにオートスケーリングを使い、遊んでいるリソースを取り戻します。エンジニアリング、財務、プロダクトを一緒にするFinOpsの実践を確立し、クラウドの支出が四半期ごとの驚きではなく、共有の継続的な責任になるようにします。

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

選択	長所	短所	最適な場合
Kubernetes	強力、可搬、巨大なエコシステム	急な複雑さ。運用の負担	規模での多くのサービス
マネージドなコンテナサービス	運用の負担が少ない。開始が速い	いくらかのロックイン。制御が少ない	単純さを望むチーム
単一の共有クラスター	効率的な資源の利用	隔離が難しい。影響範囲	信頼された社内のテナント
テナントごとのクラスター	強い隔離	高いコストとオーバーヘッド	信頼しない、あるいは規制対象のワークロード
マルチクラウドの可搬性	柔軟性。ロックインを避ける	最小公倍数的なサービス	戦略的なリスクの緩和
単一クラウドの深いマネージドサービス	最大の生産性	ベンダーへの依存	速度重視のチーム

包括的なトレードオフは、能力対複雑さです。Kubernetesとクラウドネイティブのアーキテクチャは、弾力性、レジリエンス、速度を届けます。しかし小さなチームが日常的に過小評価する、相当な運用上と認知上の負担を課します。同様に、完全なマルチクラウドの可搬性を追うことは、生産性を選択肢と交換します。正しい答えは規模とリスクによります。多くのチームと強いガバナンスのニーズを持つ大きな組織は、通常、投資を正当化します。より小さな取り組みは、複雑さを隠すマネージドなサービスに、しばしばよりよく仕えられます。

チームで議論すべき問い

イメージに署名し、デプロイ時に署名を検証していますか。そして重大な脆弱性は実際にビルドをブロックしますか。 イメージは信頼の単位なので、その周りのサプライチェーンは、警告ではなく固いゲートに値します。署名され検証されたイメージだけが走れるか、スキャンが重大な発見をブロックするのか単に記録するだけか、チームが構築元とする強化されたベースイメージの選り抜きのレジストリを誰が保守するかを決めてください。企業と政府のワークロードでは、これはしばしばコンプライアンスの要件で、毒された依存関係が本番に届くことへの最良の防御でもあります。現状を持ち込んでください。動いているイメージのどれだけが強化されたベースから来ているか、いくつがパッチの当たっていない重大なCVEを抱えているか、署名のないイメージが今スケジュールされうるか。重大な発見がデプロイを止めないなら、スキャナーは飾りです。
リソースのリクエスト、上限、クォータは、高価な容量を遊ばせずに、あるワークロードが隣人を飢えさせるのをどう防ぎますか。 共有のクラスターでは、上限のないワークロードが周りのすべてをクラッシュさせたりスロットルしたりしえ、あまりに寛大に設定されたクォータは、プラットフォームを正当化する利用率の利得を無駄にします。妥当な既定、誰がそれを調整するか、リクエストがまったく設定されていないワークロードをどう捉えるかを決めてください。規模では、これは信頼性の統制であり、コストの統制でもあります。適切なサイズ化こそ、FinOpsの節約の多くが住む所だからです。データを持ち込んでください。現在のクラスターの利用率、ワークロードが追い出されたりスロットルされたりする頻度、クォータのない名前空間。目標は密で安全な詰め込みなので、欠けた上限を、プラットフォームが拒否する欠陥として扱います。
コンテナの内側に住んでよい状態は何で、それ以外はすべてどこへ行きますか。 クラウドネイティブのレジリエンスは、プラットフォームが自由に再スケジュールできる使い捨てのインスタンスに依存し、それは、重要な状態がコンテナのローカルディスクではなくマネージドなデータサービスに住む場合にだけ成り立ちます。ルールを明示的に決めてください。コンテナに偶然保存された状態は、次の再スケジュールでデータ損失になるからです。古いアプリケーションを移行するチームにとって、これはしばしば最も難しい部分です。レガシーのサービスは安定したローカルのファイルシステムを想定するからです。目録を持ち込んでください。どのサービスがローカルの状態を書き、どれがスティッキーセッションやノードアフィニティに頼り、それぞれを外部化するには何が必要か。状態が外部になるまでは、弾力的に見えるが実際には動かせないコンテナを持っています。
多くのチームがクラスターを共有するとき、隔離のモデルはソフトかハードのマルチテナンシーとして意図して選ばれ、統制はその選択に合っていますか。名前空間は信頼された社内チームを分けますが、積極的に敵対的あるいは侵害されたワークロードを封じ込めず、ソフトなテナンシーをハードのように扱うことは、起こるのを待っているセキュリティインシデントです。ワークロードごとに、テナントが単に公平な共有を必要とするのか、互いを信頼しないと想定しなければならないのかを決め、それから統制を合わせてください。ソフトの場合は名前空間、クォータ、ネットワークポリシー、RBAC、ハードの場合は別々のクラスターやより強いサンドボックス。大きな組織にとって、この決定はコストを直接駆動します。テナントごとのクラスターは共有の名前空間よりはるかに高価なので、脅威モデルが求める所でだけ隔離の予算を使いたいからです。テナントの目録を持ち込んでください。今日どのワークロードがクラスターを共有し、どれが規制対象あるいは外部向けのトラフィックを扱い、ネットワークポリシーがまだ既定で許可になっているのはどこか。企業と政府の設定では、信頼しないワークロードをソフトなテナンシーのもとで混ぜることは、まさに監査人が指摘する発見なので、彼らが指摘する前に境界を名指ししてください。
マルチクラウドの可搬性にいくら払っていて、実際にそれを使うことはありますか。 コンテナ、Kubernetes、オープンなAPIへの標準化はワークロードを動かせる状態に保ちますが、その選択肢を保つためにすべてのマネージドなサービスを拒否することは、組織が決して行使しないかもしれない可搬性のために、本物の日々の生産性を交換します。可搬性が本物の要件である所、たとえば署名した主権や出口の義務と、すべてのチームを遅くする心の拠り所である所を決めてください。相反する考慮は速度です。深いマネージドなサービスは機能をより速く出荷し、最小公倍数的なアーキテクチャは、すべてのチームへの常設の税です。証拠を持ち込んでください。どのマネージドなサービスを避け、それがエンジニアリングの時間でいくらかかったか、プロバイダー間でワークロードを移したことがあるか、契約が実際に何を義務づけているか。政府と規制対象の採用者にとって、データ所在地とソブリンクラウドのルールは可搬性を交渉の余地のないものにしえます。同じマニフェストとパイプラインがソブリンのリージョンとプライベートな飛び地で走るよう設計しますが、これは無料の保険ではなくコンプライアンスのコストだと誠実に認めてください。
各チームは自分が使うものを見られ、請求書が驚きになる前に誰かがそれを所有していますか。 弾力的なプラットフォームでは、コストはエンジニアリングの決定の直接の出力ですが、コスト配分のタグと可視のダッシュボードがなければ、支出は、財務がエスカレートするまで誰も責任を感じない共有のプールに積み上がります。コストをチームとサービスにどう帰属させるか、誰がレビューするか、エンジニアがコストをパフォーマンス指標の隣で見るのか、四半期に一度聞くだけなのかを決めてください。緊張は、説明責任と摩擦の間にあります。コストを強く押しすぎるとすべての決定が予算の交渉になり、無視すると、遊んでいる過大なワークロードが静かに複合します。数字を持ち込んでください。チームごとの現在の支出、どれだけの容量が遊んでいるか過大か、暴走するワークロードがどれだけ速く気づかれるか。企業と政府の予算では、帰属されないクラウドの支出は、ガバナンスの失敗であり、本物の財務リスクでもあるので、事後に突き合わせるのではなく、エンジニアリング、財務、プロダクトを同じ会話に入れるFinOpsの実践を立ち上げてください。

セクター別の視点

スタートアップ。 自前のKubernetesクラスターではなく、マネージドなコンテナサービスに手を伸ばしてください。二つのサービスとプラットフォームエンジニアがいないなら、コントロールプレーンは、余裕のない気を散らすものです。最小限のベースから小さなイメージをパッケージ化し、バージョンを固定し、ビルドに一つの脆弱性スキャンを加え、インスタンスが使い捨てに保たれるよう、すべての状態をマネージドなデータベースに押し込みます。実際に正当化するだけのサービスと人員ができるまで、名前空間、オペレーター、マルチクラウドの可搬性は飛ばします。

小規模事業者。 専任のプラットフォームの専門家がおらず予算も厳しいので、マネージドなサービスに強く頼り、そうでなければ人員を置かなければならないオーケストレーションをプロバイダーに動かしてもらってください。コンテナの基本を、セキュリティの床として扱います。最小限のイメージ、バージョンの固定、パイプラインでのスキャンが、わずかな労力で保護の大半を与えます。築くより、サポートされたプラットフォームを買うことを好み、価格や条件が変わっても閉じ込められないよう、標準のコンテナとオープンなAPIという、十分な可搬性を保ちます。

大企業。 仕事は、多くのチームにわたるプラットフォームのガバナンスです。強化されたベースイメージ、署名とスキャンのゲート、クォータ、ネットワークポリシー、RBACを伴う名前空間のテナンシー、コスト配分のタグとFinOpsのダッシュボードを供給する中央のプラットフォームチーム。数百のサービスが同じように運用されるよう、デプロイの契約を標準化し、チームがデプロイをセルフサービスしながら、セキュリティ、マルチテナンシー、コストを中央で管理します。プラットフォームチームに適切に資金を出してください。資源の足りないプラットフォームは、組織全体が待つボトルネックになるからです。

政府。 主権、データ所在地、公的な説明責任がアーキテクチャを形づくります。同じパイプラインがソブリンのリージョンと認定されたオンプレミスの飛び地で走るよう、標準のコンテナとKubernetesでワークロードを動かし、所在地とアクセスの境界を慣習ではなく方針として符号化します。内部の強化されたレジストリからイメージを引き、最も機微なデータにはハードなマルチテナンシーを適用し、レジリエンスと交渉力を与える可搬性を保ちます。調達規則はしばしば単一ベンダーへのロックインを禁じるからです。

事例

スタートアップ。 6人のスタートアップは、二つのサービスを最小限のベースから作った小さなコンテナイメージとしてパッケージ化し、自前のKubernetesクラスターではなくマネージドなコンテナサービスで動かすので、誰もコントロールプレーンの世話をする必要がありません。ベースイメージのバージョンを固定してビルドに脆弱性スキャンを加えますが、実際に少数以上のサービスを持つまで、より重いオーケストレーションの機能は意図して飛ばします。状態はマネージドなPostgresのデータベースに住み、コンテナを使い捨てに保ち、プラットフォームがデータ損失なしにそれらを再起動あるいはスケールできるようにします。

大企業。 通信会社は、共有のKubernetesクラスター上で数百のマイクロサービスを動かします。プラットフォームチームが強化されたベースイメージを提供し、イメージの署名と脆弱性のゲートを徹底し、クォータ、ネットワークポリシー、RBACを伴う名前空間に事業部門を隔離します。コスト配分のタグとFinOpsのダッシュボードが各プロダクトラインに支出を帰属させ、オートスケーリングが需要に合わせて容量を適切なサイズにします。プロダクトチームは、サーバーを管理せずに、一貫したプラットフォームに一日に数十回デプロイします。会社はセキュリティとコストの中央の制御を保ちます。

政府。 国の医療サービスは、市民のデータを国境内に、国の法的な制御のもとに保たなければなりません。標準のコンテナとKubernetesを使ってソブリンクラウドのリージョンでワークロードを動かすので、最も機微なデータのために、同じパイプラインとマニフェストが、オンプレミスの認定された環境でも走ります。データ所在地とアクセスの境界は方針として符号化され、イメージは内部の強化されたレジストリから引かれ、ハードなマルチテナンシーが機微なワークロードを隔離します。ソブリンのリージョンとプライベートな飛び地にわたる可搬性は、コンプライアンスを犠牲にせずに、サービスにレジリエンスと交渉力を与えます。

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

コンテナとオーケストレーションのROIは、より高い資源の利用率、より速く信頼できるデプロイ、支出を需要に合わせる弾力的なスケーリング、自己修復による改善されたレジリエンスから来ます。共通のプラットフォームへの標準化は、チーム間の重複した労力を減らし、オンボーディングを速めます。すべてのサービスが同じデプロイと運用の契約に従うからです。

TCOの分析は、運用の負担について誠実でなければなりません。採用のコストには、プラットフォームエンジニアリングの人員、訓練、イメージとクラスターのセキュリティツール、プラットフォーム自体を動かす継続的な労力が含まれます。採用しないコストには、チーム間の一貫しないオーダーメイドのデプロイ、高価なインフラストラクチャの貧しい利用率、脆い手作業のスケーリング、レジリエンスと主権の要件を満たす難しさが含まれます。リーダーシップには、論拠は規模にかかっています。あるサービスの数を下回ると、複雑さは元を取らないかもしれず、マネージドなサービスのほうが賢明です。しかし企業と政府の規模では、統治されたクラウドネイティブのプラットフォームは、通常、最も費用対効果が高く強靭な基盤で、プラットフォームチームにそれを適切に動かす資金を出すことが条件です。

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

太って、スキャンされていないイメージ。 信頼されていないベースから築かれた肥大したイメージは、不要な脆弱性を抱え、すべてを遅くすること。
何にでもKubernetes。 少数の単純なサービスに複雑なオーケストレーターを採用することは、見返りなしに複雑さを買うこと。
リソースの上限の無視。 リクエストと上限なしには、一つのワークロードが隣人を飢えさせたりクラッシュさせたりしうること。
敵対的なワークロードへのソフトなテナンシー。 信頼しないテナントを隔離するのに名前空間だけに頼ることは、起こるのを待っているセキュリティインシデント。
偶然のステートフルなコンテナ。 使い捨てのコンテナに重要な状態を保存すると、再スケジュールでデータ損失につながること。
コストへの盲目。 クラウドの支出を、エンジニアリングの出力ではなく固定の間接費として扱うと、暴走する請求書につながること。
可搬性の劇場。 組織が実際に使うことのない可搬性を守るために、すべてのマネージドなサービスを拒否すること。

成熟度モデル

レベル1: 開始。 コンテナは、使われるとしてもその場しのぎです。イメージは手で作られスキャンされず、デプロイは手作業で反応的で、共有のプラットフォーム、コストの可視性、隔離のモデルはありません。

レベル2: 発展。 チームがアプリケーションをコンテナ化してオーケストレーターを採用しますが、実践はグループ間で異なります。イメージのスキャン、リソースの上限、署名は一貫せず、コストとマルチテナンシーは体系的に統治されていません。

レベル3: 標準化。 標準化されたプラットフォームが、組織全体で文書化され徹底されます。強化されたベースイメージ、署名とスキャンのゲート、クォータとネットワークポリシーを伴う名前空間ベースのテナンシー、RBAC、コスト配分。クラウドネイティブとtwelve-factorのパターンは、局所的な選択ではなく、期待される規範です。

レベル4: 管理。 プラットフォームが、ベースラインに対して測定され、制御されます。クラスターの利用率、強化されたベースから築かれた動いているイメージの割合、パッチの当たっていない重大な脆弱性、デプロイの頻度と変更失敗率、追い出しとスロットルの率、予算に対するチームとサービスごとのコストを追跡します。ゲートはこの証拠に基づいて徹底されます。欠けたリソースの上限と署名のないイメージは自動的に拒否され、標準からのずれは警告ではなく行動を引き起こします。

レベル5: オーケストレーション。 プラットフォームはセルフサービスで自己修復し、組織全体に統合され、適応的です。FinOpsは容量を継続的に適切なサイズにして取り戻し、可搬なアーキテクチャがハイブリッドとソブリンの要件をサポートし、プラットフォームは測定された使用から継続的に改善し、ワークロード、コスト、リスクの状況が移るにつれて、構成要素を退役させ置き換えます。

議論のためのアイデア

どの規模で、Kubernetesの採用は複雑さのための複雑さをやめて、元を取り始めますか。
あなたのワークロードにとって、ソフトとハードのマルチテナンシーの正しい境界はどこにありますか。
マルチクラウドの可搬性への投資と、深いマネージドなサービスの生産性を、どうバランスさせますか。
すべての決定を予算の交渉にせずに、エンジニアに本物のコストの説明責任をどう与えますか。
ベースイメージのガバナンスのモデルは何で、強化されたレジストリを誰が保守しますか。
主権とデータ所在地の要件は、プラットフォームのアーキテクチャをどう形づくりますか。

要点

コンテナはパッケージングと実行時を標準化し、オーケストレーションは規模での運用を標準化します。
イメージの衛生、つまり最小限で、固定され、スキャンされ、署名されたイメージは、基礎的なセキュリティです。
オーダーメイドのオーケストレーションを築くより、ネイティブのKubernetesのパターンとオペレーターを使います。
ワークロードが互いをどれだけ信頼するかに基づいて、マルチテナンシーのモデルを意図して選びます。
twelve-factorに従い、部分的な失敗とオブザーバビリティのような分散システムの現実のために拡張します。
コストをエンジニアリングの出力として扱い、FinOpsを通じて継続的に管理します。

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

Adam Wiggins, The Twelve-Factor App (methodology).
Brendan Burns, Joe Beda, and Kelsey Hightower, Kubernetes Up & Running.
Bilgin Ibryam and Roland Huß, Kubernetes Patterns.
Cornelia Davis, Cloud Native Patterns.
J.R. Storment and Mike Fuller, Cloud FinOps.
Liz Rice, Container Security.
Cloud Native Computing Foundation (CNCF), cloud-native definition and landscape.