こんにちは！ 私の名前は Vadim Madison です。Avito システム プラットフォームの開発を指揮しています。 社内でモノリシック アーキテクチャからマイクロサービス アーキテクチャに移行していることは、何度も言われてきました。 マイクロサービスを最大限に活用し、マイクロサービスに埋もれないようにインフラストラクチャをどのように変革したかを共有するときが来ました。 ここで PaaS がどのように役立つか、デプロイメントを簡素化し、マイクロサービスの作成を XNUMX 回のクリックに短縮した方法についてお読みください。 私が以下に書くすべてが Avito に完全に実装されているわけではありません。その一部はプラットフォームの開発方法に影響します。

(この記事の最後では、マイクロサービス アーキテクチャの専門家 Chris Richardson による XNUMX 日間のセミナーに参加する機会について説明します)。

マイクロサービスに至った経緯

Avito は世界最大の機密情報サイトの 15 つで、20 日あたり XNUMX 万以上の新しい広告が掲載されています。 当社のバックエンドは XNUMX 秒あたり XNUMX 件を超えるリクエストを受け入れます。 現在、数百のマイクロサービスがあります。

私たちはここ数年、マイクロサービス アーキテクチャを構築してきました。 正確には - 私たちの同僚の詳細 言った RIT++ 2017 の私たちのセクションで。CodeFest 2017 で (参照。 ビデオ) では、Sergey Orlov と Mikhail Prokopchuk が、マイクロサービスへの移行が必要な理由と、ここで Kubernetes が果たす役割について詳しく説明しました。 さて、私たちは現在、そのようなアーキテクチャに固有のスケーリングコストを最小限に抑えるためにあらゆることを行っています。

当初、私たちはマイクロサービスの開発と立ち上げを包括的に支援するエコシステムを作成していませんでした。 彼らは単に賢明なオープンソース ソリューションを収集し、それらを自宅で起動し、開発者にそれらに対処するよう招待しただけです。 その結果、彼は XNUMX か所 (ダッシュボード、内部サービス) を訪問し、その後、一枚岩で古い方法でコードをカットしたいという欲求が強くなりました。 以下の図の緑色は開発者が何らかの方法で自分の手で行うことを示し、黄色は自動化を示します。

PaaS CLI ユーティリティでは、XNUMX つのコマンドで新しいサービスが作成され、さらに XNUMX つのコマンドで新しいデータベースが追加され、Stage にデプロイされます。

「マイクロサービス断片化」の時代をどう乗り越えるのか

モノリシック アーキテクチャでは、製品の変更の一貫性を保つために、開発者は近隣のアーキテクチャで何が起こっているのかを把握する必要がありました。 新しいアーキテクチャで作業する場合、サービス コンテキストは相互に依存しなくなります。

さらに、マイクロサービス アーキテクチャを効果的にするには、次のような多くのプロセスを確立する必要があります。

• ロギング。
• トレースのリクエスト (Jaeger)。
• エラー集計 (セントリー)。
• Kubernetes からのステータス、メッセージ、イベント (イベント ストリーム処理)。
• レース制限/サーキットブレーカー (Hystrix を使用できます)。
• サービス接続の制御 (Netramesh を使用)。
• モニタリング (Grafana)。
• 組み立て（チームシティ）。
• コミュニケーションと通知 (Slack、電子メール)。
• タスクの追跡。 (ジラ)
• 文書の準備。

システムが規模を拡大しても整合性を失わず、効果を維持できるようにするために、私たちは Avito のマイクロサービスの構成を再考しました。

マイクロサービスの管理方法

以下は、多くの Avito マイクロサービス間で統一された「パーティ ポリシー」を実装するのに役立ちます。

• インフラストラクチャを層に分割する。
• サービスとしてのプラットフォーム (PaaS) の概念。
• マイクロサービスで起こるすべてを監視します。

インフラストラクチャ抽象化レイヤーには XNUMX つのレイヤーが含まれます。 上から下へ行きましょう。

A. 上部 - サービス メッシュ。 最初は Istio を試しましたが、使用するリソースが多すぎて、ボリュームに対してコストが高すぎることがわかりました。 そこで、アーキテクチャ チームのシニア エンジニア、Alexander Lukyanchenko は独自のソリューションを開発しました。 ネットラメッシュ (オープンソースで入手可能)。現在運用環境で使用しており、Istio よりも消費するリソースが数倍少ないです (ただし、Istio が誇るすべての機能を備えているわけではありません)。
B. 中 - Kubernetes。 その上にマイクロサービスをデプロイして運用します。
C. 底部 - 地金。 私たちはクラウドや OpenStack などを使用せず、完全にベアメタルに依存しています。

