• /
  • ログイン
  • 無料アカウント

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

Observability-as-code:可観測性構成を自動化して価値を高める

このガイドでは、New Relicのインストールと構成を自動化して、可観測性から得られる価値を最大化するためのアイデアとプロセスについて説明します。これは、可観測性の成熟度に関するシリーズの一部です。

概要

コードとしての可観測性は、テレメトリデータから最大の価値を引き出すのに役立つ、一貫性のある制御された自動化された方法で、可観測性ツールの構成を自動化するプロセスを説明するために使用される用語です。このリソースでは、NewRelicの実装でこれを行うことに焦点を当てます。

なぜこの可観測性をコードガイドとして使用する必要があるのですか?

インフラストラクチャ、アプリケーション、サービステクノロジーが進化するにつれて、それらの規模と複雑さが増し、インストルメンテーションツール(New Relicを含む)から収集されるデータの量が増え、データの意味を理解し、コンテキストに取り入れ、アクションを推進することに関連する課題が増えますそれの後ろから。

New Relicの構成を自動化するためのコード方法論としての可観測性の使用は、この課題に対処し、組織が採用を加速し、安定性を向上させ、より良いガバナンスを推進するのに役立ちます。

このガイドでは、コードとしての可観測性の実装に取り組む方法についてのガイダンスを提供し、NewRelicプラットフォームを高速かつ大規模に構築および保守できるようにするための優れた実践アドバイスと参照例を提供します。自動化ワークフローとプロビジョニングツールを活用して、組織が可観測性のベストプラクティスを拡張できるようにすると同時に、手作業を減らし、サービスの提供を改善します。これらのアイデアの実装を成功させると、IT組織自体とそれがサポートするビジネスの両方に真の価値がもたらされるはずです。

期待される成果

急速に変化する大規模な環境で最適に構成された可観測性ソリューションを実装および維持することに関連するコストとリスクを削減します。

具体的には、コードとしての可観測性を採用することの利点のいくつかは次のとおりです。

繰り返し可能、複製可能、再利用可能

コードを介してNewRelicリソースを管理することは、それらを簡単に繰り返し、スケーリングし、一括で更新できることを意味します。 Terraformなどのプロビジョニングツールでモジュラーアプローチを活用すると、ダッシュボード、アラート、ワークロードなどのパッケージ化されたリソースセットをすばやく簡単に共有および展開できるため、起動時間が短縮され、組織全体の標準が向上します。

労力の削減

コードを介して管理されるNewRelicリソースを作成および維持する労力は、特に大規模な作業を行う場合、ユーザーインターフェイスを介して手動で管理するよりも大幅に少なくなります。私たちのインターフェースは発見とテストに適していますが、コード管理されたリソースへの変更を一括適用できるため、リソースの管理にかかる時間を大幅に短縮できます。一般的なアプローチの1つは、ユーザーインターフェイス内でアラートとダッシュボードを開発し、それらが十分に成熟していると見なされたら、コード管理されたリソースに移行することです。

ドキュメントとコンテキスト

New Relicで構成できるリソースは多種多様であるため、単一のリソースを見ると、なぜそのリソースが作成または構成されているのかを理解するのが難しい場合があります。コードを介した構成により、特定の選択が行われた理由、時期、および対象者を説明するのに役立つ、関連するコメントとドキュメントが可能になります。

監査可能な履歴

NRAuditEventイベントを介して誰がNewRelicリソースに変更を加えたかを理解することは可能ですが、これは、変更が行われた理由、以前の状態、または誰が変更を承認したかについての背景をあまり提供しません。自動承認ベースのプロビジョニングワークフローと連携してコードを介してリソースを管理することで、変更の可視性が大幅に向上し、ガバナンスが向上すると同時に、ロールバックとリカバリの方法も提供されます。

セキュリティ

Observability-as-codeを使用すると、NewRelicリソースを管理するためのAPIキーの使用をより厳密に制御できます。流通しているAPIキーの数を減らし、それらの作成と配布に関して適切なガバナンスが実施されていることを確認することで、セキュリティが向上します。特に自動化されたワークフロー内でユーザーが自分のキーを使用することを思いとどまらせることは、キーの侵害や意図しない破損の表面積が減少することを意味します。

