Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AWSにおける横断的なログ分析と コストの管理

Naomichi Yamakita
January 26, 2025
4k

AWSにおける横断的なログ分析と コストの管理

Naomichi Yamakita

January 26, 2025
Tweet

Transcript

  1. ©2025 Metaps Holdings, Inc. # 2025.01.23 SRE Kaigi AWSにおける横断的なログ分析と コストの管理

    株式会社メタップスホールディングス プロダクトオーナー 兼 SREマネジャー ⼭北 尚道
  2. ©2025 Metaps Holdings, Inc. ⾃⼰紹介 ⼭北 尚道 株式会社メタップスホールディングス Yamakita Naomichi

    @sre_yamakita ベトナム‧ハノイでのオフショア事業⽴ち上げからキャリアをスタートし、 アプリケーション開発からマネジメントまでを経験 2015 年に当社参画。徐々にクラウドインフラにも携わり、現在は横断的な テックリードや SRE チーフエンジニアとして従事 「AWS DevDay Tokyo」登壇、「Amazon Web Services ブログ」、 「builders.flash」寄稿 昨年より SRE のためのダッシュボード「srest」プロダクトオーナーを兼任 srest プロダクトオーナー 兼 SREマネジャー
  3. ©2025 Metaps Holdings, Inc. アジェンダ • メタップス HD の SRE

    運⽤体制 • srest サービス紹介 ◦ ログの可視化 ◦ コストの可視化 ◦ srest のシステム構成 • クラウド設計における技術選定のポイント
  4. ©2025 Metaps Holdings, Inc. • ⼀⼈の SRE エンジニアが 2〜3 のプロダクトを

    運⽤している • アラートの発⽣頻度や傾向のトレースがおざなりに ◦ 「HTTP 5XX のアラート調査どうなりました?」  → アラートが多すぎて Slack のメッセージを⾒失う ◦ Sentry や Datadog など、アカウントを横断してアラー トの傾向‧集計が⾒たい 運⽤を進める上で発⽣した課題    
  5. ©2025 Metaps Holdings, Inc. ログの種別 - アプリケーション ログ種別 説明 例

    標準出力 正常動作に関するログ • サーバーの起動 • アクセスログ • カスタムログ 標準エラー 異常動作に関するログ • サーバー起動エラー • HTTP 500 ステータスの記録 • カスタムエラーログ 例外メッセージ 異常発生時にけるスタックトレースなどの詳細 な例外情報 Ruby や Python の例外メッセージ
  6. ©2025 Metaps Holdings, Inc. ログの種別 - インフラ ログ種別 説明 例

    イベントログ サービスやリソースの状態変化、ステータス変 更など • サーバーのスケーリングイベント • サービスの再起動 • クラウドリソースの変更 監査ログ セキュリティやコンプライアンスを監視するため のアクションを記録 • ユーザー認証情報の変更 • ポリシーの変更 • コンソールの操作記録 システムログ OS やミドルウェア、コンテナの動作状態を記録 • サーバー起動ログ ネットワークログ ネットワークトラフィックや通信パターンを記録 し、セキュリティ監視やパフォーマンス分析に活 用 • IP 通信、ポートの記録 • トラフィック分析
  7. ©2025 Metaps Holdings, Inc. • オブザーバビリティを⾼めるために、ログの⼀元管理は重要 • すべてのログを統合的に管理するとコストが増⼤するため、 運⽤の効率化とコスト最適化を両⽴する現実的な仕組みを検討しなければならない 重要度に応じたログ管理の実現

    ログの利用者 参照するログのタイプ 利用方法 ログの配送先 長期保存の必要性 開発者 アプリケーション例外 トレースと紐づけて確認 する Datadog (LaaS) 必要ない SRE AWS のイベントログ EC2、ECS などのア ラートから調査 Amazon S3 / Amazon CloudWatch Logs 必要ない SRE 監査ログ CloudTrail など 必要あり (監査要件)
  8. ©2025 Metaps Holdings, Inc. • 不要なログの削除やログの整形ができる ◦ Fluentd でログを集約した上で、ログのフィルタリングが柔軟に操作できる •

    複数のストレージにログを配送できる ◦ LaaS (Logging as a Service) は便利な反⾯、コストを意識しなければならない ◦ 開発者が必要とするログは数⽇程度あれば良い ▪ LaaS のログ保管期間を最⼩限にし、⻑期保管⽤に Amazon S3 を採⽤ • Amazon Kinesis という選択肢 ◦ 1 つのログが 5KB 以下の場合も 5KB 換算される問題がある Fluentd を導⼊するメリット
  9. ©2025 Metaps Holdings, Inc. アプリケーションで発⽣した例外は Sentry で補⾜ • アプリケーションに Sentry

    SDK を組み 込み、例外メッセージを Sentry に送信 • 開発者は Slack に通知されたメッセージ を確認することで、アプリケーションで 発⽣したエラーを確認することができる • プロジェクト設定やアラート周りも最近 は Terraform 対応が充実化してきている
  10. ©2025 Metaps Holdings, Inc. AWS イベントの監視 - Fargate • タスクが異常終了したときの原因を調査する場合、AWS

    コンソールから停⽌理由を確 認できる ◦ ただし、イベントログにアクセスできるのは数⼗分程度と短い
  11. ©2025 Metaps Holdings, Inc. AWS イベントの監視 - Fargate • 過去のイベントログを確認するには、

    Amazon EventBridge にイベントを配送 する必要がある • イベントデータはタスクのメタデータが JSON 形式が返されるため、 containers.exitCode や stoppedReason を確認することで、終了理由を確認する ことができる • Fargate のイベントはほぼリアルタイム に EventBridge に提供されるため、 Slack 通知を⽤いた迅速な トラブルシューティングが可能
  12. ©2025 Metaps Holdings, Inc. EventBridge にログを集約することで AWS の健康状態を把握できる • 150

    を超える多くのサービスが EventBridge の受信イベントに対応 • Auth0 や New Relic、Mackerel など、 サードパーティとの統合もサポート
  13. ©2025 Metaps Holdings, Inc. • SRE チームが管理する全ての AWS アカウントに EventBridge

    + Lambda を構築し、中央集約型 データベースにログを送信する仕組みを構築 • ログの可視化には Metabase を活⽤すること で、どの AWS アカウントにどのような問題が起 きているか、横断した可視化が可能に • 社内におけるサービス化の気運が⾼まり、⼀般 公開に向けてシステム構成をリアーキテクト • 2024年9⽉、srest として正式リリース ◦ SRE + REST: SRE を休ませる AWS イベントを収集する基盤が完成
  14. ©2025 Metaps Holdings, Inc. • Datadog、New relic、Sentry、 PagerDutyをサポート • 各サービスが提供する

    Webhook 機能を ⽤いて srest にイベントログを送信 ◦ モニターのしきい値を超えたアラート ◦ アプリケーション例外 ◦ オンコールのステータスなど srest におけるログ収集の仕組み - API
  15. ©2025 Metaps Holdings, Inc. • お客様の AWS 環境で発⽣した各種イベ ントログを srest

    にルーティング • srest が提供する CloudFormation テン プレートをデプロイすることで、ルー ティングに必要なリソースは⾃動⽣成さ れる srest におけるログ収集の仕組み - EventBridge
  16. ©2025 Metaps Holdings, Inc. srest がサポートする EventBridge サポートイベント (2025 年

    1 ⽉現在) ログ種別 イベントソース 例 Amazon CloudWatch aws.cloudwatch アラーム状態の更新 Amazon EC2 aws.ec2 インスタンスステータスの変更、AMI イベント、セキュリティグループイ ベント、スナップショットイベントなど Amazon ECS aws.ecs タスクステータスの変更・サービスアクション・コンテナインスタンスの状 態変更・タスク定義の登録 Amazon GuardDuty aws.guardduty 異常な API の呼び出し・不審なインスタンスの通信・トロイの木馬・ルー トキットなどの脅威検出 Amazon Inspector 2 aws.inspector2 Inspector が検出したセキュリティ評価の更新 Amazon RDS aws.rds インスタンスステータスの変更、 DB パラメータグループの変更、スナッ プショットイベント、フェイルオーバーイベントなど AWS SecurityHub aws.securityhub SecurityHub が検出したセキュリティ上の問題の更新通知・セキュリ ティスコアの更新 AWS Helath aws.health スケジュールされたメンテナンス・アカウント固有の問題
  17. ©2025 Metaps Holdings, Inc. AWS Well-Architected Framework - コスト最適化 •

    Well-Architected Framework は、 クラウド上でワークロードを設計および 実践するためのベストプラクティス • フレームワークの 1 つ、「コスト最適化」 では、以下の⽬標が掲げられている ◦ クラウド財務管理の実践 ◦ 経費⽀出と使⽤量の認識 ◦ コスト効率を考慮しながらリソースを利⽤する ◦ 需要を管理しリソースを供給する ◦ 継続的最適化
  18. ©2025 Metaps Holdings, Inc. クラウドコストは可視化できていますか? • AWS であれば、コンソールにログインする ことで使⽤状況を確認できる •

    その反⾯、複数のアカウントを管理してい ると、それぞれのコストが上昇しているの か、安定しているのか判断が難しい • AWS Organization で横断的に確認できる とはいえ、都度ログインするのは⾯倒 ◦ あるいは Organization アカウントの利⽤が制 限されている
  19. ©2025 Metaps Holdings, Inc. • THE STATE OF OBSERVABILITY IN

    2024: A PRACTITIONER PERSPECTIVE の調査 によると、オブザーバビリティ実践者の 85% はコスト管理が SRE の役割であ る、と回答している • SRE の強みはシステムの動作やリソース 利⽤状況、パフォーマンスへの深い理解 がある点であり、これはサービスの信頼 性を維持しながらコスト最適化を主導す る理想的なポジションとも⾔える SRE の新たな領域: コスト最適化
  20. ©2025 Metaps Holdings, Inc. • コストを信頼性の問題として扱う 稼働時間やレイテンシの SLO を設定するのと同じように、コスト効率の⽬標を設定す ることを検討する

    • コスト最適化の⾃動化 異常な⽀出の急増に関するアラートを設定し、需要に基づいてリソースのスケーリン グを⾃動化し、開発者が設計上の選択によるコストへの影響を理解できるようにセル フサービスツールを作成する • コスト分析のためにオブザーバビリティを使⽤する オブザーバビリティツールを使⽤して、コスト要因を可視化する Balancing act: Reliability vs. cost vs. innovation
  21. ©2025 Metaps Holdings, Inc. srest が提供するコスト可視化の仕組み • Cost Explorer を参照可能な

    IAM ロール を発⾏し、STS 経由でお客様の AWS 環 境からコスト情報を定期的に取得 • 複数の AWS Organization、AWS アカウ ントを横断できるほか、選択した期間で のコスト⽐較、サービス単位での期間⽐ 較などをシンプルで分かりやすい UI で 提供
  22. ©2025 Metaps Holdings, Inc. コストアロケーション機能 (2025 年 1 ⽉リリース) •

    AWS アカウント内のリソースを任意の条件 でグルーピングし、コストを按分する機能 • AWS アカウント ID のほか、AWS サービス 名、リソース ID、分配タグなどを⽤いた按 分に対応
  23. ©2025 Metaps Holdings, Inc. コストアロケーションの仕組み • Cost & Usage Report

    (CUR 2.0) を有効化 し、S3 に出⼒されたレポートデータを srest が定期的に STS 経由で取得 • srest は、コストアロケーションで設定 された条件を元にレポートデータにタグ 付けを⾏ない、ダッシュボードでの可視 化を提供
  24. ©2025 Metaps Holdings, Inc. コスト管理でありがちな問題 • インフラの構成を変更したことで急激に コストが上昇したが、請求書が届いてか ら問題が発覚した •

    未使⽤リリースが削除されず、継続的に 課⾦が発⽣している • AWS Budgets でアラートを設定したい が、管理する AWS アカウントが多すぎ て対応する時間が取れない
  25. ©2025 Metaps Holdings, Inc. コストの機能⽐較 機能 AWS srest 可視化 サービス名

    AWS Cost Explorer コストアナリティクス 特徴 操作が簡単で、素早くデータを確認可 能。データ保持期間は 13 ヶ月 必要最小限の機能に絞り、開発者以外 にも分かりやすい UI を提供。データ保 持は 13 ヶ月以上可能 高度な分析 サービス名 AWS Data Exports (CUR 2.0) AWS Cost Categories AWS Budgets コストアロケーション 特徴 コストの生データを CSV や、Amazon QuickSight に連携する形で提供。 Cost Categories や Budgets と連携す ることで、コストの按分やアラート通知も 可能 コストの取り込みから可視化、按分、ア ラート通知までを一元管理
  26. ©2025 Metaps Holdings, Inc. 技術スタック カテゴリ 用途 主な技術 フロントエンド UI

    の実装 Vue.js バックエンド API の実装 Ruby (Serverless Framework) インフラ アプリケーションの配信 AWS Amplify API エンドポイント Amazon API Gateway ユーザーの認証・認可 Amazon Cognito データベース Amazon OpenSearch Amazon DynamoDB (Amazon DocumentDB から移行中) コンピューティング AWS Lambda バッチ処理 AWS Batch イベントソース Amazon EventBridge データストリームの収集 Amazon Kinesis データの配送 Amazon Data Firehose
  27. ©2025 Metaps Holdings, Inc. IaC • インフラのコード化には Terraform を利⽤ ◦

    AWS のほか、Datadog、GitHub、Sentry、PagerDuty もコード化 ◦ モジュール形式で実装し、他のプロダクトとインフラ構成を共通化 • srest ではアプリケーション開発に Serverless Framework を採⽤ ◦ どこまで Terraform で管理し、どこから Serverless Framework で管理するか ◦ アプリケーションレイヤーに密に結合するリソースは Serverless Framework、その他のリソー スは Terraform で管理する⽅針 Terraform Serverless Framework • VPC • OpenSearch Service • IAM • Security Group • S3 • ... • API Gateway • Lambda • Kinesis • Firehose • Batch • ...
  28. ©2025 Metaps Holdings, Inc. ログ: イベント駆動アーキテクチャ • イベントログは EventBridge、あるいは API

    Gateway 経由で srest に集約される • イベントデータは常に送られる訳ではな いが、スパイク時は秒間数千以上のリク エストが発⽣することもあるため、 Kiness を配置してピーク時の負荷を軽減 する構成に
  29. ©2025 Metaps Holdings, Inc. • EventBridge 経由で Step Functions を実

    ⾏し、Lambda で ETL の前処理を⾏った 後、AWS Batch を⽤いて CUR データの 収集‧分析‧加⼯を⾏なう コスト: ポーリング駆動アーキテクチャ
  30. ©2025 Metaps Holdings, Inc. • リソース設計 ◦ 負荷変動や将来的な拡張性を⾒据えたリソースのスケーリング設計 • オブザーバビリティ

    ◦ ログやメトリクスを収集‧分析できる基盤を構築し、運⽤の可視化を図る • コスト管理 ◦ リソース効率を考慮し、運⽤中のコスト最適化を計画する • セキュリティ ◦ クラウド全体の認可‧認証の基盤を構築する • 技術選定 ◦ IaC ツール、フレームワークの使⽤範囲、データベースの利⽤⽤途など クラウド設計を始める際に考えるべきこと
  31. ©2025 Metaps Holdings, Inc. フレームワーク選定の⼀例 機能 AWS SAM AWS CDK

    Serverless Framework デプロイ AWS CloudFormation 記述形式 YAML プログラミング言語 (TypeScript など) YAML、TypeScript 開発が容易か △ ◎ (プログラミング知識が必要) ◎ プラグイン △ - ◎ アプリケーション規模 小〜中規模 中〜大規模 小〜中規模 サポート Amazon Web Services, Inc. Serverless, Inc. + コミュニティが活発 その他 インフラとアプリケーションを 同じ言語で記述できる。 Serverless Framework がサ ポートしていないリソースは CloudFormation ベースの コードと組み合わせる必要が ある。
  32. ©2025 Metaps Holdings, Inc. Terraform ディレクトリ設計の⼀例 ディレクトリを分けない サービスごとに ディレクトリを分割 抽象化したレイヤーで

    ディレクトリを分割 applyの回数 1回で済む ▲サービス単位で実行 レイヤーの粒度で実行 (database、network など) 安全性 ▲低い (影響範囲が広域に及ぶ) 高い 比較的高い tfstateのサイズ ▲非常に大きい (applyの実行速度に影響) 小さい 比較的小さい リソース間の 依存関係 シンプル ▲複雑 比較的シンプル コンフリクト ▲発生しやすい 発生しづらい 比較的発生しづらい
  33. ©2025 Metaps Holdings, Inc. バッチサービス選定の⼀例 AWS Lambda AWS Fargate AWS

    Batch 構築が容易か ◎ △ (デプロイの整備) ◯ 大規模データ処理 ▲✕ △ ◯ 起動速度 ◎ ◯ △ リトライ あり ▲なし あり 他のサービスとの連携 ◎ △ △ 実行時間の制限 ▲最大15分 なし なし 注意点 コールドスタート対策の検討 が必要 Fargate の全ての機能をカ バーしている訳ではない
  34. ©2025 Metaps Holdings, Inc. スキーマレスデータベース選定の⼀例 Amazon DocumentDB Amazon OpenSearch Service

    Amazon DynamoDB 書き込み 中速 低速 高速 読み込み ▲中速 (メモリ次第) 高速 高速 複雑な検索 可能 可能 ▲やや難しい (設計次第) スケーラビリティ 中 高 (インデックスやシャードの 設計が必要) 高 (オートスケール可能) メンテナンスウィンドウ あり あり なし 利用料 インスタンスやストレージ使用 量による (RI) インスタンスやストレージ使用 量による 安い
  35. ©2025 Metaps Holdings, Inc. まとめ: クラウド設計を⾏なう上での注意点 • クラウド設計では、各サービスの利点と課題を理解し、プロジェクト要件に最適な組 み合わせを選択する必要がある •

    システム構成は要件や規模に応じてリアーキテクトを検討する • 完璧なインフラは存在しない。過剰な設計をせずシンプルなアーキテクチャを取り⼊れ る