すべてのレイヤーは PaaS によって結合されます。 そして、このプラットフォームは XNUMX つの部分で構成されています。

I. 発電機、CLI ユーティリティ経由で制御されます。 開発者が正しい方法で最小限の労力でマイクロサービスを作成できるよう支援するのは彼女です。

II. 統合コレクター 共通のダッシュボードを通じてすべてのツールを制御できます。

Ⅲ． ストレージ。 重要なアクションのトリガーを自動的に設定するスケジューラーと接続します。 このようなシステムのおかげで、誰かが Jira でタスクを設定し忘れたからといって、タスクが XNUMX つも見逃されることはありません。 これには Atlas という内部ツールを使用します。

Avito でのマイクロサービスの実装も単一のスキームに従って実行されるため、開発およびリリースの各段階でのマイクロサービスの制御が簡素化されます。

標準のマイクロサービス開発パイプラインはどのように機能しますか?

一般に、マイクロサービス作成チェーンは次のようになります。

CLI プッシュ → 継続的インテグレーション → ベイク → デプロイ → 人工テスト → カナリア テスト → スクイーズ テスト → 本番 → メンテナンス。

正確にこの順序で見てみましょう。

CLIプッシュ

• マイクロサービスの作成.
私たちはすべての開発者にマイクロサービスの使い方を教えるために長い間苦労しました。 これには、Confluence で詳細な手順を記述することが含まれます。 しかし、計画は変更され、追加されました。 その結果、移行の開始時にボトルネックが発生しました。マイクロサービスの起動にはさらに時間がかかり、それでも作成中に問題が頻繁に発生しました。

最終的に、マイクロサービスを作成する際の基本的な手順を自動化するシンプルな CLI ユーティリティを構築しました。 実際、これは最初の git Push を置き換えます。 彼女が具体的に何をしているかは次のとおりです。

— 「ウィザード」モードで、テンプレートに従ってサービスを段階的に作成します。 Avito バックエンドには、PHP、Golang、Python などの主要なプログラミング言語のテンプレートがあります。

- 一度に XNUMX つのコマンドで、特定のマシンにローカル開発用の環境をデプロイします。 - Minikube が起動され、Helm チャートが自動的に生成され、ローカル kubernetes で起動されます。

— 必要なデータベースに接続します。 開発者は、ローカル、ステージ、運用環境を問わず、必要なデータベースにアクセスするために IP、ログイン、パスワードを知る必要はありません。 さらに、データベースはフォールト トレラント構成でバランシングを使用して即座にデプロイされます。

— ライブアセンブリ自体を実行します。 開発者が IDE を通じてマイクロサービス内の何かを修正したとします。 ユーティリティはファイル システム内の変更を確認し、それに基づいてアプリケーション (Golang 用) を再構築し、再起動します。 PHP の場合、キューブ内のディレクトリを転送するだけで、そこでライブリロードが「自動的に」取得されます。

— 自動テストを生成します。 ブランクの形ですが、使用には非常に適しています。

• マイクロサービスの導入.

私たちにとって、マイクロサービスのデプロイは少し面倒な作業でした。 次のものが必要でした。

I. Dockerfile。

II. 構成。
Ⅲ． Helm チャートはそれ自体が煩雑であり、次のものが含まれます。

— チャート自体。
— テンプレート;
— さまざまな環境を考慮した具体的な値。

Kubernetes マニフェストを再加工する手間が省け、マニフェストが自動的に生成されるようになりました。 しかし最も重要なのは、導入が極限まで簡素化されたことです。 今後は Dockerfile が作成され、開発者は XNUMX つの短い app.toml ファイルに構成全体を書き込みます。

はい、app.toml 自体では、しばらくの間何もすることがありません。 サービスのコピーをどこに、そしていくつ生成するかを指定し (開発サーバー上、ステージング上、本番環境上)、その依存関係を示します。 [engine] ブロックの line size = "small" に注目してください。 これは、Kubernetes 経由でサービスに割り当てられる制限です。

