予測スケーリングと異常検知にKinsta APIを活用する方法

リソースの管理は、サイトのパフォーマンスと安定性の最適化に欠かせません。WordPressサイトでは、トラフィックの急増に対応し、必要に応じてリソースを拡張して、パフォーマンスの異常を素早く検知できることが重要です。

Kinsta APIには、予測スケーリングと異常検知に役立ついくつかのエンドポイントがあります。

そこで今回は、リソースの予測スケーリングと異常検知とは何か、Kinsta APIをどのように活用することができるかをご紹介します。具体的なシナリオを想定し、APIの機能を検証して、ワークフローに統合する方法を見ていきます。

予測スケーリングと異常検知

Kinsta APIの機能については後ほど掘り下げますが、まずは予測スケーリングの必要性やサイトパフォーマンスの異常を検知する利点をご説明します。

予測スケーリングの利点

予測スケーリングとは、予測される需要に基づいてサイトのリソースを管理する技術で、データの分析、使用パターンの精査、その他の関連する要因を含むプロアクティブなアプローチが特徴です。

サイトのトラフィックやリソースの消費量が増加するタイミングを予測することで、需要に応じたスケーリングを実現します。その結果、パフォーマンスが最適化され、全体的なユーザーエクスペリエンス（UX）を改善することができます。

具体的には、以下のような利点があります。

1. サイトパフォーマンスの向上─リソースを拡張することでパフォーマンスのボトルネックを防ぎ、トラフィックの急増時にもサイトの応答性を維持することができる。
2. 費用の最適化─より効率的にリソースを割り当て、リソースを過剰にプロビジョニングすることがなくなるため、不要な費用を削減できる。
3. ユーザーエクスペリエンスの改善─トラフィックの急増が緩和されることでサイトの負荷が軽減され、一貫性のあるスムーズで迅速なフロントエンド体験を提供できる。

そして予測スケーリングにサーバーのパフォーマンス異常を検知する機能を組み合わせると、より効果的です。

異常検知の利点

スケーリング戦略とよく密接に関連する側面として、サイトのパフォーマンス測定指標における異常の検知が挙げられます。CPU使用率、メモリ消費量、および応答時間には基準値と極端な異常値が存在し、これらが問題の原因になったり、最適化の機会になったりする可能性があります。

この異常を早期に検出することで、潜在的な問題がサイトの可用性とUXに影響を与え、深刻な問題になる前に対処することができます。他にも以下のような利点があります。

• プロアクティブな問題解決─速やかに問題を深刻になる前に解決することでサイトのダウンを最小限に抑え、サイトの継続的な可用性を確保。
• サイトの安定性の向上─現在のパフォーマンスの問題を特定して対処できるため、結果としてサイト全体の安定性と信頼性が向上する。
• 最適化の洞察─発生した異常を分析し、実行可能な最適化に関する貴重な洞察を得ることができる。

異常検知とパフォーマンスのスケーリングは表裏一体。両者を組み合わせることで、堅牢なパフォーマンス基盤を確立することができます。次のセクションでは、具体的なシナリオを想定してみます。

予測スケーリングと異常検知の使用例

利用可能なサーバーリソースを増やすことには数々の利点があり、ほぼすべてのサイトで、何らかの形でこの戦略が必要になってくると言っても過言ではありません。

実際の環境で予測スケーリングと異常検知をどのように使用するか、具体例をご紹介します。まずは最も一般的なシナリオから。

1. 繁忙期のECサイト

ECサイトでは、常に一貫したトラフィックとエンゲージメントを確保できるのが理想的ですが、実際には変動は否めません。セール時期や年末年始などにトラフィックが急増するECサイトを考えてみます。

このシナリオでは、異常検知が広範な役割を果たします。まずパフォーマンス指標を確認し、トラフィックレベルに関する過去のデータを分析します。その指標をもとに予想されるトラフィックの急増を予測すれば、確保すべきリソースを検討し始めることができます。

1年の特定の時点で予想されるトラフィックレベルに基づき、プロアクティブにリソースを拡張します。例えば、負荷の増加に対応するためCPUやメモリを増やすなど。フロントエンドでは、ユーザーにスムーズなショッピング体験を一貫して提供することができ、最終的には費用を抑えるだけでなく、収益の増加にもつながります。

2. 大きなイベント発生時のニュースおよびメディアサイト

ニュースのような速報性が重要になるコンテンツを扱うサイトも、ECサイトと似た性質があり、大きなイベントやニュース速報が発生する際にトラフィックが急増します。

突然のアクセス増加（スパイク）はECサイトよりも頻繁に起こり、予測がより困難になります。また、関連コンテンツへのアクセスも時に重要です（気象警報など）。

このようなサイトにも、予測スケーリングが力を発揮します。ECサイト同様、過去の類似イベント発生時のトラフィックパターンを分析することで、いつ、どの程度の規模に拡大するかを予測し、情報に基づいて意思決定を行うことができます。また、現在のニュース傾向を監視することも有用です。このシナリオにおける第一の目標は、サイトがアクセスしやすく、レスポンシブな状態を維持すること。スムーズなUXも重要ですが、アクセスのしやすさが鍵になります。

