生産を中断せずにマイクロサービスに切り替える方法

今日は、モノリシックソリューションがマイクロサービスにどのように移行されたかを説明します。 私たちのアプリケーションでは、24時間、1日24時間から12万回のトランザクションを処理しています。 ユーザーは12のタイムゾーンで作業します。 同時に、機能が頻繁に追加されましたが、これはモノリスで行うのは非常に困難です。 これが、システムが安定した24時間365日の運用、つまりHighLoad、High Availability、Fault Toleranceを必要とした理由です。

MVPモデルに従ってこの製品を開発しています。 ビジネスの要件に従って、アーキテクチャはいくつかの段階で変更されました。 最初は、ソリューションがどのように見えるべきか誰も知らなかったため、一度にすべてを実行することはできませんでした。 機能の追加と拡張を繰り返しながら、アジャイルモデルを移動しました。



最初は、アーキテクチャは次のようになりました。ユーザーからのリクエストをプロキシするための唯一のwar、Tomcat、およびNginxを備えたMySqlがありました。



環境（および最小CI / CD）：

• 開発-開発におけるプッシュによる展開、
• QA-1日1回、開発、
• 製品-マスターとボタンで、
• 手動統合テスト、
• すべてがJenkinsで機能します。

開発は、ユーザーシナリオに基づいて構築されました。 すでにプロジェクトの開始時点で、ほとんどのスクリプトは一種のワークフローに適合しています。 しかし、それでもすべてではなく、この状況により開発が複雑になり、「ディープデザイン」を実行できませんでした。



2015年、私たちのアプリケーションは生産されました。 産業運用では、アプリケーション、その開発、および変更をprod-serverに送信する際の柔軟性に欠けることが示されています。 高可用性（HA）、継続的デリバリー（CD）、継続的インテグレーション（CI）を実現したかったのです。

HI、CD、CIに到達するために解決する必要がある問題は次のとおりです。

• 新しいバージョンを展開するときにシンプル-デプロイされたアプリケーションに時間がかかりすぎた、
• 製品要件の変更と新しいユーザーケースに関する問題-小さな修正でもテストと検証に時間がかかりすぎた、
• Tomcatでのセッションの復元に関する問題：予約システムとサードパーティサービスのセッション管理、アプリケーションの再起動時に、Tomcatによってセッションが復元されませんでした。
• リソースのリリースに関する問題：遅かれ早かれTomcatを再起動する必要があり、メモリリークが発生しました。

これらすべての問題を順番に解決し始めました。 そして彼らが最初に取り上げたのは、製品の要件の変化でした。

最初のマイクロサービス

課題：製品要件と新しいユースケースの変更。
技術的な答え：最初のマイクロサービスが登場しました-彼らはビジネスロジックの一部を別のwarファイルに取り込み、Tomcatに入れました。



フォームの別のタスクが私たちにやってきました：週の終わりまでに、サービスのビジネスロジックを更新し、この部分を別のwarファイルに入れて同じTomcatに入れることにしました。 構成と開発の速度を上げるために、Spring Bootを使用しました。

定期的にユーザー設定を変更することで問題を解決する小規模ビジネス機能を作成しました。 ビジネスロジックが変更された場合、Tomcat全体を再起動する必要はなく、30分間ユーザーを失い、そのごく一部のみを再起動する必要があります。

同じ原則に従ってロジックを正常にレンダリングした後、アプリケーションに変更を加え続けました。 そして、システム内の何かを根本的に変えるタスクが私たちのところに来た瞬間から、これらの部分を別々に取り出しました。 したがって、私たちは常に新しいマイクロサービスを蓄積しています。

マイクロサービスを選び出した主なアプローチは、ビジネス機能またはビジネスサービス全体の割り当てです。

そのため、1Cなどのサードパーティシステムと統合されたサービスを迅速に分離しました。

最初の問題はタイピングです。

課題：マイクロサービスはすでに15。タイピングの問題。
技術的な答え： Spring Cloud Feign。

