New Relic と AWS CDK for Terraform を用いた NewsPicks の SLO 監視システムの構築

2025-04-02
デベロッパーのためのクラウド活用方法

Author : 飯野 卓見 (株式会社ユーザベース)

無料クーポン特典の詳細 » 
X ポスト »
 シェア »
 はてブ »

こんにちは。株式会社ユーザベース NewsPicks事業部 SREチームに所属しております飯野と申します。

弊社で運営する NewsPicks は国内最大級の経済ニュースプラットフォームです。さまざまな配信メディアから提供いただいたコンテンツをキュレーションしてお届けするだけではなく、速報性の高いニュースについてはプッシュ通知でユーザーにいち早くお知らせしています。特に重要な経済指標の発表や企業の決算発表、大型 M&A などの速報は、多くのユーザーが同時にアプリを起動する要因となります。

過去にアプリ起動時に利用する API のレイテンシーが悪化したことを検知できず、利用者に不便をかけてしまったことがあります。このような障害の早期発見と迅速な解決を行い、ユーザー体験を守っていくためにも、適切なモニタリングは不可欠です。
そこで、重要なユーザー体験の変化を検知し守っていくための SLO (サービスレベル目標) の構築とモニタリングを開始しました。

本記事では New Relic を使用した SLO 監視システムの構築における工夫や注意点について詳しく紹介します。

ユーザー体験を守るためにサービスレベル目標を定める

NewsPIcks は経済メディアですので「アプリを起動して記事を閲覧する」という一連の操作 (ユーザージャーニー) がストレスなく行えることが非常に重要です。プッシュ通知時など一斉にアプリを起動し、サービスに負荷がかかるタイミングでもこの操作は発生し、この操作が遅くなることがユーザー体験の悪化に直結します。

「アプリを起動してから記事を閲覧する」のように特に重要なユーザージャーニーをクリティカルユーザージャーニーとして定義します。

弊サービスのクリティカルユーザージャーニーの例としては次のようなものがあります。

  • 記事が閲覧できる
  • 動画が閲覧できる
  • サービスの総合トップページが閲覧できる。
  • 記事に対してリアクション (コメントなど) が行える

この記事では「記事が閲覧できる」を例として取り上げ、New Relic での SLO の設定とアラート通知設定を行います。

サービスレベル目標の設定

クリティカルユーザージャー二ーで利用する API エンドポイント に対して SLO を作成します。

「記事が閲覧できる」で利用する API エンドポイントは New Relic では次の TransactionName※ で参照できます。

WebTransaction/SpringController/news/{news} (GET)

※TransactionName は利用しているシステムの言語やフレームワークによって異なります。適時読み替えていただければと思います。

SLI (サービスレベル指標) としては可用性とレイテンシーを利用し、それぞれ目標を定めます。今回は次の目標を設定します。

期間

カテゴリ

SLI

SLO のターゲット

28

可用性

記事が閲覧できること => エラーが発生しないこと

99.9%

28

レイテンシー

レイテンシーが 300ms 以内であること

95%

この目標はサービスの進化とともに変化していきます。SLO のメンテナンスを容易にするため、AWS Cloud Development Kit for Terraform (CDK for Teraform) を利用して IaC 管理で SLO の構築を行います。

概要

今回構築したシステムの全体像です。

本題 (解説、手順)

1. APM Event を送信するための newrelic-agent の導入

New Relic に蓄積した APM Events をもとに SLO を構築していくため、事前に New Relic Agent の導入が必要です。各種ドキュメントにそって導入をお願いします。

2. CDK for Terraform を利用するための準備

弊社では AWS のリソースの IaC 管理のツールとして AWS Cloud Development Kit (AWS CDK) を全面的に採用しています。この AWS CDK での経験を生かすために、同じ使い勝手を得られる CDK for Terraform (以下cdktf) で New Relic Provider を利用して SLO を構築しています。

cdktf のリモートバックエンドには AWS を利用します。cdktf で生成する SLO とはライブライクルが異なるため専用スタックで作成すると良いでしょう。必要なリソースは次の二つです。

AWS をリモートバックエンドとして利用するために必要なリソースを AWS CDK で定義する

// Terrafrom S3 Backendが利用するリソースを定義する
// SLOを定義するCDK for Terraformのスタックとはライフライクルが異なるため、
// 別スタックとして定義すると良い。

