Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
技術的負債との戦い! PR TIMESエンジニアチームの オブザーバビリティ改善ジャーニー #...
Search
shinyasakurai
February 18, 2024
Programming
1
1.8k
技術的負債との戦い! PR TIMESエンジニアチームの オブザーバビリティ改善ジャーニー #devsumi
Developers Summit 2024で登壇したときの資料です。
https://event.shoeisha.jp/devsumi/20240215/session/4837
shinyasakurai
February 18, 2024
Tweet
Share
More Decks by shinyasakurai
See All by shinyasakurai
月間7500万PVのサービスのCDNをFastlyに移行してみた
shinyasakurai
0
270
Other Decks in Programming
See All in Programming
開発を加速する共有Swift Package実践
elmetal
PRO
0
300
TypeScriptで 負荷テストを書こう 〜k6のシングルバイナリの秘密〜
dora1998
7
2.8k
仮想ファイルシステムを導入して開発環境のストレージ課題を解消する
segadevtech
2
390
健康第一!MetricKitで始めるアプリの健康診断 / App Health Checkups Starting with MetricKit
nekowen
4
790
ゲームボーイアドバンスでSwiftを動かそう
k_koheyi
0
510
REXML改善のその後
naitoh
0
150
めざせ!WKWebViewマスター! / WKWebView Master
marcy731
3
480
Hono・Prisma・AWSでGeoなAPI開発
nokonoko1203
5
610
TypeScriptとGraphQLを活用した変化に強いプロダクト作り
bicstone
4
550
【TID2024】模擬講義:プログラマと一緒にゲームをデザインしてみよう!
akatsukigames_tech
0
380
The Future of Frontend i18n : Intl.MessageFormat
sajikix
1
2.4k
dotfiles について話したい #湘なんか
stefafafan
2
280
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
47
2.7k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
3k
[RailsConf 2023] Rails as a piece of cake
palkan
44
4.6k
Build your cross-platform service in a week with App Engine
jlugia
228
18k
Principles of Awesome APIs and How to Build Them.
keavy
125
16k
WebSockets: Embracing the real-time Web
robhawkes
59
7.3k
GitHub's CSS Performance
jonrohan
1029
450k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
24
2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
32k
Git: the NoSQL Database
bkeepers
PRO
425
64k
Transcript
技術的負債との戦い! PR TIMESエンジニアチームの オブザーバビリティ改善ジャーニー 株式会社PR TIMES 開発本部 インフラチーム テックリード 櫻井
慎也
自己紹介
櫻井 慎也 - PR TIMESの主催するハッカソンインターンで 最優秀賞を獲得し、2018年にPR TIMESに 新卒入社 - サーバーサイドエンジニアを経て
インフラチームのテックリードに就任 - New Relicを使った監視基盤の構築や PR TIMESのAWS移行PJのリーダー等を務め る
会社紹介
Product|基幹事業 プレスリリース配信サービスを運営 企業の一次情報が日本で最も集まるプラットフォームとして、国内トップシェア • 利用企業社数 • 国内上場企業利用率 • プレスリリース数 •
メディアユーザー数 • パートナーメディア • サイト閲覧数 • SNSアカウント • 個人ユーザー数 91,115社 56.7% 34,092件 / 月 26,395名 251媒体 8,984万PV / 月 Facebook 129,700 Twitter 457,921 189,902名 ※2023年11月末時点
Product|事業ポートフォリオ プレスリリース配信サービス 「PR TIMES」 ストーリー配信サービス 「PR TIMES STORY」 広報・PRの効果測定サービス 「PR
TIMES Webクリッピング」 動画PRサービス 「PR TIMES LIVE」「PR TIMES TV」 クライアントとメディアのパートナーとして広報・PR支援の実施 「PRパートナー事業」
Product|事業ポートフォリオ タスク・プロジェクト管理ツール 「Jooto」 カスタマーサポートツール 「Tayori」 アート特化型オンライン PRプラットフォーム 「MARPH」 トレンドニュースメディア 「ストレートプレス」
Z世代向けWebメディア 「isuta」 若手ビジネスパーソン向け Webメディア 「U-NOTE」 PR・広告・プロモーション事例メディア 「PR EDGE」 スタートアップメディア 「THE BRIDGE」
入社当初のPR TIMES について
コード行数が非常に多く、複雑である • サービス開始から10年以上が経過 • コピペで増殖した自社製PHPフレームワーク • ドキュメントやテストコードはほとんどない • call_user_func関数を使った動的な関数呼び出し →
静的解析が効かないのでIDEの機能が活かせない → どこかを変更すると予期せぬ箇所で不具合が発生する
問い合わせがあるまでエラーやバグを検知できない • バグやエラーはお客様からのお問い合わせがあって初めて検 知できる状態 • New Relicは導入されていたがアラートの設定がされていな かったため、突発的に発生したエラーに対応できない
レスポンスが遅くデータベースの負荷も高い • N+1問題やスロークエリなどによってレスポンスが悪化 している箇所がいくつもある • データベースの負荷が常時高く、多いときには毎週 フェイルオーバーが発生するような状態 • オンプレの物理サーバーなのでスケールアップするのも難しい
サーバーに入らないとログを見られない • ログファイルの転送や集約がされていないので、 ログを見るためにはサーバーにSSH接続する必要がある • 複数台のサーバーが並列で動いているので、それぞれのサー バーのログを確認する必要がある
New Relicを使って 改善できたこと
エラー監視(APM Errors)
エラー監視(APM Errors)
エラー監視(APM Errors + Alerts) APMエージェントからNew Relicにエラー送信 New RelicのAlert機能を 使ってSlackに通知
エラー監視(APM Errors + Alerts) Slackのメンション機能を 使って通知する Errorsタブへ ワンクリックで 飛べるようにする
パフォーマンス改善 (APM Transactions) パフォーマンスを改善するときは 実行回数 × 平均実行時間 = 総実行時間 が大きいものから優先的に対応する!
パフォーマンス改善 (APM Transactions)
パフォーマンス改善 (APM Transactions) N+1問題が発生していると推測できる データベースの 呼び出し回数
ログ監視 (Logs + Alerts) Fluentdを使ってNew Relic Logsにログを転送し、エラーをSlackに通知
cron監視 (horenso + Logs + Alerts) horensoというコマンドラッパーツールを使ってcronの 実行結果をログに出力し、そのログをNew Relicで監視する。 出力される内容
• 実行コマンド • 終了コード • 標準出力 • 標準エラー出力 • 開始日時 • 終了日時 など
NRQL SQLのようなクエリ言語でNew Relicに保存されている データを取得することができ、アラートやダッシュボード化すること も可能 NRQLで データを取得 アラートを設定 ダッシュボードに 追加
グラフを描画 JSONで出力 CSVで出力 URLを共有
NRQL NRQLの構文例 • SELECT, FROM, WHERE : SQLと同じ • FACET
: 指定した項目でグループ化 • SINCE, UNTIL : 時間範囲を指定 • TIMESERIES : 時系列データをグラフ化 など 詳しくは NRQLリファレンス を参照
NRQL 例 : prtimes.jp のユーザーエージェントごとのアクセス数
NRQL 生成AIを使ってNRQLを生成することもできる
NRQL 生成AIを使ってNRQLを生成することもできる
デプロイスクリプト の改善
改善前のデプロイスクリプトの問題点 • Git上で削除されたファイルがサーバーから削除されない • サーバーごとにフロントエンドのビルドが走るため デプロイに時間がかかる • ソースコードを稼働中のディレクトリにrsyncするため、 変更量が多いとダウンタイムが発生してしまう •
処理が色んなファイルにバラバラに記述されていて 読みにくい
1からデプロイスクリプトを作り直すことを決定 • 複雑な処理は必要ないのでシェルスクリプトで実装 • 処理の流れを分かりやすくするために関数を使わずに コメント+コマンドの羅列で記述 • 以下のオプションをsetコマンドで設定 • set
-x : 実行するコマンドを出力 • set -e : エラーが発生したら途中で終了する • set -u : 未定義の変数があればエラーにする
ビルドを1回にまとめる サーバーごとにフロントエンドのビルドが走るため デプロイに時間がかかる (ビルド→デプロイ→ビルド→デプロイ→...) ↓ 最初にビルドしてから全てのサーバーにデプロイするように変更す る
シンボリックリンクを使った無停止デプロイ ソースコードを稼働中のディレクトリに直接rsyncするため、 デプロイされる順番次第でエラーが発生する可能性がある。 ファイルA ファイルB 呼び出す デプロイサーバー ファイルA 呼び出せない Webサーバー
デプロイ リクエスト
シンボリックリンクを使った無停止デプロイ → 待機状態の別のディレクトリにrsyncしたあとで シンボリックリンクの向き先を変更することで ダウンタイムなしでデプロイできる。
シンボリックリンクを使った無停止デプロイ /var/www/app リクエスト デプロイ 変更前の構成
シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト /var/www/app シンボリックリンク /var/www/app2 変更後の構成 コピー
シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト デプロイ /var/www/app シンボリックリンク /var/www/app2 変更後の構成
シンボリックリンクを使った無停止デプロイ /var/www/app1 リクエスト /var/www/app シンボリックリンク /var/www/app2 変更後の構成
Git上で削除したファイルをサーバー上で削除する • Git上で削除されたファイルがサーバーから削除されない • rsync でデプロイするときに --delete オプションが ついていないのが原因 •
削除時にダウンタイムが発生する可能性があるため(?) • rsync に --delete をつけて実行できるようにしたい
Git上で削除したファイルをサーバー上で削除する 1. とりあえず --dry-run と--delete オプションをつけて rsyncコマンドを実行して削除予定のファイルを調べてみる 2. 消してはいけないファイルがあれば --exclude
オプションを使っ て除外リストに入れていく • ログファイル • キャッシュファイル • アップロードされたファイル など 3. 消してはいけないファイルがなくなったら --dry-run オプションを消して完了!
改善後のデプロイスクリプト • デプロイ時間は約6分30秒から約2分0秒に大幅改善 • シンボリックリンクを使ってダウンタイムなしで デプロイできるようになった • Git上で削除されたファイルがサーバーから削除されるのでリファ クタリングがしやすくなった
マルチステージング環境の 構築
改善前のステージング環境の問題点 ステージング環境が1つしかないため、使用時にアナウンスした り、他の人が使い終わるのを待つ必要があった。 ステージング Webサーバー ステージング 使います まだかな... まだかな...
マルチステージングを実現するための方法 ApacheのVirtualDocumentRoot機能を活用した。 使用例 VirtualDocumentRoot "/var/www/%0" のとき、 hoge.example.com でこのサーバーにアクセスすると /var/www/hoge.example.com が
実際のドキュメントルートになる。
マルチステージング環境の構成 これにより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
オンプレから AWSへの移行
当時のオンプレ環境の抱えていた課題 • インフラエンジニアしかサーバーを立ち上げられない • データベースが物理サーバーで動いており、 スケールアップやストレージの拡張ができない • インフラがコード管理されていないため同じ構成の サーバーを立ち上げることができない •
オンプレについて詳しいメンバーがおらず 問題が発生しても解決するのが難しい
データベースのストレージが枯渇しそう • 既にデータベースのストレージの90%近くを使っており、 一年以内にストレージが枯渇すると予想されていた • 物理サーバーのスロットが空いていないため、 これ以上ストレージを拡張することが不可能 不要なデータ を削減 移行時のミス
でWALが急増 約10GB/月の ペースで漸増
RDSへの移行で発生した問題 • 当時利用していたPostgreSQLのバージョン(9.6)が RDSのサポート対象外 • バックアップファイルから復元しようとすると数時間 かかる • ストレージが枯渇しかけているため、オンプレ環境で バージョンアップをしている余裕はない
→ 移行時のダウンタイムを最小限に抑えるために AWS DMSを使ったロジカルレプリケーションを構築し、 バージョンアップとAWSへの移行を同時に行う。
Webサーバーやストレージなども同時に移行する データベースのみAWSに移行してしまうと AWS-オンプレ間の専用線がボトルネックになり レスポンスの低下などが発生すると予想されたため、 WebサーバーやBatchサーバー、共有ストレージなども 同時にAWSへ移行する必要があった。
AWS移行先の構成図(当時)
AWSに移行してみて感じたメリット • データベースが爆速になった
AWSに移行してみて感じたメリット • バックアップの取得が爆速になった PostgreSQL NetApp ONTAP AWS移行前 1~2時間 バックアップなし AWS移行後
10分以内 10分以内
AWSに移行してみて感じたメリット • IAM管理が楽になった • EC2インスタンスに直接IAMロールをアタッチできるため、 IAMユーザーのアクセスキーをサーバーに保存するよりも 安全かつ管理が楽
AWSに移行してみて感じたメリット • 踏み台サーバーが不要になった • AWS Session Managerを使ってサーバーに接続する ので踏み台サーバーを廃止 • Oneloginを使ってAWSの権限を管理しているので
新入社員や退職者の公開鍵の管理が不要に
AWSに移行してみて感じたメリット • インフラのコード化がしやすくなった • AWS移行のタイミングでTerraformやAnsibleを使った構 成管理を導入 • インフラ構成がGitHubでバージョン管理できる
AWSに移行してみて感じたメリット • New Relicでインフラの監視がしやすくなった • Cloudwatch Metric Streamsを使ってAWSのほぼ全て のリソースのメトリクスをNew Relicに転送できる
• RDSやLambdaの出力するログもCloudWatch Logs 経由でNew Relicに転送できる • 転送したデータのクエリやアラートなどが AWSに比べて使いやすい!(個人的感想)
AWSに移行してみて感じたメリット • AWSのマネージドサービスを導入しやすくなった • LambdaやS3, OpenSearchなどとの連携がしやすい • IAMロールを使った権限管理が楽 • VPC内で通信できるので高速
オブザーバビリティが どう変わったか
© 2024 New Relic, Inc. All rights reserved. オブザーバビリティの成熟度とは •
レジリエンスのある運用 • 高品質なコードのデリバリ • 複雑さと技術的負債の管理 • 予測可能な間隔でリリース • ユーザーへの洞察 https://info.honeycomb.io/observability-maturity-model-tw/ オブザーバビリティの質が影響する組織の機能
オブザーバビリティの成熟度について • レジリエンスのある運用 • 障害が発生してもすぐに検知し対応できるようになった • 高品質なコードのデリバリ • New Relicを使ってエラーの原因やボトルネックの
特定がしやすくなり順調に改善が進んでいる • 予測可能な間隔でリリース • マルチステージングの構築やデプロイスクリプトと リリースフローの改善により高速にリリースサイクルを回す ことができるようになった
今後の課題
セキュリティの強化 • プレスリリース配信サービスとして社会インフラを担うためにセ キュリティの強化は必要不可欠 • 直近で実施した施策 • Flatt Security社によるセキュリティ診断 •
PHPのバージョンアップ • 今後予定している施策 • Fastly WAFの導入 • New Relic IASTの導入
フロントエンドを含めたエンドツーエンドの監視 • サーバーサイドの監視はできるようになってきたが フロントエンドの監視がまだあまりできていない • New RelicのBrowserやSynthetic Monitoringを使って エンドツーエンドの監視を実現したい
コード品質の改善 • 最近は良くなってきたもののまだまだレガシーコードは残って いるので、より良いコードに変えていきたい • 監視に必要なログの出力やエラーハンドリングなど オブザーバービリティ向上のための改善もしていきたい
We are hiring!!
PR TIMES HACKATHON 2024 25卒向け選考直結ハッカソンやります!
PR TIMES エンジニア 採用 中途入社も絶賛募集中です! - VPoE - テックリード -
QA - フロントエンド - バックエンド - インフラ - PdM など...