新たなIaCの登場、FinOps周りの標準化：DevOps/SRE/Kube Weekly Update (2023/11/20-26)
以下の３つの記事から気になったもの & 個人的に気になったものを毎週紹介しています。
(今週のKubeWeeklyのUpdateは最新号がリリースされていなかったため、Skipです)
DevOps Weekly（ https://devopsweeklyarchive.com/ ）
SRE Weekly（ https://sreweekly.com/ ）
KubeWeekly（ https://www.cncf.io/kubeweekly/ ）
DevOps Weekly
Radius
MicrosoftがRadiusという新しいオープンソースプロジェクトを発表しました。
Radiusはオープンソースのクラウドネイティブ・アプリケーション・プラットフォームであり、開発者とそれを支援する事業者がパブリッククラウドとプライベートインフラを横断してクラウドネイティブ・アプリケーションを定義、展開、共同開発できるようにします。
以上公式ドキュメントからの引用なのですが、Terraformなどのような既存のIaCツールと何が違うのかがわかりづらいかと思います。
インフラストラクチャレイヤーをプロビジョニングする際は、Terraformがデファクトスタンダードになっていると思います。ですが、新しいAWSやAzureのサービスを利用するとき、Terraform Resourceが未サポートだったりすると思います。結果的に、CloudFormationを利用したり、またKubernetesの設定ファイルの管理にはHelmおよびHelmfileを利用したりなど、プロビジョニングツールがバラバラになると思います。
そのような時にRadiusを利用すると、これらの設定が1つのデプロイメントに集約できるとのことです。
これがRadiusの真意であり、既存のIaCツールであるTerraformやCloudFormationの上位に位置するものとして捉えることができます。
以下の方のブログにて、非常に詳しくRadiusについてシリーズで取り上げているので、興味のある方はぜひ読んでみてください。
また、以前Radiusの発表がされた際のプレゼンテーションがYouTubeにアップされていました。デモパートもあるので、興味のある方はこちらも是非見てみてください。
ただ、Radiusプロジェクト自体はまだ初期段階であるため、β版などはまだなようです。
まだ自分自身もツールの詳細や、このツールによって具体的にどのようなメリットを得られるのかが不明瞭なため、今後もウォッチしていければと思います。
FOCUS (FinOps Open Cost & Usage Specification)
マルチクラウド環境において、各クラウドサービスのコストを管理するのは、それぞれのフォーマットが異なっており、非常に面倒な作業となっています。
先週11月16日にversion 1.0 previewがリリースされたFOCUS（FinOps Open Cost & Usage Specification）というプロジェクトでは、全てのクラウドサービスプロバイダにおける利用料金や使用量などのデータのオープン化と標準化を進めています。
ここ最近Azureの利用も増えており、ますますこのマルチクラウドにおけるコストデータの標準化機運は高まってきている印象です。
Azureでは、このFOCUSスキーマに則ったコストと使用状況のデータ出力のサポート（プレビュー版）をリリースしています。
今後も各クラウドサービスにおいて、このFOCUSスキーマで標準化されたコストデータが利用できるようになると思われます。
以下の記事では、「FOCUS標準が2024年にクラウド請求の標準化に向けて本格化する」と述べられており、今後のプロジェクトの動向をチェックしていければと思います。
SRE Weekly
Don’t name your EKS Managed NodeGroups (unless you want to trigger an incident)
Datadogなどでノードグループのメトリクスを処理するときに、どのノードグループがどのクラスターに属しているかをわかりやすくするために、ノードグループの名前を変更したとします。すると、クラスター上の全てのノードグループが置き換えられていき、本番環境がダウンしてしまう事案が発生してしまいます。
ノードグループの多くのプロパティのうち、名前を更新するには CreateNodeGroup メソッドを呼び出してから、DeleteNodeGroup メソッドを呼び出す必要があります。そのため、作成の呼び出しが行われてポッドがReadyになる前に削除の呼び出しが行われてしまいます。
CloudFormationでは、公式ドキュメントにも書いてあるようにノードグループの名前を変更すると、リプレース（新規に作成）され、前のノードグループは削除されます。
また、ノードグループには静的な名前をつけることはできません。そのようなことをCloudFormationで行ってしまうと、名前は変更しなくてもNodeGroupの再作成が必要な変更（AMIやディスクサイズの変更）を行った際に Already Exists のエラーが発生してしまいます。これは、ノードグループの名前は一意である必要があるためです。
そのため、ノードグループの名前は自動生成するようにして、任意の名前をつけようとするのはやめましょうという話でした。
Incident Response and DevOps in the Age of Generative AI
この記事では、生成AIがインシデントレスポンス（以下、IR）やDevOpsにどう影響をもたらすかを3人のシニアエンジニアによってパネルディスカッション形式で語られています。
3人とも、現時点では生成AIのみで物事を実行する域には達しておらず、人間が介入する必要があると語っています。しかし、運用面などにおいては強力なサポートツールとして進化していく可能性があると述べられています。
インシデントレスポンスに与える影響 : Nora Jones
生成AIにはIRに関して少なくとも２つの強みがあると述べられています。
- インシデントの概要を即座にチームに提供し、事態発生時に最新情報を把握するのに役立つ
- インシデント対応におけるあらゆる情報を収集・分析し、より価値のあるポストモーテムに役立つ
ただ、IRは依然として未知と例外に満ちた分野であり、主に過去のデータに基づいてパターンマッチングを行うように構築されたツールには全く適していません。そのため、インシデントの修復がAIによって即座に実行される可能性は低く、少なくとも現時点では生成AIはコンテンツの作成および要約を行うために最適化されていると述べられています。
ただ、将来的には、過去の大量のインシデントデータに基づかれたAIが、現在解決しているインシデントに似た過去のインシデントを示すのに役立つ可能性はあると語っています。ただし、魔法のようなものにはならないとも語っています。
ソフトウェアエンジニアリングおよびそのキャリアに与える影響 : Jeremy Edberg
生成AIは現時点ではあくまでも助言ツールであり、開発プロセスを大幅にスピードアップするツールにはなるが、人間の介入は無くならないと述べられています。
また、エンジニアとしての就職のハードルを下げることができるのではないか、とも語っています。これまで、一般的な推論には優れているが、コーディング構文の詳細を学ぶことに興味がなかったなどの理由で、エンジニアのキャリアを考えたことのなかった人が、キャリアとしてエンジニアリングを選択する可能性は高いとも述べられています。
エンジニアのオペレーションとスキルセットに与える影響：Blent Chapman
SREにおける生成AIの最大の価値はアフターレポートになるかもしれないと述べられています。例として、先にも挙がったようなポストモーテムの作成に役立つと考えられています。
また、チャップマン氏は監視モニターなどのグラフを分析し、根本原因を調査するときに、一見見ても分からないような異常を検出するような人がいたことを思い出し、AIツールも最終的には過去のデータを基に予測される事象を提供するのに役立つのではないかとも語っています。
そして、運用面に関してもAIに新たな可能性を見出しています。例えば、AWSコンソールにおいて会話的に要望を入力すると、それに対してAIが現在のリソース状況を踏まえてプロビジョニングの提案がなされるようになる可能性はあると語っています。
そして、今後も多くの開発者が必要になるが、彼らの多くは新たな「プロンプト」のスキルセット（＝適切な質問をし、適切なデータをフィードし、有用な情報を得るためのスキルセット）が必要になると語られています。（これらは一種の芸術であるとも言っています）
まとめ
生成AIの発達がめざましい昨今ですが、インシデント管理には不向きではあるものの、FOCUSのようなFinOps周りでは強力なサポートツールになるのではと感じています。
Discussion