// tfstateの更新の排他制御を行うロックテーブル
new dynamodb.Table(scope, "StateLockTable", {
    partitionKey: {
        name: "LockID",
        type: dynamodb.AttributeType.STRING,
    },
    billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
    removalPolicy: RemovalPolicy.RETAIN,
});

// tfstateを保存するためのS3バケット
new s3.Bucket(scope, "StatesBucket", {
    versioned: true,
    removalPolicy: RemovalPolicy.RETAIN,
    publicReadAccess: false,
    blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
    encryption: s3.BucketEncryption.S3_MANAGED,
});

cdktf の TerraformStack から Amazon S3 Backend を作成することで参照することができます。

TerrafromStack リモートバックエンドとして Amazon S3 Backend を指定する
(TerraformState (tfstate) の保存先として S3 バケット、tfstate の更新の排他制御として Amazon DynamoDB テーブルを利用する)

import { S3Backend, TerraformStack } from "cdktf";

const stack: TerraformStack; // SLOを定義するTerrafromStack

const bucketName = "your-terrform-state-bucket-name"; // S3バケットのバケット名
const tfStateKey = "your-stack-name.tfstate"; // TerraformStackのtftateを保存するS3 Object Key
const dynamodbTableNam = "your-terrafrom-state-lock-table-name"; // tfstate更新の排他制御を行うDynamoDBテーブルのテーブル名
const awsRegion: "your-aws-region"; // S3バケット、DynamoDBテーブルが存在するAWSリージョン

// stackのtfstateを保存するリモートバックエンドとしてS3Backendを指定する
new S3Backend(stack, {
    bucket: bucketName,
    key: tfStateKey,
    dynamodbTable: dynamodbTableName;
    region: awsRegion,
});

New Relic のリソースの操作を行うために New Relic Provider を初期化します。

Terraform の NewrelicProvider を初期化する。

import { NewrelicProvider } from "@cdktf/provider-newrelic/lib/provider";

const newrelicAccountId: string; // New RelicのAccount ID
const newrelicApiKey: string;    // New RelicのAPI Key
const newrelicRegion: string;    // New RelicのRegion。"US", "EU"

// NewrelicProvicerの初期化
new NewrelicProvider(scope, "newrelic", {
    accountId: newrelicAccountId,
    apiKey: newrelicApiKey,
    region: newrelicRegion,
});

最後に New Relic の APM (アプリケーションパフォーマンス監視) Entity への参照を作成します。これは ServiceLevel の作成時に利用します。

APM Entity への参照を作成する。

import { DataNewrelicEntity } from "@cdktf/provider-newrelic/lib/data-newrelic-entity";

const name: string; // New RelicのAPM Entity名
const entity = new DataNewrelicEntity(scope, "api-entity", { name });

これで準備が整いました。

3. API エンドポイントごとの ServiceLevel を作成する

New Relic では SLO は ServiceLevel というリソースで表現されます。

画像をクリックすると拡大します

可用性の ServiceLevel の定義を示します。

endpoint-availability-service-level.ts を見る

import { DataNewrelicEntity } from "@cdktf/provider-newrelic/lib/data-newrelic-entity";
import { ServiceLevel } from "@cdktf/provider-newrelic/lib/service-level";
import { Construct } from "constructs";
import * as SqlString from "sqlstring";

export interface EndpointAvailabilityServiceLevelProps {
    entity: DataNewrelicEntity;
    name: string;
    description?: string;
    objectiveTarget: number;
    transactionName: string;
}

export class EndpointAvailabilityServiceLevel extends Construct {
    readonly serviceLevel: ServiceLevel;

