サービス

ジャンル

職種：エンジニア

職種：ビジネス職

職種：デザイナー

職種：バックオフィス

職種：その他職種

技術

<h2 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-はじめに">はじめに</h2>

<p>こんにちは。dmm4all.top　二次元コンテンツ事業 同人開発部 の鷹羽です。<br />
普段は部長として約40名規模のエンジニア組織のマネジメントをしています。</p>

<p>本記事では長年利用されてきたサーバーサイドのレガシーシステムを、<strong>ビッグバンではなく堅実にリプレイスした</strong>ときの手法や学びについて記載します。<br />
同じようなことで悩まれている方の参考になれば幸いです。</p>

<h2 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-サーバーサイドのレガシーシステム">サーバーサイドのレガシーシステム</h2>

<p>長年利用され続けているシステムであり、DMM社内で作られたPHPの独自フレームワークです。</p>

<p>新規機能の開発など長年使い続けてきた結果、様々な課題が出てきたため、リプレイスをするという決断をしました。</p>

<h2 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-レガシーシステムの課題">レガシーシステムの課題</h2>

<p>リプレイスという判断に至った主な課題は以下の通りです。</p>

<ul>
	<li>一般的なOSSのフレームワークではなく、独自フレームワークのためラーニングコストが高い</li>
	<li>PHPのバージョンが古い（５系）、サーバのOSも古い</li>
	<li>長年の利用によってコードが複雑化し、通常の保守運用もままならない</li>
	<li>ユニットテストツールも導入が難しく、品質担保が難しい</li>
	<li>仕様書や設計書などドキュメントもなく、あったとしてもメンテされていないため信用性が低い</li>
</ul>

<h3 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-コードの複雑化">コードの複雑化</h3>

<p>課題の中でも特にコードが複雑化してしまっているのが致命的でした。<br />
修正頻度の高い処理の循環的複雑度を計測すると、<strong>91</strong>という結果になりました。</p>

<p>91という循環的複雑度がどれほど致命的かは、以下の表を見てもらうと分かりやすいかと思います。</p>

<table border="1" cellpadding="1" cellspacing="1" style="width:500px;">
	<thead>
		<tr>
			<th scope="col">
			<p style="text-align: left;"><strong>循環的複雑度</strong></p>
			</th>
			<th scope="col">
			<p style="text-align: left;"><strong>複雑さの状態</strong></p>
			</th>
			<th scope="col">
			<p style="text-align: left;"><strong>バグ混入確率</strong></p>
			</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>
			<p>１０以下</p>
			</td>
			<td>
			<p>非常に良い構造</p>
			</td>
			<td>
			<p>２５%</p>
			</td>
		</tr>
		<tr>
			<td>
			<p>３０以上</p>
			</td>
			<td>
			<p>構造的なリスクあり</p>
			</td>
			<td>
			<p>４０％</p>
			</td>
		</tr>
		<tr>
			<td>
			<p>５０以上</p>
			</td>
			<td>
			<p>テスト不能</p>
			</td>
			<td>
			<p>７０％</p>
			</td>
		</tr>
		<tr>
			<td>
			<p><strong>７５以上（ココ）</strong></p>
			</td>
			<td>
			<p><strong>いかなる修正もバグを生む</strong></p>
			</td>
			<td>
			<p><strong>９８％</strong></p>
			</td>
		</tr>
	</tbody>
</table>

<p>※参考：エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング</p>

<p>そのため、簡単な改修でも品質担保がかなり難しい状態でした。</p>

<p>また、新規機能開発などの案件着手時に担当エンジニアから</p>

<p>「サーバーサイドがこのレガシーシステムなので、実現が難しい。」<br />
「実現しようとしたら、通常の数倍の工数がかかる」</p>

<p>という意見が出てしまうほどで、事業運営をしていく中で常にボトルネックになっていました。</p>

<p>&nbsp;</p>

<h2 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-プロジェクトの立ち上げ">プロジェクトの立ち上げ</h2>

<p>リプレイスのプロジェクトを立ち上げるにあたって、「やること」「やらないこと」を定義しました。</p>

<h3 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-やること">やること</h3>

<ul>
	<li>レガシーシステムをサーバごと全て新しいシステムに切り替える</li>
	<li>新しいシステムにおいて、コードの保守性や品質担保が高く保てる仕組みを構築する</li>
	<li>進め方として3段階のフェーズに分け、各フェーズごと順番に進める（詳細は後述）</li>
	<li>画面設計書を新規で作成し、それを元に実装を行う</li>
	<li>URLによる振り分けを利用し、ページ単位で切り替えをリリースする</li>
</ul>

<p>特に最後の</p>

<ul>
	<li>URLによる振り分けを利用し、ページ単位で切り替えをリリースする</li>
</ul>

<p>という、いわゆるストラングラーパターンが本プロジェクトの重要な点でした。<br />
この方法を取ることにより、1回のリリースまでの期間が短くなり、リスクを抑えてリリースすることが可能になりました。</p>

