Log Service:レイヤー 7 Server Load Balancer のアクセスログの分析

SLB は、RealServer のスケーリングおよび故障冗長性の復旧をサポートします。大規模な同時 Web アクセスリクエストの処理をサポートし、アプリケーションの高い信頼性を保証します。

• リクエストの送信元リージョンを表示します。

  この例では、次の図に示すとおり、ほとんどのリクエストは 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 ディメンションからの統計

次の図に示すとおり、時間の範囲を選択し、ステータスコードを指定して、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 からのページリダイレクトリクエストのログの詳細を示しています。