    constructor(scope: Construct, id: string, props: EndpointAvailabilityServiceLevelProps) {
        super(scope, id);

        const { entity, name, description, objectiveTarget, transactionName } = props;

        this.serviceLevel = new ServiceLevel(this, "Default", {
            guid: entity.guid,
            name,
            description,
            events: {
                accountId: entity.accountId,
                validEvents: { // 可用性測定の母集団となるイベントを絞り込むクエリ
                    from: "Transaction",
                    where: [ // EntityとTransactionNameを絞り込み条件とします。
                        SqlString.format("entityGuid = ?", [entity.guid]),
                        SqlString.format("name = ?", [transactionName]),
                    ].join(" AND "),
                },
                badEvents: { // 可用性測定の不正なイベントを絞り込むクエリ
                    from: "TransactionError", // エラーが記録されているTransactionErrorを利用します。
                    where: [ // EntityとTransactionName、予期せぬエラーであることをを絞り込み条件とします。
                        SqlString.format("entityGuid = ?", [entity.guid]),
                        SqlString.format("transactionName = ?", [transactionName]),
                        "error.expected IS FALSE", // 予期せぬエラー
                    ].join(" AND "),
                },
            },
            objective: {
	              target: objectiveTarget, // SLO目標のターゲット
                timeWindow: {
                    // 今回作成するSLOでは期間を最大の28日で定義します。
                    rolling: { count: 28, unit: "DAY" }, 
                },
            },
        });
    }
}

レイテンシーの ServiceLevel の定義を示します。

endpoint-latency-service-level.ts を見る

import { DataNewrelicEntity } from "@cdktf/provider-newrelic/lib/data-newrelic-entity";
import { ServiceLevel } from "@cdktf/provider-newrelic/lib/service-level";
import { Construct } from "constructs";
import * as SqlString from "sqlstring";

export interface EndpointLatencyServiceLevelProps {
    entity: DataNewrelicEntity;
    name: string;
    description?: string;
    objectiveTarget: number;
    duration: number;
    transactionName: string;
}

export class EndpointLatencyServiceLevel extends Construct {
    readonly serviceLevel: ServiceLevel;

    constructor(scope: Construct, id: string, props: EndpointLatencyServiceLevelProps) {
        super(scope, id);

        const { entity, name, description, objectiveTarget, duration, transactionName } = props;

        this.serviceLevel = new ServiceLevel(this, "Default", {
            guid: entity.guid,
            name,
            description,
            events: {
                accountId: entity.accountId,
                validEvents: { // レイテンシー測定の母集団となるイベントを絞り込むクエリ
                    from: "Transaction",
                    where: [ // EntityとTransactionNameを絞り込み条件とします。
                        SqlString.format("entityGuid = ?", [entity.guid]),
                        SqlString.format("name = ?", [transactionName]),
                    ].join(" AND "),
                },
                goodEvents: { // レイテンシー測定の適切なイベントを絞り込むクエリ
                    from: "Transaction",
                    where:  [ // EntityとTransactionName、応答時間が指定された値未満であることを絞り込み条件とします。
                        SqlString.format("entityGuid = ?", [entity.guid]),
                        SqlString.format("name = ?", [transactionName]),
                        SqlString.format("duration <= ?", [duration]),
                    ].join(" AND "),
                },
            },
            objective: {
	              target: objectiveTarget, // SLO目標のターゲット
                timeWindow: {
                   // 今回作成するSLOでは期間を最大の28日で定義します。
                   rolling: { count: 28, unit: "DAY" },
                },
            },
        });
    }
}

「記事が閲覧できる」の Transaction 名と SLO は次のとおりです。

  • Transaction名 : WebTransaction/SpringController/news/{news} (GET)

  • SLO

期間

カテゴリ

SLI

SLOのターゲット

28

可用性

記事が閲覧できること＝＞エラーが発生しないこと

99.9%

28

レイテンシー

レイテンシーが 300ms以内であること

95%

この定義をもとに可用性とレイテンシーの ServiceLevel を作成します。

可用性とレイテンシーの SLO を作成する

const entity: DataNewrelicEntity;

const endpointAvailabilityServiceLevel = new EndpointAvailabilityServiceLevel(
    scope,
    "news-endpoint-availability-service-level",
    {
        entity,
        name: "/news/{news} (GET) Availability",
        objectiveTarget: "99.9",
        transactionName: "WebTransaction/SpringController/news/{news} (GET)",
    },
);

const endpointAvailabilityServiceLevel = new EndpointLatencyServiceLevel(
    scope,
    "news-endpoint-latency-service-level",
    {
        entity,
        name: "/news/{news} (GET) Latency",
        objectiveTarget: "95",
        duration: "0.3", // 単位は秒
        transactionName: "WebTransaction/SpringController/news/{news} (GET)"
    }
);

これで New Relic での SLO 作成が行えました。

4. SLO 違反を検知するための AlertPolicy と AlertCondition を作成する

次は SLO 違反を検知するための設定を作成します。

画像をクリックすると拡大します

