Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 大規模サイトリビルドの現場から：成功と失敗 のリアルな教訓 2024/10/27 パーソルキャリア 奥野堅斗

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S GIVE PEOPLE THE POWER TO OWN THEIR WORK-LIFE. 人々に「はたらく」を自分のものにする力を パーソルキャリア株式会社 東京都港区 1989年6月 1,127百万円 人材紹介サービス、求人メディアの運営 転職・就職支援、採用・経営支援サービスの提供 6,929名 （有期社員含む グループ会社出向中の者は除く 2024年3月1日時点） 社名 本社 創業 資本金 事業内容 従業員数

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 自己紹介 名前 奥野堅斗 技術領域 会計ソフトベンダー4年 パーソルキャリア2年 職歴 趣味 Java Spring Oracle AWS ロードバイク サウナ 筋トレ 詳細を見る 転職なら、求人情報・転職サイトdoda（デューダ） 求人を紹介してもらう 知りたい・聞きたい イベント 閲覧履歴 気になる Web履歴書 ログイン 会員登録

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S Today's intended audience. 本日の想定した聞き手 サイトのリビルドについて興味のある方 リビルドの他社事例を知りたい方

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S What I want to convey today. 今日お伝えしたいこと リビルドは大変だけどやる価値はある リビルドの進め方についてこうやったら上手くいくかも

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S Table of Contents. 目次 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ 質疑応答(残り時間)

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 Pick up! 気になる dodaリビルドについて

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 「doda」について_サイト概要 転職希望者と求人をマッチングするWebサイト です 主なページとしては、 「求人検索ページ」「求人ページ」 「気になるページ」「検索条件の保存ページ」 「〇〇向け特集ページ」などがあります 他求人サイトとの大きな違いは転職エージェントについ ても1つのサイトで機能として持っていることです。 具体的にはキャリアアドバイザーとのカウンセリング予約 やメッセージのやり取りなどもできます。 サービス開始時期：2007年 求人数：26万件 (2024/10/14時点) 会員数：9,120,000（2024/9月時点）

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 「doda」について_リビルド前のアーキテクチャ構造 ・アーキテクチャは典型的なモノリス構成です ・SpringBoot+JSPを利用し、SSR(サーバーサイドレンダリング)方式で画面描画しています ・ページごとに2つにサーバーが分かれています(正確には他にもある) ・基盤CというRestAPIが存在するが実態は基盤Aと密結合されておりAPIの再利用性は低いです ・周辺システムが多数存在し、同じDBを介して様々なデータのやり取りを行っています... 基盤A 求人関連のページ 会員向け機能 ページ 基盤B 基盤C DB AWS Cloud Oracle Cloud Apache solr(検索エンジ ン) 求人を作成する 社内システム キャリアアドバイザー 向けの社内システム CMS 特集ページなど etc…

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 「doda」について_技術負債の話 15年以上稼働し続けているので、技術的負債がたくさん 1.フロントエンドとバックエンドの責務が曖昧 →ビジネスロジックとUI機能が密接で画面に依存した処理が多くコードの再利 用が困難です 2.ソースコードの複雑化、低いテストカバレッジ率 →大きすぎるメソッドと、書けるはずもないテストコード。外部に依存しすぎてモッ クだらけで何をテストしたいかわからないテストコードなどなど 3.UIのコンポーネント化がされておらず再利用が難しい →似ているけど、’何か違う’ 部品が多発。 →UIを修正するたびにCSSが競合し影響範囲の確認で骨が折れる 4.DBを周辺システムと’共用’しておりテーブルの修正が困難 → 影響調査、各システム関係者との調整で修正コストが高い 5.半分手動のCI/CD、過剰なインフラスペック →Jenkinsを用いた秘伝のスクリプトによるデプロイ →サーバーを常時稼働させているため、夜間などは過剰スペックで無駄なコスト が発生 [静的解析ツールで表した技術負債の量] 縦軸:テストカバレッジ率 横軸：技術負債の解消にかかる時間 円の大きさ：コード量 円の色：赤(やばい) > 黄色 >緑(正常) 小さな修正でも影響範囲が見えずデグレに怯える日々でした...

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 「doda」について_技術負債の話続き 内製エンジニア数の推移 2019(8名) -> 2020(20名) -> 2022(40名) -> 現在70名以上 ・dodaは最近まで内製チームが存在せず、今の基盤となるシステムは全て外部ベンダーへの外注で作られている ・機能追加も外注先ごとに特色があり書き方がさまざま、UIの見た目もさまざまになってしまった ・設計書はある(Excel)が更新されていないものも多い ・内製エンジニア化が2019年ごろから始まり、ここ5年で急速にエンジニア組織が大きくなった 今の技術負債状態になるまでの軌跡

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドに至った経緯 doda 大手A社 大手B社 大手C社 LCP(レンダリング) 4s 3s 4.7s 2.9s FID(操作性) 197ms 207ms 28ms 34ms CLS(画面の安定性) 0.55 0.09 0.17 0.03 TOPページのCWV指標(リビルド前 2021/3時点) ビジネス影響が出るので早急に修正する必要があるが、今のフロントエンドの作りだと改善に限界がある 加えて、エンジニアの内製化も進み技術負債を何とかしないという気運がエンジニア組織内で高まります →「dodaをリビルドしよう」となりました 2021年にGoogleがCoreWebVitals 指標を発表 →SEOのランキングに影響するUXに特化した指標 →dodaサイトは各指標が競合サイトよりも低く、SEOスコアの大幅悪化が予想された...

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S dodaリビルドの範囲 一部のCMSで作成していたページを含めdodaサイトのサーバー全てがリビルド対象となりました これらのサーバーをモダンなアーキテクチャに変更しCI/CDも拡充した形に1から作り直しました ただし、DBは他システムも参照しているためリビルドの範囲外となりました 基盤A 求人関連のページ 会員向け機能ページ 基盤B 基盤C DB AWS Cloud Oracle Cloud Apache solr(検索エンジン) 求人を作成する 社内システム キャリアアドバイザー 向けの社内システム CMS 特集ページなど etc… リビルド対象：赤丸

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 気になる リビルド手法 Pick up!

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S ストラングラーパターンの採用 画面単位でリビルドしていくことをストラングラーパターンといいます 1つずつ機能を新しいアーキテクチャに移行して、全ての機能の移行が終わったタイミングで古い基盤を破棄しま す 古い木を徐々に覆って窒息させ、最終的に置き換える「イチジクの木」からこの名前がついているらしいです dodaリビルドではページ数も多く移行に時間がかかるためストラングラーパターンを採用しました モノリスからマイクロサービスへ Sam Newman 著、島田 浩二 訳 新基盤 旧基盤 会員ページ 求人ページ 検索ページ 旧基盤 会員ページ 求人ページ 検索ページ TOPページ TOPページ TOPページ 新基盤 [1つずつ機能を移行していく] [全ての移行が完了して初めて旧基盤を削除する] デメリット： 平行稼働期間中は新旧2つの基盤の修正・メンテが必要になる →期間を見定めて古いソースをDeprecated していくことが大切 →公開してから大体1か月くらいを平行稼働期間として定めていました メリット： 段階的に置き換えるため、システム全体のダウンといったクリティカルなリスクを最小限に抑えられる 何か問題があっても既存システムが残っているのですぐに切り戻せる

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S ストラングラーパターンの具体的な実現方法 ALB＋プロキシサーバーで実現 リビルド対象の特定のリクエストのみ新アーキテクチャへ処理を流す PC画面とSP画面を別々にリリースすることもあるのでユーザーエージェントによる分岐といった複雑なものはプロキシサーバーを立てて 振り分けています リビルド基盤側で何か問題が見つかった場合は、ALBの振り分けルールを変更するだけなので切り戻しも容易 プロキシサーバー ALB リビルド基盤 旧基盤 /page2 /page1 UAに’iPhone’ ‘android’を含む 「/doda/page1」のSP画面をリビルドした場合 AWS Cloud 上記以外 ALBを採用した理由は下記 ①AWSが提供するフルマネージドなサービスなので自動でオートスケールなど管理が楽だから ②ルーティングが比較的シンプルだから

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S よりミニマムな形でのストラングラーパターン 画面単位ではなくコンポーネントごとに移行していくということもdodaリビルドで実験的に取り入れています メリットしては、画面修正が入りやすい画面などでコードフリーズせずに実施することができる デメリットとしては、新基盤側に移すときにも追加で実装する必要がある 【具体的な方法】 ・コンポーネントはReactで開発し、コンパイル＆ミニファイしたものを旧基盤に配置してリリースする ・部品ごとに置き換えていき、一定の置き換えが終わったタイミングでページごと置き換える ・必要なRestAPIはバックエンドに移行する ・ソースは新しい基盤側で管理 旧基盤 JSP [コンポーネント単位で移行していく] JSP JSP 新バックエンド基盤 GET フッターに表示するデータを取得 ビジネスロジック部 分は新しい基盤に RestAPIとして移 行しておく React 新フロントエンド基盤 React [全てのコンポーネントの置き換えが完了したら新基盤に移行する] React React React 新バックエンド基盤

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リリース手法：カナリヤリリース カナリヤリリース・・・アプリケーションやサービスの新しいバージョンを本番環境で一部のユーザーに限定してリリースする方法 一定期間空けて問題なければ段階的に開放ユーザーを増やしていく リリースによる障害の最小化とインフラ面でのリソース課題を前もって検知できる こちらもALBで簡単に実現可能 注意点として「スティッキーセッション※」は必ず有効にする必要があります ※一度目のリクエストでCookieにどちらの基盤に遷移したかの状態を持たせて2回目以降も同じ基盤を向けさせること プロキシサーバー ALB 新基盤 旧基盤 /doda/page2 /doda/page1 UA に’iPhone’ ‘android’を 含む 「/doda/page1」のSP画面を10%カナリヤリリースしたい場合 AWS Cloud 上記以外 重み付け 10% ALB 重み付 け90%

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 気になる リビルドの成果 Pick up!

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-インフラ面 リビルド前のアーキテクチャ 基盤A 求人関連のページ 会員向け機能ページ 基盤B 基盤C DB AWS Cloud Oracle Cloud Apache solr(検索エンジン) 求人を作成する 社内システム キャリアアドバイザー 向けの社内システム CMS 特集ページなど etc… リビルド対象：赤丸

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-インフラ面 リビルド後のアーキテクチャ 新フロントエンド基盤 DB AWS Cloud RestAPI 新バックエンド基盤 Nginx Task #1 Nextjs Task #1 Springboot Task #1 CloudWatch sidecar app ECS ECS sidecar sidecar ・フロントエンドがNext.js(ReactのSSRフレームワーク)バックエンドがSpringBootのRestAPIとして分離 ・それぞれECS+Fargate でDocker化 Apache solr(検索エンジン) ログ・メトリク ス収集 DB接続 ログ・メトリ クス収集

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-インフラ面 ①CI/CDの整備 Before ・Jenkinsで実施 ・マージ後に手動実行する必要がある ・自動テスト・静的チェックを自動で実施できない ・アプリケーション開発者が何の処理をしているのかをすぐ に確認できず、エラー調査が大変 ・誰でもアカウントさえあれば本番実行できてしまう After ・GitHubActionを導入 ・マージ後に自動でデプロイ実行 ・PR作成時、マージ時に自動テストと静的チェックを実施。 ・問題がある場合はPRがマージできないように設定 ・本番環境のデプロイ時の承認フローの作成 →masterのPRの複数承認。 →GitHubActionフローの中に承認タスクを追加 秘伝のタレと化したシェル CodeDeploy 3.Image push ECR ECS Image Blue/Green 4.デプロイ実行 2.静的解析 トリガー PR・マージ 1.自動テス ト実行

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-インフラ面 ②オートスケール導入 Before After ・台数が固定化されており負荷の低い時間も無駄なコストが発生 ・台数を増やす場合、EC2インスタンスごと増やす必要があり、一定 の手順が必要。急なリクエスト増にすぐ対応できない ・前の作りがステートフルなWebサーバーなので、オートスケールする 際のセッション管理が手間(スティッキーセッションで回避はできるが負 荷集中する可能性) ・常時台数＋負荷が閾値を超えると自動で台数増加可能 ・サーバーが不測の事態で急に落ちても自動復旧 ・台数増加の閾値はCPU使用率とメモリ使用率、Javaのスレッド数 などを見ている ・急なリクエスト増でも耐えられる

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-インフラ面 ③Blue/Greenデプロイ Before After ・サーバーを1台ずつALB切り離し→停止→資材配置→起動してい るため時間がかかる ・問題が発生したときの切り戻しが遅い ・特にリリース直後のロールバックが素早くできないためユーザー影響が 広がってしまう ・前のバージョン(blue)を止めずに新しいバージョン(green)をデプロイし、 greenが全てデプロイしたタイミングで一気に切り替える方法 ・切り替えが一斉に行われるためダウンタイムがすくない ・greenデプロイ後も一定時間blueを残しておくことで、問題が起きた時 にボタン1つでロールバックできる ロールバックボタン↓

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-インフラ面 ④ IaC(Infrastructure as Code)の実現 Before After ・インフラ開発する人が限られており、Excel等に手順があるだけで属 人化している ・いつ誰が何の目的でインフラ構成を変更したかわからない ・AWS Cloudformationでインフラ構築 ・yml(json)形式で記載してAWSのインフラ設定が全て記載できる ・設定ファイルをGitで管理することでいつ誰が何の目的で変更したか 一目でわかる ・アプリケーションと同じGit上で管理することでアプリケーション開発者 もインフラについて容易に確認できる xxx環境構築手順書 xxx切り戻し手順書 xxx変更手順書 ymlファイルイメージ↓ infra repository .github app common dev prod

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-アプリケーション面 ①クリーンアーキテクチャを導入 Before After ・MVCだけどMVCでないソースコード。巨大なController ・似たようなロジックが大量にあり再利用されない ・外部接続と密結合でテストが書きずらい ・UIの変更やAPIの変更など外部の影響を受けやすいソース ・ビジネスロジックを外部(APIやDB)に依存させないことで変更に強く なる。テストも書きやすくなる。 ・ビジネスロジックが独立しているため再利用が進む ・ドメイン知識をソースに落とし込みやすくなる ・どこに何を書くべきかが決まっていることでソースの可読性が上がる Presentation Infrastructure UseCase Domain Controller Service Reposit ory 3者は強く依存しあっている ビジネスロジックが外へ依存しない

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-アプリケーション面 ①クリーンアーキテクチャを導入(詳細) クリーンアーキテクチャを守ってもらうために パッケージの依存関係をテストコードで担保するため「ArchUnit」を採用した ★ArchUnit★ プレーンな Java ユニット テスト フレームワークを使用して Java コー ドのアーキテクチャをチェックするためのライブラリ。 JUnitベースで書けるので学習コストも少なく導入しやすい。 ①それぞれのパッケー ジにレイヤーとしての 名前を付ける ②各レイヤーがどこか らなら呼ばれてOKな のかを書く

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-アプリケーション面 ②テストカバレッジが高いのでリファクタしやすい Before ・テストカバレッジが低く、既存のソースを触りたくない。 ・テスト書こうにも依存が多かったり、1つのメソッドが巨大で書 きにくい After ・ドメイン層のテストカバレッジが高いため変更してもテストで品質を 担保できる

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-アプリケーション面 ③Reactコンポーネント化による再利用性向上 Before ・似ているけど微妙に違うコンポーネントが多発 ・同じコンポーネントだけどCSSがぶつかって修正が必要 ・1画面の同時開発が難しい After ・Reactコンポーネントとして定義することで使いまわしが容易になった ・StoryBookを採用することでコンポーネント単位でUIを確認が可能 となり1画面の同時開発が容易となった 似ているけど違う・・・

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-アプリケーション面 ④静的解析ツールによるソースの脆弱性、スメルコードの検知を自動化 Before ・SpotBugsによる静的解析は行っていたが、運用が形骸化 ・既存ソースの警告が放置され無法状態 ・開発者がローカルで確認しているだろうという善意で成り立っていた After ・SonarQubeを導入し、レポートやダッシュボードで見える化 ・PR実行時に自動で連携し、OK/NGをPR上で確認できるようにした ・SonarQube上でどのチームによる修正による警告かがわかるのでリ リースする前に警告が残っていればそれを各チームに連絡する運用を実 施 GitHubActionと連携することでPR上に表示できる SonarQubeのダッシュボード

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの成果-アプリケーション面 ⑤ローカル開発環境のセットアップが容易に Before After 30分 3分 1~2日 1時間 ローカル環境で1回起動してビルドが終わる時間 初日配属されてローカル環境構築をセットアップする時間 ※既存の巨大なソースと複雑 なパッケージ構成から解放され たってだけの話ですが、現場の 開発者視点は一番インパクト ありました

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 気になる リビルドの「進め方」でよかった点 Pick up!

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの「進め方」でよかった点 1. ストラングラーパターンにより問題発生時にすぐに切り戻すことができた 2. Datadogの活用と他の開発部署やビジネスサイドの人を巻き込みバグを早 期発見 3. アプリケーション内の予期せぬエラー発生時は全て古い基盤へリダイレクト(保 険措置)する処理を入れた 4. リモートワークの中、仮想オフィスを取り入れた

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの「進め方」でよかった点① ストラングラーパターンにより問題発生時にすぐに切り戻すことができた プロキシサーバー ALB リビルド基盤 旧基盤 /page2 /page1 UAに’iPhone’ ‘android’を含 む 「/doda/page1」のSP画面をリビルドした場合 AWS Cloud 上記以外 古い基盤は捨てずに移行するのでリリース後問題が起きれた場合、ALBの振り 分け変更するだけで元の機能は担保される /page1 いや そもそもバグを出さない ようにしようよ？

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドするって大変 リビルドって本当に大変なんです… ・設計書がない中、他人の書いた継ぎ接ぎな膨大なソースを読み仕様を起こす →1万行を超えるクラス、ほぼすべての画面で呼ばれる謎の巨大JSファイル ・DBへの登録1つ取っても仕様を変えてしまうと、どのシステムにどんな影響があるかわからない ・仕様なのかバグなのか誰も判断してくれない中で自分たちで確認していくしかない →バグっぽいから直す⇒後になって仕様ってことがわかる・・・ なので、少しのバグを許容して勇気をもってリリースしてしまうことも大切なのではと思う。 問題起きたら速攻で切り戻すので… 全てのバグを潰そうとすれば、膨大な調査と膨大なテストが必要になる ＞いや、そもそもバグを出さないようにしようよ？ それはおっしゃる通りですが、、、

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 開発パフォーマンスの指標「FourKeys」に当てはめると… ・ FourKeys ・・・ Googleが2020年ごろに提唱した開発パフォーマンス指標。4つの指標がありこの指標が高いチームは開発生産性が高いとされる メトリック 定義 エリート 高 中 低 デプロイの頻度 組織による正常 な本番環境への リリースの頻度 オンデマンド （1日に何度 も） 1週間から1カ 月に1回 1カ月から半年 に1回 半年以上の間 隔 変更のリードタ イム commit から本 番環境稼働まで の所要時間 24h未満 1日~1週間 1か月以内 1か月超 平均修復時間 組織が本番環 境での障害から 回復するのにか かる時間 1時間未満 1日未満 1日から1週間 半年以上 変更障害率 デプロイが原因で 本番環境で障 害が発生する割 合 5％未満 5％〜10％ 10％〜15％ 15％ ~ バグを一切出さないってことだけが開発パフォーマンスではない 今回のリビルドでは、早期のCI/CD拡充とストラングラーパターンでによって「デプロイ頻度」「変更のリードタ イム」「平均修復時間」指標を底上げ＝リリースサイクルを高めることで生産性を高めることができました

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの「進め方」でよかった点② Datadogの活用と、他の開発部署やビジネスサイドを巻き込みバグを早期発見 たとえすぐに戻せる状態だったとしても、問題が起きていることを検知できなければ意味が ない アプリケーション面でのバグ、インフラ 面での障害 →ログやメトリクスの監視とアラート発 報で検知 そもそもの仕様面からミスっている場合 →使用ユーザーの声、計測数値を見ているビジネ スサイドの声、他システムでのエラーや予期せぬ動 作で検知 Datadogを活用 関係部署に連絡＆ コミュニケーションラインを築く

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S Datadogによるエラー検知の取り組み 下記の機能を活用してエラーの早期発見を目指しました ①ダッシュボード機能(見える) ・関連するアプリについて必要な情報をメトリクスやエ ラーログ項目をまとめることが大切 ・リリース後は毎日朝会などでダッシュボードを確認 ②モニター機能(検知) ・特定の閾値を超えた時に発報する機能 ・TeamsやSlackに連携 ③トレース(調査) ・各サービス間を跨いで処理の流れを追うこ とができる ・エラーが起きた際にどこで問題起きたのか ・処理遅いときにどこの処理がボトルネックが 一目でわかる

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 関係部署に連絡とコミュニケーションラインを築く ・関係しそうな部署に連絡する ・文面としては「ささいな変化でもよいので、何か兆候があれば教えていただきたいです」的なニュアンスで密にコミュニケーション取れるようにしておく ・連絡はできればチャットツールが良い。上記連絡を投げたチャットツールの窓で些細な傾向でも投げてもらうようにすることが大切 実際に検知できた事例 (法人関連の部署から) 「10/1以降のメールで送った求人 のPV数が急に落ちてそうだけど、リ ビルド関係ありそうですかね?」 (リビルドチーム) ご連絡ありがとうございます。 ちょっと確認してみます。 (リビルドチーム) すいません。計測処理が一部漏 れていることがわかりました。ユー ザー影響ありそうでしょうか？ (法人関連の部署から) そうですね。法人様への報告して いる数値になるので至急修正お 願いしたいです (リビルドチーム) 承知しました。至急切り戻します。

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの「進め方」でよかった点③ アプリケーション内の予期せぬエラー発生時は全て古い基盤へリダイレクトする保 険的処理を入れた ストラングラーパターンと似ていますが、アプリケーション側でエラーが発生した場合、古い基盤にリダイレクトさせるようにしました 内部でエラーが起きているけどユーザー影響がほとんどない状態にできました(表示速度は遅くなります) プロキシサーバー ALB リビルド基盤 旧基盤 /page2 or /page1?old_redirect=1 /page1 「/doda/page1」のSP画面をリビルドした場合 AWS Cloud エラー発生！ 実際にあった事例 フロントエンド基盤 バックエンド基盤 GET 求人情報 400エラー！ IDの桁数がおかしい不正な リクエストだ！ でも実は、超特殊なケースでIDの桁数が 少ない場合があるという仕様が漏れていた 求人情報が 取れない.. 旧基盤へリダイレクト 旧基盤では問題なく 表示できるためユー ザー影響なし 特殊なクエリを持たせてリダイレクト /page1?old_redirect=1

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドの「進め方」でよかった点④ フルリモート体制の中、仮想オフィスを取り入れた リビルドPJTは完全リモートワークで実施しましたが、 メンバー内から「メンバー間でコミュニケーションが希薄」という声が出ていた中で、ちょうど全社的に導入されたタイミングもありバーチャルオフィスをルール化した ツールは「ovice」を使っていました [バーチャルオフィスの良いところ] ①出社してる感出る。すぐ話したい人に話に行ける ②GoogleカレンダーやTeamsとも連携でき、MTG中などはマークが変わるので声をかけていいタイミングがわかる ③キックオフといったイベントのときも「その場にいる一体感」とリアクションができるので参加している側も話す側もお互いとって良い 応対可能 作業中 会議中 近くに行ってマイクをオンにすれば会話ができます。 話しかける前に「肩ポン」をします

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 気になる リビルドの「進め方」での反省点 Pick up!

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドでの反省点 1.初期メンバーのアサインをもっと考えたほうがよかった 2. Docker化をもっと早い段階で進めたほうががよかった 3.バックエンド領域のダークローンチを検討したほうがよかった

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドでの反省点① 初期メンバーのアサインをもう少し考えたほうがよかった 当初はReactへの移行＋バックエンドのRestAPI作成よりもフロントエンド側の実装量が多いということで フロントエンドエンジニアの比重が多かった リビルドの初期段階は、既存ソースが読めるJavaエンジニアorドメイン知識が豊富なメンバーをアサインして 一番の肝となる仕様調査を重視したほうが良かった フロントエンドエンジニア バックエンドエンジニア インフラエンジニア [初期のメンバー構成] フロントエンドエンジニア バックエンドエンジニア インフラエンジニア [仕様が固まりアーキテクチャも安定した後のメンバー構成]

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドでの反省点② Docker化をもっと早い段階でしたほうがよかった CWV指標の改善を優先して最初にフロントエンドサーバーを新環境に移行したが そのタイミングではDocker化する余裕がなくEC2で稼働していました その後にバックエンドの環境移行でDocker化を進めて、そこが安定稼働したのちに同じ仕組みをフロントエンドアーキテクチャにも採用 していました。その経緯もありフロントエンドのDocker化が遅れました しばらくオートスケールができない状態となっていまい余計なコストと監視の注力が必要でした 画面が増えるごとに過去のリクエスト数から試算＆カナリヤリリースでメトリクスを監視して様子を見ながらサーバースペックを強化しました リビルド基盤 旧基盤 10% 90% リビルド基盤 旧基盤 50% 50% メトリクスの上昇値を見てサーバー負荷 が問題ないか確認 [カナリヤリリースの流れ]

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドでの反省点② Docker化をもっと早い段階でしたほうがよかった② しかし、ある日画面を100%公開した4時間後に大量のGoogleクローラーbotのリクエストが殺到することがありました 平常時の10倍のリクエストが2，3時間の間に断続的にリクエストの波が押し寄せました (既存のページが大幅に更新されたりした場合、Googlebotはそれを検知してクロール頻度を上げることがあるとのこと) 結果、サーバー1台のCPU使用率がMAXに張り付き、その時間帯のレイテンシーが大幅悪化 たまたま、日中であったためすぐに対応できたが、サーバーを構築する必要がありそれなりの時間を要してしまった

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S リビルドでの反省点③ バックエンド領域のダークローンチを検討したほうがよかった ダークローンチとは・・・ユーザーに公開しない形でシステムのバグの有無やパフォーマンスが問題ないことを確認すること dodaでは登録テーブルと登録するカラム情報が多岐にわたり、それらの登録値を他システムが参照するため念入りに進 めたほうがよかった DB AWS Cloud Oracle Cloud 新バックエンド基盤 旧基盤 検証用DB 整合性を検証する 新フロントエンド基盤 古い基盤の中で新しい 基盤のAPI処理を呼ぶ 検証用のスキー マにデータ登録

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 気になる 今後の取り組み Pick up!

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S dodaのマイクロサービス化PJT ・マイクロサービスとは・・・「システム全体を複数の独立した小さなサービス（マイクロサービス）に分割し、それぞれが特定のビジネス機能を 担当する設計手法」 ・それぞれのサービスは疎結合で独立してデプロイできる ・サービスごとに独立したDBを持っている AWS Cloud EKS Aurora(MySQL ) API-GW マイクロサービス群 独立したスキーマ DB Oracle Cloud Kafkaブローカー Kafkaリスナー

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S マイクロサービス化の流れ(1) ・他システムからの参照されるため古いDBは残しつつ新しいDBを作成する必要 があります ・参照処理と登録処理を2段階で移行してきます。 ・まずは登録処理を先にマイクロサービス化して、しばらくユーザー影響ない形で 並行稼働し処理に問題がないか比較検証しました DB 他システム 移行前モジュール マイクロサービス 登録 参照 他システム 移行前モジュール 登録 参照 登録 登録 参照 参照 登録 既存 STEP1 登録処理を並行稼働 比較用DB STEP2 比較検証 DB 比較結果を日時で出力 マイクロサービスDB 比較用DB DB

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S マイクロサービス化の流れ(2) マイクロサービス 他システム 移行前モジュール 参照 参照 登録 データコピー マイクロサービス 参照 登録 参照 登録 移行前モジュール 登録 STEP3 登録先を正規DBに変更 STEP4 参照先をマイクロサービスへ 他システム ・比較検証が問題なければ登録系処理をマイクロサービスに移行します ・このときマイクロサービスと他システムとの関係を疎結合にしたいのでメッセージキューサービスであるKafkaを使用します ・その後、古いDBのデータを一括マイクロサービス側のDBにETLツールを使用してデータ移行します ・その後、参照系処理をマイクロサービスに移します マイクロサービスDB 旧DB マイクロサービスDB 旧DB

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S 1. dodaリビルドについて 2. リビルドの手法 3. リビルドで実現したこと 4. リビルドの「進め方」でよかった点 5. リビルドの「進め方」での反省点 6. 今後の取り組み 7. まとめ Table of Contents. 目次 気になる まとめ Pick up!

Copyright © PERSOL HOLDINGS CO., LTD. All Rights Reserved. S まとめ Dodaのリビルドは 仕様のドキュメントがない状態で、 周辺システムとの依存関係が大きいから極力現状の仕様(特にDBへの登録)は変えない状態で、 各ベンダーさんが作った統一感のない複雑なソースからリバースエンジニアリングするという大変なPJTでしたが ①ストラングラーパターンを用いてバックアップを残しておき、問題発生したときにすぐに切り戻すことと ②ログとメトリクスの監視を自動化し、他の開発部署やビジネスサイドの人を巻き込みバグを早期発見できること によってユーザー影響が少ない形でリビルドを進めることができました また、モダンアプリケーションへの移行であっても 既存仕様や既存の言語に強いエンジニアのアサインを重要視することも大切だと思いました。 長々となりましたが以上になります ご清聴ありがとうございました