Automation as Code を導入する方法：Infrastructure as Code を Policy as Code へと拡張

Infrastructure as Code (IaC) という戦略的基盤の次の段階として、組織はその手法を運用ライフサイクルのあらゆる段階で IT プロセスを自動化するために使用し始めています。IaC はインフラストラクチャの構築、プロビジョニング、デプロイを標準化しますが、IT チームは Ops as Code (OaC) を導入することで、それと同様にデプロイ後のシステムの管理と保守をコード化することができます。このアプローチはさらに Policy as Code (PaC) へと拡張し、アプリケーションとソリューションのガバナンス、リスク、およびコンプライアンスのプロセスを自動化することができます。

自動化による提供の迅速化と効率性の向上はアプリケーションチームとインフラストラクチャチームの共通の目標ですが、ほとんどのチームは Day 2 運用とガバナンスに関して手動のアプローチに頼りきりになっています。自動化はこれらの領域にも多くのメリットをもたらしますが、Day 2 プロセスを自動化するためには既存のチームが新しいツールと手法を学ぶ必要があります。Ops as Code と Policy as Code は確立されている IaC 戦略を拡張する方法で導入されるため、このカルチャーシフトは単純化されます。今ある知識や現在使用中のツールは、別のタスクに活用できます。

企業は IaC の手法に従って OaC と PaC を導入し、ベストプラクティスのコード化やあらゆる運用プロセスのルーチンタスクの自動化を行い、それによってエンドツーエンドの自動化を達成可能な状態へと導くことができます。これらの Automation as Code アプローチを使用することで、一貫性のあるスケーラブルな方法でプロセスを実行できるようになるため、チームは最低限の手動操作で、最初から最後までコンプライアンスを遵守したアプリケーション、インフラストラクチャ、ワークロードを構築および保守できます。

サーバー、クラウドインスタンス、オペレーティングシステム、ストレージ、ロードバランサー、およびその他のエンドポイントといった IT インフラストラクチャの構築と管理はずっと、時間のかかる手動プロセスでした。しかしインフラストラクチャはコンテナ化が進み、データセンター、マルチクラウド、エッジロケーションなどさまざまな場所にデプロイされるようになった現在、その一部は、特にクラウドでは、コードとしてデプロイされています。

インフラストラクチャをコードとしてデプロイすると、迅速にスピンアップして、急速に増大する要求やスケーラビリティのニーズに対応することができます。しかし、このメリットによってインフラストラクチャ管理の複雑性と緊急性も高まってしまい、組織がインフラストラクチャのプロビジョニング、デプロイ、廃棄を日常的に行う必要に迫られることも少なくありません。そうした状況に対応するために、IT チームは IaC を導入してこれらのプロセスを自動化するようになりました。

IaC に含まれるもの 

IaC アプローチでは、自動的に実行されるコードによってインフラストラクチャの定義、プロビジョニング、および管理を行います。IaC を使用すると、インフラストラクチャ仕様を含む設定ファイルが作成され、適切に設定されたインフラストラクチャとクラウドインスタンスの編集と配信が容易になります。IaC はこれらの仕様をコード化および文書化するので、チームが文書に残らないアドホックな変更を行うことを回避でき、毎回同じ環境がプロビジョニングされるようになります。

IaC でインフラストラクチャを自動化するということは、開発者がアプリケーションを開発したりデプロイメントをプッシュしたりするたびに手動でインフラストラクチャ・コンポーネントをプロビジョニングおよび管理する必要がないということです。これは、人的エラーとダウンタイムを減らすと同時に、スピードと一貫性を大きく向上させます。このアプローチではまた、ベストプラクティスを自動化コードとして構築できるので、あらゆるタスクを、チーム間で共有された専門知識に従って実行できるようになります。

インフラストラクチャ・ワークフローの自動化ガイドを読む

IaC 戦略の拡張

新しいツールの開発やそれまでと異なる作業方法の導入には時間がかかるため、ほとんどの組織にとって IaC は難しい変革でした。しかし導入した組織では、チームは何に注力するかを柔軟に選択できる自由を獲得し、問題に対してもよりアジャイルに対応できるようになりました。現在では多くの自動化ツールが IaC を処理できるようになっています。また大抵の IT チームはこの文化的な変化を受け入れているので、IaC によってもたらされる多くのメリットを活用できます。

