💨

アジャイル開発及びマイクロサービスアーキテクチャの採用について

2022/06/06に公開約2,300字

はじめに

  • アジャイル開発及びマイクロサービスアーキテクチャの採用についての個人的な所感を書く。ここに記載する内容は個人的な見解であり、正しくない面も多くあると思うが、プロジェクトを開始するにあたり、ここの判断が成功・失敗に直結する重要な点であると考えている。
  • 特に、大規模システムを更改する等のプロジェクトは数年に渡り、企業のコストに直結する。また、プロジェクトの青写真を描ける人は本当に少ない。業務観点で既存の運用フローからの変更がどのようなものになるか、どのような影響がでるか。また、システム観点でも運用が数年先も耐えうるものであるか検討しなければならない。
  • アジャイル開発は採用してチャレンジすべき、マイクロサービス化の採用は慎重に考えるべきというスタンスを私は取っている。
  • アジャイル開発を採用する、故にマイクロサービス化も採用という流れはリスクなので、しっかり検討した上で、プロジェクト参加者の同意を取った上で、採用すべきである。

https://zenn.dev/hiroharu8864/articles/eb16849cc3dfab
  • 「マイクロサービスアーキテクチャー化をどうやって進めるか」は、上記記事で検討したが、そもそもアーキテクチャ採用に至る経緯がどのようになっているのか確認したいと考えた。

個人的所感

  • アジャイル開発を取り入れる優位点は、スプリントの粒度を決めて、プロトタイプを作成し、エンドユーザと適宜共有することで認識のズレがないよう開発を進めていくことであり、ここが一番の重要な点であると考えている。(適度なスパンでプロトタイプを提供できれば、アジャイル開発である必要すらないと考えている)
  • 細かいスプリントを回しながら開発するアジャイル開発がマイクロサービスアーキテクチャと相性が良いだけであって、目的や目標の達成手段としてマイクロサービスが最適解ではない場合が多いのではないか。また、そのマイクロサービス化を実施する前提での判断ありきで進めるべきではない。
  • 既存システムをマイクロサービスアーキテクチャへ刷新するということは、既存システムのデータ要素が混在している状況を正しく機能別に整理して、再配置することが第一となる。さらに、細かい粒度で疎結合が可能であれば、マイクロサービス化することを検討する。マイクロサービス化はマストではなく、機能別にシステムを再配置することがより重要である。
  • 機能別にシステムを配置し、そのシステム単位(機能別、サービス別)で組織を形成し、運用オペレーションを回しやすくできる。これは既存システムでも、ある程度完成している。
  • 正しく機能別に再配置するためには、既存システムの機能を正しく分析する必要がある。ここでシステムが大規模であればあるほど分析に時間がかかるし、すべて分析できないかも知れない。
    • システムの仕様書関連が正しく運用されて、細かい修正もすべて仕様書に反映されている。
    • 分断するマイクロサービスの粒度を決める。既存システムも大枠では機能・サービス別に作成されているものであるから、そこから先のマイクロ化をどうするか決める。
    • さらなるマイクロ化を進めたら、システム間連携IFが膨大に増加する。増加したIFすべてでシナリオテストを作成し、エラー時の運用を定義する必要がある。
    • 対象システムのクラウド化から着手するが、モノリスがオンプレ環境であった場合、システム間連携IFがクラウド〜データセンターとなり、セキュリティやトラフィック課金など追加検討事項が増加する。
    • このアラート拾ったら、このチームに連絡という運用にまで落とせるのか?
  • システム観点で言っても、分割を進めて多段になったシステムは稼働率が低下するし、システムが単純に増加するので、障害率も増加する。サーキットブレーカーなど、障害時におけるエンドユーザの待ち時間低下の仕組みは存在するが、エラーはエラーなので、対処にはならない。それであれば、粒度を大きくしたモノリス(サービス別システムでJAR, WARでサーバへデプロイ)をシステム冗長化するほうが、稼働率・保守の面でも優れているのではないか。
  • 業務観点では、オペレーションに関するFIT&GAPもシステム同様に時間をかけて実施すべき。業務のすべてが自動化されているオペレーションはなく、イレギュラーな対応はシステム化に至らず、手作業など至るところに残っていると考えられる。
  • システムだけ先鋭化しても、それを運用するオペレーションはナレッジ・スキル含めて変更に時間がかかる。とくにオペレーション変更は運用ミスに繋がるため、なるべく既存に影響が出ないよう変更を少なく設計する必要がある。(業務チームは保守的であり、それが良い面であったりする)

まとめ

  • これらの事項を加味したシステム全体像をある程度共有化し、プロジェクトメンバー間で認識齟齬がない状態で、マイクロサービス化すべきだという総意をどうやって取得するかが、まだ理解出来ていない。
  • モノリシックな仕組みから、マイクロサービスへ変革することが、良質なサービスを生み出すことに繋がることになるのか、正直言ってわからない。ただ、数年先の青写真がないまま、マイクロサービス化ありきでシステム更改を進めるのはリスクであるから、今後多くの事例を分析していくことが必要である。成功事例だけではなく、主に失敗事例から。ただし、失敗事例は世になかなか出て来ない。

Discussion

ログインするとコメントできます