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

by shinyasakurai

Slide 1

Slide 1 text

技術的負債との戦い！ PR TIMESエンジニアチームのオブザーバビリティ改善ジャーニー株式会社PR TIMES 開発本部インフラチームテックリード櫻井慎也

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

櫻井慎也 - PR TIMESの主催するハッカソンインターンで最優秀賞を獲得し、2018年にPR TIMESに新卒入社 - サーバーサイドエンジニアを経てインフラチームのテックリードに就任 - New Relicを使った監視基盤の構築や PR TIMESのAWS移行PJのリーダー等を務める

Slide 4

Slide 4 text

会社紹介

Slide 5

Slide 5 text

Product｜基幹事業プレスリリース配信サービスを運営企業の一次情報が日本で最も集まるプラットフォームとして、国内トップシェア ● 利用企業社数 ● 国内上場企業利用率 ● プレスリリース数 ● メディアユーザー数 ● パートナーメディア ● サイト閲覧数 ● SNSアカウント ● 個人ユーザー数 91,115社 56.7％ 34,092件 / 月 26,395名 251媒体 8,984万PV / 月 Facebook 129,700 Twitter 457,921 189,902名　　　　※2023年11月末時点

Slide 6

Slide 6 text

Product｜事業ポートフォリオプレスリリース配信サービス「PR TIMES」ストーリー配信サービス「PR TIMES STORY」広報・PRの効果測定サービス「PR TIMES Webクリッピング」動画PRサービス「PR TIMES LIVE」「PR TIMES TV」クライアントとメディアのパートナーとして広報・PR支援の実施「PRパートナー事業」

Slide 7

Slide 7 text

Product｜事業ポートフォリオタスク・プロジェクト管理ツール「Jooto」カスタマーサポートツール「Tayori」アート特化型オンライン PRプラットフォーム「MARPH」トレンドニュースメディア「ストレートプレス」 Z世代向けWebメディア「isuta」若手ビジネスパーソン向け Webメディア「U-NOTE」 PR・広告・プロモーション事例メディア「PR EDGE」スタートアップメディア「THE BRIDGE」

Slide 8

Slide 8 text

入社当初のPR TIMES について

Slide 9

Slide 9 text

コード行数が非常に多く、複雑である • サービス開始から10年以上が経過 • コピペで増殖した自社製PHPフレームワーク • ドキュメントやテストコードはほとんどない • call_user_func関数を使った動的な関数呼び出し → 静的解析が効かないのでIDEの機能が活かせない → どこかを変更すると予期せぬ箇所で不具合が発生する

Slide 10

Slide 10 text

問い合わせがあるまでエラーやバグを検知できない • バグやエラーはお客様からのお問い合わせがあって初めて検知できる状態 • New Relicは導入されていたがアラートの設定がされていなかったため、突発的に発生したエラーに対応できない

Slide 11

Slide 11 text

レスポンスが遅くデータベースの負荷も高い • N+1問題やスロークエリなどによってレスポンスが悪化している箇所がいくつもある • データベースの負荷が常時高く、多いときには毎週フェイルオーバーが発生するような状態 • オンプレの物理サーバーなのでスケールアップするのも難しい

Slide 12

Slide 12 text

サーバーに入らないとログを見られない • ログファイルの転送や集約がされていないので、ログを見るためにはサーバーにSSH接続する必要がある • 複数台のサーバーが並列で動いているので、それぞれのサーバーのログを確認する必要がある

Slide 13

Slide 13 text

New Relicを使って改善できたこと

Slide 14

Slide 14 text

エラー監視(APM Errors)

Slide 15

Slide 15 text

エラー監視(APM Errors)

Slide 16

Slide 16 text

エラー監視(APM Errors + Alerts) APMエージェントからNew Relicにエラー送信 New RelicのAlert機能を使ってSlackに通知

Slide 17

Slide 17 text

エラー監視(APM Errors + Alerts) Slackのメンション機能を使って通知する Errorsタブへワンクリックで飛べるようにする

