BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル 開発者のベロシティを実現するためにDevOpsガバナンスが重要な理由

開発者のベロシティを実現するためにDevOpsガバナンスが重要な理由

キーポイント

  • アプリケーション環境の複雑さと、コスト管理、計画、コンプライアンスを維持する必要性は、管理を誤ると、開発者が迅速にイノベーションを起こす上で大きな障害となる。

  • DevOpsチームは、多数の環境と急速に進化するアプリケーションアーキテクチャにより、大規模な組織では特に変更管理の負担が大きく、DevOpsと開発者の間に摩擦が生じる。

  • 異種インフラストラクチャからアプリケーションが形成される可能性のある、現実的なシナリオとして考えられる正確なツールは、コスト分析の要素を提供すべきである。

  • TerraformやHelmのようなIaCのスーパーセットであるアプリケーション環境、構成スクリプト、パラメータ、キー、シーケンス、オペレーションは、DevOpsチームによって一元管理されるべきである。これにより、修正と変更をより適切に追跡できるようになり、開発者チームに迅速かつ透過的に伝わるようになる。

  • 変更管理、コスト管理、コンプライアンスは、アプリケーション環境があらゆる製品組織のイノベーションを加速するために不可欠であるにもかかわらず、非常に複雑であるという事実を浮き彫りにしている。

  • 最新のソフトウェア組織を運営するために必要なコラボレーション、ガバナンス、コスト管理を提供するには、インフラストラクチャにアクセスしてIaCプラットフォーム(Helm、Terraformなど)を活用するだけでは不十分であることが明らかになりつつある。開発環境から本番環境まで、インフラ管理は、開発環境から本番稼働まで、アプリケーション環境のライフサイクル全体を通してこれらのニーズをサポートすることが重要である。

原文リンク(Why_ev-Op)

製品イノベーションが、どのような組織の市場においても、ビジネスの成功を実現する重要な要素であることは、もはやよく知られている。高度に差別化され、機能的、高性能、そして楽しいエクスペリエンスに対するユーザーの期待は、かつてないほど高まっている。COVIDは速度と、複数のチャネルを通じてインターネット経由でサービスを提供することに重点を移行する企業の数を悪化させている。

しかし、組織によっては、速度と技術革新は、コスト管理、計画、コンプライアンスとは正反対である。現在、高速な運用を妨げるあらゆる潜在的な障害が、標準化と自動化となっている。そのような例の1つが、テストの実施方法と実施者の変革である。すべてのアプリケーションのテストを担当する中央集権的なチームから、開発チームにテスト担当のソフトウェア開発/設計エンジニア(SDET)を必要とするチームへの大規模なシフトがある。このシフトには、ツールとプロセスの更新が伴う。同様に、アプリケーションインフラストラクチャのトピック(開発/テスト段階での環境の可用性に関連するため)は、長い間待ち望まれていたオーバーホールの最適な候補である。

開発者が環境の定義を自分の責務の一部と考えることはほとんどなく、スキルもその気もないため、中心となるDevOpsチームがアプリケーション環境を定義するのが一般的だ。これらの責任は、インフラの割り当て、オーケストレーション、コンフィギュレーション、そして管理で構成される。この文脈で使われる一般的なテクノロジには、Terraform、Helmチャート、Ansibleスクリプトなどがある。シナリオの例として、開発者がコードを機能ブランチにコミットし、不具合が発生していないことを確認するために簡単なスモークテストを実行したいときに、アプリケーション環境が使用されることがある。ビルドサーバはコードをビルドし、新しく作成された環境にアプリケーションをデプロイする。この環境定義は、DevOpsチームによってこれらのアセットを通じて作成され、DevOpsチームまたは開発チームによってビルドサーバーに設定される。

どこで歯車が狂うか

他の多くのケースと同様に、複数の開発チームと集中管理されたDevOpsチームとのコラボレーションは、摩擦を引き起こす可能性がある。例えば、アプリケーションの要件や開発者のニーズの変化により、環境が定期的に変更されることがある。組織が複数のアプリケーションと多くのチームを抱えている場合、すでに開発者のブロックを効率的に解除するのに苦労しているDevOpsチームに負担がかかる可能性がある。開発者は現実的である。彼らは腕まくりをし、時には異なるコンフィギュレーションやコンポーネントを使用して、微調整や再設定を行い、コンフィギュレーションファイルの海に行き着く。これは、文化的、財政的、そしてコンプライアンスを含む複数の領域における課題につながる。

混乱を維持する:小さな(環境の)変更が大きな遅れにつながる可能性

