Amazon Web Services ブログ

組織のクラウドオペレーションをいかにモダナイズするか

過去 10 年間で、IT 運用チームとアプリケーション開発者が協調する方法は急速に進化してきました。かつて両チームには明確な責任分担があり、一方のチームはアプリケーション実行のためのサーバーやさまざまなコンポーネント（ストレージ、DNS、ネットワークなど）の提供と保守に重点を置き、もう一方のチームは主にアプリケーションの機能の開発、バグの修正、デプロイする成果物のパッケージングに重点を置いていました。最終的にこの分担はサイロ化されたアプローチにつながり、明らかな課題に直面します。サイロ化はチーム間のコミュニケーションを妨げます。開発者はコードをリリースする準備が整うと、運用チームにほとんど、あるいはまったく連携することなく引き渡すということがしばしばありました。その結果、運用チームは直前に与えられた要件でリリースするために奔走することになります。これはソフトウェアデリバリーのボトルネックにつながり、機能やバグ修正のリリースが遅れる原因になっていました。運用チームはソフトウェアデリバリーだけでなく、オンコール業務にも責任を持つ必要がありました。これにはアプリケーションとインフラストラクチャの両方から生じる問題への対処が含まれています。インシデントが発生すると問題の原因に関係なく、運用チームがアラートを受け取ることになるのです。そこである疑問が浮かび上がりました。それは、ソフトウェア開発者が耐障害性と信頼性に優れたソフトウェアを開発する動機は何か、ということです。「throw it over the wall」や「it works on my laptop」といった言葉 (訳註: それぞれ「向こうのチームに任せてしまおう」、「手元のマシンだと動くんだけど」の意) はそのために作られたもので、今日でも議論の中でよく使われています。

DevOps は開発者と運用チームの間に架け橋を築くことを目的として、前述の課題に対応して生まれました。DevOps は責任を共有する文化を育むことと、コミュニケーションと統合を通じた両チーム間の協調に重点を置いています。このアプローチでは継続的インテグレーション (CI) と継続的デリバリー (CD)、マイクロサービスアーキテクチャ、監視/ログ/トレースによる可視化を活用してインフラストラクチャとアプリケーションの自動化を促進します。DevOps モデルの採用によって、最終的により迅速で信頼性の高いリリースサイクルが得られます。このモデルは善意に基づくものであり、DevOps プラクティスの実装は容易ではありません。組織は DevOps が期待する文化に適応し、忠実に実行することに苦労しています。さらに、チームはスピードと安定性の適切なバランスを見つけるのに苦労することがあり、ダウンタイムや環境の不安定さを恐れてかつてのやり方に戻ってしまうことがよくあります。DevOps は協調と自動化の文化に重点を置いていますが、すべての開発者が運用に関わることを望んでいるわけではなく、逆もまた同様です。そこである疑問が浮かび上がります。開発者が自由に管理できる、セルフサービスへの「ゴールデンパス」 (a golden path) を提供しながら、ガードレールとベストプラクティスを組み込んだストレスのない開発者体験を一元化して提供するにはどうすればよいかということです。ここでプラットフォームエンジニアリングの出番です。

プラットフォームエンジニアリングはインフラストラクチャと運用の更なる発展を後押しすると同時に、開発者が堅牢でスケーラブルなアプリケーションを作成して提供できるようにする、組織にとって重要なメカニズムとして台頭してきました。リソースのプロビジョニングを抽象化するグッドプラクティスが組み込まれたセルフサービスメカニズムを提供することで、開発者体験を向上させることを目的としています。これは DevOps のプラクティスの上に構築されており、開発者がセルフサービスを通じてリソースを完全にコントロールできるようになり、誰かに仕事を押し付ける必要もありません。プラットフォームチームがこのようなセルフサービスインターフェースを実装する方法は GitOps に焦点を当てた戦略の活用から、UI や API を通じた内部開発者プラットフォーム (Internal Developer Platform) の構築まで、さまざまな方法があります。より迅速でアジャイルな開発に対する需要が高まる中、多くの組織がこのモデルを採用して業務の効率化、可視性の向上、コストの削減、そして新しいアプリケーションの導入に伴う負担の軽減を図っています。

