累計580万人（2020年12月末時点） ものユーザーに利用されてきた、転職サービス「doda」。その安全性と安定性を守り、より快適なサービスを提供し続けられるのは、基盤を支える保守・監視体制が万全であるからこそ、実現できています。よりこの体制を盤石なものにすべく、今回行われたのが “Datadog導入プロジェクト”です。
かねてから抱えていた課題をどのように解決し、またこの先どのような未来を描いているのか。PMとして取り組みを推進したプロダクト開発統括部 プロダクト開発部 アーキテクトグループの石川と、技術支援として協同したインフラ基盤統括部 システム共通BITA部 IT基盤グループの森本に話を聞きました。
※森本は退職していますが、本人の同意を得て掲載を継続しています。
サービスを安全に、安定して提供するために――必要な保守・監視の課題解決へ
――まずは、今回のDatadog導入プロジェクトの概要と、お二人それぞれの役割から教えてください。
石川：今回、dodaの主要サーバーの保守・監視において「障害時に素早く原因を究明でき、また効率的に月次での分析ができている状態」を目指すべく、クラウド型システム監視サービス「Datadog」の導入に取り組みました。私はPMとして、要件の決定や予算管理、社内稟議の対応など、全体の管理の役割を担っています。
森本：私は、所属するIT基盤グループで監視も含めたIT基盤領域の改善に取り組んでいるため、今回は技術支援として、Datadog導入から活用までの課題解決方法を提案していく役割で入らせていただきました。
――これまでのdodaのサーバー保守・監視体制には、どのような課題があったのでしょうか。
石川：主に3つのシステム上の課題がありました。
まず1つは、これまで全社共通で利用してきた保守・監視ツールでは、保守に必要な情報が十分取得できていなかったこと。サイトや特定の機能が動かなくなるなど障害が起きたときに、すぐには原因が究明できず、必要な情報を得るためには都度シェルを記載して監視項目を追加し、障害の再発を待たなければいけない状況でした。
また全社で利用しているため、負荷の都合上1分おきの計測しかできず、1分未満の障害が検知できなかったのです。
2つ目は、dodaで利用しているオンプレ型のElastic APMでは、数日分のデータのみで、長い目で見たデータ推移の監視や比較分析ができませんでした。
そして3つ目は、収集したデータを可視化する手段がなく、集計・分析と資料作成に工数がかかってしまっていたこと。月次でメトリクスの推移やアクセスログ分析、パフォーマンス分析を行うにあたり、CSVを都度加工しなければシステム状況やデータ同士の相関関係を確認できない状態でした。
森本：そして以前からこのような課題を抱えていたにも関わらず、既存の監視方法が当たり前のものとして受け入れられ、見直しなどが行われてこなかったという体制基盤の問題も少なからずありましたね。
――そうして長期的に抱えていた課題に、今回取り組むことになった背景を教えてください。
石川：まずは、今回導入したDatadogのように包括的なデータを取得して可視化できる便利なツールが、ここ数年の間に登場し始めていました。ちょうど検討していた時に、Datadog社の方から「トライアルをやってみないか」とお声がけをいただき、接点ができたことが一つのきっかけになりました。
そして、この時期に組織の構造が大きく変化したことも要因ですね。それまで、機能開発には積極的に投資がなされる中で、機能を「守る」部分が劣後してしまう傾向にありました。しかしちょうどトライアルで検証を始めた頃に、保守や運用など「正しくサービスを提供するために必要な取り組みにも力を注いでいこうという方針になりました。
この変化を受けて、今回長い間抱えていた課題に向き合うことになったのだと認識しています。
――会社としても、体制を変えていこうという動きがあったのですね。保守・監視体制の根本に関わる根深い課題だったようですが、今回改善に乗り出すにあたり、どのようにプロジェクトを進めていかれたのでしょうか。
石川：まずはDatadogをトライアルで導入して、正しく使えそうな機能とその仕様を検証すると共に、他の類似サービスについても、機能やコスト、仕様に対する評判などを調べていました。比較検討からスタートし、現実的なコスト感と、抱えている課題を改善できそうな仕様が確認できたことで、Datadogの導入が決定しました。
森本：Datadogの場合、あらかじめ監視項目が埋め込まれているため項目追加の手間もなく、サーバーにエージェントをインストールするだけで、必要な詳細メトリクスを可視化できます。またAPM機能を利用すれば、一定の期間での比較・分析が行えますし、ダッシュボード機能などによって手動での集計工数も大幅に削減が可能です。
そしてこれらの機能が全て一つのプラットフォームで構築されているため、一元管理がしやすく、また最初に導入しなかった機能の追加も難易度が高くありません。こうした様々な要素が決め手になりましたね。
――ツールが決まってからは、一気に導入が進められたのですか？
石川：導入すると決まった後もやってみないと分からないことが多く、進める中で要件や構成が変動する可能性もあったため、軌道修正しながら慎重に進めていく必要がありました。
そこで、「フェーズ1：すぐにやりたいこと」「フェーズ2：やりたいが、直近でなくてよいもの」「フェーズ3：理想論ではやるべきだが、効果を再検証する必要のあるもの」の3フェーズを設定し、優先度によって課題を分類。障害が発生したときの素早い原因調査や、月次集計業務の工数削減をフェーズ1に、コストの削減やAWSやAkamai などの情報を取り込んで一元管理できるような仕組みをフェーズ2に。そしていずれはツールを一本化することを、理想としてフェーズ3に据え、順に取り組み始めました。
本当に使いやすく、意味があるものを見極める
――メトリクスを最適化することを最優先に、プロジェクトが本格的に進められる中、実際にDatadogはどのような形で導入されたのでしょうか。
石川：まず導入範囲は、サービスの障害発生時に明確な反応が起きるものや、転職希望者の方に直接的な影響のあるものなど、主要なサーバーに絞っています。
また機能も、闇雲に全て導入するのではなく、正しく活用できるものに絞りました。サーバーのCPUやメモリ、ディスクなど基本的な情報を監視するinfrastructureと、各サーバーのアクセスログやエラーログを一元管理し、分析の工数削減に役立てられるLog managerは全台に導入。またアクション別、メソッド別のパフォーマンス分析ができるAPMの機能は、全台ではなく必要性のある一部に導入しています。
一方で、APMで取得した情報を俯瞰的に分析できるanalysisや、Datadog対象ホスト間のin/outのパケット可視化ができるnetworkなどの機能は、トライアルで目に見える改善の効果や今後の活用法が見出せなかったため、導入しない選択をしました。
――全てをDatadogに置き換えればよい、という訳ではないのですね。
森本：そもそも全てのサーバーを現在のツールで監視しており、これは絶対に必要で今後も維持されることです。その上で費用をかけてSaaSを導入するのであれば、コストと効果を考えて必要性を吟味する視点が欠かせません。
年に一度障害が起きるか起きないか、というサーバーにも導入するのか、分析をしても必要な情報が得られるかはわからないところを、スコープに入れるのか、などコストを使うからには、冷静に見極めていく必要があります。
石川：システムによって、最適なツールやその運用方法はそれぞれ異なるため、全てをDatadogに統一すればよいかというと、必ずしもそうではありません。管理者が本当に使いやすく、意味があると判断したものを入れていくのが望ましいのだと考えています。
フェーズ3でツールの一本化を掲げていますが、これもあくまで理想論です。dodaは独立しておらず、一部他のチームと共有しているサーバーもあるため、全てを変更するには全社的な取り組みが必要です。そしてそれをするだけの重大な効果が見込まれているわけでもないですから、有意義な範囲で導入ができればよいかなと思います。
――導入にあたっての困難やハードルなどはありましたか？
森本：機能の導入については、トライアルを行っていますしDatadogg社からのサポートもいただいているので、特に困難を感じることはありませんでした。
一歩進んで、データを可視化する上では、アウトプットの仕方に工夫が必要という点での難しさはありました。誰が何を目的にこのデータを見るのかを考えて、ただ可視化するのではなく使い勝手や分析のしやすさを考慮しながら、表現方法を変えていく必要があります。ここは運用者にヒアリングをして試行錯誤した部分でしたし、これからも工夫と調整が求められると思っています。
――大きな困難もなく導入が進められたのは、2人の連携があってのことだったのではないでしょうか。
石川：そうですね。自分1人で取り組むと「チカラでなんとかする」というところに落ち着きがちですが、手が回らない部分や、知見が足りずに考慮できない部分について、森本さんに技術的な提案や調査をいただけたのがありがたかったですね。自分では思いつかないところに指摘をもらったり、自分ではここまでやらなかっただろうというところまで作り込んでもらったりと、有機的な連携ができたと思っています。
森本：なんだかうれしいですね（笑）私も本当にやりやすく進めさせていただきました。。自分でやれるところはできるだけ手を動かして、推進力をもって進められるよう意識していましたが、PMとして判断していただくべきところが多々あったので、相談・報告しながら連携できたのかなと。
特に私たちのサービスが扱うのはユーザーさんの大切な個人情報なので、情報セキュリティとの調整に苦労する部分がありましたが、1人では難しいなと思った時に石川さんに助けていただき、うまく進めてこられたなと実感しています。
「監視の民主化」を実現するための、第1歩に
――2人で乗り越えて来られた今回のプロジェクト。現段階での進捗はいかがでしょうか。
石川：フェーズ2までが完了し、最初に思い描いていたことはほぼ達成できました。障害時の原因分析が迅速にできる状態が構築され、また当初工数をかけて手動で行っていた分析・可視化についても、Datadogのダッシュボード機能によってリアルタイムでデータを表示・追跡できる状態になっています。
――もうフェーズ2まで！フェーズ3は今見えている景色によって変わってくるのだと思いますが、今後取り組みたいことや課題として考えていらっしゃることはありますか？
石川：まずは監視とビジネスのインパクトとの相関が弱いことですね。ビジネスへの影響度と監視が連動して、緊急度などもうまく表現できるようになるといいなと思っていて。「このような事象が起きたら、優先度はこうなる」など、ビジネスとシステムの内容を紐付ける定義づけに取り組んでいく必要があります。
また体制上の問題として、今は保守は保守担当しか担っていない状況です。スクラムチームは機能開発だけを担っていて、大きな障害があった場合に協力する以外は、基本的には保守は切り分けられた作業になっています。しかし理想としては、機能開発をしている人も、自身が扱っているシステムについては保守に対しても責任をもち、全員で保守を回していくのがあるべき状態なのではと思うのです。
ただ有事の際に原因にあたりをつけることは、スキルがあるエンジニアでないと難しいのが現状ですし、セキュリティ上、本番データを大勢で触らない方がいいという問題もあって。そのため一概にこうすべき、とは言えませんが、都度監視項目を作り込まなくてもデータを把握できる状態になったことは、今回大きな一歩だったのかなと振り返ります。
森本：そうですね。システムの状況を見たいときに各自がグラフを見て分析したり、見たいグラフがないときは自分で作って分析できたり。そうして開発者と保守運用者の切り分けなく「監視の民主化」を実現する、一つのきっかけになったらいいですね。
個人的には、ユーザーさんにフォーカスして、サービスを気持ちよく使っていただけるように、開発したものが適切に監視されている状態を表現していきたいです。何かが起きた時にすぐ検知できることももちろん大切ですが、そこからビジネスやユーザーに直結させることが一番大切で、本来の目的ですから。
――今回のDatadog導入をきっかけに、ユーザーにとってよりよいサービスを実現するための挑戦が続いていくのだと思います。ユーザーの目に直接触れる訳ではないけれど、根本的で大切な仕事。そんな舞台で活躍されるお2人の、原動力は何なのでしょうか。
森本：監視が好きで、グラフが好き。ただそれだけですね（笑）。数字が跳ねたり難しい動きを見せたりしたときに、どうやって解決するかを考えることに、わくわくしながら取り組んでいます。
石川：私も森本さんと同じですね。決して華やかではないし目立つかどうかではなくて、インフラが好きなんですよね。障害時に問題を可視化して、原因を究明して納得できる。普通にシステムを運用しているだけでは見えてこない、内側のことが分かるからこその面白さがあると思っています。
――Datadog導入PJTを通じてさらなる保守/監視の強化の重要性や、2人のインフラに対するワクワク感が伝わりました！ステキなお話をありがとうございました。
（取材＝伊藤秋廣（エーアイプロダクション）／文＝永田遥奈）
石川 篤 Atsushi Ishikawa
プロダクト開発統括部 プロダクト開発部 アーキテクトグループ リードコンサルタント2016年12月にパーソルキャリアに入社。前職は病院の社内SEとして病院独自のソフト開発や営業、導入支援に取り組む。現職では、システムアーキテクトとしてdodaのシステムリフォームを行っている。
森本 伸幸 Nobuyuki Morimoto
インフラ基盤統括部 システム共通BITA部 IT基盤グループ リードエンジニア
2018年12月にパーソルキャリアに入社。前職は交通系やその他電子マネー、QR 決済など電子マネー決済システムのインフラを設計から運用・保守まで担当。現職では、IT基盤領域の課題の洗い出しから対応・自動化まで広く担当している。現在は退職。
※2021年2月現在の情報です。
