复习《微服务模式》第11章-横切关注事项

在第11章中，我们将开展能够承受真实环境的服务的开发工作。

• 機能要件とは別に、サービスを成り立たせる上で必要な横断的関心事の話

• 横断的関心事とは、セキュリティ、設定可能性、可観測性とされている

横断的関心事はたくさんあるので、それらをある程度まとめて扱える、マイクロサービスシャシーや、その派生であるサービスメッシュについての説明

安全

• セキュリティの主要な4要素：認証、認可、監査、セキュアな通信

ここでは認証と認可をとりあげる

モノリシックでの認証

HttpSessionや、それよりも少し上位のセキュリティコンテキストAPIなどが認証情報の保持に使われる
どちらも1プロセス限定あるいは、プロセス間で共有しても密結合になる
マイクロサービスには向かない

マイクロサービスでの認証

これは入口となるAPIゲートウェイで行うのがよい

マイクロサービスでの認可

これはサービスの詳細が必要なので、各サービスで行うのがよい

マイクロサービスとOAuth2.0

ここの部分の説明は全体的に賛同しかねる
イマイチな点：OAuthなのにパスワードグラントをベースにしている（通常は非推奨）
JWTにユーザーの情報を全部入れるのがいいというのも、この辺はトレードオフがあって、検証しようとすると結局別サーバーへの同期通信が発生するし、情報を入れすぎるのは個人情報漏洩という意見もあるので、識別子型のアクセストークンが採用される場合もあるらしい。

设定的可能性

• 設定情報をいかに外出しするかの話

• 別サービスにhttpアクセスするならホスト名が必要、kafkaでメッセージングするならkafkaのネットワーク位置、DBにアクセスするならDBのパスワードなどが設定情報として必要

• プッシュ型の外部設定

起動時のコマンドラインオプションや環境変数で、設定情報あるいは設定情報ファイルのパスを渡すやり方
メカニズムとしてはシンプル
ただしマイクロサービスのようにプロセスがたくさん立ち上がるアーキテクチャだと、それぞれのプロセスの起動コマンドに渡せるようにしなければいけない

プル型の外部設定

設定サーバーを立てて、そこを参照しにく
AWS Parameter Storeのような専用なものもあれば、DBサーバーやgitなども選択肢に入る
一元化、暗号化、動的再読込など便利と言えば便利
一方で、お守りの必要なサーバーがまた一つふえるという大きな欠点も。
設定サーバーへのアクセス情報だけは、push型にしないといけない

可观测性

• さまざまな観測について。

• health checkパターン

みんな大好きhealth check。
zabbixなどから、サービスの死活管理しましょう
helth checkでどこまで監視するかは、開発者次第

Log Aggregation

マイクロサービスは複数プロセス、複数ホストで動いて、デバッグしづらいので、まずは一箇所にログを集めましょう
集めたログはElastic Searchなどで解析

Distributed Tracing

単にログを集めただけではできないこと：スタックトレースの表示
ではどうするか

APIゲートウェイで外部からのリクエストにトレースIDを振る
APIが自身の処理には、スパンIDを振る
サービスへの呼び出しを行う際には、トレースIDとスパンIDを伝搬する
呼ばれたサービスが、別のサービスを呼び出すさいも、同じことを行う
各サービスは、都度、分散トレーシングサーバーに情報を送る

上記は手書きだと大変なので、AOPで透過的に行う
分散トレーシングサーバーとしては、zipkinというのが有名らしい
トレースIDやスパンIDなどを渡すHttpヘッダは標準化されている

Application Metrics

メモリ使用量、CPU利用率など、OSやVMレベルの情報
オーダー数、キャンセル数などアプリレベルの情報
AWS Cloudwatchは、プッシュモデル
Prometheusは、プルモデル
個人的には、必要なときにcurlなどで読めるプルモデルの方が良さそうな気もする

Exception tracking

通常のログは単一行出力にしておいて、例外ログは別で記録した方がいいよという話
HoneyBadgerというライブラリを使うとログを拾って、サーバーに送って、issue管理にチケットまで作ってくれる
通常ログと例外が一緒に出ている方が時系列が分かりやすくて便利じゃない？という意見もある

Audit logging

実現手段が3つある

手書き
AOP
イベントソーシング

個人的には監査ログは、ビジネス要件が絡むので手書きな気がする

微服务架构和服务网格

• マイクロサービスシャシーは、各サービスのプロセス内で動作するライブラリとして以下を行う

外部設定
ヘルスチェック
アプリメトリクス
サービスディスカバリ
サーキットブレイカー
分散トレーシング

マイクロサービスシャシーは、プロセス内で動くので、Java用、Node用などテクノロジスタックに合わせる必要がある
サービスメッシュ

シャシーで実現するうちのいくつかを、サービスから独立したネットワークレイヤーとして実現する
テクノロジスタック非依存になるし、各サービス内で動作するものが減るでの作りとしてもシンプルになる
といっても目立ったところはサービスディスカバリやサーキットブレイカーで、ほかはある程度サービス側でもやらないと成り立たない。
最近よく聞く、istioはサービスメッシュの一つ

总结

• この章で紹介された横断的関心事は多かれ少なかれ、ほとんどのサービスで必要になるのは分かる

• サービスシャシーやサービスメッシュを導入すれば、その多くをまとめて面倒を見てくれるのが便利なのも分かる

• とはいえ、サービスシャシーやサービスメッシュの使い方を覚えて、実際に障害発生時に対処できるくらい熟練するには多くの時間を要するでしょう

サービス作るのは大変だ