3. 利用用途が多様なSaaSアプリケーション

SaaS（Software as a Service）アプリケーションもまた、顧客の行動とサービスに対する全体的な需要の両方に基づいて利用用途が変動するため、不安定になりがちです。この良い例になるのが、2020年3月の新型コロナウイルス感染症（COVID-19）の蔓延時です。1,600万人の労働者がリモートワークを余儀なくされ、最初の2週間でSlackの利用者は20％増加しました。

異常検知は、リソースを拡張する際に何が問題であるかを把握するのに有用です。コロナ禍でもユーザーが仕事を継続できるようにすることが使命であったSlackにとって、これは特に重要でした。

使用パターンに応じてインフラを最適化するには、予測スケーリングが不可欠です。過去のデータを分析し、プロアクティブな戦略を実施することで、UXを向上し、費用を最小限に抑えて、顧客からの信頼と対外的な評価を高めることができます。

リソース管理に役立つKinsta APIの機能

リソースのスケーリングを実装し、異常を検知する方法を持つことは非常に重要です。Kinstaのお客様は、多数の指標を分析できるコントロールパネル「MyKinsta」を使用することができます。

とはいえ、高度な柔軟性が必要になる状況においては、MyKinstaだけでは不十分かもしれません。そこで出番になるのがKinsta APIです。MyKinstaの機能にフックするためのエンドポイントが多数用意されており、中にはスケーラビリティと分析に便利なものもあります。

• CPU Usage：サーバーのCPU使用率を経時的に監視し、問題になる前に傾向や潜在的なボトルネックを特定するのに有用。
• Memory Usage：メモリ消費量を追跡し、負荷を処理するのに十分なリソースが確保できていることを確認し、必要に応じて拡張できる。
• Bandwidth：送信データの合計の分析はスケーリング戦略を実行するための良い指標に。
• Slowest Requests：サイトのパフォーマンスに最も大きな影響を与えるリクエストとレスポンスを示す多数あるエンドポイントの1つ。

後ほど詳しくご紹介しますが、Kinsta APIがカバーするのは、予測スケーリングと異常検知の基本的な側面のみです。

• Kinsta APIはデータを送信することができないため、将来の問題を予測する必要がある。
• Kinsta APIで必要なスケーリングを実装することはできないため、自分で作業を行うことになる。
• Kinsta APIを使用して様々な方法でサイトを監視することはできるが、目標によっては役立つエンドポイントがない可能性がある（エンドポイントは現在も継続的にリリース中です）。

しかしながらAPIには多数の機能があり、そのプログラム的な性質により、他のシステムに接続したり、独自の関数やクラスを実装したりなど、ありとあらゆることを実現できます。

Kinsta APIを使用して異常を検知する

スケーリングは毎日行う作業ではなく、トリガーが必要になるのは年に数回程度というのが一般的。そのため、より頻繁に行うことになるサーバーパフォーマンス指標の異常を検知する方法をご紹介します。

監視とアラートの設定

監視システムは、プロアクティブな対処を行うための基盤になります。考慮すべき点は多数ありますが、まずは基本となる以下の点を考えてみてください。

• 監視するもの─主要な指標を確認するために独自のレポートを取得したり、頻繁にチェックが必要になる指標はMyKinstaで確認したりするなど。
• 警告の受け取り方─しきい値に達するたびにSlackの通知や簡単なメールを受信するなど。
• ベースラインの決定─サーバーの一般的な動作をよく理解し、過去の指標データと将来の傾向などを調べる。

上記を考慮した上で、Kinsta APIでエンドポイントの設定を始めます。

異常検知に役立つKinsta APIエンドポイント

先にも触れましたが、異常検知に役立つエンドポイントはいくつかあります。

• Bandwidth：送信するデータの総量を測定
• HTTP Requests Per Minute：サイトが1分間に何回のHTTPリクエストを受けるかを測定

傾向の分析に適したエンドポイントは以下のとおり。

• CPU Usage：選択した期間の平均総CPU使用率
• Memory Usage：選択した期間の総メモリ消費量の平均

スケーリングには、以下のエンドポイントが有用です。

• Build Time：アプリのビルドにかかる時間を測定（CPUとメモリ使用量の指標と組み合わせることで、スケーリングの必要性を判断できる）
• Run Time：アプリのランタイムの合計は、使用量の優先順位の決定や、パフォーマンスのボトルネックの特定に役立つ

異常検知にエンドポイントを使用する例を見てみます。Node.jsを使用してあるサイトの帯域幅をチェックします。APIキーの検証（環境変数を使用する可能性が高い）と帯域幅を常時監視する何らかの方法を実装する必要があります。

import fetch from 'node-fetch';


const API_TOKEN = <あなたのAPIトークン>;
const APPLICATION_ID = <あなたの企業ID>;

