転職dodaの基幹システム「DC廃止→AWS移行前倒し」を“無事故で”どう実現? コスト予測も高精度に:死活監視を脱して“障害対応の迅速化”も(1/2 ページ)
転職サービス「doda」を提供するパーソルキャリア。同社はグループ共通のデータセンター廃止の計画が進む中、基幹業務システムのクラウド移行を無事故で完了。その後、クラウドでのアーキテクチャ改善や、クラウドコストの予測精度向上、障害対応の迅速化などに取り組んできた。どう実現したのか、その裏側を聞いた。
転職サービス「doda」を提供するパーソルキャリアは、転職エージェントサービスを支える基幹業務システムの刷新を機に、システムの安定性を高め、継続的に改善できる取り組みを進めてきた。
同社転職エージェントサービス(キャリアアドバイザーが支援する転職サービス)の基幹業務システムは、十数億円を投じた全面刷新を2019年に完了させた後、オンプレミス環境から「Amazon Web Services」(AWS)への移行に踏み切った。当初は数年をかけてアーキテクチャを改善した上で、クラウドへ移行する計画だった。ところが、グループ共通のデータセンターを廃止する方針が持ち上がり、クラウド移行の大幅な前倒しを迫られた。
数千人の従業員が利用する基幹業務システムをクラウドへ移行する上で、まず課題となったのが、何を根拠に「移行しても問題ない」と判断するかだった。移行後も、システム変更による影響をどう把握し、改善の効果やコストの変化をどう見極めるかという課題が残る。
同社は急きょの計画見直しを迫られながらも、どのようにクラウド移行の安全性を確かめながら無事故で完了させ、その後も継続的なシステム改善を進めてこれたのか。その裏側を聞いた。
DC廃止からAWS移行を前倒し、「問題ない」をどう判断?
パーソルキャリアは、非対面型の人材紹介・転職支援サービス「dodaプラス」の基幹システム刷新に始まり、キャリアアドバイザーが転職希望者の相談に応じながら支援する転職エージェントサービスの基幹業務システム、さらに求人広告媒体を扱う複数のシステムまで、数年をかけて順次AWS環境へ移してきた。dodaプラスでは2023年、転職エージェントサービスでは2024年にクラウドへの移行を完了した。グループ共通のデータセンターを廃止するという方針の下、期限が区切られた中での作業だった。
こうした移行で慎重な判断が求められるのは、移行後のシステムが以前と同等以上の状態で動くのかどうかを確認することだ。その判断には根拠が要る。「クラウドへ切り替えて大丈夫ですと言っても、それだけでは説得力がない。何を根拠に問題ないと言えるのかを説明する責任がある」と、同社基幹システムのアーキテクチャ改善を横断的に統括している石井孝典氏は話す。
同社ではオブザーバビリティー(可観測性)を導入し、中でもAPM(アプリケーションパフォーマンス監視)を活用しながら、そのデータを判断の根拠としてプロジェクトを進めてきた。クラウド移行のプロジェクトに活用する以前から、転職エージェントサービスの基幹業務システムを刷新した際、死活監視中心の運用から脱却し、システムが“良い状態で動いているのかどうか”まで継続的に把握するために、New RelicのAPMツールを導入していた。
オンプレミスとクラウドの環境を並べて比較
もともとはアーキテクチャを改善しながら3年後くらいをめどにクラウドへ移行する計画だったというが、グループ全社で利用しているデータセンターを廃止するという計画が決まった。「むしろ先にクラウドへ移行してから改善するという方針に転換した」と石井氏は話す。
基幹システムの移行に当たっては、問題が生じていないことを確認しながら進める慎重さが求められる。同社が重視したのは、移行前後のシステムを同じ指標で比較できる状態をつくることだった。CPUやメモリの使用率、レスポンスタイム、エラーの発生状況などを同じ条件で比較し、移行による影響を見極めながら進められるようにした。
同社は、オンプレミス環境とクラウド環境の指標を1つのダッシュボードに並べ、同じ画面から比較できるようにした。「『クラウド vs. オンプレミス』といった名前のダッシュボードをAPMツールで作り、両環境を同じ基準で比較することで確実な判断の下で移行を進められた」と、APMの導入・活用を推進してきた久保木翔一氏は振り返る。
オンプレミス環境とクラウド環境で想定とは異なる挙動が起きていないかどうかを見極め、問題があれば切り替えを止める判断材料にすることが目的だった。例えば一度に全てのトラフィックを切り替えるのではなく、オンプレミス環境とクラウド環境へ段階的に振り分けながら検証を進めた。その際、同社では両環境へ50対50でトラフィックを流す設定とした。「ダッシュボードでAPIのコール数を確認することで、設定が実際に反映されているかどうかを検証できた」と久保木氏は話す。
一方で、想定通りになっていないケースもあった。50対50にしたつもりなのに、オンプレミス側が全部リクエストを吸い取っているようなこともあったという。原因はロードバランサーの設定だった。設定上は問題ないように見えていても、実際のトラフィックを可視化したことで、想定と実態のずれを早い段階で発見できた。
「同じデータ」で意思決定する
システム変更やクラウド移行を安全かつスピーディーに進めるには、開発者や保守担当者、プロジェクトマネジャーも含めて同じデータを見ながら判断できることが重要だと、転職エージェントサービス基幹業務システムの開発・運用を統括する後藤拓馬氏は話す。
その点では1つのダッシュボードを共有し、確認すべき点や修正すべき点を洗い出し、「ここはおかしいのではないか」と議論をしながら進められたのは大きかったという。特に、システムを100%クラウドへ切り替えるような影響範囲の大きいプロジェクトでは、「何をもって移行してよいと判断するのか」という共通の判断基準が欠かせない。後藤氏は「ダッシュボードを見ながら認識を共有することで、より正確に認識を合わせ、より早く意思決定を進めることができた」と話す。
クラウドへの移行後に問題が発生していないかどうかを検証する上でも、オンプレミスとの比較を基本にした。「クラウドの環境ではAPMツールでさまざまなエラーが上がってきたが、その全てが対応が必要なものではない。そのためオンプレミスのときには出ていなかったエラーを探す、という考え方で検証を進めた」(久保木氏)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
大量アラートを「53%削減」 サーバ300台を運用する情シスは何を変えた?
約300台のサーバを運用するオープンハウスグループでは、大量に届くアラートへの対応が担当者の負担となっていた。そこで監視運用の仕組みを見直し、アラート数を約53%削減した。同社は監視の運用をどう変えたのか。
Wantedlyのインフラチームは「挑戦を続けるための」開発・運用基盤をどう築いてきた?
ビジネスSNS「Wantedly」を提供するウォンテッドリーは、コンテナやKubernetes、マイクロサービスなど新しい技術を早くから取り入れ、サービス開発のスピードを高めてきた。開発者が開発に集中できる環境と、安定したユーザー体験を支える仕組みをどう構築してきたのか。取り組みの背景と狙いを聞いた。
障害調査にかかる時間を20分の1に airClosetは「客に言われるまで問題に気付けない」をどうなくした?
システムの問題は、原因が分からなければ解決が難しくなる。社外からの指摘で異変に気付くこともあったというエアークローゼットは、問題の原因を突き止めるための仕組みをどう変え、調査を迅速化したのか。
AIが書いたコードの「未知のリスク」にどう向き合う?――鍵は「エンジニアの能力を拡張できるか」
AIによってソフトウェア開発のスピードは飛躍的に高まっている。一方、AIで生成されるコードの増加は、システムの挙動にどのような影響があるのか把握することを一段と難しくする。企業はこれにどう向き合うべきか。オブザーバビリティーツールを提供するNew RelicのCEO、アシャン・ウィリー氏に聞いた。
58万人が使う決済アプリ、遅い原因が「4時間たっても不明」――食品スーパーはどう解消した?
マルエツなど食品スーパーを傘下に持つU.S.M.Hは、スマートフォン決済サービス「Scan&Go」の運用を見直し、時間がかかっていたアプリケーション遅延の原因究明を迅速化した。その仕組みとは。


