DevOps 技術: クラウド インフラストラクチャ

多くの組織がクラウド コンピューティングを採用しています。クラウドは、クラウド プロバイダからインフラストラクチャを購入するだけではありません。米国立標準技術研究所(NIST)は、クラウド コンピューティングの 5 つの基本的な特徴を定義しています。

  • オンデマンド セルフサービス: プロバイダの人手を介さず、ユーザーは必要に応じてコンピューティング リソースをプロビジョニングできます。
  • 広範なネットワーク アクセス: 機能には、スマートフォン、タブレット、ノートパソコン、ワークステーションなどのさまざまなプラットフォームからアクセスできます。
  • リソースプール: プロバイダ リソースは、マルチテナント モデルでプールされています。物理リソースや仮想リソースは、オンデマンドで動的に割り当てられます。ユーザーは、国、州、データセンターなどの高い抽象化レベルでロケーションを指定できます。
  • 迅速な拡張性: 機能を柔軟にプロビジョニング、リリースして、必要に応じて迅速にスケールアウトまたはスケールアウトできます。無制限とされるため、いつでも任意の量で適切に対応できます。
  • 測定サービス: クラウド システムは、ストレージ、処理、帯域幅、アクティブ ユーザー アカウントなど、サービスの種類に基づいてリソースの使用を自動的に管理、最適化、報告します。

DevOps Research and Assessment(DORA)2019 年 State of DevOps レポートでは、クラウド テクノロジーを採用したと主張する人の 29% のみが、上記で定義された 5 つの特徴すべてを満たしていることに同意または強く同意していることがわかりました。2018 年と 2019 年の両方で、DORA の調査によると、パフォーマンスの高い人は、パフォーマンスの低い人よりも、この 5 つの重要なクラウドの特徴すべてを満たしている可能性が 23 倍以上高くなっています。そのため、クラウド コンピューティング テクノロジーを採用したと主張するチームや経営幹部は、期待した成果が得られなかったことに不満を感じています。

DORA の調査によると、多くの組織では、従来のデータセンター実務とプロセスを使用してクラウド インフラストラクチャを管理するため、次のようなメリットが得られません。

  • ソフトウェア配信のパフォーマンスの向上: スループットの向上とより高いレベルの安定性
  • サービスの可用性の向上
  • コストの可視性の向上: 2019 年には、クラウドの基本特性がすべて満たされた回答者がソフトウェアの運用コストを正確に推定できる可能性が 2.6 倍であることがわかりました。また、最も運用コストの高いアプリケーションを簡単に特定できる可能性は2倍になります。

たとえば、クラウド インフラストラクチャを使用する多くの組織では、開発者が必要に応じて環境にセルフサービスすることを許可していません。チケットを出すか、電子メールを送信し、環境がプロビジョニングされるまで、または構成の変更が行われるまで数日待つ必要があります。この場合、組織はクラウド サービスに対して支払いを行うかもしれませんが、それは NIST の定義に基づくクラウドではありません。

クラウドに移行する場合、組織では、従来のデータセンターで実装したプロセスや手法を再設計することにリソースを使う必要があります。クラウド ネイティブのパターンと手法の採用により、クラウド コンピューティングのアジリティ、安定性、可用性、コスト透明性を実現する必要があります。基盤となるテクノロジーがクラウドに存在しても、実務担当者の成果が変わらない(テスト環境の取得、新しいインフラストラクチャのプロビジョニング、構成の変更などに数日から数週間かかる)場合、その組織は望む実績を得られません。

クラウド インフラストラクチャの実装方法

NIST の 5 つの特性を実装するためのクラウド ネイティブ プロセスとプラクティスの実現には、デベロッパー、運用チーム、情報セキュリティ、調達、財務などのいくつかの IT チームにおける大きな変革が含まれます。この変革において、矛盾する目的を特定し解決するために、チーム間の緊密な連携が必要になります。

たとえば、多くのデベロッパーは、クラウド プラットフォームを使用するとき本番環境インフラストラクチャを完全に管理できることを期待します。情報セキュリティの専門家はこのプラクティスに反対しますが、これには正当な理由があります。規律のある変更管理なしでは、クラウド インフラストラクチャは、管理が難しく、外部の脅威に対して脆弱で、規制要件を満たさない、もろいシステムに変わる可能性があるからです。

ただし、これらの要件を満たしながら、デベロッパーが必要なリソースをプロビジョニングすることは可能です。多くの組織では、Infrastructure as Code のパラダイムを採用しています。(GitOps は一例です。)自動化されたメカニズムで、インフラストラクチャ構成はバージョン管理でチェックされ、デベロッパーは環境のプロビジョニング、構成の変更、デプロイを実行できます。このメカニズムでは、バージョン管理からコードを取得し、人手を介さずに、必要に応じてクラウドの API でオペレーションを実行します。バージョン管理と自動化により、すべてのアクションとその出力がログに記録され、各環境の変更ごとに完全なトレースと監査が可能になります。

Infrastructure as Code を使用すると、変更を効果的に管理し、情報セキュリティ管理を適用できます。たとえば、(Google で行われているように)バージョン管理で指定された構成に対する変更はすべて、指定されたグループの誰かが承認を行うようにすることで、職務分掌を実装できます。ただし、Infrastructure as Code に移行するには、情報セキュリティ管理を実装するためのポリシーの変更など、多大な技術的努力とプロセスの変更が必要になります。

別の例を考えてみましょう。通常、クラウド プロバイダは、使用中のインフラストラクチャのみに対して課金します(NIST の 5 番目の特性である、「測定されたサービス」を満たすものです)。固定費用のインフラストラクチャから変動費用への変化は、調達と財務の両面に大きく影響する可能性があります。2019 年の State of DevOps Report では次のように説明されています。

