[レポート] DEV312: Fully Realizing the Microservices Vision with Service Mesh #reinvent

2018.11.30

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

本記事はAWS re:Invent 2018 「DEV312-S - Fully Realizing the Microservices Vision with Service Mesh」のレポートです。

The service mesh is becoming the most critical component of the cloud-native stack, with users ranging from small startups to Internet giants and traditional enterprises. While still early in terms of adoption, this new infrastructure layer has massive implications for the way companies build and operate distributed systems. In this session, SignalFx provides an overview of distributed systems and service instrumentation, then examines how a service mesh approach addresses inter-service communication, testing, and other fundamental challenges of adopting microservices architecture. Learn about the considerations for monitoring and observability, as well as the trade-offs, of implementing service mesh. This session is brought to you by AWS partner, SignalFx.

スピーカー

Arijit Mukherji - CTO, SignalFx

レポート

マイクロサービスとクラウドの環境は複雑だが、サービスメッシュは我々を約束の地に連れて行ってくれる。

サービスメッシュってなに?

サービスメッシュはサービス間のコミュニケーションのためのインフラのレイヤーである。 コミュニケーションを可視化し、管理可能にし、コントロールできるようにしてくれる。

μ1がμ2と接続する必要がある場合、

ドメイン名もしくはIPで直接接続できる。

各サービスを特定するために、一般的にサービスディスカバリが使われる。

サービスメッシュはそれぞれのインスタンスにL7プロキシを追加する。

サービスディスカバリはプロキシのレイヤーでハンドリングされる。

ユーザの意思がPolicy Engineに注入され、プロキシはPolicy Engineとやり取りを行う。

一般的なユースケース

  • エラーハンドリング
    • プロトコルを認識したプロキシによる自動的なリトライ
    • サーキットブレーカー
      • おかしなマイクロサービスへの呼び出しを止める
  • ロードバランサー
    • プロキシがL7ロードバランサーとして振る舞う
  • リクエストのルーティング
    • アプリケーションを認識したプロキシとサービスディスカバリが複雑なルーティングを可能にする
    • 例えば顧客やソフトウェアのバージョンなどを元にしたルーティング
  • 認証
    • 誰が誰にアクセスしているのか?
    • マイクロサービス間のコミュニケーションの透過的な暗号化

サービスメッシュの実装いろいろ。

どうやるか

マイクロサービスのサービスディスカバリとしてのプロキシ

設定をPolicy Engineに集約

  • ユーザは設定をPolicy Engineに集約
  • Policy Engineは全てのプロキシに設定をプッシュ

フィードバックを元にした設定の適用

  • 動作状態を基にしたフィードバックによるプロキシの再設定

実行時の振る舞い最適化

  • エラーハンドリング、リトライ、タイムアウト
    • HTTPのような一般的なプロトコルを使っていれば、プロキシはエラーやリトライをハンドリングできる
    • マイクロサービスのコードベースを単純化する
    • エラーハンドリングの振る舞いを設定化
  • サーキットブレーカー
    • プロキシはエラーとレイテンシーの統計をとる
    • 統計はポリシーエンジンがインスタンスの状態管理に利用する
    • おかしなインスタンスは自動的に新しいリクエストの受信を止める
  • コストとパフォーマンスの最適化
    • ネットワークコスト最適化のために同じ場所にあるターゲットを優先
    • レイテンシー最適化のために早いインスタンスを優先

テスト

  • 多くのカオスエンジニアリングの特徴はサービスメッシュで実装されている
  • エラーやパフォーマンスにおける問題のシミュレーション
    • 失敗や特定のエラーのシミュレーション
    • レイテンシやその他パフォーマンスの問題をシミュレーション
    • ホスト、地理、顧客などに影響するランダムな問題のシミュレーション
  • Chaos Experienceの自動化

サービスメッシュとモニタリング

  • メトリクス
    • 可視化
    • アラート
    • 一画面で参照可能
  • ログ
    • 根本原因の分析
    • セキュリティ
  • APM
    • 現代的な環境での分散トレーシング

サービスメッシュがモニタリングに与える影響

  • 品質における最低ラインを確率
    • 標準化された全てのREDメトリクス、トレースなどによってバラついた品質を直す
    • RED - Rates (calls/sec), Errors, Durations (call latencies)

サービスメッシュによるモニタリングの統合

  • intentドリブンなオペレーションのためのフィードバックの提供
    • 標準化された高品質な測定は、フィードバックベースの自動化をサポートする
  • インフラのモニタリング要件
    • 多様な環境のサポート
    • データ収集のための自動設定
    • 細分化
    • リッチなメタデータ
    • 一貫性のある測定の収集
    • インフラの相関
    • スケーラビリティ
    • ミュータブルなメタデータとフレキシブルなクエリ
  • 分析の要件
    • 全てのデータセットを跨いだHigh-cardinalityな分析
    • タイムリーかつインタラクティブ
    • プログラマブルでデータサイエンスの要件を満たす

SignalFxについて

最後にSignalFxの紹介がありました。