Lecture course on Microservices : Part 3

Transcript

1. Lecture course on Microservices 第３部：マイクロサービスにおける CI/CD とモニタリング 中井悦司 / Etsuji Nakai 2022/02/16 ver2.3
2. Contents • 9. マイクロサービスにおけるデプロイメント • 10. マイクロサービスのモニタリングシステム • 11. ロギングとトレーシング 2
3. 9. マイクロサービスにおけるデプロイメント
4. プロダクション環境の構成要素 4 • サービス実行環境（Kubernetes など）に加えて、CI/CD パイプライン、ネットワーク管 理、モニタリングシステムなどの構築が必要 プロダクション モニタリング システム ネットワーク 管理システム サービス実行環境 デプロイメントパイプライン ランタイム（VM、 コンテナなど） ロードバランサー、 DNS など デプロイメント ツール 開発ツール
5. マイクロサービス環境におけるデプロイメントの特徴 • 小さな変更（← マイクロサービスのメリット） ◦ リリース時の変更量を小さく保つ事で、起こり得る問題を予測可能にして、リリース に伴うリスクを減らす • マニュアル作業の限界 ◦ リリース頻度を考慮すると、伝統的なマニュアル作業はスケールしない • 自動化によるプロセスの一貫性の担保 ◦ 静的コードチェック、単体テスト、統合テストなど、デプロイメントに必要なプロセ スを自動化することで、変更の大小にかかわらず、すべてのマイクロサービスに一貫 性を持った手順を適用する 5
6. マイクロサービス環境におけるデプロイメントの特徴 6 プロダクション ステージング 不要になった サービス ステージングに 未反映の外部依存 サービスのコード変更 サービスごとの 独立した変更 ステージングでの 事前テスト 共通のデプロイメントプロセス
7. デプロイメントの課題 • 安定性の実現 ◦ マイクロサービスの追加や機能変更が頻繁に行われる環境で、安定的にサービスを提供 しつづけるには何が必要か？ • Testing in production ◦ プロダクション環境でなければテストできない内容をどのように取り扱うか？ • 依存関係の管理 ◦ マイクロサービス間の依存関係により、ビルドやリリースが独立して実施できなくなる 状況をどのようにして避けるか？ • マイクロサービスの撤収 ◦ 利用されなくなったマイクロサービスを発見・撤収する方法は？ 7
8. デプロイメントプロセスのゴール • Safety at pace : デプロイのスピードと安全性を両立。デプロイメントの各ステージに適 切な Validation プロセスを実装すること • Consistency : サービスの種類（技術スタックなど）に依存しない、「予測可能」でス ケーラブルなプロセスを提供 8 ソース コード コード レビュー ビルド 単体テスト ステージング デプロイ 統合テスト プロダクション デプロイ Artifact Repository Code Repository ステージング環境 プロダクション環境 Testing in production
9. Consistent （予測可能）ではないプロセスの例 9 • プロダクション環境でこれをやると、どのような問題が・・・？ インスタンスごとに異なる コミットのコードが使われる 仮想マシン App ロードバランサー 仮想マシン App 仮想マシン App Code Repository スタートアップスクリプト でコードをダウンロード・ 自動インストール リポジトリのタイムライン 仮想マシン１ 仮想マシン２
10. アーティファクトの管理 10 • ソースをコミットした後にビルドプロセスを実行することで、デプロイメントに利用する 「アーティファクト」を生成する • アーティファクトは、Immutable で Deterministic でなければならない ◦ 同じコミットからビルドすれば、必ず同一のアーティファクトが生成される • アプリケーションバイナリだけではなく、 その実行に必要となるすべてのコンポーネ ントをアーティファクトして管理する必要 がある ◦ 依存ライブラリー、（スクリプト言語 の場合）インタープリター、ロギング ツール、etc... ソース コード Artifact Repository Code Repository アーティファクト ビルド プロセス ステージング／ プロダクション デプロイ
11. デプロイ環境の違いを構成ファイルで管理 11 • すべてのデプロイ環境（Test, Staging, Production）で同一のアーティファクトを使用 • 環境による違いは、構成ファイルで管理 ◦ 構成ファイルはソースコードの一部としてバージョン管理する Artifact Repository アーティファクト ステージング プロダクション PROJECT_ID=production DATABASE=production.db.host DEBUG=False LOG_LEVEL=INFO PROJECT_ID=staging DATABASE=staging.db.host DEBUG=TRUE LOG_LEVEL=DEBUG 環境ごとに 構成ファイルを用意
12. コンテナを用いる場合 12 • アーティファクトとしてパッケージングする範囲は、ランタイムの選択（物理ホスト、仮想 マシン、コンテナ等）によって変わる • ランタイムとしてコンテナを用いる場合は、下図のようなデプロイメントモデルが標準的 仮想／物理マシン コンテナ アプリケーション バイナリー ・・・ Container Registory アプリケーションバイナリーを 含むコンテナイメージをデプロイ コンテナクラスター コンテナ スケジューラー 仮想／物理マシン 仮想／物理マシン 仮想／物理マシン Service A Service B コンテナスケジューラーが サービスの配置を決定 コンテナイメージを Pull
13. Kubernetes のメリット • Kubernetes のようなコンテナ専用のクラスター管理基盤を利用することで、次のような メリットが得られる ◦ デプロイ環境の標準化（プロダクションとステージングの構成を同一に保つ） ◦ カナリアリリース、Blue-Green デプロイメントなど、Continuous Delivery の手法 が利用しやすくなる • ステージング環境の構成には、いくつかの選択肢が考えられる ◦ すべてのサービスをデプロイ ◦ サブシステムごとに関連するサービスだけをデプロイした個別の環境を用意 13
14. カナリアリリースによるローリングアップデート 14 • コンテナを用いることで、ローリング アップデートや Blue-Green デプロイ メントなどの手法が利用しやすくなる • 問題発生時は、即座にロールバックを 実施 ◦ デプロイだけでなく、ロールバッ クも自動化が必要 ◦ フィーチャーフラグも活用 v1 v1 v1 v2 v2 一部のトラフィック を v2 に向ける メトリックを比較して、 v2 の安全性を確認する v1 v2 v2 v2 v2 段階的に v2 の 割合を増やす
15. フィーチャーフラグの活用 • 新しい機能を追加する際に、その機能を on / off するためのフラグを用意しておく • 問題発生時は、ロールバックする代わりに、該当機能を off にする設定ファイルの再デプ ロイのみを行う（設定ファイルもコードの一部として、リポジトリで管理する） • 複数のサービスにまたがる機能の場合、サービス間で設定の不整合がおきないように注意 が必要 15 ◦ 設定ファイルの代わりに、 Feature store / Feature service を用いる方法もある Feature store Customer service Order service 設定 on/off 設定取得 Customer service Order service Feature service Feature store 設定取得
16. Dark launch の活用 • 既存バージョンと新バージョンの 両方を並行稼働して結果を比較 • エンドユーザーには新バージョン の結果は見せない • ML モデルのデプロイでよく利用 される手法 16 API ゲートウェイ ML v1 service ML v2 service リクエストを 複製して転送 v1 からの レスポンスのみ利用 Prediction log それぞれの 処理結果を比較
17. アーティファクトリポジトリを用いた自動化プロセス 17 ソース コード コード レビュー ビルド 単体テスト ステージング デプロイ 統合テスト プロダクション デプロイ Artifact Repository Code Repository ステージング環境 プロダクション環境 ビルド済みの バイナリーを保存 テスト済みの バイナリーをデプロイ テスト結果 を記録 テスト結果 を記録 コードのコミットをトリガーにして 単体テスト/統合テストまでを自動化 プロダクション環境へのデプロイ （カナリアリリース/Blue-Green デプロイメント） Testing in production
18. 10. マイクロサービスのモニタリングシステム
19. 参考書籍 19 https://www.humio.com/resources/reports/free-ebook-distributed-systems-observability/
20. モニタリングとオブザーバビリィティ • モニタリング：システムが正常に稼働し ていることをメトリックから確認 • オブザーバビリティ：システムがなぜ正 常に稼働しないのかをログやトレースか ら確認 • メトリック ⇨ モニタリング • トレース、ログ ⇨ オブザーバビリティ 20 メトリックの モニタリング トレース
21. （参考）オブザーバビリィティの役割 21 起こり得る問題 テスト可能な問題 テスト不可能な問題 予測可能な問題 予測不可能な問題 テストで発見 モニタリングで発見 ロギング／ トレーシングで 何が起きたかを理解する オブザーバビリィティ が特に必要な領域
22. 必ず収集するべきメトリック • インフラリソースの監視：USE Method ◦ Usage：CPU、メモリ、ネットワーク帯域などのリソース使用率 ◦ Saturation：リソースの枯渇を監視 ◦ Error：サーバー、ネットワーク機器など、インフラシステムの障害を監視 ※ リソースの枯渇だけではなく、使用率の急激な減少などにも注意する 22
23. 必ず収集するべきメトリック • API サービスの性能監視：RED Method ◦ Request Rate：単位時間あたりのリクエスト数 ◦ Error Rate：単位時間あたりのエラー数 ◦ Duration of request（Latency）：エラーを除いた正常応答のレイテンシー ※ システム上は正常なレスポンスを返していても、（誤ったコンテンツが返るなど） 　ユーザーから見て期待する結果とは限らない点に注意 23
24. 複数のメトリックを紐づけた理解 • A：ゲートウェイで受けたリク エストがバックエンドに到達し ているか？ • B：ゲートウェイで受けたリク エストがバックエンドで処理さ れているか？ • C：イベントが正しく処理され ているか 24 Order service Order database Fee service Fee rules database Market service イベントキュー イベントキュー ゲートウェイの リクエスト数 Order service のリクエスト数 イベント発行数 fee service の リクエスト数 A B C
25. メトリックの表示方法 • ゲージ：一般的な数値データ → 折れ線グラフで表示 ◦ DB 接続数、メモリ使用量、CPU 使用量、異常停止中のコンテナ数など • カウンター：短調増加する数値データ → 折れ線グラフで表示 ◦ リクエスト総数、エラー総数、送受信バイト数など • ヒストグラム：値の分布に意味があるもの → ヒストグラムで表示 ◦ レイテンシーの分布、レスポンスのサイズなど 25 • SRE が表示内容を自由にカスタマイズできるダッ シュボードが必要 • ビジネスアナリストによるサービス利用状況の分 析からシステム上の問題が発見される場合もある
26. アラート設定のテクニック • 緊急度に応じた通知方法 ◦ 即時呼び出し、対応依頼チケットの発行、記録のみなど • 必要なアラートに限定する ◦ SLO に影響するエラー ◦ 問題が発生していること（正常状態では発生し得ない状況）を示唆するデータ ▪ プログラミングにおける Assertion のようなもの ▪ 複数のメトリックの相関にも注意する ◦ 即時対応が必要ないものは、アラートではなくチケットを発行する ◦ 「アクション可能でないアラート」は通知しない 26
27. 11. ロギングとトレーシング
28. モノリスのトレーシング • 基本的には、単一のアプリケーションログを追えばよい • データベース、ネットワーク、OSなどのログは、それぞれ個別に確認 28 アプリケーションログ データベースログ OS ログ
29. マイクロサービスのトレーシング • 複数サービスのログを個別に確認するのは現実的ではない • さまざまなコンポーネントのログを集約して検索できるロギングシステムが必要 29
30. ログに含めるとよい情報 • タイムスタンプ（UTC 表記 + タイムゾーン） • ID：リクエスト ID、ユーザー ID などシステム全体でユニークな情報はできる限り含める • ソース：ホスト、クラス、モジュール、関数、ファイル名など • レベルとカテゴリー：ERROR、DEBUG、INFO、WARN など 30
31. ログの形式 • 人間がそのまま読める点と機械 で処理できる点のメリットを考 えると JSON がベスト • 個人情報など、「収集してはい けない情報」にも注意する 31 { "source_host" : "e7003378928a", "pathname" : "usrlocallibpython3.6site-packagesnamekorunners.py", "relativeCreated" : 386.46125793457031, "levelno" : 20, "msecs" : 118.99447441101074, "process" : 1, "args" : [ "orders_service" ], "name" : "nameko.runners", "filename" : "runners.py", "funcName" : "start", "module" : "runners", "lineno" : 64, "@timestamp" : "2018-02-02T18:42:09.119Z", "@version" : 1, "message" : "starting services: orders_service", "levelname" : "INFO", "stack_info" : null, "thread" : 140612517945416, "processName" : "MainProcess", "threadName" : "MainThread", "msg" : "starting services: %s", "created" : 1520275329.1189945 } システムから取得できる情報を 自動で付加するツールもある
32. メトリックとログの違い • メトリックはモニタリング用のダッシュボードに表示 • ログは、ログ管理システムに集約 32
33. （参考）kubernetes 環境でのログ収集 • 各サービスは、標準出力にログを書き出す • ホスト上のエージェントが集約して、ログ管理サーバーに転送 • Elastic Search + Kibana （Google Cloud なら Cloud Logging）で検索、表示 33
34. ログのトレーシング • 複数サービスが関連する処理をリクエスト ID で 紐づけて、ビジュアライゼーションするツールを 利用 ◦ スパン：ネストしたコールのツリー ◦ トレース：各コールの処理時間の時系列図 • ビジュアライゼーションに必要な情報を自動的に ログ出力するツールが必要 ◦ Jaeger: https://www.jaegertracing.io/ ◦ Google Cloud なら OpenCensus + Cloud Tracing 34
35. プロダクション環境の構成要素 35 • プロダクション環境のインフラ構成にも標準化・自動化が必要 プロダクション モニタリング システム ネットワーク 管理システム サービス実行環境 デプロイメントパイプライン ランタイム（VM、 コンテナなど） ロードバランサー、 DNS など デプロイメント ツール 開発ツール
36. （参考）Microservices chassis との統合 • Microservices chassis：マイクロサービスのデプロイに必要なコンポーネントをすべてイ ンテグレーションした「標準デプロイ環境」 • アプリケーション開発者は、所定のツールセット（ライブラリ）を使用することで、透過 的に利用可能 • Microservices chassis と統合されたデプロイメントパイプラインが理想 　※ 現状は、Jenkins / Spinnaker などの自動化ツールとクラウドサービスを組み合わせて、 　　段階的に実装するのが現実的 36
37. Thank You.