プッシュ通知時など、定常的に発生する負荷の変化でのご検知を回避するためバーンレートアラートを作成します。NewsPicks では Google が提唱する 1 時間で 2% のエラーバジェット消費をベストプラクティスとして採用し、バーンレートアラートを作成しています。

SLO 目標に応じてバーンレートアラートで利用する閾値は変化するため、計算のためのヘルパークラスを用意します。

burn-rate.ts を見る

import { ServiceLevel } from "@cdktf/provider-newrelic/lib/service-level";

// Googleは1時間で2%のSLOエラーバジェット消費についてアラートを出すことを推奨している
// https://sre.google/workbook/alerting-on-slos/
const GOOGLE_RECOMMENDED_ERROR_BUDGET_CONSUMPTION_RATE = 0.02;

// ServiceLevelからバーンレートアラートの閾値を求めるクラス
export class BurnRate {
    readonly serviceLevel: ServiceLevel;
    readonly errorBudgetConsumptionRate: number;

    constructor(
        serviceLevel: ServiceLevel,
        errorBudgetConsumptionRate = GOOGLE_RECOMMENDED_ERROR_BUDGET_CONSUMPTION_RATE,
    ) {
        this.serviceLevel = serviceLevel;
        this.errorBudgetConsumptionRate = errorBudgetConsumptionRate;
    }

    // ServiceLevelのバーンレート
    get burnRate(): number {
        const timeWindowDays =
            this.serviceLevel.objectiveInput?.timeWindow.rolling.count ?? { count: 28, unit: "DAY" }.count;
        const timeWindowHours = timeWindowDays * 24;
        const alertWindowHours = 1.0;
        return (this.errorBudgetConsumptionRate * timeWindowHours) / alertWindowHours;
    }

    // バーンレートアラート用の閾値
    get threshold(): number {
        if (this.serviceLevel.objectiveInput?.target == undefined) {
            throw Error(`ServiceLevel: ${this.serviceLevel.nameInput}のSLOターゲットが設定されていません。`);
        }
        const target = this.serviceLevel.objectiveInput?.target;
        const errorRate = 1.0 - target / 100.0;
        // アラート閾値。単位は%なので100倍する
        const threshold = errorRate * this.burnRate * 100;
        return threshold > 100 ? 100 : threshold;
    }

    static get googleRecommendedErrorBudgetConsumptionRate(): number {
        return GOOGLE_RECOMMENDED_ERROR_BUDGET_CONSUMPTION_RATE;
    }
}

可用性に対するバーンレートアラートの条件を作成します。可用性はサービス提供に影響するため critical として作成します。

availability-nrql-alert-condtion.ts を見る

import { AlertPolicy } from "@cdktf/provider-newrelic/lib/alert-policy";
import { NrqlAlertCondition } from "@cdktf/provider-newrelic/lib/nrql-alert-condition";
import { ServiceLevel } from "@cdktf/provider-newrelic/lib/service-level";
import { Fn } from "cdktf";
import { Construct } from "constructs";
import * as SqlString from "sqlstring";

import { BurnRate } from "./burn-rate";

interface AvailabilityNrqlAlertConditionProps {
    readonly alertPolicy: AlertPolicy;
    readonly serviceLevel: ServiceLevel;
    readonly name: string;
    readonly description?: string;
}

export class AvailabilityNrqlAlertCondition extends Construct {
    readonly alertCondition: NrqlAlertCondition;

    public constructor(scope: Construct, id: string, props: AvailabilityNrqlAlertConditionProps) {
        super(scope, id);
        
        const { alertPolicy, serviceLevel, name, description } = props;

        const query = SqlString.format(
            [
                "FROM Metric",
                "SELECT",
                "  100 - clamp_max((sum(newrelic.sli.valid) - sum(newrelic.sli.bad)) / sum(newrelic.sli.valid) * 100, 100) as 'Error Rate'",
                "WHERE sli.guid = ?",
            ].join(" "),
            [serviceLevel.sliGuid],
        );

        this.alertCondition = new NrqlAlertCondition(this, "Default", {
            // Workaround: https://github.com/cdktf/cdktf-provider-newrelic/issues/972
            policyId: Fn.tonumber(alertPolicy.id),
            name,
            description,
            type: "static",
            nrql: { query },
            critical: {
                operator: "ABOVE",
                threshold: new BurnRate(serviceLevel).threshold,
                thresholdDuration: 60,
                thresholdOccurrences: "AT_LEAST_ONCE",
            },
            aggregationWindow: 3600,
            slideBy: 60,
            // null可だがnullの場合、常に差分が出るためデフォルト値を指定する
            violationTimeLimitSeconds: 259200,
        });
    }
}