確立された手法と IaC 向けに設計されたツールを使用することで、IT チームは運用ライフサイクル全体にわたって Automation as Code アプローチを実践し、プロビジョニング、設定、アプリケーションのデプロイ以上のことを行い始めています。運用ライフサイクルに関する唯一絶対の定義は存在しませんが、典型的には以下のように Day で分類されます。

• Day 0：設計。ビルドの指定、設定、インフラストラクチャのコンストラクトのプロビジョニング 
• Day 1：デプロイ。インフラストラクチャの設置、セットアップ、設定
• Day 2：保守。デプロイされたインフラストラクチャに関するシステムの管理、保守、更新

IaC は Day 0 と Day 1 に一貫性をもってインフラストラクチャを構築およびプロビジョニングする方法を提供します。Ops as Code はこのアプローチを、システムの管理、保守、更新など、アプリケーションやサービスがデプロビジョニングされるまで継続される Day 2 運用へと拡張します。

システムの動作状況のモニタリング、アップグレードのインストール、問題への対処などといった Day 2 タスクは、これまでずっと手作業で行われてきました。たとえばサーバーやアプリケーションがダウンした場合、IT チームはアラートのチケットを受け取りますが、これでわかるのは調査の必要な症状だけです。担当者はそこから問題を評価しなければならず、物理的な機材にログオンし、調査を行って原因を特定し、他の IT エキスパートを呼び出して解決を依頼します。問題は最終的には解決されますが、このプロセスには時間がかかります。エンタープライズの運用では規模が何倍にもなるので、かかる時間はさらに増加します。

それに加えて、Day 0 と Day 1 のインフラストラクチャタスクの複雑性が増大したように、Day 2 運用の複雑性も高まっています。にもかかわらず、Day 2 の課題に対して自動化はまだそれほど使用されていません。多くの組織が IaC を導入し、Day 0 と Day 1 のプロセスを自動化しました。そして現在では、この同じアプローチをデータセンター、クラウド環境、エッジデプロイメントへと適用し、技術のスプロール現象の抑制やリソースの解放に役立てることができるようになっています。

Ops as Code に含まれるもの

Ops as Code は IaC を自然な形で発展させたものです。インフラストラクチャチームと運用チームが蓄積してきた知識 (問題解決を通して獲得してきたあらゆる経験) をコード化し、自動化で使用します。これにより、そうした運用知識はチーム内の個人が所有するだけのものではなく、誰もがアクセスできるリソースになります。

OaC はチームのハウツーや Day 2 の運用知識を標準化、コード化、および体系化するプロセスです。OaC の導入に向けて、組織は以下のことをする必要があります。 

• 標準化：共通のコードベースを使用し、組織全体で活用して運用の一貫性を向上させられるようにします
• コード化：運用知識と構築のベストプラクティスを自動化されたプロセスで使用できるようにします 
• 体系化：統合されていないツールとプロセスを、統合されたエンドツーエンドのアプローチにまとめます

こうして Day 2 のハウツーはコード化され、システムのインテリジェンス、複雑性、相互依存性が高まる中でも、自動的に実行できるようになります。

他のあらゆる自動化の用途と同様、Ops as Code も人材を排除するものではありません。むしろ、チームが煩雑な手動タスクにかける時間を最小限に抑え、将来を見据えたプロジェクトにより大きく注力できるようにするためのものです。OaC はチームの知識を共有のアプローチと統合するので、複数の運用モデルおよびチーム構造をまたいだコラボレーションをサポートすることもできます。

IaC 手法と OaC 手法をガバナンスまで広げると、IT チームを手間のかかるリクエストベースのプロセスから解放することができます。このようなプロセスの例としてポリシー (コンプライアンス要件、ベストプラクティス、会社の方針を遵守するためのルール、条件、手順) の適用があります。 

