プロダクションレディマイクロサービス

マイクロサービス

マイクロサービス vs モノシリックアプリケーションの対比
モノシリックアプリケーション

• デプロイのスケールの低さ、効率の悪さ、ベロシティの低さ、
• 最新技術の悪さ
  などがデメリットとして挙げられる

マイクロサービス

• 上記の問題はマイクロサービスを採用することで解決ができる
  システム、ビジネス、アジリティなどの観点を考慮し規模が大きくなれば自然と採用される

デメリットも存在する

• 安定性したインフラが必要
• マイクロサービスをサポートするために、組織構造の変更、それから生じるサイロ化
• 信頼性と可用性を保証するために、サービス自体のアーキテクチャの標準化 + マイクロサービスが満たさないといけない要件

とのこと

モノリス -> マイクロサービス

モノリスの特徴

web３層構造のコード管理の話

• front, backendのコードを１つのコードベースにまとめる(リポジトリも)
• front, backendコードを分割し管理
• 外部データベースを必要とせず、すべてのデータをメモリに格納するアプリケーションでは３つ(front, backend, db)の要素を１つのリポジトリで管理する

モノリスでは比較的にfront, backendといったコードがまとめられて管理されている.
開発規模が小さい場合はコードの保守管理、applicationの運用などは負担が少ない場合がある。

だがサービスが成長しコードの行数が膨れ上がるにつれ、メンテナンスは難しくなり、変更に対するテストの実行時間の遅延と増加、deploy後の障害などの問題を抱えるようになる

またops的側面の負担も増える

• サーバー自体の垂直、並行スケーリングの考慮
• メンテナンスに対する負荷
  などを表示る

開発とデプロイは悪夢になります。そして技術的負債は積み上がっていく。こういったライフサイクルになったアプリケーションはモノリスと呼ばれるようになる。

これはモノリスの性質。

スケーラビリティを得るためには並行性とパーティション分割が必要だが、モノリスはでこれらを実現するのは極めて困難。

このスケーラビリティの課題を解決するためにマイクロサービスが存在する

マイクソサービス

• １つのことだけを非常によくこなす小さなアプリケーションのこと。
• マイクロサービスは簡単に交換でき、独立に開発デプロイできる小さなコンポーネント
• マイクロサービスはマイクロサービス同士協調して動作する

このマイクロサービス同士の協調動作をマイクロサービスエコシステムという

マイクロサービスを導入メリット

• 技術負債が減る
• 開発者の生産性やベロシティ、テスト効率向上
• スケーラビリティが向上
• デプロイが容易性が得られる
  これらがメリット

ただ、マイクロサービスに移行するためには以下のステップを行わなければならない

• モノリスを適切な機能単位に分割する.( codeベースで)
  • 適切なコンポーネント単位で分割しないと小さなモノリスを産んで負債となる
• マイクロサービスの担当チームを設ける。それに伴う組織再編
  • チーム作成のアプローチとしては2点
    • 1つのマイクロサービスに専念させるチームを作る。機能開発とオンコールローテションの調和が必要でdeveloper, sreのアサインが必要(十分な)
    • 複数のサービスを担当させるパターン。チームはそれらのサービスを並列開発する。疲弊しないように注意が必要
• マイクロサービスエコシステムを安定稼働させるplatformチームが必要

ここまでやりきってマイクロサービスへ移行を開始することができる。

ここまで、最初からマイクロサービスでアプリケーションを作ればという疑問も生まれる
だただし、マイクロサービスを実行するにはそれを支える、インフラを持っていないし、それを管理できる人的コストも存在しない。なので成長した企業がスケーラビリティの問題に直面するほどに達した企業だけである。