DevOps とは?

DevOps モデルでは、開発とオペレーションが「サイロ化」されることはありません。 場合によっては、開発チームとオペレーションチームを 1 つのチームに統合することが行われます。エンジニアは、開発とデプロイのテストからオペレーションに至るアプリケーションのライフサイクル全体にわたって作業するため、1 つの職務にとどまらず、幅広くスキルを磨くことができます。

採用する DevOps モデルによっては、品質管理チームとセキュリティチームがアプリケーションのライフサイクル全体にわたって開発とオペレーションにもさらに緊密にかかわります。DevOps のチーム全員がセキュリティに焦点を当てる場合、これは DevSecOps と呼ばれます。

こうしたチームは、これまで手動で時間がかかっていた処理を自動化する手法を使用します。迅速かつ確実にアプリケーションを運用して展開するために役立つテクノロジースタックとツールを使用します。さらにこれらのツールは、通常、他のチームのサポートを必要とするタスク (例えばコードのデプロイ、インフラストラクチャのプロビジョニングなど) をエンジニアが単独で実行するために役立ちます。これにより、チームの作業速度はさらに向上します。

ソフトウェアとインターネットは、ショッピング、エンターテイメント、銀行業務に至るまで、その世界と産業を一変させました。今やソフトウェアは単にビジネスに役立つものというだけではありません。それどころか、ビジネスのあらゆる部分での不可欠な構成要素となっています。企業は、オンラインサービスまたはアプリケーションとして配信されたソフトウェアを通して、あらゆる種類のデバイスで、顧客と相互にやりとりを行います。また、流通、通信、および運用など、価値連鎖のあらゆる分野を一変させて運用効率を向上させるためにソフトウェアを使用します。物理的な商品を扱う企業が 20 世紀に産業のオートメーションによって製品を設計し、製造し、配送する方法を変化させたのと同じように、今日の世界で企業は、ソフトウェアを作成し、配信する方法を変化させる必要があります。

DevOps の文化と考え方

DevOps に移行するには、文化と考え方を変化させる必要があります。簡単に言うと、DevOps はこれまでサイロ化されていた開発と運用の 2 つのチームの間の障壁を取り除きます。一部の組織では、開発チームと運用チームを分けることなく、エンジニアが両方の役割を担う場合さえあります。DevOps では、2 つのチームが一緒に作業することで、開発者の生産性と、運用の信頼性がともに最適化されます。さらに、頻繁にコミュニケーションを取ることで、効率性を高め、顧客に提供するサービスの質が向上するように努めます。これらのチームはサービスに対する完全なオーナーシップを持ちます。エンドカスタマーのニーズと、そのニーズを満たす方法を考慮して、従来規定されてきた役割、または役職によって定められた範囲を超えることがあります。 品質管理チームとセキュリティチームも、これらのチームと緊密に統合される場合があります。DevOps モデルを使用している組織には、組織構造にかかわらず、全体の開発とインフラストラクチャのライフサイクルを責任を持って確かめるチームが必要です。

DevOps の手法について

ソフトウェア開発およびインフラストラクチャ管理のプロセスの自動化および合理化を通して、組織がより迅速に革新するために役立つ幾つかの主な手法があります。これらの手法の多くは、適切なツールで実行されます。

1 つの基本的な手法は、頻繁に小さな更新を実行することです。これは、組織が顧客のためにより迅速に革新を実行する方法です。通常、この手法による更新頻度は、従来型のリリース手法で実行する更新頻度よりも高くなります。頻繁に小さな更新をすることで、各デプロイのリスクを減らすことが可能です。この方法では、チームはエラーが発生した最後のデプロイを特定できるため、チームはより迅速にバグに対処できます。更新の回数やサイズはさまざまですが、DevOps モデルを使用している組織は、従来のソフトウェア開発の手法を使用する組織よりも頻繁に更新をデプロイします。

組織はマイクロサービスアーキテクチャを使用し、アプリケーションをより柔軟にして革新をすばやく実現することもできます。マイクロサービスアーキテクチャにより、大きくて複雑なシステムを、シンプルで独立したプロジェクトに切り離すことができます。アプリケーションは、多くの個別のコンポーネント (サービス) に分割されます。各サービスは 1 つの目的または機能のみに限定され、同等のサービスとアプリケーション全体から独立して動作します。このアーキテクチャによってアプリケーションの更新における連携オーバーヘッドが低減されます。そして、各サービスに対して、それぞれのオーナーシップを持つ小さなアジャイルチームが存在する場合、組織はよりすばやく作業できます。

しかし、マイクロサービスと増大するリリース頻度の組み合わせは、より多くのデプロイにつながり、運用上の課題をもたらします。そのため、継続的インテグレーションや継続的デリバリーのような DevOps の手法は、これらの問題を解決し、安全で信頼できる方法で組織が迅速に配信できるようにします。Infrastructure as Code や、設定管理のようなインフラストラクチャをオートメーションする手法は、頻出する変化に対してコンピューティングリソースが伸縮自在に対応できる状態に保つために役立ちます。さらに、モニタリングとログ記録の使用により、エンジニアがアプリケーションとインフラストラクチャのパフォーマンスを追跡することがサポートされ、それによって問題にすばやく対応できます。

全体的にこれらの手法は、組織が顧客により速く、より信頼性のある更新を配信するために役立ちます。これが重要な DevOps の手法に関する概要です。

継続的インテグレーションは、開発者が自分のコード変更を定期的にセントラルリポジトリにマージし、その後に自動化されたビルドとテストを実行するソフトウェア開発の手法です。継続的インテグレーションの主な目的は、バグを早期に発見して対処すること、ソフトウェアの品質を高めること、そしてソフトウェアの更新を検証してリリースするためにかかる時間を短縮することです。

