マイクロサービス: Kubernetes を使用している場合でも、サイズは重要です

19月XNUMX日、モスクワで 起こった マイクロサービスに特化した最初のテーマ別会議 HUG (Highload++ User Group)。 「Operating Microservices: Size Matters, Even If You Have Kubernetes」というプレゼンテーションがあり、マイクロサービス アーキテクチャを使用したプロジェクトの運用における Flant の豊富な経験を共有しました。 まず第一に、これは現在または将来のプロジェクトでこのアプローチの使用を検討しているすべての開発者にとって役立ちます。

導入 レポートのビデオ (50 分、記事よりもはるかに有益)、およびその主要な抜粋をテキスト形式で提供します。

注意: この投稿の最後にはビデオとプレゼンテーションもあります。

導入

通常、優れたストーリーには始まり、メインプロット、そして解決策があります。 このレポートは序章のようなものであり、その点では悲劇的です。 また、マイクロサービスについて外部からの視点が提供されることに注意することも重要です。 営業.

まずはこのグラフから始めます。このグラフの作成者は (2015 年に) だった マーティン・ファウラー:

これは、モノリシック アプリケーションが特定の値に達すると、生産性がどのように低下​​し始めるかを示しています。 マイクロサービスは、初期の生産性が低いという点で異なりますが、複雑さが増すにつれて効率の低下はそれほど目立ちません。

Kubernetes を使用する場合について、このグラフに追加します。

マイクロサービスを使用したアプリケーションが優れているのはなぜですか? なぜなら、そのようなアーキテクチャはアーキテクチャに重大な要件を提示し、その要件は Kubernetes の機能によって完全にカバーされるからです。 一方、特に今日の典型的なモノリスは正確にはモノリスではないため、この機能の一部はモノリスに役立ちます (詳細はレポートで後述します)。

ご覧のとおり、最終的なグラフ (モノリシック アプリケーションとマイクロサービス アプリケーションの両方が Kubernetes を使用したインフラストラクチャ内にある場合) は、元のグラフとあまり変わりません。 次にKubernetesを利用して動作するアプリケーションについて説明します。

有用なマイクロサービスと有害なマイクロサービス

そして主なアイデアは次のとおりです。

何ですか 通常の マイクロサービスアーキテクチャ? 作業効率が向上し、真のメリットがもたらされるはずです。 グラフに戻ると、次のようになります。

彼女に電話したら 有用、グラフの反対側には次のようになります。 危害を与える マイクロサービス (作業に干渉します):

「主な考え方」に戻ります。そもそも自分の経験を信じるべきでしょうか? 今年の初めから調べてみたら 85プロジェクト。 それらのすべてがマイクロサービスだったわけではありません (そのうちの約 5 分の 500 から半分がそのようなアーキテクチャを持っていました) が、これは依然として多数です。 私たち (Flant 社) はアウトソーサーとして、小規模企業 (開発者 XNUMX 名) と大企業 (開発者約 XNUMX 名) の両方で開発されたさまざまなアプリケーションを管理しています。 さらなる利点は、これらのアプリケーションが稼働し、長年にわたって進化しているのが見られることです。

なぜマイクロサービスなのか?

マイクロサービスの利点についての質問には次のようになります。 非常に具体的な答え すでに言及したマーティン・ファウラーから:

1. モジュール性の明確な境界。
2. 独立した展開。
3. テクノロジーを選択する自由。

私はソフトウェア アーキテクトや開発者と何度も話し、なぜマイクロサービスが必要なのかを尋ねてきました。 そして私は彼らの期待をリストにしました。 何が起こったかは次のとおりです。

いくつかのポイントを「感覚で」説明すると、次のようになります。

• モジュールの明確な境界: ここにはひどいモノリスがあり、すべてが Git リポジトリにきちんと配置され、すべてが「棚の上」にあり、温かいものと柔らかいものが混在しません。
• デプロイメントの独立性: サービスを独立してロールアウトできるため、開発が迅速化されます (新機能を並行して公開します)。
• 開発の独立性: このマイクロサービスを XNUMX つのチーム/開発者に提供し、そのマイクロサービスを別のチーム/開発者に提供できるため、より速く開発できます。
• бо信頼性の向上: 部分的な機能低下が発生した場合 (20 マイクロサービスのうち XNUMX つのマイクロサービスが低下した場合)、機能を停止するボタンは XNUMX つだけで、システム全体は機能し続けます。