<p>もし新システムに全てのページ＆機能を実装してからビッグバン的なリリースを行う場合、以下のデメリットがあると考えています。</p>

<ul>
	<li>リリースまでに時間がかかる
	<ul>
		<li>その間にレガシーシステムにリリースされた機能追加など案件の内容を追従しないといけなくなり、さらに時間がかかる</li>
	</ul>
	</li>
	<li>リリース後に不具合があった場合、切り戻しなどが難しく、最悪の場合は環境ごとすべて切り戻す必要が出てくる
	<ul>
		<li>何かあったときのリスクが大きい</li>
	</ul>
	</li>
</ul>

<h3 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-やらないこと">やらないこと</h3>

<ul>
	<li>他システムは本プロジェクトでは改修しない</li>
	<li>テーブル定義などDB側の変更は基本的に行わない</li>
	<li>現行仕様を踏襲し、ユーザーからの見た目や使い勝手は変えない</li>
	<li>フロントエンド改善の議論は行わない</li>
	<li>新しいシステムに切り替えたことにより、パフォーマンス劣化などユーザーにとって不利益を与えない</li>
</ul>

<p>特に最後の</p>

<ul>
	<li>新しいシステムに切り替えたことにより、パフォーマンス劣化などユーザーにとって不利益を与えない</li>
</ul>

<p>が重要だと思っています。<br />
いくら新しいシステムになって開発者が喜べる状況になっても、ユーザーにとって不利益があれば、それは改悪だと考えています。<br />
ユーザーに不利益が無いよう、慎重に進めることを意識しました。</p>

<h2 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-進め方とフェーズ">進め方とフェーズ</h2>

<p>以下３つのフェーズに分けて進めました。</p>

<ol>
	<li>新しいシステムに1ページのみ置き換え、効果測定</li>
	<li>全てのページを新しいシステムに置き換える</li>
	<li>レガシーシステムをサーバごと全て無くす</li>
</ol>

<h3 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-フェーズ１．新しいシステムに1ページのみ置き換え、効果測定">フェーズ１．新しいシステムに1ページのみ置き換え、効果測定</h3>

<p><img alt="" data-base-url="https://confl.arms.dmm.com" data-image-src="/download/attachments/1991652817/image-2024-5-1_17-13-57.png?version=1&amp;modificationDate=1714551236078&amp;api=v2" data-linked-resource-container-id="1991652817" data-linked-resource-container-version="23" data-linked-resource-content-type="image/png" data-linked-resource-default-alias="image-2024-5-1_17-13-57.png" data-linked-resource-id="1991653882" data-linked-resource-type="attachment" data-linked-resource-version="1" data-unresolved-comment-count="0" draggable="false" height="250" src="https://confl.arms.dmm.com/download/attachments/1991652817/image-2024-5-1_17-13-57.png?version=1&amp;modificationDate=1714551236078&amp;api=v2" /></p>

<p>まずはPVが少なく、万が一何かがあってもユーザー影響の少ないページを選出し、そのページのみ新システムに移行しました。<br />
「1ページ」の中には全ページで利用が必要な共通処理（ログイン処理など）や開発環境整備、新システム用サーバ構築なども含まれます。<br />
※次フェーズで全ページを移行していくための土台作りが本フェーズに当たります。</p>

<p>開発環境整備と一言で言っても、今までなかったユニットテストの導入、循環的複雑度を低く保つための仕組みづくりなど、やるべきことは多岐にわたりました。<br />
しかし、ここを軽んじてプロジェクトを進めてしまうと、過去のレガシーシステムの二の舞であると関係者全員が分かっていたため、しっかり話し合って進めることができました。</p>

<p>効果測定としては以下を実施しました。</p>

<ul>
	<li>循環的複雑度の計測</li>
	<li>ページ表示速度の比較</li>
	<li>メモリ使用量の比較</li>
</ul>

<p>効果測定の結果、もし悪くなっていたらサービスインせずに切り戻し、改善して再度効果測定をする、という流れでこのフェーズは進めました。</p>

<h4 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-このフェーズで起きたこと、学び">このフェーズで起きたこと、学び</h4>

<p>実際、初めて新システムができた時の<strong>ページ表示速度は、レガシーシステムより悪い</strong>という結果になりました。<br />
明らかに新システムの方が実行されるコード量も少なく、シンプルになった理想形のはずなのに&hellip;&hellip;。</p>

<p>頭を悩ませながら調査したところ、レガシーシステムは長年にわたり利用されてきた秘伝のタレ的な感じで（かなり読み解きづらかったですが）随所にキャッシュ利用などの高速化処理が実施されていることが分かりました。<br />
<strong>レガシーシステムだからといって侮るなかれ、学ぶものは多々ある</strong>ということを思い知らされたフェーズでした。</p>

<p>また循環的複雑度については、前述の通り<strong>91だったところから、すべて10以下を保つ仕組みが構築できた</strong>のがこのフェーズの大きな成果でした。</p>

<p>その他、いくつかの課題をクリアしたうえで、次フェーズへ進めることができました。<br />
&nbsp;</p>

