はじめに
こんにちは。RSSのM.D.です。
まず自己紹介から。これまで20年ほどソフトウェアエンジニアとしての経験を重ねてRSSへ入社しました。海外のIT企業や国内AIベンチャーでの経験もあります。
まだ入社して半年ほどなのですが早速重要なプロジェクトを任されまして、その仕事が一息ついたというタイミングで、今回のテックブログ執筆を打診されました。
今回の記事では、RSS内でのここまでの取り組みを通じて、新入社員として私がRSSに対して感じたことや、今後の期待について書いてみたいと思います。
入社1年目社員、レガシー環境に出会う
キャリア研修（中途入社者のための研修）終了後ほどなくして、社員S.R.より相談を受けました。
「Google CloudにあるCloud SQL (MySQL) インスタンスを急いでアップグレードしなければならない」とのこと。詳細を聞いていくと、RSS内システムにおける、綺麗とは言いきれない実態が見えてきました。
具体的には、Google Cloud上にデプロイされているRDBのうち数十インスタンスがMySQL 5.6もしくは5.7のままで運用されていました。MySQL 5.7のリリースは2015年でほぼ10年前のバージョンで、今新たにMySQLを採用するなら8.0や8.4といったバージョンを選択するのがより適切です。幸いにしてGoogle Cloudの側でMySQL 5.6、5.7にサポートを提供していますので完全な「危殆化」しているわけではありません。しかしMySQLとしては決して新しいバージョンとは言えず、むしろ「レガシーDB」と言って差し支えない状況です。
古いソフトウェア環境が使われ続けていることに懸念を感じることに加えて、今回は経営目線でもはっきり分かるリスクが目に留まりました。
Cloud SQL の延長サポート | Cloud SQL for MySQL | Google Cloud
Googleによる延長サポートについて、2025年2月からはvCPU毎の追加費用がかかるようになります。相談を受けたのは2024年10月で、残り3ヶ月を切っていました。
当社において、延長サポートによるコスト負担が無視できない金額になることもすぐ分かってきました。試算したところ、今のままでは1年で数千万円の追加コストになります。今すぐに行動を開始するべき事態です。
コスト試算の中でもとりわけ、vCPU二桁後半を擁する大きめのCloudSQLインスタンスが含まれていたことが私としては特に気になりました（このMySQLインスタンスをこの記事では「インスタンスX」とでも名付けておくことにします）。
例えば仮にHA構成で100vCPUとして試算しますと、1USDを150JPYとした場合、このインスタンスだけで大まかに1ヶ月あたり200万円程度追加コストがかかることになります。現状USD/JPYの為替レートを見通しづらいことを考慮すると、このインスタンスだけでも年額2500万円程度を追加コストとして見込まざるを得ないことになります。えらいこっちゃ。
インスタンスXは「もともとオンプレミス環境にあった共用サーバであった」ということが、状況をよりややこしくしていました。
- システムが暗黙に依存している部分（密結合）があり分離が困難である
- アップグレードの可否を単一のシステムだけで決められない
といった共有環境に発生しがちな制約が、今回のアップグレードにおいては大きな足かせとなります。
追加コストの高さと移行が一筋縄でいかなそうであること。すぐさま「それ、やばくないですか！？」という反応をせずにいられませんでした。
「はっきりしない」ことが問題
さて、ここから具体的に何をすればよいのでしょうか。
実は、S.R.からの相談の核心も「そこ」にありました。具体的な技術的問題の難しさ以上に「何を順番にすればよいのかはっきり分析することが出来ていない状態」だったのです。
「分析できない」などと書かれるとギョッとする方もいらっしゃるかもしれませんが……個人的な経験で言えば国内で度々目にしてきた光景でもあります。念のため補足説明をしておくと、単にMySQL 5.6/5.7をアップグレードするだけではおしまいではない、という暗黙の制約も併せて考える必要があります。DBに依存しているアプリケーションが動作しなくなっては元も子もないわけです。DBのアップグレードだけをするのではなく依存するシステムや組織内の課題を整理して、問題が発生しない・発生しづらい順序で対応していく必要があります。ここまでくると、一介のソフトウェア技術者が「はっきり分析」できるとは限らないことが、おぼろげながら分かるかもしれません。
特にRSSの場合、ここ数年で加速度的にシステム開発を続けてきた経緯がありました。一般に組織の急拡大フェーズでは、技術と事業、新規開発と定常運用をバランスよく俯瞰して初めてできるような指摘・予防策が抜け落ちがちです。「ソフトウェアシステムの経年劣化」が気づかぬうちに組織を蝕んでいきます。
加えて、既存の問題が後回しにされたりすると、社員から問題が見えなくなっていく・指摘しづらくなっていくこともしばしばあります。「部屋の中の象」という比喩がありますが、今回は「運用環境で飼っている象」とでも言いましょうか。しかし幸いにして、新入社員の私にとっては、その「象」はまだ良く見えます。その点で、私のほうが有利なところもあるわけです。
見通しを良くする
さて、社内の誰にとっても「はっきりしない」部分がある問題に取り組んでいくことになります。私がまず意識したのは、「はっきりさせる」ことをもう少しだけ具体化して「見通しを良くする」ことでした。社内でもしばしばこの表現を用いて指針を伝えています。言い換えると「次に何をすればいいのかが分からないのであれば、今できることの中で何を選んで実行すれば分かるようになるか、仮説を立てて実行する」ということです。
まずここまでの状況を整理してみます。
- 古いMySQLのサーバが多数ある
- セキュリティ上の脅威ではまだないが、会社が負担するコストが3ヶ月後に急速に膨れ上がるため、早急に更新したい
- クラウドの上の対象のサーバは多数あり、複数のサービスで共用しているものもある。歴史が長く、事情が分からないものもある
- 依存するアプリケーションへの影響を無視できない
- 事情が上記のように込み入っていて何から始めればよいのかが関係者でもはっきりしない
こう並べられるだけでも「見通し」は良くなるものですが、とはいえ次の具体的アクションが一択で決まるわけではなさそうです。判断が要ります。
今回は私の直感で「事情が分からないDB」を一掃することを一旦の目標としました。
さて、組織全体にとっては「一部、事情が分からないDBが混ざっている状態」でしょうが、私にとっては「全て、事情が分からないDB」です。私にとって見れば、やること自体は（決して楽とは思いませんが）単純です。
具体的には、前掲の「複数のアプリケーションが共存している大きいインスタンス」にあるDBを全て順番に調べていきます（幸いDB数は100まではなかったと記憶しています）。各データベースの責任者を既存の管理シートで確認したり、データベースの中身を確認したり、利用状況を確認していきます。過去に運用されていたアプリケーションの残滓もあれば、昔から在籍している社員が、かろうじておぼろげに事情を覚えているDBもありました。
そういったあらゆる調査を経ても有意義な情報が得られないものが「誰にとっても事情が分からないDB」です。事情が分からないDBがあると、そのDBについて次に何をすればよいのかは分かりません。……当たり前ですね。
それを特定し、他の社員に確認を取りながら具体的な対策を練っていきます。特に有効なのは「アーカイブ（削除）する」ことです。地道な結果として、この調査によって、前掲の共有環境にあるDBについても少なくない数（20〜30程度）が「アーカイブ・削除して問題はない」という判断に至ります。決まればやるだけです。
なお、全ての作業で順調であった、ということは決してありません。「本番環境を止めてしまう」という不名誉な事態も経験しました。作業後に「XXXというDBに触れた方いませんか」という連絡がチャットに流れたのです。それ、私がまさに消したDBじゃないですか。久しぶりに全身の身の毛がよだつような感覚。概ね入社2ヶ月目の頃のことでは、なおさら生きた心地もしません。
……と、失敗もあったものの、結果として「インスタンスXから事情が分からないDBを一掃する」ことが出来ました。すると残ったDBについては「必要であるという確信が社員にあり、そのDBについて決める人が誰なのかが分かる」という状態になります。
それに加えて、インスタンスXについて「実はvCPU数を大幅に減らしても問題がない」ということも分かってきました。改めて現状のシステム負荷やクラウド上の設定見直しをすることで、コスト面でのリスクを大幅に下げることに成功します。
意図した通り「見通し」はこの段階で非常に良くなりました。
適切な担当者へ引き継ぐ
全体の「見通しを良く」なったところで、残った個別のDBについて具体的な話をする段階に移らなければなりません。それぞれのシステムからすれば、むしろここからが「移行の本番」と言っても過言ではありません。残ったDBを使用しているシステムの更新も含むよりアプリ開発寄りの議論が必要になります。
この記事ではアプリに関わる論点は割愛しますが、例えば「アップグレード後もログイン出来るのか」とか「文字化けしないか」といった論点を、アプリ固有の事情も踏まえて行っていくということです。特にアプリ毎の事情については、開発者や利用者の視点での丹念な検証が必ず必要になりますので、ここまでのような「新入社員なりのアプローチ」では進めることはできません。
「流石にここから先は手を出しづらいなぁ」と思っていたそのタイミングで、（これは私ではなく別の方の差配によるものですが）アプリケーション開発課から、DBのアップグレード計画を一斉に打診する流れが社内に生まれました。これ幸い。
既に述べた通り、当初のコスト試算では「１年目で数千万になってしまうかもしれない」という危惧がありました。改めて試算をしてみると、年間で1千万を割り込むくらいにまで延長サポートの総額が下がります。併せて、ここまでの過程で不要なリソースを特定したことで、延長サポート以前の基本的な運用コストも削減できていました。為替リスク等見通せないことは多々あるながらも、全体として「コストの上振れはほぼないのでは」というところまで示せるようになりました。
「レガシーDB」が実際に一掃されきるまでにはもう少し時間がかかるでしょうが、入社後わずかな中では、微力ながらも組織に貢献できたのではないかなと思います。
RSSに感じる課題と期待
対策が後手に回っている感覚はあるものの、レガシー環境が残ってしまうこと自体がおかしいとまでは私は思いません。もともとお声がけいただいた経緯も「ソフトウェア技術者・開発プロセスの社内レベルを向上させる」といった趣旨が含まれていましたので、ある程度覚悟していたことでもあります。
会社の将来にとってより重要なのは「問題が明らかになった後に適切な対応をできるか」です。それを念頭にここまでを振り返ってみると、RSSでは予想よりもスムーズに物事が動いていくように感じられ、大変心強い印象です。
ではもう少し掘り下げて、なぜ「スムーズに物事が動いていく」と感じるのか。これについて入社して間もない今の段階では結論は出しづらいのですが、RSSの社員の姿勢が総じて前向きであることは強く関係しているはずです。
レイスグループ全体で共有している考え方に「心得」というものがあります。
https://recruit.race.co.jp/company/philosophy
グループ全体でこの「心得」を重視しているのは、入社時の研修だけでなく、日々のやり取りからも伺われます。この中に「前向き」という項目がそもそもあること、加えて「責任感」「向上心」といった項目があり、日々社員が意識して行動していることが、結果として物事の進行をスムーズにしている大きな要因であろうと思います。
私にとっては「不透明な状況で組織が物事を決められるか」がより大事です。技術的なプロジェクト進行を、漠然とした不安や官僚的な手続きによって阻害される方が、やはり、困ります。RSSについては、技術的な部分においては「手が止まっていた」印象が当初あったものの、技術的に道筋が示せた後は不確実な部分へのリスクの受容も含めて十分以上のスピード感があります。
「レガシー」と判断される環境がRSS内にまだ残っているのは確かです。私の立場としては、そういったレガシー環境を刷新しつつ、AI活用をはじめとした新しい技術要素を取り入れ、クラウドネイティブな開発に向けた施策を行っていくことになります。組織の将来に目を向けてみると、技術的負債が解消された後のRSSには底しれないポテンシャルがある、私はそのように感じます。
レイスシステムソリューションズ株式会社のソフトウェア開発や、
採用に関するお問い合わせについては、下記のリンクにてお問い合わせください。