効率的なデルタ変更

Terraformのようなプロビジョニングツールを使用すると、既存のリソースにデルタ変更を加えることができます。これにより、リソースの破棄と再作成を最小限に抑えながら、変更が必要なリソース属性のみが変更されるため、更新が迅速かつ効率的になります。これは、ダッシュボードやアラートなどのリソースのGUIDが更新時に変更されないようにするために重要です。

外部刺激に反応する

コードとしての可観測性と自動化されたワークフローを組み合わせることで、アプリケーションの展開、インフラストラクチャイベント、その他のデータ入力などの外部刺激の結果として、NewRelicリソースを作成および修正できます。たとえば、展開時にコードバージョンリリース間で主要なゴールデンシグナルメトリックを比較するダッシュボードとアラートを自動的に生成できます。

コンテキストの所有権とパッケージ化

コードでリソースを管理すると、関連するリソースを一緒に管理できます。ユーザーインターフェイス全体に分散する場合よりも、コード内でそれらを1か所で理解して管理する方が簡単です。たとえば、これにより、さまざまなチームが影響範囲内のリソースを管理、表示、および維持でき、管理するリソースを探す必要がなくなります。

災害からの回復

時折、間違いが発生し、間違ったリソースが更新または削除されます。手動のリソース管理でこれらの状況から回復することは困難です。これは、以前に何が存在したかを知ることは容易ではなく、リソースが変更されたり失われたりした場合でも簡単ではないためです。 Observability-as-codeは、リソースを再作成したり、期待される構成にリセットしたりできるようにすることで、これらの問題から保護するのに役立ちます。また、構成のずれを事前に検出する機会も作成します。

展開の速度

Observability-as-codeは、共通のリソースセットをチーム間で簡単に共有し、可観測性ツールのブートストラップに使用できるようにすることで、展開の速度を加速します。これは、同様のアプリケーション展開アーキテクチャがcookie-cutterモジュールベースのNewRelicリソースの恩恵を受けるマイクロサービスアーキテクチャで特に顕著です。再利用可能な集中管理モジュールを作成すると、可観測性ツールへの一般的なアプローチを標準化するのにも役立ちます。

主要業績評価指標

コードとしての可観測性の展開の成熟度は、さまざまな方法で評価できます。一般に、コードを介して管理される環境内のリソースが多いほど、展開は成熟します。 KPIの一部を次に示します。

前提条件

New Relic使用したコード実装としての可観測性に着手する前に、NewRelicUniversityから入手できる基本事項について理解しておく必要があります。

また、次のことを行う必要があります。

  • Terraformなどのプロビジョニングツールを選択して精通している
  • 自動化ワークフローをサポートするCI/CDプラットフォームにアクセスできます
  • NewRelicプラットフォームとAPI機能に精通している
  • リソースのタグ付けと命名の規則または戦略を決定しました
  • KPIを決定するための資産粒度戦略を決定します
  • CI/CDツールからの変更を適用するためのサービスアカウントAPIキーと権限モデルを準備しました

現在の状態を確立する

コードとしての可観測性の実践に着手する前に、現在の状態を評価する必要があります。上記の成熟度評価の概念を活用して、環境の成熟度を判断し、最初に取り組む環境に優先順位を付けることができます。

改善プロセス

New Relicでコードとしての可観測性を採用することを決定したかもしれませんが、開始方法がわからない場合、または一般的な行き止まりやトラップを避けたい場合があります。ここでは、コードとしての可観測性を自信を持って採用できるように、優れたプラクティス、アドバイス、および参照例に関するガイドを提供します。

チームベースのリソースの分離

多くのチームが、単一のNewRelicアカウントまたは複数のアカウントにわたるリソースの管理に関与している可能性があります。コードとしての可観測性の実践は、リソースの分離、アクセス、および管理をより厳密に制御する方法を提供します。個人への書き込みアクセスを制限し、マネージコードを介して変更を適用することで、チームはお互いのリソースに影響を与えるリスクを冒すことなく、同じスペースで安全に作業できます。