async function checkBandwidth(token, id, timeframeStart, timeframeEnd, intervalInSeconds) {
  const query = new URLSearchParams({
    interval_in_seconds: intervalInSeconds,
    timeframe_start: timeframeStart,
    timeframe_end: timeframeEnd,
  }).toString();

  const resp = await fetch(`https://api.kinsta.com/v2/applications/${id}/metrics/bandwidth?${query}`, {
    method: 'GET',
    headers: {
      Authorization: 'Bearer <YOUR-API-KEY>',
    },

  });

  const data = await resp.json();

  if (!resp.ok) {
    console.error('Error checking bandwidth:', data);
    return;
  }

  console.log('Bandwidth data:', data);

}


async function run() {
  const timeframeStart = '2021-07-22T18:10:45.511Z';
  const timeframeEnd = '2021-07-22T18:10:45.511Z';
  const intervalInSeconds = '3600';

  await checkBandwidth(API_TOKEN, APPLICATION_ID, timeframeStart, timeframeEnd, intervalInSeconds);
}

run().catch(error => {
  console.error('An error occurred', error);
  process.exit(1);
});

通知には、帯域幅が一定の制限に達したときに会話を開始するSlackチャンネルを設定することができます。

異常値を検出するには、取得したデータに異常値がないか確認し、そこから対策を練ります。

異常値への対応

スクリプトが異常を検知すると、Slackにpingを送信します。対応方法は戦略によって異なりますが、今回は例として問題の根本原因をさらに調査、診断、解決する方法を確立していきます。

例えば、クライアントサイトであれば、サービスレベル契約（SLA）を締結し、決められた時間内に対応するように要求することができます。自分のサイトであれば、分析パネルを開き、ログに目を通すだけで良いかもしれません。

セットアップ方法は、チームの規模、要件、リソースによって異なりますが、いずれにしても、続いては予測スケーリングを実装します。

Kinsta APIを使用して予測スケーリングを実装する

ベースラインの指標を把握したら、リソースをスケーリングするかどうかを決定します。先に触れた通り、自動の予測スケーリングは自分で実装しなければなりません。Kinstaのアプリケーションホスティングを利用しているお客様は、MyKinstaの「アプリケーション」画面でこの機能を使用することができます。

Kinsta APIでは、予測スケーリングに役立つ以下のようなことを実行できます。

• スケーリングの必要性を確認する
• 全体的およびマクロ的なリソース消費を評価する
• スケーリングの対象となるボトルネックを見つける

bandwidth、HTTP requests per minute、average response timeは、スケーリングの必要性を判断するのに適したエンドポイントです。帯域幅とHTTPリクエストをチェックすることで、予測スケーリングと異常検知の両方の目的を果たすことができます。

傾向分析に使えるエンドポイントは、予測スケーリングにも有用です。CPUとメモリの使用率は、いずれもサーバーの性能を上げる必要があるかどうかを判断する指標になります。

最後に、ページ読み込みのボトルネックはリソースを消耗するため、スケーリングの価値があるかもしれません。これには、slowest requestsエンドポイントを監視します。MyKinstaではグラフで確認可能です。

これらはスケーリングの必要性の表れであり、最適化のチャンスかもしれません。問題を早期に解決することで、サイトに割り当てるリソースの量が減少し、結果としてリソースが解放されることで、（理論的には）より効率的な対応になります。

予測スケーリングと異常検知をワークフローに組み込むヒント

最後に、予測スケーリングと異常検知をワークフローに組み込むためのヒントやベストプラクティスをご紹介します。

• スケーリングと異常検知の指針となるサイトパフォーマンスの明確なベースラインとしきい値を見つける。
• 予測モデルの精度と関連性を定期的に見直し、更新する時間を確保する。
• 可能な限り監視を自動化し、チーム全体が確認できる自動通知を設定して、作業量を最小限に抑える。

自動化と手作業のバランスをとるには、以下のヒントを参考にしてみてください。

• 自動化したスケーリングアクションと手動での監視の良いバランスを見つける。戦略に対する適切なレベルの制御と説明責任を果たすために非常に重要。
• 自動スケーリングを導入する場合は、いつ発動し、いつ手動での操作が必要になるかについて、明確なガイドラインとルールを設ける。
• 自動化したルールを定期的に見直し、微調整する。これにより、効率を高めながらレポートの誤検出を最小限に抑えることができる。

また、分析と監視に関しては測定指標を常にチェックし、あらゆる変化に対応する必要があります。このプロセスを簡素化する方法はいくつかあります。

そして最も重要になるのは、下した決断の結果を定期的に分析すること。どのように決断を下したかをしっかり把握することで、次の意思決定をより効果的なものにすることができます。

まとめ

予測スケーリングと異常検知を行うことで、WordPressサイトのパフォーマンスと応答性をプロアクティブに維持することができます。Kinsta APIは、プログラムでこれらの技術を実装し、構築するのに一役買ってくれます。

例えば、Kinsta APIには、パフォーマンスの監視に役立つエンドポイントが多数あります。適切なスクリプトを使用すれば、ベースラインとベンチマークを設定し、Slackのようなプラットフォームと連動して、自動通知を設定可能です。これにより、必要時にも迅速に対応することができます。