レイテンシーに対するバーンレートアラートの条件を作成します。こちらは可用性ほど緊急度は高くないため warning として作成します。

latency-nrql-alert-condtion.ts を見る

import { AlertPolicy } from "@cdktf/provider-newrelic/lib/alert-policy";
import { NrqlAlertCondition } from "@cdktf/provider-newrelic/lib/nrql-alert-condition";
import { ServiceLevel } from "@cdktf/provider-newrelic/lib/service-level";
import { Fn } from "cdktf";
import { Construct } from "constructs";
import * as SqlString from "sqlstring";

import { BurnRate } from "./burn-rate";

interface AvailabilityNrqlAlertConditionProps {
    readonly alertPolicy: AlertPolicy;
    readonly serviceLevel: ServiceLevel;
    readonly name: string;
    readonly description?: string;
}

export class AvailabilityNrqlAlertCondition extends Construct {
    readonly alertCondition: NrqlAlertCondition;

    public constructor(scope: Construct, id: string, props: AvailabilityNrqlAlertConditionProps) {
        super(scope, id);
        
        const { alertPolicy, serviceLevel, name, description } = props;

        const query = SqlString.format(
            [
                "FROM Metric",
                "SELECT",
                "  100 - clamp_max((sum(newrelic.sli.valid) - sum(newrelic.sli.bad)) / sum(newrelic.sli.valid) * 100, 100) as 'Error Rate'",
                "WHERE sli.guid = ?",
            ].join(" "),
            [serviceLevel.sliGuid],
        );

        this.alertCondition = new NrqlAlertCondition(this, "Default", {
            // Workaround: https://github.com/cdktf/cdktf-provider-newrelic/issues/972
            policyId: Fn.tonumber(alertPolicy.id),
            name,
            description,
            type: "static",
            nrql: { query },
            critical: {
                operator: "ABOVE",
                threshold: new BurnRate(serviceLevel).threshold,
                thresholdDuration: 60,
                thresholdOccurrences: "AT_LEAST_ONCE",
            },
            aggregationWindow: 3600,
            slideBy: 60,
            // null可だがnullの場合、常に差分が出るためデフォルト値を指定する
            violationTimeLimitSeconds: 259200,
        });
    }
}

作成したバーンレートアラートの条件をサービスレベルに適用します。

// アラートポリシーを作成
const alertPolicy = new AlertPolicy(scope, "alert-policy", {
    name: "SLO violation",
    incidentPreference: "PER_CONDITION", // アラート条件ごとにIssue
});

const endpointAvailabilityServiceLevel: EndpointAvailabilityServiceLevel; // 可用性のSLO
// 可用性に対するアラート条件を作成
new AvailabilityNrqlAlertCondition(scope, 'availability-alert-condition', {
  alertPolicy,
  serviceLevel: endpointAvailabilityServiceLevel.serviceLevel,
  name: 'availability burn rate alert condition'
});

const endpointLatencyServiceLevel: EndpointLatencyServiceLevel; // レイテンシーのSLO
// レイテンシーに対するアラート条件を作成
new LatencyNrqlAlertCondition(scope, 'latency-alert-condition', {
  alertPolicy,
  serviceLevel: endpointLatencyServiceLevel.serviceLevel,
  name: 'latency burn rate alert condition'
});

これらのリソースにより、SLO 違反が継続しエラーバジェット消費が一定以上になると New Relic に Issue が作成されるようになります。

5. 通知設定を作成する

SLO 違反を New Relic で検知できるようになったので、その内容を Slack に通知します。

画像をクリックすると拡大します

通知を行う場合は NotificationChannel という通知先を表すリソースを作成します。Slack 用のサブクラスを定義すると良いでしょう。

slack-notification-channel.ts を見る

import { NotificationChannel, NotificationChannelConfig } from "@cdktf/provider-newrelic/lib/notification-channel";
import { Construct } from "constructs";

export interface SlackNotificationChannelConfig
    extends Omit<NotificationChannelConfig, "type" | "product"> {
    readonly channelId: string;
}