Slide 18

Slide 18 text

パフォーマンス改善 (APM Transactions) パフォーマンスを改善するときは実行回数 × 平均実行時間 = 総実行時間が大きいものから優先的に対応する！

Slide 19

Slide 19 text

パフォーマンス改善 (APM Transactions)

Slide 20

Slide 20 text

パフォーマンス改善 (APM Transactions) N+1問題が発生していると推測できるデータベースの呼び出し回数

Slide 21

Slide 21 text

ログ監視 (Logs + Alerts) Fluentdを使ってNew Relic Logsにログを転送し、エラーをSlackに通知

Slide 22

Slide 22 text

cron監視 (horenso + Logs + Alerts) horensoというコマンドラッパーツールを使ってcronの実行結果をログに出力し、そのログをNew Relicで監視する。出力される内容 • 実行コマンド • 終了コード • 標準出力 • 標準エラー出力 • 開始日時 • 終了日時など

Slide 23

Slide 23 text

NRQL SQLのようなクエリ言語でNew Relicに保存されているデータを取得することができ、アラートやダッシュボード化することも可能 NRQLでデータを取得アラートを設定ダッシュボードに追加グラフを描画 JSONで出力 CSVで出力 URLを共有

Slide 24

Slide 24 text

NRQL NRQLの構文例 • SELECT, FROM, WHERE : SQLと同じ • FACET : 指定した項目でグループ化 • SINCE, UNTIL : 時間範囲を指定 • TIMESERIES : 時系列データをグラフ化など詳しくは NRQLリファレンスを参照

Slide 25

Slide 25 text

NRQL 例 : prtimes.jp のユーザーエージェントごとのアクセス数

Slide 26

Slide 26 text

NRQL 生成AIを使ってNRQLを生成することもできる

Slide 27

Slide 27 text

NRQL 生成AIを使ってNRQLを生成することもできる

Slide 28

Slide 28 text

デプロイスクリプトの改善

Slide 29

Slide 29 text

改善前のデプロイスクリプトの問題点 • Git上で削除されたファイルがサーバーから削除されない • サーバーごとにフロントエンドのビルドが走るためデプロイに時間がかかる • ソースコードを稼働中のディレクトリにrsyncするため、変更量が多いとダウンタイムが発生してしまう • 処理が色んなファイルにバラバラに記述されていて読みにくい

Slide 30

Slide 30 text

1からデプロイスクリプトを作り直すことを決定 • 複雑な処理は必要ないのでシェルスクリプトで実装 • 処理の流れを分かりやすくするために関数を使わずにコメント+コマンドの羅列で記述 • 以下のオプションをsetコマンドで設定 • set -x : 実行するコマンドを出力 • set -e : エラーが発生したら途中で終了する • set -u : 未定義の変数があればエラーにする

Slide 31

Slide 31 text

ビルドを1回にまとめるサーバーごとにフロントエンドのビルドが走るためデプロイに時間がかかる (ビルド→デプロイ→ビルド→デプロイ→...) ↓ 最初にビルドしてから全てのサーバーにデプロイするように変更する

Slide 32

Slide 32 text

シンボリックリンクを使った無停止デプロイソースコードを稼働中のディレクトリに直接rsyncするため、デプロイされる順番次第でエラーが発生する可能性がある。ファイルA ファイルB 呼び出すデプロイサーバーファイルA 呼び出せない Webサーバーデプロイリクエスト

Slide 33

Slide 33 text

シンボリックリンクを使った無停止デプロイ → 待機状態の別のディレクトリにrsyncしたあとでシンボリックリンクの向き先を変更することでダウンタイムなしでデプロイできる。

Slide 34

Slide 34 text

シンボリックリンクを使った無停止デプロイ /var/www/app リクエストデプロイ変更前の構成

Slide 35

Slide 35 text

シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト /var/www/app シンボリックリンク /var/www/app2 変更後の構成コピー

Slide 36

Slide 36 text

シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエストデプロイ /var/www/app シンボリックリンク /var/www/app2 変更後の構成

Slide 37

Slide 37 text

シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト /var/www/app シンボリックリンク /var/www/app2 変更後の構成

Slide 38

Slide 38 text

Git上で削除したファイルをサーバー上で削除する • Git上で削除されたファイルがサーバーから削除されない • rsync でデプロイするときに --delete オプションがついていないのが原因 • 削除時にダウンタイムが発生する可能性があるため(？) • rsync に --delete をつけて実行できるようにしたい

Slide 39

Slide 39 text

Git上で削除したファイルをサーバー上で削除する 1. とりあえず --dry-run と--delete オプションをつけて rsyncコマンドを実行して削除予定のファイルを調べてみる 2. 消してはいけないファイルがあれば --exclude オプションを使って除外リストに入れていく • ログファイル • キャッシュファイル • アップロードされたファイルなど 3. 消してはいけないファイルがなくなったら --dry-run オプションを消して完了！

Slide 40

Slide 40 text

改善後のデプロイスクリプト • デプロイ時間は約6分30秒から約2分0秒に大幅改善 • シンボリックリンクを使ってダウンタイムなしでデプロイできるようになった • Git上で削除されたファイルがサーバーから削除されるのでリファクタリングがしやすくなった

Slide 41

Slide 41 text

マルチステージング環境の構築

Slide 42

Slide 42 text

改善前のステージング環境の問題点ステージング環境が1つしかないため、使用時にアナウンスしたり、他の人が使い終わるのを待つ必要があった。ステージング Webサーバーステージング使いますまだかな... まだかな...

Slide 43

Slide 43 text

マルチステージングを実現するための方法 ApacheのVirtualDocumentRoot機能を活用した。使用例 VirtualDocumentRoot "/var/www/%0" のとき、 hoge.example.com でこのサーバーにアクセスすると /var/www/hoge.example.com が実際のドキュメントルートになる。

Slide 44

Slide 44 text

マルチステージング環境の構成これにより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

Slide 45

Slide 45 text

オンプレから AWSへの移行

Slide 46

Slide 46 text

当時のオンプレ環境の抱えていた課題 • インフラエンジニアしかサーバーを立ち上げられない • データベースが物理サーバーで動いており、スケールアップやストレージの拡張ができない • インフラがコード管理されていないため同じ構成のサーバーを立ち上げることができない • オンプレについて詳しいメンバーがおらず問題が発生しても解決するのが難しい

Slide 47

Slide 47 text

データベースのストレージが枯渇しそう • 既にデータベースのストレージの90%近くを使っており、一年以内にストレージが枯渇すると予想されていた • 物理サーバーのスロットが空いていないため、これ以上ストレージを拡張することが不可能不要なデータを削減移行時のミスでWALが急増約10GB/月のペースで漸増

Slide 48

Slide 48 text

RDSへの移行で発生した問題 • 当時利用していたPostgreSQLのバージョン(9.6)が RDSのサポート対象外 • バックアップファイルから復元しようとすると数時間かかる • ストレージが枯渇しかけているため、オンプレ環境でバージョンアップをしている余裕はない → 移行時のダウンタイムを最小限に抑えるために AWS DMSを使ったロジカルレプリケーションを構築し、バージョンアップとAWSへの移行を同時に行う。

Slide 49

Slide 49 text

Webサーバーやストレージなども同時に移行するデータベースのみAWSに移行してしまうと AWS-オンプレ間の専用線がボトルネックになりレスポンスの低下などが発生すると予想されたため、 WebサーバーやBatchサーバー、共有ストレージなども同時にAWSへ移行する必要があった。

Slide 50

Slide 50 text

AWS移行先の構成図(当時)

Slide 51

Slide 51 text

AWSに移行してみて感じたメリット • データベースが爆速になった

Slide 52

Slide 52 text