インフラストラクチャと運用をコードとして定義し、管理し始めると、セキュリティチームやコンプライアンスチームも同じ戦略を使用し、Policy as Code アプローチでそれらのコードにポリシーを適用して、ガバナンスの管理方法を標準化することができるようになります。

自動化を行っても、最初からコンプライアンスとガバナンスを遵守できるわけではありません。そのためには、IaC と OaC が運用ライフサイクルのすべてのステージで適切に適用されるよう、一貫性をもってポリシーを適用しなければなりません。これまで、一般的なガバナンスの手法には次のようなものがありました。 

• ワークフローに承認を組み込み、個人がアドホックな解決方法を実行しにくくする
• ロールベースのアクセス制御 (RBAC) または属性ベースのアクセス制御 (ABAC) により抑制的なセキュリティ権限付与を行い、テクノロジーを変更できる人、方法、条件、特性を細かく制限する

このような手動操作に頼ったアプローチはミスを生みやすく、時間もかかります。Policy as Code はこれらのプロセスを自動化することを目指します。自動化を設定して、たとえば IT スタッフが会社の基準に従わないクラウドインスタンスを作成できないようにしたり、コンプライアンスで求められている内容を実装していないコードを提供できないようにしたりすることができます。RBAC や ABAC が必要であることに変わりはありませんが、PaC を導入することで、何をいつ実行できるかについて、はるかに粒度が小さい、自動化されたプロセスを作成することができるようになります。

Policy as Code に含まれるもの

PaC は IaC および OaC とよく似た戦略に従い、ポリシーとセキュリティ要件をコードとして記述することでコンプライアンスのプロセスを自動化します。これにより、あらゆるプロセスに標準を組み込み、チームの壁を超えて同一のルールを一貫して適用できます。PaC はコードを使用してポリシーの定義、更新、共有、適用を行うので、ガバナンスを一元化し、文書化された一貫性のある方法であらゆる IT アクションに効率的にポリシーを適用できます。

コードをポリシーとして定義してあれば、スピンアップしてデプロイしたインフラストラクチャや、自動化されたタスクを実行するときの運用にシームレスに適用し、自動化がいつどこで行われていようと標準のアプローチを実施できます。たとえば、特定のホストで発生した問題を修復するための自動化を従業員が実行する場合、各アクションにコードとして組み込まれているポリシーにより、この従業員がチームのルールに反することを実行できないようにすることが可能です。

また、PaC を導入すると、決められた標準に従って技術的環境とリソースを使用できるようになります。たとえば、機密性の高いコンピューティングリソースから直接インターネットにアクセスできるルートの存在を禁じるセキュリティポリシーがある場合、PaC を使用すると、そうしたルートが作られないようにしたり、サービスポートを HTTPS と SSH のみに限定したりすることができます。

さまざまなシステムのスケーラビリティが AI によって何倍にも拡張されつつありますが、これにより、IT は人間の力のみで達成したり制御したりできる範囲を超えて進化し始めています。自動化の開発を加速する Red Hat® Ansible® Lightspeed with IBM watsonx Code Assistant のような AI サービスを使用すれば、チームはポリシーをコードとして記述し、学習モデルに始めからガバナンスを組み込むことができます。たとえば、AI ツールがポリシーを学習モデルに取り入れていれば、コンテンツ作成者は必須のコンプライアンスを自動で維持するコードを作成することができます。

PaC でガバナンスを自動化すると、AI 駆動の管理によって革新的な効率性が提供され、必要な制御も維持されるので、IT チームのためのアクションはすべて、コンプライアンスが組み込まれた状態で実行されます。

ひと言でいえば、Automation as Code の変革は主として文化的な課題です。IaC の自動化から得た経験を活用し、同じ手法とツールを使用することで、IT チームは開発ライフサイクル全体の運用に対してより効率的で適応性の高いアプローチを取ることができます。

DevOps の導入により、企業ではさまざまなメリットと課題が発生しましたが、それでもその取り組みが広まったことから、そのように大規模なカルチャーシフトも可能であることがわかりました。自動化を行う際には常にタスクの実行方法の変更が伴います。そして、統合された Automation as Code 戦略を導入するためには、運用のあらゆる段階でプラクティスを共有することで、チーム同士がコラボレーションする方法を変革する必要があります。IaC、OaC、PaC はその取り組みの中心となります。

