仕様の複雑化、過渡期特有の難解なコード、技術スタックの老朽化… システムの健全な成長を妨げる要因に対する基本戦略 - ログミーTech
要約:
- 成瀬允宣氏、GMOインターネットグループ所属のデベロッパーエキスパートが、システムアーキテクチャの刷新についての取り組みと成果を発表。
- システムアーキテクチャ刷新の背景として、組織の継続的成長の必要性を強調。
- システム成長の阻害要因として、仕様の複雑化、過渡期特有の難解なコード、技術スタックの老朽化を指摘。
- 仕様の複雑化：サービスの成長に伴い機能が追加され、仕様が複雑化する。
- メンバーの入れ替わり：新しいメンバーの参加と古いメンバーの退職により、情報の伝達と理解にギャップが生じる。
- ドキュメントの不確実性：メンテナンスが行われず、時代遅れの情報が残る問題。
- 過渡期特有の複雑なコード：他プロジェクトからのコード流用や未熟なコードが成長を阻害。
- 動いていることが正義という考え方によるリファクタリングの欠如。
- 古い技術スタックの使用：例えば、ASP.NETの旧バージョンなどが依然として使用されている。
- 成瀬氏は、これらの課題に取り組み、システムアーキテクチャを刷新する過程での学びや成果を共有。
- 「Struts」の使用：2001年から使われており、当時の技術スタックが現在も使用されている。
- VB（Visual Basic）の使用：20年前は主流だったが、現在は.NET Frameworkの一部としてほぼC#と同じだが、若干の構文の違いがある。
- パッケージマネージャーの欠如：「npm」が2010年に登場したが、多くのプロジェクトではパッケージマネージャーが未導入で、最新の技術スタックとは異なる状況。
- 健全なシステムを目指す重要性：現在の問題を排除し、成長しやすいシステムを目指すべき。
- システムの分解と疎結合：巨大なモノリシックなシステムを小さな単位に分解し、理解しやすくする。また、密結合なシステムを疎結合に変更する。
- コードの多様性の削減：無意味なコードの多様性を減らし、書き方をある程度統一する。
- 逆コンウェイ戦略の採用：望ましいアーキテクチャを実現するために、組織やチームの構造を進化させる。
- マイクロサービスの採用：サービスのサイズが小さく、互いに疎結合であることが目標に合致。
- 重要な参考文献：『マイクロサービスパターン』と『モノリスからマイクロサービスへ』。
- Pub/Subのアーキテクチャの採用：サービス間の依存関係を疎にし、チームの成長を阻害しない。
- Proof of Concept（PoC）の実施：フレームワークに依存せず、新しいシステムに移行する方法の検証。
- マイクロサービスの実装：「Akka」「Axon」「Eventuate」「Spring Boot」＋「Spring Cloud」などのフレームワークの評価と選択。
- CQRS+ESの実現に必要なライブラリの開発：「Kinesis」などのメッセージブローカーの利用。
先行開発事例の作成：新しいアプローチの道筋を示し、他者が従いやすくする。
「イネイブリングチーム」の結成：スキル習得を支援する専門チームを作成。
- メンバーの学習フェーズ：新しいアーキテクチャの習得に時間を要した。
- 属人化の問題への対応：イベントストーミングを用いて、ドキュメントのメンテナンスを組み込むことで対処。
- 技術支援の強化：経験豊富な外部の専門家を技術支援として迎え入れる。
- 多くの失敗と学び：フレームワーク選定ミス、複数プロジェクトの同時進行、意思疎通の問題など。
- イネイブリングチームの成功：技術支援の強化により、他チームへの教育効果が上昇。
- マイクロサービスの採用：SpringとAxon Frameworkを用いたシステムが完成。
- イベントストーミングの効果：開発者が図を参照しながらコードを書く習慣が形成される。
- Pub/Subアーキテクチャの実現：Kafkaを用いたデータ伝達でサービス間の依存関係を緩和。
- アーキテクチャ刷新の成果：仕様の複雑化の解消、難解なコードの解決、技術スタックの更新。
- アーキテクトの役割：後続のメンバーのために道を切り開くことが重要。