AWSに移行してみて感じたメリット • バックアップの取得が爆速になった PostgreSQL NetApp ONTAP AWS移行前 1~2時間バックアップなし AWS移行後 10分以内 10分以内

Slide 53

Slide 53 text

AWSに移行してみて感じたメリット • IAM管理が楽になった • EC2インスタンスに直接IAMロールをアタッチできるため、 IAMユーザーのアクセスキーをサーバーに保存するよりも安全かつ管理が楽

Slide 54

Slide 54 text

AWSに移行してみて感じたメリット • 踏み台サーバーが不要になった • AWS Session Managerを使ってサーバーに接続するので踏み台サーバーを廃止 • Oneloginを使ってAWSの権限を管理しているので新入社員や退職者の公開鍵の管理が不要に

Slide 55

Slide 55 text

AWSに移行してみて感じたメリット • インフラのコード化がしやすくなった • AWS移行のタイミングでTerraformやAnsibleを使った構成管理を導入 • インフラ構成がGitHubでバージョン管理できる

Slide 56

Slide 56 text

AWSに移行してみて感じたメリット • New Relicでインフラの監視がしやすくなった • Cloudwatch Metric Streamsを使ってAWSのほぼ全てのリソースのメトリクスをNew Relicに転送できる • RDSやLambdaの出力するログもCloudWatch Logs 経由でNew Relicに転送できる • 転送したデータのクエリやアラートなどが AWSに比べて使いやすい！(個人的感想)

Slide 57

Slide 57 text

AWSに移行してみて感じたメリット • AWSのマネージドサービスを導入しやすくなった • LambdaやS3, OpenSearchなどとの連携がしやすい • IAMロールを使った権限管理が楽 • VPC内で通信できるので高速

Slide 58

Slide 58 text

オブザーバビリティがどう変わったか

Slide 59

Slide 59 text

© 2024 New Relic, Inc. All rights reserved. オブザーバビリティの成熟度とは ● レジリエンスのある運用 ● 高品質なコードのデリバリ ● 複雑さと技術的負債の管理 ● 予測可能な間隔でリリース ● ユーザーへの洞察 https://info.honeycomb.io/observability-maturity-model-tw/ オブザーバビリティの質が影響する組織の機能

Slide 60

Slide 60 text

オブザーバビリティの成熟度について • レジリエンスのある運用 • 障害が発生してもすぐに検知し対応できるようになった • 高品質なコードのデリバリ • New Relicを使ってエラーの原因やボトルネックの特定がしやすくなり順調に改善が進んでいる • 予測可能な間隔でリリース • マルチステージングの構築やデプロイスクリプトとリリースフローの改善により高速にリリースサイクルを回すことができるようになった

Slide 61

Slide 61 text

今後の課題

Slide 62

Slide 62 text

セキュリティの強化 • プレスリリース配信サービスとして社会インフラを担うためにセキュリティの強化は必要不可欠 • 直近で実施した施策 • Flatt Security社によるセキュリティ診断 • PHPのバージョンアップ • 今後予定している施策 • Fastly WAFの導入 • New Relic IASTの導入

Slide 63

Slide 63 text

フロントエンドを含めたエンドツーエンドの監視 • サーバーサイドの監視はできるようになってきたがフロントエンドの監視がまだあまりできていない • New RelicのBrowserやSynthetic Monitoringを使ってエンドツーエンドの監視を実現したい

Slide 64

Slide 64 text

コード品質の改善 • 最近は良くなってきたもののまだまだレガシーコードは残っているので、より良いコードに変えていきたい • 監視に必要なログの出力やエラーハンドリングなどオブザーバービリティ向上のための改善もしていきたい

Slide 65

Slide 65 text

We are hiring!!

Slide 66

Slide 66 text

PR TIMES HACKATHON 2024 25卒向け選考直結ハッカソンやります！

Slide 67

Slide 67 text

PR TIMES エンジニア採用中途入社も絶賛募集中です！ - VPoE - テックリード - QA - フロントエンド - バックエンド - インフラ - PdM など...