第5章：クラウド環境特有のトラブルシューティング

章の概要

学習目標: クラウド環境での責任分担、分散アーキテクチャ、サービス依存を理解し、クラウド特有の診断手法を習得する
前提知識: 第4章の各レイヤー診断技術
到達点: クラウドネイティブなトラブルシューティング能力の獲得
想定学習時間: 5-6時間

5.1 クラウドサービスの障害パターンと影響分析

難易度: ★★☆（中級）

共有責任モデルにおける責任範囲の明確化

クラウドサービスでは、クラウドプロバイダーと利用者の間で運用責任が分担されます。問題発生時の適切な対応のために、責任範囲を正確に理解することが必要です。

IaaS環境での責任分担では、インフラストラクチャサービスでの責任範囲を明確化します。

プロバイダー責任範囲：

物理インフラ（データセンター、ハードウェア）
仮想化レイヤー（ハイパーバイザー）
ネットワークインフラ（物理ネットワーク）
基本セキュリティ（物理セキュリティ）

利用者責任範囲は、ゲストOS以上の全ての層に及びます。OSのシステムサービス状態の管理、ネットワークインターフェースの設定、セキュリティポリシーの実装など、従来のシステム管理者が行っていた作業の多くが、引き続き利用者の責任となります。

PaaS環境での責任分担では、プラットフォームサービスでの責任範囲を理解します。

プロバイダー責任範囲：

OS、ランタイム環境
ミドルウェア、開発フレームワーク
プラットフォーム監視

利用者責任範囲：

アプリケーションコード
データ管理
ユーザー認証・認可
API使用

SaaS環境での責任分担では、ソフトウェアサービスでの責任範囲を把握します。

リージョンとアベイラビリティゾーンの障害影響

リージョン障害の特性と対策では、広範囲での障害への対応を計画します。

リージョン障害の確認：

# AWS CLI での複数リージョン確認
aws ec2 describe-regions
aws sts get-caller-identity --region us-east-1
aws sts get-caller-identity --region us-west-2

# サービス状況確認
curl -s https://status.aws.amazon.com/

マルチリージョン戦略：

データレプリケーション設定
DNS フェイルオーバー設定
アプリケーションの地理分散

アベイラビリティゾーン障害の管理では、リージョン内での障害分散を図ります。

AZ障害の検出：

# EC2インスタンスのAZ確認
aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,Placement.AvailabilityZone]'

# ELBのヘルスチェック確認
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:...

クラウドサービス固有の監視と診断

サービス可用性の監視では、依存するクラウドサービスの状態を継続的に監視します。

サービスヘルスの監視は、各クラウドプロバイダーのヘルスダッシュボードやAPIを通じて、サービスの健全性、性能低下、部分的障害、地域限定の問題などを継続的に評価します。Personal Health DashboardやService Healthの情報は、プロアクティブな監視と予防的な対応を可能にします。

APIレート制限とリソース制約の本質

クラウドサービスのAPIレート制限は、サービスの安定性と公平性を保つための重要な保護機構です。不適切なAPI使用パターンは、アプリケーションの性能低下、サービスの一時停止、予期しないコスト増加を引き起こす可能性があります。

APIレート制限の設計は、サービスごと、操作ごと、ユーザーごとに異なり、バースト容量、持続可能レート、リクエストキューの深さなど、複数のパラメーターで制御されています。効果的なAPI使用戦略には、指数バックオフ、リクエストのバッチ化、キャッシュ戦略の最適化などが含まれます。

5.2 主要クラウドプロバイダーでの実践的アプローチ

難易度: ★★★（上級）

AWS（Amazon Web Services）での診断技術

CloudWatch による統合監視では、AWS全体のメトリクス監視とアラート管理を行います。

CloudWatchメトリクス確認：

# EC2インスタンスメトリクス
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2023-01-01T00:00:00Z \
  --end-time 2023-01-01T23:59:59Z \
  --period 300 \
  --statistics Average

# RDSパフォーマンス確認
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name DatabaseConnections \
  --dimensions Name=DBInstanceIdentifier,Value=mydb-instance \
  --start-time 2023-01-01T00:00:00Z \
  --end-time 2023-01-01T23:59:59Z \
  --period 300 \
  --statistics Average

AWS X-Ray による分散トレーシングでは、マイクロサービスアーキテクチャでの問題を分析します。

X-Rayトレース分析：

# トレース取得
aws xray get-trace-summaries \
  --time-range-type TimeRangeByStartTime \
  --start-time 2023-01-01T00:00:00 \
  --end-time 2023-01-01T23:59:59

