こんにちは。New Relic技術担当の井上です。
この記事では実際にNew Relicを使う前の導入ステップとして、New Relicアカウントの基本構造について解説していきます。アカウントを管理していく上で、必要となる前提知識のため、ユーザ作成する前に知識を深める一助になれば幸いです。
はじめに
New Relicでアカウントを作成する前に、運用目的・組織構成・セキュリティなど、複数の観点から整理することが必要です。やみくもにアカウントを作成した後、運用を変更したいと思ってもなかなか難しいと思います。まずは、New Relicのアカウントの構造を確認後、それぞれどのように使い分けしたらよいかを解説していきます。
アカウントの全体像
New Relicのアカウントを設定する上で3つの要素があります。APIキーについては別の記事にて解説します。
| 項目 | 説明 |
| 組織(Organization) | New Relic の顧客単位。1契約につき1つの組織が払い出される。 |
| アカウント(Account) | 環境ごとにアクセスを分離、プロジェクトごとにデータを分けたいなど、組織に属するデータの集まりを管理する単位。1組織に複数アカウントを持つことが可能。アカウントは7桁の数字を指します。 |
| ユーザー(User) | New Relicコンソールを操作する人。ロールとユーザータイプを組み合わせて、柔軟に権限のコントロールが可能。ユーザーは1つ以上のグループに所属する必要があります。 |
アカウントとユーザーの意味が混乱しそうですが、アカウントはシステムの箱、ユーザーは使う人と置き換えてとらえることが良いかもしれませんね。
組織(Organization)
New Relicに初回サインアップした後に、自動的に作成されます。組織単位の中で、アカウントの作成やユーザーの作成を行うことになります。New Relicに対する契約を分割したい場合、別のOrganizationを作成する必要があります。
アカウント(Account)
New Relicに初回サインアップと同時にデフォルトで1つ作成されます。環境やプロジェクトに応じて、複数アカウントを作成することができますが、運用の複雑化や共有の制限も伴うため、構成は目的に応じて選ぶ必要があります。ただし、無料枠での利用の場合は、デフォルトで作成された1つのアカウントのみ利用可能です。下の表はアカウントを分けることのメリット・デメリットをまとめた一例になります。
| 項目 | メリット | デメリット |
| データ分離 | 環境（本番・開発）ごとにデータを明確に分離できる | 統合的な可視化が難しくなる（ダッシュボードやトレースの横断が不可） |
| アクセス制御 | 役割ごとにアカウント単位で権限を細かく設定できる | ユーザー管理が複雑化（グループ・ロール・アカウントアクセスの調整が必要） |
| セキュリティ | アカウント単位でアクセス制限をかけることで、情報漏洩リスクを軽減できる | アラートやダッシュボードなどの共有ができず、再設定が必要になる |
| 契約管理 | データ量の管理をアカウント単位で把握しやすくなる | 実際の契約は組織単位なので、有償ユーザー数やデータ量の合算管理が必要 |
ユーザー(User)
New Relicのコンソールの操作には、ロールとユーザータイプの2つがそろって初めて操作することができます。ここの設定を誤ると予期しない操作ができてしまったり、課金に関わる部分もあるため、注意が必要です。それぞれ解説していきます。
ロール
ロールは、操作権限を意味します。ダッシュボードを作成できる、アラートを設定できる、ユーザーを管理できるなどを決める操作権限を指し、グループに割り当てをします。初期設定で用意されているロールは以下になります。
| ロール名 | 説明 |
| All Product Admin | 組織全体の設定、ユーザー管理、請求情報など、すべての管理機能にアクセス可能。 |
| Standard User | データの閲覧・ダッシュボードの作成・アラート設定などが可能。ただし、ユーザー管理や請求情報にはアクセス不可。 |
| Read Only | データの閲覧のみ可能。設定変更やアラート作成などは不可。 |
| Billing Manager | 請求情報の閲覧・管理が可能。その他の機能にはアクセス不可。 |
ユーザータイプ
ユーザータイプは、機能アクセスできる範囲を制御します。APMやInfrastructureなどのNew Relicの機能そのものを決めるアクセス権限でユーザーごとに割り当てをします。New Relicはユーザー数課金とデータ従量課金で構成されています。ユーザー数課金対象のユーザータイプはCoreとFull Platformユーザーの数となります。
| ユーザータイプ | 権限の概要 | 有償アカウント |
| Basic
マネジメント層向け オペレータ (アラートとログの確認のみの運用者) |
ダッシュボードの閲覧、アラートの確認、ログの確認 | ー |
| Core
調査・修正だけを業務とする開発者 |
Basicの機能に加え、Errors Inbox（エラー集約）、ログ管理UI
※機能が限定的のため、利用非推奨 |
〇 |
| Full Platform
サービス品質に責任のある開発者・運用者 (SRE/Ops) |
全機能にアクセス可能 | 〇 |
Adminロールを持っていても、Basicユーザーであれば、APMなどの機能にアクセスできません。逆にFull Platform Userであっても、Read Onlyロールしか持っていなければ、Read Onlyロールでアクセス許可されている画面しか閲覧できません。
参考：ユーザータイプ：ベーシックユーザー、コアユーザー、フルプラットフォーム ユーザー | New Relic Documentation
グループ設定
ロールはグループに割り当てる必要があります。直接ロールをユーザーに割り当てることはできません。ユーザーは、1つ以上のグループに所属することで、グループに割り当てられたロール（権限）とユーザータイプを通じて、New Relicの機能にアクセスできます。ユーザーが複数のグループに所属している場合、各グループに割り当てられたロールの権限がすべて合算されます。アカウントの管理の観点から、1つのグループに1つのロールが望ましいと考えます。
サードパーティ製品と連携する場合のアカウントの考え方
サードパーティ製品との連携(例：AWSやAzure、PagerDuty等)には、専用のユーザーを作成することが推奨されています。必要な権限のみを割り当てることでセキュリティリスクを低減させます。
サードパーティ製品との連携には、APIキーと呼ばれる鍵が必要です。このAPIキーは、発行したユーザーのアカウント権限を継承します。例えば、管理者権限を持つユーザーがAPIキーを発行した場合、そのキーは設定変更やユーザー追加など、管理者レベルの操作が可能になります。そのため、サードパーティ製品との連携に使用するAPIキーは、必要最小限の権限を持つ専用のユーザーから発行することが望ましいとされています。クラウドサービスなどからメトリクス取得のみであれば読み取り専用のみを持つユーザー、アラートを外部連携(PagerDuty,Servicenow等)であれば、書き取り権限を持つユーザーから作成する使い分けが必要になります。
アカウント設計を考える
ここまでで、New Relicのアカウント構造について解説していきました。では、実際にアカウント設計をしていく上で、「組織」、「アカウント」、「ユーザー」の観点でどのように設計を進めたらよいかをまとめてみました。下記がすべてではないので、例として記載しています。
| 観点 | 考慮要素 | 作成する(分ける)かどうかの検討ポイント |
| 組織 | 組織構造 | 部門や担当ごとの分離が必要か？ |
| 請求管理 | アカウントごとに請求を分けたいか？ | |
| アカウント | 環境分離 | 開発・ステージング・本番など、運用・デプロイのために環境を分ける必要があるか？ |
| プロジェクト分離 | サービスやアプリなど、全くかかわらない異なるチーム・目的で運用されるか？ | |
| アラート制限 | 数千件のアラート設定が必要か？(アカウントごとに上限があるため) | |
| ユーザー | 権限管理 | 管理者・運用担当者・開発者などの役割分担が必要か(グループ・カスタムロール作成要否) |
| インテグレーション | AWSやSlack、PagerDutyなどとの連携に使うか？ | |
| アクセス範囲 | 最小権限の原則に則り、アクセスさせるか？(カスタムロールの作成要否) |
さいごに
New Relicのアカウント構成や、コンソールにアクセスする際に必要となる権限について、概要を解説しました。アカウント構成は、組織の運用形態や監視対象の規模に応じて設計することが重要です。また、ユーザー権限の設計においては、最小権限の原則を意識することで、不要な操作や情報漏洩のリスクを低減できます。この記事が、New Relicの安全かつ効率的な運用に少しでもお役立ていただければ幸いです。
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。
