はじめに
こんにちは、KUDs です。
本記事では、ELB アクセスログの有効化手順や料金について、AWS 初心者向けに解説します。
AWS と ELB について概説
改めまして、AWS は、Amazon.com が提供するクラウドコンピューティングサービスです。
※AWS: Amazon Web Services
AWS ではインフラからモニタリングまで、200 以上のサービスが提供されています。
その中の一つである ELB は、AWS のロードバランシングサービスです。
※ELB: Elastic Load Balancing
ELB は、アプリケーションに対するトラフィックを自動的に分散します。
これによって、アプリケーションの可用性とフォールトトレランスを高めます。
以下のタイプを提供しています。
- Classic Load Balancer
- Application Load Balancer
- Network Load Balancer
ELB アクセスログの重要性と利用例
ELB アクセスログは、アプリケーションのリクエストデータを詳細に記録する機能です。
これによって、以下のようなモニタリングが可能になります。
- ネットワークパフォーマンスの問題解析
- ユーザー行動の分析
- 不正なアクセスの特定
例えば、アクセスログにより、特定の時間帯に高負荷が発生していることを確認できれば、リソースをスケールアップするタイミングを理解するのに役立ちます。
また、エラーコードを追跡することで、アプリケーションで問題が発生している箇所を特定できます。
必要な準備
AWS アカウントのセットアップ
まず、AWS を利用するためには、AWS アカウントの作成が必要です。
十中八九、この記事を読んでいる人は既にアカウント作成済みかとは思いますが、もしまだの人がいれば AWS 公式サイトから作成しましょう。
なお、本記事は東京リージョン(ap-northeast-1)を利用する前提で執筆しております。
必要なAWSサービス（ELB、S3）の概観
この記事では、AWSの2つのサービス、ELB と S3 に焦点を当てています。
※S3: Simple Storage Service
- ELB：
- 前述の通り、アプリケーションのトラフィックを自動的に分散するサービスです。
- ELB を使用することで、アプリケーションの可用性と耐障害性を向上させることができます。
- S3：
- オブジェクトストレージサービスです。
- Web 上でのデータ保存や、静的ファイルのホスティングが可能です。
- この記事では、ELBからのアクセスログを保存するためにS3バケットを使用します。
S3 バケットの設定
新規 S3 バケットの作成または既存バケットの使用
まず、ELB アクセスログを保存するための S3 バケットが必要です。
ここでは、新規バケットを作成するか、既存のバケットを使用することができます。
新規 S3 バケットを作成する場合は、以下の手順で作成可能です。
- AWS Management Consoleにログイン
- 「Services」から「S3」を選択
- 「Create bucket」ボタンをクリック
- バケット名（世界中で一意である必要あり）とリージョンを入力
- 「Create」をクリック
以上で、新規の S3 バケットが作成できます。
既存のバケットを使用する場合は、後の手順で必要となるため、バケット名をメモしておきましょう。
S3 バケットポリシー
次に、ELB がログファイルを書き込む権限を与えるための S3 バケットポリシーが必要です。
権限不足エラー
そもそも、バケットポリシーが適切に設定されていない場合、以下のようなエラーが発生します。
Access Denied for bucket: your-bucket-name. Please check S3bucket permission
このようなエラーが発生した場合、適切なバケットポリシー設定が必要となります。
バケットポリシー設定手順
以下の手順では、適切なバケットポリシーを設定します。
- S3コンソールから対象のバケットを選択
- 「Permissions」タブをクリック
- 「Bucket Policy」ボタンをクリック
- 下記のサンプルポリシーを入力し、「Save」をクリック
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"PublicReadForGetBucketObjects",
"Effect":"Allow",
"Principal": {"AWS":"arn:aws:iam::582318560864:root"},
"Action":["s3:PutObject"],
"Resource":["arn:aws:s3:::your_bucket_name/*"]
}
]
}
※ここでは、「your_bucket_name」をあなたのバケット名に置き換えてください。
※「582318560864」は、ELB アカウント ID です。
ご自身の AWS アカウント ID ではないのでご注意くださいませ。
※東京リージョン以外をご利用中の方は、以下をご参照ください。
| リージョン | ELB アカウント ID |
| 米国東部 (バージニア北部) | 127311923021 |
| 米国東部 (オハイオ) | 033677994240 |
| 米国西部 (北カリフォルニア) | 027434742980 |
| 米国西部 (オレゴン) | 797873946194 |
| アジアパシフィック (大阪) | 383597477331 |
| 欧州 (フランクフルト) | 054676820928 |
| 欧州 (アイルランド) | 156460612806 |
| 欧州 (ロンドン) | 652711504416 |
| ヨーロッパ (ミラノ) | 635631232127 |
| 欧州 (パリ) | 009996457667 |
※最新の正確な情報は公式ドキュメントをご参照ください。
ELB アクセスログの有効化
AWS ELB コンソールからの設定方法
次に、ELB コンソールからアクセスログを有効にするには、以下の手順を実行します。
- AWS Management Consoleにログイン
- 「Services」から「EC2」を選択
- 左側のパネルから「Load Balancers」を選択
- アクセスログを有効にするロードバランサーを選択
- 「Description」タブの下で「Edit attributes」をクリック
- 「Access logs」セクションで「Enable access logs」を選択
- 「S3 location」に、ログを保存するS3バケットの名前を入力
- 「Save」をクリック
AWS CLI を用いた設定方法
もしくは、AWS CLI を使用してアクセスログを有効にするには、以下のコマンドを実行します。
ここでは、「my-load-balancer」をあなたのロードバランサー名に、「my-bucket-name」をあなたの S3 バケット名に置き換えてください。
aws elbv2 modify-load-balancer-attributes --load-balancer-arn my-load-balancer --attributes Key=access_logs.s3.enabled,Value=true Key=access_logs.s3.bucket,Value=my-bucket-name
これによって、ELB のアクセスログが S3 バケットに保存されるようになります。
なお、CLI に関する詳細は、以下の AWS 公式ドキュメントをご確認ください。
アクセスログの解析と利用
アクセスログの基本的な読み方
ELB アクセスログでは、詳細なリクエスト情報を提供します。
これらのログデータでは、行ごとにリクエスト情報を含み、その各部分はスペースで区切られます。
主要な項目としては、以下のようなものがあります。
- timestamp（時間）
- elb（ロードバランサー名）
- client:port（クライアントのIPとポート）
- target:port（ターゲットのIPとポート）
- request_processing_time（リクエスト処理時間）
- backend_processing_time（バックエンド処理時間）
- response_processing_time（レスポンス処理時間）
- elb_status_code（ELBのステータスコード）
- target_status_code（ターゲットのステータスコード）
- received_bytes（受信バイト数）
- sent_bytes（送信バイト数）
- “request”（リクエストの詳細）
- “user_agent”（ユーザーエージェント）
- ssl_cipher（SSL暗号）
- ssl_protocol（SSLプロトコル）
これらの情報を活用することによって、アプリケーションのパフォーマンスや問題の特定が可能になります。
なお、より詳細な情報は、以下の AWS 公式ドキュメントをご参照ください。
ログを用いた問題診断の例
アクセスログを利用すれば、例えば特定のステータスコード（4xxや5xx）が頻発している場合の問題診断が可能です。
これらのステータスコードが多い場合は、バックエンドのアプリケーションが適切に動作していないか、またはリクエスト自体に問題がある可能性があります。
また、request_processing_time や backend_processing_time が長い場合、アプリケーションが高負荷であることを示している可能性があります。
これらの情報は、パフォーマンス改善やスケールアウトのタイミングを判断するのに役立ちます。
ELB アクセスログの料金
もちろん、S3 のストレージコストは発生しますが、S3 にログファイルを送信するために ELB が使用する帯域については料金は発生しません。
S3 のストレージコストについては以下をご参照ください。
つまり、ログデータを長期間保存する場合は、相応のストレージコストが発生することになります。
例えば、ログに頻繁にアクセスしない場合は、ライフサイクルポリシーを設定して、古いログを自動的に Glacierに移動させることで、ストレージコストを節約できます。
もしくは、一定期間でログが不要になる場合は、削除することも一つの手です。
ELB アクセスログを有効にする際は、これらのコスト要因を考慮に入れて、適切なログ管理とコスト管理の戦略を策定することが重要です。
まとめ
アクセスログがもたらす利点の再確認
本記事では、ELB アクセスログを有効化する手順を確認しました。
AWS の ELB アクセスログは、アプリケーションのトラフィックパターンを理解し、パフォーマンスの問題を特定し、セキュリティインシデントを調査する強力なツールです。
ログを適切に設定し、解析することで、あなたのアプリケーションはより安定し、効率的に動作します。
しかしながら、サーバ内部のエラーについては詳細を検知できません。
そこで、必要に応じて、EC2 内部でメトリクスやログを収集することを検討してください。
以下の記事では、メトリクス収集やアプリケーションログの収拾について議論しており、参考になるかと思います。
コメント