スタンバイアドベントカレンダー 2024 の 12/24 の記事になります。
スタンバイで Architect や EM をしている辻です。
スタンバイでは事業の成長・拡大および中長期的な事業継続のため、機能開発に加えて技術的な改善活動もいくつか実施しております。 この記事では2024年の振り返りも兼ねて、最近のスタンバイの技術的な取り組みをいくつか紹介します。
取り組み全体の概要
昨年度以前から継続しているものも含め、スタンバイ全体では
・コスト最適化
・システムのリアーキテクチャ
・開発効率を上げるためのツールなどの導入
を進めてきました。
コスト最適化
スタンバイはサービスのインフラに AWS を利用しています。
もともとインフラコストは課題ではあり23年度も対応をしたのですが、昨今の強い円安の影響もありインフラコストの課題が大きくなってきていたため、24年度の前半は特に全体で優先度を上げて改めて対応を進めました。
ただ、コスト削減！という形で闇雲に進めてしまうと、システムの障害に繋がったり、開発活動の効率や品質が下がったり、Savings Plans の不適切な購入により長期間削減できない無駄なコストが発生したりといった問題も起きるリスクがあるため、慎重に調査や検討をして進めました。
特には開発活動の効率や品質を下げる（エンジニアの苦労が過剰に増えたり、制約事項が増える）ような削減を進めてしまうと本末転倒になるので、取り組みの呼び名も "削減" ではなく "最適化" とするなど、良くない方向に行かないように意識しながらみんなで進めました。
スタンバイでは各領域ごとの開発チームがスクラムを組んで開発活動をしています。
そのため、全体の目標と方針を共有した上で、各チーム自身が自立的にコスト目標と最適化施策を立案し実施していきました。
加えて全開発チームの代表が揃う定例会議の場なども適宜活かし、各種相談やチーム間調整などもスムーズに進められました。
具体的な各チームの目標設定と施策実施時期についてはトップダウンではなくボトムアップをベースとした形で進めたため、最終的に目標達成できるのかという懸念は最初に出ましたが、各チームが全体目標も意識しつつチーム間で連携しながら取り組み、全体で目標を超える金額のコスト最適化を達成できました！
主な実施施策の概要は以下になります。
・求人データとその更新を管理する巨大 DB 周りのコスト削減
・DB のクラスター再構築による容量削減やリザーブドインスタンスの活用
・Aurora MySQL のコストを 54% 削減 の記事の件。最も効果が大きかった施策
・ECS, EKS で動くアプリのオートスケールの設定やリソースサイズの見直し
・S3 の保存データを精査し、安全な範囲で不要データの削除やライフサイクルの設定（一部は Intelligent-Tiering を利用）
・Compute Savings Plans の追加購入
・今後の EC2, ECS, Lambda などのリソースの増減予測をモニタリング＋各開発チームへのヒアリングで精度高く見積もり、追加購入
・カバー率が 50% 程度だったものを 80% 程度までアップ
・検索エンジン Vespa で利用する EC2 のインスタンスタイプを AWS Arm ベースの Graviton に変更
・サービス改善施策の実施に伴い大きなコスト増が見込まれていたが、この対応により増加幅を小さく抑えられた
・EKS の基盤を Fargate から EC2 に変更することにより、 Datadog 含めた EKS に関連するトータルコストの削減
・昨年に実施していた施策ですが、効果があった施策なので紹介
各施策ごとに丁寧に調査やモニタリングをしながら段階的に進めたため、これらの施策を原因としたインシデントを起こさずに削減できたことも大きな成果でした。
各種システムのリアーキテクチャ
スタンバイは2015年にビズリーチの新規事業として始まったサービスです。サービスとシステムの年齢はもう10年近くになることもあり、課題もたくさん出てきています。
検索エンジンについては 検索エンジンをVespaへ移行しています の記事にあるように刷新をしていますが、
検索エンジン以外のシステム群においても、扱うデータ量やトラフィックの増加への対応、各種施策のトライアンドエラーの歴史、
優先度の兼ね合いで改善活動を長期間実施できていないシステムがいくつか存在するなど、いわゆる技術負債と呼ばれるものがいくつかあります。
また、全体的なシステムアーキテクチャと技術選定に関しても、今後の開発や運用保守の効率の観点で見直したほうが良い部分も出てきていました。
これらの課題はすぐに深刻な問題に直結するものではありませんが、対応をしなければ中長期的には開発効率の低下やインシデント発生率の上昇が続き、中長期的にサービス改善の停滞や継続すら危ぶまれる状況を生み出しかねない類のものになります。
そのため、課題の影響度、緊急性、改善効果の見込みなどを考慮して優先順位をつけてロードマップを引き、いくつかのシステムのリアーキテクチャを各開発チームで進めています。
規模が大きく道半ばの案件もありますが確実に進捗しており、一部は本番リリースを迎えられ期待していた開発効率やパフォーマンスの改善を実現できました。
主には以下のような取り込みを実施しています。
開発に用いる言語の変更
スタンバイのシステムの大半は Scala で実装されてきたのですが、これについては昨今いくつかの課題が顕在化してきました。
世界的にも国内においても Scala の人気が他の言語と比較して高くない状況にあり、エンジニア採用が困難になってきていました。
また Akka のライセンス変更をはじめとする依存ライブラリやフレームワークに大きな変化があり、Scala を継続利用していくにも不確実性と諸々の対応工数が大きくなる見込みがありました。
昨年からスタンバイ内でこの課題に関する議論を重ね、
・言語利用者数の状況
・OSS の開発体制
・今後のエンジニア採用
・静的型付け言語であること（型安全性）
・並行処理の扱いやすさ
・マイクロサービス間の通信の安定性(壊れにくさ)と高パフォーマンスの実現のしやすさ
・学習コスト含めた現状からの移行コスト
等々の観点で複数の言語を比較検討し、バックエンド開発で用いるメインの言語を Go に変更していくことを決定しました。
そして、徐々にバックエンドのアプリケーションを Go での実装に切り替えることを進めています。
社内のサービス間通信についても REST から gRPC に徐々に移行していくことを進めています。
昨年の決定時点ではスタンバイ内の Go の経験者はかなり少なかったため不安要素もある大きな決定でしたが、外部の講師の方を招いた勉強会や社内でのノウハウ共有なども実施しながら、いくつかのサービスの Go への移行が完了しています。
求人取り込み・管理システムの刷新
前述のコスト最適化のパートでも触れた、巨大な DB を用いている求人データの取り込み管理システムについても、アーキテクチャの刷新を進めています。
このシステムは、求人データ本体だけでなく各種取り込み処理の状態管理についても主に１つの DB クラスターで集中管理されています。
取り扱う求人数自体の増加に加え、求人データ取り込みの処理数や内容の複雑さが増してきており、DB がパフォーマンスとコストにおいてネックになっています。
そして今後もスタンバイのサービス改善のため求人データの取り込み処理は追加や変更をし続けていく必要があります。
求人データの取り込み管理はスタンバイのサービスの改善と継続の肝となる重要な部分のため、
「パフォーマンス」、「コスト」、「開発・運用のしやすさ」を改善を目指して、DB を中心としたアーキテクチャからストリームを中心としたアーキテクチャへの刷新を進めています。
データ基盤の刷新
スタンバイのサービス改善のための各種意思決定や検索エンジン改良の材料となる各種ログや求人に関するデータを管理している「データ基盤」に関しても、DWH のリアーキテクチャを進めています。
現状のスタンバイのデータ基盤はデータ統合やモデリング、メタデータの整備などの観点で課題が多く、各種データ分析業務がとても煩雑で品質も高くできていない状況にあります。
DWH のリアーキテクチャによってこれらの課題が一気に解消されるという類の話ではなくデータの管理方法をはじめとした運用の課題も大きいですが、これらの課題解決を進めやすくするための基盤整備のためにリアーキテクチャを実施しています。
ここも時間がかかる取り組みではありますが、正確なデータと分析結果を元にした意思決定をしていくことはサービス改善において非常に重要になることのあので、取り組みを進めています。
開発効率や品質向上のためツール導入や取り組み
開発活動の効率や品質を高めるために、下記をはじめとするツールの導入や取り組みを実施しました。
・GitHub Copilot の導入
・AI のサポートも適宜利用し、開発の品質と効率の向上を図るため
・Renovate の導入推進による依存ライブラリの更新の効率化
・低コストでこまめにアップデートする仕組みを整備することにより、安全性と安定性の向上を図るため
・Codecov の導入推進によるテストカバレッジの可視化
・日々の開発運用に欠かせない自動テストの改善活動を進めやすくするため
GitHub Copilot については AI からの提案内容について吟味する必要があるなど注意は必要ですが、利用しているエンジニアからは開発効率が良くなったという声が多かったです。
まとめ
上記で紹介した取り組みは一部で、他にも多数リファクタリングや各種改善活動を各開発チームで進めています。
どんな事業でも同様ですが、提供するサービスや組織を運営し成長させ続けていくためには、目には見えにくい部分の改善活動が必要になります。
こういった活動とサービス改善に直結する施策開発のバランスをどう取るのかは常に難しいことですが、スタンバイでは四半期ごとに全体での各種案件の優先度調整を実施できていることもありバランス良く取り組めていると感じています。
こういった取り組みで開発活動の地盤を固めつつ、求人検索サービスの磨き込みをしていきたいです。
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。 www.wantedly.com
