振り返り、SRE、自動化

去年の後半あたり、SRE 本を読んだ。

買ったのは、翻訳本の発売すぐだったので、だいぶ前なのだけど、その当時はあまり面白いと思えずに読むのをやめてしまったのだと思う。そのあと、所謂、インフラエンジニアというロールになるのを意識し始めて、クラウド（AWS）を使って、システムの構築や運用をする経験を積んでいった。

AWS のたくさんあるサービスを調べて、小さなスタートアップのシステムを効率よく構築・運用するにはどうしたらいいかを考えた。構成管理を行い、 CI/CD の仕組みを整えた。途中から、社内でマイクロサービスの波が来たので、基盤のようなものが必要だと考えて、ロギングやモニタリングの横串の仕組みを整えたりした。

そういったの経て、 SRE 本を読んだのもあると思う。また、直近で Kubernetes に触れる機会があったのも大きいと思う。SRE 本を読んで、面白い、わかる、と少し感じられるようになった。

自律的なシステム

SRE 本では、自動化にはレベルがあるといっていて、最もハイレベルなものは自律的なシステムだといっている。 これまで自分は、自動化というと、Terraform や Ansible なもので構成管理をしたり、特定の目的のスクリプトを組んで流したりする、そういうものが一番に頭に浮かんでいた。 自律的なシステムは、外部ではなく内部に仕組みを持ち、自己修復性を持ち、正しい状態に収束するように動く。Kubernetes の Operator は、まさしくそういうものだと思うし、クラウドネイティブ全体がそういうパラダイムと言えるかもしれない。

この話は、冪等性、中央集権 vs 分割統治、また、 push型 vs pull型などいろんな話題を含んでいるように思える。いずれにせよ、ソフトウェアエンジニアリングというのは、すこし見方を変えると、硬直的だったものが柔軟でスケーラブルなものに変わったりするのが面白い。 また、壊れることを前提に考えるというのも重要だ。そうすると壊れにくいものができる。壊れるものをコントロールするには、ソフトウェアを書く、ということが必要になる。

SRE は、自動化のためにエンジニアリングに注力する。これは、元々アプリケーションを書いていた自分にとっては、ポジティブなことに感じる。コードを書くのは楽しい。コードを書くことで、システムをコントロールして、スケーラブルな仕組みを作る。 実際には、すごく高度な自律性のあるシステムを組むということは、今の自分の状況だと稀だろう。でも、ちょっとした glue コードを書く、何かのイベントに反応してシステムの状態を柔軟に変える、とか明日からやっていけることは多くある。

話はすこし逸れて、Go という言語。最近は、だいぶ手に馴染んできたなと感じる。 小さなバイナリになり、デプロイしやすい。安定的に動く。リソース消費も小さい。標準ライブラリも充実している。小さなスクリプトを書くこともできるし、サーバを書くこともできる。システムを扱うようなエンジニアにとっては、かなり理想に近い言語なのではないかと思う。 クラウドネイティブ関連の OSS を見ていると、多くは Go で書かれているので、そういったときに躊躇なくコードが読める、というのも非常に大きい。

共通基盤をつくる

基盤というものについて。今の自分の仕事の一つが、アプリケーションを効率的に、開発・運用するための基盤を作ること、だと思っている。 本番運用できるシステムというのは、それなりに考慮しておかないといけないことがある。それはスタートアップの小さなシステムであっても。モニタリング、ロギング、セキュリティ、守っておかなければならないものがある。 歴史を重ねてくると、運用するサービスは増えていく。新しいプロダクトも立ち上がる。そういった中で、あるサービスを効率的にプロダクションレディに持っていくにはどうしたらいいか、あるいはプロダクションレディだと自信を持つにはどうしたらいいか、と考える。一つの方法が、共通基盤をつくってそこに乗せるというやり方だと思う。

ある程度はうまくいっていると思う。一方で、迷いも多くて、自分が考えた基盤は正しい設計だったのか、正しい技術選択だったか、不安になることもある。また、その基盤が硬直性を生んでいるのではないか、使う側の自由を奪っていないか、そうのもある。 クラウドは、プリミティブなものから、どんどん抽象化されてアプリケーションの課題を解決するために洗練されてきている。特にサーバレスの文脈でそう思う。 基盤を作るというは、そういう状況の中で、足りないものを埋める、あるいはあえて制約を課す、ということだと思う。時代と要求に合わせて、拡張する、あるいは消える、ということをしていかなければならない。アプリケーションエンジニアが、必要としているコンポーネントを使える状況を作っておく。その上で信頼性の高いシステムになるようにする。

アプリケーションのパラダイムも知っておくこと、クラウド技術のパラダイムも知っておくこと、両方が重要だと思うが、それは楽しいことだとも思う。

これから

大きな組織の SRE の話を聞くとやっていることのレベルが違いすぎて圧倒されることはある。まあ、自分で SRE を名乗ったことはないのだが、先人たちの偉大なプラクティスを、自分なりに噛み砕いて実践していくことには価値があると思っている。

最近自分は、「コントロール」という言葉を意識的に使うようになった。サービスが増えていくとだんだん詳細は把握できなくなっていくし、昔のことは忘れてしまったりする。権限移譲も行っていく必要がある。そういう中で、システム全体に自信を持つにはどうしたら良いか、コントロールできている、という意識を持つにはどうしたら良いか。正しく動かすにはどうしたら良いか。 小さなチームで、大きなシステムを扱えるようにするというのは、エンジニアリング、なのだと思う。