このブログ記事では今日の組織で使用されている一般的な運用モデルについて、プラットフォームエンジニアリングが当てはまる場所や、セルフサービスプラットフォームの構築と開発に利用される一般的なパターン、そしてこの新たな分野の今後の展望について説明します。

オペレーションモデル

私たちにとって重要なのは今日の運用チームの運用方法と、インフラストラクチャのインスタンス化やパイプラインの定義からアプリケーションのデプロイまで、開発チームをサポートするさまざまな方法を理解することです。以下の図では、4 つの一般的な運用モデルを取り上げ、それぞれがもたらす利点と課題について説明します。これはプラットフォームチームが適している場所とそうでない場所を理解する上でも重要です。

オペレーションモデル一覧

中央集権型プロビジョニング

中央集権型プロビジョニングモデルでは、インフラストラクチャの設計、導入、管理の責任は主に一元化された中央チームにあります。組織はリリース管理、プロセス管理、サイロ化されたチーム (ネットワーク、コンピューティング、パイプラインなど) の分割など、範囲が狭い特定の役割に統制の施行を割り当てます。リクエストモデルでは通常、チケットまたはリクエストを中央チームまたはサイロ化された専任チームに送信します。チケットはバックログに入り、開発者はリソースがプロビジョニングされるまで待つ必要があります。理想的な環境では、中央チームがリソースとパイプラインを迅速にプロビジョニングして開発者は稼働できますが、実際には中央チームは忙しく、優先順位を付ける必要があります。開発チームは待たされたり、必要なものを事前に予測したりしなければならないことがよくあります。

このモデルではリソースのプロビジョニングを中央集権的に制御できますが、デリバリープロセスにボトルネックが生じ、一般的にデプロイサイクルとフィードバックループが遅くなります。このモデルは要件やユースケースが異なる多数の開発チームをサポートする場合に特に困難になります。最終的に、このモデルはチーム間のフラストレーションや摩擦を招き、しばらくすると組織がこのモデルでの運用をやめようとすることになります。これが次のモデル、つまりプラットフォーム型ゴールデンパスモデルへと進むことにつながります。

プラットフォーム型ゴールデンパス

プラットフォーム型ゴールデンパスモデルは開発者が一連の標準に従うことで一貫性を維持しながら、何らかのカスタマイズを行えるようにするアプローチです。このモデルでは、プラットフォームエンジニアは開発チームがそのまま使用できる共通のアーキテクチャに基づいて、適切なデフォルト設定、ガードレール、およびグッドプラクティスを備えた「好ましい」標準を明確に示します。洗練されたプラットフォームチームは、このフレームワークを元に次のような方法で独自のカスタマイズを実装できます。

テンプレートの作成と更新はプラットフォームチームが担当し、通常はメンテナンスの責任を共有します。このアプローチでは、一貫性と柔軟性のバランスが取れているため、標準を維持しながらある程度のカスタマイズが可能です。ただし、開発チームはインフラストラクチャを自由にカスタマイズできるため、組織全体の可視性を維持するのは難しい場合があります。プラットフォームチームがこうしたパターンに基づいて構築しているさまざまな開発チームがデプロイするリソース全体に変更を伝播させたい場合、これは特に困難になります。

組み込み型 DevOps

組み込み型 DevOps モデルは、DevOps エンジニアが開発チームと直接連携してインフラストラクチャを定義、プロビジョニング、保守するモデルです。組織がこのモデルを使用する方法には、いくつかの一般的なパターンがあります。

  • フローティングモデル (floating model): このモデルでは、開発プロセスの早い段階で DevOps エンジニアが開発チームに直接参加し、必要なパイプラインとインフラストラクチャリソースの構築を支援し、すべてが稼働したら別のチームに移ります。
  • 常任組み込みモデル (permanent embedded model): 開発チームに常任の DevOps エンジニアを配置して、アプリケーションの進展や初期のイテレーション、メンテナンスをサポートします。理想的には、DevOps エンジニアはプロジェクトの最初からアサインされ、機能要求やバグ修正に基づいてインフラストラクチャと自動化のサポートと改善を続けます。