次に、構成に基づいて、必要なすべての Helm チャートが自動的に生成され、データベースへの接続が作成されます。

• 基本的な検証。 このようなチェックも自動化されています。
追跡する必要があります:
— Dockerfile はありますか。
— app.toml はありますか。
— 入手可能なドキュメントはありますか?
— 依存関係は大丈夫ですか？
— アラート ルールが設定されているかどうか。
最後に、どの製品メトリクスを監視するかをサービスの所有者自身が決定します。

• 文書の準備。
まだ問題のある分野です。 これは最も明白であるように思えますが、同時に「忘れられがちな」記録でもあり、したがって連鎖の中で脆弱な部分となります。
各マイクロサービスのドキュメントが必要です。 これには次のブロックが含まれます。

I. サービスの簡単な説明。 文字通り、それが何をするのか、そしてなぜそれが必要なのかについてのいくつかの文です。

II. アーキテクチャ図のリンク。 たとえば、キャッシュに Redis を使用しているのか、永続モードのメイン データ ストアとして Redis を使用しているのかを、一目見ただけで簡単に理解できることが重要です。 Avito では今のところ、これは Confluence へのリンクです。

Ⅲ． 手順書。 サービスの開始とその処理の複雑さに関する短いガイド。

IV. よくある質問、サービスを使用するときに同僚が遭遇する可能性のある問題を予測することをお勧めします。

V. API のエンドポイントの説明。 突然宛先を指定しなかった場合、あなたのマイクロサービスに関連する同僚がほぼ確実にその料金を支払うことになります。 現在、これには Swagger と、brief と呼ばれるソリューションを使用しています。

VI. ラベル。 または、サービスが会社のどの製品、機能、または構造部門に属しているかを示すマーカー。 これらは、たとえば、同僚が XNUMX 週間前に同じ事業部門に対して展開した機能を削減するかどうかをすぐに理解するのに役立ちます。

VII. サービスの所有者。 ほとんどの場合、それ (またはそれら) は PaaS を使用して自動的に決定できますが、安全を期すため、開発者はそれらを手動で指定する必要があります。

最後に、コード レビューと同様に、ドキュメントをレビューすることをお勧めします。

継続的インテグレーション

• リポジトリを準備しています。
• TeamCity でパイプラインを作成します。
• 権利の設定。
• サービス所有者を検索します。 ここには、手動マーキングと PaaS による最小限の自動化というハイブリッド スキームがあります。 完全自動スキームは、サポートのためにサービスが別の開発チームに移管された場合、またはサービス開発者が辞めた場合などに失敗します。
• Atlas へのサービスの登録 （上記を参照）。 すべての所有者と依存関係。
• 移行を確認しています。 潜在的に危険なものがないかどうかを確認します。 たとえば、それらの XNUMX つでは、サービスの異なるバージョン間のデータ スキーマの互換性を壊す可能性のある変更テーブルまたはその他のものがポップアップ表示されます。 その後、移行は実行されず、サブスクリプションに配置されます。PaaS は、安全に使用できる場合にサービス所有者に通知する必要があります。

焼く

次の段階は、展開前のサービスのパッケージ化です。

• アプリケーションを構築します。 古典によれば、Docker イメージで。
• サービス自体と関連リソースの Helm チャートの生成。 データベースとキャッシュが含まれます。 これらは、CLI プッシュ段階で生成された app.toml 構成に従って自動的に作成されます。
• 管理者がポートを開くためのチケットを作成する （必要な場合に）。
• 単体テストの実行とコードカバレッジの計算。 コード カバレッジが指定されたしきい値を下回っている場合、サービスはそれ以上デプロイメントに進むことはできません。 許容範囲内にある場合、サービスには「悲観的な」係数が割り当てられます。その後、時間が経過しても指標に改善が見られない場合、開発者はテストに関して進歩がないという通知を受け取ります (そしてそれについて何かをする必要があります）。
• メモリと CPU の制限を考慮する。 私たちは主に Golang でマイクロサービスを作成し、Kubernetes で実行します。 したがって、Golang 言語の特殊性に関連する微妙な点が XNUMX つあります。デフォルトでは、GOMAXPROCS 変数を明示的に設定しない場合、起動時にマシン上のすべてのコアが使用され、同じマシン上で複数のそのようなサービスが起動されると、それらのサービスが開始されます。資源を奪い合い、互いに干渉し合う。 以下のグラフは、アプリケーションを競合なしでリソース競合モードで実行した場合に、実行時間がどのように変化するかを示しています。 （グラフの出典は ここで).