// 通知先（Slack）
export class SlackNotificationChannel extends NotificationChannel {
    public constructor(scope: Construct, id: string, props: SlackNotificationChannelConfig) {
        super(scope, id, {
            ...props,
            type: "SLACK",
            product: "IINT",
            property: [{ key: "channelId", value: props.channelId }, ...props.property],
        });
    }
}

発生した Issue と通知先の紐付けは Workflowで 行います。Workflow の issueFilter を利用することで対象となる Issue を選択できます。Issue に設定されたタグをもとに一つの Issue を複数の通知先に通知するための仕組みを作成します。

contextual-notification-workflow.ts を見る

import { AlertPolicy } from "@cdktf/provider-newrelic/lib/alert-policy";
import { NotificationChannel } from "@cdktf/provider-newrelic/lib/notification-channel";
import { Workflow } from "@cdktf/provider-newrelic/lib/workflow";
import { Construct } from "constructs";

export interface ContextualNotificationWorkflowProps {
    name: string;
    alertPolicy: AlertPolicy;
    destination: {
        notificationChannel: NotificationChannel;
        notificationContext: string;
    };
    enabled: boolean;
}

// https://docs.newrelic.com/docs/alerts-applied-intelligence/applied-intelligence/incident-workflows/incident-workflows/
export class ContextualNotificationWorkflow extends Construct {
    readonly workflow: Workflow;
    public constructor(scope: Construct, id: string, props: ContextualNotificationWorkflowProps) {
        super(scope, id);
        
        const { name, alertPolicy, destination: {notificationChannel, notificationContext}, enabled } = props;

        this.workflow = new Workflow(this, "Default", {
            name,
            issuesFilter: {
                name: "filter by notificationContext",
                type: "FILTER",
                predicate: [
                    // IaCで作成したAlertConditionに限定する。(IssueにはAlertConditionのPolicyIDが反映される)
                    {
                        attribute: "accumulations.tag.policyId",
                        operator: "EXACTLY_MATCHES",
                        values: [alertPolicy.id],
                    },
                    // 同じ通知先が含まれているのIssueに限定する。(IssueにはAlertConditionのTagが反映される)
                    {
                        attribute: "accumulations.tag.notificationContext",
                        operator: "CONTAINS",
                        // 同名のタグが複数存在する場合、値はカンマ区切りで連結された文字列となる。
                        // ()で囲んだ値を設定することでCONTAINSでフィルター可能にしいている。
                        values: [`(${notificationContext})`],
                    },
                ],
            },
            // MutingRuleでミュートされている場合は通知を行わない
            mutingRulesHandling: "DONT_NOTIFY_FULLY_OR_PARTIALLY_MUTED_ISSUES",
            // 通知先
            destination: [{ channelId: notificationChannel.id }],
            // 有効か
            enabled,
        });
    }
}

通知先を作成します。 alert , warn , slo-alert (debug 用) の 3 種類の通知先を定義します。

ソースコードを見る

interface ContextualNotificationConfig {
    slackChannel: { id: string, name: string };
    context: string;
}

const contextualNotificationConfigs: ContextualNotificationConfig[] = [
    {
        slackChannel: { id: "xxxx", name: "xxx-alert" },
        context: "alert",
    },
    {
        slackChannel: { id: "yyyy", name: "xxx-warn" },
        context: "warn",
    },
        {
        slackChannel: { id: "yyyy", name: "xxx-slo-alert" },
        context: "slo-alert",
    },
];
const slackDestinationId: string; // New RelicのSlack Workspace接続設定のID
const alertPolicy: AlertPolicy;

for (const config of contextualNotificationConfigs) {
    // 通知先（Slackチャンネル）を作成する
    const notificationChannel = new SlackNotificationChannel(this, `${config.slackChannel.name}-slack-notification-channel`, {
        channelId: config.slackChannel.id,
        destinationId: slackDestinationId,
        name: `Slack: ${config.slackChannel.name} Notification Channel`,
    });

    // New Relic Isusue(SLO違反で作成される)の通知設定
    new ContextualNotificationWorkflow(this, `${config.context}-contextual-slack-channel-workflow`, {
        name: `Context: ${config.context} Notification (Slack: ${config.slackChannel.name})`,
        alertPolicy,
        destination: {
            notificationChannel,
            notificationContext: config.context,
        },
        enabled: true,
    });
}