中央のプラットフォームチームやアーキテクチャチームは許容される構成とリソースを定義し、DevOps エンジニアが開発チームのニーズを満たす最適な使用方法を決定します。個々のチームがテンプレートとパイプラインの保守と更新を担当します。このモデルでは俊敏性と柔軟性が向上しますが、開発チームごとに DevOps エンジニアを雇用するための資金も必要になり、開発チームの規模が拡大するにつれてコストがかさむ可能性があります。このモデルを運用する際には DevOps チームのメンバー間の協調を維持し、ベストプラクティスを共有できるようにすることが重要です。

分散型 DevOps

最後に、分散型 DevOps モデルでは開発チームにインフラストラクチャとパイプラインの定義と管理に関する完全なエンドツーエンドの所有権と責任が与えられます。中央チームがガードレールや境界の構築に集中して、境界内の影響範囲を制限できるようにすることもあるでしょう。また、開発チームが自由に設計上の意思決定を行い、自律性を保てるようにしながら、デプロイされるインフラストラクチャが会社の基準を満たしていることを確認するプロセスを作成することもできます。このアプローチでは俊敏性と柔軟性が最大になりますが、不整合、エラー、セキュリティの脆弱性が発生するリスクも最も高くなります。さらに、このモデルでは開発チームがスタック全体を所有するようになるため、組織内の文化を変える必要がありますし、責任が増えることになります。このモデルの採用を開発者は躊躇うかもしれません。特に、クラウドでのリソース構築に慣れていない場合には顕著です。

結局のところ、各モデルには長所と短所があります。このブログの目的は、現れつつあるパターンについて啓蒙することです。最終的にどのアプローチが適切かは、組織固有のニーズと目標、そして文化的な変化への意欲次第です。前述のパターンのうち、最も一般的になりつつあるのは、プラットフォーム型ゴールデンパスと分散型 DevOps の 2 つです。さらに、プラットフォームチームが同じ組織内でこの 2 つのパターンを行ったり来たりすることが多いこともわかっています。その理由の 1 つは、抽象化と自動化によってクラウドでのインフラストラクチャ構築を容易にするテクノロジーによるものです (AWS Cloud Development Kit (CDK)、AWS Serverless Application Model (SAM) CLI、AWS Copilot、サーバーレスフレームワークなどのツールを考えてみてください)。次に、このようなユースケースをサポートするために現れつつあるテクノロジーパターンを見てみましょう。

新たなテクノロジーパターン

内部開発者プラットフォームと GitOps プラクティスはソフトウェア開発プロセスを合理化し、開発チームとプラットフォームチーム間の協調を改善するため、ますます注目度が高まっています。内部開発者プラットフォームでは、開発者がアプリケーションおよび関連するインフラストラクチャリソースの構築、テスト、デプロイ、監視に必要なリソースとツールにアクセスするための一元化されたプラットフォームを提供します。内部開発者プラットフォームは UI、API、または Git 経由で事前承認済みのパターンを含むセルフサービスインターフェイスを提供することで、開発チームが独立して作業し、より効果的に互いに協調できるようになります。これにより、運用チームの負担が軽減されるだけでなく、開発者がリソースのプロビジョニングを待つ必要がなくなるため開発の俊敏性とスピードも向上します。内部開発者プラットフォームによってパラダイムが変化します。なぜなら、開発チームは提供されたインターフェースを通じて一元的にバックエンドリソースを利用できプラットフォームチームはその設計と標準の定義に集中できるからです。プラットフォームチームは内部開発者プラットフォームを製品と見なし、開発者を顧客と見なすべきです。

内部開発者プラットフォームは UI と API を通じて多くの価値と抽象化を提供しますが、デプロイメントオーケストレーションの中心として Git を使用することを好む組織もあります。このような場合は GitOps を活用することが役立ちます。GitOps は、インフラストラクチャとアプリケーションのデプロイを統制および管理するためのソースとして Git を活用する方法論です。GitOps では、インフラストラクチャはコードとして宣言的に定義され、変更は Git で追跡されるため、デプロイプロセスの標準化と自動化が可能になります。デプロイオーケストレーションに Git を使用することは新しいことではありませんが、GitOps には Git オーケストレーションを新たなレベルに引き上げる概念がいくつかあります。