たとえば、それぞれが異なるNewRelicアカウントでアプリケーションを監視する複数のアプリケーションチームに代わってクラウドインフラストラクチャを管理する共有インフラストラクチャチームがあるとします。この共有インフラストラクチャチームは、アプリケーションチーム自身のリソースとともに、これらのアカウント内で独自のNewRelicリソースを管理します。ユーザーの書き込みアクセスを制限し、主要なリソースがコードとしての可観測性ワークフローを介してのみ管理されるようにすることで、チームのリソースが調和して共存し、不正または意図しない変更の可能性を減らすことができます。

Team based resource isolation permission model

この図は、さまざまなチームの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機能を活用して、組み込みの承認およびレビューメカニズムを使用してコードを自動的に計画および適用します。

Example Terraform workflow

この図は、変更がPRとして発生し、PRが承認されてメインにマージされ、リソースの展開がトリガーされる方法を示しています。

ワークフローの実装例

次の参照例は、さまざまなシステムでTerraformワークフローを設定する方法を示しています。

バージョンの固定

observability-as-codeワークフローを介してリソースを自動的にプロビジョニングする場合、ワークフローがすべての実行で同じように実行されるようにすることが重要です。パイプライン障害の原因となる予期しないアップグレードが発生しないように、使用したNewRelicプロバイダーとTerraformのバージョンをバージョン固定することをお勧めします。ピンのバージョンを決定する場合は、定期的に最新バージョンにアップグレードしてテストする必要があります。制約バージョンの詳細については、 Terraformドキュメントをご覧ください。

構成ドリフトの検出

構成のドリフトを理解することは、可観測性プラットフォームの安定性と信頼性を確保するために重要です。アクセス制御とアクセス許可の戦略によっては、ユーザーがコードで管理されているUIのリソースを変更できる場合があります。この構成のずれを検出すると、変更を理解し、必要に応じて構成を修正できます。

動作には主に2つのモードがあります。

  • 検出と通知:このモードでは、ドリフトが検出され、オペレーターに通知されます。ただし、修正の変更は自動的には行われません。
  • 検出、修正、通知:このモードでは、ドリフトが検出され、可能な場合はワークフローによって自動的に修正されます。
Configuration drift workflow

この図は、構成ドリフトワークフローを実装する方法を示しています。検出された変更はNewRelicに報告され、そこでアラートを受け取り、時間の経過とともに追跡できます。

構成ドリフト参照例

このリファレンス例では、GitHubアクションを利用して、通常のTerraformプランの操作をスケジュールします。検出された変更の数はNewRelicに報告され、Terraformの再適用をオプションで開始できます。

Terraform構成のドリフトの例

結論

採用すべきベスト・プラクティス

  • KPIを明確に定義および実装して、コードとしての可観測性の成熟度を測定します。
  • 新しいコードとしての可観測性機能を実装する前に、現在の状態を確立して伝達します。
  • 可能な限り自動化を活用して、環境全体での可観測性の提供を加速します。
  • コードを介して作成されたアセットを自動ドキュメント化します。
  • 構成のドリフトを追跡およびアドレス指定します。
  • 環境全体で資産の拡張再利用を促進します。

価値の実現

このプロセスの最後に、次の利点を理解する必要があります。

  • コードとしての現在の可観測性の成熟度を簡単かつ効果的に伝達します。
  • 環境の可観測性までの時間を短縮します。
  • 可観測性を実装するために必要な手作業を減らし、生産時間を解放します。
  • 実稼働環境でのオペレーショナルリスクを軽減します。
  • 問題をより迅速に検出して解決する機能を向上させます。
  • 新しいリリースを展開する時間を短縮します。
  • テレメトリデータを組織全体にとってより実用的なものにします。
  • サービスの可用性とビジネスへの提供を改善します。
問題を作成する
Copyright © 2022 New Relic Inc.