こんにちは。エンジニアの佐々木です。
Monthly hyggeと呼んでいる、月に一回開催している社内勉強会があるのですが、1月末にこんな↓ゴールとテーマで話をしました。
2020年でやってきたことをじっくり振り返り、これからの課題もメンバーと共有できたので、ここでも公開しておこうと思います。
1. SREって?
2. 2020年を軽く振り返る
3. 2021年の課題
4. その先は
そもそも、SREとは?
サイトリライアビリティエンジニアリング(SRE)とは、Googleで培われたシステム管理とサービス運用の方法論です。Goowww.oreilly.co.jp
(みなさんもきっとご存知のこちらの本、僕も途中で挫折しつつも大切に読んでいます)
SREは高速道路
先日クラシコムに興味をもってくださったエンジニアの方とお話ししたときにお伝えした内容なのですが、SREとは車が安全にスピードを出して運転ができるように高速道路を整備するようなものだと思っています。
(高速道路という例えは、以前どなたかの資料を読んだときにその例えが挙がっており、そこからインスパイアされています。どの資料だったかは失念してしまいました…)
2020年、ものすごくいろいろやったな・・・
2020年に取り組んだことのなかで、特に思い出深いのは負荷試験です。
なかなかやれる機会が多いタイプの仕事ではないと思うので、自分にとっては良い経験になりました。特に今回は、SREに知見のある(界隈では神と呼ばれている方)にアドバイザーとしてフォローをいただきながら取り組めたことが貴重でした。
- シナリオ作成
- ツールの選定(負荷試験ツールはk6、APMはDatadog)
- 試験環境の作成
などやることは多かったのですが、その分現状の課題点をたくさん把握することができました。
試験後、インスタンス・DB構成の変更を行い実際にパフォーマンスの改善が行えたわけですが、パフォーマンス改善以外にもMackerelプラグインの追加、監視設定の改善、ログ管理の改善、APMの管理など、以前から課題に感じていた部分も合わせて改善できた部分も多くありました。
2021年に向けて見えてきた課題
(スライドをそのまま貼りたいところなのですが、社内でしかお見せできないところが多々あり、お伝えできる範囲で改めて文章に起こしています)
大きな課題として3つ挙げました。
- DevSecOpsと呼ばれる領域
- 検証環境作成の簡易化・自動化
- インフラコストの管理・最適化
DevSecOpsは、DevOpsの延長線上にあります。普段の開発ライフサイクルの中で、セキュリティの実施も組み込む取り組みです。これは昨今のクラウドネイティブな技術の進歩ととともに、セキュリティの分野でも自動化などの技術革新が進んだ結果、現実的に行える取り組みとなりました。
クラシコムでは、2020年にTerraformやローカル環境以外でのコンテナ技術の採用など、インフラ面での整備を進めた結果、セキュリティの自動化にも取り組めるベースがようやく整ったと感じ、改めて課題として挙げました。より具体的にどんなことをやるか(もしくはやったか)に関しては、別途記事を書きたいと思っています。
検証環境作成の簡易化・自動化に関しては、関係者も増え実施したい施策も増えてきており、今後さらに組織やサービスが拡大すると考えたときに、整備しておくことで工数ややりとりの手間を削減でき、リリースまでの速度短縮が望めるのではと考えています。
インフラコストの管理・最適化に関しては、今後さらに増えていくであろうサーバーやSaasなどのサービス群を適切に管理することで、利益の損失を抑えることが目的になります。
その先の未来
クラシコムのエンジニアは、個々人の志向性としてフルスタックでありたい人もいますし、人数が少ないという環境であることからフルスタックであることも時には求められます。
そんな中SREというポジションがあるのは、今までインフラ面をうまく見ることができなかった時期もあり、腰を据えて改善をする必要があったためです。
改善を続けて改めて思ったことは、SREはインフラだけ見ていれば良いものではなく、また、他のエンジニアもインフラをまったく気にしなくて良いということではありませんでした。
SREの責務として障害管理などありますが、障害になるのはインフラ側の問題ではなくアプリケーション側の実装・設計の問題となることも少なくありません。
SRE以外のエンジニアの見える範囲、できる範囲も増やしてやることで、そういった問題を抱える可能性を低くしていきたいと今は考えています。
社内での発表時、[SREの民主化とクラウド移行]という記事のタイトルから拝借させていただき、2021年の課題の先にやりたいことは「SREの民主化」であると伝えました。
この記事でも書かれていますが、つまるところは権限を移譲することで、安全に組織をスケールしていける状態を作りだしたいと僕も考えています。そのためには整備しなければいけないことがまだまだたくさんあるのですが、コツコツと改善を加えていれば気づいたときには遠くへたどり着けているであろうと信じています。
建てて終わりではない。式年遷宮は続く。
いざ振り返ってみると、1年でも遠くまで来たなというか、前進を感じました。
でも一回整備できたら終わりではない。(例えるのも恐れ多いですが)式年遷宮のように作り続けていくことが必要だと強く感じています。
式年遷宮は20年だけど、ソフトウェアは4年かな。ソフトウェアの減価償却期間が4年ですからね。
もしクラシコムに興味を持ってくださった方がいらっしゃったら、一緒に高速道路の整備方法について話しませんか?