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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

目指すはPub/Sub マイクロサービスに向かって進むサービスAはデータをイベントでもつそのイベントをMessageBrokerに送出する MessageBrokerのメッセージを任意のタイミングで他サービスが利用する ↓ サービスBがサービスAに依存しない＝疎結合なシステム開発

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

失敗には学びが多い

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

準備の成果はあったのか？

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

課題は解決できたのか？

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

あと歩く道拓くは険し道