Automation as Code 戦略へのカルチャーシフトをサポートするために、チームは以下のことを行う必要があります。

• ソフトウェア開発者のように考える：git などのリポジトリを使用し、ビジネスのあらゆる領域で先進的な開発とデプロイの考え方をする文化を推進します。
• 自動化ファーストの意識を育てる： 新しいプロジェクトや作りたいものがある場合、ただそれを作るのではなく、まずそれを自動化する方法を考えます。シンプルな自動化プロジェクトから開始し、そこから拡張していきます。 
• 個人のスキルや経験から開始する： 組織内の全員の知識を集約して自動化として構築し、人材ギャップに対処します。こうすることで、コンテンツと専門知識をチーム間で共有できるようになります。

Automation as Code の成功は、この哲学をシステム設計チームや管理チームなどあらゆるチームに浸透させることで達成できます。これらのアプローチを使用すると、個々のチームがバラバラに部分的な自動化を進めてそれらに互換性があることを期待するのではなく、組織のすべてのチームが共同で戦略と規範を形作り、それを共有することができます。

この戦略を実践していくためには、各チームは特定のケースやチームでのみ機能するアドホックなソリューションの作成から脱却する必要があります。組織が複数のツールを使用して IaC や DevOps を進めようとした場合、それらは想定以上に複雑化し、技術的負債を生み出してしまう可能性があります。統合された自動化プラットフォームを使用すると、設定、ネットワーク、インフラストラクチャ、クラウドタスクの実行に使用するのと同じ自動化言語を、ドメインの壁を超えて運用タスクでも使用できるようになり、IT チームがエンドツーエンドの完全なライフサイクルを管理するのに役立ちます。

Red Hat Ansible Automation Platform には Event-Driven Ansible、アナリティクス、強化されたセキュリティ、認定および検証済みのコンテンツの広範なエコシステムなど、企業全体で自動化を実装するのに必要なすべてのツールが含まれており、新しい自動化の取り組みをすばやく軌道に乗せるのに役立ちます。人間が解読しやすい YAML を使用するので、組織全体でさまざまなスキルレベルのユーザーが自動化コンテンツを共有、検証、管理できます。 

Ansible Automation Platform を使用すると、運用チーム、インフラストラクチャチーム、アプリケーションチームの経験を YAML ベースの Ansible Playbook および Ansible Rulebook としてコード化することができます。playbook と rulebook を使用すると既知の解決法のパターンを Automation as Code のアプローチに変換でき、また、Event-Driven Ansible は特定のイベントが発生したときにその自動化をトリガーすることができます。

専門知識を playbook や rulebook の形に組み上げることで、チームは IT 応答を自動化して構成ドリフトの抑制、長期的な保守の問題の最小化、平均復旧時間 (MTTR) の短縮を実現できます。Event-Driven Ansible はモジュール式の設計になっており、運用ライフサイクルのあらゆる段階で、さまざまなドメインやユースケースにおいて、必要なタイミングと場所で IT アクションを自動化できます。

Event-Driven Ansible の詳細

Red Hat Ansible Lightspeed with IBM watsonx Code Assistant を使うと、専門知識を信頼できる YAML コードに変換し、それをチームやドメインの壁を超えて共有できるので、Automation as Code アプローチの実践がさらに容易になります。ユーザーはタスクリクエストを自然言語で入力できます。Ansible Lightspeed は IBM watsonx 基盤モデルと対話し、Ansible Playbook を作成するためのコード候補を生成します。このサービスはさまざまな経験レベルのチームメンバーの生産性、効率性、正確性を高めるのに役立ち、組織全体で自動化の一貫性を向上させることができます。

Red Hat では事前構成済みの Ansible Automation Platform 環境でインタラクティブラボを提供しています。このラボを活用すれば、迅速な開発とデプロイから、運用とアナリティクスの単純化、一貫性のあるエンドツーエンドのユーザーエクスペリエンスに至るまで、IT プラクティスを効率的に作成、管理、拡張する方法を実験、演習、習得できます。