大規模サイトリビルドの現場から：成功と失敗のリアルな教訓 / Site Rebuild,Real Lessons Learned from Successes and Failures_JJUG Fall 2024

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

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

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

Today's intended audience. 本日の想定した聞き手サイトのリビルドについて興味のある方リビルドの他社事例を知りたい方

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

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

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

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

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

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

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

リビルドに至った経緯 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スコアの大幅悪化が予想された...

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

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

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

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

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

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

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

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

リビルドの成果-インフラ面リビルド後のアーキテクチャ新フロントエンド基盤 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接続ログ・メトリクス収集

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

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

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

リビルドの成果-インフラ面 ④ 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

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

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

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

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

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

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

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

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

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

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

開発パフォーマンスの指標「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拡充とストラングラーパターンでによって「デプロイ頻度」「変更のリードタイム」「平均修復時間」指標を底上げ＝リリースサイクルを高めることで生産性を高めることができました

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大規模サイトリビルドの現場から：成功と失敗のリアルな教訓 / Site Rebuild,Rea...

大規模サイトリビルドの現場から：成功と失敗のリアルな教訓 / Site Rebuild,Real Lessons Learned from Successes and Failures_JJUG Fall 2024

More Decks by techtekt

Other Decks in Programming

Featured

Transcript