ドリフト検出とドリフト原因分析の問題に対処する

今日のDevOpsに従事している誰もが、リソースをコード化することで観察、管理、自動化が容易になることに同意するでしょう。しかし、ほとんどのエンジニアは、この変革が新たな課題をもたらすことも認識しています。

おそらく、IaC運用の最大の課題はドリフトです。これは、ランタイム環境がIaCで定義された状態から逸脱するシナリオであり、深刻な長期的影響をもたらす可能性のある問題を引き起こします。これらの不一致は、クラウド環境の一貫性を損ない、インフラストラクチャの信頼性や保守性に関する潜在的な問題、さらには重大なセキュリティやコンプライアンスリスクを引き起こす可能性があります。

これらのリスクを最小限に抑えるために、これらの環境を管理する責任がある人々は、ドリフトをインフラストラクチャ運用チームにとって高優先度のタスク（そして大きな時間の浪費）として分類しています。

これにより、望ましい構成と実際のインフラストラクチャの状態との間の不一致を示すドリフト検出ツールの採用が増加しています。ドリフトの検出には効果的ですが、これらの解決策はアラートの発行とコードの差分の強調に限定されており、根本原因に関する深い洞察を提供することはありません。

ドリフト検出が不十分な理由

ドリフト検出の現在の状況は、ドリフトが確立されたCI/CDパイプラインの外で発生し、しばしば手動の調整、APIトリガーの更新、または緊急修正にさかのぼることから派生しています。その結果、これらの変更は通常、IaCレイヤーに監査トレイルを残さず、コードの不一致を単にフラグ付けするツールに制限されるため、見えないスポットを作り出しています。これにより、プラットフォームエンジニアリングチームは、ドリフトの起源や最善の対処方法について推測するしかありません。

このような不明瞭さは、ドリフトの解決をリスクのあるタスクにします。なぜなら、目的を理解せずに変更を自動的に元に戻す（一般的なデフォルトのアプローチ）ことは、問題の渦巻きを引き起こす可能性があり、一連の問題を引き起こす可能性があるからです。

リスクの1つは、これによって正当な調整や最適化が取り消される可能性があり、既に対処されていた問題を再導入したり、貴重なサードパーティーツールの操作を妨げたりする可能性があります。

たとえば、突然の本番問題に対処するために通常のIaCプロセスの外で適用された手動の修正を取り上げます。このような変更を元に戻す前に、その目的や影響を保存するためにコーディファイすることが重要です。そうしないと、病気よりも悪化する可能性のある治療法を処方するリスクがあります。

検出がコンテキストに合致

組織がこれらのジレンマに取り組む様子を見て、‘ドリフト原因’という概念が生まれました。この概念は、AI支援の論理を用いて大規模なイベントログを精査し、それぞれのドリフトに追加のコンテキストを提供します。変更をその起源に遡って追跡し、単に「何が」起こったかだけでなく、「誰が」、「いつ」、「なぜ」を明らかにします。

非均一なログを一括処理し、ドリフト関連のデータを収集するこの能力は、調整プロセスの脚本をひっくり返します。例を挙げると、前に述べたシナリオに戻り、検出ソリューションからのドリフトアラートを受け取る場面を思い描いてみましょう — 今回は追加のコンテキスト付きです。

今や、ドリフト原因から提供された情報をもとに、ドリフトを認識するだけでなく、変更が午前2時にジョンによって行われたことを特定することができます。この時、アプリケーションはトラフィックの急増を処理していました。

この情報がなければ、ドリフトが問題であると仮定し、変更を元に戻すことになり、重要な業務に支障をきたし、下流の失敗を引き起こす可能性があります。

しかし、追加のコンテキストがあれば、点をつなぐことができ、ジョンに連絡して、修正が即時の問題に対処したことを確認し、盲目的に調整すべきではないと判断できます。さらに、このコンテキストを利用して、先を見越して考え、設定に調整を加えてスケーラビリティを追加し、問題の再発を防ぐこともできます。

これは簡単な例ですが、追加の根本原因のコンテキストを持つことの利点を示すのに役立つことを願っています。これは、デバッグやトラブルシューティングの他の領域では標準であるにもかかわらず、ドリフト検出から長い間欠けていた要素です。もちろん、目標はチームが何が変わったかだけでなく、なぜ変わったのかを理解し、自信を持って最善の行動を取ることができるようにすることです。

 

IaC管理を超えて

しかし、ドリフトに対する追加のコンテキストは重要であるとはいえ、はるかに大きなパズルの一部に過ぎません。コーディファイドリソースを使用して大規模なクラウドフリートを管理することは、特にスケールにおいて、ドリフトの課題以上のものをもたらします。現在の世代のIaC管理ツールはリソース管理に効果的ですが、企業規模の環境においてより大きな可視性と制御の需要が新しい要件を生み出し、不可避の進化を促進しています。

この進化が向かう方向の一つは、クラウド資産管理（CAM）であり、これはクラウド環境内のすべてのリソースを追跡および管理します。これは、IaC、API、または手動操作を通じてプロビジョニングされたかどうかにかかわらず、資産の統一的なビューを提供し、組織が構成、依存関係、リスクを理解するのを助けます。これらはすべて、コンプライアンス、コスト最適化、および運用効率にとって不可欠です。

IaC管理が運用面に焦点を当てる一方で、クラウド資産管理はクラウドの姿勢の可視性と理解を強調します。追加の可観測性レイヤーとして機能し、コード化されたワークフローとアドホックな変更のギャップを埋め、インフラストラクチャの包括的な視点を提供します。

1+1は3になる

IaC管理とCAMの組み合わせは、チームが明確さとコントロールを持って複雑さを管理する力を与えます。年末が近づくにつれ、「予測シーズン」がやってきました — そこで私の予測をお伝えします。過去10年のほとんどを費やして、より人気のある（自分で言うのもなんですが）IaC管理プラットフォームの構築と洗練に取り組んできた結果、私はこれが業界の自然な進展であると見ています：IaC管理、オートメーション、ガバナンスをコード化されていない資産への可視性の向上と組み合わせることです。

このシナジーは、より正確で適応性があり、将来にわたって持続可能なクラウドガバナンスフレームワークの基盤を形成すると信じています。今や、IaCがクラウドインフラストラクチャ管理の基盤であることはほぼ確実です。しかし、すべての資産がコード化されるわけではないことも認識しなければなりません。そのような場合、エンドツーエンドのインフラストラクチャ管理ソリューションはIaCレイヤーだけに限定されてはいけません。

次のフロンティアは、チームがコード化されていない資産への可視性を拡大する手助けをし、インフラストラクチャが進化するにつれて、シームレスに機能し続けることを保証することです — 一度に一つの調整されたドリフトを超えて。