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

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

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

DevOps Research and Assessment(DORA)2019 年の State of DevOps Report では、クラウド テクノロジーを採用していると主張するユーザーのうち、ここに定義した 5 つの重要な特性すべてが満たされているかどうかについて、そう思う、または強くそう思うと回答したのは 29% にすぎませんでした。DORA の 2018 年と 2019 年の調査によると、パフォーマンスの高いユーザーは、パフォーマンスの低いユーザーと比較して、クラウドの 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 つの特性を満たす際の最大の課題は次のとおりです。

  • 実装するために相互に連動する必要がある組織の機能間の調整と連携が不十分。
  • 技術、プロセス、組織の変革への投資が不十分。

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

クラウドへの移行には何年もかかります。他のあらゆる大規模な変更と同様に、小さな作業から開始し、何が機能して何が機能しないかを判断するために迅速にテストすることが重要です。また、学習内容や効果的なパターンや手法を継続的かつ統制的に組織全体にスケールアウトすることも重要です。

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

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

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

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

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

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

また、NIST の重要な特性を適切に実装しているかどうかを直接測定することもできます。このドキュメントの冒頭に列挙した特性が示すものをどの程度実感しているかをチームに尋ねてください。「そう思う」または「強くそう思う」と回答するチームは良い成果を上げている一方、「どちらでもない」または「そう思わない」と回答するチームは、成果を上げるために障害を取り除くサポートを必要としています。そして、クラウドを使用しているチームのうち、実際に NIST の条件を満たしているチームの数はいくつかを考慮します。

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

次のステップ