アーキテクチャ刷新の現場 / Scene of architectural renewal

アーキテクチャ刷新にどのように立ち向かったかのお話です。

何を予測し
何を準備し
何を失敗したか

そんなお話です。

【プロポーザル】
ある特定の課題を解決するために、未知の技術や方法を採用する必要に迫られる状況は、技術者のキャリアの中で度々出くわすものです。 私も最近、そのような挑戦的な状況に直面しました。 このセッションでは、新しいアーキテクチャや技術基盤を導入する過程で私が行った取り組みや準備、そしてそれらの採用によってもたらされた実際の結果や変化についてお話します。 採用の背景から選択の過程、そして実際の結果までの道のりを通して、未知の技術やアーキテクチャの採用に関する有益な知見や学びを共有いたします。

こちらはGMO Deceloper Day 2023 でお話しました。
詳細は以下をどうぞ。
https://developers.gmo.jp/developersday/?session=40095

YouTube: https://www.youtube.com/watch?v=gejnwpvsWJE
Code: https://github.com/nrslib/pubsubdoc

# URL
YouTube: https://www.youtube.com/c/narusemi
HomePage: https://nrslib.com
Twitter: https://twitter.com/nrslib

Transcript

1. アーキテクチャ刷新の現場
2. ことのあらまし 課題予測と事前準備 失敗と成果 まとめ アーキテクチャ刷新の現場
3. ことのあらまし 課題予測と事前準備 失敗と成果 まとめ アーキテクチャ刷新の現場
4. 成長し続けなくてはならない
5. システムの成長を阻害する要因 ・仕様の複雑化 ・過渡期特有の難解なコード ・技術スタックの相対的な老朽化 システムが成長し続けるために必要なこと
6. 仕様の複雑化 ・サービスの成長に伴う機能追加 「こんな機能あるんだ……」 ・メンバーの入れ替え 「あ、そこは〇〇さんが詳しいよ。え？退職した？そう……」 ・ドキュメントの不確実性 メンテナンスを欠かしていない者だけが石を投げなさい システムが成長し続けるために必要なこと
7. 過渡期特有の複雑なコード ・コードは別のプロジェクトに侵食する うまくいったサービスのコードはその巧拙を抜きに”参考”される ・チャレンジコード 誰しも初めてはあるよね＋忙しい、が合わさると レビューをすり抜けて理解に苦しむコードが生まれる ・動いているのが正義なのでつぎ足します リファクタリングの選択肢がないためにダラダラと システムが成長し続けるために必要なこと
8. 技術スタックの相対的な老朽化 ・MVCナニソレ ASP.NET MVC 1.0 が2009年3月、Strutsは2001年 ・VB ただ、結局.NETだからモダンだと思う ・パッケージマネージャ？ ないよ ちなみにnpmが2010年らしい システムが成長し続けるために必要なこと
9. 成長しやすいシステムを目指す ・巨大なシステムを小さなシステムに 理解の範囲を狭める ・密結合なシステムを疎結合なシステムに 依存関係を整理して、互いを疎に ・無意味なコードの多様性を排除 システム間連携と基本コードの指針を準備 健全な成長は健やかなシステムから
10. チームの機敏性を確保する
11. ことのあらまし 課題予測と事前準備 失敗と成果 まとめ アーキテクチャ刷新の現場
12. コンウェイの法則と逆コンウェイ戦略 コンウェイの法則 システムを設計する組織は 自らのコミュニケーション構造を まねた設計を 生み出すように制約される。 基本戦略 逆コンウェイ戦略 チームと組織構造を進化させて 望ましいアーキテクチャへ 促進する
13. まずはマイクロサービスの情報収集 ・サービスのサイズが小さい →理解の範囲が狭くて済む ・サービスは互いに疎である →サービスは独立して成長できる 望ましいアーキテクチャは何か どうやらこの方向に進んだらよさそうだ
14. マイクロサービス実践にあたって学習 特に役に立ったのはこの2冊 ・マイクロサービスパターン 実装面で困難となる個所を知る CQRS+ESによるPub/Subがゴールである予測をする ・モノリスからマイクロサービスへ 現状をマイクロサービス化していくうち 最も困難となる移行のテクニックを習得 マイクロサービスに向かって進む
15. 目指すはPub/Sub マイクロサービスに向かって進む サービスAはデータをイベントでもつ そのイベントをMessageBrokerに送出する MessageBrokerのメッセージを 任意のタイミングで他サービスが利用する ↓ サービスBがサービスAに依存しない ＝疎結合なシステム開発
16. 自前実装によるPoC ・フレームワークに依存できない 一般的なMVCなどと比べて マイクロサービスに関しては先駆者がいないため 自らが先駆者となる必要がある そのため誰よりも知っておく必要がある ↓ということでCQRS+ESを理解するために自分で実装した（JDBC,CosmosDB, DynamoDB） https://github.com/nrslib/microservice-with-event-sourcing-sample-kotlin マイクロサービスに向かって進む
17. フレームワーク選定 ・CQRS+ESを実現するために比較検討 Akka: Scalaとアクターモデルがネック Axon Framework: 情報少ない Eventuate Tram: EventSourcingを意識してコードを書く必要がある Spring Boot + Spring Cloud: EventSourcingするのはまぁまぁ骨が折れそう マイクロサービスに向かって進む
18. フレームワーク選定 ・CQRS+ESを実現するために比較検討 Akka: Scalaとアクターモデルがネック Axon Framework: 情報少ない Eventuate Tram: EventSourcingを意識してコードを書く必要がある Spring Boot + Spring Cloud: EventSourcingするのはまぁまぁ骨が折れそう マイクロサービスに向かって進む ☆当初
19. フレームワーク選定 ・CQRS+ESを実現するために比較検討 Akka: Scalaとアクターモデルがネック Axon Framework: 情報少ない Eventuate Tram: EventSourcingを意識してコードを書く必要がある Spring Boot + Spring Cloud: EventSourcingするのはまぁまぁ骨が折れそう マイクロサービスに向かって進む ☆現在
20. ライブラリ作成 メッセージブローカーにイベントを送出する必要がある →ストリーム処理のためAmazon Kinesisを利用する →そのためのライブラリが必要なので開発 （Kinesis Connector Libraryベース） マイクロサービスに向かって進む
21. 先行開発事例 道を切り拓かないと誰もついてこない →事例を作るのがとにかく先決 →ひとつのサービスをまずは打ち出すため、メンバーと一緒に作り始める →まずはコンセプトの説明から 実現に必要なものを揃える
22. 必要なのはフレームワークだけじゃない メンバーはこれまでにないアーキテクチャを習得しなくてはならない →現業をおろそかにはできない →新規技術をキャッチアップするには何かしらの施策が必要 実現に必要なものを揃える
23. 組織・メンバーの成長を支援する方法 参考になった本はチームトポロジー 特にイネイブリングチームの考え方が 今回のスキル習得支援にもっとも適合 実現に必要なものを揃える
24. イネイブリングチーム結成 当初は自分に加えてもう１名（Aさん）の計２名からスタート 先ほどのサービス開発を担当するメンバーの支援をする とはいえ最初はAさんもはじめて触るアーキテクチャなので 将来を見越して学習するフェーズ 実現に必要なものを揃える
25. 俗人化を避けるにはドキュメントしかない ドキュメントがメンテナンスされない理由は明白 →実装者に実利が少ないから →開発のフローにドキュメントのメンテナンスを 組み込んだほうが得と思えるような手法が必要 仕様の複雑化への対応策
26. イベントストーミング 仕様の複雑化への対応策
27. 図とコードが一致する 仕様の複雑化への対応策 イベントストーミング図の付箋はそのままクラスになる →図を描くことがコードのヒントになる コードの変更がどこに影響するかわかる →意図せぬ変更の防止により安全性を向上 後発のメンバーも図を見て把握できる →キャッチアップが容易になるとメンバーのスケーリングも可能
28. 初めてのことが多いため困難が予測される 説得力を得るために 技術支援を入れてもよいとのお達しを受ける とはいえ、この規模で、かつこういった形のマイクロサービスを やっている組織は本当に少ない 自分のツテで信頼できる人に技術支援として参画してもらった 壁打ち相手として非常に助かった
29. ことのあらまし 課題予測と事前準備 失敗と成果 まとめ アーキテクチャ刷新の現場
30. 失敗には学びが多い
31. フレームワーク選定ミス Akka有料化に完全に巻き込まれる 開発の最中であったので様子見ができず即決断を求められる プランBであったAxon Frameworkにフレームワークを変更 結果的にこれはハレーションが減少させたので功を奏したといえる 失敗を見ていこう
32. フレームワーク変更の余波 せっかく作ったKinesis用ライブラリは使えません メッセージブローカーどうしましょう？ Axon Frameworkとの相性も考慮してKafkaに舵取りし直し Topic? SASL+SCRAM? ﾅﾆｿﾚ? から土日で一気にキャッチアップ 失敗を見ていこう
33. 複数プロジェクト同時並行 当初より無理があると感じていたが 複数チームで同時にマイクロサービス化を推進しはじめた 事例もない中多くのメンバーが同じ方向に進むのはやはり難しい そもそも自分しかいない状況で全チームサポートは不可能に近い 失敗を見ていこう
34. 逆コンウェイ戦略をもくろんだチーム改変 逆コンウェイ戦略を狙ったようなチーム改変があった 残念ながら逆コンウェイ戦略はあくまで戦略でしかなかった アーキテクチャの変更をする「余力」と「実行力」がない場合は 現状のアーキテクチャに沿ったコミュニケーションが継続される 失敗を見ていこう
35. 先行事例を人任せにした サービスの担当者にコードを書いてもらい始めた →間接的なコーディングが非常に難しく進捗が出づらくなってしまった いったん引き取って、先行事例は自分が作ることに 失敗を見ていこう
36. 成果を出すまでの期間について意思疎通がうまくいっていなかった あと歩く 道拓くは 険し道 PoCや調査含めて１年程度では花開かず、年度末ごろ方針変更を下された 自分が手掛けていた先行事例まであとわずかであったため １サービスのアーキテクチャシフトの継続を死守 失敗を見ていこう
37. 準備の成果はあったのか？
38. イネイブリングチームの活躍 最初のイネイブリングチームとして発足したチームは現在9名 うち技術支援をメインとしているメンバーは4名 現在7チームを同時支援 準備の成果
39. マイクロサービス 目論見通りのアーキテクチャのシステムの完成 Spring+Axon Frameworkはハレーションが少ない （コードの見た目はほぼSpring） どの粒度でコードを区切り、どうやってAPIをコールして、 それを自サービスに紐づけて、といったコードが 基本的に同じ書き方になった 準備の成果
40. イベントストーミング 本格的なマイクロサービスになると イベントストーミング図なしでは理解が困難になる まずは図を作り、それを見ながらコードを書くという習慣を 自然とメンバーが習得しているのを観測できた 準備の成果
41. Pub/Subの実現 メッセージブローカーをKafkaにしたことで イベントデータを無制限に保存する選択肢が増えた ジャーナルDBからデータを読み取らなくても リードモデルのデータ読み取りで Kafkaを参照するだけで済む （CPUや通信料の節約） 準備の成果
42. ことのあらまし 課題予測と事前準備 失敗と成果 まとめ アーキテクチャ刷新の現場
43. 課題は解決できたのか？
44. システムの成長を阻害する要因 ・仕様の複雑化 ・過渡期特有の難解なコード ・技術スタックの相対的な老朽化 システムが成長し続けるために必要なこと 全行程でみるとまだまだ道半ばではあるものの これらを対抗策のピースはすでにそろった感覚
45. あと歩く 道拓くは 険し道