実行時間は短いほど良いです。 最大: 643 ミリ秒、最小: 42 ミリ秒。 写真はクリック可能です。

手術にかかる時間は短いほど良いです。 最大: 14091 ns、最小: 151 ns。 写真はクリック可能です。

アセンブリの準備段階で、この変数を明示的に設定することも、ライブラリを使用することもできます。 automaxproc Uberの人たちから。

展開する

• 規約を確認する。 サービス アセンブリを目的の環境に配信し始める前に、次の点を確認する必要があります。
- API エンドポイント。
— API エンドポイント応答のスキーマへの準拠。
— ログ形式。
— サービスへのリクエストのヘッダーの設定 (現在、これは netramesh によって行われます)
— イベント バスにメッセージを送信するときに所有者トークンを設定します。 これは、バス全体のサービスの接続を追跡するために必要です。 サービスの接続性を向上させない冪等データ (これは良いことです) と、サービスの接続性を強化するビジネス データ (これは非常に悪いことです!) の両方をバスに送信できます。 そして、この接続が問題になった時点で、バスの書き込みと読み取りを誰が行うかを理解することは、サービスを適切に分離するのに役立ちます。

Avito にはまだそれほど多くのコンベンションはありませんが、その数は拡大し続けています。 このような合意がチームが理解し理解できる形式で利用できるようになればなるほど、マイクロサービス間の一貫性を維持することが容易になります。

模擬試験

• クローズドループテスト。 このために私たちは現在オープンソースを使用しています Hoverfly.io。 まず、サービスの実際の負荷を記録し、それから閉ループ内でそれをエミュレートします。

• ストレステスト。 私たちはすべてのサービスを最適なパフォーマンスで提供できるよう努めます。 また、各サービスのすべてのバージョンは負荷テストの対象となる必要があります。これにより、サービスの現在のパフォーマンスと、同じサービスの以前のバージョンとの違いを理解できます。 サービスの更新後にパフォーマンスが XNUMX 分の XNUMX に低下した場合、これはその所有者にとって明らかなシグナルであり、コードを詳しく調べて状況を修正する必要があります。
たとえば、収集したデータを使用して自動スケーリングを正しく実装し、最終的にはサービスがどの程度スケーラブルであるかを一般的に理解します。

負荷テスト中に、リソース消費が設定された制限を満たしているかどうかを確認します。 そして私たちは主に極端なことに焦点を当てます。

a) 総負荷を調べます。
- 小さすぎる - 負荷が数回突然低下すると、おそらく何かがまったく機能しなくなる可能性があります。
- 大きすぎます - 最適化が必要です。

b) RPS に従ってカットオフを調べます。
ここでは、現在のバージョンと以前のバージョンの違いと合計数量を見ていきます。 たとえば、サービスが 100 rps を生成する場合、そのサービスの記述が不十分であるか、これがその特異性によるものですが、いずれにせよ、これはサービスを非常に注意深く観察する理由になります。
逆に、RPS が多すぎる場合は、おそらく何らかのバグがあり、一部のエンドポイントがペイロードの実行を停止し、他のエンドポイントが単にトリガーされただけであると考えられます。 return true;

カナリアテスト

合成テストに合格した後、少数のユーザーでマイクロサービスをテストします。 私たちは、サービスの対象ユーザーのごくわずかなシェア (0,1% 未満) から慎重に開始します。 この段階では、サービスの問題をできるだけ早く示すために、正しい技術指標と製品指標がモニタリングに含まれることが非常に重要です。 カナリア テストの最短時間は 5 分、主なテスト時間は 2 時間です。 複雑なサービスの場合は、時間を手動で設定します。
私たちは分析します：
— 言語固有のメトリクス、特に php-fpm ワーカー。
— Sentry のエラー。
— 応答ステータス。
- 正確かつ平均的な応答時間。
— レイテンシー;
— 処理済みおよび未処理の例外。
— 製品の指標。

スクイズテスト