# サービスマップ取得
aws xray get-service-graph \
  --start-time 2023-01-01T00:00:00 \
  --end-time 2023-01-01T23:59:59

VPC Flow Logs によるネットワーク分析では、AWS ネットワーク内のトラフィックを詳細に分析します。

Flow Logs分析：

# Flow Logsの有効化確認
aws ec2 describe-flow-logs

# CloudWatch Logs でのFlow Logs確認
aws logs describe-log-groups --log-group-name-prefix VPCFlowLogs

Azure での診断と監視

Azure Monitor の活用では、Azure全体の統合監視を実現します。

Azure Monitor確認：

# リソースのメトリクス確認
az monitor metrics list --resource /subscriptions/.../resourceGroups/myRG/providers/Microsoft.Compute/virtualMachines/myVM

# ログクエリ実行
az monitor log-analytics query \
  --workspace workspace-id \
  --analytics-query "Heartbeat | where Computer == 'myVM' | limit 10"

Application Insights によるアプリケーション監視では、アプリケーション性能の詳細監視を行います。

Application Insights確認：

# アプリケーション可用性確認
az monitor app-insights query \
  --app app-id \
  --analytics-query "requests | where timestamp > ago(1h) | summarize count() by bin(timestamp, 5m)"

Google Cloud Platform（GCP）での監視と分析

Cloud Monitoring による統合監視では、GCP リソースの包括的な監視を実現します。

Cloud Monitoring確認：

# メトリクス確認
gcloud monitoring metrics list --filter="resource.type=gce_instance"

# アラートポリシー確認
gcloud alpha monitoring policies list

Cloud Logging によるログ分析では、GCP全体のログを統合的に分析します。

Cloud Logging確認：

# ログエントリ確認
gcloud logging read "resource.type=gce_instance AND severity>=ERROR" --limit=50

# ログベースメトリクス確認
gcloud logging metrics list

5.3 サーバーレス・コンテナ環境の課題と対策

難易度: ★★★（上級）

サーバーレス環境でのトラブルシューティング

関数実行とパフォーマンスの分析では、サーバーレス関数の実行特性を詳細に分析します。

Lambda関数診断（AWS）：

# Lambda関数のログ確認
aws logs describe-log-groups --log-group-name-prefix /aws/lambda/

# 関数の設定確認
aws lambda get-function --function-name my-function

# 実行統計の確認
aws lambda get-function-configuration --function-name my-function

コールドスタート分析：

import time
import json

def lambda_handler(event, context):
    # コールドスタート検出
    if 'cold_start' not in globals():
        global cold_start
        cold_start = True
        print("Cold start detected")
    else:
        print("Warm start")
    
    start_time = time.time()
    # 処理実行
    processing_time = time.time() - start_time
    
    return {
        'statusCode': 200,
        'body': json.dumps({
            'processing_time': processing_time
        })
    }

イベントドリブンアーキテクチャの監視では、イベントの流れと処理状況を包括的に監視します。

SQSキュー監視：

# キューの状況確認
aws sqs get-queue-attributes \
  --queue-url https://sqs.region.amazonaws.com/account/queue-name \
  --attribute-names All

# デッドレターキューの確認
aws sqs receive-message \
  --queue-url https://sqs.region.amazonaws.com/account/dlq-name \
  --max-number-of-messages 10

コンテナ環境での診断技術

コンテナライフサイクルの監視では、コンテナの作成から終了までの全ライフサイクルを監視します。

Docker診断：

# コンテナ状態確認
docker ps -a
docker stats

# コンテナログ確認
docker logs container-id --timestamps

# コンテナ内でのプロセス確認
docker exec container-id ps aux

Kubernetes クラスタの診断では、Kubernetes環境での包括的な問題診断を行います。

Kubernetes診断：

# クラスタ状態確認
kubectl cluster-info
kubectl get nodes -o wide

# ポッド状態確認
kubectl get pods --all-namespaces
kubectl describe pod pod-name

# サービス確認
kubectl get services
kubectl get endpoints

# ログ確認
kubectl logs pod-name -c container-name --previous

ポッド診断詳細：

# ポッドのリソース使用量
kubectl top pods --all-namespaces

# ポッドのイベント履歴
kubectl get events --sort-by=.metadata.creationTimestamp

# ネットワーク診断
kubectl exec -it pod-name -- nslookup kubernetes.default

コンテナセキュリティの監視では、コンテナ環境固有のセキュリティリスクを管理します。

セキュリティ診断：

# コンテナイメージの脆弱性スキャン
docker scan image-name

