Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

nrs
December 05, 2023

アーキテクチャ刷新の現場 / 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

nrs

December 05, 2023
Tweet

More Decks by nrs

Other Decks in Programming

Transcript

  1. アーキテクチャ刷新の現場

    View full-size slide

  2. ことのあらまし
    課題予測と事前準備
    失敗と成果
    まとめ
    アーキテクチャ刷新の現場

    View full-size slide

  3. ことのあらまし
    課題予測と事前準備
    失敗と成果
    まとめ
    アーキテクチャ刷新の現場

    View full-size slide

  4. 成長し続けなくてはならない

    View full-size slide

  5. システムの成長を阻害する要因
    ・仕様の複雑化
    ・過渡期特有の難解なコード
    ・技術スタックの相対的な老朽化
    システムが成長し続けるために必要なこと

    View full-size slide

  6. 仕様の複雑化
    ・サービスの成長に伴う機能追加
    「こんな機能あるんだ……」
    ・メンバーの入れ替え
    「あ、そこは〇〇さんが詳しいよ。え?退職した?そう……」
    ・ドキュメントの不確実性
    メンテナンスを欠かしていない者だけが石を投げなさい
    システムが成長し続けるために必要なこと

    View full-size slide

  7. 過渡期特有の複雑なコード
    ・コードは別のプロジェクトに侵食する
    うまくいったサービスのコードはその巧拙を抜きに”参考”される
    ・チャレンジコード
    誰しも初めてはあるよね+忙しい、が合わさると
    レビューをすり抜けて理解に苦しむコードが生まれる
    ・動いているのが正義なのでつぎ足します
    リファクタリングの選択肢がないためにダラダラと
    システムが成長し続けるために必要なこと

    View full-size slide

  8. 技術スタックの相対的な老朽化
    ・MVCナニソレ
    ASP.NET MVC 1.0 が2009年3月、Strutsは2001年
    ・VB
    ただ、結局.NETだからモダンだと思う
    ・パッケージマネージャ? ないよ
    ちなみにnpmが2010年らしい
    システムが成長し続けるために必要なこと

    View full-size slide

  9. 成長しやすいシステムを目指す
    ・巨大なシステムを小さなシステムに
    理解の範囲を狭める
    ・密結合なシステムを疎結合なシステムに
    依存関係を整理して、互いを疎に
    ・無意味なコードの多様性を排除
    システム間連携と基本コードの指針を準備
    健全な成長は健やかなシステムから

    View full-size slide

  10. チームの機敏性を確保する

    View full-size slide

  11. ことのあらまし
    課題予測と事前準備
    失敗と成果
    まとめ
    アーキテクチャ刷新の現場

    View full-size slide

  12. コンウェイの法則と逆コンウェイ戦略
    コンウェイの法則
    システムを設計する組織は
    自らのコミュニケーション構造を
    まねた設計を
    生み出すように制約される。
    基本戦略
    逆コンウェイ戦略
    チームと組織構造を進化させて
    望ましいアーキテクチャへ
    促進する

    View full-size slide

  13. まずはマイクロサービスの情報収集
    ・サービスのサイズが小さい
    →理解の範囲が狭くて済む
    ・サービスは互いに疎である
    →サービスは独立して成長できる
    望ましいアーキテクチャは何か
    どうやらこの方向に進んだらよさそうだ

    View full-size slide

  14. マイクロサービス実践にあたって学習
    特に役に立ったのはこの2冊
    ・マイクロサービスパターン
    実装面で困難となる個所を知る
    CQRS+ESによるPub/Subがゴールである予測をする
    ・モノリスからマイクロサービスへ
    現状をマイクロサービス化していくうち
    最も困難となる移行のテクニックを習得
    マイクロサービスに向かって進む

    View full-size slide

  15. 目指すはPub/Sub
    マイクロサービスに向かって進む
    サービスAはデータをイベントでもつ
    そのイベントをMessageBrokerに送出する
    MessageBrokerのメッセージを
    任意のタイミングで他サービスが利用する

    サービスBがサービスAに依存しない
    =疎結合なシステム開発

    View full-size slide

  16. 自前実装によるPoC
    ・フレームワークに依存できない
    一般的なMVCなどと比べて
    マイクロサービスに関しては先駆者がいないため
    自らが先駆者となる必要がある
    そのため誰よりも知っておく必要がある
    ↓ということでCQRS+ESを理解するために自分で実装した(JDBC,CosmosDB, DynamoDB)
    https://github.com/nrslib/microservice-with-event-sourcing-sample-kotlin
    マイクロサービスに向かって進む

    View full-size slide

  17. フレームワーク選定
    ・CQRS+ESを実現するために比較検討
    Akka: Scalaとアクターモデルがネック
    Axon Framework: 情報少ない
    Eventuate Tram: EventSourcingを意識してコードを書く必要がある
    Spring Boot + Spring Cloud: EventSourcingするのはまぁまぁ骨が折れそう
    マイクロサービスに向かって進む

    View full-size slide

  18. フレームワーク選定
    ・CQRS+ESを実現するために比較検討
    Akka: Scalaとアクターモデルがネック
    Axon Framework: 情報少ない
    Eventuate Tram: EventSourcingを意識してコードを書く必要がある
    Spring Boot + Spring Cloud: EventSourcingするのはまぁまぁ骨が折れそう
    マイクロサービスに向かって進む
    ☆当初

    View full-size slide

  19. フレームワーク選定
    ・CQRS+ESを実現するために比較検討
    Akka: Scalaとアクターモデルがネック
    Axon Framework: 情報少ない
    Eventuate Tram: EventSourcingを意識してコードを書く必要がある
    Spring Boot + Spring Cloud: EventSourcingするのはまぁまぁ骨が折れそう
    マイクロサービスに向かって進む
    ☆現在

    View full-size slide

  20. ライブラリ作成
    メッセージブローカーにイベントを送出する必要がある
    →ストリーム処理のためAmazon Kinesisを利用する
    →そのためのライブラリが必要なので開発
    (Kinesis Connector Libraryベース)
    マイクロサービスに向かって進む

    View full-size slide

  21. 先行開発事例
    道を切り拓かないと誰もついてこない
    →事例を作るのがとにかく先決
    →ひとつのサービスをまずは打ち出すため、メンバーと一緒に作り始める
    →まずはコンセプトの説明から
    実現に必要なものを揃える

    View full-size slide

  22. 必要なのはフレームワークだけじゃない
    メンバーはこれまでにないアーキテクチャを習得しなくてはならない
    →現業をおろそかにはできない
    →新規技術をキャッチアップするには何かしらの施策が必要
    実現に必要なものを揃える

    View full-size slide

  23. 組織・メンバーの成長を支援する方法
    参考になった本はチームトポロジー
    特にイネイブリングチームの考え方が
    今回のスキル習得支援にもっとも適合
    実現に必要なものを揃える

    View full-size slide

  24. イネイブリングチーム結成
    当初は自分に加えてもう1名(Aさん)の計2名からスタート
    先ほどのサービス開発を担当するメンバーの支援をする
    とはいえ最初はAさんもはじめて触るアーキテクチャなので
    将来を見越して学習するフェーズ
    実現に必要なものを揃える

    View full-size slide

  25. 俗人化を避けるにはドキュメントしかない
    ドキュメントがメンテナンスされない理由は明白
    →実装者に実利が少ないから
    →開発のフローにドキュメントのメンテナンスを
    組み込んだほうが得と思えるような手法が必要
    仕様の複雑化への対応策

    View full-size slide

  26. イベントストーミング
    仕様の複雑化への対応策

    View full-size slide

  27. 図とコードが一致する
    仕様の複雑化への対応策
    イベントストーミング図の付箋はそのままクラスになる
    →図を描くことがコードのヒントになる
    コードの変更がどこに影響するかわかる
    →意図せぬ変更の防止により安全性を向上
    後発のメンバーも図を見て把握できる
    →キャッチアップが容易になるとメンバーのスケーリングも可能

    View full-size slide

  28. 初めてのことが多いため困難が予測される
    説得力を得るために
    技術支援を入れてもよいとのお達しを受ける
    とはいえ、この規模で、かつこういった形のマイクロサービスを
    やっている組織は本当に少ない
    自分のツテで信頼できる人に技術支援として参画してもらった
    壁打ち相手として非常に助かった

    View full-size slide

  29. ことのあらまし
    課題予測と事前準備
    失敗と成果
    まとめ
    アーキテクチャ刷新の現場

    View full-size slide

  30. 失敗には学びが多い

    View full-size slide

  31. フレームワーク選定ミス
    Akka有料化に完全に巻き込まれる
    開発の最中であったので様子見ができず即決断を求められる
    プランBであったAxon Frameworkにフレームワークを変更
    結果的にこれはハレーションが減少させたので功を奏したといえる
    失敗を見ていこう

    View full-size slide

  32. フレームワーク変更の余波
    せっかく作ったKinesis用ライブラリは使えません
    メッセージブローカーどうしましょう?
    Axon Frameworkとの相性も考慮してKafkaに舵取りし直し
    Topic? SASL+SCRAM? ナニソレ? から土日で一気にキャッチアップ
    失敗を見ていこう

    View full-size slide

  33. 複数プロジェクト同時並行
    当初より無理があると感じていたが
    複数チームで同時にマイクロサービス化を推進しはじめた
    事例もない中多くのメンバーが同じ方向に進むのはやはり難しい
    そもそも自分しかいない状況で全チームサポートは不可能に近い
    失敗を見ていこう

    View full-size slide

  34. 逆コンウェイ戦略をもくろんだチーム改変
    逆コンウェイ戦略を狙ったようなチーム改変があった
    残念ながら逆コンウェイ戦略はあくまで戦略でしかなかった
    アーキテクチャの変更をする「余力」と「実行力」がない場合は
    現状のアーキテクチャに沿ったコミュニケーションが継続される
    失敗を見ていこう

    View full-size slide

  35. 先行事例を人任せにした
    サービスの担当者にコードを書いてもらい始めた
    →間接的なコーディングが非常に難しく進捗が出づらくなってしまった
    いったん引き取って、先行事例は自分が作ることに
    失敗を見ていこう

    View full-size slide

  36. 成果を出すまでの期間について意思疎通がうまくいっていなかった
    あと歩く 道拓くは 険し道
    PoCや調査含めて1年程度では花開かず、年度末ごろ方針変更を下された
    自分が手掛けていた先行事例まであとわずかであったため
    1サービスのアーキテクチャシフトの継続を死守
    失敗を見ていこう

    View full-size slide

  37. 準備の成果はあったのか?

    View full-size slide

  38. イネイブリングチームの活躍
    最初のイネイブリングチームとして発足したチームは現在9名
    うち技術支援をメインとしているメンバーは4名
    現在7チームを同時支援
    準備の成果

    View full-size slide

  39. マイクロサービス
    目論見通りのアーキテクチャのシステムの完成
    Spring+Axon Frameworkはハレーションが少ない
    (コードの見た目はほぼSpring)
    どの粒度でコードを区切り、どうやってAPIをコールして、
    それを自サービスに紐づけて、といったコードが
    基本的に同じ書き方になった
    準備の成果

    View full-size slide

  40. イベントストーミング
    本格的なマイクロサービスになると
    イベントストーミング図なしでは理解が困難になる
    まずは図を作り、それを見ながらコードを書くという習慣を
    自然とメンバーが習得しているのを観測できた
    準備の成果

    View full-size slide

  41. Pub/Subの実現
    メッセージブローカーをKafkaにしたことで
    イベントデータを無制限に保存する選択肢が増えた
    ジャーナルDBからデータを読み取らなくても
    リードモデルのデータ読み取りで
    Kafkaを参照するだけで済む
    (CPUや通信料の節約)
    準備の成果

    View full-size slide

  42. ことのあらまし
    課題予測と事前準備
    失敗と成果
    まとめ
    アーキテクチャ刷新の現場

    View full-size slide

  43. 課題は解決できたのか?

    View full-size slide

  44. システムの成長を阻害する要因
    ・仕様の複雑化
    ・過渡期特有の難解なコード
    ・技術スタックの相対的な老朽化
    システムが成長し続けるために必要なこと
    全行程でみるとまだまだ道半ばではあるものの
    これらを対抗策のピースはすでにそろった感覚

    View full-size slide

  45. あと歩く 道拓くは 険し道

    View full-size slide