第2回 Software Architecture: The Hard Parts 読書会@リモート

第2回 Software Architecture: The Hard Parts 読書会 - connpass


参加者トピック

ディスカッション

+ch03: Architectural Modularity

  • 今日の世界で生き残るためには、ビジネスはアジャイルでなければなりません
  • しかし、ビジネス・ステークホルダーが迅速な意思決定と方向転換を行うことができても、企業のテクノロジー・スタッフがその新しい指示を変化をもたらすほど迅速に実行できない場合があります
  • テクノロジーがビジネスと同じ速さで動けるようにするには(逆に言えば、テクノロジーがビジネスを遅らせないようにするには)、アーキテクチャーにある程度のアジリティが必要です

  • 大規模な技術スタックを移行した思い出

    • その時は、社長を巻き込む一大イベントにした
    • ApplemacOS Lepard から Snow Lepard へ移行した話を参考にしていた
      • 機能追加より基盤の移行を優先した話

+Modularity Drivers

モジュール化を促進する動機。

  • 競争優位性という目的を実現する要因は、可用性、スケーラビリティ、市場投入時間
  • 市場投入時期を達成するというのは、アジリティを高めること
  • アジリティを高めるには、デプロイ容易性、テスト容易性、保守容易性を高めるとよい

  • Completitive advantage

    • Availability
    • Scalability
    • Speed to market
      • Agility
        • Deployability
        • Testablity
        • Maintenability

+Maintainability

+Testability

  • 「サービス間の通信が増加すると、テスタビリティは急速に低下します。」

    • それでも安心感はあるのでやってしまうかなと
    • 実際に通信せず、契約ベースのテストでOKにする、という判断はあるかもしれない
  • ランタイムに閉じた範囲でテスタビリティを高めるのはいい話

    • ランタイム境界を越えるようだと新たな課題が出てきてしまう感じ
  • 小さく分解すれば並列に作業を進められる、という話もある

  • GraphQL

    • クエリする側、ロードする側のテストは容易になるとして
    • 複雑なクエリのテストを効率的にする方法は無いだろうか
  • API ベースのエコシステムが流行った時代があった

    • プロセス内APIを単純にWeb APIにしたら性能が圧倒的に劣化したため、元に戻した話がある

Testing Strategies in a Microservice Architecture を思い出した。

+Deployability

  • 2週間でも遅いと感じている

  • 「もしマイクロサービスを特定の順序で完全なセットとしてデプロイしなければならないのであれば、モノリスに戻して苦痛を省いてください。」

    • 結構ある

+Scalability

  • マイクロサービスの設計、分割に失敗すると、非機能要求を実現できなくなりがち

    • サービスの単位がドメインとしてはいびつになることがある
  • モノリシックアプリケーションのスケーラビリティはデータベースがボトルネックになっていたという理解

    • マイクロサービスアーキテクチャにすることで、スケーラビリティを扱いやすくなったのかな
    • Spanner 使ってるけど無限にスケールできるわけじゃない感じ
      • Aurora だとどうなんだろう
  • バーストトラフィックに対応できる弾力性が実現できたとして、下流のサービスや後続のデータ処理パイプラインとかまで考慮できるかな

  • サービスが成長するとログはどんどん増えていくので、一括処理するところが大変になる

+Availability/Fault Tolerance

  • 「決済処理が利用できなくなっても、システムのユーザーは商品の検索や注文を行うことができなければなりません。」
    • そんな状態あり得る?
    • 注文サービスが決済サービスを同期的に呼ぶ構造になっているなら、ちゃんと制御できることになる

+Sysops Squad Saga: Creating a Business Case

そうはならんやろう、という結論だった。

参考情報