# Kubernetesセキュリティポリシー確認
kubectl get podsecuritypolicy
kubectl get networkpolicy

# RBAC設定確認
kubectl get rolebindings --all-namespaces
kubectl auth can-i create pods --as=system:serviceaccount:default:default

5.4 クラウド運用コストに関わるトラブルシューティング

難易度: ★★☆（中級）

コスト急増の原因分析と対策

クラウドの従量課金モデルでは、設定ミスや予期しない負荷により、コストが急激に増加する可能性があります。

コスト監視と異常検知では、継続的なコスト監視により異常を早期発見します。

AWS Cost Explorer API使用：

# コスト情報取得
aws ce get-cost-and-usage \
  --time-period Start=2023-01-01,End=2023-01-31 \
  --granularity DAILY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# 予算確認
aws budgets describe-budgets --account-id 123456789012

Azure Cost Management：

# コスト分析
az consumption usage list --top 10

# 予算アラート確認
az consumption budget list

リソース使用効率の最適化では、クラウドリソースの効率的な利用により、コストパフォーマンスを向上させます。

未使用リソース検出：

# AWS 未使用EBSボリューム検出
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].[VolumeId,Size,CreateTime]'

# 未使用Elastic IP検出
aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]'

# 停止中のEC2インスタンス
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=stopped \
  --query 'Reservations[*].Instances[*].[InstanceId,InstanceType,LaunchTime]'

リソースサイジング分析：

# CloudWatchメトリクスを使用したサイジング分析
import boto3
from datetime import datetime, timedelta

def analyze_instance_utilization(instance_id):
    cloudwatch = boto3.client('cloudwatch')
    
    end_time = datetime.utcnow()
    start_time = end_time - timedelta(days=7)
    
    # CPU使用率取得
    cpu_metrics = cloudwatch.get_metric_statistics(
        Namespace='AWS/EC2',
        MetricName='CPUUtilization',
        Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}],
        StartTime=start_time,
        EndTime=end_time,
        Period=3600,
        Statistics=['Average', 'Maximum']
    )
    
    avg_cpu = sum(point['Average'] for point in cpu_metrics['Datapoints']) / len(cpu_metrics['Datapoints'])
    max_cpu = max(point['Maximum'] for point in cpu_metrics['Datapoints'])
    
    if avg_cpu < 20 and max_cpu < 50:
        return "Oversized - consider downsizing"
    elif avg_cpu > 80 or max_cpu > 90:
        return "Undersized - consider upsizing"
    else:
        return "Appropriately sized"

課金最適化戦略では、クラウドプロバイダーの課金オプションを効果的に活用します。

Reserved Instance分析：

# AWS Reserved Instance使用状況
aws ce get-reservation-utilization \
  --time-period Start=2023-01-01,End=2023-01-31

# Savings Plans使用状況
aws ce get-savings-plans-utilization \
  --time-period Start=2023-01-01,End=2023-01-31

リソース最適化と自動化

Infrastructure as Code（IaC）による管理では、インフラストラクチャの定義と管理を自動化します。

Terraformでのコスト最適化：

# terraform/cost-optimization.tf
resource "aws_instance" "web" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = var.instance_type
  
  # スポットインスタンスの使用
  instance_market_options {
    market_type = "spot"
    spot_options {
      max_price = "0.05"
    }
  }
  
  # 自動停止タグ
  tags = {
    AutoStop = "true"
    Environment = var.environment
  }
}

# Auto Scaling設定
resource "aws_autoscaling_group" "web" {
  name                = "web-asg"
  min_size            = 1
  max_size            = 10
  desired_capacity    = 2
  vpc_zone_identifier = var.subnet_ids
  
  # コスト最適化のためのmixed instances
  mixed_instances_policy {
    instances_distribution {
      on_demand_percentage = 20
      spot_allocation_strategy = "diversified"
    }
    
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.web.id
        version = "$Latest"
      }
      
      override {
        instance_type = "t3.medium"
      }
      override {
        instance_type = "t3.large"
      }
    }
  }
}

監視とアラートの自動化では、運用監視を包括的に自動化します。

CloudWatchアラーム設定：

# コスト異常検知アラーム
aws cloudwatch put-anomaly-detector \
  --namespace AWS/Billing \
  --metric-name EstimatedCharges \
  --stat Average \
  --dimensions Name=Currency,Value=USD

# 高CPU使用率アラーム
aws cloudwatch put-metric-alarm \
  --alarm-name cpu-high \
  --alarm-description "High CPU usage" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2

Lambda自動修復関数：