ソリューションをマイクロサービスにカットし始めたからといって、問題が解決することはありませんでした。 さらに、新しい問題が発生し始めました：

• モジュール間のDtoでの入力とバージョン管理の問題、
• Tomcatに1つのwarファイルではなく、多くのwarファイルをデプロイする方法。

新しい問題により、技術作業中のすべてのTomcatの再起動時間が長くなりました。 作業が複雑になったことがわかりました。

もちろん、タイピングの問題はそれ自体では発生しませんでした。 おそらく、いくつかのリリースの過程で、テスト段階または開発中にこれらのエラーを発見し、なんとかすることができたため、単に無視しました。 しかし、生産の途中でいくつかのエラーが発見され、緊急の修正が必要になったとき、規制を導入するか、この問題を解決するツールの使用を開始しました。 httpリクエスト用のクライアントライブラリであるSpring Cloud Feignに気付きました。

github.com/OpenFeign/feign
cloud.spring.io/spring-cloud-netflix/multi/multi_spring-cloud-feign.html

彼を選んだのは

-プロジェクトに実装するためのオーバーヘッドはほとんどありません。
-彼はクライアントを生成し、
-サーバーとクライアントの両方で1つのインターフェースを使用できます。

彼は、私たちが顧客を形成したという事実によってタイピングの問題を解決しました。 また、サービスのコントローラーには、顧客の形成と同じインターフェースを使用しました。 したがって、タイピングの問題はなくなりました。

ダウンタイム 最初の戦い。 操作性

ビジネス上の課題： 18のマイクロサービス、現在はシステムのダウンタイムは受け入れられません。
技術的な答え：アーキテクチャの変更、サーバーの拡張。

ダウンタイムと新しいバージョンの展開にまだ問題があります。Tomcatセッションの復元とリソースの解放に問題があります。 マイクロサービスの数は増え続けました。

すべてのマイクロサービスの展開プロセスには約1時間かかりました。 時々、Tomcatリソースのリリースの問題のために、アプリケーションを再起動する必要がありました。 これをより迅速に行う簡単な方法はありませんでした。

アーキテクチャを変更する方法について考え始めました。 インフラストラクチャソリューション部門と協力して、既存のソリューションに基づいて新しいソリューションを構築しました。



アーキテクチャの外観は次のように変更されました。

• アプリケーションを複数のデータセンターに水平に分割し、
• 各サーバーにFilebeatを追加し、
• トランザクションとログの数が増えるにつれて、ELK用に別のサーバーを追加しました。
• いくつかのhaproxy + Tomcat + Nginx + MySQLサーバー（これが高可用性を提供する方法です）。

使用された技術は次のとおりです。

• Haproxyルーティングとサーバー間のバランス、
• Nginxは静的変数の配布を担当し、tomcatはアプリケーションサーバーでした。
• ソリューションの特徴は、各サーバー上のMySQLが他のMySQLの存在を知らないことでした。
• データセンター間の遅延の問題により、MySQLレベルでのレプリケーションは不可能でした。 そのため、マイクロサービスのレベルでシャーディングを実装することにしました。

したがって、ユーザーからTomcatのサービスにリクエストが来たとき、彼らは単にMySQLからデータをリクエストしました。 整合性が必要なデータは、すべてのサーバーから収集され、接着されました（すべての要求はAPIを介して行われました）。

このアプローチを適用すると、データの一貫性が少し失われましたが、現在の問題は解決しました。 ユーザーは、どのような状況でもアプリケーションを操作できます。

• サーバーの1つがクラッシュした場合でも、システム全体の操作性をサポートする3〜4が残っていました。
• バックアップは、それらが作成された同じデータセンター内のサーバーではなく、近隣のサーバーに保存しました。 これは災害復旧に役立ちました。
• フォールトトレランスは、複数のサーバーを通じて対処されました。

とても大きな問題が解決されました。 使いやすいユーザーになりました。 更新をロールバックしたとき、彼らは感じませんでした。

