このガイドでは、New Relicのインストールと構成を自動化して、可観測性から得られる価値を最大化するためのアイデアとプロセスについて説明します。これは、可観測性の成熟度に関するシリーズの一部です。
概要
コードとしての可観測性は、テレメトリデータから最大の価値を引き出すのに役立つ、一貫性のある制御された自動化された方法で、可観測性ツールの構成を自動化するプロセスを説明するために使用される用語です。このリソースでは、NewRelicの実装でこれを行うことに焦点を当てます。
このガイドを使用する理由
インフラストラクチャ、アプリケーション、サービステクノロジーが進化するにつれて、それらの規模と複雑さが増し、インストルメンテーションツール（New Relicを含む）から収集されるデータの量が増え、データの意味を理解し、コンテキストに取り入れ、アクションを推進することに関連する課題が増えますそれの後ろから。
New Relic の構成を自動化するためのコードの方法論としての可観測性を使用することで、この課題に対処し、組織が採用を加速し、安定性を向上させ、より良いガバナンスを推進するのに役立ちます。
このガイドでは、可観測性をコードとして実装する方法についてのガイダンスを提供し、New Relic プラットフォームを迅速かつ大規模に構築および維持できるようにするための適切なアドバイスと参照例を提供します。自動化ワークフローとプロビジョニング ツールを活用して、組織がオブザーバビリティのベスト プラクティスを拡張できるようにすると同時に、手作業を減らし、サービス提供を改善します。これらのアイデアの実装が成功すれば、IT 組織自体と、IT 組織がサポートするビジネスの両方に真の価値がもたらされるはずです。
期待される成果
急速に変化する大規模な環境で最適に構成された可観測性ソリューションを実装および維持することに関連するコストとリスクを削減します。
具体的には、コード プラクティスとしてオブザーバビリティを採用する利点のいくつかを以下に示します。
繰り返し可能、複製可能、再利用可能
コードを介してNewRelicリソースを管理することは、それらを簡単に繰り返し、スケーリングし、一括で更新できることを意味します。 Terraformなどのプロビジョニングツールでモジュラーアプローチを活用すると、ダッシュボード、アラート、ワークロードなどのパッケージ化されたリソースセットをすばやく簡単に共有および展開できるため、起動時間が短縮され、組織全体の標準が向上します。
労力の削減
コードを介して管理されるNewRelicリソースを作成および維持する労力は、特に大規模な作業を行う場合、ユーザーインターフェイスを介して手動で管理するよりも大幅に少なくなります。私たちのインターフェースは発見とテストに適していますが、コード管理されたリソースへの変更を一括適用できるため、リソースの管理にかかる時間を大幅に短縮できます。一般的なアプローチの1つは、ユーザーインターフェイス内でアラートとダッシュボードを開発し、それらが十分に成熟していると見なされたら、コード管理されたリソースに移行することです。
ドキュメントとコンテキスト
New Relicで構成できるリソースは多種多様であるため、単一のリソースを見ると、なぜそのリソースが作成または構成されているのかを理解するのが難しい場合があります。コードを介した構成により、特定の選択が行われた理由、時期、および対象者を説明するのに役立つ、関連するコメントとドキュメントが可能になります。
監査可能な履歴
NRAuditEventイベントを介して誰が New Relic リソースに変更を加えたかを理解することはできますが、これでは、変更が行われた理由、以前の状態、または変更を承認した人についての背景はほとんどわかりません。自動化された承認ベースのプロビジョニング ワークフローと連携してコードを介してリソースを管理することで、変更をより明確に可視化し、ガバナンスを改善すると同時に、ロールバックと回復の方法も提供します。
セキュリティ
コードとしての可観測性により、New Relic リソースを管理するための API キーの使用をより厳密に制御できます。流通している API キーの数を減らし、その作成と配布に関して適切なガバナンスを確保することで、セキュリティが向上します。特に自動化されたワークフロー内で、ユーザーが独自のキーを使用することを思いとどまらせることは、キーの侵害や意図しない破損の可能性を減らすことを意味します。
効率的なデルタ変更
Terraformのようなプロビジョニングツールを使用すると、既存のリソースにデルタ変更を加えることができます。これにより、リソースの破棄と再作成を最小限に抑えながら、変更が必要なリソース属性のみが変更されるため、更新が迅速かつ効率的になります。これは、ダッシュボードやアラートなどのリソースのGUIDが更新時に変更されないようにするために重要です。
外部刺激に反応する
コードとしての可観測性と自動化されたワークフローを組み合わせることで、アプリケーションのデプロイ、インフラストラクチャ イベント、またはその他のデータ入力などの外部刺激の結果として、New Relic リソースを作成および修正できます。たとえば、デプロイ時にコード バージョン リリース間で主要なゴールデン シグナル メトリックを比較するダッシュボードとアラートを自動的に生成できます。
コンテキストの所有権とパッケージ化
コードでリソースを管理すると、関連するリソースを一緒に管理できます。ユーザーインターフェイス全体に分散する場合よりも、コード内でそれらを1か所で理解して管理する方が簡単です。たとえば、これにより、さまざまなチームが影響範囲内のリソースを管理、表示、および維持でき、管理するリソースを探す必要がなくなります。
災害からの回復
ときどきミスが発生し、間違ったリソースが更新または削除されます。手動のリソース管理でこのような状況から回復することは困難です。なぜなら、以前に存在していたものを知ることは容易ではなく、リソースが変更されたり失われたりすることさえも簡単ではないからです。コードとしての可観測性は、リソースを再作成したり、期待される構成にリセットしたりできるようにすることで、これらの問題から保護するのに役立ちます。また、構成のドリフトをプロアクティブに検出する機会も生まれます。
展開の速度
コードとしての可観測性は、共通のリソース セットをチーム間で簡単に共有し、可観測性ツールのブートストラップに使用できるようにすることで、展開の速度を加速します。これは、似たようなアプリケーション展開アーキテクチャがクッキーカッターモジュールベースの New Relic リソースの恩恵を受けるマイクロサービスアーキテクチャで特に顕著です。再利用可能な集中管理モジュールを作成することは、可観測性ツールへの一般的なアプローチを標準化するのにも役立ちます。
主要業績評価指標
コード デプロイとしての可観測性の成熟度は、いくつかの方法で評価できます。一般に、コードによって管理される環境内のリソースが多いほど、展開はより成熟します。いくつかの KPI を次に示します。
前提条件
New Relicを使用したコード実装としての可観測性に着手する前に、NewRelicUniversityから入手できる基本事項について理解しておく必要があります。
また、次のことを行う必要があります。
- Terraformなどのプロビジョニングツールを選択して精通している
- 自動化ワークフローをサポートするCI/CDプラットフォームにアクセスできます
- NewRelicプラットフォームとAPI機能に精通している
- リソースのタグ付けと命名の規則または戦略を決定しました
- KPIを決定するための資産粒度戦略を決定します
- CI/CDツールからの変更を適用するためのサービスアカウントAPIキーと権限モデルを準備しました
現在の状態を確立する
コードとしての可観測性の実践に着手する前に、現在の状態を評価する必要があります。上記の成熟度評価の概念を活用して、環境の成熟度を判断し、最初に取り組む環境に優先順位を付けることができます。
改善プロセス
New Relicでコードとしての可観測性を採用することを決定したかもしれませんが、開始方法がわからない場合、または一般的な行き止まりやトラップを避けたい場合があります。ここでは、コードとしての可観測性を自信を持って採用できるように、優れたプラクティス、アドバイス、および参照例に関するガイドを提供します。
チームベースのリソースの分離
多くのチームが、単一のNewRelicアカウントまたは複数のアカウントにわたるリソースの管理に関与している可能性があります。コードとしての可観測性の実践は、リソースの分離、アクセス、および管理をより厳密に制御する方法を提供します。個人への書き込みアクセスを制限し、マネージコードを介して変更を適用することで、チームはお互いのリソースに影響を与えるリスクを冒すことなく、同じスペースで安全に作業できます。
たとえば、それぞれが異なるNewRelicアカウントでアプリケーションを監視する複数のアプリケーションチームに代わってクラウドインフラストラクチャを管理する共有インフラストラクチャチームがあるとします。この共有インフラストラクチャチームは、アプリケーションチーム自身のリソースとともに、これらのアカウント内で独自のNewRelicリソースを管理します。ユーザーの書き込みアクセスを制限し、主要なリソースがコードとしての可観測性ワークフローを介してのみ管理されるようにすることで、チームのリソースが調和して共存し、不正または意図しない変更の可能性を減らすことができます。
この図は、さまざまなチームのCI / CDパイプラインが、重複する複数のアカウントで分離されたリソースを管理するためにどのようにアクセスできるかを示しています。
APIキー
NerdGraph APIを使用して、またはTerraformなどのプロビジョニングツールを介してリソースを管理するには、NewRelicユーザーキーが必要です。ユーザーキーは特定のユーザーに関連付けられており、そのユーザーの権限を継承します。
サービスアカウント
実際の人間のユーザーに対してNewRelicユーザーキーを作成すると、自動パイプラインに問題が発生する可能性があります。たとえば、チームの移動の一環としてそのユーザーの権限が変更された場合、またはユーザーが組織を離れた場合、それに依存する自動化パイプラインは失敗する可能性があります。
自動化の目的で特別に作成された中央管理チームによって管理される「サービスアカウント」ユーザーを作成することを検討してください。これらのチームは、他の実装チームに配布するためのキーを生成および管理できます。サービスアカウントを使用して複数のキーを生成し、実装チームが独自のキーのみを使用するようにすることができます。この方法で管理されたキーは、より簡単に監査され、権限が正しく設定され、安定していることを確認するのに役立ちます。個人は、開発とテストを除いて、自分のユーザーキーを使用しないように奨励されるべきです。
自動APIキー生成
NerdGraphを介して新しいRelicユーザーキーを生成できるため、完全に自動化されたオンデマンドキープロビジョニングが可能になります。これは、ポータルまたはサービスプロセスフローを介したキーの生成を自動化するために使用できます。
自動化ツール
Terraformを使用して、NewRelicリソースのプロビジョニングを管理することをお勧めします。 Terraformのようなツールを使用すると、呼び出すAPIや、作成されたものの記録を維持する方法を気にすることなく、コードでリソースを構成できます。
New Relicは、独自のNewRelicTerraformプロバイダーを積極的に維持しています。機能のリクエストと問題は、オープンソースのTerraformGitHubリポジトリで送信できます。
状態管理
Terraformを使用してNewRelicリソースを管理する場合、Terraformの状態を安定して記録することが重要です。理想的には、状態はリモートの場所に安全に保存され、バージョン管理され、安定性を確保するために状態ロックを活用する必要があります。
管理対象リソースを特定する
コード管理されているNewRelicのリソースを簡単に識別できることが重要です。これにより、成熟度KPIを評価できるだけでなく、UIを操作するユーザーが、コード管理されているため手動で変更してはならないリソースを理解するのにも役立ちます。
コードで管理されるリソースのタグ付けと命名について、組織全体で一貫した標準を開発することをお勧めします。少なくとも、リソースがコード管理されていることをタグ付けして識別する必要があります。たとえば、タグcodeManaged=trueと、場合によってはサフィックスまたはプレフィックスをリソース名に追加して（たとえば、「データベースパフォーマンスの概要[CM]」）、それらを識別しやすくすることができます。さらに、所有チーム、リソースのソース、コードバージョンなど、さらに役立つ情報をリソースにタグ付けすることを検討する必要があります。
大規模なリソースセットの処理
新しい構成が適用されたときに変更を探すために、Terraformで構成されたすべてのリソースを更新および評価する必要があります。構成の量が増えると、チェックするリソースのリストが増えます。各チェックにはAPI呼び出しが必要であるため、大規模な構成は完了するまでに時間がかかる場合があり、並行して行われるリクエストが多すぎるとAPIの制限に遭遇する可能性があります。 1つのアプローチは、単一の状態内で管理されるリソースの数を減らし、構成をパーツに分割することです。また、Terraformリクエストの並列処理を減らすことで、APIの制限を緩和できます。
モジュール式のアプローチを取る
モジュールは、Terraformでリソース構成をパッケージ化して再利用するための主な方法であり、任意の数のNewRelicリソースを一緒にパッケージ化するために活用できます。このようなパッケージ化により、パラメーター駆動型のデプロイメントが可能になります。たとえば、アプリケーション名を取得し、概要ダッシュボード、ゴールデンシグナルアラート、および合成ジャーニーをすべて1つの操作で構築するモジュールがあるとします。
Terraformモジュールは、リモートレジストリに公開して、チームが他のチームによって開発されたリソースパッケージを共有および消費できるようにすることができます。これにより、標準化を実装し、バージョン管理された変更と改善を簡単に展開する機会が提供されます。
実装リファレンス
自動化ワークフロー
自動化ワークフローは、コードとしての可観測性をチームや組織にスケーリングするために不可欠です。 Terraformワークフローを推進できるCI/CDツールとサービスは多数あります。これらにより、構成の変更について話し合い、承認すると同時に、監査可能な変更の証跡を提供できます。
チームがNewRelic構成で共同作業できるように、 Terraformワークフローを採用することをお勧めします。そのようなワークフローの1つは、GitHub、GitLab、Bitbucketなどのコードバージョン管理システムのCI / CD機能を活用して、組み込みの承認およびレビューメカニズムを使用してコードを自動的に計画および適用します。
この図は、変更がPRとして発生し、PRが承認されてメインにマージされ、リソースの展開がトリガーされる方法を示しています。
ワークフローの実装例
次の参照例は、さまざまなシステムでTerraformワークフローを設定する方法を示しています。
- GitHub Actions の例: この例では、 GitHub Actionsを AWS S3 でサポートされた状態ストレージと一緒に使用する方法を示します。
- GitLabパイプラインの例：この例は、 GitLabパイプラインをGitlabhttp状態ストレージと一緒に使用する方法を示しています。
- Bitbucketパイプラインの例：この例は、 BitbucketパイプラインをS3でバックアップされた状態ストレージと一緒に使用する方法を示しています。
バージョンの固定
observability-as-codeワークフローを介してリソースを自動的にプロビジョニングする場合、ワークフローがすべての実行で同じように実行されるようにすることが重要です。パイプライン障害の原因となる予期しないアップグレードが発生しないように、使用したNewRelicプロバイダーとTerraformのバージョンをバージョン固定することをお勧めします。ピンのバージョンを決定する場合は、定期的に最新バージョンにアップグレードしてテストする必要があります。制約バージョンの詳細については、 Terraformドキュメントをご覧ください。
構成ドリフトの検出
構成のドリフトを理解することは、可観測性プラットフォームの安定性と信頼性を確保するために重要です。アクセス制御とアクセス許可の戦略によっては、ユーザーがコードで管理されているUIのリソースを変更できる場合があります。この構成のずれを検出すると、変更を理解し、必要に応じて構成を修正できます。
動作には主に2つのモードがあります。
- 検出と通知：このモードでは、ドリフトが検出され、オペレーターに通知されます。ただし、修正の変更は自動的には行われません。
- 検出、修正、通知：このモードでは、ドリフトが検出され、可能な場合はワークフローによって自動的に修正されます。
この図は、構成ドリフトワークフローを実装する方法を示しています。検出された変更はNewRelicに報告され、そこでアラートを受け取り、時間の経過とともに追跡できます。
構成ドリフト参照例
この参照例では、GitHub Actions を活用して、通常の Terraform プラン操作をスケジュールします。検出された変更の数は New Relic に報告され、オプションで Terraform の再適用を開始できます。
結論
採用すべきベスト・プラクティス
- KPIを明確に定義および実装して、コードとしての可観測性の成熟度を測定します。
- 新しいコードとしての可観測性機能を実装する前に、現在の状態を確立して伝達します。
- 可能な限り自動化を活用して、環境全体での可観測性の提供を加速します。
- コードを介して作成されたアセットを自動ドキュメント化します。
- 構成のドリフトを追跡およびアドレス指定します。
- 環境全体で資産の拡張再利用を促進します。
価値の実現
このプロセスの最後に、次の利点を理解する必要があります。
- コードとしての現在の可観測性の成熟度を簡単かつ効果的に伝達します。
- 環境の可観測性までの時間を短縮します。
- 可観測性を実装するために必要な手作業を減らし、生産時間を解放します。
- 実稼働環境でのオペレーショナルリスクを軽減します。
- 問題をより迅速に検出して解決する機能を向上させます。
- 新しいリリースを展開する時間を短縮します。
- テレメトリデータを組織全体にとってより実用的なものにします。
- サービスの可用性とビジネスへの提供を改善します。