典型的な (有害な) マイクロサービス アーキテクチャ

なぜ現実が私たちの期待と異なるのかを説明するために、次のように説明します。 集団的 さまざまなプロジェクトの経験に基づいたマイクロサービス アーキテクチャのイメージ。

例としては、Amazon や少なくとも OZON と競合する抽象的なオンライン ストアが挙げられます。 そのマイクロサービス アーキテクチャは次のようになります。

さまざまな理由により、これらのマイクロサービスは異なるプラットフォームで作成されます。

各マイクロサービスには自律性が必要であるため、多くのマイクロサービスには独自のデータベースとキャッシュが必要です。 最終的なアーキテクチャは次のとおりです。

その影響は何でしょうか?

ファウラーもこれ持ってる 記事があります — マイクロサービス利用時の「支払い」について：

そして私たちの期待が満たされたかどうかを見てみましょう。

モジュールの境界を明確に...

しかし 実際に修正する必要があるマイクロサービスはいくつあるのでしょうか?変更を展開するには? 分散トレーサーなしですべてがどのように機能するかを理解することさえできるでしょうか (結局のところ、すべてのリクエストはマイクロサービスの半分によって処理されます)。

パターンがあります」大きな土の塊”、そしてここでそれは分散された土の塊であることが判明しました。 これを確認するために、リクエストがどのように行われるかをおおよその図で示します。

展開の独立性...

技術的にはそれが達成されており、各マイクロサービスを個別に展開できます。 ただし、実際には、常にロールアウトされることを考慮する必要があります。 多くのマイクロサービス、そして考慮する必要があります 展開の順序。 良い意味で、リリースを正しい順序でロールアウトしているかどうかを別の回路でテストする必要があるのが一般的です。

テクノロジーを選択する自由...

彼女は。 自由はしばしば不法と隣り合わせであることを覚えておいてください。 ここで非常に重要なのは、単に「遊ぶ」ためだけにテクノロジーを選択しないことです。

開発の独立性...

(非常に多くのコンポーネントを含む) アプリケーション全体のテスト ループを作成するにはどうすればよいでしょうか? ただし、それでも最新の状態に保つ必要があります。 これらすべては、次のような事実につながります。 実際のテスト回路数原則的には含めることができますが、 最小限であることが判明.

これらすべてをローカルに展開するのはどうでしょうか? 多くの場合、開発者は、回路がテスト用に空くまで待たなければならないため、開発者が独立して作業を「ランダムに」実行していることがわかりました。

個別のスケーリング...

はい、ただし使用する DBMS の領域に制限があります。 指定されたアーキテクチャの例では、Cassandra には問題がありませんが、MySQL と PostgreSQL には問題が発生します。

Боより高い信頼性...

実際には、XNUMX つのマイクロサービスに障害が発生すると、システム全体の正常な機能が損なわれることが多いだけでなく、次のような新たな問題も発生します。 すべてのマイクロサービスをフォールトトレラントにするのは非常に困難です。 マイクロサービスは異なるテクノロジー (memcache、Redis など) を使用するため、それぞれについてすべてを検討して実装する必要があります。これはもちろん可能ですが、膨大なリソースが必要です。

負荷測定可能性...

これは本当に良いですね。

マイクロサービスの「軽さ」…

私たちは巨大なだけではなく、 ネットワークのオーバーヘッド (DNS へのリクエストが増加しているなど) だけでなく、多くのサブクエリを開始したことも原因です。 データを複製する (ストア キャッシュ)、大量のストレージが必要になりました。

そして、これが私たちの期待に応えた結果です:

しかし、それだけではありません！

なぜなら：

• おそらくメッセージバスが必要になるでしょう。
• 適切なタイミングで一貫性のあるバックアップを作成するにはどうすればよいでしょうか? 唯一の人 реальный このためのトラフィックをオフにするオプションもあります。 しかし、本番環境でこれを行うにはどうすればよいでしょうか?
• 複数の地域のサポートについて話している場合、それぞれの地域で持続可能性を組織することは非常に労働集約的な作業です。
• 集中的な変更を行う際に問題が発生します。 たとえば、PHP バージョンを更新する必要がある場合、各リポジトリ (リポジトリは数十あります) にコミットする必要があります。
• 運用の複雑さは、率直に言って指数関数的に増大しています。

