# Envoy [[Lyft]] で開発された、開発者が信頼でき最終的には完全に透過的となることを目指したハイパフォーマンスなネットワーク基盤(プロキシ)。開発は2015年初めに始まった。[[Matt Klein]] が開発者。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]] ch.26 §26.4.1) ## Lyft での展開の段階 1. **エッジプロキシ**として、既存の AWS ELB サーバー群をリプレース・強化。強化されたオブザーバビリティとプロトコルサポートがプロダクト問題のトリアージに効果的だと実証された。 2. **MongoDB 安定性支援**: BSON(Binary JSON)パーサーを追加し、MongoDB トラフィックと生の TCP プロキシを検査してアプリケーションとデータベース間の接続数を制限。グローバルなレート制限も追加。 3. **サイドカー**として全アプリケーションに展開。内部の集中型ロードバランサーを撤去し、結果整合性のあるサービスディスカバリシステムと API を構築、全 Envoy 間で稠密な HTTP/2 メッシュをデプロイ。 (Source: ch.26 §26.4.1) ## 主な機能・設計特性 - **ホットリスタート**: 接続を一切落とすことなく、設定とバイナリの両方を含めて完全に再起動できる。迅速かつ容易なデプロイ・ロールバックを可能にする。 - **管理エンドポイント**: 人間が読める形式でローカルに情報をやり取りできる、オンノードデバッグ用の頑健なエンドポイント群。 - **アクティブ/パッシブなヘルスチェック**とサービスディスカバリの結合により、結果整合性のあるディスカバリストアでも高い信頼性を実現。 - **データプレーン**としての位置づけ: ネットワークトラフィックの転送(ロードバランシング・接続プーリング・リクエスト/レスポンス変更)を担う。設定管理は手作業 → Python/Jinja によるテンプレート生成 → 完全集中型の設定システム(コントロールプレーン)へと段階的に進化した。 (Source: ch.26 §26.3.6, §26.4.1-26.4.2) ## 運用上の学び(Lyft での実例) - デフォルトダッシュボード・トレース・ログ・アラームの自動作成によりサービス単位の運用ベースラインを確立。 - 大規模でフラットな L3 IP サブネットを前提とするサービスメッシュ特有の課題として、ARP キャッシュサイズの調整(`net.ipv4.neigh.default.gc_thresh1` 等)が必要になった。 - ファイル記述子作成の失敗を OOM 相当の致命的エラーとして扱う設計により、診断困難な問題への可視性を高めた。 (Source: ch.26 §26.4.2.3) ## 関連 - [[Matt Klein]] — 開発者、Lyft ネットワークチーム責任者 - [[Lyft]] — 開発元、ケーススタディの主体 - [[Istio]] — Envoy 上に構築された完全管理ソリューション - [[サービスメッシュ]] - [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]]