多くの組織では、CIで使用されるアプリケーション環境は、早い段階でリードアーキテクトやDevOpsエンジニアによって設計されてきた。製品やチームの規模に伴い、これらの資産の多くのバリエーションがチーム内でローカルに作成されてきた。このアプローチは、変更が必要ないときにはうまく機能する。しかし、変更が必要になった日、特にそれが複数のチームやインフラ構成資産に影響を与える場合、これは開発者にとっての障害になる可能性がある。

例えば、この単純なTerraformの定義を見てみよう:


 provider "aws" {
 profile = "default" 
 region = "us-west-2"
}

resource "aws_instance" "app_server" {
 ami = "ami-830c94e3" 
 instance_type = "t2.micro"
 tags = {
 Name = "ExampleAppServerInstance"
 }
}

DevOpsチームがマシンをより強力なものに変更するよう求められている、もしくはタグ付けの変更が必要だとしよう。各チームが使っているTerraformファイルの海の中で、誰がそのレポジトリを知っていて、どのように書かれ、どのように調整されたかを調査するのは非常に負担が大きい。10チームのためにこれを行うのは途方もない仕事であり、2週間以上かかることもある。

その間に開発者はどうしているかと言うと、将来的に問題が発生する可能性があることを知りながらも、Terraformをハッキングして、コーディングを続けられるようにしている。

アプリケーション記述子を統合することで、モジュール化とテスト済みで実績のある要素の再利用による効率化が可能になる。こうすることで、DevOpsチームはスケーラブルで再現可能な方法で、開発チームのニーズに素早く対応することができる。

潜在的なアンチパターンには次のようなものがある:

開発者がアプリケーション環境の変更ニーズを、チケット発行システム経由で垣根を超えてDevOpsチームに投げかけてしまい、関係が悪化する。リーダーは、このシナリオを事前に検知する安全措置を講じ、適切な対応を検討すべきである。インフラストラクチャコントロールプレーンは、多くの場合、基礎となるIaCファイルを発見して取り込み、環境間のコードドリフトを検出する機能を提供できる。このプロセスを自動化することで、開発者とDevOpsチームの間の摩擦の多くを軽減することができる。

開発者は自分たちの手で物事を進めようとするため、ローカルのIaCファイルの変更回数が増え、それに伴ってコントロールが効かなくなる。ミスが起こり、物事が機能しなくなり、非難の声が上がる。上記と同様に、DevOpsチームは、開発者がアプリケーション開発に集中し、環境管理から解放されるよう、適切なツールを使用できるようにする必要がある。

コストを抑制する

最近では、企業が提供するサービスの一部として、大量のデータに依存する何らかの人工知能を持つことが一般的だ。つまり、開発者がコードを作成または修正し、それをテストしようとすると、かなり堅牢な環境が必要になり、かなりのコストがかかる可能性がある。さらに、多くの開発者が継続的に並行して作業する場合は、非常に高くつく可能性がある。クラウドのコスト管理は、異種環境の利用によってさらに複雑になる可能性がある。

効果的なツールは、様々な複雑で現実的なシナリオを管理できるものでなければならない。例えば、オンプレミスのインフラストラクチャコンポーネントとクラウドを組み合わせたハイブリッドインフラストラクチャでホストされるアプリケーションを想像してほしい。コスト計算ツールは、複数のユーザー、チーム、環境を扱いながら、設計と運用の両方をカバーするコスト分析の要素を提供できなければならない。

キーポイント:タグ付けとコストは、最初からプロセスと環境に組み込む必要がある。それに基づいて、環境を立ち上げて評価する際だけでなく、より広く支出効率を検討するためのツールとして、適切なレポートを提供する必要がある。典型的なシングル・クラウド・ベンダーでは、それを提供するツールがある。ヘテロジニアスなインフラストラクチャのセットアップでは、それは少し難しいかもしれない。

気をつけるべき潜在的なアンチパターン

チームは、環境設計と環境の利用(例えば、1日の終わりには環境を撤収する)に関して、より規律を持って取り組んでいる。多くの行動の変化と同じように、この変化も不自然で、維持するのが難しい。時間が経てば、長続きはしないだろう。さらに、これらの環境のスピンアップとティアダウンを手動で行わなければならない場合、時間の経過とともに環境の構成がドリフトする可能性がある。

DevOpsの担当者に「コスト担当」を割り当てるのは、非現実的なアプローチになりかねない。適切なタグ付けツールがない場合、この担当者は各チームを渡り歩き、ある時点でタグをインストールして保守し、その後も保守し続けるよう依頼しなければならない。レポーティングのインフラストラクチャを構築し、レポートを提供しなければならない。特に、(多忙な)開発者チームの数が増え、異種インフラストラクチャをベースとするアプリケーションが急速に進化している現状では、これは大変な仕事である。