import boto3
import json

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    
    # CloudWatchアラームからのイベント処理
    alarm_data = json.loads(event['Records'][0]['Sns']['Message'])
    
    if alarm_data['AlarmName'] == 'cpu-high':
        instance_id = alarm_data['Trigger']['Dimensions'][0]['value']
        
        # インスタンスの詳細取得
        response = ec2.describe_instances(InstanceIds=[instance_id])
        instance = response['Reservations'][0]['Instances'][0]
        
        # 自動スケールアップ判定
        current_type = instance['InstanceType']
        
        # より大きなインスタンスタイプにアップグレード
        upgrade_map = {
            't3.micro': 't3.small',
            't3.small': 't3.medium',
            't3.medium': 't3.large'
        }
        
        if current_type in upgrade_map:
            new_type = upgrade_map[current_type]
            
            # インスタンス停止→タイプ変更→起動
            ec2.stop_instances(InstanceIds=[instance_id])
            
            waiter = ec2.get_waiter('instance_stopped')
            waiter.wait(InstanceIds=[instance_id])
            
            ec2.modify_instance_attribute(
                InstanceId=instance_id,
                InstanceType={'Value': new_type}
            )
            
            ec2.start_instances(InstanceIds=[instance_id])
            
            return f"Upgraded {instance_id} from {current_type} to {new_type}"
        
    return "No action taken"

実践チェックリスト

クラウド基本診断チェック

共有責任モデルに基づいて責任範囲を明確化した
リージョン・AZ レベルでの障害影響を評価した
プロバイダーのService Health Dashboardを確認した
API制限と課金状況を監視している

プロバイダー別診断チェック

AWS: CloudWatch、X-Ray、VPC Flow Logsを活用した
Azure: Azure Monitor、Application Insightsを活用した
GCP: Cloud Monitoring、Cloud Loggingを活用した
複数プロバイダー環境での統合監視を実装した

サーバーレス・コンテナ診断チェック

Lambda/Function のコールドスタート問題を分析した
コンテナのライフサイクルと性能を監視した
Kubernetesクラスタの健全性を確認した
コンテナセキュリティ設定を検証した

コスト最適化チェック

未使用リソースを定期的に検出・削除している
リソースサイジングを継続的に最適化している
Reserved Instance/Savings Plansを効果的に活用している
自動化によるコスト制御を実装している

クラウド診断フローチャート

クラウド問題発生
    ↓
責任範囲確認（共有責任モデル）
    ↓
プロバイダー側 ← → 利用者側
    ↓              ↓
Service Health    [環境別診断]
Dashboard確認     ├─IaaS: OS・アプリ
    ↓             ├─PaaS: アプリ・データ  
API/課金状況確認   └─SaaS: 設定・使用方法
    ↓
[アーキテクチャ別診断]
├─従来型: VM・ネットワーク
├─サーバーレス: Function・イベント
└─コンテナ: Pod・クラスタ
    ↓
統合監視ツール活用
├─AWS: CloudWatch・X-Ray
├─Azure: Monitor・App Insights  
└─GCP: Monitoring・Logging
    ↓
根本原因特定・対策実施

重要コマンドリファレンス

AWS診断

# EC2インスタンス状態
aws ec2 describe-instances
# CloudWatchメトリクス
aws cloudwatch get-metric-statistics
# VPC情報
aws ec2 describe-vpcs
# コスト情報
aws ce get-cost-and-usage

Azure診断

# VM状態確認
az vm list --output table
# メトリクス確認
az monitor metrics list
# ログ確認
az monitor log-analytics query

GCP診断

# インスタンス確認
gcloud compute instances list
# ログ確認
gcloud logging read
# モニタリング
gcloud monitoring metrics list

Kubernetes診断

# クラスタ状態
kubectl cluster-info
# ポッド状態
kubectl get pods --all-namespaces
# ログ確認
kubectl logs pod-name
# リソース使用量
kubectl top nodes

重要用語集

共有責任モデル: クラウドプロバイダーと利用者間での運用責任分担の概念

リージョン/AZ: クラウドサービスの地理的・物理的な配置単位

サーバーレス: サーバー管理が不要なコンピューティングモデル

コンテナオーケストレーション: コンテナの配置・管理・スケーリングの自動化

Infrastructure as Code: インフラ構成をコードとして管理する手法

API レート制限: API呼び出し頻度の制限機能

コールドスタート: サーバーレス関数の初回実行時の初期化遅延

次章への接続

第5章で習得したクラウド環境での診断技術を基に、第6章では継続的な学習と改善のプロセスを学びます。インシデントから得られた知見を組織的な資産として蓄積し、将来の問題を予防する仕組みの構築方法を習得します。