OpenGitOps で定義されている GitOps の原則を見てみましょう。

  • 宣言型 (Declarative): GitOps によって管理されるシステムは、望ましい状態を宣言的に表現する必要があります。
  • バージョン管理とイミュータブル (Versioned and Immutable): 望ましい状態は、不変性とバージョン管理を強制し、完全なバージョン履歴を保持する方法で保存されます。
  • 自動化された定義の取得 (Pulled Automatically): ソフトウェアエージェントは、望ましい状態の宣言をソースから自動的に取得します。
  • 継続的調整 (Continuously Recounciled): ソフトウェアエージェントは実際のシステム状態を継続的に監視し、望ましい状態を適用しようとします。

GitOps はすべての変更を一元的に追跡できるため、エラーのリスクを軽減し、組織全体の一貫性を向上させるのに役立ちます。さらに、開発者は使い慣れた Git のインターフェースを利用できるようになるだけでなく、インフラストラクチャとアプリケーションの望ましい状態を 1 か所に保存できるようになります。GitOps は Git 内の望ましい状態を常に維持し、ドリフトが発生した場合は外部プロセスがリソースの状態を調整することに重点を置いています。GitOps は Flux や ArgoCD などのツールを使用して Kubernetes エコシステムの中で誕生しました。

最後に取り上げるべきトレンドは、特に分散型 DevOps モデル内で機能し、インフラストラクチャとアプリケーションデリバリを含むスタックに対してエンドツーエンドの責任を負っているチームに関するものです。基盤となるクラウドリソースをつなぎ合わせる専門家であると同時に、アプリケーションのビジネスロジックを構築する専門家であるために必要な認知的負荷は非常に高くなります。チームが抽象化と自動化の力をインフラストラクチャのプロビジョニングに活用しようとするのはこの課題に対処するためです。これは前述の手法と似ているように思えるかもしれませんが、主な違いは開発者体験を向上させるために特別に設計されたツールを使用する点にあります。ツールはさまざまなコンポーネント (ネットワーク、アイデンティティ、そしてそれらの連携) を抽象化することで中央チームとやりとりをする必要がなくなり、開発者が自律的に運用し、インフラストラクチャの完全な所有権を引き継きます。このトレンドは AWS App Composer、AWS CodeCatalyst、SAM CLI、AWS Copilot CLI、AWS Cloud Development Kit (CDK) などの革新的なツールの採用によって実証されています。

未来を見据えて

確かなことが 1 つあるとすれば、開発者支援を成功させるまでの旅路はまだ道半ばであり、スピード、セキュリティ、柔軟性のバランスを見つけるのは難しい場合があることは明らかです。こうしたテクノロジーの進化の流れの中で Git はインフラストラクチャとアプリケーションのデプロイ自動化の中核であり続けてきました。 Git そのものは新しいことではありませんが、GitOps などの Git を中心に構築されているプロセスは新しいものです。業界はトレンドとして引き続きこのモデルに引き寄せられています。AWS では簡単な統合で開発者が Git を信頼できるソースとして活用できるようにする方法を模索しています。たとえば、AWS Protonは template sync という機能を使って中央テンプレートストレージ用に Git との統合を実現し、最近では service sync と呼ばれる機能をリリースしました。この機能により、開発者はGitを使って Proton サービスを設定してデプロイできます。また、プラットフォームチームと開発者はテンプレートと必要なインフラストラクチャリソースの状態を Git にシームレスに保存できます。初期設定以外に追加の作業は必要ありません。

内部開発者プラットフォームを構築することへの関心は急速に高まっており、それでもまだ初期の段階であることもわかっています。プラットフォームチームは AWS Proton、AWS Service Catalog、Backstage、その他の SaaS プロバイダーなどのツールを使用して開発者がライブラリや「ショッピングカート」を通じてパターンをセルフサービスできるように、パターンを一元的に定義できます。内部開発者プラットフォームを構築するチームでは、開発者が中央テンプレートで定義されていない追加のリソースを展開できるようにする方法を考えることが重要です。開発者プラットフォームはユースケースの大半を解決できますが、すべてを解決することはほぼ不可能です。開発者がプラットフォームにデプロイしたサービスの上にリソースをデプロイできないと、このブログの冒頭で概説した元の課題と同じ状況に戻ってしまい、最終的には実装が失敗するかもしれません。AWS Protonは components と呼ばれる機能によってこれを解決します。開発者は独自の IaC テンプレートを持ち込んで、Proton を通じてデプロイされたサービスの上にデプロイできます。

