Alibaba Cloud Server Load Balancer (SLB) はトラフィックを複数のインスタンスへ分散し、アプリケーションのサービス能力を向上させます。 SLB を使用すると、SPOF (単一障害点) を防止し、アプリケーションの可用性とフォールトトレランス能力を向上させることができます。 SLB は、クラウドアーキテクチャにあるほとんどのサービス向けのインフラストラクチャコンポーネントです。 継続的に SLB のモニター、検出、診断、レポートを作成を行う必要があります。 SLB インスタンスの実行ステータスは、クラウドサービスプロバイダーが提供するモニタリングレポートを使用して確認できます。

現在、HTTP または HTTPS ベースのレイヤー 7 SLB において、アクセスログを生成できます。 アクセルログには、リクエストの受信時刻、クライアントの IP アドレス、処理待ち時間、リクエスト URI、バックエンド RealServer (Alibaba Cloud ECS インスタンス) アドレス、返されたステータスコードなど、約 30 の列が含まれます。 列や機能の詳細については、「レイヤー 7 Server Load Balancer のアクセスログ」をご参照ください。

このトピックでは、Log Service の分析 (OLTP、OLAP) 機能および可視化とリアルタイムクエリ機能に基づいたレイヤー 7 SLB アクセスログのリアルタイム収集、クエリ、分析に対する最適なスキームについて説明します。 合わせて、SLB インスタンスのレポート統計やログクエリ、分析を行うための一般的な方法について説明します。 このスキームでは、視覚的レポート、クエリ、分析エンジンを組み合わせて、 SLB インスタンスのステータスをリアルタイムでインタラクティブに分析します。

現在、レイヤー 7 SLB アクセスログはすべてのリージョンでご利用いただけます。

前提条件

  1. Log Service とレイヤー 7 SLB が有効である必要があります。
  2. レイヤー 7 SLB ログを収集している必要があります。 ログの収集方法についての詳細は、「レイヤー 7 Server Load Balancer のアクセスログ」をご参照ください。

可視化分析

ビジネスの概要

SLB は、RealServer のスケーリングおよび故障冗長性の復旧をサポートします。大規模な同時 Web アクセスリクエストの処理をサポートし、アプリケーションの高い信頼性を保証します。
一般的なビジネス概要のメトリックスは次のとおりです。
  • PV: クライアント (リクエストソースの IP アドレス) が送信した HTTP または HTTPS リクエスト数
  • UV: リクエストの合計数 同じクライアント IP アドレスからのリクエストは、1 つのリクエストとしてカウントされます。
  • リクエストソースレート: 合計 PV 数に対して、ステータスコードが 2XX であるリクエストの割合 (%)
  • リクエストトラフィック: リクエストの長さの合計 (request_length フィールドで指定された内容)
  • レスポンストラフィック: SLB からクライアントへ返される HTTP 応答本文の合計バイト数 (body_bytes_sent フィールドで指定された内容)
  • リクエストの PV ヒートマップ: クライアントの IP アドレスが存在するリージョン内の PV の密度を表示します。
  • リクエストの送信元リージョンを表示します。
    この例では、次の図に示すとおり、ほとんどのリクエストは Pearl River Delta と Yangtze River Delta から送信されています。
  • Log Service のダッシュボードでは、クライアントの IP アドレスや SLB インスタンスの ID などのフィルター条件を追加し、フィルター条件を満たすデータを現在のグラフに表示することができます。
    たとえば、指定した SLB インスタンスの一定期間にわたっての PV や UV の傾向を表示することができます。

スケジューリング分析のリクエスト

クライアントから送信されたリクエストはまず SLB で処理され、その後ビジネスロジックに基づいて処理するために、複数の RealServer の 1 つへ送られます。 SLB は異常な RealServer を検出し、トラフィックを正常な状態の他の RealServer へ送ります。 異常の RealServer が正常な状態になった後、トラフィックはこれらの RealServer へ引き続き送られます。 すべてのプロセスは自動で実行されます。SLB インスタンスへリスナーを追加します。 リスナーに対しては、ラウンドロビン、重み付きラウンドロビン (WRR)、最小接続アルゴリズム (WLC) の 3 つのスケジューリング方法を使用できます。
  • ラウンドロビン: 訪問数に基づいて、外部リクエストがバックエンド ECS インスタンスへ順次配信されます。
  • WRR: 各バックエンド RealServer に対して重みを設定します。 重みの大きい RealServer は、重みの小さい RealServer よりも多くのリクエストを受信します。
  • WLC: 各バックエンド RealServer の重みと負荷 (接続数) に基づいてリクエストが転送されます。 重みが同じ場合、接続数が少ないバックエンド RealServer が、接続数が多いバックエンド RealServer よりも多くのリクエストを受信します。