6. SLO 違反に通知先を設定する

最後に SLO 違反の通知先を設定します。SLO 違反の結果作成される Issue には AlertCondition のタグが反映されます。AlertCondition 側にタグを設定することで通知先の設定が行えます。

ソースコードを見る

const availabilityNrqlAlertCondition: AvailabilityNrqlAlertCondition;
// 可用性のアラート条件にタグを設定する。alert, slo-alertのチャンネルにcriticalとして通知される
new EntityTags(this, "availability-alert-condition-tags", {
    guid: availabilityNrqlAlertCondition.alertCondition.entityGuid,
    tag: [
        // Issueにコピーされると "(alert),(slo-alert)"となる。
        { key: "notificationContext", values: ["(alert)", "(slo-alert)"] }
    ],
});

const latencyNrqlAlertCondition: LatencyNrqlAlertCondition;
// latencyのアラート条件にタグを設定する。warn, slo-alertのチャンネルにwarningとして通知される
new EntityTags(this, "latency-alert-condition-tags", {
    guid: latencyNrqlAlertCondition.alertCondition.entityGuid,
    tag: [
        // Issueにコピーされると "(warn),(slo-alert)"となる。
        { key: "notificationContext", values: ["(warn)", "(slo-alert)"] }
    ],
});

まとめ

CDK for Terraform を利用した New Relic での SLO 構築について紹介しました。

弊社では AWS CDK をすでに採用していたため、同じ概念とライブラリを活用している CDK for Terraform を選択することができました。リモートバックエンドとして Amazon S3 を利用することで追加のインフラコストなしで Terraform の導入も行えました。

今回の SLO は SRE チームで作成したのですが、他チームの開発者からも AWS CDK と同じ感覚で改善が行えると好評です。

IaC での SLO 管理を始めて 2 年になり、当初 10 個ほどだった API エンドポイントも現在では 150 を超えています。複数のチームからの API エンドポイントの追加、削除、SLO 調整のコントリビューションがあり、民主化が進んでいます。SLO の調整や SLO モニタリングの仕組み化が進み、複数回ユーザー体験悪化の防止 (早期発見) が行えました。この成功体験により開発者の性能に関する意識も高まり、コミュニケーションが活発化しています。

また、SLO を運用する中で次のような問題に遭遇しました。AutoScaling の設定により容易にサービスのスケールアウトが行えますが、オブザーバビリティツールへのメトリクス送信量も比例して増えるため、転送量に注意が必要です。

過去に、一つのコンテナに複数のアプリケーションを同居させて動かしていたECSタスクをアプリケーションごとのコンテナに分割したのち、スケールアウトさせてしまったことがありました。このときメトリクス送信のサンプリング数を調整していなかったため、分割した倍数のメトリクスが送信されてしまい、契約したデータ転送量を大幅に超えてしまうという問題が発生しました。単位サンプリング期間あたりのサンプリング数は設定ファイルや環境変数で変更できます。アプリケーションの実行単位やAutoScalingの設定を変更した際は必ず見直しましょう。

APM (アプリケーションパフォーマンス監視) から SLO を作成する場合、アプリケーションより手前で発生するエラー (Web アプリケーションファイアウォール での Block や Application Load Balancer でのエラー) は SLO の集計の母数から除外されます。Amazon ECS の OutOfMemoryError などでコンテナが停止された場合、Elastic Load Balancing では 502/504 が記録されますが、APM ではメトリクスは送信できないため検知できず、結果として可用性のSLO 違反は発生しません。CloudWatch AlarmでELBのターゲットグループのメトリクス（HealthyHostCountやTargetConnectionErrorCountなど）も合わせて監視すると良いでしょう。

SLO だけに頼らず、問題に応じた監視を併用していくことも重要です。

builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

メンバー特典を受け取る » 

筆者プロフィール

飯野 卓見 (いいの たくみ)
株式会社ユーザベース NewsPicks事業部 SREチーム

2023 年に株式会社ユーザベースに入社。
NewsPicks では、性能改善と安定性向上に取り組みながら、技術スタックのモダン化、DX 改善、コスト削減を通じて、サービスの今と未来を作っている。
実益を兼ねた趣味は依存関係の更新。庭いじり感覚で楽しんでいる。

X ポスト »
 シェア »
 はてブ »

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する