Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lecture course on Microservices : Part 3

Lecture course on Microservices : Part 3

Etsuji Nakai

February 06, 2024
Tweet

More Decks by Etsuji Nakai

Other Decks in Technology

Transcript

  1. プロダクション環境の構成要素 4 • サービス実行環境(Kubernetes など)に加えて、CI/CD パイプライン、ネットワーク管 理、モニタリングシステムなどの構築が必要 プロダクション モニタリング システム

    ネットワーク 管理システム サービス実行環境 デプロイメントパイプライン ランタイム(VM、 コンテナなど) ロードバランサー、 DNS など デプロイメント ツール 開発ツール
  2. マイクロサービス環境におけるデプロイメントの特徴 • 小さな変更(← マイクロサービスのメリット) ◦ リリース時の変更量を小さく保つ事で、起こり得る問題を予測可能にして、リリース に伴うリスクを減らす • マニュアル作業の限界 ◦

    リリース頻度を考慮すると、伝統的なマニュアル作業はスケールしない • 自動化によるプロセスの一貫性の担保 ◦ 静的コードチェック、単体テスト、統合テストなど、デプロイメントに必要なプロセ スを自動化することで、変更の大小にかかわらず、すべてのマイクロサービスに一貫 性を持った手順を適用する 5
  3. デプロイメントの課題 • 安定性の実現 ◦ マイクロサービスの追加や機能変更が頻繁に行われる環境で、安定的にサービスを提供 しつづけるには何が必要か? • Testing in production

    ◦ プロダクション環境でなければテストできない内容をどのように取り扱うか? • 依存関係の管理 ◦ マイクロサービス間の依存関係により、ビルドやリリースが独立して実施できなくなる 状況をどのようにして避けるか? • マイクロサービスの撤収 ◦ 利用されなくなったマイクロサービスを発見・撤収する方法は? 7
  4. デプロイメントプロセスのゴール • Safety at pace : デプロイのスピードと安全性を両立。デプロイメントの各ステージに適 切な Validation プロセスを実装すること

    • Consistency : サービスの種類(技術スタックなど)に依存しない、「予測可能」でス ケーラブルなプロセスを提供 8 ソース コード コード レビュー ビルド 単体テスト ステージング デプロイ 統合テスト プロダクション デプロイ Artifact Repository Code Repository ステージング環境 プロダクション環境 Testing in production
  5. Consistent (予測可能)ではないプロセスの例 9 • プロダクション環境でこれをやると、どのような問題が・・・? インスタンスごとに異なる コミットのコードが使われる 仮想マシン App ロードバランサー

    仮想マシン App 仮想マシン App Code Repository スタートアップスクリプト でコードをダウンロード・ 自動インストール リポジトリのタイムライン 仮想マシン1 仮想マシン2
  6. アーティファクトの管理 10 • ソースをコミットした後にビルドプロセスを実行することで、デプロイメントに利用する 「アーティファクト」を生成する • アーティファクトは、Immutable で Deterministic でなければならない

    ◦ 同じコミットからビルドすれば、必ず同一のアーティファクトが生成される • アプリケーションバイナリだけではなく、 その実行に必要となるすべてのコンポーネ ントをアーティファクトして管理する必要 がある ◦ 依存ライブラリー、(スクリプト言語 の場合)インタープリター、ロギング ツール、etc... ソース コード Artifact Repository Code Repository アーティファクト ビルド プロセス ステージング/ プロダクション デプロイ
  7. デプロイ環境の違いを構成ファイルで管理 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 環境ごとに 構成ファイルを用意
  8. コンテナを用いる場合 12 • アーティファクトとしてパッケージングする範囲は、ランタイムの選択(物理ホスト、仮想 マシン、コンテナ等)によって変わる • ランタイムとしてコンテナを用いる場合は、下図のようなデプロイメントモデルが標準的 仮想/物理マシン コンテナ アプリケーション

    バイナリー ・・・ Container Registory アプリケーションバイナリーを 含むコンテナイメージをデプロイ コンテナクラスター コンテナ スケジューラー 仮想/物理マシン 仮想/物理マシン 仮想/物理マシン Service A Service B コンテナスケジューラーが サービスの配置を決定 コンテナイメージを Pull
  9. Kubernetes のメリット • Kubernetes のようなコンテナ専用のクラスター管理基盤を利用することで、次のような メリットが得られる ◦ デプロイ環境の標準化(プロダクションとステージングの構成を同一に保つ) ◦ カナリアリリース、Blue-Green

    デプロイメントなど、Continuous Delivery の手法 が利用しやすくなる • ステージング環境の構成には、いくつかの選択肢が考えられる ◦ すべてのサービスをデプロイ ◦ サブシステムごとに関連するサービスだけをデプロイした個別の環境を用意 13
  10. カナリアリリースによるローリングアップデート 14 • コンテナを用いることで、ローリング アップデートや Blue-Green デプロイ メントなどの手法が利用しやすくなる • 問題発生時は、即座にロールバックを

    実施 ◦ デプロイだけでなく、ロールバッ クも自動化が必要 ◦ フィーチャーフラグも活用 v1 v1 v1 v2 v2 一部のトラフィック を v2 に向ける メトリックを比較して、 v2 の安全性を確認する v1 v2 v2 v2 v2 段階的に v2 の 割合を増やす
  11. フィーチャーフラグの活用 • 新しい機能を追加する際に、その機能を on / off するためのフラグを用意しておく • 問題発生時は、ロールバックする代わりに、該当機能を off

    にする設定ファイルの再デプ ロイのみを行う(設定ファイルもコードの一部として、リポジトリで管理する) • 複数のサービスにまたがる機能の場合、サービス間で設定の不整合がおきないように注意 が必要 15 ◦ 設定ファイルの代わりに、 Feature store / Feature service を用いる方法もある Feature store Customer service Order service 設定 on/off 設定取得 Customer service Order service Feature service Feature store 設定取得
  12. Dark launch の活用 • 既存バージョンと新バージョンの 両方を並行稼働して結果を比較 • エンドユーザーには新バージョン の結果は見せない •

    ML モデルのデプロイでよく利用 される手法 16 API ゲートウェイ ML v1 service ML v2 service リクエストを 複製して転送 v1 からの レスポンスのみ利用 Prediction log それぞれの 処理結果を比較
  13. アーティファクトリポジトリを用いた自動化プロセス 17 ソース コード コード レビュー ビルド 単体テスト ステージング デプロイ

    統合テスト プロダクション デプロイ Artifact Repository Code Repository ステージング環境 プロダクション環境 ビルド済みの バイナリーを保存 テスト済みの バイナリーをデプロイ テスト結果 を記録 テスト結果 を記録 コードのコミットをトリガーにして 単体テスト/統合テストまでを自動化 プロダクション環境へのデプロイ (カナリアリリース/Blue-Green デプロイメント) Testing in production
  14. 必ず収集するべきメトリック • API サービスの性能監視:RED Method ◦ Request Rate:単位時間あたりのリクエスト数 ◦ Error

    Rate:単位時間あたりのエラー数 ◦ Duration of request(Latency):エラーを除いた正常応答のレイテンシー ※ システム上は正常なレスポンスを返していても、(誤ったコンテンツが返るなど)  ユーザーから見て期待する結果とは限らない点に注意 23
  15. 複数のメトリックを紐づけた理解 • A:ゲートウェイで受けたリク エストがバックエンドに到達し ているか? • B:ゲートウェイで受けたリク エストがバックエンドで処理さ れているか? •

    C:イベントが正しく処理され ているか 24 Order service Order database Fee service Fee rules database Market service イベントキュー イベントキュー ゲートウェイの リクエスト数 Order service のリクエスト数 イベント発行数 fee service の リクエスト数 A B C
  16. メトリックの表示方法 • ゲージ:一般的な数値データ → 折れ線グラフで表示 ◦ DB 接続数、メモリ使用量、CPU 使用量、異常停止中のコンテナ数など •

    カウンター:短調増加する数値データ → 折れ線グラフで表示 ◦ リクエスト総数、エラー総数、送受信バイト数など • ヒストグラム:値の分布に意味があるもの → ヒストグラムで表示 ◦ レイテンシーの分布、レスポンスのサイズなど 25 • SRE が表示内容を自由にカスタマイズできるダッ シュボードが必要 • ビジネスアナリストによるサービス利用状況の分 析からシステム上の問題が発見される場合もある
  17. アラート設定のテクニック • 緊急度に応じた通知方法 ◦ 即時呼び出し、対応依頼チケットの発行、記録のみなど • 必要なアラートに限定する ◦ SLO に影響するエラー

    ◦ 問題が発生していること(正常状態では発生し得ない状況)を示唆するデータ ▪ プログラミングにおける Assertion のようなもの ▪ 複数のメトリックの相関にも注意する ◦ 即時対応が必要ないものは、アラートではなくチケットを発行する ◦ 「アクション可能でないアラート」は通知しない 26
  18. ログに含めるとよい情報 • タイムスタンプ(UTC 表記 + タイムゾーン) • ID:リクエスト ID、ユーザー ID

    などシステム全体でユニークな情報はできる限り含める • ソース:ホスト、クラス、モジュール、関数、ファイル名など • レベルとカテゴリー:ERROR、DEBUG、INFO、WARN など 30
  19. ログの形式 • 人間がそのまま読める点と機械 で処理できる点のメリットを考 えると 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 } システムから取得できる情報を 自動で付加するツールもある
  20. ログのトレーシング • 複数サービスが関連する処理をリクエスト ID で 紐づけて、ビジュアライゼーションするツールを 利用 ◦ スパン:ネストしたコールのツリー ◦

    トレース:各コールの処理時間の時系列図 • ビジュアライゼーションに必要な情報を自動的に ログ出力するツールが必要 ◦ Jaeger: https://www.jaegertracing.io/ ◦ Google Cloud なら OpenCensus + Cloud Tracing 34
  21. プロダクション環境の構成要素 35 • プロダクション環境のインフラ構成にも標準化・自動化が必要 プロダクション モニタリング システム ネットワーク 管理システム サービス実行環境

    デプロイメントパイプライン ランタイム(VM、 コンテナなど) ロードバランサー、 DNS など デプロイメント ツール 開発ツール
  22. (参考)Microservices chassis との統合 • Microservices chassis:マイクロサービスのデプロイに必要なコンポーネントをすべてイ ンテグレーションした「標準デプロイ環境」 • アプリケーション開発者は、所定のツールセット(ライブラリ)を使用することで、透過 的に利用可能

    • Microservices chassis と統合されたデプロイメントパイプラインが理想  ※ 現状は、Jenkins / Spinnaker などの自動化ツールとクラウドサービスを組み合わせて、   段階的に実装するのが現実的 36