技術的負債との戦い！ PR TIMESエンジニアチームの オブザーバビリティ改善ジャーニー #devsumi

Developers Summit 2024で登壇したときの資料です。
https://event.shoeisha.jp/devsumi/20240215/session/4837

Transcript

1. 技術的負債との戦い！ PR TIMESエンジニアチームの オブザーバビリティ改善ジャーニー 株式会社PR TIMES 開発本部 インフラチーム テックリード 櫻井 慎也
2. 自己紹介
3. 櫻井 慎也 - PR TIMESの主催するハッカソンインターンで 最優秀賞を獲得し、2018年にPR TIMESに 新卒入社 - サーバーサイドエンジニアを経て インフラチームのテックリードに就任 - New Relicを使った監視基盤の構築や PR TIMESのAWS移行PJのリーダー等を務め る
4. 会社紹介
5. Product｜基幹事業 プレスリリース配信サービスを運営 企業の一次情報が日本で最も集まるプラットフォームとして、国内トップシェア • 利用企業社数 • 国内上場企業利用率 • プレスリリース数 • メディアユーザー数 • パートナーメディア • サイト閲覧数 • SNSアカウント • 個人ユーザー数 91,115社 56.7％ 34,092件 / 月 26,395名 251媒体 8,984万PV / 月 Facebook 129,700 Twitter 457,921 189,902名 　　　　※2023年11月末時点
6. Product｜事業ポートフォリオ プレスリリース配信サービス 「PR TIMES」 ストーリー配信サービス 「PR TIMES STORY」 広報・PRの効果測定サービス 「PR TIMES Webクリッピング」 動画PRサービス 「PR TIMES LIVE」「PR TIMES TV」 クライアントとメディアのパートナーとして広報・PR支援の実施 「PRパートナー事業」
7. Product｜事業ポートフォリオ タスク・プロジェクト管理ツール 「Jooto」 カスタマーサポートツール 「Tayori」 アート特化型オンライン PRプラットフォーム 「MARPH」 トレンドニュースメディア 「ストレートプレス」 Z世代向けWebメディア 「isuta」 若手ビジネスパーソン向け Webメディア 「U-NOTE」 PR・広告・プロモーション事例メディア 「PR EDGE」 スタートアップメディア 「THE BRIDGE」
8. 入社当初のPR TIMES について
9. コード行数が非常に多く、複雑である • サービス開始から10年以上が経過 • コピペで増殖した自社製PHPフレームワーク • ドキュメントやテストコードはほとんどない • call_user_func関数を使った動的な関数呼び出し → 静的解析が効かないのでIDEの機能が活かせない → どこかを変更すると予期せぬ箇所で不具合が発生する
10. 問い合わせがあるまでエラーやバグを検知できない • バグやエラーはお客様からのお問い合わせがあって初めて検 知できる状態 • New Relicは導入されていたがアラートの設定がされていな かったため、突発的に発生したエラーに対応できない
11. レスポンスが遅くデータベースの負荷も高い • N+1問題やスロークエリなどによってレスポンスが悪化 している箇所がいくつもある • データベースの負荷が常時高く、多いときには毎週 フェイルオーバーが発生するような状態 • オンプレの物理サーバーなのでスケールアップするのも難しい
12. サーバーに入らないとログを見られない • ログファイルの転送や集約がされていないので、 ログを見るためにはサーバーにSSH接続する必要がある • 複数台のサーバーが並列で動いているので、それぞれのサー バーのログを確認する必要がある
13. New Relicを使って 改善できたこと
14. エラー監視(APM Errors)
15. エラー監視(APM Errors)
16. エラー監視(APM Errors + Alerts) APMエージェントからNew Relicにエラー送信 New RelicのAlert機能を 使ってSlackに通知
17. エラー監視(APM Errors + Alerts) Slackのメンション機能を 使って通知する Errorsタブへ ワンクリックで 飛べるようにする
18. パフォーマンス改善 (APM Transactions) パフォーマンスを改善するときは 実行回数 × 平均実行時間 = 総実行時間 が大きいものから優先的に対応する！
19. パフォーマンス改善 (APM Transactions)
20. パフォーマンス改善 (APM Transactions) N+1問題が発生していると推測できる データベースの 呼び出し回数
21. ログ監視 (Logs + Alerts) Fluentdを使ってNew Relic Logsにログを転送し、エラーをSlackに通知
22. cron監視 (horenso + Logs + Alerts) horensoというコマンドラッパーツールを使ってcronの 実行結果をログに出力し、そのログをNew Relicで監視する。 出力される内容 • 実行コマンド • 終了コード • 標準出力 • 標準エラー出力 • 開始日時 • 終了日時 など
23. NRQL SQLのようなクエリ言語でNew Relicに保存されている データを取得することができ、アラートやダッシュボード化すること も可能 NRQLで データを取得 アラートを設定 ダッシュボードに 追加 グラフを描画 JSONで出力 CSVで出力 URLを共有
24. NRQL NRQLの構文例 • SELECT, FROM, WHERE : SQLと同じ • FACET : 指定した項目でグループ化 • SINCE, UNTIL : 時間範囲を指定 • TIMESERIES : 時系列データをグラフ化 など 詳しくは NRQLリファレンス を参照
25. NRQL 例 : prtimes.jp のユーザーエージェントごとのアクセス数
26. NRQL 生成AIを使ってNRQLを生成することもできる
27. NRQL 生成AIを使ってNRQLを生成することもできる
28. デプロイスクリプト の改善
29. 改善前のデプロイスクリプトの問題点 • Git上で削除されたファイルがサーバーから削除されない • サーバーごとにフロントエンドのビルドが走るため デプロイに時間がかかる • ソースコードを稼働中のディレクトリにrsyncするため、 変更量が多いとダウンタイムが発生してしまう • 処理が色んなファイルにバラバラに記述されていて 読みにくい
30. 1からデプロイスクリプトを作り直すことを決定 • 複雑な処理は必要ないのでシェルスクリプトで実装 • 処理の流れを分かりやすくするために関数を使わずに コメント+コマンドの羅列で記述 • 以下のオプションをsetコマンドで設定 • set -x : 実行するコマンドを出力 • set -e : エラーが発生したら途中で終了する • set -u : 未定義の変数があればエラーにする
31. ビルドを1回にまとめる サーバーごとにフロントエンドのビルドが走るため デプロイに時間がかかる (ビルド→デプロイ→ビルド→デプロイ→...) ↓ 最初にビルドしてから全てのサーバーにデプロイするように変更す る
32. シンボリックリンクを使った無停止デプロイ ソースコードを稼働中のディレクトリに直接rsyncするため、 デプロイされる順番次第でエラーが発生する可能性がある。 ファイルA ファイルB 呼び出す デプロイサーバー ファイルA 呼び出せない Webサーバー デプロイ リクエスト
33. シンボリックリンクを使った無停止デプロイ → 待機状態の別のディレクトリにrsyncしたあとで シンボリックリンクの向き先を変更することで ダウンタイムなしでデプロイできる。
34. シンボリックリンクを使った無停止デプロイ /var/www/app リクエスト デプロイ 変更前の構成
35. シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト /var/www/app シンボリックリンク /var/www/app2 変更後の構成 コピー
36. シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト デプロイ /var/www/app シンボリックリンク /var/www/app2 変更後の構成
37. シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト /var/www/app シンボリックリンク /var/www/app2 変更後の構成
38. Git上で削除したファイルをサーバー上で削除する • Git上で削除されたファイルがサーバーから削除されない • rsync でデプロイするときに --delete オプションが ついていないのが原因 • 削除時にダウンタイムが発生する可能性があるため(？) • rsync に --delete をつけて実行できるようにしたい
39. Git上で削除したファイルをサーバー上で削除する 1. とりあえず --dry-run と--delete オプションをつけて rsyncコマンドを実行して削除予定のファイルを調べてみる 2. 消してはいけないファイルがあれば --exclude オプションを使っ て除外リストに入れていく • ログファイル • キャッシュファイル • アップロードされたファイル など 3. 消してはいけないファイルがなくなったら --dry-run オプションを消して完了！
40. 改善後のデプロイスクリプト • デプロイ時間は約6分30秒から約2分0秒に大幅改善 • シンボリックリンクを使ってダウンタイムなしで デプロイできるようになった • Git上で削除されたファイルがサーバーから削除されるのでリファ クタリングがしやすくなった
41. マルチステージング環境の 構築
42. 改善前のステージング環境の問題点 ステージング環境が1つしかないため、使用時にアナウンスした り、他の人が使い終わるのを待つ必要があった。 ステージング Webサーバー ステージング 使います まだかな... まだかな...
43. マルチステージングを実現するための方法 ApacheのVirtualDocumentRoot機能を活用した。 使用例 VirtualDocumentRoot "/var/www/%0" のとき、 hoge.example.com でこのサーバーにアクセスすると /var/www/hoge.example.com が 実際のドキュメントルートになる。
44. マルチステージング環境の構成 これにより1台のサーバーで複数のステージング環境を動かすこと ができ、他の人が終わるのを待つ必要がなくなった。 /var/www/alice.example.com *.example.com /var/www/bob.example.com /var/www/charlie.example.com alice.example.com bob.example.com charlie.example.com
45. オンプレから AWSへの移行
46. 当時のオンプレ環境の抱えていた課題 • インフラエンジニアしかサーバーを立ち上げられない • データベースが物理サーバーで動いており、 スケールアップやストレージの拡張ができない • インフラがコード管理されていないため同じ構成の サーバーを立ち上げることができない • オンプレについて詳しいメンバーがおらず 問題が発生しても解決するのが難しい
47. データベースのストレージが枯渇しそう • 既にデータベースのストレージの90%近くを使っており、 一年以内にストレージが枯渇すると予想されていた • 物理サーバーのスロットが空いていないため、 これ以上ストレージを拡張することが不可能 不要なデータ を削減 移行時のミス でWALが急増 約10GB/月の ペースで漸増
48. RDSへの移行で発生した問題 • 当時利用していたPostgreSQLのバージョン(9.6)が RDSのサポート対象外 • バックアップファイルから復元しようとすると数時間 かかる • ストレージが枯渇しかけているため、オンプレ環境で バージョンアップをしている余裕はない → 移行時のダウンタイムを最小限に抑えるために AWS DMSを使ったロジカルレプリケーションを構築し、 バージョンアップとAWSへの移行を同時に行う。
49. Webサーバーやストレージなども同時に移行する データベースのみAWSに移行してしまうと AWS-オンプレ間の専用線がボトルネックになり レスポンスの低下などが発生すると予想されたため、 WebサーバーやBatchサーバー、共有ストレージなども 同時にAWSへ移行する必要があった。
50. AWS移行先の構成図(当時)
51. AWSに移行してみて感じたメリット • データベースが爆速になった
52. AWSに移行してみて感じたメリット • バックアップの取得が爆速になった PostgreSQL NetApp ONTAP AWS移行前 1~2時間 バックアップなし AWS移行後 10分以内 10分以内
53. AWSに移行してみて感じたメリット • IAM管理が楽になった • EC2インスタンスに直接IAMロールをアタッチできるため、 IAMユーザーのアクセスキーをサーバーに保存するよりも 安全かつ管理が楽
54. AWSに移行してみて感じたメリット • 踏み台サーバーが不要になった • AWS Session Managerを使ってサーバーに接続する ので踏み台サーバーを廃止 • Oneloginを使ってAWSの権限を管理しているので 新入社員や退職者の公開鍵の管理が不要に
55. AWSに移行してみて感じたメリット • インフラのコード化がしやすくなった • AWS移行のタイミングでTerraformやAnsibleを使った構 成管理を導入 • インフラ構成がGitHubでバージョン管理できる
56. AWSに移行してみて感じたメリット • New Relicでインフラの監視がしやすくなった • Cloudwatch Metric Streamsを使ってAWSのほぼ全て のリソースのメトリクスをNew Relicに転送できる • RDSやLambdaの出力するログもCloudWatch Logs 経由でNew Relicに転送できる • 転送したデータのクエリやアラートなどが AWSに比べて使いやすい！(個人的感想)
57. AWSに移行してみて感じたメリット • AWSのマネージドサービスを導入しやすくなった • LambdaやS3, OpenSearchなどとの連携がしやすい • IAMロールを使った権限管理が楽 • VPC内で通信できるので高速
58. オブザーバビリティが どう変わったか
59. © 2024 New Relic, Inc. All rights reserved. オブザーバビリティの成熟度とは • レジリエンスのある運用 • 高品質なコードのデリバリ • 複雑さと技術的負債の管理 • 予測可能な間隔でリリース • ユーザーへの洞察 https://info.honeycomb.io/observability-maturity-model-tw/ オブザーバビリティの質が影響する組織の機能
60. オブザーバビリティの成熟度について • レジリエンスのある運用 • 障害が発生してもすぐに検知し対応できるようになった • 高品質なコードのデリバリ • New Relicを使ってエラーの原因やボトルネックの 特定がしやすくなり順調に改善が進んでいる • 予測可能な間隔でリリース • マルチステージングの構築やデプロイスクリプトと リリースフローの改善により高速にリリースサイクルを回す ことができるようになった
61. 今後の課題
62. セキュリティの強化 • プレスリリース配信サービスとして社会インフラを担うためにセ キュリティの強化は必要不可欠 • 直近で実施した施策 • Flatt Security社によるセキュリティ診断 • PHPのバージョンアップ • 今後予定している施策 • Fastly WAFの導入 • New Relic IASTの導入
63. フロントエンドを含めたエンドツーエンドの監視 • サーバーサイドの監視はできるようになってきたが フロントエンドの監視がまだあまりできていない • New RelicのBrowserやSynthetic Monitoringを使って エンドツーエンドの監視を実現したい
64. コード品質の改善 • 最近は良くなってきたもののまだまだレガシーコードは残って いるので、より良いコードに変えていきたい • 監視に必要なログの出力やエラーハンドリングなど オブザーバービリティ向上のための改善もしていきたい
65. We are hiring!!
66. PR TIMES HACKATHON 2024 25卒向け選考直結ハッカソンやります！
67. PR TIMES エンジニア 採用 中途入社も絶賛募集中です！ - VPoE - テックリード - QA - フロントエンド - バックエンド - インフラ - PdM など...