コンプライアンスは開発者のスピードと相反するものなのだろうか?

コンプライアンスというトピックは、一般的な開発者にはなじみがなく、その話題が持ち上がったとしても、通常は温かく歓迎されることはない。確かに、コンプライアンスによって速度が向上したり、エンドユーザーの生活を楽にするものではないが、市場によっては(例えば金融サービスやヘルスケア)、コンプライアンスが必須であったり、差別化要因であったりする。ソフトウェアの作成とイノベーションを加速させる結果、コンプライアンスが維持されなくなることを懸念する組織もあるだろう。

通常、(少なくともインフラとアクセスに関しては)全チームにまたがるコンプライアンス議題の報告と指導を任されるDevOpsチームのリーダーにとって、多くのチームに対応することは困難である。

例えば、Terraformファイル内で秘密がどのように管理されているかを考えてみよう。秘密保護には、明らかに異なる投資レベル(資金と労力)がある。

DevOpsチームがこの意思決定プロセスを担当する場合、まず異なるチームが使用しているInfrastructure as Codeファイルのセットを評価し、これらのファイルを調べて必要な変更を加える必要がある。これは大規模なプロセスだ。その代わりに、もしTerraformファイルがDevOpsチームによってモジュール方式で一元管理されていれば、彼らはどのリポジトリとファイルを変更する必要があるかを正確に知ることができ、変更は開発者チームにとって迅速かつ透過的になる。

バラバラで分散化されたIaCファイルから構成された環境の非常に典型的な側面(そして大きな欠点)の1つは、本番環境を反映していないことが多いということだ。このようなプロセスの結果、開発者が本番環境について思い込みをすることがあり、それが別のチームによって変更される可能性がある。環境が一元管理されていない場合、ソフトウェア開発ライフサイクルを通じて、ある環境での変更が他の環境に反映されない可能性がある。その結果、壊滅的な欠陥が本番環境に導入され、場合によっては大停電を引き起こす可能性がある。多数のインフラストラクチャが定義されているため、DevOpsチームは本番環境でデバッグする必要がある。

キーポイント:環境のトポロジ(どの程度本番環境を模倣しているか)、シークレット、キーなどの意味で、下位環境を本番環境と同様に扱う。下層環境を迅速にセットアップし、オンデマンドで撤去する手段を提供することで、下層環境のコストを管理する。

下位環境(ステージング、開発など)が本番環境を模倣するために少しずつ前進しているが、わずかな試みしかしていないことに注意する。最終的には、この努力は長期にわたって維持されず、本番環境へのデプロイに失敗したり、最悪、機能停止やセキュリティの脅威にさらされたりする危険性がある。

特別なビルドや環境は、本番環境を模倣するために構築されるが、結局はいくつかのケースをカバーするに過ぎない。本番環境を模倣していない環境で構築されたバージョンのデプロイによる本番環境での失敗、あるいは同様にセキュリティ侵害に対する自然な反応は、そのチームおよび/またはマイクロサービスを強化することである。しかし、このアプローチは、リスクを次のチームに移すだけである。どのチームとマイクロサービスがより現実的な環境を必要とするかを分析し、調整するアプローチは、全体的で完全である必要がある。下位の環境は、共通の基本コンポーネントを持ち、いくつかのチームが追加レイヤーを持つようなモジュール方式で記述する必要がある。基本的に、各チームが完全に異なるという状況は避けなければならないが、これは管理が非常に難しくなる。

要約すると、変更管理、コスト管理、コンプライアンスは、アプリケーション環境が非常に複雑なトピックであり、あらゆる製品組織の変革と速度を促進するために不可欠なトピックであるという事実を強調する3つの側面に過ぎない。大半の組織は、アプリケーション環境を完璧なものにはしておらず、実際、完璧からはほど遠い。インフラストラクチャソリューション(通常はオンプレミスからクラウドへ)の移行中であったり、モノリシックからサービス指向アーキテクチャへの移行中であったりする。さらに、ビジネスの成長ニーズもあり、そのニーズをサポートするために慎重なアプリケーションアーキテクチャの計画が必要となる。コスト管理とガバナンスを維持するビジネスのニーズは、開発者が目指すスピード感のあるイノベーションとしばしば対立する。しかし、こうである必要はない。各チームに適切なレベルのコントロールを提供し、スケールでのコラボレーションを促進し、ビジネスに必要な成長をもたらす、より良い方法がある。

作者について

この記事に星をつける

おすすめ度
スタイル

BT