こちらは、Livesense Adventcalendar 2021 19日目の記事です
こんにちは、かたいなかです。最近、マイクロサービスで構築されたシステムをインフラの運用を破綻させずにスケールさせていくために必要なことをずっと考えています。
自分のための備忘録も兼ねてマイクロサービスを破綻させずにスケールさせていくためにSREの観点で使う技術に関係なく最低限必要だと考えていることをポエム記事としてまとめてみます。
問題
システムが巨大になってくると、マイクロサービスの数や関わるエンジニアの数に比例してインフラの運用工数が増えていきます。インフラの運用工数が増え続けると、いずれサービスレベルの低下やインフラ作業のリードタイムの増大に繋がり、システムの品質や開発効率に悪影響を及ぼします。
この問題に対処するために、運用工数の増大に対してスクリプトによる自動化等で工数を減らすというのがよくある打ち手ですが、マイクロサービスごとに構成が異なったりするとに簡単に自動化できなかったりします。 そんなふうにして自動化が遅れていると、最終的に自動化によって運用工数が減るペースよりもシステムの成長に伴って運用工数が増えるペースのほうが大きくなり、自動化による解決が難しくなります。 そうすると、自動化ではなく抜本的にシステムを作り変え解決を図るのですが、これもシステムの大きさが大きくなればなるほど移行完了までかかる時間がかかることになり、ビジネスに対する影響が大きくなってしまいます。
個人的な経験でも、このような状態に陥りながらも運用エンジニアのがんばり等でなんとかシステムを動かし続けているシステムは世の中に沢山存在するのではないかと思っています。
そのような状態に陥ってしまうのをできる限り避けるにはどのようにしたら良いでしょうか？
こうしたらいいんじゃないかと思っていること
上記のような問題はよくある問題だと思いますが、個人的にこのような問題に対処するにはSREの観点では以下のような対策が必要ではないかと思っています。
トイルの量の計測
システムの標準化
作業の自動化・運用のセルフサービス化
それぞれについて具体的に書いていきます。
トイルの量の計測
なによりもまず運用コストがどの程度なのか計測する必要があると思っています。計測することにより、トイルが増えすぎて改善に手が回らない手遅れの状態になる前に改善に向けた施策を検討することができるようになります。
計測には例えばtogglのようなツールにより計測したトイルにかかっている時間やトイルに分類されるチケット数を用いることが考えられます。また、開発者自身が行っている作業の中でもトイルとなっている作業があるかもしれないため、開発者サーベイ等の結果も併用すると良いでしょう。
測定した値をインフラチーム内で定期的に共有し、どのような種類のトイルがあるか等を定期的に分析すると良いでしょう。トイルを減らすにはどうしたらよいか優先的に自動化するべきタスクはどれかなどSRE内部で定期的に議論する場を設定します。トイルの量が増えすぎた場合には運用を破綻させないために行う作業の量を制限する必要があるかもしれません。
システムの標準化
マイクロサービスごとに構成に大きな差分があるとシステム全体の認知コストが大きく増大します。認知コストが大きいシステムは自動化やセルフサービス化等の取り組みを行うのが難しくなります。 そのため、なるだけ自然に標準的な構成に従えるようなしくみを準備する必要があります。
標準的な構成等について書かれたドキュメント等はどのシステムにもあると思いますが、個人的にはそれだけでは不十分だと考えています。マイクロサービスの場合、特に複数のチームのエンジニアが関わることになりドキュメントへの準拠を担保できなくなるためです。
たとえば、Terraformを使用して運用している場合にはlint, tfsec, モジュール機能等を使用し、可能な限り自然に標準に従えるようにし、違反した場合には自動で検出できるような仕組みを考えていく必要があります。
このとき、すべてのシステムを標準に合わせようとすると無理が出てくるため、8~9割程度を標準でカバーし残りの1割を個別運用するようにすると現実的かと思います。
作業の自動化・運用のセルフサービス化
システムの成長に伴って増えていくトイルに対して、まず浮かぶ対策はスクリプト化等による自動化です。また、システムの構成変更やクラウドサービスの新機能の導入等により作業自体を不要にしてしまうこともできるかもしれません。
このような自動化を行っていく中で、開発に必要な作業は可能な限りインフラに依存せずセルフサービスで行えるようにしていく必要があります。開発者自身がオーナーシップを持って運用していくことは高品質なシステムを構築する上で不可欠です。また、インフラエンジニアの数はアプリケーション開発者の数に比べて限られているため開発者側で行える作業はセルフサービスで行ってもらうことが合理的です。
このようなセルフサービス化の対象には、新バージョンのデプロイや環境変数の修正、エラー調査に必要なログの取得や新しいマイクロサービスのデプロイやマイクロサービスごとのダッシュボードの作成、まで様々な作業が含まれます。
このようなセルフサービス化に伴いSLOや権限の管理等でガードレールを設けていく作業も同時に行うことで品質やセキュリティの担保も行っていくとよいでしょう。
個人的にはセルフサービス化等により先回りして開発者の作業が快適に行える環境を作っていくことこそSREの仕事なのではないかと思っています。
雑感
個人的にはトイルの増大に早めに対処していくことこそがSREの本質だと思っています。
SRE本ではトイルの量を工数の50%に抑える必要性が述べられています。最初読んだときにはやりすぎではないかと思っていたのですが、最近様々なシステムに関わることが増えるにつれて運用が個人の頑張りに依存せず持続可能な状態を維持していくためには現実的に必要な対処ではないかと思っています。