スクイーズ テストは「スクイーズ」テストとも呼ばれます。 この技術の名前は Netflix に導入されました。 その本質は、最初に XNUMX つのインスタンスを実際のトラフィックで障害点まで満たし、その制限を設定することです。 次に、別のインスタンスを追加して、このペアを再び最大までロードします。 最初の「絞り」で天井と三角州が見えます。 そこで、一度に XNUMX つのインスタンスを接続し、変化のパターンを計算します。
「圧縮」によるテスト データも共通のメトリクス データベースに流入し、そこで人為的な負荷結果をそれらで強化したり、「合成」をそれらで置き換えたりすることもあります。

生産

• スケーリング。 サービスを実稼働環境に展開するとき、サービスがどのように拡張されるかを監視します。 私たちの経験では、CPU インジケーターのみを監視することは効果的ではありません。 純粋な形式の RPS ベンチマークによる自動スケーリングは機能しますが、オンライン ストリーミングなどの特定のサービスに対してのみ機能します。 したがって、最初にアプリケーション固有の製品メトリクスを検討します。

その結果、スケーリング時に以下を分析します。
- CPU および RAM インジケーター、
— キュー内のリクエストの数、
- 反応時間、
— 蓄積された履歴データに基づく予測。

サービスをスケーリングするときは、チェーン内の最初のサービスをスケーリングせず、そのサービスがアクセスするサービスが負荷によって失敗しないように、その依存関係を監視することも重要です。 サービスのプール全体の許容可能な負荷を確立するために、「最も近い」依存サービスの履歴データ (CPU と RAM の指標の組み合わせと、アプリ固有のメトリクスに基づく) を確認し、履歴データと比較します。サービスの初期化など、「依存関係チェーン」全体にわたって上から下まで続きます。

サービス

マイクロサービスが稼働したら、それにトリガーをアタッチできます。

トリガーが発生する典型的な状況を次に示します。
— 潜在的に危険な移行が検出されました。
— セキュリティアップデートがリリースされました。
— サービス自体は長らくアップデートされていませんでした。
— サービスの負荷が著しく減少したか、サービスの製品メトリクスの一部が通常の範囲を超えています。
— このサービスは新しいプラットフォーム要件を満たさなくなりました。

トリガーの中には、動作の安定性を担うものもあれば、システム メンテナンスの機能としてのものもあります。たとえば、一部のサービスが長期間デプロイされておらず、その基本イメージがセキュリティ チェックに合格しなくなった場合などです。

ダッシュボード

つまり、ダッシュボードは PaaS 全体のコントロール パネルです。

• テストカバレッジ、イメージの数、製品コピーの数、バージョンなどのデータを含む、サービスに関する単一の情報。
• サービスとラベル（ビジネスユニットへの所属のマーカー、製品の機能など）によってデータをフィルタリングするためのツール
• トレース、ロギング、監視のためのインフラストラクチャ ツールと統合するためのツール。
• 単一のサービスポイントのドキュメント。
• サービス全体にわたるすべてのイベントを単一の視点から見ることができます。

合計で

PaaS を導入する前に、新しい開発者は、本番環境でマイクロサービスを起動するために必要なすべてのツール (Kubernetes、Helm、社内の TeamCity 機能、フォールト トレラントな方法でのデータベースやキャッシュへの接続のセットアップなど) を理解するのに数週間を費やすことができました。クイックスタートを読んでサービス自体を作成するには数時間かかります。

HighLoad++ 2018 でこのトピックに関するレポートを作成しました。ご覧ください。 ビデオ и プレゼンテーション.

最後まで読んでいただいた方へのボーナストラック

Avito では、開発者向けに XNUMX 日間の社内トレーニングを開催しています。 クリス・リチャードソン、マイクロサービスアーキテクチャの専門家。 この投稿の読者の XNUMX 人に参加の機会を与えたいと考えています。 それは 研修プログラムを掲載しました。

訓練は5月7日からXNUMX日までモスクワで行われる。 これらは完全に占有される営業日です。 昼食とトレーニングは私たちのオフィスで行われ、交通費と宿泊費は選ばれた参加者自身が支払います。

参加申し込みができます このGoogleフォームで。 あなたから - トレーニングに参加する必要がある理由と連絡方法に関する質問への答え。 クリスがトレーニングに参加する参加者を自分で選ぶため、英語で答えてください。
トレーニング参加者の名前は、この投稿の更新および開発者向けソーシャル ネットワーク Avito (AvitoTech で発表) で発表します。 Фейсбуке, VKontakte, Twitter) 遅くとも 19 月 XNUMX 日までに。

出所： habr.com