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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

©2025 Metaps Holdings, Inc. ● ⼀⼈の SRE エンジニアが 2〜3 のプロダクトを運⽤している ● アラートの発⽣頻度や傾向のトレースがおざなりに ○ 「HTTP 5XX のアラート調査どうなりました?」 → アラートが多すぎて Slack のメッセージを⾒失う ○ Sentry や Datadog など、アカウントを横断してアラートの傾向‧集計が⾒たい運⽤を進める上で発⽣した課題　　

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

©2025 Metaps Holdings, Inc. ログの種別 - インフラログ種別説明例イベントログサービスやリソースの状態変化、ステータス変更など ● サーバーのスケーリングイベント ● サービスの再起動 ● クラウドリソースの変更監査ログセキュリティやコンプライアンスを監視するためのアクションを記録 ● ユーザー認証情報の変更 ● ポリシーの変更 ● コンソールの操作記録システムログ OS やミドルウェア、コンテナの動作状態を記録 ● サーバー起動ログネットワークログネットワークトラフィックや通信パターンを記録し、セキュリティ監視やパフォーマンス分析に活用 ● IP 通信、ポートの記録 ● トラフィック分析

Slide 13

Slide 13 text

©2025 Metaps Holdings, Inc. ● オブザーバビリティを⾼めるために、ログの⼀元管理は重要 ● すべてのログを統合的に管理するとコストが増⼤するため、運⽤の効率化とコスト最適化を両⽴する現実的な仕組みを検討しなければならない重要度に応じたログ管理の実現ログの利用者参照するログのタイプ利用方法ログの配送先長期保存の必要性開発者アプリケーション例外トレースと紐づけて確認する Datadog (LaaS) 必要ない SRE AWS のイベントログ EC2、ECS などのアラートから調査 Amazon S3 / Amazon CloudWatch Logs 必要ない SRE 監査ログ CloudTrail など必要あり (監査要件)

Slide 14

Slide 14 text

Slide 15

Slide 15 text

©2025 Metaps Holdings, Inc. ● 不要なログの削除やログの整形ができる ○ Fluentd でログを集約した上で、ログのフィルタリングが柔軟に操作できる ● 複数のストレージにログを配送できる ○ LaaS (Logging as a Service) は便利な反⾯、コストを意識しなければならない ○ 開発者が必要とするログは数⽇程度あれば良い ■ LaaS のログ保管期間を最⼩限にし、⻑期保管⽤に Amazon S3 を採⽤ ● Amazon Kinesis という選択肢 ○ 1 つのログが 5KB 以下の場合も 5KB 換算される問題がある Fluentd を導⼊するメリット

Slide 16

Slide 16 text

©2025 Metaps Holdings, Inc. アプリケーションで発⽣した例外は Sentry で補⾜ ● アプリケーションに Sentry SDK を組み込み、例外メッセージを Sentry に送信 ● 開発者は Slack に通知されたメッセージを確認することで、アプリケーションで発⽣したエラーを確認することができる ● プロジェクト設定やアラート周りも最近は Terraform 対応が充実化してきている

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

©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 スケジュールされたメンテナンス・アカウント固有の問題

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

Slide 31

Slide 31 text

©2025 Metaps Holdings, Inc. クラウドコストは可視化できていますか? ● AWS であれば、コンソールにログインすることで使⽤状況を確認できる ● その反⾯、複数のアカウントを管理していると、それぞれのコストが上昇しているのか、安定しているのか判断が難しい ● AWS Organization で横断的に確認できるとはいえ、都度ログインするのは⾯倒 ○ あるいは Organization アカウントの利⽤が制限されている

Slide 32

Slide 32 text

©2025 Metaps Holdings, Inc. ● THE STATE OF OBSERVABILITY IN 2024: A PRACTITIONER PERSPECTIVE の調査によると、オブザーバビリティ実践者の 85% はコスト管理が SRE の役割である、と回答している ● SRE の強みはシステムの動作やリソース利⽤状況、パフォーマンスへの深い理解がある点であり、これはサービスの信頼性を維持しながらコスト最適化を主導する理想的なポジションとも⾔える SRE の新たな領域: コスト最適化

Slide 33

Slide 33 text

©2025 Metaps Holdings, Inc. ● コストを信頼性の問題として扱う稼働時間やレイテンシの SLO を設定するのと同じように、コスト効率の⽬標を設定することを検討する ● コスト最適化の⾃動化異常な⽀出の急増に関するアラートを設定し、需要に基づいてリソースのスケーリングを⾃動化し、開発者が設計上の選択によるコストへの影響を理解できるようにセルフサービスツールを作成する ● コスト分析のためにオブザーバビリティを使⽤するオブザーバビリティツールを使⽤して、コスト要因を可視化する Balancing act: Reliability vs. cost vs. innovation

Slide 34

Slide 34 text

Slide 35

Slide 35 text

©2025 Metaps Holdings, Inc. srest が提供するコスト可視化の仕組み ● Cost Explorer を参照可能な IAM ロールを発⾏し、STS 経由でお客様の AWS 環境からコスト情報を定期的に取得 ● 複数の AWS Organization、AWS アカウントを横断できるほか、選択した期間でのコスト⽐較、サービス単位での期間⽐較などをシンプルで分かりやすい UI で提供

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

©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 と連携することで、コストの按分やアラート通知も可能コストの取り込みから可視化、按分、アラート通知までを一元管理

Slide 40

Slide 40 text

Slide 41

Slide 41 text

©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

Slide 42

Slide 42 text

©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 ● ...

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

©2025 Metaps Holdings, Inc. ● リソース設計 ○ 負荷変動や将来的な拡張性を⾒据えたリソースのスケーリング設計 ● オブザーバビリティ ○ ログやメトリクスを収集‧分析できる基盤を構築し、運⽤の可視化を図る ● コスト管理 ○ リソース効率を考慮し、運⽤中のコスト最適化を計画する ● セキュリティ ○ クラウド全体の認可‧認証の基盤を構築する ● 技術選定 ○ IaC ツール、フレームワークの使⽤範囲、データベースの利⽤⽤途などクラウド設計を始める際に考えるべきこと

Slide 47

Slide 47 text

©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 ベースのコードと組み合わせる必要がある。

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

©2025 Metaps Holdings, Inc. スキーマレスデータベース選定の⼀例 Amazon DocumentDB Amazon OpenSearch Service Amazon DynamoDB 書き込み中速低速高速読み込み ▲中速 (メモリ次第) 高速高速複雑な検索可能可能 ▲やや難しい (設計次第) スケーラビリティ中高 (インデックスやシャードの設計が必要) 高 (オートスケール可能) メンテナンスウィンドウありありなし利用料インスタンスやストレージ使用量による (RI) インスタンスやストレージ使用量による安い

Slide 51

Slide 51 text

Slide 52

Slide 52 text