DevelopersSummit2020参加レポート/サービスメッシュは本当に必要なのか、何を解決するのか

AWS
Developers Summit_logo

DevelopersSummit2020に行ってきました。
一番印象的だった発表の参加レポートをまとめてみました。
AWSの原さんという方の発表です。
インターネット上では「鳥の人」として知られているようでした。

まとめ

  • サービスメッシュの必要性、サービスメッシュが解決する課題についての発表
  • モノリスの課題がなくなっても、マイクロサービス固有の課題が出てくる
  • マイクロサービスが本当に必要なのか、既存の問題を解決してくれるか、マイクロサービス固有の課題を飲み込んで開発していけるかを考えよう

所感

  • 個人的にはベスト発表オブデブサミ2020
  • ロジカルでわかりやすく、重厚な内容だった
  • マイクロサービス化しても新たな課題は生まれる
  • まずはよいモノリスを目指したい
  • 新しい技術がすべてを解決してくれるわけではなく、結局別の課題が出てくることを忘れない

発表内容

モノリシックなシステムアーキテクチャの課題

  • 関係者間調整のオーバヘッド
  • 変更による影響範囲の広さ
  • モジュール構造維持の難しさ
  • 非効率的なスケーリング
  • テスト・ビルドに要する時間の長さ

マイクロサービス化に期待される効果

  • 変更による影響範囲の局所化
  • モジュール境界の維持しやすさ
  • 独立したデプロイとスケーリング
  • 自律的なチームによる開発・運用
  • Polyglot(特性に合わせて言語を選べる)

分散トレーシングサービス

  • 現実世界のモノリスは複雑
  • 分散アプリケーションの分析・調査のための、ツールを用意する必要がある
  • AWSではX-rayがそれにあたる
  • 1つ1つのリクエストとレスポンスを詳細解析できる
  • 分散トレーシングサービスを使って、データを追えるようになっておかないといけない

マイクロサービスの課題

  • サービスを適切に分割することが難しい
  • テストを考えるのが難しい
  • 影響範囲を自サービス内に収めることが難しい
  • 自律的なチームが必要だが、好き勝手にやっていいということではない
  • サービス間通信の信頼性と可観測性を確保する必要がある
  • マイクロサービスは構造上ネットワークを経由してAPIを呼ぶつくりになっているが、ネットワークの可用性が100%であることを前提としてコードを書いてはいけない

サービス間通信の信頼性

  • ネットワーク経由通信=失敗が前提
  • 防衛的実装が必須要件

防衛的実装

呼び出し先サービスの位置が一定ではないことを想定する

  • アプリケーションのデプロイ先は一定ではない
    • 参照先のIPアドレスが一定ではない
  • 動的に名前解決する、サービスディスカバリが必要

一時的な呼び出し失敗を想定する

  • リトライ処理が必須

継続した呼び出し失敗を想定する

  • サーキットブレーカーを用意する
    • 呼び出しを一時的にやめるべき、レスポンスがずっと遅いのはベターではない
    • 呼び出し先サービスのパフォーマンス悪化するかもしれない
    • タイムアウト、SLOを守れなくなる恐れがある

呼び出し元システムの不具合を想定する

  • スロットリングを設定、呼び出し元から自分たちを守る

サービス間通信の可観測性を高める実装

  • ログ・メトリクス・トレース情報の出力フォーマットを、各サービスで統一する必要がある
  • 理想はそうだが、すべてを実装仕切ることは難しい。

最初の解決策

  • 共通ライブラリを配布する
  • アプリケーションコード+共通ライブラリでマイクロサービス化
  • でも下記の課題が  
    • アプリケーション改修が必要  
    • 特定の言語用のライブラリがない 
    • 共通ライブラリでパフォーマンスが悪化  
    • 共通ライブラリのバージョンを更新してくれない  
    • ライブラリを入れてくれない
  • これもうまくいかない

第2の解決策

  • プロキシへのオフロードというアイデア
    • これをサービスメッシュと呼ぶ
  • マイクロサービスに必要な実装を、プロキシに任せることができる
  • EnvoyProxyが有名
    • OSS、Lyft社が2016年に開始
    • Yamlで設定すると、EnvoyProxyがよしなに通信してくれる
  • また別の課題が
  • プロキシとアプリケーションが密結合してしまう
  • プロキシ設定に設定ファイルを利用すると、設定変更時にデプロイと再起動が必要になる
  • プロキシとアプリケーションのライフサイクルとオペレーションモデルは異なる
  • そこでAWS AppMesh
    • Envoy Proxyの動的設定変更を可能にする

AWS AppMesh

  • AppMeshはサービスメッシュのコントロールプレーン
  • アプリケーションレベルのネットワークを定義する
  • クラスタやサービスにまたがるメッシュを構築できる
  • EC2上のK8s&ECSとか、EC2アプリ&Fargateとか

サービスメッシュの必要性

  • そもそも、モノリスをマイクロサービスにする必然性があるのか?から考える
  • コードの品質やテストのなさをモノリスのせいにしてないか?
  • マイクロサービスにしてもこれらが不要になるわけではない

スピーカーの意見

  • 個人的には組織のスケーラビリティとプロダクトの成長度合いがマッチしなくなったら、マイクロサービスを導入すれば良いと思っている
  • いいモノリスが一番よいシステムだと思っている

コメント

タイトルとURLをコピーしました