たとえば、IP アドレスが172.19.39. **の RealServer はジャンプサーバーでもあります。 そのパフォーマンスは、他の 3 つの RealServer の 4 倍です。 この RealServer の重みを 100 と設定した場合、他の 3 つの RealServer の重みは 20 に設定されます。次のステートメントを実行し、インスタンスのアクセスログに基づいて、2 つのディメンションのトラフィックを集計します。
* | select COALESCE(client_ip, vip_addr, upstream_addr) as source, COALESCE(upstream_addr, vip_addr, client_ip) as dest, sum(request_length) as inflow group by grouping sets( (client_ip, vip_addr), (vip_addr, upstream_addr))
Sankey ダイアグラムに基づいて、仮想 IP アドレスディメンションから SQL ステートメントによって返された結果を集計、可視化することで、リクエストトラフィックトポロジを取得します。 リクエストが複数のクライアント IP アドレスから SLB 仮想 IP アドレス (172.19.0. **) へ送信された場合、そのリクエストトラフィックは、20:20:20:100 の割合でバックエンド RealServer へ送られます。 Sankey ダイアグラムでは、各 RealServer の負荷を明確に示しています。

トラフィックと待ち時間の分析

1 分ごとにトラフィックと待ち時間の集計コンピューティングを実行します。
  • request_length と body_bytes_sent ディメンションからの統計
  • request_time と upstream_response_time ディメンションからの統計

リクエストの概要

リクエスト方法、プロトコル、ステータスコードなど、アクセスログにある複数のディメンションからの HTTP や HTTPS リクエストを分析します。

次の図に示すとおり、時間の範囲を選択し、ステータスコードを指定して、Log Service のクエリや分析機能に基づいてログにある RealServer を特定します。
  1. さまざまななリクエスト方法に関する PV の統計を収集します。
  2. 時間ディメンションでは、さまざまなリクエスト方法に関する、一定期間にわたっての PV のトレンドラインを表示します。
  3. さまざまなステータスコードを持つリクエストの割合から、サービスの実行ステータスを確認できます。 ステータスコード 500 のリクエストが多数ある場合、バックエンド RealServer のアプリケーションで内部エラーが発生します。
  4. 各ステータスコードの PV のトレンドラインを表示します。

ソース分析のリクエスト

クライアントの IP アドレスを分析することで、地理的な場所 (国、県、市) や通信事業者の情報を取得します。
  1. さまざまな事業者の IP アドレスからのリクエストに対して PV 分布図を作成します。
  2. クライアントの IP アドレスを分析することで、リクエストソースを PV の降順で表示します。
  3. ユーザーエージェント情報を表示します。

    ユーザーエージェント (http_user_agent) は、Web サイトやサービスにアクセスしているユーザーの識別に使用できる一般的なメトリックです。 たとえば、検索エンジンは Web クローラーを使って Web サイトリソースをスキャンしたりダウンロードします。 一般的には、クローラーへのアクセス頻度が低い場合、検索エンジンは Web サイトの内容をタイムリーにアップデートすることができます。Web サイトのプロモーションや検索エンジンの最適化 (SEO) が容易になります。 高い PV を持つリクエストが Web クローラーから送信された場合、サービスパフォーマンスとサーバーのリソースが浪費される可能性があります。 したがって、高い PV を持つリクエストをモニターし、浪費を回避する対策を講じる必要があります。

    SLB インスタンス ID、アプリケーションホスト、ユーザーエージェントに基づいた関連レコードのアクセスログを検索できます。 次の図は、Sogou Web クローラーから送信された GET リクエストのログを示しています。 リクエストは頻繁ではなく、アプリケーションに対する悪影響はありません。

操作の概要

SLB アクセスログは、トラフィック分析のアクセスログを使ってビジネスプランを作成するマーケティングチームにとって不可欠なものです。
  1. さまざまなリージョンの PV 分布を表示します。
    地理的なディメンションでさまざまなリージョンの PV を表示することにより、サービスにとって主要なお客様がいるエリアや PV が低くさらなるプロモーションが必要なエリアを把握することができます。
  2. リクエストのホストや URI を表示します。

    Web サイトの場合、訪問者の行動を分析をすることで、Web サイトのコンテンツを構築する際に有用なリファレンスを提供します。 コンテンツの良し悪しは、PV が最も高いまたは最も低い上位の Web サイトのホストや URI から判断できます。

  3. リクエスト URI を表示します。
    一般的なリソース (アクセスログの request_uri フィールドで指定されたもの) では、ログの詳細にある http_referer フィールドに注意し、Web サイトのリクエストソースを表示します。 良いリクエストソースを強化し、ホットリンク保護を有効にします。 次の図は、Baidu Image からのページリダイレクトリクエストのログの詳細を示しています。