転職dodaの基幹システム「DC廃止→AWS移行前倒し」を“無事故で”どう実現？ コスト予測も高精度に：死活監視を脱して“障害対応の迅速化”も（2/2 ページ）

転職サービス「doda」を提供するパーソルキャリア。同社はグループ共通のデータセンター廃止の計画が進む中、基幹業務システムのクラウド移行を無事故で完了。その後、クラウドでのアーキテクチャ改善や、クラウドコストの予測精度向上、障害対応の迅速化などに取り組んできた。どう実現したのか、その裏側を聞いた。

[遠藤文康，＠IT]

クラウドコストの予測精度が向上

　「New RelicのAPMツールが入っているシステムは、年間予算の精度が非常に高い」と石井氏は言う。利用初年度はクラウド利用量の予測が難しく、予算も多めに確保という判断になっていたが、クラウド移行から1年、2年、3年と経過を見てくる中で、“想定外の動きをしない”ことも、年間どれくらい使われて、どれくらいリクエストがあるかも把握できている。「じわじわ増えている分も含めて統計が取れているので、予算取りの精度はかなり上がっている」（石井氏）という。

　利用実態が分かれば、クラウド利用料も見積もりやすくなる。過去の利用状況から今後の増減も予測できるため、必要以上に予算を積み増す必要がなくなる一方、追加の予算が必要になった場合も、その理由をデータに基づいて説明できると石井氏は言う。

　削減施策についても同じことが言える。久保木氏は、目標に対して実際にどれだけ削減できたのかというファクトを出せるようになったと話す。「非現実的なものではなく、3割削減など現実的な目標数値を掲げた上で、その事実を定量的に示すことができる。これに基づいて投資効果も測れるようになっている」（久保木氏）

障害調査「1〜2時間」が「数分〜十数分」に

　システムを継続的に改善していくには、経験や勘に頼るのではなく、データを基に判断し、誰でも同じ品質で運用できる仕組みが欠かせないと久保木氏は話す。

　例えばクラウドへの移行やOSの変更など、インフラやミドルウェア寄りの変更でも、APMを活用してシステムの状態を確認しながらリリースを進めてきた。「アプリケーションの変更とは異なり、インフラ寄りの変更は影響を把握しにくい部分があるが、カナリアリリースなどの際に数値を見ながら少しずつ調整することで、インフラ系のリリースも恐れずに進めることができる」（久保木氏）

　運用の現場でもAPMの有無による違いは大きいという。以前は、障害が発生すると各サーバからログを収集し、手作業で突き合わせる必要があった。保守ベンダーの中では、そのための“独自のExcel”が作られることもあるなど、担当者の属人的なノウハウに依存することで、担当者の変更による品質のばらつきなどもあった。

　全サーバの情報をAPMツールから一元的に確認できるようになり、そうした属人的な作業に頼らざるを得ないことはなくなった。後藤氏は「以前は障害を検知してからログを集め終えるまで1〜2時間かかることもあったが、今は数分から十数分で全体の状況を確認できておりこの違いは大きい」と話す。ある程度エラーの原因を推測できるところまで内製で実施し、すぐに修正の依頼まで進めることができるため、工数的にもコスト的にも負担を減らせると久保木氏も付け加える。

アーキテクチャは変わっても、見るべき指標は変わらない

　こうしていったんクラウドには全面的に移しているものの、その後もアーキテクチャは継続的に変わっていると石井氏は話す。オンプレミスの仮想環境からAWSのインスタンスへ移行した後も、IaC（Infrastructure as Code）による構成管理の自動化、「Amazon EC2」のオートスケール機能によるリソースの自動調整、コンテナ化と、クラウドらしい運用へ段階的に進化させている。さらに効率化を進めるためにアプリケーションの構造もモノリシックからマイクロサービスに分割することなども検討を進めている。

　「アーキテクチャは絶えず変化していくが、見るポイントは変わらない。同じ指標で継続して評価できるからこそ、データを基に次の設計や改善を判断できる」。石井氏はシステムを継続的に改善していく上での、変更や決断との向き合い方についてそう話す。

---

　死活監視からの脱却に始まった同社のオブザーバビリティー実践は、クラウド移行に伴うリスク解消や障害対応の迅速化にとどまらず、クラウドコストの最適化や、その後のアーキテクチャ改善を支える取り組みへと広がってきた。

　グループ共通のデータセンター廃止によってクラウド移行の前倒しを迫られる中でも、無事故で乗り切ることができたのはオブザーバビリティーによる可視化あっての成果だったと言えるが、それだけではない。その後もアーキテクチャに変更を加えながら、その影響をデータで確認しつつ、次の改善や投資の判断につなげている。

　オブザーバビリティーが単なる監視や障害対応だけの仕組みではなく、ビジネスの推進を支える基盤になっているとも言え、それこそが継続的な改善を目指すSRE（サイト信頼性エンジニアリング）も含め、“運用という役割”に求められるものではないだろうか。