<h3 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-フェーズ２．全てのページを新しいシステムに置き換える">フェーズ２．全てのページを新しいシステムに置き換える</h3>

<p><img alt="" data-base-url="https://confl.arms.dmm.com" data-image-src="/download/attachments/1991652817/image-2024-5-1_17-15-0.png?version=1&amp;modificationDate=1714551299386&amp;api=v2" data-linked-resource-container-id="1991652817" data-linked-resource-container-version="23" data-linked-resource-content-type="image/png" data-linked-resource-default-alias="image-2024-5-1_17-15-0.png" data-linked-resource-id="1991653888" data-linked-resource-type="attachment" data-linked-resource-version="1" data-unresolved-comment-count="0" draggable="false" height="250" src="https://confl.arms.dmm.com/download/attachments/1991652817/image-2024-5-1_17-15-0.png?version=1&amp;modificationDate=1714551299386&amp;api=v2" /></p>

<p>このフェーズでは、ページ単位で新システムに移植していきました。</p>

<p>フェーズ１で実施した効果測定もページ単位で常に実施し、リリースしてもよいかの判定として利用しました。</p>

<h4 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-このフェーズで起きたこと、学び.1">このフェーズで起きたこと、学び</h4>

<p><strong>ページ単位でのリリースを行うことで、かなりのメリットがあると学べた</strong>フェーズでした。<br />
具体的には以下の通りです。</p>

<ul>
	<li>1ページごとに担当エンジニアをアサインすることで、同時並行で複数のページの移植作業が進められた</li>
	<li>他の機能追加などのキャッチアップやリリース調整が容易</li>
	<li>ページ単位でのリリースのため、何が不具合があった場合の切り戻しなどが容易</li>
	<li>画面設計書作成や効果測定など常に行う作業もリリースをこなすごとにルーティン化し、徐々にスピードアップすることができた</li>
</ul>

<p>&nbsp;</p>

<h3 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-フェーズ３．レガシーシステムをサーバごと全て無くす">フェーズ３．レガシーシステムをサーバごと全て無くす</h3>

<p><img alt="" data-base-url="https://confl.arms.dmm.com" data-image-src="/download/attachments/1991652817/image-2024-5-1_18-3-17.png?version=1&amp;modificationDate=1714554196878&amp;api=v2" data-linked-resource-container-id="1991652817" data-linked-resource-container-version="23" data-linked-resource-content-type="image/png" data-linked-resource-default-alias="image-2024-5-1_18-3-17.png" data-linked-resource-id="1991654205" data-linked-resource-type="attachment" data-linked-resource-version="1" data-unresolved-comment-count="0" draggable="false" height="150" src="https://confl.arms.dmm.com/download/attachments/1991652817/image-2024-5-1_18-3-17.png?version=1&amp;modificationDate=1714554196878&amp;api=v2" /></p>

<p>フェーズ２で全ページの移植が完了したのち、本フェーズでレガシーシステムを無くすための撤去作業を行います。<br />
また、サーバ撤去だけでなく、コード管理していたリポジトリの削除なども対応しました。</p>

<h4 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-このフェーズで起きたこと、学び.2">このフェーズで起きたこと、学び</h4>

<p>長年使い続けてきたシステムだったので、撤去に向けてサーバへの残通信調査など想定以上の作業が発生しました。<br />
また、サーバやソースコード関連の作業だけでなく、ドキュメントの修正など作業範囲は多岐にわたりました。</p>

<p>当初から予定していたフェーズでしたが、レガシーシステムからのリプレイスは<strong>新システムをリリースしてサービスインしておしまいではない</strong>ということを、改めて気づかされたフェーズでした。</p>

<p>&nbsp;</p>

<h2 id="id-サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話-最後に">最後に</h2>

<p>本施策は大掛かりだったため、私一人の力では完了できなかったと思います。<br />
ご協力いただいた方々（各ページ移設の担当者やプロジェクト進行を主導いただいた方（特に同人開発部 唐崎さん、荒尾さん））に感謝を。</p>

<p>&nbsp;</p>

<p>本記事に関して詳細が知りたい、もう少し話を聞いてみたい、求人に少し興味が出たが応募までにカジュアル面談してみたいなどあれば、遠慮なくお声がけください。<br />
以下からカジュアル面談も可能ですので、気軽にリクエストしてください。<br />
<a href="https://pitta.me/matches/QbXoDwORqszC" rel="nofollow">https://pitta.me/matches/QbXoDwORqszC</a><br />
<a href="https://youtrust.jp/recruitment_posts/dc2daf42866dc054bc815588d968806b">https://youtrust.jp/recruitment_posts/dc2daf42866dc054bc815588d968806b</a><br />
<br />
二次元コンテンツ事業 同人開発部では、一緒に働く仲間を募集しています。<br />
ぜひご応募ください。</p>


電子書籍

PCゲーム

同人

サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話

サーバーサイドのレガシーシステムを、ビッグバンではなく堅実にリプレイスした話

シェア

一緒に働く仲間を募集しています！

関連する求人

関連する記事