これをどうすればいいでしょうか？

モノリシック アプリケーションから始める。 ファウラーの経験 彼は話します 成功したほとんどすべてのマイクロサービス アプリケーションはモノリスとして始まり、大きくなりすぎて壊れたということです。 同時に、最初からマイクロサービスとして構築されたほぼすべてのシステムは、遅かれ早かれ深刻な問題に遭遇しました。

もう XNUMX つの重要な考え方は、マイクロサービス アーキテクチャを使用したプロジェクトを成功させるには、次のことをよく理解しておく必要があるということです。 対象領域とマイクロサービスの作り方。 そして、対象分野を学ぶための最良の方法は、一枚岩を作ることです。

しかし、すでにこの状況に陥っている場合はどうなるでしょうか?

問題を解決するための最初のステップは、それに同意し、それが問題であり、これ以上苦しみたくないことを理解することです。

成長しすぎたモノリスの場合 (追加のリソースを購入する機会がなくなったとき)、それを切断すると、この場合は逆のことがわかります。つまり、過剰なマイクロサービスが役に立たなくなり、妨げになる場合です。 余分な部分を切り取って拡大する!

たとえば、上で説明した集合画像の場合...

最も疑わしいマイクロサービスを削除します。

フロントエンド生成を担当するすべてのマイクロサービスを結合します。

... XNUMX つの (あなた自身が考えているように、現代的で通常の) 言語/フレームワークで書かれた XNUMX つのマイクロサービス:

これには XNUMX つの ORM (XNUMX つの DBMS) と最初のいくつかのアプリケーションが含まれます。

...しかし、一般的には、より多くのデータを転送でき、次の結果が得られます。

さらに、Kubernetes ではこれらすべてを個別のインスタンスで実行します。つまり、負荷を測定し、個別にスケールすることができます。

要約する

もっと大きな絵を見てください。 マイクロサービスに関するこれらすべての問題は、誰かが自分のタスクを引き受けたが、「マイクロサービスをいじりたい」という理由で発生することがよくあります。

「マイクロサービス」という言葉の「マイクロ」の部分は冗長です。。 それらが「マイクロ」であるのは、巨大な一枚岩よりも小さいという理由だけです。 しかし、それらを小さなことだと考えないでください。

最後に、元のグラフに戻って考えてみましょう。

そこに書かれたメモ （右上） 要するに、 プロジェクトを作成するチームのスキルが常に重要です — これらは、マイクロサービスとモノリスのどちらを選択するかにおいて重要な役割を果たします。 チームに十分なスキルがないのにマイクロサービスを作り始めると、間違いなく致命的なストーリーになります。

ビデオとスライド

スピーチのビデオ (約 50 分。残念ながら、レポートの雰囲気を大きく決定する訪問者のさまざまな感情は伝わりませんが、それはそのようなものです):

報告書のプレゼンテーション:

PS

私たちのブログの他のレポート:

• «モニタリングとKubernetes» (ドミトリー・ストリャロフ、28 年 2018 月 XNUMX 日、RootConf にて);
• «Kubernetes と GitLab を使用した CI/CD のベスト プラクティス» (Dmitry Stolyarov、7 年 2017 月 XNUMX 日 HighLoad++);
• «小規模プロジェクトにおける Kubernetes の経験» (ドミトリー・ストリャロフ、6 年 2017 月 XNUMX 日、RootConf にて);
• «dapp を使用して CI/CD 用の Docker イメージを迅速かつ便利に構築します» (Dmitry Stolyarov、8 年 2016 月 XNUMX 日 HighLoad++);
• «Docker を使用した継続的デリバリーの実践» (ドミトリー・ストリャロフ、31 年 2016 月 XNUMX 日、RootConf にて).

次の出版物にも興味があるかもしれません。

• «2018 年、マイクロサービスの狂気は終焉";
• «Google によるコンテナ使用に関する 7 つのベスト プラクティス";
• «Kubernetes 実装の課題に関する The New Stack の統計'。

出所： habr.com