前述のパターンの人気が高まっていることから、アプリケーションの特定の要件や、ガバナンスを必要とするプラットフォームチームや中央チームの要求に合わせてクラウドリソースを設定する開発者にとって満たされていないニーズが明らかになっています。これは特にサーバーレスワークロードでよく見られます。開発者は AWS Step Functions などのサービスを利用してアプリケーションとインフラストラクチャのコードを統合し、アプリケーション層からマネージドサービス自体にさまざまなロジックを移すことがしばしばあります。これらのリソースは、ビジネスロジックの要件の変化に適応する動的な性質を持つため、一元化して管理することはますます困難になっています。したがって、これらのパターンを汎用的に適用可能な設計図にまとめて、さまざまなビジネスシナリオで再利用することはほぼ不可能です。

クラウドリソースとアプリケーションコードの区別がますます曖昧になるにつれ、開発者は基盤となるロジックを効率化し、目的の結果を迅速かつ安全に達成できるツールを採用せざるを得なくなっています。このような状況ではプラットフォームチームがこれらのツールを特定して組み込み、組織の安全手段と想定が確実に守られるようにすることが重要です。そうすることで、開発者の好みと、プラットフォームや中央チームが必要とする基本的なガバナンスとのギャップを効果的に埋められるのです。

おわりに

紹介したいくつかのモデルを促進するために設計されたさまざまな運用モデルと新たなトレンドについて詳しく探索しました。プラットフォームエンジニアリングは DevOps の継続的な進化を表しており、開発者体験を向上させて迅速で安全な導入を実現することを目的としています。同じ組織内であっても、開発者のスキルセットや好みはさまざまであることを認識することが重要です。スタック全体を完全に所有することを好む開発者もいれば、インフラストラクチャを気にせずにコードを書くことに専念したい開発者もいます。プラットフォームエンジニアリングプラクティスは障害となるのではなく、実現を促すような方法でさまざまなパターンに対応するよう継続的に発展していく必要があります。そのためには開発者を顧客とする製品としてプラットフォームを扱い、開発者のニーズや好みに優先順位を付け、効果的に対処する必要があります。

紹介されている運用モデルのどれがあなたの組織に当てはまるかを判断するには、自己評価を開始し、社内で話し合いを行うことをお勧めします。現在のインフラストラクチャのプロビジョニング、導入プロセス、開発チームのサポートを評価してください。各モデルの利点と課題を把握し、組織固有のニーズ、目標、文化的な変化への意欲とどのように一致しているかを検討してください。

このプロセスを円滑に進めるには経営層、プラットフォームエンジニアリング、開発者、DevOps など、さまざまなチームから主要な利害関係者を集めて共同のワークショップを開催してください。このワークショップでは、4 つの運用モデル (中央集権型プロビジョニング、プラットフォーム型ゴールデンパス、組み込み型 DevOps、分散型 DevOps) を確認し、次の点について話し合います。

  • 各モデルは現在の組織構造やプロセスとどの程度一致していますか?
  • 組織内で各モデルを採用または移行することによる潜在的なメリットと課題は何ですか?
  • 現在運用しているモデルについて、どのような課題に直面していますか？
  • インフラストラクチャ構築と導入の自動化を最適化するために、テクノロジーを活用するにはどうすればよいでしょうか？

この自己評価を実施し、オープンな対話をすることで組織は最適な運用モデルを特定し、技術チーム内の協調、効率性、俊敏性を最適化するための戦略的計画を策定できます。より詳しいガイドをご希望の場合は、当社のソリューションアーキテクトや AWS パートナーに連絡してください。

本記事は、Adam Keller による “How organizations are modernizing for cloud operation” を翻訳したものです。翻訳はソリューションアーキテクトの山崎 宏紀が担当しました。