ダウンタイム 二度目の戦い。 完全な価値

ビジネス上の課題： 23のマイクロサービス。 データの一貫性の問題。
技術的な解決策：サービスを互いに別々に起動します。 改善された監視。 ズールとエウレカ。 個々のサービスの開発とその提供を簡素化しました。

問題が発生し続けました。 これが私たちのredelaの見た目です：

• 再入力の場合、データの一貫性がなかったため、機能の一部（最も重要ではない）がバックグラウンドにフェードインしました。 たとえば、新しいアプリケーションをローリングするとき、統計は劣っていました。
• アプリケーションを再起動するために、あるサーバーから別のサーバーにユーザーを誘導する必要がありました。 また、約15〜20分かかりました。 その上、ユーザーはサーバーからサーバーに切り替えるときにログインする必要がありました。
• また、サービスの数が増えたため、Tomcatを再起動しました。 そして今、私は多数の新しいマイクロサービスに従う必要がありました。
• サービスとサーバーの数に比例して、レッドレイ時間が増加しました。

考えてみると、サービスを互いに別々に起動することで問題を解決できると判断しました。1つのTomcatでサービスを開始せず、それぞれが同じサーバー上でサービスを開始する場合です。



しかし、他の疑問が生じました。サービスはどのように相互に通信し、どのポートを外部に開放する必要があるのでしょうか？

多数のポートを選択し、それらをモジュールに配布しました。 ポートに関するすべての情報をpomファイルまたは一般的な構成のどこかに保持する必要を避けるために、これらの問題を解決するためにZuulとEurekaを選択しました。

ユーリカ-サービス発見
Zuul-プロキシ （TomcatにあったコンテキストURLを保存するため）

Eurekaは、サービス間の通信が可能になったため、高可用性/フォールトトレランスのパフォーマンスも改善しました。 現在のデータセンターに適切なサービスがない場合は、別のサービスセンターに移動するように設定します。

監視を改善するために、既存のスタックからSpring Boot Adminを追加して、どのサービスで何が起こっているのかを理解しました。

また、複数の同一のサービスを同じサーバーに展開する問題を取り除くために、専用サービスをステートレスアーキテクチャに移行し始めました。 これにより、単一のデータセンター内で水平スケーリングが可能になりました。 同じサーバー内で、更新時に同じアプリケーションの異なるバージョンを実行したため、ダウンタイムもありませんでした。

個々のサービスとその配信の開発を簡素化するという点で、継続的配信/継続的統合にアプローチしたことが判明しました。 これで、1つのサービスの提供がリソースのリークを引き起こすことを恐れる必要がなくなり、サービス全体を再起動する必要がありました。

新しいバージョンを展開する際のシンプルさは依然として残っていますが、完全ではありません。 サーバー上の複数のjarを1つずつ更新すると、これはすぐに起こりました。 また、多数のモジュールを更新するときにサーバーで問題は発生しませんでした。 ただし、アップグレード中に25個のマイクロサービスすべてを再起動するには非常に長い時間がかかりました。 Tomcatの内部よりも高速ですが、これは一貫して行われます。

また、すべてをjarで実行することでリソースを解放する問題を解決し、システムのメモリ不足キラーがリークまたは問題に対処しました。

ファイト3、情報管理

ビジネス上の課題： 28のマイクロサービス。 管理する必要がある多くの情報。
技術的ソリューション： Hazelcast。

引き続きアーキテクチャを実装し、基本的なビジネストランザクションが一度に複数のサーバーをカバーすることを認識しました。 1ダースのシステムにリクエストを送信するのは不便でした。 そのため、イベントメッセージングとユーザーとのシステム作業にHazelcastを使用することにしました。 また、後続のサービスでは、サービスとデータベース間のレイヤーとして使用していました。



最終的に、データの一貫性の問題を取り除きました。 これで、不要なアクションを実行せずに、すべてのデータベースにデータを同時に保存できました。 Hazelcastに、受信した情報を保存するデータベースを指定しました。 彼はすべてのサーバーでこれを行いました。これにより作業が簡素化され、シャーディングを取り除くことができました。 それで、アプリケーションレベルのレプリケーションに移りました。

