ログ収集・分析基盤の構築
【概要】 ログデータ保存方法の改善とログデータ分析基盤の構築 【担当】 チーム構成: - CTO: 1名 - エンジニア: 1名 エンジニアとして、バックエンド及びインフラのライブラリ選定,設計,コーディング,テストを担当。 【使用技術】 Ruby | Ruby on Rails | Amazon EC2 | Amazon S3 | Amazon Kinesis Data Firehose | aws-kinesis-agent | Amazon Athena | Docker | Logrotate | cron 【課題】 - APIサーバーのログは、AutoScalingのEC2インスタンス数増減によりサーバーごと破棄されてしまっていた - 本番環境にて不具合や障害があった際、サーバーにSSHログインしてログを追うような面倒さがあったり、そもそも該当ログが既に破棄されてしまっている、といったようなことがあった 【取り組み】 - APIサーバーにaws-kinesis-agentをインストールし、Railsアプリケーションのログをトラッキングするよう設定。aws-kinesis-agentは一定期間ごとにログデータをAmazon Kinesis Data Firehoseを通じてS3バケットに送信するようにし、ログデータをEC2インスタンスの外側で保存 - 収集したログデータをクエリできるようにするため、Amazon AthenaからS3へと接続してログデータのテーブルを作成 【工夫した点】 - 当初はCloudWatchLogsを採用しようと考えていたが、当時のサービス運営状況においては約15GiB/日のログデータが発生していたので、CloudWatchLogsでログの収集・保存を行うとかなりの高額になってしまうことが判明。よって、より安価かつCloudWatchLogsと同等の難易度で実装可能なKinesis Data FirehoseとS3の組み合わせを採用 - Railsアプリケーションのデフォルトのログフォーマットだと検索性が低かったため、JSONフォーマットでロギングするよう変更。エンジニアメンバーに「不具合調査の際キーワードにするパラメータ」をヒアリングし、それをJSONのkey:valueとして出力するためのログフォーマッティングクラスを実装することで実現 - 運用開始直後、日付変更のタイミングでaws-kinesis-agentがログファイルのトラッキングに失敗する現象に悩まされたが、cronで実行されているLogrotateのローテーションモードがcopytruncateであり、このモードがaws-kinesis-agentでサポートされていないことを突き止め、createモードに修正することで解決 【成果】 不具合調査だけでなくアクセス元の集計等データ分析にも活用できるログ収集・分析基盤で、プロダクトの保守性向上と改善の両方に貢献。