継続的インテグレーションの詳細

継続的デリバリーとは、ソフトウェア開発手法の 1 つで、コード変更が発生すると、自動的に構築、テスト、および実稼働環境へのリリース準備が実行されるというものです。継続的デリバリーは継続的インテグレーションを拡張したもので、すべてのコード変更が、ビルド段階の後にテスト環境または本番環境、あるいはその両方にデプロイされます。継続的デリバリーを適切に実装することにより、開発者は、標準化されたテストプロセスに合格し、デプロイ準備の整ったビルドの成果物を常に手元に持つことになります。

継続的デリバリーと AWS CodePipeline の詳細

マイクロサービスのアーキテクチャは、1 つのアプリケーションを小さなサービスのセットとして構築するためのアプローチとして設計されています。各サービスは独自のプロセスで実行され、軽量のメカニズムで明確に定義されたインターフェイスによって他のサービスと通信します。通常は HTTP ベースのアプリケーションプログラミングインターフェイス (API) を使用します。マイクロサービスはビジネスコンピューティングを中心に構築され、各サービスは 1 つの目的に範囲が限定されています。さまざまなフレームワークやプログラミング言語を使用してマイクロサービスを作成し、単一のサービスまたはサービスのグループとして、それらを単独でデプロイできます。

Amazon Container Service (Amazon ECS) の詳細

AWS Lambda の詳細

Infrastructure as Code は、バージョン管理や継続的インテグレーションなど、コードおよびソフトウェア開発技術を使用して、プロビジョンおよび管理されたインフラストラクチャの手法です。クラウドの API によるモデルでは、開発者とシステム管理者がプログラムでスケールに応じてインフラストラクチャを操作できます。手動でリソースをセットアップして設定する必要はありません。そのため、エンジニアはコードベースのツールを使用してインフラストラクチャを操作でき、アプリケーションコードと同じ方法でインフラストラクチャを扱えます。コードで定義されるため、インフラストラクチャとサーバーは標準化されたパターンですばやくデプロイされ、最新のパッチまたはバージョンで更新され、反復可能な方法で複製されます。

AWS CloudFormation を使用した Infrastructure as Code の管理

設定管理

開発者とシステム管理者はコードを使用してオペレーティングシステムを自動化し、設定、運用タスクなどをホストします。コードを使用することで、設定変更は反復可能になり、標準化できます。開発者とシステム管理者がオペレーティングシステム、システムアプリケーション、およびサーバーソフトウェアを手動で設定する必要がなくなります。

Amazon EC2 Systems Manager を使用した Amazon EC2 とオンプレミスシステムの設定と管理の方法

AWS OpsWorks を使用した設定管理の活用

コードとしてのポリシー

インフラストラクチャとクラウドで体系化された設定では、組織はスケールに応じて動的にコンプライアンスを監視して適用できます。つまり、コードで記述されたインフラストラクチャによって、自動化された方法で追跡、検証、および再設定が可能になります。これにより、組織にとってリソース全体の変更を管理することが容易になり、セキュリティ対策が分散された方法で適切に実施されます (例えば、情報セキュリティ、PCI-DSS 準拠、または HIPAA 準拠)。準拠していないリソースについては、詳細に検査するように自動的に警告することや、コンプライアンスに自動的に戻すことさえできるので、組織内のチームはよりすばやい速度で作業できます。

AWS Config と Config Rules を使用して、インフラストラクチャのコンプライアンスをモニタリングおよび強制適用する方法

組織は、メトリクスとログをモニタリングし、アプリケーションおよびインフラストラクチャのパフォーマンスが製品のエンドユーザーエクスペリエンスにどのように影響しているかを確認できます。アプリケーションおよびインフラストラクチャで生成されたデータとログの取り込み、分類、および分析によって、組織は、問題または予期しない変更の根底にある原因を捉えながら、変更や更新がどのようにユーザーに影響するかを理解できます。サービスが 24 時間年中無休で使用できるように求められるにつれて、またアプリケーションとインフラストラクチャの更新頻度が増大するにつれて、アクティブモニタリングはますます重要になっています。アラートを作成してデータのリアルタイム分析を実行することも、組織がより積極的にサービスをモニタリングするために役立ちます。

Amazon CloudWatch を使用してインフラストラクチャのメトリクスとログをモニタリングする方法

AWS CloudTrail を使用して AWS API コールを記録およびログ記録する方法

組織におけるコミュニケーションと共同作業の向上は、DevOps の主な文化的側面の 1 つです。DevOps のツールとソフトウェア配信プロセスのオートメーションを使用すると、開発および運用に対するワークフローおよび責任を物理的に一緒に担うことになるため、共同作業が定着します。それに加えて、これらのチームは、チャットアプリケーション、課題やプロジェクトの追跡システム、および wiki の使用を通して、情報共有やコミュニケーションの促進について強力な文化的基準を定めます。これにより、開発者、運用、およびマーケティングや営業など他のチームの全体にわたりコミュニケーションがスピードアップします。組織のあらゆる部分が目標とプロジェクトに向かってより緊密に連携します。

DevOps モデルでは、チームが顧客のために迅速かつ確実にデプロイして、革新を進めることをサポートする効果的なツールを利用しています。これらのツールを使用して、手動タスクの自動化、規模に応じた複雑な環境を管理するチームのサポート、エンジニアによる DevOps で達成可能な高速性の制御を可能にします。AWS では DevOps 向けに設計され、最初に AWS クラウドで使用するように作られたサービスを提供しています。これらのサービスは、前述のような DevOps の手法を使用するために役立ちます。

AWS DevOps サービスの詳細

AWS パートナーソリューションの詳細