また、セッションをHazelcastに保存し始め、承認に使用しました。 これにより、ユーザーに気付かれずにサーバー間でユーザーを転送できました。

マイクロサービスからCI / CDへ

ビジネスの課題：実稼働環境で更新プログラムのリリースを加速する必要があります。
技術的ソリューション：アプリケーションの展開パイプライン、コードを操作するためのGitFlow。

マイクロサービスの数とともに、内部インフラストラクチャも開発されました。 サービスの本番環境への配信を促進したかったのです。 これを行うために、アプリケーションに新しい展開パイプラインを実装し、コードを操作するためにGitFlowに切り替えました。 SIは、各コミットのテストの収集と実行、単体テストの実行、統合テスト、アプリケーション配信による成果物の追加を開始しました。



これを迅速かつ動的に行うために、これらすべてのタスクを実行して開発者をプッシュするいくつかのGitLabランナーをデプロイしました。 GitLab Flowのアプローチのおかげで、いくつかのサーバーがあります：開発、QA、リリース候補、本番。

開発は次のとおりです。 開発者は、別のブランチ（機能ブランチ）に新しい機能を追加します。 開発者が終了すると、開発のメインブランチとブランチをマージするリクエストを作成します（ブランチへのリクエストのマージ）。 他の開発者は合併要求を見て、それを受け入れるか、または受け入れません。その後、コメントが修正されます。 マージ後、トランクブランチで特別な環境が展開され、環境を上げるためのテストが実行されます。

これらのすべての段階が完了すると、QAエンジニアは自分の「QA」ブランチに変更を加え、機能および研究テスト用に以前に作成されたテストケースでテストを実施します。

QAエンジニアが完了した作業を承認すると、変更はRelease-Candidateブランチに移動し、外部ユーザーがアクセスできる環境に展開します。 この環境では、顧客は当社の技術を受け入れて検証します。 その後、すべてをプロダクションに蒸留します。

何らかの段階でバグがある場合、これらのブランチでこれらの問題と開発の平均を解決します。 また、Redmineが機能のステージを通知できるように、小さなプラグインを作成しました。



これにより、テスターはタスクに接続する必要がある段階を確認し、開発者はバグを修正することができます。エラーが発生した段階を確認し、特定のブランチに移動してそこでバグを再生できます。

さらなる開発

ビジネス上の課題：ダウンタイムなしでサーバーを切り替えます。
技術的ソリューション： Kubernetesでのパッケージ化。



現在、展開の最後に、技術専門家がjer-kiをPRODサーバーに報告して再起動します。 これはあまり便利ではありません。 Kubernetesを実装し、それをデータセンターにリンクし、それらを更新し、それらを一度にロールすることにより、システムの作業を自動化したいと考えています。

このモデルに進むには、次の作業を完了する必要があります。

• ユーザーが無差別にすべてのサーバーにリクエストを送信できるように、現在のソリューションをステートレスアーキテクチャにもたらします。 一部のサービスでは、引き続き何らかのセッションデータがサポートされています。 この作業は、データベースのデータ複製にも適用されます。
• また、いくつかのビジネスプロセスを含む最後の小さなモノリスを切断する必要があります。 これにより、最後の主要なステップである継続的デリバリーにつながります。

PSマイクロサービスへの移行で何が変わったのか

• 要件の変更の問題を取り除きました。
• Hazelcastに転送することにより、Tomcatでセッションを復元する問題を取り除きました。
• あるサーバーから別のサーバーにユーザーを転送する場合、ログインする必要はありません。
• リソースのリリースに伴うすべての問題を解決し、オペレーティングシステムの肩に移しました。
• 入力とバージョン管理の問題は、Feignのおかげで解決されました。
• Gitlab Pipelinesの助けを借りて、自信を持って継続的デリバリーに移行しています。