長期的な視点で挑むアーキテクチャの再設計と最適化への挑戦
ミイダスでは「M2プロジェクト」と称して、サービス改善と拡張に向けた長期的な開発の取り組みを実施しています。リリース後に明らかになったパフォーマンスの問題や機能拡張の要求に応えるため、このプロジェクトはサービスのスケーラビリティと保守性の向上を目標として掲げています。
しかし、その目標達成への道のりはまだ終わりを見せていません。サービスリリース後、避けて通れない成長の痛み ―パフォーマンスの低下、コードベースの複雑化、そして開発の遅れ― に直面しながらも、私たちはそれらに対応するための継続的な努力を積み重ねてきました。
新しい機能の開発が追加されるたび、M2プロジェクトは一時的に中断され、将来にわたって生じうる問題への対策を織り交ぜながら改善を続けています。今回はこの挑戦的なプロジェクトを担当した宮本と磯崎に、理想と現実の狭間について赤裸々に語っていただきました。
ーー 初めに自己紹介をお願いします。
宮本: 宮本です。私はアーキテクチャの設計と、新しいシステムへの移行を支援しています。具体的には、アーキテクチャの設計とそれに必要な基盤にあたる箇所のプログラミングに従事しています。ミイダスの開発に関わって既に7〜8年になります。ミイダスはとてもユニークな会社で、業務委託でありながら長期的にプロジェクトに取り組めるのが良いですね。
磯崎：ミイダスのCTOを務めている磯崎です。新卒からSIerで15年ほど働き、初めての転職先としてインテリジェンス（現：パーソルキャリア）に入社しました。SIerでは証券会社や保険会社など、大規模サービスの保守業務に携わっていましたが、新規サービス開発に興味があり、当時のインテリジェンス内での新規事業であったミイダスの立ち上げに参加しました。
ーー M2プロジェクト発足の背景について教えて下さい。
宮本: ミイダスっていう会社は、ほとんどスタートアップみたいな感じで動いているんですよ。私が入ったのも、ミイダスが完成した直後くらいで。スタートアップらしく、最初はとにかく製品を早く市場に出すこと、そして必要な機能を追加していくことに集中していました。でも、その後の機能拡張やユーザー数の増加に合わせた対応が少し疎かになってしまっていたんです。
そこで、まずはこの問題を解決しなければならないと考えました。データ量が増えた結果、速度が低下するという問題はリリース直後から存在していたので。
M2プロジェクトは、こうした問題を根本から解決するために立ち上がりました。一時的な対処ではなく全体を見直す必要があったからです。
磯崎: サービスが大きくなっていくに従って、性能の問題や保守性、そして全体の拡張性のところをしっかりと改善していく必要があるんですよね。途中でコードがごちゃごちゃになってくると「作り直したい」と思うこともあります。さらにチームの人数が増えてくると、みんなで同時に開発を進めるのが難しくなってきます。
そこで、データを分割したりソースコードの構成を見直したりすることを考えました。この新しい取り組みで全部が解決するわけではないんですけど。少なくとも今出てる問題には対応できると思っています。
ーー 開発中に直面した最大の課題はなんでしょうか？
宮本: 最大の課題は、既存のシステムを維持しながら新しい技術に移行することでした。例えば、バックエンドをGoに移行するなど大きな変更が必要でした。しかし、全てを一度に変更するわけにはいかないので、段階的に進める必要がありました。
ミイダスのバックエンドに関しては、シングルページアプリケーションへの移行に伴い、M2プロジェクト以前にHackLangで開発されていた部分をGo言語で書き直しています。現在はこれをさらにM2化していかなければいけません。この作業は、同じGO言語内で行われるわけですが、別のプロジェクトメンバーが取り組んでいるフロントエンドとM2で取り組む範囲には違いがあります。特にフロントエンドは、シングルページをよりモダンな形に進化させる方向で取り組まれてます。
磯崎: そうですね。データベースの分割やAPIの再設計など、技術的な挑戦が多くありました。このプロジェクトにおいて、データベースの分割が非常に大きな役割を担っています。しかし、この作業は終わりが見えず、非常に時間がかかっています。現在、600〜700ほど存在するAPIの中で、まだ200〜300が手付かずの状態で残されています。
宮本: さらに、ミイダスでは機能追加や変更が多すぎるという問題も抱えています。変更に伴う修正コストとM2への移行作業を同時に進めることが難しいため、結果としてそのままの修正を加え続けることが多いです。
磯崎: こうした問題はよくある話です。理想としては、サービスを一時停止し機能追加も中断して、ゼロベースでのリニューアルを行えたらと思います。しかし現実にはそのようなことはビジネスの都合的に難しいです。そのため、私たちはその方法を取らずに、少しずつ問題を解決していく方針を取っています。ただ、この方法だと終わりが見えないことが多いんですよね。数年前からずっと頑張って続けている状況です。
ーー アーキテクチャの再設計におけるアプローチについて教えて下さい。
宮本: 私たちは、将来的にも持続可能なアーキテクチャを目指しました。色々なアーキテクチャについては勉強しましたが、機能追加が多いこともあり教科書通りにやるのは難しいなと感じました。そのためしっかしとしたレイヤーを持つこと、業務ロジックを担うモデルとその他の部分をきちんと分けることに重点を置いたアーキテクチャを意識しました。
システムを構成する各レイヤーを明確に分け、業務ロジックとその他の部分とをきちんと分離することで、時間が経過してもシステムが古くなりにくい構造を実現することができたのです。何年か経っていますが、"古臭いね"と言われることはほとんどありません。アーキテクチャの劣化を避けるために、長期的な視点での再設計を目指した方向性としては、うまくいってると思います。
ーー 現在のプロジェクト体制について教えて下さい
宮本: 実は、新しいものを作るときは全員でM2プロジェクトの方法で取り組むようにしているんです。だから専任の人がいるわけではなく、手が空いた人が担当しています。
例えば、飛行機の片方の翼をM2プロジェクト仕様に変えて、もう片方は古いままというケースはよくあります。しかしその状態でもうまく飛ばなくてはいけません。一部をM2プロジェクト仕様に切り替えながらも、全体がしっかり機能するように気を配っています。
ーー M2プロジェクトの振り返りと今後
磯崎: データを変えずにソースコードだけを更新するのか、データだけをまず移行してしまうなど、個々の部品ごとにアプローチがあります。システムをリプレイスする過程で、誰もが直面する壁です。厳しいものがありますが、その中でどう工夫し、どうスケジュールを組むかが重要です。
完璧なものを作ろうと思っていても、結局多くの妥協が必要になります。ただ、段階的に取り組むことで、失敗のリスクを減らしながら、より良い解決策を見つけることができます。
どんな方法がベストだったかは結局分かりませんし、どの方法を選んでも、"ああ、やっぱりあっちの方法でやっておけばよかった"と思うことが出てきます。重要なのは、しっかりと議論をして、準備を整えること。そして時間がかかるという理解も必要です。新しい人がチームに入った時に、"どっちのバージョンを使えばいいのかわからない"という状況や中途半端に投げ出すことを避けなければなりません。
宮本: 磯崎さんが話してくれたように、新しいシステムを作り直すことは外から見るとカッコいいですが、実際は非常に泥臭い作業です。どちらが良いかの正解を見つけるのは難しく、私たちは初期段階で多くの議論をしました。正解を出すことができれば楽ですが、そう簡単にはいきません。
最初にどのようなコストを払うか、そしてその後日々どのようなコストが発生するかをしっかりと考えてスタートしました。最終的には、プロジェクトの中で出会った課題に対して、私たちなりのベストな解決策を常に見つけ出しているんです。
磯崎: 何か特別な方法を使ったわけではなく、地道にやるしかないことなので。。
宮本: サービスを一時停止して全面的にリニューアルする方法と比べて、議論に時間をかけた分、後悔が少なかったと感じています。ただ、新しくシステムを置き換えるとなると、必ず多くの妥協点が出てきます。"この日までに設計を終えなければならない"とか、考慮していなかった例外ケースが出てきて設計が崩れたり。
今更作り直すわけにもいかないという状況になりがちです。だから、全部を粛々と進めるという方法はおすすめできないですね、でも、必要ならば仕方がないということで。リニューアルしたかったのは事実ですが。
初めに、新機能の開発を一時的に停止できないかと提案もしました。でも、当然ながら受け入れられなかったので、今の状態に至っていますね（笑）。
ミイダス Techについて
ミイダスでは、様々な技術イベントを開催しています。connpassやYouTubeチャンネルでミイダスグループのメンバーになった方には、最新の開催情報やアーカイブの公開情報が届きますのでぜひご登録をお願いいたします。
イベントページ：https://miidas-tech.connpass.com/
Twitter：https://twitter.com/miidas_tech
この記事が気に入ったらサポートをしてみませんか？