BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Lyftにおけるマイクロサービステストの拡張と自動化

Lyftにおけるマイクロサービステストの拡張と自動化

原文(投稿日:2022/03/31)へのリンク

Liftは以前、エンドツーエンドのテストなど、いくつかの目的でクラウドベースの分離環境を使用していた。しかしながら、マイクロサービスの数が増えるにつれて、これらの環境を用いたテストでは拡張性が不足するようになり、次第に価値を失っていった。先日の記事では、Lyftが共有ステージング環境においてリクエスト分離を使用したテストへ移行し、運用デプロイメントのゲート管理に受け入れテストを使用するようになった経緯を紹介した。

Lyftは、エンジニアがテスト目的で使用可能な、Dockerベースのコンテナオーケストレーション環境を構築した。この環境は、データベースシーディング、パッケージとイメージのダウンロード、インストールなど、ローカル仮想マシンを管理するツール類とそのコンフィギュレーションで構成されている。当初はローカルでの使用を想定したものだったが、後にクラウドに移行して、Oneboxと呼ばれるようになった。

エンジニアはOneboxを使って、自身がテストしたいサービスを、その依存関係や関連するデータストアと合わせて実行することができた。簡単に言えば、Lyftシステムのミニチュア版だ。最終的にOneboxは、これ以上拡張できないというポイントに到達した。

一方でLyftは、トラフィック(シミュレーション)とサービスレベルの面で、実運用システムに近い共用ステージング環境も用意していたので、それを活用してサービスのフィーチャーブランチをデプロイし、現実的なデータに基づいたフィードバックを取得する作業をすでに行っていた。この環境は、新機能をテストする上では、Oneboxの置き換え候補として有望なものだったが、サービス間の分離機能が欠けていたため、不安定な新機能がステージング環境全体に問題を引き起こす可能性を持っていた。

その解決策として、ステージング環境に"ステージングオーバーライド"が実装された。これは"[Lyftの]分離モデルのアプローチを根本から変えるものでした。完全に分離された環境を用意する代わりに、共有環境内でリクエストを分離するようにしたのです。"

つまり新たなアプローチは、サービス全体を分離するのではなく、リクエストを分離するのである。

(出典: https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-3-extending-our-envoy-mesh-with-staging-fdaafafca82f)

このテクニックを使うことで、Lyftのサービスメッシュに参加しない、従って通常のトラフィックを阻害しない形での、サービスインスタンスの配置と起動が可能になる同社はこれを、"オフロードデプロイメント(offloaded deployment)"と呼んでいる。新機能をテストする場合は、新たなインスタンスにルーティングされるように、特別なヘッダをリクエストに付加すればよい。

LyftはEnvoyを使ってサービスメッシュを構築しているので、すべてのトラフィックがEnvoyサイドカーを通過する。デプロイされたサービスはサービスメッシュに登録され、発見可能(discoverable)になり、メッシュ内の他のサービスから送られたリクエストの処理を開始する。オフロードデプロイメントにはコントロールプレーンに対して、そのサービスを発見可能にしないように指示するメタデータが含まれている。

オフロードデプロイメントは、専用のGitHubボットを起動することによって、開発者のプルリクエストから直接生成することができる。Lyftのプロキシアプリケーションを使えば、protobufエンコードされたメタデータをOpenTracingバッゲージとして追加することが可能になる。このメタデータは、サービスの実装言語、サービス間のプロトコルやキューなどに関わらず、リクエストのライフタイムを通じてすべてのサービス間で伝搬される。EnvoyのHTTPフィルタはステージングオーバーライドをサポートするように修正されており、オーバーライドメタデータに基いて、リクエストをオフロードインスタンスにルーティングする。

CI中のインテグレーションテストにもOnebox環境が使用されていたが、マイクロサービスの数が増えたことによって、実行するテスト数や実行時間も増加していた。それとは逆に、Oneboxを使用しなくなったことと同じ理由で、その有効性は減少していた。

Lyftのエンジニアたちは既存のエンドツーエンドテストを調査した。その結果、重要なビジネスフローを表現しているのが一部であることを突き止め、

それら重要なテストを受け入れテストに置き換えた。その作業と並行して、各サービスがそれぞれ統合テストセットを持つ従来のテストモデルを改め、エンドツーエンドテストの受け入れテストの小規模かつ集中的なコレクションへと移行した。受け入れテストを集中化することによって、テストの重複を回避すると同時に、テストの関連性をより適切に設定および維持できるようになり、テスト間でのコードの再利用も可能になった。

また、"内部ループ"CIの一部としてエンドツーエンドテストを実行することを止める、という判断が採用され、デプロイメント実施後のステージング環境での受け入れテストで代替されることになった。

この受け入れテストの結果が以降の運用環境へのデプロイメントの条件となるため、事実上、新たな運用デプロイメントゲートの役割を果たすことになる。

(出典: https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-4-gating-deploys-with-automated-acceptance-4417e0ebc274)

さらに、既存のトラフィックシミュレーションエンジンを拡張して、受け入れテストの実行にも使用できるようにした。既存のエンジンを拡張した経緯から、テストの記述には独自の設定構文を使用する。これがもし、"スクラッチから始めていたのならば、CucumberやGherkinのような既存のテストフレーワークを使った方がよかったかも知れません。"

コミット毎に実行していた統合テストを運用投入前の受け入れテストに切り替えたことで、数千件のテストが削除されたか、ユニットテストに置き換えられた。プルリクエストも数分でマージできるようになったが、実運用に入る前のバグ数にはほとんど影響していない。

受け入れテストの話題に関して、InfoQには、Ben Linders氏がDave Farley氏に自動受け入れテストとの関連とメリットについて尋ねたインタビューがある。

作者について

この記事に星をつける

おすすめ度
スタイル

BT