「財務面では、クラウドが短期的にはコスト削減につながらないと述べられていますが、情報の透明性が高いことは認識されています。これはどういうことでしょうか。クラウドはシステム オーナーにコストの透明性を提供しますが、チャージバック モデルなどのメカニズムがない限り、ユーザーはこれらのコストを支払いません。このことにより、確認されずに大きく変動するコストが発生し、クラウドのコストの予測が難しくなる可能性があります。これらのシナリオでは、インフラストラクチャの費用を負担するチームは、低い可視化性がシステムユーザーによる効率的なシステムの構築を妨げるとしても、予測可能なデータセンターを好む可能性があります。システムオーナーがより効率的なシステムを構築するための可視性とそのためのインセンティブの両方を持つように、チャージバックまたは同様のメカニズムを使用して、インセンティブをより適切に調整することを組織にお勧めします。」

構成レベルと財務レベルの両方でインフラストラクチャがどのように管理されているかを考慮するだけでなく、アプリケーションを再設計し、クラウドの安定性、信頼性、俊敏性というメリットを実現する必要があります。システムをクラウド ネイティブのパラダイムに再設計する方法については、Google Cloud ホワイト ペーパーの「クラウド ネイティブへの再構築: デベロッパーの生産性を大幅に向上させる革新的なアプローチ」をご覧ください。

最も重要な考慮事項は、クラウド デプロイが実際に迅速で、信頼性の高いリリース、およびより高いレベルの可用性、速度と信頼性を実現できているか、という点です。

クラウド インフラストラクチャを実装する際のよくある問題

NIST によって定義された 5 つの特性を満たす際の最大の障害は次のとおりです。

  • 実装するには連携する必要がある組織内チームの調整とコラボレーションが不十分。
  • 技術、プロセス、組織の変革への投資が不十分。

多くの組織は、アプリケーションをクラウドに移行するためのリフト&シフト方式から始まります。これには、アプリケーションとクラウド インフラストラクチャを管理するためのプロセスの最小限の変更が必要になり、比較的迅速に行うことができます。しかし、メリットも同様に最小限です。リフト&シフトから、新しいソフトウェアのクラウド ネイティブのパラダイムや、進化し続ける既存の戦略的システムに移行する計画は重要です。

クラウドへの移行は複数年にわたるプロセスです。あらゆる大規模な変更と同様に、小規模なテストをすばやく開始して、何が効果的で何が効果的でないのかを把握し、組織全体で統制のとれた学習のスケールアウトと有効なパターンや実践を維持することが重要です。

その過程では、次のようなさまざまな課題があります。

  • プロセス、アーキテクチャ、ガバナンスを再設計し、クラウド ネイティブな方法で規制要件を満たす
  • 環境間の論理的な分離を保証し、チャージバックを有効にし、クラウドの拡散や孤立したインフラストラクチャを防止しながら、チームがデプロイと構成の変更をセルフサービスできるマルチテナントインフラストラクチャアーキテクチャの設計
  • クラウド インフラストラクチャ プラットフォームのプロダクト開発体制を構築する
  • 資本投資ではなく、従量制のサービスとしてインフラストラクチャへの調達の移行をサポートする
  • デベロッパーがクラウド ネイティブ アプリケーションの構築方法を理解するのをサポートする
  • オペレーションを最新のサイト信頼性エンジニアリング(SRE)に移行する。たとえば、Infrastructure-as-Code を手動のチケットベースの構成管理の代わりにデプロイするなど
  • クラウド ネイティブ システムと非クラウドベース システム(メインフレームおよびパッケージ ソフトウェア/COTS を含む)の統合の計画と実行

こうした課題を乗り越えるには、組織のあらゆるレベルで持続的な投資とコラボレーションを推進する大きな変革プログラムが必要です。

クラウド インフラストラクチャの測定方法

測定対象を決めるには、まずクラウド インフラストラクチャを導入することで得られるメリットを考えます。その後、そのメリットが実現する範囲を測定します。

たとえば、費用の可視性を高めることが目標である場合、インフラストラクチャにかかる費用について、関連する業務分野、チーム、プロダクト、環境に応じて適切に請求されているかを追跡できます。

また、NISTの重要な特性を適切に実装しているかどうかを直接測定することもできます。このドキュメントの上部に記載されている特性の記述にどの程度同意しているかをチームに尋ねてください。「そう思う」または「そう思う」と回答しているチームは高い成果を上げている一方、「どちらでもない」または「そう思わない」と回答するチームが、成果を果たす際の障害を解消する支援とサポートを必要としています。そして、クラウドを使用していると主張するチームで、実際に NIST の条件を満たしているチームの数を考慮します。

重要な特性のいくつかは、プロセスを測定することで直接得ることもできます。たとえば、インフラストラクチャの変更を管理するプロセスがある場合、変更を加える始めから終わりまでの時間を測定できます。また、組織におけるクラウド ネイティブ テクノロジーの普及状況も確認できます。たとえば、手動プロビジョニングではなく、Kubernetes または自動スケーリング グループを使用して管理するクラスタまたはマシンの割合、あるいはホストの有効期間などです。一般的に、データセンターでは、稼働時間が長いほど、信頼度が高いことを意味します。クラウド ネイティブ パラダイムでは、既存のホストを変更するのではなく、新しい構成で新しい仮想ホストを起動することで構成変更を行うことがよくあります。この手法は、エフェメラル インフラストラクチャと呼ばれており、この場合、長い稼働時間は、パッチが適用されていないマシンを意味します。

次のステップ