レシピについて
Composer レシピは、設定した条件に対してクラウドリソースを評価するための、再利用可能な定義です。評価するリソースを選択し、クエリー条件を追加し、重大度やピラー などのメタデータを設定します。レシピを公開すると、一致したリソースは独自のInsights として表示される場合があります。
ガイド付きウォークスルーについては、チュートリアル: 最初のレシピ を参照してください。項目ごとの詳細なリファレンスについては、レシピの作成と編集 を参照してください。
前提条件
レシピを作成または実行する前に、次を行います。
-
評価対象とするクラウドアカウントに対して Composer を有効化 します。
-
アカウントのスキャンが正常に完了していることを確認します。スキャンが完了するまで、クエリー結果と Insights は不完全であったり、最新でなかったりする可能性があります。アカウントのカバレ ッジ を参照してください。
レシピのワークフロー
大まかな流れは次のとおりです。
-
レシピビルダー でレシピを作成します。
-
クエリーを実行 でテストし、準備ができたら 保存して公開 します。必要に応じて継続的な評価を有効にします。レシピのライフサイクル を参照してください。
-
一致したリソースは、Composer ダッシュボード や Insights 上に独自の Insights として表示される場合があります。
レシピビルダー
レシピビルダー は、レシピを作成および編集するためのワークスペースです。開くと、ページには次の要素が含まれます。
-
上部バー: クエリーを実行、保存して公開、および レシピを複製、すべてクリア、新しいレシピを作成 などのオプションにアクセスするためのケバブメニュー（⋮）といったアクションがあります。編集、複製、クリア を参照してください。
-
Resources パネル: キャンバスにドラッグできるクラウドリソースタイプが一覧表示されます。自分のリソースのみ表示 を使用して一覧を絞り込むことができます。Resources を参照してください。
-
キャンバス: リソースと任意のリレーションを配置する中央の領域です。キャンバスが、クエリーが評価する対象を定義します。
-
レシピビルダーのサイドパネル: レシピに関する設定が 3 つのタブに分かれています。
-
アカウントスキャン のステータス: Composer がアカウントを最後にスキャンした時刻を表示します。クエリー結果を最新のリソースに反映させるには、スキャンが正常に完了している必要があります。アカウントのカバレッジ を参照してください。
項目ごとのステップバイステップリファレンスについては、レシピの作成と編集 を参照してください。
レシピのライフサイクル
レシピは、ステータス、テスト、公開、および任意の継続的な実行を通じて、設計段階から本番の評価へと進みます。イテレーションの中で、レシピの編集、複製、リセットも行うことができます。
下書きと公開済み
Composer ダッシュボード上では、各レシピに Draft または Published のステータスが表示されます。
-
クエリーを実行 は、現在の設定を即座にテストします。レシピは公開されません。
-
保存して公開 は、レシピを保存し、公開済みとしてマークして、本番評価として実行できるようにします。
クエリーの設計中は、レシピを下書きのままにしておくと便利です。未公開のレシピは、本番の継続的なインサイトポリシーとしては動作しません。
公開する前に、同じリソースと条件を対象とするレシピがすでに存在しないか、Composer ダッシュボードで検索することを推奨します。既存のレシピを再利用またはカスタマイズすることで、重複したレシピの公開を避けられます。同じリソースに一致する重複した Cost レシピは、コスト削減額を水増ししてしまう可能性があります。
継続的にチェックして実行する
レシピ公開後も Composer にリソースの評価を継続して実行させたい場合は、Details タブで 継続的にチェックして実行する を選択します。継続的な実行が有効かどうかにかかわらず、オンデマンドでテストしたいときは、いつでも クエリーを実行 を使用できます。
編集、複製、クリア
レシピの変更方法は、そのレシピを組織が所有しているかどうかによって異なります。
-
直接編集: 組織が所有するレシピを開き、詳細やクエリーを変更してから 保存して公開 を選択します。
-
複製: 任意のレシピ（DoiT 提供のレシピを含む）を開き、ケバブメニュー（⋮）から レシピを複製 を選択し、コピーをカスタマイズして新しいレシピとして保存します。既存のレシピから学ぶには、複製が最も安全な方法です。
-
すべてクリア または 新しいレシピを作成 を選択して、ページを離れずにビルダーのキャンバスと詳細をリセットします。レシピの表示 を参照してくだ さい。
所有していないレシピを表示することはできますが、通常はそれらを上書きすることはできません。編集可能な自分用のコピーが必要な場合は、まずレシピを複製してください。
ピラー
ピラーは、そのレシピが生成するインサイトの種類を分類します。Details タブで、そのレシピが検出するよう設計された問題に合致する 1 つ以上のピラーを選択します。選択した値は、公開されたレシピとともに独自の Insights に引き継がれ、チームはカテゴリ（Cost、Operations、Performance、Security）で検出結果をフィルタリングできます。
ピラーは次のような点で有用です。
-
クエリーを開く前に、そのレシピがどのような種類の問題に対処しているかを把握できます。
-
FinOps・プラットフォーム・セキュリティチームが、すべての検出結果を確認しなくても、Insights ダッシュボード 上で関連する Insights を見つけやすくなります。
-
1 つの検出結果が複数の懸念事項にまたがる場合（例えば、無駄な支出を生み、利用率の低さも示すアイドルリソース）、複数選択によりそれを表現できます。
サポートされる値は次のとおりです。
-
Cost: コスト最適化、無駄、コスト削減の機会（例: 未使用または適切なサイズにできるリソース）。
-
Operations: 運用上の健全性、オートメーション 、モニタリング、ガバナンス。
-
Performance: ワークロードの利用率、キャパシティ、応答性。
-
Security: 誤った設定、アクセスリスク、露出、および関連するハードニングチェック。
例
未アタッチの AWS EBS ボリュームを検出するレシピを作成するとします。Details で Cost ピラーと、任意で Resource deletion コスト関数を選択します。これは、未使用ストレージの支払いを停止することが目的のためです。レシピを公開すると、一致したボリュームは Cost Insights として表示されます。Insights ダッシュボードを確認する人は、Cost でフィルタリングし、他の支出関連の推奨事項とあわせてそれらの検出結果を見ることができます。
同じレシピで、アタッチされているがほとんど使用されていないボリュームも検出する場合は、利用率に焦点を当てたチームがそれらの Insights を見つけられるように、2 つ目のピラーとして Performance を追加することもできます。
Insights で使用されるより長いカテゴリ説明については、Insights のカテゴリ を参照してください。
コンプライアンス基準（例: SOC2、HIPAA、GDPR）は、レシピに付与できる任意のタグです。ピラーの代わりになるものではなく、コンプライアンス重視のフィルタリングのためにインサイトへラベル付けす る目的で使用します。
Cost が選択されている場合は、Cost function（例: resource deletion や extended support）も設定できます。レシピの作成と編集 を参照してください。