気の向くままに書き綴る

勉強会参加したメモや日々の思ったことのメモ等

なぜMicroservicesが重要なのか(Why Microservices Matter)を読んだ

Heroku | Why Microservices Matterを読んだ。

 

Microservicesについては、以下が非常にわかりやすい!!

"Microservices"を読んだ | SOTA

 

Herokuは、

The Twelve-Factor App(日本語訳)SaaSの方法論を上げている。

上記2つを合わせて読むと面白い。

Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。

・セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。

・下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。

・モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。

・開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。

ツールアーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 

Twelve-Factorの方法論は、

どのようなプログラミング言語で書かれたアプリケーションにでも適用できる。
また、どのようなバックエンドサービス(データベース、メッセージキュー、メモリキャッシュなど)の組み合わせを使っていても適用できる。

 

以下は、読んだ時の簡単なメモ。

Why Microservices Matter

すべての成功したアプリケーションは、時間をかけて複雑さが増す。

Developerはその複雑性に立ち向かうために、2つの戦略がある。

  • そのままチームみんなでKeepする(monolith)
  • チームを複数に分けて小さなプロジェクトを進める(Microservices)
 

■ monolith

  • 最も極端なmonolithは、ひとつのコードベース
  • すべてのアプリケーションのロジックが入りチーム全員がコントリビューター

このアプローチがもっとも自然で大体このモデルに向かう傾向がある。

これは多くの点で簡単かつ、一つのコードベースは分散システムにかかるコストを減らすことができる。 

しかし時間が経つにつれて、

  • 大きくなるプロジェクトによるDeployするコストが大きくなる
  • 大きなチームは共同作業が困難になっていく 
 

■ Microservices

  • 管理ができるように大きなプロジェクトを分解する戦略
  • 分解したプロジェクトは、書かれるべきものを見やすくする習慣を作る

この戦略へ進むことはソフトウェアがよりスケールする可能性がある。

 既に大規模なIT業界(少なくともHerokuやNetflix、Amazon)では組織的な開発の中核を担っている。

しかし、Microservicesの開発をすることで、新たな課題が存在する。

Microservicesのコンセプト

ざっくり自分たちのアプリケーションを機能毎に因数分解していくことである。

これを達成するためには、

  1. ビジネス要件ごとに分割(例:アカウント管理、広告、インターフェース)
  2. 1を提供するプログラムを書き出す
  3. 各サービスをつなげる(HTTP、AMQP、Redisのような言語に依存しない形で)
  4. 最後に、他のサービスとデータを交換するためのプロトコルを介してメッセージを渡す

 

Microservicesのメリットとして、

  • 低レイテンシのために分散することができる
  • 冗長性を確保するために、同時に同じサービスの複数のバージョンを実行することができる
  • サービスはコードによって強要されず、ビジネス単位で組織的に動くことにできる。
  • 未来の技術やインターフェースに対して対処しやすい

しかし、Microservicesは銀の弾丸ではない。

個々のサービスを固ることで複雑さを取り除く一方、

全体的には、ネットワークレベルでの分散システムの多くの課題がある。

Microservicesの可能性と課題

monolithアプリは多くの責任を一つの巨大プログラムで包括している。

Microservicesはそれぞれ単一で責任をもってプログラムを小さく構成している。

 

Microservicesを用いることで

  • エンジニアチームがサービス毎に独立して動くことができる
  • そして小さいプログラムは理解しやすく、開発者が新しくJoinしてもすぐに貢献できる

また個々のアプリケーションは独立しているため、サービス全体に対して大きなコストをかけずに変換することができる

  • 新技術が利用可能かつ、特定のサービスに有効であれば、そのサービス限定で書き換えることができる
  •  言語にとらわれないプロトコルを利用するため、アプリケーションは異なる言語で実装ができる

 

もちろん、ソフトウェアがリリースされなければ意味が無い
小さなサービスの展開は、単一のコードベースよりもはるかに大きなオーバーヘッドが発生する。

  • いくつかのサービスはロードバランサのようなものをサポートする必要である
  • monolithでも行っているProcess監視等を一つひとつ行わなくてはならない
  • 独立して様々な作業をスケールさせる必要がある
  • 各サービスは処理が異なる組み合わせのためメモリやIOの設定と監視を異なる形式で入れるべきである
  • 各サービスのスケールタイプは、ユーザの需要に適応するべきである

柔軟性、レスポンス、処理効率、サポートの面で膨大な運用コストがかかる。 

信頼できる可用性をもつPaaSの存在

PaaSはあなたのソフトウェアを抽象化させてコンテナを提供する。

 さらにコンテナの外では、ロードバランサから独立したスケールとプロセスモニタリングを含め、すべてプラットフォーム上から提供される。

 

PaaSを利用することで、

  • Deployする専任者の資格はいらない
  • Deploy自体のコスト削減(git push)
  • デベロッパーはさらにはプロジェクトマネージャのようなジェネラリストように成長する

Heroku利用者の中では、誰もが運用にフルタイムを捧げていない。

しかし、すべての開発者は世界カ国でデプロイすることができる。

PaaSの出現により、Microservicesへの展開が目指しやすくなっている。

何を意味するのか?

時間をかけてプロジェクトを拡張する方法の一部として、Microservicesへの戦略を検討した方が良い。Microservicesのオーバーヘッドは、PaaSを利用することでオーバーヘッドを下げる。

 

しかし、複数のコードベースを実行するためには運用上の課題をクリアにすることが必要である。

 さらに、各コンポーネントで監視および警告などを設定する必要がある。

 

Microservicesは個々のコンポーネントのテストとリリースを簡単にするが、

システム統合レベルでのコストが発生する。

 

サービスのいずれかが停止した場合、

他のサービスはどのように振る舞うのか?そのための計画と対策が必要である。

また、あまりにも細かくコードをアップして分割することをスタートしてはいけない

各分割点は、APIチームが時間をかけてサポートする必要がある。

まずは彼らのAPIからモバイルとウェブを分離することを開始するのが非常に賢明な場所である。

 

全体的のアプリケーションを分解する戦略は、
より良い技術の選択を行うことができ、チームがより速度を与え、可用性を維持するために、より多くの方法を与えることができる。

 

Herokuの上でMicroservicesを活用する方法の詳細は以下のYouTubeがある

Production-ready Node Architecture - YouTube

Fred George - Microservice Challanges - YouTube