プロダクションレディマイクロサービスを読んでみた

書籍を読んだものの、読みっぱなしになっていたので気づいた点をメモしておこうと思う。

動機

• 所属先ではSREプロジェクトが立ち上がりジョインしているが、具体的に何をするのかよくわかっておらず勉強し始めた次第。
• コンテナを用いた開発・本番運用が組織内で本格化している。
• モノリシックなアーキテクチャからマイクロサービスへの転換が起こり始めている。

感想

大規模サービス向けに書かれている内容が多いです。 そのため、求められる基準がかなり高い。

私はスタートアップ系のため、うーん。ただ学ぶことは非常に多い。 これが全てできるようになったら大企業が行なっている品質基準を満たすことができるということがわかった。

これから少しずつ対応していきたい。

書籍でも対応するのに数年かかると言っている。焦らずに地道に対応して行くしかないですね。

思ったことについて、それぞれの項目の中で書いた。

概要

マイクロサービス化をした（あるいは、これからする）ものの、本番環境で利用するには何をすべきかについて 8つの評価基準を設けて、それについて語っているものです。

また、これとは別に可用性という９つ目の指標があるが、これについては８つの基準を満たすことで高い可用性を保つことができると言われている。

• 安定性 (Stability)
• 信頼性 (Reliability)
• スケーラビリティ (Scalability)
• パフォーマンス (Performance)
• 耐障害性 (Fault Tolerance)
• 大惨事対応 (Catastrophe Preparedness)
• 監視 (Monitoring)
• ドキュメント (Documentation)

8評価基準に対するメモ

安定性

変更によるマイナスの影響を緩和するための施策が用意されていること

安定したデプロイ　

開発環境 -> ステージング -> カナリア --> 本番

デプロイによる影響を最小限に抑える。また問題が発生しても自動的にリカバリーする仕組みが有ると良い。 カナリア：本番環境の2-5％程度のトラフィックを処理させて変更内容を検証する環境をいうらしい。しばらく、この環境で運用し問題がなければ本番環境にデプロイする流れ。

デプロイに失敗した場合に自動的にロールバックする仕組みが有ると良い。

所感

カナリア環境はないので、へぇー！と思った。用意してみたい。 また、デプロイ成功したんだけど、その後の継続的なヘルスチェックで失敗したらロールバックさせる仕組みが有るといいなと思った。

信頼性

• クライアントやステークホルダーからみて安心して使えるマイクロサービスであることに対する基準
  • テストがしっかりされている
  • 安心、確実なデプロイ

クライアントはマイクロサービスを使っている別のマイクロサービスという意味も有るかも。

所感

•  テストはしてるけど、十分にできているかは疑問が湧いた。今までと違った観点でのテストが必要かもしれない。

スケーラビリティ

タスクをどのように分割統治するか

並行性、パーティション分割

• トラフィックの増加に簡単に対応できる
  • できないと , レイテンシ増加、インシデント、機能停止に繋がる。
• 質的な成長、量的な成長の二つの判断基準を明確にする
  • 質：ページビューなど
  • 量：毎秒何リクエストまで処理可能かなど
• データ格納、処理する方法もスケーラブル
• 急激なトラフィック増大（バースト処理）に対応できる

アーキテクチャのレビューを行うことでどこに問題があるか分かるらしい。

所感

• ウィークポイントな気がする。書きたいことがいっぱいありすぎる。

パフォーマンス

マイクロサービスがタスクをどれくらい効率よく処理しているか

• 非同期処理によりパフォーマンス・スケーラビリティ向上ができるのに同期処理にしている ... 改善必要
• コストが高い通信などの処理を大量に行なっている .. SQLの大量発行とか？
• CPU,メモリなどのリソース割り当てを富豪的に使っている ... お金の無駄遣い？ (コストパフォーマンス？）

所感

• ウィークポイントな気がする。アプリケーション内の処理で改善できることがたくさんありそう。

耐障害性 / 大惨事対応

機能停止、インシデントが発生した場合の対処が行われている

それらが自動的に繰り返し、ランダムでテストされている

障害の検出と修正

新たに見つかったら、テストスイートに追加する

1. 障害発生のシナリオを明らかにする
2. 戦略を練る
3. 計画を立てる

計画を立てて終わりだと、あまり意味がない。避難訓練みたいに実際にやってみることが大事。

データセンターがダウンしたことを想定し、あるリージョン上のインスタンスを強制的にダウンさせてみるなど。

アーキテクチャレビューを重ねることで、色々問題点が分かるみたい。 基本的にはSPOF(Single Point of Failure)を排除して行くことが課題になりそうだ。

やってみること

回復性テスト

• マイクロサービスエコシステム、インフラに強制的に障害を発生させてテストする
• コードテスト
• ロードテスト
• カオステスト
  • 本番環境で障害シナリオを実行する。（ランダム＆スケジュールされている）
  • 全ての障害シナリオに対応できることを証明し続ける。
  • Netfilixがやってると言われているテストでしょうか？

負荷テスト

トラフィックの急激な変化にどれだけ耐えられるか明確化する。また耐えられなくなった場合の対応措置を明確化する

手に負えない場合のシナリオ

どうしようもない場合に、何をすべきか決めておく。

連絡先の共有とかでしょうか？

所感

• カオステストやってみたい。

監視

ロギング

必要な情報に簡単にアクセス、検索できることが重要らしい。 最近だと ElasticSearch , Kibanaとか？

必要な情報の定義が難しい。自分の解釈では問題が発生した際に再現をしなくてもログだけで原因がわかり修正ができる。ということかな。 再現できる不具合ばかりではないため。

GUI

dashboardとかの話。 サービスが健全で有ることがすぐ分かること。エンジニアでなくても見て分かることが重要らしい。 見せ方重要ですね。

アラート

効果的でアクション可能な主要メトリックに基づくアラート

障害の検知はアラートで行う。ダッシュボードを見ないとわからない・・・というのはよくないらしい。

• 正常 , 警告、危険の3種類のアラートが有ると良いみたい。

所感

だいたいできてるのかな。ただ改善点は有る。

ドキュメント

• 一元管理
• 簡単にアクセス、検索できることが大事。

所感

ドキュメントはいくつかの場所に散在しちゃってて、改善したいと思ってました。

その他

• マイクロサービス間の通信について
  • RPC(リモートプロシージャコール）を介したやりとり ... 非同期
  • REST APIによるやりとり ... 同期

マイクロサービスエコシステムの4層モデル

layer	/	対象	備考
4	マイクロサービス
3	アプリケーションプラットフォーム
2	通信	サービス間の通信。DNS, RPC, API サービス検出、サービスレジストリ、負荷分散
1	ハードウェア	Machine, OS , Docker,...

アンチパターン

• APIをバージョニングすること

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化