オブザーバビリティの成熟で改善できる、組織の5つの機能とは？
New Relicの小林氏は、自社サービスを「監視ツールと呼ばれがちだが、オブザーバビリティ・プラットフォームとして位置づけている」と紹介する。
オブザーバビリティとは、「システムの状態をリアルタイムで捉え、問題の有無にかかわらずその原因を調査し理解する能力」のことだ。この能力は誰もが持っており、その度合いや成熟度によってその有益性を評価してほしいと小林氏は述べる。
加えて、オブザーバビリティを効果的に活用することで、ユーザーとエンジニア、双方の幸福につながると語る。しかし、その概念は抽象的であるため、特に次の5つの機能が組織の中で強化されることで、幸福度が向上すると解説した。
- レジリエンスのある運用：障害からの迅速な復旧が実現し、システム運用の強化が見込まれる。そのためレジリエンスがあるシステム運用が可能になる。
- 高品質なコードのデリバリー：事前テストを通じて潜在的な障害点を特定できるため、高品質なコードのデリバリーが促進される。
- 複雑さと技術的負債の管理：オブザーバビリティツールを活用することで、運用期間が長くなるにつれて増加するシステムの複雑さや技術的負債の管理を容易にする。
- 予測可能な間隔でリリース：定期的かつ予測可能な間隔での機能リリースが可能になり、デリバリー頻度と生産性の向上が実現できる。
- ユーザーへの洞察：運用中のシステムを通じてユーザー行動の詳細が把握できるため、ユーザーに関する深い洞察が得られ、ビジネスへの貢献が期待できる。
小林氏は、「オブザーバビリティ能力が高い場合、これらの組織の5つの機能が強化され、システムに関わるユーザーと利用するエンドユーザー両方に良い結果が得られます」と述べた。
PR TIMESが直面した3つの課題、コピペコードで複雑化したシステムが抱える負債とは？
次に、PR TIMESの櫻井氏が、オブザーバビリティ向上によるシステム改善の取り組みを解説した。櫻井氏が入社した2018年当時のPR TIMESシステムは多くの課題を抱えており、特に「システムの一部を変更した際に予期せぬ箇所で不具合が発生してしまう」ことが大きな悩みであったと述べた。
課題は、大きく分けると3つあった。1つ目の課題は、コードが非常に多く複雑であった点だ。これは10年以上前に作成された独自のPHPフレームワークがコピー&ペーストによって増殖し、結果としてコード行数が増加、システムが複雑化したためである。
2つ目は、エラーやバグが発生しても、問い合わせがあるまで検知できない点だ。当時からNew Relicが導入されていたものの、エラー監視のアラート設定が適切ではなかったため突発的なエラーを即座に検知できなかった。
第3の課題は、レスポンスの遅延とデータベースの高負荷だ。フェイルオーバーが頻繁に発生し、データベースがオンプレミスであったために、クラウドのように容易にスケールアップできなかった。この課題は作業性にも関連し、ログの確認に各サーバーへSSHで直接アクセスする必要があるため非効率となっていた。
エラー発生時も効率的に対応、「New Relic」のエンジニアフレンドリーな機能
櫻井氏は、これらの課題解決に向けてNew Relicを活用した改善ジャーニーに乗り出す。
エラーの検知に関しては、New Relicの著名な機能であるAPM（アプリケーション・パフォーマンス・モニタリング）を活用した。APM内の「Errors」というタブを使うと、エラーの一覧を発生件数や割合のグラフと共に確認できる。エラークラスやエラーメッセージによるグルーピング機能もあり、「問題発生時やリリース後には、このページを最初に確認するようにしています」と櫻井氏は利便性の高さを評価した。
エラー一覧ページでは、特定のエラーを選択すると詳細ページに遷移し、発生日時やURLなどのデータを確認できる。さらに「Logs in Context」という機能を利用すれば、エラー発生前後のログを閲覧できるので、エラーの原因を効率的に特定できる。エラーの原因特定に必要なデータはこの詳細ページに集約されるので、ここを見るだけで多くのエラー原因を理解できるというわけだ。
またエラーが発生した場合、New RelicならSlackなどのコミュニケーションツールに通知を送ることができる。重要なアラートには担当者へのメンションをつけ詳細ページへのリンクを付与することで、迅速な対応が可能となった。
パフォーマンスの改善では、改善すべき箇所の特定が重要だ。例えばページ表示のパフォーマンス改善なら、アクセスが1日数回のページよりも何万回も表示されるページを優先して改善すべきだ。New RelicのAPMのTransactionsという機能を使うと、総実行時間が長い処理を順に表示したり、平均実行時間や実行回数、エラーレートなどでソートしたりできる。これらの機能により、改善が必要な処理を特定しやすくなった。
ログの監視に関しては、オープンソースのデータ収集ソフトウェア「Fluentd」を活用し、New Relicにログを転送して、New Relic上で確認できる体制を構築した。特に監視が必要なエラーログについては、Slackに通知する仕組みも導入した。また定期的なタスクを実行するcronについても、実行結果のログをNew Relicに転送し監視している。
その他、New Relicには「NRQL（ヌルクル）」という独自のクエリ言語があり、これを使うとNew Relicに保存されているほぼ全てのデータを検索し、表示できる。データはグラフ描画やCSV、JSON形式で出力し、URLを通じた共有やダッシュボードでのアラート作成も可能だ。最近では生成AIが搭載され、テキストの指示だけでもクエリを生成できる。櫻井氏は「NRQLは、個人的にNew Relicで最も気に入っている機能の1つです。まだ試していない方にはぜひ使用をお勧めします」と述べ、この機能の有用性を強調した。
「エンジニア人生に余裕が生まれる」デブロイスクリプトとマルチステージングとは
今回の改善に合わせて、デプロイスクリプトも根本から全面的に見直された。従来は、「デプロイ時間が長い」「ダウンタイムが発生する」「処理がさまざまなファイルに分散していて読みづらい」といった課題が存在していたためだ。
デプロイ時間については、サーバーごとにビルドを行っていたのを、最初に一括でビルドしてから全てのサーバーにデプロイする形に変更し、6分30秒から約2分と大幅に短縮した。そのほか、シンボリックリンクを活用して無停止でデプロイを実施するなど工夫を凝らし、デプロイの高速化を達成している。これら改善により、PR TIMESのエンジニアからは「人生に余裕が生まれた」というポジティブなフィードバックが寄せられていると櫻井氏は報告した。
またステージング環境については、改善前は環境が1つしかなく、使用前に他のエンジニアに連絡するか他の人が使い終わるのを待つ必要があった。そこで、「Apache」のVirtualDocumentRoot機能を活用し、開発者ごとにディレクトリを作成するようにデプロイスクリプトを変更した。これにより1台のサーバーで複数のステージング環境を並行して動かすことができ、複数人で作業を進行できるようになった。
AWSへのクラウド移行でクエリ処理が10倍早く！？ AWS移行のメリットとは
PR TIMESでは、オブザーバビリティ改善と並行して、クラウドへの移行作業も実施された。当初オンプレミス環境において、インフラエンジニア以外がサーバーを立ち上げることはできず、データベースのストレージ使用率が90%を超えるなどクラウドへの移行は緊急の課題であった。1年以内にストレージが枯渇すると見積もられていたほどだ。
このため「Amazon RDS」への移行が検討された。移行時の課題は、「バックアップファイルからの復元に数時間を要すること」と「使用していたPostgreSQLのバージョンが古く、バージョンアップが不可欠だった点」の2つだ。これらは、ダウンタイムを最小限に抑えられるサービスである「AWS DMS」を使用することで、バージョンアップとAWSへの移行を同時に実行して解決した。さらに、データベースだけではなく、Webサーバーや共有ストレージもAWSに移行された。
移行には多くの労力を要したが、その分メリットも大きかったと櫻井氏は振り返る。データベースの処理速度が向上し、移行前のクエリ処理時間が20〜50ミリ秒であったのに対し、移行後は5ミリ秒以下にまで短縮された。毎週のように発生していたフェイルオーバーもなくなり、1〜2時間を要していたバックアップが10分以内に完了するようになった。「AWS IAM」の使用もより簡便になり、移行前は必要だった踏み台サーバーも不要になった。
AWSへの移行でデータベースのクエリ処理時間が大幅に削減
グラフ中央の2022年9月より右が移行後、従来のような山はない
またNew Relicによるシステムの監視も容易になったそうだ。AWSのCloudwatch Metric Streamsという機能を使うと、AWSのほぼ全てのリソースのメトリクスをNew Relicに転送することができるためと櫻井氏は話す。
オブザーバビリティの向上でリリースサイクルが高速化、高品質なコードのデリバリーのポイントは？
今回のオブザーバビリティ改善への旅で、櫻井氏は複数の面の進歩があったと述べる。
「レジリエンスのある運用に関しては、障害を即座に検知し対応できるようになりました。高品質なコードのデリバリーにおいては、New Relicの活用でエラーの原因やボトルネックを特定しやすくなり、デリバリーの品質改善も順調です。予測可能な間隔でのリリースについては、マルチステージング環境の構築やデプロイスクリプト、リリースフローの改善によって、リリースサイクルを高速化できるようになりました」と語り、オブザーバビリティの向上による幅広い利益を強調した。
コードの品質に関しては現在も改善が進んでいるものの、「レガシーコードがまだ残っており、さらに改善して、より良いコードへと変えていきたい」とさらなる改善への期待を示す。
今後の取り組みとしては、セキュリティの強化が目標とのことだ。直近の施策としては、第三者によるセキュリティ診断やPHPのバージョンアップが実施されている。次のステップとして「自動でセキュリティテストを行い、脆弱性を検出する機能を導入したい」と意欲的に語り、セッションのまとめとした。
