[論文レビュー] Developing a Process in Architecting Microservice Infrastructure with Docker, Kubernetes, and Istio

Yujing Wang, Darrel Ma|arXiv (Cornell University)|Nov 6, 2019

Software System Performance and Reliability参考文献 2被引用数 4

ひとこと要約

本稿では、Docker、Kubernetes、Istioを用いてモノリス型のJava Springアプリケーションをマイクロサービスに移行するための三段階的でコードベースおよびプラットフォームに依存しないプロセスを提案する。この手法により、コンテナ化、Istioによるサービスメッシュ通信、KubernetesのConfigMapsを用いた構成管理、およびGitOpsパイプラインによる自動化されたロールアウトを通じて、安定的でスケーラブルなデプロイメントが可能となり、最適化されたコールバッチ処理によりサービス間のレイテンシが低減される。

ABSTRACT

As an application usage grows, its owner scales up vertically by replacing old machines with more powerful ones. This methodology is expensive and leads to resource waste. In response to the business needs, internet giants have developed the microservice architecture, which lets developers divide up their application into smaller units that can be hosted on multiple machines, thus enabling horizontal scale up. We propose a triphasic incremental process to transform a traditional application into a microservice application that guarantees stability during the operation. Then we demonstrated such methodology in a prototype microservice application based on an existing monolithic application. First, the developer splits a monolithic application into atomic services and aggregated services. Second, these services are packaged, containerized, and then deployed on Kubernetes. During this stage, Istio is deployed on the Kubernetes cluster to establish pod level communications, delegate traffic flows and filter requests, and enable the autoscaler. Other external add-ons, such as database connections, are defined in service entry. In the last stage, we developed an algorithm guideline to minimize inter-service calls by compiling all needed calls into a list and perform one finalized call. Although it increases memory usage, it avoided the wait time incurred during interservice calls. We then investigated managing configurations using config maps, recommended a pipeline being developed to perform automatic rollover.

研究の動機と目的

• モノリス型のJava Springアプリケーションをマイクロサービスに変換するための再現可能でスケーラブルかつポータブルな手法の欠如に対処すること。
• ベンダーや言語に依存しない安定的で段階的な移行を可能にすること。
• システムの信頼性とパフォーマンスを維持しながら、サービス間通信のオーバーヘッドを最小限に抑えること。
• GitOpsの原則に従い、自動化された構成管理と継続的デプロイメントを実装すること。
• 既存のデータインfraストラクチャと互換性を保ちつつ、将来の拡張性をサポートすること。

提案手法

• モジュール化可能な分解を可能にするために、モノリスを原子的および集約的サービスに分割する。
• Dockerを用いてサービスをコンテナ化し、Kubernetesによるオーケストレーションで動的スケーリングと管理を実現する。
• Istioをサービスメッシュとして統合し、サービス間通信、トラフィックルーティング、リクエストフィルタリング、および事前定義されたしきい値に基づく自動スケーリングを管理する。
• KubernetesのConfigMapsを活用して構成を外部化し、アプリケーションコードの再デプロイなしにリモートで更新可能にする。
• GitOpsパイプライン（例：Weave Fluxを用いる）を実装し、リモートGitリポジトリでの構成変更に伴い自動的にポッドを再起動する。
• 複数のサービス間コールを1回のリクエストに統合するバッチ処理アルゴリズムを開発し、ラウンドトリップ回数を削減することで、O(2(N + L))の実行時間計算量を達成する。

実験結果

リサーチクエスチョン

• RQ1 モノリス型アプリケーションを最小限の混乱を伴いながら段階的にマイクロサービスアーキテクチャに変換する方法は何か？
• RQ2 Kubernetesベースのマイクロサービス環境において、サービスディスcoveryとサービス間通信を効果的に管理するにはどうすればよいか？
• RQ3 効率的な読み取り/書き込みパフォーマンスを確保しながら、既存のデータインfraストラクチャと互換性を保つデータ戦略は何か？
• RQ4 構成管理をコードから分離し、継続的デプロイメントを自動化するにはどのような手法が有効か？
• RQ5 機能を損なわずにサービス間通信のオーバーヘッドを最小限に抑える技術は何か？

主な発見

• 三段階プロセスにより、Docker、Kubernetes、Istioを用いてモノリス型のJava Springアプリケーションが、スケーラブルでコンテナ化されたマイクロサービスアーキテクチャに成功して移行された。
• Istioにより、動的トラフィック管理、リクエストフィルタリング、および事前定義されたしきい値に基づく自動スケーリングが可能になった。
• ConfigMapsにより、バージョン管理可能な外部構成が可能になり、アプリケーションコードとは独立して更新できるようになった。
• GitOpsパイプラインにより、完全に自動化され、idempotent（同一性保証）な構成ロールアウトが実現され、手動操作が不要となった。
• バッチ処理アルゴリズムにより、複数のコールを1つのリクエストに統合することで、サービス間コールのレイテンシが低減され、ラウンドトリップ遅延の最小化によるパフォーマンス向上が達成された。
• バッチ処理によるメモリ使用量のわずかな増加はあったが、待機時間の短縮によるパフォーマンス向上がコストを上回った。