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とか
サービスメッシュの必要性
- そもそも、モノリスをマイクロサービスにする必然性があるのか？から考える
- コードの品質やテストのなさをモノリスのせいにしてないか？
- マイクロサービスにしてもこれらが不要になるわけではない
スピーカーの意見
- 個人的には組織のスケーラビリティとプロダクトの成長度合いがマッチしなくなったら、マイクロサービスを導入すれば良いと思っている
- いいモノリスが一番よいシステムだと思っている
コメント